Dobrý den, čtenáři Habra! Tématem tohoto článku bude implementace nástrojů pro obnovu po havárii v úložných systémech AERODISK Engine. Původně jsme chtěli napsat v jednom článku o obou nástrojích: replikaci a metroclusteru, ale bohužel se ukázalo, že článek je příliš dlouhý, a tak jsme článek rozdělili na dvě části. Pojďme od jednoduchého ke složitému. V tomto článku nastavíme a otestujeme synchronní replikaci – vypustíme jedno datové centrum a také přerušíme komunikační kanál mezi datovými centry a uvidíme, co se stane.
Naši zákazníci se nás často ptají na různé otázky týkající se replikace, takže než přejdeme k nastavení a testování implementace replik, řekneme si něco málo o tom, co je replikace v úložišti.
Některé teorie
Replikace v úložných systémech je nepřetržitý proces zajištění identity dat na několika úložných systémech současně. Technicky se replikace provádí dvěma způsoby.
Synchronní replikace – jedná se o zkopírování dat z hlavního úložného systému do záložního s následným povinným potvrzením obou úložných systémů, že data byla zaznamenána a potvrzena. Až po potvrzení na obou stranách (oba úložné systémy) jsou data považována za zaznamenaná a lze s nimi pracovat. To zajišťuje zaručenou identitu dat na všech úložných systémech účastnících se repliky.
Výhody této metody:
- Data jsou vždy stejná na všech úložných systémech
nevýhody:
- Vysoká cena řešení (rychlé komunikační kanály, drahé optické vlákno, dlouhovlnné transceivery atd.)
- Omezení vzdálenosti (do několika desítek kilometrů)
- Neexistuje žádná ochrana proti logickému poškození dat (pokud jsou data poškozena (úmyslně nebo náhodně) na hlavním úložném systému, automaticky a okamžitě se poškodí na záložním systému, protože data jsou vždy totožná (to je paradox)
Asynchronní replikace – jedná se také o kopírování dat z hlavního úložného systému do záložního, ale s určitým zpožděním a bez nutnosti potvrzovat zápis na druhé straně. S daty můžete pracovat ihned po jejich nahrání do hlavního úložného systému a na záložním úložném systému budou data dostupná po nějaké době. Identita údajů v tomto případě samozřejmě není vůbec zajištěna. Data na zálohovacím úložném systému jsou vždy trochu „v minulosti“.
Výhody asynchronní replikace:
- Nízkonákladové řešení (jakékoli komunikační kanály, volitelná optika)
- Bez omezení vzdálenosti
- Na zálohovacím úložném systému se data nezhoršují, pokud jsou poškozena na hlavním (alespoň na nějakou dobu); pokud dojde k poškození dat, můžete repliku kdykoli zastavit, abyste zabránili poškození dat na záložním úložném systému
nevýhody:
- Data v různých datových centrech nejsou vždy totožná
Výběr režimu replikace tedy závisí na obchodních cílech. Pokud je pro vás kritické, aby záložní datové centrum obsahovalo přesně stejná data jako hlavní datové centrum (tj. obchodní požadavek na RPO = 0), budete muset vydělat peníze a smířit se s omezeními synchronního replika. A pokud je zpoždění ve stavu dat přijatelné nebo prostě nejsou peníze, pak určitě musíte použít asynchronní metodu.
Vyzdvihněme také samostatně takový režim (přesněji topologii) jako je metrocluster. V režimu metrocluster se používá synchronní replikace, ale na rozdíl od běžné repliky umožňuje metrocluster oběma systémům úložiště pracovat v aktivním režimu. Tito. nemáte oddělení mezi aktivními a pohotovostními datovými centry. Aplikace pracují současně se dvěma úložnými systémy, které jsou fyzicky umístěny v různých datových centrech. Prostoje při nehodách v takové topologii jsou velmi malé (RTO, obvykle minuty). V tomto článku nebudeme uvažovat o naší implementaci metroclusteru, protože se jedná o velmi rozsáhlé a rozsáhlé téma, proto mu budeme věnovat samostatný, další článek, který bude pokračovat.
Také velmi často, když mluvíme o replikaci pomocí úložných systémů, mnoho lidí má rozumnou otázku: > „Mnoho aplikací má své vlastní replikační nástroje, proč používat replikaci na úložných systémech? Je to lepší nebo horší?
Zde neexistuje jednoznačná odpověď, takže zde jsou argumenty PRO a PROTI:
Argumenty PRO replikaci úložiště:
- Jednoduchost řešení. Pomocí jednoho nástroje můžete replikovat celou svou datovou sadu bez ohledu na typ zatížení a aplikaci. Pokud používáte repliku z aplikací, budete muset nakonfigurovat každou aplikaci zvlášť. Pokud jich je více než 2, pak je to extrémně pracné a drahé (replikace aplikací obvykle vyžaduje samostatnou a ne bezplatnou licenci pro každou aplikaci. Ale o tom níže).
- Můžete replikovat cokoli – jakoukoli aplikaci, jakákoli data – a vždy to bude konzistentní. Mnoho (většina) aplikací nemá replikační schopnosti a repliky z úložného systému jsou jediným způsobem, jak zajistit ochranu před katastrofami.
- Za funkčnost replikace aplikací není třeba přeplácet. Zpravidla to není levné, stejně jako licence na repliku úložného systému. Za licenci na replikaci úložiště ale musíte zaplatit jednou a licenci na repliku aplikace je potřeba zakoupit pro každou aplikaci zvlášť. Pokud je takových aplikací hodně, pak to stojí pěkný peníz a náklady na licence na replikaci úložiště se stávají kapkou v moři.
Argumenty PROTI replikaci úložiště:
- Replika přes aplikace má více funkcionality z pohledu aplikací samotných, aplikace lépe zná svá data (samozřejmě), takže je více možností, jak s nimi pracovat.
- Výrobci některých aplikací nezaručují konzistenci svých dat, pokud se replikace provádí pomocí nástrojů třetích stran. *
* - kontroverzní teze. Například známý výrobce DBMS již velmi dlouho oficiálně prohlašuje, že jejich DBMS lze normálně replikovat pouze pomocí jejich prostředků a zbytek replikace (včetně úložných systémů) „není pravda“. Život ale ukázal, že tomu tak není. S největší pravděpodobností (ale není to jisté) se prostě nejedná o nejčestnější pokus prodat více licencí zákazníkům.
V důsledku toho je ve většině případů replikace z úložného systému lepší, protože Jedná se o jednodušší a méně nákladnou možnost, ale existují složité případy, kdy je potřeba specifická funkčnost aplikace a je nutné pracovat s replikací na úrovni aplikace.
Konec teorie, nyní praxe
Repliku nakonfigurujeme v naší laboratoři. V laboratorních podmínkách jsme emulovali dvě datová centra (ve skutečnosti dva sousední racky, které se zdály být v různých budovách). Stojan se skládá ze dvou úložných systémů Engine N2, které jsou vzájemně propojeny optickými kabely. Fyzický server se systémem Windows Server 2016 je připojen k oběma úložným systémům pomocí 10Gb Ethernetu. Stojan je celkem jednoduchý, ale to na podstatě nic nemění.
Schematicky to vypadá takto:
Logicky je replikace organizována následovně:
Nyní se podívejme na funkci replikace, kterou nyní máme.
Podporovány jsou dva režimy: asynchronní a synchronní. Je logické, že synchronní režim je omezen vzdáleností a komunikačním kanálem. Zejména synchronní režim vyžaduje použití optických vláken jako fyziky a 10gigabitového Ethernetu (nebo vyšší).
Podporovaná vzdálenost pro synchronní replikaci je 40 kilometrů, hodnota zpoždění optického kanálu mezi datovými centry je až 2 milisekundy. Obecně to bude fungovat s velkými zpožděními, ale pak dojde k silným zpomalením při nahrávání (což je také logické), takže pokud plánujete synchronní replikaci mezi datovými centry, měli byste zkontrolovat kvalitu optiky a zpoždění.
Požadavky na asynchronní replikaci nejsou tak závažné. Přesněji řečeno, nejsou tam vůbec. Postačí jakékoli funkční ethernetové připojení.
V současné době úložný systém AERODISK ENGINE podporuje replikaci pro bloková zařízení (LUN) prostřednictvím protokolu Ethernet (přes měděné nebo optické). Pro projekty, kde je vyžadována replikace přes síť SAN přes Fibre Channel, aktuálně přidáváme vhodné řešení, které ale ještě není hotové, takže v našem případě pouze Ethernet.
Replikace může fungovat mezi libovolnými úložnými systémy řady ENGINE (N1, N2, N4) od juniorských systémů po starší a naopak.
Funkčnost obou režimů replikace je zcela identická. Níže jsou uvedeny další podrobnosti o tom, co je k dispozici:
- Replikace „one to one“ nebo „one to one“, tedy klasická verze se dvěma datovými centry, hlavním a záložním
- Replikace je „jedna k mnoha“ nebo „jedna k mnoha“, tzn. jeden LUN lze replikovat do několika úložných systémů najednou
- Aktivujte, deaktivujte a „obrácejte“ replikaci, abyste povolili, zakázali nebo změnili směr replikace
- Replikace je k dispozici pro fondy RDG (Raid Distributed Group) i DDP (Dynamic Disk Pool). Jednotky LUN fondu RDG však lze replikovat pouze do jiného RDG. To samé s DDP.
Existuje mnohem více malých funkcí, ale nemá smysl je vyjmenovávat; zmíníme je při nastavování.
Nastavení replikace
Proces nastavení je poměrně jednoduchý a skládá se ze tří fází.
- Nastavení sítě
- Nastavení úložiště
- Nastavení pravidel (spojení) a mapování
Důležitým bodem při nastavování replikace je, že první dvě fáze by se měly opakovat na vzdáleném úložném systému, třetí fáze - pouze na hlavním.
Nastavení síťových prostředků
Prvním krokem je konfigurace síťových portů, přes které bude přenášen replikační provoz. Chcete-li to provést, musíte povolit porty a nastavit jejich IP adresy v sekci Front-end adaptéry.
Poté musíme vytvořit fond (v našem případě RDG) a virtuální IP pro replikaci (VIP). VIP je plovoucí IP adresa, která je svázána se dvěma „fyzickými“ adresami řadičů úložiště (porty, které jsme právě nakonfigurovali). Toto bude hlavní replikační rozhraní. Můžete také operovat nikoli s VIP, ale s VLAN, pokud potřebujete pracovat s označeným provozem.
Proces vytvoření VIP pro repliku se příliš neliší od vytvoření VIP pro I/O (NFS, SMB, iSCSI). V tomto případě vytvoříme běžný VIP (bez VLAN), ale nezapomeňte uvést, že je určen pro replikaci (bez tohoto ukazatele nebudeme moci v dalším kroku přidat VIP do pravidla).
VIP musí být ve stejné podsíti jako IP porty, mezi kterými se pohybuje.
Tato nastavení opakujeme na vzdáleném úložném systému, samozřejmě s jinou IP.
VIP z různých úložných systémů mohou být v různých podsítích, hlavní je, že mezi nimi existuje směrování. V našem případě je tento příklad přesně zobrazen (192.168.3.XX a 192.168.2.XX)
Tím je příprava síťové části dokončena.
Nastavení úložiště
Nastavení úložiště pro repliku se od běžného liší pouze tím, že mapování provádíme pomocí speciální nabídky „Mapování replikace“. Jinak je vše stejné jako u normálního nastavení. Teď po pořádku.
V dříve vytvořeném fondu R02 musíte vytvořit LUN. Vytvořme ji a nazvěme ji LUN1.
Potřebujeme také vytvořit stejnou LUN na vzdáleném úložném systému stejné velikosti. tvoříme. Aby nedošlo k záměně, zavolejte na vzdálenou LUN LUN1R
Pokud bychom potřebovali vzít LUN, který již existuje, pak bychom při nastavování repliky museli odpojit tuto produktivní LUN od hostitele a jednoduše vytvořit prázdnou LUN stejné velikosti na vzdáleném úložném systému.
Nastavení úložiště je dokončeno, pojďme k vytvoření pravidla replikace.
Nastavení pravidel replikace nebo replikačních odkazů
Po vytvoření LUN na úložném systému, který bude v tuto chvíli primární, nakonfigurujeme replikační pravidlo LUN1 na úložném systému 1 až LUN1R na úložném systému 2.
Nastavení se provádí v nabídce „Vzdálená replikace“.
Vytvořme pravidlo. Chcete-li to provést, musíte určit příjemce repliky. Tam také nastavíme název připojení a typ replikace (synchronní nebo asynchronní).
Do pole „vzdálené systémy“ přidáme náš úložný systém2. Pro přidání je potřeba použít management IP storage systems (MGR) a název vzdálené LUN, do které budeme replikaci provádět (v našem případě LUN1R). Řídicí IP adresy jsou potřeba pouze ve fázi přidávání připojení, nebude přes ně přenášen replikační provoz, k tomu se použije dříve nakonfigurovaný VIP.
Již v této fázi můžeme přidat více než jeden vzdálený systém pro topologii „jeden k mnoha“: klikněte na tlačítko „přidat uzel“, jako na obrázku níže.
V našem případě existuje pouze jeden vzdálený systém, takže se omezujeme na toto.
Pravidlo je připraveno. Vezměte prosím na vědomí, že se automaticky přidá ke všem účastníkům replikace (v našem případě jsou dva). Můžete vytvořit tolik pravidel, kolik chcete, pro libovolný počet LUN a v libovolném směru. Například pro vyvážení zátěže můžeme replikovat část LUN z úložného systému 1 do úložného systému 2 a druhou část naopak z úložného systému 2 do úložného systému 1.
Úložný systém 1. Ihned po vytvoření začala synchronizace.
Úložný systém 2. Vidíme stejné pravidlo, ale synchronizace již skončila.
LUN1 na úložném systému 1 je v roli Primární, to znamená, že je aktivní. LUN1R na úložném systému 2 je v roli Sekundární, to znamená, že je v pohotovostním režimu pro případ selhání úložného systému 1.
Nyní můžeme připojit naši LUN k hostiteli.
Připojíme se přes iSCSI, i když to jde i přes FC. Nastavení mapování přes iSCSI LUN v replice se prakticky neliší od běžného scénáře, takže se zde nebudeme podrobně zabývat. Pokud něco, tento proces je popsán v článku „".
Jediný rozdíl je v tom, že mapování vytváříme v nabídce „Mapování replikace“.
Nastavili jsme mapování a předali LUN hostiteli. Hostitel viděl LUN.
Naformátujeme jej do lokálního souborového systému.
To je vše, nastavení je dokončeno. Na řadu přijdou testy.
Testování
Vyzkoušíme tři hlavní scénáře.
- Pravidelné přepínání rolí Sekundární > Primární. Pravidelné přepínání rolí je potřeba v případě, že např. potřebujeme provést nějaké preventivní operace v hlavním datovém centru a během této doby, aby byla data dostupná, přeneseme zátěž do záložního datového centra.
- Nouzové přepínání rolí Sekundární > Primární (selhání datového centra). Toto je hlavní scénář, pro který existuje replikace, která může pomoci přežít úplné selhání datového centra bez zastavení společnosti na delší dobu.
- Rozdělení komunikačních kanálů mezi datovými centry. Kontrola správného chování dvou úložných systémů v podmínkách, kdy je z nějakého důvodu nedostupný komunikační kanál mezi datovými centry (např. bagr kopal na špatném místě a rozbil tmavou optiku).
Nejprve začneme zapisovat data do naší LUN (zápis souborů s náhodnými daty). Okamžitě vidíme, že se využívá komunikační kanál mezi úložnými systémy. To lze snadno pochopit, pokud otevřete sledování zatížení portů, které jsou zodpovědné za replikaci.
Oba úložné systémy nyní mají „užitečná“ data, můžeme zahájit test.
Pro každý případ se podívejme na hašovací součty jednoho ze souborů a zapišme si je.
Pravidelné střídání rolí
Operaci přepínání rolí (změna směru replikace) lze provést s jakýmkoli úložným systémem, ale stále budete muset přejít na oba, protože budete muset zakázat mapování na primárním a povolit ho na sekundárním (který se stane primárním ).
Možná se nyní nabízí rozumná otázka: proč to nezautomatizovat? Odpověď zní: je to jednoduché, replikace je jednoduchý prostředek odolnosti proti katastrofám, založený výhradně na ručních operacích. Pro automatizaci těchto operací existuje režim metrocluster, který je plně automatizovaný, ale jeho konfigurace je mnohem složitější. O nastavení metroclusteru napíšeme v příštím článku.
Na hlavním úložném systému deaktivujeme mapování, abychom zajistili zastavení nahrávání.
Poté na jednom z úložných systémů (na tom nezáleží, na hlavním nebo záložním) v nabídce „Vzdálená replikace“ vyberte naše připojení REPL1 a klikněte na „Změnit roli“.
Po několika sekundách se LUN1R (záložní úložný systém) stane primárním.
Mapujeme LUN1R s úložným systémem2.
Poté se náš disk E: automaticky připojí k hostiteli, ale tentokrát „dorazil“ z LUN1R.
Pro každý případ porovnáme hashovací součty.
Identický. Test prošel.
Failover. Selhání datového centra
V současné době je hlavním úložným systémem po pravidelném přepínání úložný systém 2, resp. LUN1R. Abychom napodobili nehodu, vypneme napájení obou řadičů úložiště2.
Už k němu není přístup.
Podívejme se, co se děje na úložném systému 1 (v tuto chvíli záložním).
Vidíme, že primární LUN (LUN1R) není k dispozici. Chybová zpráva se objevila v protokolech, na informačním panelu a také v samotném pravidle replikace. Data od hostitele jsou proto aktuálně nedostupná.
Změňte roli LUN1 na Primární.
Dělám mapování na hostitele.
Ujistěte se, že se na hostiteli zobrazuje jednotka E.
Zkontrolujeme hash.
Vše je v pořádku. Úložný systém úspěšně přežil pád datového centra, které bylo aktivní. Přibližná doba, kterou jsme strávili připojením „reverze“ replikace a připojením LUN ze záložního datového centra, byla asi 3 minuty. Je jasné, že v reálné výrobě je vše mnohem složitější a kromě akcí s úložnými systémy je potřeba provádět mnohem více operací na síti, na hostitelích, v aplikacích. A v životě bude tato doba mnohem delší.
Zde bych chtěl napsat, že vše, test byl úspěšně dokončen, ale nespěchejme. Hlavní úložný systém „leží“, víme, že když „spadl“, byl v roli Primárního. Co se stane, když se náhle zapne? Budou dvě primární role, což se rovná poškození dat? Pojďme to teď zkontrolovat.
Pojďme najednou zapnout základní úložný systém.
Načte se několik minut a poté se po krátké synchronizaci vrátí do služby, ale v roli sekundárního.
Vše OK. Rozdělený mozek se nekonal. Přemýšleli jsme o tom a vždy po pádu se skladovací systém zvedne do role Sekundárního, bez ohledu na to, jakou roli měl „během života“. Nyní můžeme s jistotou říci, že test selhání datového centra byl úspěšný.
Selhání komunikačních kanálů mezi datovými centry
Hlavním úkolem tohoto testu je ujistit se, že se úložný systém nezačne chovat divně, pokud dočasně ztratí komunikační kanály mezi dvěma úložnými systémy a pak se znovu objeví.
Tak. Odpojíme dráty mezi skladovacími systémy (předpokládejme, že je vykopal bagr).
Na Primární vidíme, že neexistuje žádné spojení se Sekundárním.
Na Sekundární vidíme, že neexistuje žádné spojení s Primárním.
Vše funguje dobře a nadále zapisujeme data do hlavního úložného systému, to znamená, že se zaručeně liší od záložního, to znamená, že se „oddělili“.
Během několika minut „opravíme“ komunikační kanál. Jakmile se úložné systémy navzájem uvidí, automaticky se aktivuje synchronizace dat. Zde se od správce nic nevyžaduje.
Po nějaké době je synchronizace dokončena.
Spojení bylo obnoveno, ztráta komunikačních kanálů nezpůsobila žádné nouzové situace a po zapnutí proběhla automaticky synchronizace.
Závěry
Rozebrali jsme teorii – co je potřeba a proč, kde jsou klady a kde zápory. Poté nastavíme synchronní replikaci mezi dvěma úložnými systémy.
Dále byly provedeny základní testy na normální přepínání, poruchu datového centra a poruchu komunikačního kanálu. Ve všech případech úložný systém fungoval dobře. Nedochází ke ztrátě dat a administrativní operace jsou omezeny na minimum pro manuální scénář.
Příště si situaci zkomplikujeme a ukážeme si, jak celá tato logika funguje v automatizovaném metroclusteru v aktivním-aktivním režimu, tedy kdy oba úložné systémy jsou primární a chování při výpadcích úložného systému je plně automatizováno.
Pište prosím komentáře, rádi obdržíme fundovanou kritiku a praktické rady.
Do příště.
Zdroj: www.habr.com