Sziasztok Habr olvasók! Ennek a cikknek a témája a katasztrófa-helyreállítási eszközök megvalósítása lesz az AERODISK Engine tárolórendszerekben. Kezdetben egy cikkben szerettünk volna írni mindkét eszközről: a replikációról és a metroclusterről, de sajnos a cikk túl hosszúnak bizonyult, ezért a cikket két részre osztottuk. Menjünk az egyszerűtől a bonyolult felé. Ebben a cikkben a szinkron replikációt állítjuk be és teszteljük – egy adatközpontot eldobunk, valamint megszakítjuk az adatközpontok közötti kommunikációs csatornát, és meglátjuk, mi történik.
Ügyfeleink gyakran tesznek fel különféle kérdéseket a replikációval kapcsolatban, ezért mielőtt rátérnénk a replikák beállítására és megvalósításának tesztelésére, eláruljuk, mi is az a replikáció a tárhelyen.
Egy kis elmélet
A tárolórendszerekben történő replikáció egy folyamatos folyamat, amely során több tárolórendszeren egyszerre biztosítják az adatok azonosságát. Technikailag a replikáció kétféleképpen valósul meg.
Szinkron replikáció – ez az adatok másolása a fő tárolórendszerről a tartalék rendszerre, majd mindkét tárolórendszer kötelező megerősítése, hogy az adatok rögzítésre és megerősítésre kerültek. Mindkét oldal (mindkét tárolórendszer) megerősítése után tekinthető az adatok rögzítettnek és feldolgozhatók. Ez garantált adatazonosságot biztosít a replikában részt vevő összes tárolórendszeren.
Ennek a módszernek az előnyei:
- Az adatok minden tárolórendszeren mindig azonosak
Hátrányok:
- A megoldás magas költsége (gyors kommunikációs csatornák, drága optikai szál, hosszúhullámú adó-vevők stb.)
- Távolságkorlátozás (több tíz kilométeren belül)
- Nincs védelem a logikai adatsérülés ellen (ha az adatok megsérülnek (szándékosan vagy véletlenül) a fő tárolórendszeren, az automatikusan és azonnal megsérül a tartalékon, mivel az adatok mindig azonosak (ez a paradoxon)
Aszinkron replikáció – ez is az adatok másolása a fő tárolórendszerről a tartalék rendszerre, de bizonyos késéssel és anélkül, hogy meg kellene erősíteni a másik oldali írást. Az adatokkal a fő tárolórendszerre történő rögzítés után azonnal dolgozhat, a tartalék tárolórendszeren pedig egy idő után elérhetők lesznek az adatok. Az adatok azonossága ebben az esetben természetesen egyáltalán nem biztosított. A biztonsági mentési rendszeren lévő adatok mindig „a múltban” vannak.
Az aszinkron replikáció előnyei:
- Olcsó megoldás (bármilyen kommunikációs csatorna, opcionális optika)
- Nincs távolság korlátozás
- A biztonsági mentési rendszeren az adatok nem romlanak meg, ha a fő rendszeren (legalábbis egy ideig) megsérülnek; ha az adatok megsérülnek, mindig leállíthatja a replikát, hogy megakadályozza az adatsérülést a biztonsági mentési tárolórendszeren
Hátrányok:
- A különböző adatközpontokban lévő adatok nem mindig azonosak
Így a replikációs mód kiválasztása az üzleti céloktól függ. Ha kritikus fontosságú az Ön számára, hogy a biztonsági mentési adatközpont pontosan ugyanazokat az adatokat tartalmazza, mint a fő adatközpont (vagyis az RPO üzleti követelménye = 0), akkor ki kell fizetnie a készpénzt, és el kell viselnie a szinkron korlátait. másolat. És ha az adatállapot késése elfogadható, vagy egyszerűen nincs pénz, akkor feltétlenül az aszinkron módszert kell használnia.
Külön kiemeljünk egy olyan módot (pontosabban egy topológiát), mint a metrocluster. Metrocluster módban szinkron replikáció használatos, de a normál replikától eltérően a metrocluster lehetővé teszi mindkét tárolórendszer aktív módban történő működését. Azok. nem választja el az aktív és a készenléti adatközpontokat. Az alkalmazások egyszerre működnek két tárolórendszerrel, amelyek fizikailag különböző adatközpontokban helyezkednek el. Az ilyen topológiájú balesetek során fellépő leállások nagyon kicsik (RTO, általában perc). Ebben a cikkben nem foglalkozunk a metrocluster megvalósításával, mivel ez egy nagyon nagy és terjedelmes téma, ezért ennek folytatásaként külön, következő cikket szentelünk neki.
Ezenkívül nagyon gyakran, amikor a tárolórendszereket használó replikációról beszélünk, sok emberben ésszerű kérdés merül fel: > „Sok alkalmazásnak saját replikációs eszköze van, miért érdemes replikációt használni tárolórendszereken? Jobb vagy rosszabb?
Itt nincs egyértelmű válasz, ezért itt vannak a PRO és a KONSZ érvek:
Érvek a tárhelyreplikációra:
- A megoldás egyszerűsége. Egyetlen eszközzel replikálhatja a teljes adatkészletet, függetlenül a terhelés típusától és az alkalmazástól. Ha alkalmazásokból származó replikát használ, minden alkalmazást külön kell konfigurálnia. Ha 2-nél több van belőlük, akkor ez rendkívül munkaigényes és költséges (az alkalmazás replikációjához általában külön és nem ingyenes licenc szükséges minden alkalmazáshoz. De erről lentebb).
- Bármit lemásolhat – bármilyen alkalmazást, bármilyen adatot –, és mindig konzisztens lesz. Sok (a legtöbb) alkalmazás nem rendelkezik replikációs képességekkel, és a tárolórendszer replikái az egyetlen módja annak, hogy védelmet nyújtsanak a katasztrófák ellen.
- Nem kell túlfizetni az alkalmazás replikációs funkcióiért. Általános szabály, hogy nem olcsó, akárcsak a tárolórendszer-replika licencei. A tárhelyreplikáció licencéért azonban egyszer fizetnie kell, és az alkalmazás replikájának licencét minden alkalmazáshoz külön kell megvásárolni. Ha sok ilyen alkalmazás van, akkor ez egy jó fillérbe kerül, és a tárhelyreplikáció licencek költsége csepp a kosárban.
Érvek a tárolási replikáció ELLEN:
- Az alkalmazásokon keresztüli replika több funkcionalitással rendelkezik maguknak az alkalmazásoknak a szempontjából, az alkalmazás jobban ismeri az adatait (nyilvánvalóan), így több lehetőség van a velük való munkavégzésre.
- Egyes alkalmazások gyártói nem garantálják adataik konzisztenciáját, ha a replikáció harmadik féltől származó eszközökkel történik. *
* - vitatott tézis. Például egy jól ismert DBMS-gyártó már nagyon régóta hivatalosan kijelenti, hogy az ő DBMS-üket csak az eszközeik segítségével lehet normálisan replikálni, és a replikáció többi része (beleértve a tárolórendszereket is) „nem igaz”. De az élet megmutatta, hogy ez nem így van. Valószínűleg (de ez nem biztos) egyszerűen nem ez a legőszintébb kísérlet arra, hogy több licencet adjunk el az ügyfeleknek.
Ennek eredményeként a legtöbb esetben jobb a replikáció a tárolórendszerről, mert Ez egy egyszerűbb és olcsóbb lehetőség, de vannak összetett esetek, amikor speciális alkalmazásfunkciókra van szükség, és alkalmazásszintű replikációval kell dolgozni.
Kész az elmélettel, most a gyakorlattal
A replikát a laborunkban konfiguráljuk. Laboratóriumi körülmények között két adatközpontot emuláltunk (valójában két szomszédos állványt, amelyek úgy tűnt, hogy különböző épületekben voltak). Az állvány két Engine N2 tárolórendszerből áll, amelyek optikai kábelekkel kapcsolódnak egymáshoz. A Windows Server 2016 rendszert futtató fizikai szerver mindkét tárolórendszerhez csatlakozik 10 Gb Ethernet segítségével. Az állvány meglehetősen egyszerű, de ez nem változtat a lényegen.
Sematikusan így néz ki:
Logikailag a replikáció a következőképpen szerveződik:
Most pedig nézzük meg a mostani replikációs funkciót.
Két mód támogatott: aszinkron és szinkron. Logikus, hogy a szinkron üzemmódot a távolság és a kommunikációs csatorna korlátozza. Különösen a szinkron mód megköveteli az üvegszálas fizika és a 10 Gigabit Ethernet (vagy magasabb) használatát.
A szinkron replikáció támogatott távolsága 40 kilométer, az adatközpontok közötti optikai csatorna késleltetési értéke legfeljebb 2 milliszekundum. Általánosságban elmondható, hogy nagy késéssel fog működni, de ilyenkor erős lassulások lesznek rögzítés közben (ami logikus is), így ha az adatközpontok között szinkron replikációt tervezünk, érdemes ellenőrizni az optika minőségét és a késéseket.
Az aszinkron replikáció követelményei nem olyan komolyak. Pontosabban, egyáltalán nincsenek ott. Bármilyen működő Ethernet kapcsolat megteszi.
Jelenleg az AERODISK ENGINE tárolórendszer támogatja a blokkeszközök (LUN-ok) replikációját Ethernet protokollon keresztül (réz vagy optikai úton). Azokhoz a projektekhez, ahol a szálas csatornán keresztüli SAN-szöveten keresztüli replikáció szükséges, jelenleg egy megfelelő megoldást adunk hozzá, de az még nincs készen, így esetünkben csak Ethernet.
A replikáció bármely ENGINE sorozatú tárolórendszer (N1, N2, N4) között működhet, a fiatalabb rendszerektől a régebbiekig és fordítva.
A két replikációs mód funkcionalitása teljesen azonos. Az alábbiakban további részleteket olvashat arról, hogy mi áll rendelkezésre:
- Replikáció „egy az egyhez” vagy „egy az egyhez”, vagyis a klasszikus változat két adatközponttal, a fő és a biztonsági másolattal
- A replikáció „egy a sokhoz” vagy „egy a sokhoz”, azaz. egy LUN egyszerre több tárolórendszerre replikálható
- A replikáció aktiválása, deaktiválása és „fordítása” a replikáció engedélyezéséhez, letiltásához vagy irányának megváltoztatásához
- A replikáció az RDG (Raid Distributed Group) és a DDP (dinamikus lemeztár) készletekhez egyaránt elérhető. Egy RDG-készlet LUN-jait azonban csak egy másik RDG-re lehet replikálni. Ugyanez a DDP-vel.
Sokkal több apró funkció van, de nincs különösebb értelme felsorolni őket; a beállítás során megemlítjük őket.
Replikáció beállítása
A beállítási folyamat meglehetősen egyszerű, és három szakaszból áll.
- Hálózati konfiguráció
- Tárolás beállítása
- Szabályok (kapcsolatok) felállítása és leképezés
A replikáció beállításának fontos pontja, hogy az első két szakaszt meg kell ismételni a távoli tárolórendszeren, a harmadik szakaszt - csak a fő.
Hálózati erőforrások beállítása
Az első lépés a hálózati portok konfigurálása, amelyeken keresztül a replikációs forgalom továbbításra kerül. Ehhez engedélyeznie kell a portokat, és be kell állítania azok IP-címét a Front-end adapters részben.
Ezek után létre kell hoznunk egy készletet (esetünkben RDG-t) és egy virtuális IP-t replikációhoz (VIP). A VIP egy lebegő IP-cím, amely a tárolóvezérlők (az imént konfigurált portok) két „fizikai” címéhez van kötve. Ez lesz a fő replikációs felület. Nem VIP-el, hanem VLAN-nal is működhet, ha címkézett forgalommal kell dolgozni.
A replika VIP létrehozásának folyamata nem sokban különbözik az I/O (NFS, SMB, iSCSI) VIP létrehozásától. Ebben az esetben létrehozunk egy normál VIP-t (VLAN nélkül), de feltétlenül jelezzük, hogy replikációra szolgál (ezen mutató nélkül a következő lépésben nem tudjuk VIP-t hozzáadni a szabályhoz).
A VIP-nek ugyanabban az alhálózatban kell lennie, mint az IP-portoknak, amelyek között lebeg.
Ezeket a beállításokat egy távoli tárolórendszeren ismételjük meg, természetesen más IP-vel.
A különböző tárolórendszerekből származó VIP-ek különböző alhálózatokban lehetnek, a lényeg, hogy legyen közöttük útválasztás. Esetünkben ez a példa pontosan látható (192.168.3.XX és 192.168.2.XX)
Ezzel befejeződik a hálózati rész előkészítése.
Tárhely beállítása
A replika tárolásának beállítása csak annyiban tér el a megszokottól, hogy a leképezést egy speciális „Replikációs leképezés” menün keresztül végezzük. Egyébként minden ugyanaz, mint a normál beállításnál. Most sorrendben.
A korábban létrehozott R02 készletben létre kell hoznia egy LUN-t. Hozzuk létre, és hívjuk LUN1-nek.
Ugyanazt a LUN-t is létre kell hoznunk egy azonos méretű távoli tárolórendszeren. alkotunk. A félreértések elkerülése érdekében hívjuk a távoli LUN LUN1R-t
Ha egy már létező LUN-t kell vennünk, akkor a replika beállítása közben le kell kapcsolnunk ezt a hatékony LUN-t a gazdagépről, és egyszerűen létre kell hoznunk egy azonos méretű üres LUN-t a távoli tárolórendszeren.
A tárolás beállítása befejeződött, folytassuk a replikációs szabály létrehozását.
Replikációs szabályok vagy replikációs hivatkozások beállítása
Miután létrehozta a LUN-okat a tárolórendszeren, amely jelenleg az elsődleges lesz, az 1. tárolórendszer LUN1 replikációs szabályát a 1. tárolórendszeren a LUN2R-re konfiguráljuk.
A beállítás a „Távoli replikáció” menüben történik
Hozzunk létre egy szabályt. Ehhez meg kell adnia a replika címzettjét. Itt beállítjuk a kapcsolat nevét és a replikáció típusát is (szinkron vagy aszinkron).
A „távoli rendszerek” mezőben hozzáadjuk a tárolórendszerünket2. A hozzáadáshoz a felügyeleti IP-tárolórendszereket (MGR) és annak a távoli LUN-nak a nevét kell használnia, amelybe replikációt hajtunk végre (esetünkben LUN1R). A vezérlő IP-címekre csak a kapcsolat felvételének szakaszában van szükség, a replikációs forgalom nem továbbításra kerül rajtuk, ehhez a korábban beállított VIP-t használjuk.
Már ebben a szakaszban egynél több távoli rendszert is hozzáadhatunk az „egy a sokhoz” topológiához: kattintson a „csomópont hozzáadása” gombra, ahogy az alábbi ábrán látható.
A mi esetünkben csak egy távoli rendszer létezik, ezért erre korlátozzuk magunkat.
A szabály kész. Kérjük, vegye figyelembe, hogy a rendszer automatikusan hozzáadja az összes replikációs résztvevőhöz (esetünkben kettő van). Annyi ilyen szabályt hozhat létre, amennyit csak akar, tetszőleges számú LUN-hoz és bármilyen irányban. Például a terhelés kiegyensúlyozása érdekében az LUN-ok egy részét replikálhatjuk az 1. tárolórendszerről a 2. tárolórendszerre, a másik részét pedig éppen ellenkezőleg, a 2. tárolórendszerről az 1. tárolórendszerre.
Tárolórendszer 1. Közvetlenül a létrehozás után megkezdődött a szinkronizálás.
Tárolórendszer 2. Ugyanezt a szabályt látjuk, de a szinkronizálás már véget ért.
Az 1. tárolórendszeren lévő LUN1 elsődleges szerepkörben van, azaz aktív. A 1. tárolórendszeren a LUN2R másodlagos szerepkörben van, azaz készenléti állapotban van, ha az 1. tárolórendszer meghibásodik.
Most már csatlakoztathatjuk a LUN-unkat a gazdagéphez.
iSCSI-n keresztül fogunk csatlakozni, bár ez FC-n keresztül is megtehető. A leképezés iSCSI LUN-on keresztüli beállítása egy replikában gyakorlatilag nem különbözik a szokásos forgatókönyvtől, ezért itt nem foglalkozunk vele részletesen. Ha valami, ezt a folyamatot a cikk írja le "".
Az egyetlen különbség az, hogy a „Replikációs leképezés” menüben hozzuk létre a leképezést
Beállítottuk a térképezést, és megadtuk a LUN-t a házigazdának. A házigazda meglátta a LUN-t.
Helyi fájlrendszerbe formázzuk.
Ez az, a beállítás kész. A tesztek ezután következnek.
tesztelés
Három fő forgatókönyvet fogunk tesztelni.
- Rendszeres szerepváltás Másodlagos > Elsődleges. Rendszeres szerepváltásra van szükség arra az esetre, ha például a fő adatközpontban megelőző műveleteket kell végeznünk, és ez idő alatt, hogy az adatok elérhetőek legyenek, a terhelést átvisszük a tartalék adatközpontba.
- Vészhelyzeti szerepváltás Másodlagos > Elsődleges (adatközponti hiba). Ez a replikáció fő forgatókönyve, amely segíthet túlélni egy teljes adatközponti meghibásodást anélkül, hogy a vállalatot hosszabb időre leállítaná.
- Az adatközpontok közötti kommunikációs csatornák lebontása. Két tárolórendszer helyes működésének ellenőrzése olyan körülmények között, amikor valamilyen okból nem elérhető az adatközpontok közötti kommunikációs csatorna (például rossz helyen ásott kotrógép, és eltörte a sötét optikát).
Először elkezdjük írni az adatokat a LUN-ba (véletlenszerű adatokkal). Azonnal látjuk, hogy a tárolórendszerek közötti kommunikációs csatorna kihasználva van. Ez könnyen megérthető, ha megnyitja a replikációért felelős portok terhelésfigyelését.
Mindkét tárolórendszer rendelkezik „hasznos” adatokkal, kezdhetjük a tesztet.
Minden esetre nézzük meg az egyik fájl hash összegét, és írjuk le.
Rendszeres szerepváltás
A szerepek váltása (a replikáció irányának megváltoztatása) bármely tárolórendszerrel elvégezhető, de továbbra is mindkettőre kell menni, mivel az elsődlegesen le kell tiltani a leképezést, a másodlagoson pedig engedélyezni kell (amelyből elsődleges lesz ).
Talán most felmerül egy ésszerű kérdés: miért nem automatizáljuk ezt? A válasz: egyszerű, a replikáció a katasztrófákkal szembeni ellenálló képesség egyszerű eszköze, amely kizárólag kézi műveleteken alapul. Ezen műveletek automatizálására van egy metrocluster mód, amely teljesen automatizált, de a konfigurációja sokkal bonyolultabb. A metrocluster felállításáról a következő cikkben írunk.
A fő tárolórendszeren letiltjuk a leképezést, hogy biztosítsuk a rögzítés leállását.
Ezután az egyik tárolórendszeren (mindegy, a fő vagy a tartalék) a „Távoli replikáció” menüben válassza ki a REPL1 kapcsolatunkat, és kattintson a „Szerepkör módosítása” gombra.
Néhány másodperc múlva a LUN1R (tartalék tárolórendszer) elsődlegessé válik.
Leképezzük a LUN1R-t tárolórendszerrel2.
Ezek után az E: meghajtónk automatikusan csatlakozik a gazdagéphez, csak ezúttal a LUN1R-ről „érkezett”.
Minden esetre összehasonlítjuk a hash összegeket.
Ugyanúgy. Sikeres vizsga.
Feladatátvétel. Adatközpont hiba
Jelenleg a rendszeres kapcsolás után a fő tárolórendszer a 2. tárolórendszer, illetve a LUN1R. A baleset emulálásához mindkét tárolóvezérlőt kikapcsoljuk2.
Nincs több hozzáférési lehetőség hozzá.
Lássuk, mi történik az 1. tárolórendszeren (jelenleg a biztonsági rendszeren).
Azt látjuk, hogy az elsődleges LUN (LUN1R) nem érhető el. Hibaüzenet jelent meg a naplókban, az információs panelen és magában a replikációs szabályban is. Ennek megfelelően a gazdagéptől származó adatok jelenleg nem érhetők el.
Módosítsa a LUN1 szerepét Elsődlegesre.
Feltérképezést végzek a gazdához.
Győződjön meg arról, hogy az E meghajtó megjelenik a gazdagépen.
Ellenőrizzük a hash-t.
Minden rendben. A tárolórendszer sikeresen túlélte az aktív adatközpont bukását. A hozzávetőleges idő, amit a replikációs „visszafordítás” és a LUN csatlakoztatásával töltöttünk a biztonsági mentési adatközpontból, körülbelül 3 perc volt. Nyilvánvaló, hogy a valódi termelésben minden sokkal bonyolultabb, és a tárolórendszerekkel végzett műveletek mellett sokkal több műveletet kell végrehajtania a hálózaton, a gazdagépeken, az alkalmazásokban. És az életben ez az időszak sokkal hosszabb lesz.
Itt szeretném leírni, hogy minden, a teszt sikeresen lezajlott, de ne rohanjunk. A fő tárolórendszer „hazudik”, tudjuk, hogy amikor „leesett”, az Elsődleges szerepkörben volt. Mi történik, ha hirtelen bekapcsol? Két elsődleges szerepkör lesz, ami egyenlő az adatsérüléssel? Most nézzük meg.
Kapcsoljuk be hirtelen a mögöttes tárolórendszert.
Néhány percig betöltődik, majd rövid szinkronizálás után, de másodlagos szerepkörben visszatér a szolgáltatásba.
Minden oké. Az agyhasadás nem történt meg. Ezen gondolkoztunk, és mindig a bukás után a tárolórendszer másodlagos szerepkörbe emelkedik, függetlenül attól, hogy milyen szerepet töltött be az „élet során”. Most már biztosan kijelenthetjük, hogy az adatközponti hibateszt sikeres volt.
Az adatközpontok közötti kommunikációs csatornák meghibásodása
A teszt fő feladata annak biztosítása, hogy a tárolórendszer ne kezdjen furcsán viselkedni, ha átmenetileg elveszíti a kommunikációs csatornákat két tárolórendszer között, majd újra megjelenik.
Így. A tárolórendszerek közötti vezetékeket leválasztjuk (képzeljük el, hogy egy kotrógép ásta ki).
Az elsődlegesen azt látjuk, hogy nincs kapcsolat a másodlagossal.
A másodlagosnál azt látjuk, hogy nincs kapcsolat az Elsődlegessel.
Minden rendben működik, és továbbra is a fő tárolórendszerbe írjuk az adatokat, vagyis garantáltan eltérnek a tartaléktól, vagyis „szétváltak”.
Néhány perc alatt „megjavítjuk” a kommunikációs csatornát. Amint a tárolórendszerek látják egymást, automatikusan aktiválódik az adatszinkronizálás. Itt semmi sem szükséges az adminisztrátortól.
Egy idő után a szinkronizálás befejeződik.
A kapcsolat helyreállt, a kommunikációs csatornák elvesztése nem okozott vészhelyzetet, a bekapcsolás után automatikusan megtörtént a szinkronizálás.
Álláspontja
Elemeztük az elméletet - mire van szükség és miért, hol vannak az előnyök és hol a hátrányok. Ezután beállítjuk a szinkron replikációt két tárolórendszer között.
Ezt követően alapvető teszteket végeztek a normál kapcsolásra, az adatközpont meghibásodására és a kommunikációs csatorna meghibásodására. A tárolórendszer minden esetben jól működött. Nincs adatvesztés, és az adminisztratív műveletek a minimálisra csökkennek kézi forgatókönyv esetén.
Legközelebb bonyolítjuk a helyzetet, és megmutatjuk, hogyan működik mindez a logika egy automatizált metroclusterben aktív-aktív módban, vagyis amikor mindkét tárolórendszer elsődleges, és a tárolórendszer meghibásodása esetén a viselkedés teljesen automatizált.
Kérjük, írja meg észrevételeit, örömmel fogadjuk a megalapozott kritikát és gyakorlati tanácsokat.
Viszlát.
Forrás: will.com