Dobrý deň, čitatelia Habr! Témou tohto článku bude implementácia nástrojov na obnovu po havárii v úložných systémoch AERODISK Engine. Pôvodne sme chceli písať v jednom článku o oboch nástrojoch: replikácii a metroklastri, ale, žiaľ, článok sa ukázal byť príliš dlhý, preto sme ho rozdelili na dve časti. Poďme od jednoduchého k zložitému. V tomto článku nastavíme a otestujeme synchrónnu replikáciu – zrušíme jedno dátové centrum a tiež prerušíme komunikačný kanál medzi dátovými centrami a uvidíme, čo sa stane.
Naši zákazníci sa nás často pýtajú na rôzne otázky týkajúce sa replikácie, takže predtým, ako prejdeme k nastaveniu a testovaniu implementácie replík, povieme si niečo o tom, čo je replikácia v úložisku.
Niektoré teórie
Replikácia v úložných systémoch je nepretržitý proces zabezpečenia identity dát na viacerých úložných systémoch súčasne. Technicky sa replikácia uskutočňuje dvoma spôsobmi.
Synchrónna replikácia – ide o skopírovanie údajov z hlavného úložného systému do záložného s následným povinným potvrdením z oboch úložných systémov, že údaje boli zaznamenané a potvrdené. Až po potvrdení na oboch stranách (oboch úložných systémov) sa dáta považujú za zaznamenané a dá sa s nimi pracovať. To zaisťuje zaručenú identitu údajov na všetkých úložných systémoch, ktoré sa podieľajú na replike.
Výhody tejto metódy:
- Údaje sú vždy rovnaké na všetkých úložných systémoch
Nevýhody:
- Vysoké náklady na riešenie (rýchle komunikačné kanály, drahé optické vlákno, dlhovlnné transceivery atď.)
- Obmedzenia vzdialenosti (do niekoľkých desiatok kilometrov)
- Neexistuje žiadna ochrana proti logickému poškodeniu dát (ak sú dáta poškodené (úmyselne alebo náhodne) na hlavnom úložnom systéme, automaticky a okamžite sa poškodia na záložnom, pretože dáta sú vždy identické (to je paradox)
Asynchrónna replikácia – ide tiež o kopírovanie dát z hlavného úložného systému do záložného, avšak s určitým oneskorením a bez nutnosti potvrdzovania zápisu na druhej strane. S dátami môžete pracovať ihneď po ich zaznamenaní do hlavného úložného systému a na záložnom úložnom systéme budú dáta dostupné po určitom čase. Identita údajov v tomto prípade samozrejme nie je vôbec zabezpečená. Údaje v zálohovacom úložnom systéme sú vždy trochu „v minulosti“.
Výhody asynchrónnej replikácie:
- Nízkonákladové riešenie (akékoľvek komunikačné kanály, voliteľná optika)
- Žiadne obmedzenia vzdialenosti
- Na záložnom úložnom systéme sa dáta nezhoršia, ak sú poškodené na hlavnom (aspoň na nejaký čas); ak sa dáta poškodia, repliku môžete kedykoľvek zastaviť, aby ste zabránili poškodeniu dát v záložnom úložnom systéme
Nevýhody:
- Údaje v rôznych dátových centrách nie sú vždy rovnaké
Výber režimu replikácie teda závisí od obchodných cieľov. Ak je pre vás dôležité, aby záložné dátové centrum obsahovalo presne tie isté dáta ako hlavné dátové centrum (t. j. obchodná požiadavka na RPO = 0), potom budete musieť vybrať hotovosť a zmieriť sa s obmedzeniami synchrónneho replika. A ak je oneskorenie v stave údajov prijateľné alebo jednoducho nie sú žiadne peniaze, určite musíte použiť asynchrónnu metódu.
Vyzdvihnime tiež samostatne taký režim (presnejšie topológiu) ako metroklaster. V režime metrocluster sa používa synchrónna replikácia, ale na rozdiel od bežnej repliky umožňuje metrocluster obom úložným systémom pracovať v aktívnom režime. Tie. nemáte oddelenie medzi aktívnymi a pohotovostnými dátovými centrami. Aplikácie pracujú súčasne s dvoma úložnými systémami, ktoré sú fyzicky umiestnené v rôznych dátových centrách. Prestoje pri nehodách v takejto topológii sú veľmi malé (RTO, zvyčajne minúty). V tomto článku sa nebudeme zaoberať našou implementáciou metroklastra, keďže ide o veľmi rozsiahlu a rozsiahlu tému, preto jej budeme venovať samostatný, ďalší článok v pokračovaní tohto.
Tiež veľmi často, keď hovoríme o replikácii pomocou úložných systémov, veľa ľudí má rozumnú otázku: > „Veľa aplikácií má svoje vlastné replikačné nástroje, prečo používať replikáciu na úložných systémoch? Je to lepšie alebo horšie?
Tu neexistuje jednoznačná odpoveď, takže tu sú argumenty PRE a PROTI:
Argumenty PRE replikáciu úložiska:
- Jednoduchosť riešenia. Pomocou jedného nástroja môžete replikovať celý súbor údajov bez ohľadu na typ zaťaženia a aplikáciu. Ak používate repliku z aplikácií, budete musieť nakonfigurovať každú aplikáciu samostatne. Ak ich je viac ako 2, potom je to mimoriadne náročné na prácu a drahé (replikácia aplikácií si zvyčajne vyžaduje samostatnú a nie bezplatnú licenciu pre každú aplikáciu. Ale o tom nižšie).
- Môžete replikovať čokoľvek – akúkoľvek aplikáciu, akékoľvek údaje – a vždy to bude konzistentné. Mnoho (väčšina) aplikácií nemá replikačné schopnosti a repliky z úložného systému sú jediným spôsobom, ako poskytnúť ochranu pred katastrofami.
- Za funkčnosť replikácie aplikácií nie je potrebné preplácať. Spravidla to nie je lacné, rovnako ako licencie na repliku úložného systému. Za licenciu na replikáciu úložiska ale musíte zaplatiť raz a licenciu na repliku aplikácie je potrebné zakúpiť pre každú aplikáciu samostatne. Ak existuje veľa takýchto aplikácií, potom to stojí pekný cent a náklady na licencie na replikáciu úložiska sa stanú kvapkou.
Argumenty PROTI replikácii úložiska:
- Replika cez aplikácie má viac funkcionality z pohľadu samotných aplikácií, aplikácia lepšie pozná svoje dáta (samozrejme), takže je viac možností, ako s nimi pracovať.
- Výrobcovia niektorých aplikácií nezaručujú konzistentnosť svojich údajov, ak sa replikácia vykonáva pomocou nástrojov tretích strán. *
* - kontroverzná téza. Napríklad známy výrobca DBMS už veľmi dlho oficiálne vyhlasuje, že ich DBMS je možné normálne replikovať iba pomocou ich prostriedkov a zvyšok replikácie (vrátane úložných systémov) „nie je pravdivý“. Život však ukázal, že to tak nie je. S najväčšou pravdepodobnosťou (ale nie je to isté) to jednoducho nie je najčestnejší pokus predať viac licencií zákazníkom.
Výsledkom je, že vo väčšine prípadov je replikácia z úložného systému lepšia, pretože Ide o jednoduchšiu a lacnejšiu možnosť, ale existujú zložité prípady, keď je potrebná špecifická funkčnosť aplikácie a je potrebné pracovať s replikáciou na úrovni aplikácie.
Hotovo s teóriou, teraz praxou
Repliku nakonfigurujeme v našom laboratóriu. V laboratórnych podmienkach sme emulovali dve dátové centrá (v skutočnosti dva susediace stojany, ktoré sa zdali byť v rôznych budovách). Stojan pozostáva z dvoch úložných systémov Engine N2, ktoré sú navzájom prepojené optickými káblami. Fyzický server so systémom Windows Server 2016 je pripojený k obom úložným systémom pomocou 10Gb Ethernetu. Stojan je celkom jednoduchý, ale to nič nemení na podstate.
Schematicky to vyzerá takto:
Logicky je replikácia organizovaná nasledovne:
Teraz sa pozrime na replikačnú funkciu, ktorú teraz máme.
Podporované sú dva režimy: asynchrónny a synchrónny. Je logické, že synchrónny režim je obmedzený vzdialenosťou a komunikačným kanálom. Najmä synchrónny režim vyžaduje použitie vlákna ako fyzika a 10 Gigabit Ethernet (alebo vyšší).
Podporovaná vzdialenosť pre synchrónnu replikáciu je 40 kilometrov, hodnota oneskorenia optického kanála medzi dátovými centrami je do 2 milisekúnd. Vo všeobecnosti to bude fungovať s veľkými oneskoreniami, ale potom dôjde k silným spomaleniam pri nahrávaní (čo je tiež logické), takže ak plánujete synchrónnu replikáciu medzi dátovými centrami, mali by ste skontrolovať kvalitu optiky a oneskorenia.
Požiadavky na asynchrónnu replikáciu nie sú také závažné. Presnejšie povedané, vôbec tam nie sú. Postačí akékoľvek funkčné ethernetové pripojenie.
V súčasnosti úložný systém AERODISK ENGINE podporuje replikáciu pre blokové zariadenia (LUN) cez protokol Ethernet (cez meď alebo optiku). Pre projekty, kde je potrebná replikácia cez sieť SAN cez Fibre Channel, aktuálne pridávame vhodné riešenie, ktoré však ešte nie je pripravené, takže v našom prípade iba Ethernet.
Replikácia môže fungovať medzi ľubovoľnými úložnými systémami série ENGINE (N1, N2, N4) od juniorských systémov po staršie a naopak.
Funkčnosť oboch režimov replikácie je úplne identická. Nižšie sú uvedené ďalšie podrobnosti o tom, čo je k dispozícii:
- Replikácia „one to one“ alebo „one to one“, teda klasická verzia s dvomi dátovými centrami, hlavným a záložným
- Replikácia je „jedna k mnohým“ alebo „jedna k mnohým“, t.j. jeden LUN je možné replikovať do niekoľkých úložných systémov naraz
- Aktivujte, deaktivujte a „obrátte“ replikáciu, aby ste povolili, zakázali alebo zmenili smer replikácie
- Replikácia je dostupná pre fondy RDG (Raid Distributed Group) aj DDP (Dynamic Disk Pool). LUN fondu RDG však možno replikovať iba do iného RDG. To isté s DDP.
Existuje oveľa viac malých funkcií, ale nemá zmysel ich uvádzať; spomenieme ich pri nastavovaní.
Nastavenie replikácie
Proces nastavenia je pomerne jednoduchý a pozostáva z troch fáz.
- Nastavenie siete
- Nastavenie úložiska
- Nastavenie pravidiel (pripojení) a mapovanie
Dôležitým bodom pri nastavovaní replikácie je, že prvé dve etapy by sa mali opakovať na vzdialenom úložnom systéme, tretia etapa - iba na hlavnom.
Nastavenie sieťových prostriedkov
Prvým krokom je konfigurácia sieťových portov, cez ktoré sa bude prenášať replikačná prevádzka. Ak to chcete urobiť, musíte povoliť porty a nastaviť ich IP adresy v časti Front-end adaptéry.
Potom musíme vytvoriť fond (v našom prípade RDG) a virtuálnu IP na replikáciu (VIP). VIP je plávajúca adresa IP, ktorá je prepojená s dvoma „fyzickými“ adresami radičov úložiska (porty, ktoré sme práve nakonfigurovali). Toto bude hlavné replikačné rozhranie. Môžete tiež pracovať nie s VIP, ale s VLAN, ak potrebujete pracovať s označenou prevádzkou.
Proces vytvárania VIP pre repliku sa príliš nelíši od vytvárania VIP pre I/O (NFS, SMB, iSCSI). V tomto prípade vytvoríme bežný VIP (bez VLAN), ale nezabudnite uviesť, že je určený na replikáciu (bez tohto ukazovateľa nebudeme môcť VIP pridať do pravidla v ďalšom kroku).
VIP musí byť v rovnakej podsieti ako IP porty, medzi ktorými pláva.
Tieto nastavenia zopakujeme na vzdialenom úložnom systéme, samozrejme s inou IP.
VIP z rôznych úložných systémov môžu byť v rôznych podsieťach, hlavná vec je, že medzi nimi existuje smerovanie. V našom prípade je tento príklad presne zobrazený (192.168.3.XX a 192.168.2.XX)
Tým je príprava sieťovej časti hotová.
Nastavenie úložiska
Nastavenie úložiska pre repliku sa od bežného líši len tým, že mapovanie robíme cez špeciálne menu „Mapovanie replikácie“. Inak je všetko rovnaké ako pri bežnom nastavení. Teraz po poriadku.
V predtým vytvorenej oblasti R02 musíte vytvoriť LUN. Poďme si ho vytvoriť a nazvime ho LUN1.
Musíme tiež vytvoriť rovnakú LUN na vzdialenom úložnom systéme rovnakej veľkosti. Tvoríme. Aby ste sa vyhli nejasnostiam, zavolajte na vzdialenú LUN LUN1R
Ak by sme potrebovali vziať LUN, ktorý už existuje, tak pri nastavovaní repliky by sme potrebovali odpojiť túto produktívnu LUN od hostiteľa a jednoducho vytvoriť prázdnu LUN rovnakej veľkosti na vzdialenom úložnom systéme.
Nastavenie úložiska je dokončené, prejdime k vytvoreniu pravidla replikácie.
Nastavenie pravidiel replikácie alebo prepojení replikácie
Po vytvorení LUN na úložnom systéme, ktorý bude momentálne primárny, nakonfigurujeme replikačné pravidlo LUN1 na úložnom systéme 1 až LUN1R na úložnom systéme 2.
Nastavenie sa vykonáva v menu „Vzdialená replikácia“.
Vytvorme pravidlo. Ak to chcete urobiť, musíte určiť príjemcu repliky. Tam nastavíme aj názov pripojenia a typ replikácie (synchrónna alebo asynchrónna).
Do poľa „vzdialené systémy“ pridáme náš úložný systém2. Na pridanie je potrebné použiť správcovské IP úložné systémy (MGR) a názov vzdialenej LUN, do ktorej budeme vykonávať replikáciu (v našom prípade LUN1R). Kontrolné IP sú potrebné iba vo fáze pridávania pripojenia, cez ne sa nebude prenášať replikačná prevádzka, použije sa na to predtým nakonfigurovaný VIP.
Už v tejto fáze môžeme pridať viac ako jeden vzdialený systém pre topológiu „jeden k mnohým“: kliknite na tlačidlo „pridať uzol“, ako na obrázku nižšie.
V našom prípade existuje iba jeden vzdialený systém, takže sa obmedzujeme na toto.
Pravidlo je pripravené. Upozorňujeme, že sa pridáva automaticky na všetkých účastníkov replikácie (v našom prípade sú dvaja). Môžete vytvoriť toľko pravidiel, koľko chcete, pre ľubovoľný počet LUN a v akomkoľvek smere. Napríklad na vyváženie záťaže môžeme replikovať časť LUN z úložného systému 1 do úložného systému 2 a druhú časť, naopak, z úložného systému 2 do úložného systému 1.
Úložný systém 1. Ihneď po vytvorení sa začala synchronizácia.
Úložný systém 2. Vidíme rovnaké pravidlo, ale synchronizácia už skončila.
LUN1 na úložnom systéme 1 je v úlohe Primárne, to znamená, že je aktívny. LUN1R na úložnom systéme 2 je v úlohe sekundárneho, to znamená, že je v pohotovostnom režime pre prípad zlyhania úložného systému 1.
Teraz môžeme pripojiť našu LUN k hostiteľovi.
Pripojíme sa cez iSCSI, aj keď sa to dá aj cez FC. Nastavenie mapovania cez iSCSI LUN v replike sa prakticky nelíši od bežného scenára, takže sa tu nebudeme podrobne zaoberať. Tento proces je popísaný v článku „".
Jediný rozdiel je v tom, že mapovanie vytvárame v menu „Mapovanie replikácie“.
Nastavili sme mapovanie a odovzdali LUN hostiteľovi. Hostiteľ videl LUN.
Naformátujeme ho do lokálneho súborového systému.
To je všetko, nastavenie je dokončené. Na rad prídu testy.
Testovanie
Otestujeme tri hlavné scenáre.
- Pravidelné prepínanie rolí Sekundárne > Primárne. Pravidelné prepínanie rolí je potrebné v prípade, ak napríklad potrebujeme vykonať nejaké preventívne operácie v hlavnom dátovom centre a počas tejto doby, aby boli dáta dostupné, prenesieme záťaž do záložného dátového centra.
- Núdzové prepínanie rolí Sekundárne > Primárne (zlyhanie dátového centra). Toto je hlavný scenár, pre ktorý existuje replikácia, ktorá môže pomôcť prežiť úplné zlyhanie dátového centra bez zastavenia spoločnosti na dlhšie obdobie.
- Rozdelenie komunikačných kanálov medzi dátovými centrami. Kontrola správneho správania sa dvoch úložných systémov v podmienkach, keď z nejakého dôvodu nie je dostupný komunikačný kanál medzi dátovými centrami (napríklad bager vykopal na nesprávnom mieste a rozbil tmavú optiku).
Najprv začneme zapisovať dáta do našej LUN (zápis súborov s náhodnými dátami). Okamžite vidíme, že sa využíva komunikačný kanál medzi úložnými systémami. Je to ľahké pochopiť, ak otvoríte monitorovanie zaťaženia portov, ktoré sú zodpovedné za replikáciu.
Oba úložné systémy majú teraz „užitočné“ dáta, môžeme spustiť test.
Pre každý prípad sa pozrime na hašovacie súčty jedného zo súborov a zapíšme si ich.
Pravidelné striedanie rolí
Operáciu prepínania rolí (zmenu smeru replikácie) je možné vykonať s akýmkoľvek úložným systémom, ale stále budete musieť prejsť na oba, pretože budete musieť zakázať mapovanie na primárnom a povoliť ho na sekundárnom (ktorý sa stane primárnym ).
Možno teraz vyvstáva rozumná otázka: prečo to nezautomatizovať? Odpoveď znie: je to jednoduché, replikácia je jednoduchým prostriedkom odolnosti voči katastrofám, ktorý je založený výlučne na manuálnych operáciách. Na automatizáciu týchto operácií existuje režim metrocluster, ktorý je plne automatizovaný, ale jeho konfigurácia je oveľa komplikovanejšia. O nastavení metroklastra si napíšeme v ďalšom článku.
V hlavnom úložnom systéme deaktivujeme mapovanie, aby sme zabezpečili, že sa nahrávanie zastaví.
Potom na jednom z úložných systémov (na tom nezáleží, na hlavnom alebo záložnom) v ponuke „Vzdialená replikácia“ vyberte naše pripojenie REPL1 a kliknite na „Zmeniť rolu“.
Po niekoľkých sekundách sa LUN1R (záložný úložný systém) stane primárnym.
Mapujeme LUN1R s úložným systémom2.
Potom sa náš disk E: automaticky pripojí k hostiteľovi, ale tentoraz „prišiel“ z LUN1R.
Pre každý prípad porovnávame hashové sumy.
Zhodne. Test prešiel.
Failover. Porucha dátového centra
V súčasnosti je hlavným úložným systémom po pravidelnom prepínaní úložný systém 2, resp. LUN1R. Aby sme napodobnili nehodu, vypneme napájanie oboch radičov úložiska2.
Už k nemu nie je prístup.
Pozrime sa, čo sa deje na úložnom systéme 1 (v súčasnosti záložnom).
Vidíme, že primárny LUN (LUN1R) nie je dostupný. Chybové hlásenie sa objavilo v protokoloch, na informačnom paneli a tiež v samotnom pravidle replikácie. Údaje od hostiteľa sú preto momentálne nedostupné.
Zmeňte rolu LUN1 na Primárnu.
Robím mapovanie k hostiteľovi.
Uistite sa, že sa na hostiteľovi zobrazuje jednotka E.
Kontrolujeme hash.
Všetko je v poriadku. Úložný systém úspešne prežil pád dátového centra, ktoré bolo aktívne. Približný čas, ktorý sme strávili pripojením replikačného „reverzu“ a pripojením LUN zo záložného dátového centra, boli asi 3 minúty. Je jasné, že v reálnej produkcii je všetko oveľa komplikovanejšie a okrem akcií s úložnými systémami je potrebné vykonať oveľa viac operácií na sieti, na hostiteľoch, v aplikáciách. A v živote bude toto obdobie oveľa dlhšie.
Tu by som chcel napísať, že všetko, test bol úspešne dokončený, ale neponáhľajme sa. Hlavný úložný systém „leží“, vieme, že keď „spadol“, bol v úlohe Primárneho. Čo sa stane, ak sa náhle zapne? Budú dve primárne úlohy, čo sa rovná poškodeniu údajov? Teraz to skontrolujeme.
Zrazu zapnime základný úložný systém.
Načítava sa niekoľko minút a potom sa po krátkej synchronizácii vráti do prevádzky, ale v úlohe Sekundárneho.
Všetko OK. Rozštiepený mozog sa nestal. Mysleli sme na to a vždy po páde sa skladovací systém povýši na úlohu Sekundárneho, bez ohľadu na to, akú úlohu mal „počas života“. Teraz môžeme s istotou povedať, že test zlyhania dátového centra bol úspešný.
Zlyhanie komunikačných kanálov medzi dátovými centrami
Hlavnou úlohou tohto testu je uistiť sa, že úložný systém sa nezačne správať divne, ak dočasne stratí komunikačné kanály medzi dvoma úložnými systémami a potom sa znova objaví.
Takže. Odpájame drôty medzi skladovacími systémami (predstavme si, že ich kopal bager).
Na Primárne vidíme, že neexistuje žiadne spojenie so sekundárnym.
Na sekundárnom vidíme, že neexistuje žiadne spojenie s primárnym.
Všetko funguje dobre a pokračujeme v zapisovaní údajov do hlavného úložného systému, to znamená, že sa zaručene líšia od záložného, to znamená, že sa „oddelili“.
Za pár minút „opravíme“ komunikačný kanál. Akonáhle sa úložné systémy navzájom uvidia, automaticky sa aktivuje synchronizácia dát. Tu sa od správcu nič nevyžaduje.
Po určitom čase je synchronizácia dokončená.
Spojenie bolo obnovené, strata komunikačných kanálov nespôsobila núdzové situácie a po zapnutí prebehla automaticky synchronizácia.
Závery
Rozoberali sme teóriu – čo je potrebné a prečo, kde sú plusy a kde mínusy. Potom nastavíme synchrónnu replikáciu medzi dvoma úložnými systémami.
Ďalej boli vykonané základné testy na normálne prepínanie, poruchu dátového centra a poruchu komunikačného kanála. Vo všetkých prípadoch úložný systém fungoval dobre. Pri manuálnom scenári nedochádza k strate údajov a administratívne operácie sú obmedzené na minimum.
Nabudúce si situáciu skomplikujeme a ukážeme si, ako celá táto logika funguje v automatizovanom metroklastri v aktívnom-aktívnom režime, teda keď sú oba úložné systémy primárne a správanie v prípade výpadkov úložného systému je plne automatizované.
Píšte komentáre, budeme radi, ak dostaneme rozumnú kritiku a praktické rady.
Dobudúcna.
Zdroj: hab.com