Čau Habr!
Po novoročných sviatkoch sme znova spustili cloud odolný voči katastrofám na dvoch lokalitách. Dnes vám povieme, ako to funguje, a ukážeme si, čo sa stane s klientskymi virtuálnymi strojmi, keď zlyhajú jednotlivé prvky klastra a celá stránka spadne (spoiler – všetko je v poriadku).
Cloudový úložný systém odolný voči katastrofám na stránke OST.
Čo je vo vnútri
Pod kapotou klastra sú servery Cisco UCS s hypervízorom VMware ESXi, dva úložné systémy INFINIDAT InfiniBox F2240, sieťové zariadenia Cisco Nexus, ako aj prepínače Brocade SAN. Klaster je rozdelený na dve lokality – OST a NORD, t.j. každé dátové centrum má identickú sadu zariadení. V skutočnosti je to to, čo ho robí odolným voči katastrofám.
V rámci jednej lokality sa duplikujú aj hlavné prvky (hostia, prepínače SAN, sieťovanie).
Tieto dve lokality sú prepojené vyhradenými optickými trasami, ktoré sú tiež vyhradené.
Niekoľko slov o úložných systémoch. Na NetApp sme vytvorili prvú verziu cloudu odolného voči katastrofám. Tu sme vybrali INFINIDAT a tu je dôvod:
- Možnosť aktívnej-aktívnej replikácie. Umožňuje virtuálnemu stroju zostať funkčný, aj keď jeden z úložných systémov úplne zlyhá. Viac o replikácii vám poviem neskôr.
- Tri diskové radiče na zvýšenie odolnosti proti chybám systému. Zvyčajne sú dve.
- Pripravené riešenie. Dostali sme predmontovaný rack, ktorý stačí pripojiť k sieti a nakonfigurovať.
- Pozorná technická podpora. Inžinieri INFINIDAT neustále analyzujú protokoly a udalosti úložného systému, inštalujú nové verzie firmvéru a pomáhajú s konfiguráciou.
Tu je pár fotiek z rozbaľovania:
Ako to funguje
Cloud je už sám o sebe odolný voči chybám. Chráni klienta pred jednotlivými zlyhaniami hardvéru a softvéru. Odolnosť voči katastrofám pomôže chrániť pred masívnymi poruchami v rámci jednej lokality: napríklad zlyhanie úložného systému (alebo klastra SDS, čo sa stáva pomerne často 🙂), veľké chyby v sieti úložiska atď. Nuž a hlavne: takýto cloud šetrí, keď sa celá lokalita stane nedostupnou v dôsledku požiaru, výpadku prúdu, prevzatia nájazdníkov alebo pristátia mimozemšťanov.
Vo všetkých týchto prípadoch klientske virtuálne stroje naďalej fungujú a tu je dôvod.
Dizajn klastra je navrhnutý tak, aby každý hostiteľ ESXi s klientskymi virtuálnymi strojmi mohol pristupovať k akémukoľvek z dvoch úložných systémov. Ak úložný systém na lokalite OST zlyhá, virtuálne stroje budú naďalej fungovať: hostitelia, na ktorých bežia, budú pristupovať k úložnému systému na NORD kvôli údajom.
Takto vyzerá schéma zapojenia v klastri.
Je to možné vďaka skutočnosti, že medzi sieťami SAN týchto dvoch lokalít je nakonfigurované prepojenie medzi prepínačmi: prepínač Fabric A OST SAN je pripojený k prepínaču Fabric A NORD SAN a podobne aj prepínače Fabric B SAN.
Aby všetky tieto zložitosti tovární SAN dávali zmysel, medzi dvoma úložnými systémami je nakonfigurovaná Active-Active replikácia: informácie sa takmer súčasne zapisujú do lokálnych a vzdialených úložných systémov, RPO = 0. Ukázalo sa, že pôvodné dáta sú uložené na jednom úložnom systéme a jeho replika je uložená na druhom. Dáta sa replikujú na úrovni úložných zväzkov a dáta VM (jeho disky, konfiguračný súbor, odkladací súbor atď.) sú uložené na nich.
Hostiteľ ESXi vidí primárny zväzok a jeho repliku ako jedno diskové zariadenie (úložné zariadenie). Existuje 24 ciest z hostiteľa ESXi ku každému diskovému zariadeniu:
12 ciest ho pripája k lokálnemu úložnému systému (optimálne cesty) a zvyšných 12 k vzdialenému úložnému systému (neoptimálne cesty). V normálnej situácii ESXi pristupuje k údajom v lokálnom úložnom systéme pomocou „optimálnych“ ciest. Keď tento úložný systém zlyhá, ESXi stratí optimálne cesty a prepne sa na „neoptimálne“. Takto to vyzerá na diagrame.
Schéma klastra odolného voči katastrofe.
Všetky klientske siete sú pripojené k obom miestam prostredníctvom spoločnej sieťovej štruktúry. Každá lokalita prevádzkuje Provider Edge (PE), na ktorom sú siete klienta ukončené. Odborníci na služby sú zjednotení do spoločného klastra. Ak PE zlyhá na jednej lokalite, všetka prevádzka sa presmeruje na druhú lokalitu. Vďaka tomu zostávajú virtuálne stroje z lokality ponechané bez PE prístupné klientovi cez sieť.
Pozrime sa teraz, čo sa stane s klientskymi virtuálnymi strojmi počas rôznych porúch. Začnime tými najľahšími možnosťami a skončíme tým najzávažnejším – zlyhaním celej stránky. V príkladoch bude hlavnou platformou OST a záložnou platformou s replikami údajov bude NORD.
Čo sa stane s virtuálnym počítačom klienta, ak...
Prepojenie replikácie zlyhá. Replikácia medzi úložnými systémami týchto dvoch lokalít sa zastaví.
ESXi bude fungovať iba s lokálnymi diskovými zariadeniami (cez optimálne cesty).
Virtuálne stroje naďalej fungujú.
ISL (Inter-Switch Link) sa preruší. Nepravdepodobná udalosť. Ibaže by nejaký šialený bager vykopal naraz niekoľko optických trás, ktoré jazdia po nezávislých trasách a sú na miesta privádzané rôznymi vstupmi. Ale aj tak. V tomto prípade hostitelia ESXi stratia polovicu ciest a môžu pristupovať iba k svojim lokálnym úložným systémom. Repliky sa zhromažďujú, ale hostitelia k nim nebudú mať prístup.
Virtuálne stroje fungujú normálne.
Prepínač SAN zlyhá na jednej z lokalít. Hostitelia ESXi strácajú niektoré cesty k úložnému systému. V tomto prípade hostitelia na lokalite, kde prepínač zlyhal, budú fungovať iba prostredníctvom jedného z ich HBA.
Virtuálne počítače naďalej fungujú normálne.
Všetky prepínače SAN na jednej z lokalít zlyhajú. Povedzme, že takáto katastrofa sa stala na stránke OST. V tomto prípade hostitelia ESXi na tejto stránke stratia všetky cesty k svojim diskovým zariadeniam. Do hry vstupuje štandardný mechanizmus VMware vSphere HA: reštartuje všetky virtuálne stroje lokality OST v NORD maximálne za 140 sekúnd.
Virtuálne stroje bežiace na hostiteľoch lokality NORD fungujú normálne.
Hostiteľ ESXi zlyhá na jednej lokalite. Tu mechanizmus vSphere HA opäť funguje: virtuálne stroje z neúspešného hostiteľa sa reštartujú na iných hostiteľoch - na rovnakom alebo vzdialenom mieste. Čas reštartovania virtuálneho počítača je až 1 minúta.
Ak zlyhajú všetci hostitelia ESXi na lokalite OST, neexistujú žiadne možnosti: VM sa reštartujú na inom. Čas reštartu je rovnaký.
Úložný systém zlyhá na jednom mieste. Povedzme, že úložný systém zlyhá na lokalite OST. Potom hostitelia ESXi lokality OST prepnú na prácu s replikami úložiska v NORD. Keď sa chybný úložný systém vráti do prevádzky, dôjde k vynútenej replikácii a hostitelia ESXi OST opäť začnú pristupovať k lokálnemu úložnému systému.
Virtuálne stroje celý ten čas fungovali normálne.
Jedna z lokalít zlyhá. V tomto prípade budú všetky virtuálne stroje reštartované na záložnej lokalite prostredníctvom mechanizmu vSphere HA. Čas reštartu VM je 140 sekúnd. V tomto prípade sa všetky sieťové nastavenia virtuálneho počítača uložia a klient zostane prístupný cez sieť.
Aby sa zabezpečilo, že reštartovanie počítačov v zálohovacej lokalite prebehne hladko, každá lokalita je plná len z polovice. Druhá polovica je rezerva pre prípad, že by sa všetky virtuálne stroje presunuli z druhého, poškodeného miesta.
Cloud odolný voči katastrofám založený na dvoch dátových centrách chráni pred takýmito zlyhaniami.
Toto potešenie nie je lacné, pretože okrem hlavných zdrojov je potrebná rezerva na druhom mieste. Preto sú do takého cloudu umiestňované služby kritické pre podnikanie, ktorých dlhodobý výpadok spôsobuje veľké finančné straty a straty na reputácii, alebo ak informačný systém podlieha požiadavkám regulátorov alebo vnútropodnikových predpisov na odolnosť voči katastrofám.
Zdroje:
Zdroj: hab.com