Dobrý deň, čitatelia Habr! V minulom článku sme hovorili o jednoduchom prostriedku obnovy po havárii v úložných systémoch AERODISK ENGINE – replikácii. V tomto článku sa ponoríme do zložitejšej a zaujímavejšej témy – metrocluster, teda prostriedok automatizovanej ochrany pred katastrofami pre dve dátové centrá, umožňujúci dátovým centrám fungovať v aktívnom – aktívnom režime. My vám to povieme, ukážeme, rozbijeme a opravíme.
Ako obvykle, najprv teória
Metrocluster je zoskupenie rozmiestnené na niekoľkých miestach v rámci mesta alebo regiónu. Slovo „klaster“ nám jasne naznačuje, že komplex je automatizovaný, to znamená, že k prepínaniu uzlov klastra v prípade porúch dochádza automaticky.
Tu je hlavný rozdiel medzi metroklastrom a pravidelnou replikáciou. Automatizácia operácií. To znamená, že v prípade určitých incidentov (zlyhanie dátového centra, nefunkčné kanály atď.) úložný systém nezávisle vykoná potrebné akcie, aby bola zachovaná dostupnosť dát. Pri používaní bežných replík tieto akcie vykonáva úplne alebo čiastočne manuálne správca.
Čo to robí?
Hlavným cieľom, ktorý zákazníci sledujú pri používaní určitých implementácií metroklastrov, je minimalizovať RTO (Recovery Time Objective). Teda minimalizovať čas obnovy IT služieb po zlyhaní. Ak používate pravidelnú replikáciu, čas obnovy bude vždy dlhší ako čas obnovy s metroklastrom. prečo? Veľmi jednoduché. Administrátor musí byť pri svojom stole a replikovať prepínač manuálne a metrocluster to robí automaticky.
Ak nemáte v službe vyhradeného správcu, ktorý nespí, neje, nefajčí, neochorie a 24 hodín denne sleduje stav skladového systému, potom nie je možné zaručiť, že správca bude byť k dispozícii na manuálne prepnutie pri poruche.
V súlade s tým sa RTO pri absencii metroklastra alebo nesmrteľného správcu 99. úrovne služby správcovskej povinnosti bude rovnať súčtu prepínacích časov všetkých systémov a maximálnej doby, po ktorej je zaručené, že správca začne pracovať s úložnými systémami a súvisiacimi systémami.
Dospeli sme teda k jasnému záveru, že metrocluster by sa mal použiť v prípade, že požiadavka na RTO sú minúty, nie hodiny alebo dni. To znamená, že v prípade najhoršieho zlyhania dátového centra musí IT oddelenie poskytnúť podniku čas obnoviť prístup k IT službám v priebehu niekoľkých minút alebo dokonca sekúnd.
Ako to funguje?
Na nižšej úrovni používa metroklaster mechanizmus na synchrónnu replikáciu údajov, ktorý sme opísali v predchádzajúcom článku (pozri. ). Keďže replikácia je synchrónna, požiadavky na ňu zodpovedajú, alebo skôr:
- optické vlákno ako fyzika, 10 gigabitový Ethernet (alebo vyšší);
- vzdialenosť medzi dátovými centrami nie je väčšia ako 40 kilometrov;
- oneskorenie optického kanála medzi dátovými centrami (medzi úložnými systémami) je až 5 milisekúnd (optimálne 2).
Všetky tieto požiadavky majú poradný charakter, to znamená, že metroklaster bude fungovať, aj keď tieto požiadavky nebudú splnené, ale musíme pochopiť, že následky nedodržania týchto požiadaviek sa rovnajú spomaleniu prevádzky oboch skladovacích systémov v r. metroklaster.
Synchrónna replika sa teda používa na prenos dát medzi úložnými systémami a ako sa repliky automaticky prepínajú a hlavne ako sa vyhnúť split-brain? Na to sa na vyššej úrovni používa dodatočný subjekt - rozhodca.
Ako funguje rozhodca a čo je jeho úlohou?
Arbiter je malý virtuálny stroj alebo hardvérový klaster, ktorý musí byť spustený na treťom mieste (napríklad v kancelárii) a poskytuje prístup k úložnému systému cez ICMP a SSH. Po spustení by mal rozhodca nastaviť IP a potom zo strany úložiska uviesť svoju adresu plus adresy diaľkových ovládačov, ktoré sa zúčastňujú metroklastra. Potom je rozhodca pripravený pracovať.
Arbiter neustále monitoruje všetky úložné systémy v metroklastri a ak je konkrétny úložný systém nedostupný, po potvrdení nedostupnosti od iného člena klastra (jeden zo „živých“ úložných systémov) sa rozhodne spustiť procedúru prepínania pravidiel replikácie. a mapovanie.
Veľmi dôležitý bod. Rozhodca musí byť vždy umiestnený na inom mieste, ako sú tie, na ktorých sa nachádzajú úložné systémy, teda ani v dátovom centre 1, kde je nainštalovaný úložný systém 1, ani v dátovom centre 2, kde je nainštalovaný úložný systém 2.
prečo? Pretože len tak môže rozhodca s pomocou jedného z dochovaných úložných systémov jednoznačne a presne určiť pád ktoréhokoľvek z dvoch miest, kde sú úložné systémy nainštalované. Akékoľvek iné spôsoby umiestnenia rozhodcu môžu viesť k rozštiepeniu mozgu.
Teraz sa poďme ponoriť do detailov práce arbitra.
Rozhodca prevádzkuje niekoľko služieb, ktoré neustále zisťujú všetky radiče úložiska. Ak sa výsledok ankety líši od predchádzajúceho (dostupný/nedostupný), tak je zaznamenaný v malej databáze, ktorá funguje aj na arbitrovi.
Pozrime sa na logiku práce rozhodcu podrobnejšie.
Krok 1: Zistite nedostupnosť. Udalosť zlyhania úložného systému je neprítomnosť príkazu ping z oboch radičov toho istého úložného systému do 5 sekúnd.
Krok 2. Spustite postup prepínania. Keď rozhodca zistí, že jeden z úložných systémov je nedostupný, odošle požiadavku na „živý“ úložný systém, aby sa uistil, že „mŕtvy“ úložný systém je skutočne mŕtvy.
Po prijatí takéhoto príkazu od rozhodcu druhý (živý) úložný systém dodatočne skontroluje dostupnosť padlého prvého úložného systému a ak tam nie je, pošle arbitrovi potvrdenie o jeho odhade. Úložný systém je skutočne nedostupný.
Po prijatí takéhoto potvrdenia rozhodca spustí vzdialenú procedúru na prepnutie replikácie a zvýšenie mapovania na tých replikách, ktoré boli aktívne (primárne) na spadnutom úložnom systéme, a pošle príkaz do druhého úložného systému, aby zmenil tieto repliky zo sekundárnych na primárne a zvýšiť mapovanie. Druhý úložný systém teda vykonáva tieto postupy a potom poskytuje prístup k strateným jednotkám LUN sám od seba.
Prečo je potrebné dodatočné overenie? Pre kvórum. To znamená, že väčšina z celkového nepárneho (3) počtu členov klastra musí potvrdiť pád jedného z uzlov klastra. Len vtedy bude toto rozhodnutie definitívne správne. Je to potrebné, aby sa predišlo chybnému prepínaniu a tým aj rozdeleniu mozgu.
Časový krok 2 trvá približne 5 - 10 sekúnd, takže berúc do úvahy čas potrebný na určenie nedostupnosti (5 sekúnd), do 10 - 15 sekúnd po nehode budú LUN z padnutého úložného systému automaticky dostupné na prácu so živými úložný systém.
Je jasné, že aby ste sa vyhli strate spojenia s hostiteľmi, musíte sa postarať aj o správnu konfiguráciu časových limitov na hostiteľoch. Odporúčaný časový limit je aspoň 30 sekúnd. To zabráni hostiteľovi prerušiť spojenie s úložným systémom počas prepínania záťaže v prípade katastrofy a môže zabezpečiť, že nedôjde k žiadnym prerušeniam I/O.
Počkajte chvíľu, ukáže sa, že ak je všetko s metroklastrom také dobré, prečo vôbec potrebujeme pravidelnú replikáciu?
V skutočnosti nie je všetko také jednoduché.
Uvažujme o výhodách a nevýhodách metroklastra
Takže sme si uvedomili, že zjavné výhody metroklastra v porovnaní s konvenčnou replikáciou sú:
- Plná automatizácia zaisťujúca minimálny čas obnovy v prípade havárie;
- To je všetko :-).
A teraz pozor, nevýhody:
- Náklady na riešenie. Metrocluster v systémoch Aerodisk síce nevyžaduje dodatočné licencovanie (používa sa rovnaká licencia ako na repliku), ale cena riešenia bude stále ešte vyššia ako pri použití synchrónnej replikácie. Budete musieť implementovať všetky požiadavky na synchrónnu repliku plus požiadavky na metroklaster spojené s dodatočným prepínaním a dodatočným miestom (pozri plánovanie metroklastra);
- Zložitosť riešenia. Metrocluster je oveľa zložitejší ako bežná replika a vyžaduje oveľa viac pozornosti a úsilia pri plánovaní, konfigurácii a dokumentácii.
Nakoniec. Metrocluster je určite veľmi technologicky vyspelé a dobré riešenie, keď skutočne potrebujete poskytnúť RTO v priebehu niekoľkých sekúnd alebo minút. Ale ak takáto úloha neexistuje a RTO v hodinách je pre podnikanie v poriadku, potom nemá zmysel strieľať vrabce z dela. Bežná replikácia robotník-roľník je dostatočná, pretože klaster metra spôsobí dodatočné náklady a komplikácie IT infraštruktúry.
Plánovanie Metroclusterov
Táto časť si nerobí nárok na to, aby bola komplexným sprievodcom návrhom metroklastrov, ale ukazuje iba hlavné smery, ktoré by ste mali vypracovať, ak sa rozhodnete vybudovať takýto systém. Preto pri samotnej implementácii metroklastra určite zapojte na konzultácie výrobcu úložného systému (teda nás) a ďalších súvisiacich systémov.
Weby
Ako je uvedené vyššie, metroklaster vyžaduje minimálne tri miesta. Dve dátové centrá, kde budú fungovať úložné systémy a súvisiace systémy, ako aj tretie miesto, kde bude pôsobiť rozhodca.
Odporúčaná vzdialenosť medzi dátovými centrami nie je väčšia ako 40 kilometrov. Väčšia vzdialenosť s vysokou pravdepodobnosťou spôsobí dodatočné oneskorenia, ktoré sú v prípade metroklastra krajne nežiaduce. Pripomeňme, že oneskorenia by mali byť do 5 milisekúnd, aj keď je vhodné dodržať ich do 2.
Odporúča sa kontrolovať meškania aj počas plánovacieho procesu. Každý viac či menej vyspelý poskytovateľ, ktorý poskytuje optické vlákno medzi dátovými centrami, dokáže zorganizovať kontrolu kvality pomerne rýchlo.
Čo sa týka oneskorení pred arbitrom (teda medzi treťou lokalitou a prvými dvoma), odporúčaná hranica oneskorenia je do 200 milisekúnd, čiže vhodné je bežné firemné VPN pripojenie cez internet.
Prepínanie a vytváranie sietí
Na rozdiel od replikačnej schémy, kde stačí pripojiť úložné systémy z rôznych lokalít, schéma metroklastra vyžaduje prepojenie hostiteľov s oboma úložnými systémami na rôznych miestach. Aby bolo jasnejšie, v čom je rozdiel, nižšie sú uvedené obe schémy.
Ako je možné vidieť z diagramu, naši hostitelia lokality 1 sa pozerajú na úložný systém 1 aj úložný systém 2. Naopak, hostitelia lokality 2 sa pozerajú na úložný systém 2 aj úložný systém 1. To znamená, že každý hostiteľ vidí oba úložné systémy. To je predpokladom fungovania metroklastra.
Samozrejme, nie je potrebné pripájať každého hostiteľa optickým káblom k inému dátovému centru, nebudú stačiť žiadne porty ani káble. Všetky tieto pripojenia musia byť uskutočnené prostredníctvom prepínačov Ethernet 10G+ alebo FibreChannel 8G+ (FC je len na pripojenie hostiteľov a úložných systémov pre IO, replikačný kanál je momentálne dostupný len cez IP (Ethernet 10G+).
Teraz pár slov o topológii siete. Dôležitým bodom je správna konfigurácia podsietí. Je potrebné okamžite definovať niekoľko podsietí pre nasledujúce typy prevádzky:
- Replikačná podsieť, cez ktorú sa budú synchronizovať údaje medzi úložnými systémami. Môže ich byť niekoľko, v tomto prípade je to jedno, všetko závisí od aktuálnej (už implementovanej) topológie siete. Ak sú dve z nich, je zrejmé, že medzi nimi musí byť nakonfigurované smerovanie;
- Úložné podsiete, cez ktoré budú hostitelia pristupovať k úložným prostriedkom (ak ide o iSCSI). V každom dátovom centre by mala byť jedna takáto podsieť;
- Kontrolné podsiete, teda tri smerovateľné podsiete na troch miestach, z ktorých sa spravujú úložné systémy a je tam umiestnený aj arbiter.
Neberieme do úvahy podsiete pre prístup k hostiteľským zdrojom, pretože sú veľmi závislé od úloh.
Oddelenie rôznej prevádzky do rôznych podsietí je mimoriadne dôležité (obzvlášť dôležité je oddeliť repliku od I/O), pretože ak zmiešate všetku premávku do jednej „hrubej“ podsiete, nebude možné túto prevádzku riadiť a v podmienkach dvoch dátových centier to stále môže spôsobiť rôzne možnosti kolízie siete. V rámci tohto článku sa tejto problematike nebudeme hlbšie venovať, pretože o plánovaní siete natiahnutej medzi dátovými centrami si môžete prečítať na zdrojoch výrobcov sieťových zariadení, kde je to veľmi podrobne popísané.
Konfigurácia arbitra
Rozhodca musí zabezpečiť prístup ku všetkým riadiacim rozhraniam úložného systému prostredníctvom protokolov ICMP a SSH. Mali by ste myslieť aj na bezpečnosť arbitra. Je tu nuansa.
Prepnutie pri zlyhaní arbitra je veľmi žiaduce, ale nevyžaduje sa. Čo sa stane, ak rozhodca havaruje v nesprávnom čase?
- Prevádzka metroklastra v normálnom režime sa nezmení, pretože arbtir nemá absolútne žiadny vplyv na fungovanie metroklastra v normálnom režime (jeho úlohou je včas prepínať záťaž medzi dátovými centrami)
- Navyše, ak rozhodca z toho či onoho dôvodu spadne a „prespí“ nehodu v dátovom centre, k žiadnemu prepínaniu nedôjde, pretože nebude mať kto dať potrebné príkazy na prepnutie a zorganizovať kvórum. V tomto prípade sa metrocluster zmení na bežnú schému s replikáciou, ktorú bude potrebné manuálne prepnúť pri katastrofe, ktorá ovplyvní RTO.
Čo z toho vyplýva? Ak skutočne potrebujete zabezpečiť minimálnu RTO, musíte zabezpečiť, aby bol arbiter odolný voči chybám. Sú na to dve možnosti:
- Spustite virtuálny stroj s arbitrom na hypervízore odolnom voči chybám, našťastie všetky dospelé hypervízory podporujú odolnosť voči chybám;
- Ak ste na treťom mieste (v bežnej kancelárii) príliš leniví na inštaláciu normálneho klastra a neexistuje žiadny klaster hypervozor, potom sme poskytli hardvérovú verziu arbitra, ktorá je vyrobená v 2U krabici, v ktorej sú dve bežné x-86 servery fungujú a môžu prežiť lokálne zlyhanie.
Dôrazne odporúčame zabezpečiť odolnosť arbitra voči poruchám napriek tomu, že metrocluster to v normálnom režime nepotrebuje. Ale ako ukazuje teória aj prax, ak vybudujete skutočne spoľahlivú infraštruktúru odolnú voči katastrofám, potom je lepšie hrať na istotu. Je lepšie chrániť seba a svoje podnikanie pred „zákonom podlosti“, to znamená pred zlyhaním arbitra a jedného z miest, kde sa nachádza úložný systém.
Architektúra riešenia
Vzhľadom na vyššie uvedené požiadavky dostaneme nasledujúcu všeobecnú architektúru riešenia.
LUN by mali byť rovnomerne rozmiestnené na dvoch miestach, aby sa predišlo vážnemu preťaženiu. Zároveň by ste pri dimenzovaní v oboch dátových centrách mali zahrnúť nielen dvojnásobný objem (ktorý je potrebný na súčasné ukladanie dát na dvoch úložných systémoch), ale aj dvojnásobný výkon v IOPS a MB/s, aby ste predišli degradácii aplikácie v v prípade výpadku jedného z dátových centier ov.
Samostatne poznamenávame, že pri správnom prístupe k dimenzovaniu (t. j. za predpokladu, že sme poskytli správne horné limity IOPS a MB/s, ako aj potrebné zdroje CPU a RAM), ak jeden z úložných systémov v Metro cluster zlyhá, nedôjde k vážnemu poklesu výkonu za podmienok dočasnej práce na jednom úložnom systéme.
To je vysvetlené skutočnosťou, že keď dve lokality fungujú súčasne, synchrónna replikácia „zje“ polovicu výkonu zápisu, pretože každá transakcia musí byť zapísaná do dvoch úložných systémov (podobne ako RAID-1/10). Takže, ak jeden z úložných systémov zlyhá, vplyv replikácie dočasne (kým sa neobnoví zlyhaný úložný systém) zmizne a dosiahneme dvojnásobné zvýšenie výkonu zápisu. Po reštartovaní jednotiek LUN zlyhaného úložného systému na fungujúcom úložnom systéme toto dvojnásobné zvýšenie zmizne v dôsledku skutočnosti, že sa zaťaženie objaví z jednotiek LUN iného úložného systému, a vrátime sa na rovnakú úroveň výkonu, akú sme mali pred „pád“, ale len v rámci jednej lokality.
Pomocou kompetentného dimenzovania môžete zabezpečiť podmienky, pri ktorých používatelia vôbec nepocítia zlyhanie celého úložného systému. Ale ešte raz opakujeme, toto si vyžaduje veľmi starostlivé dimenzovanie, pre ktoré nás mimochodom môžete zadarmo kontaktovať :-).
Založenie metroklastra
Nastavenie metroklastra je veľmi podobné nastaveniu pravidelnej replikácie, ktorú sme opísali v . Preto sa venujme len rozdielom. V laboratóriu sme postavili lavicu na základe vyššie uvedenej architektúry, len v minimálnej verzii: dva úložné systémy prepojené cez 10G Ethernet, dva 10G prepínače a jeden hostiteľ, ktorý sa cez prepínače pozerá na oba úložné systémy s 10G portami. Rozhodca beží na virtuálnom počítači.
Pri konfigurácii virtuálnych IP (VIP) pre repliku by ste mali vybrať typ VIP - pre metrocluster.
Vytvorili sme dve replikačné linky pre dve LUN a distribuovali sme ich medzi dva úložné systémy: LUN TEST Primárny na úložnom systéme 1 (METRO link), LUN TEST2 Primárny pre úložný systém 2 (METRO2 link).
Pre nich sme nakonfigurovali dva rovnaké ciele (v našom prípade je podporované iSCSI, ale FC, logika nastavenia je rovnaká).
Úložný systém 1:
Úložný systém 2:
Pre replikačné pripojenia boli vykonané mapovania na každom úložnom systéme.
Úložný systém 1:
Úložný systém 2:
Nastavili sme multipath a predstavili ho hostiteľovi.
Nastavenie arbitra
So samotným arbitrom nemusíte robiť nič zvláštne, stačí ho povoliť na tretej stránke, dať mu IP a nakonfigurovať k nemu prístup cez ICMP a SSH. Samotné nastavenie sa vykonáva zo samotných úložných systémov. V tomto prípade stačí konfigurovať arbitra jedenkrát na ktoromkoľvek z storage controllerov v metroclusteri, tieto nastavenia budú automaticky distribuované všetkým kontrolérom.
V časti Vzdialená replikácia>> Metrocluster (na ľubovoľnom ovládači)>> tlačidlo „Konfigurovať“.
Zadáme IP arbitra, ako aj ovládacie rozhrania dvoch radičov vzdialeného úložiska.
Potom musíte povoliť všetky služby (tlačidlo „Reštartovať všetko“). Ak sa v budúcnosti zmení konfigurácia, služby sa musia reštartovať, aby sa nastavenia prejavili.
Skontrolujeme, či sú spustené všetky služby.
Tým sa dokončí nastavenie metroklastra.
Crash test
Crash test v našom prípade bude celkom jednoduchý a rýchly, keďže o funkcionalite replikácie (prepínanie, konzistencia a pod.) sa hovorilo v r. . Na otestovanie spoľahlivosti metroklastra nám teda stačí skontrolovať automatizáciu detekcie porúch, prepínania a absenciu strát záznamu (I/O stop).
Aby sme to dosiahli, emulujeme úplné zlyhanie jedného z úložných systémov fyzickým vypnutím oboch jeho radičov, pričom sme najprv začali kopírovať veľký súbor do LUN, ktorý musí byť aktivovaný na druhom úložnom systéme.
Zakázať jeden úložný systém. Na druhom úložnom systéme vidíme upozornenia a správy v protokoloch, že spojenie so susedným systémom sa stratilo. Ak sú nakonfigurované upozornenia prostredníctvom monitorovania SMTP alebo SNMP, správca bude dostávať príslušné upozornenia.
Presne o 10 sekúnd neskôr (viditeľné na oboch snímkach obrazovky) sa replikačné pripojenie METRO (to, ktoré bolo primárne na zlyhanom úložnom systéme) automaticky stalo Primárnym na fungujúcom úložnom systéme. Pomocou existujúceho mapovania zostal LUN TEST hostiteľovi k dispozícii, nahrávanie mierne kleslo (v rámci sľúbených 10 percent), ale nebolo prerušené.
Test úspešne dokončený.
Zhrnutie
Súčasná implementácia metroklastra v úložných systémoch AERODISK Engine N-series plne umožňuje riešiť problémy, kde je potrebné eliminovať alebo minimalizovať prestoje IT služieb a zabezpečiť ich prevádzku 24/7/365 s minimálnymi mzdovými nákladmi.
Dá sa samozrejme povedať, že toto všetko je teória, ideálne laboratórne podmienky a tak ďalej... ALE máme za sebou množstvo realizovaných projektov, v ktorých sme implementovali funkcionalitu odolnosti voči katastrofám a systémy fungujú perfektne. Jeden z našich pomerne známych zákazníkov, ktorí používajú len dva úložné systémy v konfigurácii odolnej voči katastrofám, už súhlasil so zverejnením informácií o projekte, takže v ďalšej časti si povieme o bojovej implementácii.
Ďakujeme, tešíme sa na plodnú diskusiu.
Zdroj: hab.com