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