Ahoj čtenáři Habr! V minulém článku jsme hovořili o jednoduchém prostředku obnovy po havárii v úložných systémech AERODISK ENGINE – replikaci. V tomto článku se vrhneme na složitější a zajímavější téma – metrocluster, tedy nástroj pro automatizovanou ochranu před katastrofami pro dvě datová centra, který umožňuje datovým centrům pracovat v režimu aktivní-aktivní. Řekneme, ukážeme, rozbijeme a opravíme.
Jako obvykle na začátku teorie
Metrocluster je shluk rozmístěný do několika míst v rámci města nebo čtvrti. Slovo "cluster" nám jasně napovídá, že komplex je automatizovaný, to znamená, že přepínání uzlů clusteru v případě selhání (failover) probíhá automaticky.
Zde spočívá hlavní rozdíl mezi metroclusterem a pravidelnou replikací. Automatizace provozu. To znamená, že v případě určitých incidentů (selhání datového centra, přerušení kanálů atd.) úložný systém samostatně provede nezbytné akce, aby byla zachována dostupnost dat. Při použití běžných replik tyto akce provádí zcela nebo částečně ručně správce.
Co to dělá?
Hlavním cílem zákazníků využívajících určité implementace metroclusterů je minimalizovat RTO (Recovery Time Objective). Tedy minimalizovat dobu obnovy IT služeb po selhání. Pokud používáte konvenční replikaci, bude doba obnovy vždy delší než doba obnovy u clusteru metropolitní oblasti. Proč? Velmi jednoduché. Správce musí být na pracovišti a replikaci přepínače ručně, zatímco cluster metra to dělá automaticky.
Pokud nemáte vyčleněného správce povinnosti, který nespí, nejí, nekouří ani neonemocní, ale 24 hodin denně se dívá na stav úložiště, pak nelze nijak zaručit, že správce bude k dispozici pro ruční přepínání při poruše.
V souladu s tím se RTO při absenci clusteru metra nebo nesmrtelného admina 99. úrovně služebních služeb správců bude rovnat součtu spínacích časů všech systémů a maximální doby, po které je správci zaručeno začít pracovat s úložným systémem a souvisejícími systémy.
Dostáváme se tedy k jasnému závěru, že metrocluster by měl být použit v případě, že požadavek na RTO jsou minuty, nikoli hodiny nebo dny.To znamená, kdy v případě nejstrašnějšího pádu datového centra musí IT oddělení zajistit společnost má čas obnovit přístup k IT službám během několika minut nebo dokonce sekund.
Jak to funguje?
Na nižší úrovni používá metrocluster mechanismus synchronní replikace dat, který jsme popsali v předchozím článku (viz níže). ). Protože replikace je synchronní, požadavky na ni jsou vhodné, nebo spíše:
- vlákno jako fyzika, 10gigabitový ethernet (nebo vyšší);
- vzdálenost mezi datovými centry není větší než 40 kilometrů;
- zpoždění optického kanálu mezi datovými centry (mezi úložnými systémy) až 5 milisekund (optimálně 2).
Všechny tyto požadavky mají poradní charakter, to znamená, že cluster metra bude fungovat, i když tyto požadavky nebudou splněny, ale je třeba chápat, že důsledky nesplnění těchto požadavků se rovnají zpomalení provozu obou úložných systémů. v klastru metra.
K přenosu dat mezi úložnými systémy se tedy používá synchronní replika, ale jak se repliky automaticky přepínají a hlavně jak se vyhnout split-brain? K tomu se na výše uvedené úrovni používá další entita - arbitr.
Jak arbitr pracuje a co je jeho úkolem?
Arbiter je malý virtuální stroj nebo hardwarový cluster, který je třeba spustit na třetím místě (například v kanceláři) a poskytnout přístup k úložišti přes ICMP a SSH. Po spuštění by měl arbitr nastavit IP a poté zadat její adresu ze strany úložiště plus adresy vzdálených ovladačů, které se účastní clusteru metra. Poté je rozhodčí připraven vyrazit.
Arbitr neustále monitoruje všechny úložné systémy v clusteru metra a v případě, že je konkrétní úložný systém nedostupný, po potvrzení nedostupnosti od jiného člena clusteru (jeden z „živých“ úložných systémů) se rozhodne zahájit proceduru přepínání pravidel replikace a mapování.
Velmi důležitý bod. Rozhodčí musí být vždy umístěn na jiném místě, než na kterém jsou umístěny úložné systémy, tedy ani v DPC 1, kde se nachází úložiště 1, ani v DPC 2, kde je úložiště 2 instalováno.
Proč? Protože jedině tak může arbitr s pomocí jednoho z dochovaných úložných systémů jednoznačně a přesně určit pád kteréhokoli ze dvou míst, kde jsou úložné systémy instalovány. Jakýkoli jiný způsob umístění rozhodce může vést k rozdělení mozku.
Nyní se pojďme ponořit do detailů práce arbitra.
Na arbitrovi běží několik služeb, které se neustále dotazují na všechny řadiče úložiště. Pokud se výsledek ankety liší od předchozího (dostupný/nedostupný), pak se zapíše do malé databáze, která funguje i na arbitrovi.
Zvažte logiku arbitra podrobněji.
Krok 1. Určení nedostupnosti. Událostí signalizující poruchu úložného systému je absence pingu z obou kontrolérů stejného úložného systému po dobu 5 sekund.
Krok 2. Spuštění procedury přepínání. Poté, co arbitr zjistil, že jeden z úložných systémů je nedostupný, odešle požadavek do „živého“ úložného systému, aby se ujistil, že „mrtvý“ úložný systém je skutečně mrtvý.
Po obdržení takového příkazu od rozhodce druhý (živý) úložný systém dodatečně zkontroluje dostupnost padlého prvního úložného systému a pokud ne, pošle arbitrovi potvrzení o jeho odhadu. SHD skutečně není k dispozici.
Po obdržení takového potvrzení arbitr zahájí vzdálenou proceduru pro přepnutí replikace a vyvolání mapování na těch replikách, které byly aktivní (primární) na padlém úložném systému, a pošle příkaz do druhého úložného systému, aby tyto repliky převedl ze sekundární na primární. a zvedněte mapování. Druhý úložný systém provádí tyto procedury, po kterých poskytuje přístup ke ztraceným LUNům ze sebe.
Proč je potřeba dodatečné ověření? Pro usnášeníschopnost. To znamená, že většina z celkového lichého (3) počtu členů klastru musí potvrdit pád jednoho z uzlů klastru. Jedině tak bude toto rozhodnutí zcela správné. To je nezbytné, aby se předešlo chybnému přepínání, a tedy rozdělení mozku.
Krok 2 trvá přibližně 5–10 sekund, takže, vezmeme-li v úvahu čas potřebný k určení nedostupnosti (5 sekund), během 10–15 sekund po selhání budou jednotky LUN se spadlým úložným systémem automaticky dostupné pro práci s živými úložný prostor.
Je jasné, že abyste se vyhnuli odpojení od hostitelů, musíte se také postarat o správné nastavení timeoutů na hostitelích. Doporučený časový limit je alespoň 30 sekund. To zabrání hostiteli zrušit připojení k úložišti během načtení převzetí služeb při selhání a může zajistit, že nedojde k přerušení I/O.
Počkejte chvíli, ukáže se, že pokud je s clusterem metra vše v pořádku, proč vůbec potřebujeme pravidelnou replikaci?
Ve skutečnosti není všechno tak jednoduché.
Zvažte výhody a nevýhody metroclusteru
Takže jsme si uvědomili, že zjevné výhody metroclusteru ve srovnání s konvenční replikací jsou:
- Plná automatizace zajišťující minimální dobu obnovy v případě havárie;
- A to je vše :-).
A teď pozor, nevýhody:
- Náklady na řešení. Metrocluster v systémech Aerodisk sice nevyžaduje další licencování (používá se stejná licence jako u repliky), přesto budou náklady na řešení ještě vyšší než při použití synchronní replikace. Budete muset implementovat všechny požadavky na synchronní repliku plus požadavky na cluster metra spojené s dalším přepínáním a dalším místem (viz plánování clusteru metra);
- Složitost rozhodnutí. Metrocluster je mnohem složitější než běžná replika a vyžaduje mnohem více pozornosti a úsilí při plánování, konfiguraci a dokumentaci.
Nakonec. Metrocluster je jistě velmi technologické a dobré řešení, když opravdu potřebujete zajistit RTO během několika sekund nebo minut. Ale pokud takový úkol neexistuje a RTO v hodinách je pro podnikání OK, pak nemá smysl střílet vrabce z děla. Stačí obvyklá replikace mezi pracovníky a rolníky, protože cluster metra způsobí dodatečné náklady a komplikuje IT infrastrukturu.
Plánování klastrů metra
Tato část si neklade za cíl být komplexním návodem k návrhu clusteru metra, ale ukazuje pouze hlavní směry, které by měly být vypracovány, pokud se rozhodnete takový systém vybudovat. Při samotné realizaci clusteru metra proto určitě zapojte ke konzultaci výrobce úložného systému (tedy nás) a dalších souvisejících systémů.
Místa konání
Jak je uvedeno výše, klastr metra vyžaduje minimálně tři místa. Dvě datová centra, kde budou fungovat úložné systémy a související systémy, a také třetí místo, kde bude pracovat arbitr.
Doporučená vzdálenost mezi datovými centry není větší než 40 kilometrů. Větší vzdálenost s vysokou pravděpodobností způsobí další zpoždění, která jsou v případě shluku metra vysoce nežádoucí. Připomeňme, že zpoždění by mělo být až 5 milisekund, i když je žádoucí dodržet 2.
Zpoždění se také doporučuje kontrolovat během procesu plánování. Jakýkoli více či méně dospělý poskytovatel, který poskytuje vlákno mezi datovými centry, může zorganizovat kontrolu kvality docela rychle.
Pokud jde o zpoždění k arbitrovi (tedy mezi třetím místem a prvními dvěma), doporučený práh zpoždění je až 200 milisekund, to znamená, že běžné podnikové připojení VPN přes internet postačí.
Přepínání a síť
Na rozdíl od schématu replikace, kde stačí propojit úložné systémy z různých míst, schéma clusteru metra vyžaduje připojení hostitelů k oběma úložným systémům na různých místech. Aby bylo jasnější, v čem je rozdíl, jsou níže uvedena obě schémata.
Jak můžete vidět z diagramu, máme hostitele webu 1, kteří se dívají na systém úložiště 1 i systém úložiště 2. Také naopak hostitelé webu 2 se dívají na systém úložiště 2 i systém úložiště 1. To znamená, že každý hostitel vidí oba úložné systémy. To je předpokladem pro provoz metroklastru.
Samozřejmě není potřeba tahat každého hostitele optickým kabelem do jiného datového centra, nebude dostatek portů a kabelů. Všechna tato připojení musí být provedena prostřednictvím přepínačů Ethernet 10G+ nebo FibreChannel 8G+ (FC pouze pro připojení hostitelů a úložiště pro IO, replikační kanál je v současnosti dostupný pouze přes IP (Ethernet 10G+).
Nyní pár slov o topologii sítě. Důležitým bodem je správná konfigurace podsítí. Musíte okamžitě definovat několik podsítí pro následující typy provozu:
- Podsíť pro replikaci, přes kterou budou data synchronizována mezi úložnými systémy. Může jich být více, v tomto případě je to jedno, vše závisí na aktuální (již implementované) topologii sítě. Pokud existují dva z nich, pak je samozřejmě nutné nakonfigurovat směrování mezi nimi;
- Podsítě úložiště, přes které budou hostitelé přistupovat k prostředkům úložiště (pokud je to iSCSI). V každém datovém centru by měla být jedna taková podsíť;
- Kontrolní podsítě, tedy tři směrovatelné podsítě na třech místech, ze kterých je spravováno úložiště, a tam je umístěn i arbitr.
Zde neuvažujeme podsítě pro přístup k hostitelským zdrojům, protože jsou vysoce závislé na úkolech.
Oddělení různého provozu do různých podsítí je nesmírně důležité (obzvláště důležité je oddělit repliku od I/O), protože pokud smícháte veškerý provoz do jedné „husté“ podsítě, nebude možné tento provoz řídit a v podmínkách dvou datových center to stále může způsobit různé možnosti kolizí sítě. V rámci tohoto článku se této problematice nebudeme hlouběji věnovat, protože o plánování sítě natažené mezi datovými centry na zdrojích výrobců síťových zařízení si můžete přečíst, kde je to velmi podrobně popsáno.
Konfigurace arbitra
Arbitr musí zajistit přístup ke všem řídicím rozhraním úložného systému prostřednictvím protokolů ICMP a SSH. Měli byste také myslet na odolnost arbitra vůči chybám. Je zde nuance.
Arbiter failover je vysoce žádoucí, ale není nutné. A co se stane, když arbitr havaruje v nevhodnou dobu?
- Provoz metroclusteru v normálním režimu se nezmění, protože arbtir nijak neovlivňuje provoz clusteru metra v normálním režimu (jeho úkolem je včas přepínat zátěž mezi datovými centry)
- Zároveň, pokud arbitr z toho či onoho důvodu upadne a „uspí“ nehodu v datovém centru, pak k žádnému přepnutí nedojde, protože nebude mít kdo dávat potřebné příkazy k přepínání a organizovat kvorum. V tomto případě se cluster metra změní na běžné schéma replikace, které bude nutné ručně přepnout během katastrofy, která ovlivní RTO.
Co z toho vyplývá? Pokud opravdu potřebujete poskytnout minimální RTO, musíte zajistit odolnost arbitra vůči chybám. K tomu existují dvě možnosti:
- Spusťte virtuální stroj s arbitrem na hypervizoru odolném proti chybám, protože všechny dospělé hypervizory podporují odolnost proti chybám;
- Pokud je na třetím místě (v podmíněné kanceláři) příliš líné nainstalovat normální cluster a neexistuje žádný existující cluster hypervizorů, pak jsme poskytli hardwarovou verzi arbitra, která je vyrobena v 2U krabici, ve které jsou dva běžné x-86 servery fungují a mohou přežít lokální selhání.
Důrazně doporučujeme, abyste zajistili odolnost arbitra proti chybám, přestože jej metro cluster v normálním režimu nepotřebuje. Jak ale ukazuje teorie i praxe, pokud vybudujete skutečně spolehlivou infrastrukturu odolnou vůči katastrofám, pak je lepší hrát na jistotu. Je lepší chránit sebe a své podnikání před „zákonem podlosti“, tedy před selháním arbitra i jednoho z míst, kde se skladovací systém nachází.
Architektura řešení
S ohledem na výše uvedené požadavky získáme následující obecnou architekturu řešení.
Logické jednotky by měly být rovnoměrně rozmístěny po dvou místech, aby se zabránilo silnému přetížení. Přitom při dimenzování v obou datových centrech je nutné zajistit nejen dvojnásobný objem (který je nutný pro ukládání dat současně na dvou úložných systémech), ale také dvojnásobný výkon v IOPS a MB/s, aby nedocházelo k degradace aplikací při výpadku jednoho z datových center - ov.
Samostatně poznamenáváme, že při správném přístupu k dimenzování (tj. za předpokladu, že jsme zajistili správné horní limity IOPS a MB/s, stejně jako nezbytné zdroje CPU a RAM), pokud jeden z úložných systémů v selže cluster metra, nedojde k žádnému vážnému poklesu výkonu v podmínkách dočasné práce na jednom úložném systému.
To je vysvětleno skutečností, že v podmínkách dvou pracovišť pracujících současně běžící synchronní replikace „spotřebovává“ polovinu výkonu zápisu, protože každá transakce musí být zapsána do dvou úložných systémů (podobně jako RAID-1 / 10). Pokud tedy některý z úložných systémů selže, efekt replikace dočasně (dokud se nezvedne neúspěšný úložný systém) zmizí a získáme dvojnásobné zvýšení výkonu zápisu. Po restartování jednotek LUN neúspěšného úložného systému na funkčním úložném systému toto dvojnásobné navýšení zmizí, protože dochází k zátěži z jednotek LUN jiného úložného systému a vrátíme se na stejnou úroveň výkonu, jakou jsme měli před „pád“, ale pouze v rámci stejné platformy.
Pomocí kompetentního dimenzování je možné zajistit podmínky, za kterých uživatelé vůbec nepocítí výpadek celého skladovacího systému. To ale opět vyžaduje velmi pečlivé dimenzování, které nás mimochodem můžete zdarma kontaktovat :-).
Nastavení clusteru metra
Nastavení clusteru metra je velmi podobné nastavení pravidelné replikace, kterou jsme popsali v . Zaměřme se tedy jen na rozdíly. V laboratoři jsme postavili lavici na základě výše uvedené architektury, pouze v minimální verzi: dva úložné systémy vzájemně propojené přes 10G Ethernet, dva 10G switche a jeden hostitel, který se přes switche dívá na oba úložné systémy s 10G porty. Rozhodce běží na virtuálním počítači.
Při konfiguraci virtuální adresy IP (VIP) pro repliku byste měli vybrat typ VIP - pro cluster metropolitní oblasti.
Vytvořil dvě replikační propojení pro dvě LUN a distribuoval je do dvou úložných systémů: LUN TEST Primární na úložišti1 (připojení METRO), LUN TEST2 Primární pro úložiště2 (připojení METRO2).
Pro ně jsme nakonfigurovali dva identické cíle (v našem případě iSCSI, ale podporuje se i FC, logika konfigurace je stejná).
úložiště1:
úložiště2:
Pro replikační odkazy byla provedena mapování na každém úložném systému.
úložiště1:
úložiště2:
Nastavili jsme multipath a představili to hostiteli.
Nastavení arbitra
Se samotným arbitrem nemusíte dělat nic zvláštního, stačí jej zapnout na třetím webu, nastavit jeho IP a nakonfigurovat k němu přístup přes ICMP a SSH. Samotná konfigurace se provádí ze samotných úložných systémů. Arbiter přitom stačí jednou nakonfigurovat na libovolném řadiči úložiště v clusteru metra, tato nastavení se všem řadičům rozdělí automaticky.
V části Vzdálená replikace>> Metrocluster (na libovolném řadiči)>> tlačítko Konfigurovat.
Zadáme IP arbitra a také ovládací rozhraní dvou řadičů vzdáleného úložiště.
Poté musíte povolit všechny služby (tlačítko "Restartovat vše"). Pokud v budoucnu provedete novou konfiguraci, je nutné služby restartovat, aby se nastavení projevilo.
Kontrolujeme, zda všechny služby běží.
Tím je nastavení metroclusteru dokončeno.
Crash test
Crash test v našem případě bude poměrně jednoduchý a rychlý, protože replikační funkčnost (přepínání, konzistence atd.) byla uvažována v . Pro otestování spolehlivosti clusteru metra nám tedy stačí zkontrolovat automatizaci detekce nehod, přepínání a absenci ztrát zápisu (I/O stop).
Za tímto účelem emulujeme úplné selhání jednoho z úložných systémů fyzickým vypnutím obou jeho řadičů po zahájení kopírování velkého souboru do LUN, který by měl být aktivován na jiném úložném systému.
Zakázat jeden úložný systém. Na druhém úložném systému vidíme v protokolech výstrahy a zprávy, že spojení se sousedním systémem zmizelo. Pokud jsou nakonfigurována upozornění prostřednictvím monitorování SMTP nebo SNMP, budou správci odeslána příslušná upozornění.
Přesně o 10 sekund později (je vidět na obou snímcích obrazovky) se replikační link METRO (ten, který byl primární na padlém úložném systému) automaticky stal primárním na funkčním úložném systému. Pomocí stávajícího mapování zůstal LUN TEST hostiteli k dispozici, záznam se trochu propadl (v rámci slibovaných 10 procent), ale nezastavil se.
Test byl úspěšně dokončen.
Shrnutí
Současná implementace metroclusteru v úložných systémech AERODISK Engine N-series plně umožňuje řešit problémy tam, kde potřebujete eliminovat nebo minimalizovat prostoje IT služeb a zajistit jejich provoz v režimu 24/7/365 s minimálními mzdovými náklady.
Dá se samozřejmě říct, že to všechno je teorie, ideální laboratorní podmínky a tak dále... ALE máme za sebou řadu realizovaných projektů, ve kterých jsme implementovali funkcionalitu obnovy po havárii a systémy fungují perfektně. Jeden z našich poměrně známých zákazníků, kde jsou použity právě dva úložné systémy v konfiguraci odolné vůči katastrofám, již souhlasil se zveřejněním informací o projektu, takže v příštím díle si povíme něco o bojové implementaci.
Děkuji, těším se na plodnou diskuzi.
Zdroj: www.habr.com