Hyper-V, geograficky oddělený cluster a Live Migration

Nedávno jsem řešil jednu zajímavou situaci, kdy bylo nutné zajistit vysokou dostupnost Hyper-V ve dvou lokalitách, primární a záložní. Řešení, které vzniklo může být zajímavou inspirací pro ostatní. Windows Server 2008 (resp. 2008 R2) podporuje clustery v oddělených lokalitách, není tedy nutné žádný další SW pro podporu clusterování v oddělených lokalitách. Jako storage bylo připraveno řešení EMC Clariion CX4, kde se jednotlivé storage replikovaly synchronně navzájem, tím byla zajištěna data na obou lokalitách. Při návrhu se zvažovaly 2 varianty a to jeden nebo dva nody clusteru na každé lokalitě. Proč tedy 2 nody na každé lokalitě? V případě výpadku jednoho fyzického serveru může převzít funkcionalitu druhý server, aniž by se prováděl cluster failover na záložní lokalitu. Obě řešení jsou graficky znázorněna na obrázcích níže.

Ve výsledku bylo zvoleno řešení kompromisní, složené ze 3 serverů – 2 v primární lokalitě a 1 v sekundární lokalitě, který díky technologii Dynamic Memory (obsažený v SP1 pro Windows Server 2008 R2 – v době vzniku článku ve verzi RC) umožňuje dočasný provoz systémů s menším objemem paměti. Výsledná konfigurace je na následujícím obrázku.

Celá konfigurace byla doplněna o SW EMC SRDF/CE, nejedná se o žádný nový software, nicméně od verze 3.1 podporuje clustering a live migration v rámci Hyper-V, nicméně dle posledních informací není podporovaný Cluster Shared Volume, tedy každý virtuální stroj musí mít vlastní LUN, který provádí failover současně s virtuálním strojem. Dá se říci, že právě SRDF/CE je tou hlavní komponentou, která si rozumí se synchronní replikou na storage a také rozumí a konfiguruje Windows Cluster service. Po instalaci SRDF/CE na všechny nody clusteru je nutné spustit tento nástroj (EMC Cluster enabler manager), kde v prvním kroku je zvolen Windows cluster, provedeno discovery storage na všech nodech clusteru a nainstalována a povolena služba Cluster Enabler Service v rámci Windows clusteru jako cluster resource. Pokud jsou zjištěny služby, které mají být vysoce dostupné pomocí Windows clusteru (kde Hyper-V je jedna z mnoha služeb), jsou tyto služby pomocí CE manageru konfigurovány. K jednotlivým službám je přidán resource, na kterém závisí storage resource (na ktrém závisí ostatní služby). Při provádění failover (Live migration) na nod clusteru ve vzdálené lokalitě je nejprve přenesena RAM, konfigurace virtuálního stroje, následně se do Offline stavu přepne virtuální stroj, storage a EMC resource, proveden failover na jiný node clusteru a následně v opačném pořadí resources nastartovány. Schématické znázornění je na následujícím obrázku.

Celý proces migrace je pouze o něco málo pomalejší, nežli pokud je prováděn pouze v rámci jednoho storage a to především z důvodu potřeby synchronizace dat mezi dvěma lokalitami a přepnutím storage, nicméně se neustále bavíme v řádech sekund, nikoliv desítek sekund – zde velice záleží na vhodné konfiguraci storage a komunikace mezi lokalitami. Níže je video (anglicky) které ukazuje kompletní řešení v praxi (nebylo možné natočit ukázku z tohoto konkrétního řešení, které popisuji v článku).

Autor: Ondřej Výšek

Ondřej je Microsoft MVP od roku 2004, v roce 2008 založil komunitní web optimalizovane-it.cz. Za svou IT karieru, jenž započala v roce 1993 prošel celou řadou pozic, od konzultanta, přes architekt, až po vytváření vizí a strategií zákazníků. V prostředích, ve kterých pomáhal byly desítky, ale i stovky tisíc uživatelů a systémů. V posledních letech se zabývá především cloudovými technologiemi Microsoft 365 a Azure ve společnosti KPCS CZ.

Next Post Previous Post