V rámci Hyper-V clusteru jsou k dispozici dvě základní metody přesunu virtuálního serveru (VM, z angl. Virtual Machine) mezi nody.
Pro zajištění vysoké dostupnosti na úrovni virtual machine (virtuální server, zkr. VM) Windows Failover Clustering, máme na výběr dvě možnosti pro přesun VM mezi jednotlivými nody clusteru a to Quick a Live Migration.V rámci tohoto článku si ukážeme v čem se jednotlivé možnosti liší jak z pohledu architektury, tak z pohledu výkonnostích metrik.
S příchodem první verze Hyper-V na operační systému Windows Server 2008 byla k dispozici možnost přesouvat VM pomocí metody Quick Migration. V další verzi – Winows Serveru 2008 R2 pak přibyla i metoda Live Migration – tedy bezvýpadkový přesun VM.
Požadavky a princip Quick Migration
Tato metoda nemá příliš specifické požadavky pro svou funkci. Jedná se pouze o běžné předpoklady vytvoření vysoce dostupného virtuálního serveru (HAVM, z angl. Highly Available Virtual Machine): umístění konfiguračních a VHD souborů na disky clusteru.
Při spuštění Quick Migration (QM) na běžící VM jsou provedeny tyto akce:
- Uložení operační paměti do souboru (umístění ve složce s konfiguračními soubory)
- Přesun/přepnutí disků obsahující soubory VM na cílový nod clusteru
- Obnovení operační paměti ze souboru
V podstatě tedy rychlost takovéto migrace VM je závislá na rychlosti zápisu a čtění pří práci s operační pamětí.
Požadavky a princip Live Migration
Live Migration (LM) neboli „migrace zaživa“ byla jednou z velkých novinek na novém Windows Serveru 2008 R2 a byla velkým důvodem proč přejít na novou verzi. Už ze svého názvu je jejím hlavním přínosem nepřerušený běh VM a tak zajištění běhu poskytovaných služeb.Předpokladem pro použití LM je použití Cluster Shared Volumes jako umístění souborů VM a dále je doporučené vyhradit síťové rozhraní, po kterém budou přenášeny data při samotné migraci. Celá operace se skládá z těchto akcí:
- Kontrola všech komponent a prostředků
a. Identifikace zdrojového a cílového nodu
b. Navázání TCP/IP spojení mezi nody
c. Kontrola dostupnosti zdrojů, konfigurovaných u migrované VM a dostupných na zdrojovém nodu (shoda modelu fyzických procesorů, dostupná RAM a procesorový výkon, dostupnost potřebných zdrojů – síť, VHD soubory, (přímo mapované) passtrough disky, grafické adaptéry apod.) - Vytvoření stínové neaktivní kopie migrované VM na cílovém nodu clusteru
- Migrace neaktivních stránek operační paměti VM až do stavu nejvyšší shody
- Zachycení veškerých zápisů do paměti VM a jejich synchronizace do VM na cílovém nodu
- Pozdržení celkového I/O virtuálního serveru, přepnutí jeho komunikace na cílový nod, smazání původní konfigurace VM a start nové zmigrované entity na cílovém serveru
Trocha měření
Pro reálnou představu jsem provedl pár měření na části naší Learning infrastruktury, která běžně slouží k výuce kurzů.
Mé prostředí se skládalo ze dvou identických HP blade serverů BL460c G6 v Hyper-V clusteru, každý s operačním systémem Windows Server 2008 R2 SP1 Datacenter, 48GB RAM, dvěma 6ti jádrovými CPU a síťovou infrastrukturou postavenou na HP VirtualConnect Flex-10. K bladům bylo přes 8Gb Fibre Channel připojeno sdílené externí pole HP EVA 4400 s FC disky s 15k otáčkami.
Mezi nody byly kromě sítě pro správu a komunikace virtuálního serveru nakonfigurovanýny privátní sítě pro cluster heartbeat síť (1Gb) a live migraci (při testech 4,7Gb nebo 100Mb). Připravil jsem jeden vzorový virtuální server s operačním systémem Windows Server 2008 R2 SP1 Standard a na něm simuloval různou zátěž pomocí nástrojů CPUBurn, Bart’s Stuff Test v1.5.4 a SQLIOSIM monitorovanou integrovaným Performance Monitoringem a aplikací RAMMap.
Konfigurace VM se v průběhu testů měnila, také její zátěž, a měřil jsem dobu trvání Quick a Live Migration a počet „ztracených“ pingů. V posledním testu jsem využil možnosti konfigurace rychlosti sítě pro LM díky VirtualConnectu a ověřil její vliv na dobu trvání. Každé měření jsem provedl 5krát a použitá hodnota tak byla průměrem naměřených, abych se vyhnul nepřesnostem ve výsledcích.
Měření doby trvání migrace bylo provedeno zároveň při její inicializaci pomocí Powershellu.
Pro Quick Migration:
Measure-Command -Expression {
Get-ClusterGroup názevresourcuVM | Move-ClusterGroup -Node cílovýnod}
Pro Live Migration:
Measure-Command -Expression {
Move-ClusterVirtualMachineRole názevresourcuVM –Node cílovýnod}
Výstupy
Závěry a grafy
Měření číslo 2 potrvdilo očekávané prodloužení doby trvání QM i LM. Vetší množství alokované RAM (1,4GB) si vyžádalo zápis většího množství dat do souboru při QM a také větší množství přenesených stránek RAM při LM. Měření číslo 3 pak poukázalo že se nejedná o přímo úměrné prodloužení těchto časů.
Z měření číslo 4 vyplývá, že zvětšení zátěže na diskový subsystém nemá příliš velký vliv na obě migrace. Doba trvání LM dokonce klesla oproti měření č. 3, ale zde se jedná o nepřesnosti měření, protože tomu mělo být spíše naopak.
U měření č. 5 je jasně vidět, jak moc je důležité mít vůbec dedikovanou síť pro LM a použít maximální možnou rychlost. Rekonfigurací z 4,7Gb na 100Mb se prodloužila doba trvání LM z 2 minut na 31 minut, tedy 15-ti násobně. Měření QM v tomto případě vůbec provedené nebylo, protože rychlost LM sítě nemá na její dobu trvání žádný vliv.
Z uvedených výsledků jasně vyplývá, že rozdíl mezi použitím QM a LM je markantní, ale při velkých zátěžích se také rapidně prodlužuje doba trvání LM. Stejně tak použití „pomalého“ diskového subsystému u metody QM značně prodlužuje její trvání. Live Migration má také vyšší nároky na hardware a konfiguraci.
Autor: Jan Marek
Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.
