reklama

Quick versus Live Migration

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:

  1. Uložení operační paměti do souboru (umístění ve složce s konfiguračními soubory)
  2. Přesun/přepnutí disků obsahující soubory VM na cílový nod clusteru
  3. 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í.

Klepněte pro větší obrázek

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í:

  1. 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.)
  2. Vytvoření stínové neaktivní kopie migrované VM na cílovém nodu clusteru
  3. Migrace neaktivních stránek operační paměti VM až do stavu nejvyšší shody
  4. Zachycení veškerých zápisů do paměti VM a jejich synchronizace do VM na cílovém nodu
  5. 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

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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

Klepněte pro větší obrázek Klepněte pro větší obrázek

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ů.

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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.

Klepněte pro větší obrázek

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.

Témata článku: Quick, Move, Cluster, Command, Bart, Stuff

Nejnovější komentáře

Můj názor
reklama
Určitě si přečtěte

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

UPC překopli páteřní kabel. V Brně i druhý den nejede internet ani kabelovka

** V Brně byl velký výpadek služeb UPC ** Důvodem je překopnutý páteřní kabel ** V některých lokalitách služby stále nefungují

5.  12.  2016 | Jakub Čížek | 100

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

17 expertek Microsoftu předpovědělo rok 2027. Splní se alespoň něco?

** Zmizí klasické vyhledávače ** Budeme programovat buňky ** Kvantové počítače překonají šifry

6.  12.  2016 | Jakub Čížek | 35

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

** Novinka od Asusu míří přímo proti MacBooku od Applu ** Nabídne daleko více výkonu za stejné peníze

2.  12.  2016 | David Polesný | 146

11 tipů na dobrý stolní počítač: od základu po herní mašiny

11 tipů na dobrý stolní počítač: od základu po herní mašiny

** Postavte si stolní počítač! Máme pro vás 11 vzorových sestav s rozpisem komponent ** Většina tipů cílí na hráče, věnujeme se ale i základnímu PC a počítačům na střih videa ** Nadělte si nový počítač třeba pod stromeček

5.  12.  2016 | Adam Kahánek | 73


reklama