Čau Habr!
Po novoročních svátcích jsme znovu spustili cloud odolný proti katastrofám založený na dvou stránkách. Dnes vám řekneme, jak to funguje, a ukážeme si, co se stane s klientskými virtuálními stroji, když jednotlivé prvky clusteru selžou a celý web se zhroutí (spoiler – s nimi je vše v pořádku).
Cloudový úložný systém odolný proti katastrofám na webu OST.
Co je uvnitř
Pod kapotou clusteru jsou servery Cisco UCS s hypervizorem VMware ESXi, dva úložné systémy INFINIDAT InfiniBox F2240, síťové vybavení Cisco Nexus a také přepínače Brocade SAN. Cluster je rozdělen do dvou lokalit – OST a NORD, to znamená, že každé datové centrum má identickou sadu zařízení. Vlastně díky tomu je odolný vůči katastrofám.
V rámci jednoho webu jsou také duplikovány hlavní prvky (hostitelé, přepínače SAN, sítě).
Tyto dvě lokality jsou propojeny vyhrazenými trasami z optických vláken, které jsou rovněž vyhrazeny.
Pár slov o úložných systémech. Na NetApp jsme postavili první verzi cloudu odolného proti katastrofě. Zde jsme vybrali INFINIDAT a zde je důvod:
- Možnost aktivní-aktivní replikace. Umožňuje virtuálnímu počítači zůstat funkční, i když jeden z úložných systémů zcela selže. Více o replikaci vám řeknu později.
- Tři řadiče disků pro zvýšení odolnosti proti chybám systému. Obvykle jsou dva.
- Připravené řešení. Dostali jsme předmontovaný rack, který stačí připojit k síti a nakonfigurovat.
- Pozorná technická podpora. Inženýři INFINIDAT neustále analyzují protokoly a události úložného systému, instalují nové verze firmwaru a pomáhají s konfigurací.
Tady je pár fotek z rozbalování:
Jak to funguje?
Cloud je již sám o sobě odolný vůči chybám. Chrání klienta před selháním jednoho hardwaru a softwaru. Odolnost proti katastrofám pomůže chránit před masivními poruchami v rámci jednoho webu: například selhání systému úložiště (nebo clusteru SDS, což se stává poměrně často 🙂), velké chyby v síti úložiště atd. No a hlavně: takový cloud ušetří, když se kvůli požáru, blackoutu, převzetí nájezdníků nebo přistání mimozemšťanů stane celá lokalita nedostupná.
Ve všech těchto případech klientské virtuální stroje nadále fungují a zde je důvod.
Návrh clusteru je navržen tak, aby každý hostitel ESXi s klientskými virtuálními stroji měl přístup k jakémukoli ze dvou úložných systémů. Pokud úložný systém na webu OST selže, virtuální stroje budou nadále fungovat: hostitelé, na kterých běží, budou přistupovat k úložnému systému na NORD pro data.
Takto vypadá schéma zapojení v clusteru.
To je možné díky skutečnosti, že mezi strukturami SAN těchto dvou lokalit je nakonfigurováno propojení mezi přepínači: přepínač Fabric A OST SAN je připojen k přepínači Fabric A NORD SAN a podobně pro přepínače Fabric B SAN.
Aby všechny tyto složitosti továren SAN dávaly smysl, je mezi dvěma úložnými systémy nakonfigurována replikace Active-Active: informace jsou téměř současně zapisovány do lokálních a vzdálených úložných systémů, RPO = 0. Ukazuje se, že původní data jsou uložena na jednom úložném systému a jeho replika je uložena na druhém. Data jsou replikována na úrovni úložných svazků a data VM (jeho disky, konfigurační soubor, odkládací soubor atd.) jsou uložena na nich.
Hostitel ESXi vidí primární svazek a jeho repliku jako jedno diskové zařízení (úložné zařízení). Existuje 24 cest z hostitele ESXi ke každému diskovému zařízení:
12 cest jej připojuje k místnímu úložnému systému (optimální cesty) a zbývajících 12 ke vzdálenému úložnému systému (neoptimální cesty). V normální situaci ESXi přistupuje k datům v místním úložném systému pomocí „optimálních“ cest. Když tento úložný systém selže, ESXi ztratí optimální cesty a přepne se na „neoptimální“. Takhle to vypadá na diagramu.
Schéma clusteru odolného proti katastrofě.
Všechny klientské sítě jsou připojeny k oběma lokalitám prostřednictvím společné síťové struktury. Každý web provozuje Provider Edge (PE), na kterém jsou sítě klienta ukončeny. PE jsou sjednoceni do společného clusteru. Pokud PE na jednom webu selže, veškerý provoz je přesměrován na druhý web. Díky tomu zůstávají virtuální stroje ze stránky ponechané bez PE přístupné přes síť klientovi.
Pojďme se nyní podívat, co se stane s klientskými virtuálními stroji při různých selháních. Začněme nejlehčími možnostmi a skončeme tou nejzávažnější – selháním celého webu. V příkladech bude hlavní platforma OST a záložní platforma s replikami dat bude NORD.
Co se stane s klientským virtuálním strojem, když...
Odkaz replikace se nezdaří. Replikace mezi úložnými systémy dvou lokalit se zastaví.
ESXi bude fungovat pouze s místními diskovými zařízeními (přes optimální cesty).
Virtuální stroje nadále fungují.
ISL (Inter-Switch Link) se přeruší. Případ je nepravděpodobný. Ledaže by nějaký šílený bagr vykopal několik optických tras najednou, které jezdí po nezávislých trasách a jsou na místa přiváděny různými vstupy. Ale stejně. V tomto případě hostitelé ESXi ztratí polovinu cest a mohou přistupovat pouze ke svým lokálním úložným systémům. Repliky se shromažďují, ale hostitelé k nim nebudou mít přístup.
Virtuální stroje fungují normálně.
Přepínač SAN selže na jednom z webů. Hostitelé ESXi ztrácejí některé cesty k úložnému systému. V tomto případě budou hostitelé v místě, kde selhal přepínač, fungovat pouze prostřednictvím jednoho z jejich HBA.
Virtuální stroje nadále normálně fungují.
Všechny přepínače SAN na jednom z webů selžou. Řekněme, že taková katastrofa se stala na webu OST. V tomto případě hostitelé ESXi na tomto webu ztratí všechny cesty ke svým diskovým zařízením. Do hry vstupuje standardní mechanismus VMware vSphere HA: restartuje všechny virtuální stroje OST webu v NORD maximálně za 140 sekund.
Virtuální stroje běžící na hostitelích serveru NORD fungují normálně.
Hostitel ESXi selže na jednom webu. Zde opět funguje mechanismus vSphere HA: virtuální stroje z neúspěšného hostitele jsou restartovány na jiných hostitelích – na stejném nebo vzdáleném místě. Doba restartu virtuálního počítače je až 1 minuta.
Pokud selžou všichni hostitelé ESXi na webu OST, neexistují žádné možnosti: virtuální počítače se restartují na jiném. Doba restartu je stejná.
Úložný systém selže na jednom místě. Řekněme, že systém úložiště selže na webu OST. Poté hostitelé ESXi webu OST přejdou na práci s replikami úložiště v NORD. Poté, co se neúspěšný úložný systém vrátí do provozu, dojde k vynucené replikaci a hostitelé ESXi OST znovu začnou přistupovat k místnímu úložnému systému.
Virtuální stroje celou tu dobu normálně fungovaly.
Jeden z webů selže. V tomto případě budou všechny virtuální stroje restartovány na záložním místě prostřednictvím mechanismu vSphere HA. Doba restartu virtuálního počítače je 140 sekund. V tomto případě budou všechna síťová nastavení virtuálního počítače uložena a zůstane klientovi přístupná přes síť.
Aby bylo zajištěno, že restartování počítačů na záložním místě proběhne hladce, je každé místo plné pouze z poloviny. Druhá polovina je rezerva pro případ, že by se všechny virtuální stroje přesunuly z druhého, poškozeného webu.
Cloud odolný proti katastrofám založený na dvou datových centrech chrání před takovými selháními.
Toto potěšení není levné, protože kromě hlavních zdrojů je na druhém místě potřeba rezerva. Do takového cloudu jsou proto umisťovány služby kritické pro podnikání, jejichž dlouhodobý výpadek způsobuje velké finanční ztráty a ztráty na reputaci nebo pokud informační systém podléhá požadavkům regulátorů nebo vnitropodnikových předpisů na odolnost vůči katastrofám.
Zdroje:
Zdroj: www.habr.com