Sziasztok Habr olvasók! Az utolsó cikkben az AERODISK ENGINE tárolórendszerek katasztrófa-helyreállításának egyszerű eszközéről beszéltünk - a replikációról. Ebben a cikkben egy összetettebb és érdekesebb témában merülünk el - a metroclusterben, azaz két adatközpont automatizált katasztrófavédelmében, amely lehetővé teszi az adatközpontok aktív-aktív módban történő működését. Megmondjuk, megmutatjuk, összetörjük és megjavítjuk.
Szokás szerint először az elmélet
A metroklaszter egy városon vagy régión belül több helyen elhelyezkedő klaszter. A „klaszter” szó egyértelműen arra utal, hogy a komplexum automatizált, vagyis a klaszter csomópontok váltása meghibásodás esetén automatikusan történik.
Ebben rejlik a fő különbség a metrocluster és a normál replikáció között. A műveletek automatizálása. Vagyis bizonyos incidensek (adatközpont meghibásodása, csatornatörés stb.) esetén a tárolórendszer önállóan elvégzi a szükséges műveleteket az adatok elérhetőségének megőrzése érdekében. Normál replikák használatakor ezeket a műveleteket részben vagy egészben manuálisan hajtja végre a rendszergazda.
Mit csinál?
A fő cél, amelyre az ügyfelek bizonyos metrocluster-megvalósítások használatakor törekednek, az RTO (Recovery Time Objective) minimalizálása. Azaz az IT-szolgáltatások hiba utáni helyreállítási idejének minimalizálása. Ha rendszeres replikációt használ, a helyreállítási idő mindig hosszabb lesz, mint a metrocluster helyreállítási ideje. Miért? Nagyon egyszerű. A rendszergazdának az asztalánál kell lennie, és manuálisan kell replikációt váltania, a metrocluster pedig ezt automatikusan megteszi.
Ha nincs ügyeletes adminisztrátora, aki nem alszik, nem eszik, nem dohányzik vagy nem betegszik meg, és a nap 24 órájában figyeli a tárolórendszer állapotát, akkor nem garantálható, hogy az adminisztrátor meghibásodás esetén kézi átkapcsolásra rendelkezésre álljon.
Ennek megfelelően az RTO metrocluster vagy a rendszergazdai ügyeleti szolgáltatás 99. szintű halhatatlan rendszergazdája hiányában egyenlő lesz az összes rendszer kapcsolási idejének összegével és azzal a maximális időtartammal, amely után az adminisztrátor garantáltan megkezdi a munkát. tárolórendszerekkel és kapcsolódó rendszerekkel.
Így arra a kézenfekvő következtetésre jutunk, hogy a metroclustert akkor kell használni, ha az RTO-igény percek, nem pedig órák vagy napok, vagyis amikor a legrosszabb adatközponti meghibásodás esetén az informatikai részlegnek kell időt biztosítania a vállalkozásnak. perceken vagy akár másodperceken belül visszaállíthatja az IT-szolgáltatásokhoz való hozzáférést.
Hogyan működik?
Az alsó szinten a metrocluster egy olyan mechanizmust használ a szinkron adatreplikációhoz, amelyet az előző cikkben ismertettünk (lásd. ). Mivel a replikáció szinkron, a követelmények megfelelőek, vagy inkább:
- optikai szál, mint fizika, 10 gigabites Ethernet (vagy magasabb);
- az adatközpontok közötti távolság nem haladja meg a 40 kilométert;
- Az optikai csatorna késleltetése az adatközpontok között (tárolórendszerek között) legfeljebb 5 milliszekundum (optimálisan 2).
Mindezek a követelmények tanácsadó jellegűek, vagyis a metroklaszter akkor is működik, ha ezek a követelmények nem teljesülnek, de meg kell értenünk, hogy ezeknek a követelményeknek a be nem tartása mindkét tárolórendszer működésének lelassulásával jár. a metroklaszter.
Tehát egy szinkron replikát használnak az adatátvitelre a tárolórendszerek között, és hogyan váltanak automatikusan a replikák, és ami a legfontosabb, hogyan lehet elkerülni az agy megosztottságát? Ehhez magasabb szinten egy további entitást használnak - egy választottbírót.
Hogyan működik a választottbíró és mi a feladata?
A döntőbíró egy kis virtuális gép vagy hardverfürt, amelyet egy harmadik helyen (például egy irodában) kell elindítani, és hozzáférést kell biztosítani a tárolórendszerhez ICMP-n és SSH-n keresztül. Indítás után a döntőbírónak be kell állítania az IP-t, majd a tárolási oldalról meg kell adnia annak címét, valamint a metroclusterben részt vevő távirányítók címét. Ezt követően a játékvezető készen áll a munkára.
A döntőbíró folyamatosan figyeli a metrocluster összes tárolórendszerét, és ha egy adott tárolórendszer nem elérhető, a klaszter egy másik tagjától (az „élő” tárolórendszerek egyikétől) történő elérhetetlenség megerősítése után úgy dönt, hogy elindítja a replikációs szabályok átállítási eljárását. és feltérképezése.
Nagyon fontos szempont. A választottbírónak mindig más helyen kell lennie, mint ahol a tárolórendszerek találhatók, azaz sem az 1. adatközpontban, ahol az 1. tárolórendszert telepítették, sem a 2. adatközpontban, ahol a 2. tárolórendszert telepítették.
Miért? Mert csak így tudja a döntőbíró az egyik fennmaradt tárolórendszer segítségével egyértelműen és pontosan megállapítani a tárolórendszerek telepítési helyének bármelyikének bukását. Bármilyen más döntőbíró felállítási módszer agyhasadást eredményezhet.
Most merüljünk el a választottbíró munkájának részleteiben.
A döntőbíró számos szolgáltatást futtat, amelyek folyamatosan lekérdezik az összes tárolóvezérlőt. Ha a szavazás eredménye eltér az előzőtől (elérhető/nem elérhető), akkor azt egy kis adatbázisban rögzítjük, ami a döntőbírón is működik.
Nézzük meg részletesebben a választottbírói munka logikáját.
1. lépés: Határozza meg az elérhetetlenséget. A tárolórendszer meghibásodása az, ha 5 másodpercen belül nem érkezik ping ugyanazon tárolórendszer mindkét vezérlőjétől.
2. lépés Indítsa el a kapcsolási eljárást. Miután a döntőbíró észrevette, hogy az egyik tárolórendszer nem elérhető, kérést küld az „élő” tárolórendszernek, hogy megbizonyosodjon arról, hogy a „halott” tárolórendszer valóban halott.
Miután megkapta a döntőbírótól egy ilyen parancsot, a második (élő) tárolórendszer ezenkívül ellenőrzi a kiesett első tárolórendszer elérhetőségét, és ha az nincs ott, visszaigazolást küld a döntőbírónak a találgatásáról. A tárolórendszer valóban nem elérhető.
A visszaigazolás kézhezvétele után a döntőbíró távoli eljárást indít a replikáció átváltására és a leképezés emelésére azokon a replikákon, amelyek aktívak (elsődlegesek) voltak a kiesett tárolórendszeren, és parancsot küld a második tárolórendszernek, hogy módosítsa ezeket a replikákat másodlagosról elsődlegesre, és feltérképezés emelése. Nos, a második tárolórendszer ennek megfelelően végrehajtja ezeket az eljárásokat, majd hozzáférést biztosít az elveszett LUN-okhoz.
Miért van szükség további ellenőrzésre? A határozatképességhez. Ez azt jelenti, hogy a fürttagok összes páratlan (3) számának többségének meg kell erősítenie az egyik fürtcsomópont bukását. Csak akkor lesz határozottan helyes ez a döntés. Erre azért van szükség, hogy elkerüljük a hibás kapcsolást és ennek megfelelően az agy megosztottságát.
A 2. lépés körülbelül 5-10 másodpercet vesz igénybe, így az elérhetetlenség megállapításához szükséges időt (5 másodperc) figyelembe véve a balesetet követő 10-15 másodpercen belül a leesett tárolórendszerből származó LUN-ok automatikusan elérhetővé válnak az élővel való munkához. tároló rendszer.
Nyilvánvaló, hogy a gazdagépekkel való kapcsolatok elvesztésének elkerülése érdekében ügyelnie kell az időkorlátok helyes beállítására is. Az ajánlott időkorlát legalább 30 másodperc. Ez megakadályozza, hogy a gazdagép megszakítsa a kapcsolatot a tárolórendszerrel a terhelésváltás során katasztrófa esetén, és biztosítani tudja, hogy ne legyenek I/O megszakítások.
Várj egy pillanatot, kiderül, hogy ha minden olyan jó a metroclusterrel, miért van szükségünk egyáltalán a rendszeres replikációra?
A valóságban minden nem ilyen egyszerű.
Nézzük meg a metroklaszter előnyeit és hátrányait
Tehát rájöttünk, hogy a metrocluster nyilvánvaló előnyei a hagyományos replikációhoz képest a következők:
- Teljes automatizálás, minimális helyreállítási idő biztosítása katasztrófa esetén;
- Ez minden :-).
És most figyelem, a hátrányok:
- Megoldás költsége. Bár az Aerodisk rendszerek metroclusteréhez nincs szükség további licencelésre (ugyanaz a licenc használatos, mint a replikánál), a megoldás költsége így is magasabb lesz, mint a szinkron replikáció használata. Meg kell valósítania a szinkron replikára vonatkozó összes követelményt, valamint a további váltásokhoz és további helyekhez kapcsolódó metrocluster követelményeit (lásd a metrocluster tervezését);
- A megoldás összetettsége. A metrocluster sokkal összetettebb, mint egy normál replika, és sokkal több figyelmet és erőfeszítést igényel a tervezéshez, a konfigurációhoz és a dokumentációhoz.
Végül is. A Metrocluster minden bizonnyal technológiailag nagyon fejlett és jó megoldás, ha valóban másodpercek vagy percek alatt kell RTO-t biztosítani. De ha nincs ilyen feladat, és az RTO órákban rendben van az üzlethez, akkor nincs értelme ágyúból verebeket lőni. A szokásos munkás-paraszt replikáció elegendő, hiszen egy nagyvárosi klaszter többletköltségeket és az informatikai infrastruktúra bonyolítását okozza.
Metrocluster tervezés
Ez a rész nem állítja, hogy átfogó útmutató a metrocluster tervezéshez, hanem csak azokat a főbb irányokat mutatja be, amelyeket érdemes kidolgozni, ha egy ilyen rendszer kiépítése mellett dönt. Ezért a metrocluster tényleges megvalósítása során mindenképpen vonjuk be a tárolórendszer gyártóját (vagyis minket) és a többi kapcsolódó rendszert konzultációra.
Helyszínek
Amint fentebb említettük, a metroclusterhez legalább három hely szükséges. Két adatközpont, ahol a tárolórendszerek és a kapcsolódó rendszerek működnek majd, valamint egy harmadik telephely, ahol a választottbíró fog dolgozni.
Az adatközpontok közötti ajánlott távolság legfeljebb 40 kilométer. A nagyobb távolság nagy valószínűséggel további késéseket okoz, ami egy metroklaszter esetében rendkívül nem kívánatos. Emlékeztetjük Önt, hogy a késések legfeljebb 5 milliszekundumot érhetnek el, bár ajánlatos 2-en belül tartani.
Javasoljuk a késések ellenőrzését a tervezési folyamat során is. Bármely többé-kevésbé érett szolgáltató, amely optikai szálat biztosít az adatközpontok között, elég gyorsan meg tudja szervezni a minőségellenőrzést.
Ami a választottbíró előtti késéseket illeti (vagyis a harmadik hely és az első kettő között), az ajánlott késleltetési küszöb legfeljebb 200 ezredmásodperc, vagyis megfelelő az interneten keresztüli rendszeres vállalati VPN-kapcsolat.
Kapcsolás és hálózat
Ellentétben a replikációs sémával, ahol elegendő a különböző helyekről származó tárolórendszerek csatlakoztatása, a metrocluster séma megköveteli a gazdagépek összekapcsolását mindkét tárolórendszerrel különböző helyeken. Annak érdekében, hogy világosabb legyen, mi a különbség, mindkét sémát az alábbiakban mutatjuk be.
Amint az a diagramból látható, az 1. oldal gazdagépei mind az 1., mind a 2. tárolórendszert nézik. Ellenkezőleg, a 2. oldal gazdagépei a 2. és az 1. tárolórendszert is megnézik. Vagyis minden gazdagép mindkét tárolórendszert látja. Ez a metroklaszter működésének előfeltétele.
Természetesen nem kell minden állomást optikai kábellel csatlakoztatni egy másik adatközponthoz, egyetlen port vagy vezeték sem lesz elég. Mindezeket a kapcsolatokat Ethernet 10G+ vagy FibreChannel 8G+ kapcsolókon keresztül kell létrehozni (az FC csak a gazdagépek és tárolórendszerek csatlakoztatására szolgál IO-hoz, a replikációs csatorna jelenleg csak IP-n keresztül érhető el (Ethernet 10G+).
Most néhány szó a hálózati topológiáról. Fontos szempont az alhálózatok helyes beállítása. Azonnal meg kell határozni több alhálózatot a következő típusú forgalomhoz:
- A replikációs alhálózat, amelyen keresztül az adatok szinkronizálva lesznek a tárolórendszerek között. Több is lehet, ebben az esetben ez mindegy, minden az aktuális (már megvalósított) hálózati topológiától függ. Ha kettő van, akkor nyilvánvalóan az útválasztást kell beállítani közöttük;
- Tárolási alhálózatok, amelyeken keresztül a gazdagépek hozzáférnek a tárolási erőforrásokhoz (ha iSCSI). Minden adatközpontban egy ilyen alhálózatnak kell lennie;
- Alhálózatok vezérlése, azaz három irányítható alhálózat három helyen, ahonnan a tárolórendszereket kezelik, és ott található a döntőbíró is.
Itt nem vesszük figyelembe az alhálózatokat a gazdagép erőforrások eléréséhez, mivel ezek nagymértékben függenek a feladatoktól.
A különböző forgalom különböző alhálózatokra történő szétválasztása rendkívül fontos (különösen fontos a replika és az I/O szétválasztása), mert ha az összes forgalmat egy „vastag” alhálózatba keverjük, akkor ezt a forgalmat nem lehet kezelni, és két adatközpont körülményei még mindig eltérő hálózati ütközési lehetőségeket okozhatnak. Ebben a cikkben nem foglalkozunk mélyebben, hiszen az adatközpontok között kifeszített hálózat tervezéséről a hálózati berendezések gyártóinak erőforrásairól olvashatunk, ahol ez igen részletesen le van írva.
Arbiter konfiguráció
A döntőbírónak hozzáférést kell biztosítania a tárolórendszer összes felügyeleti interfészéhez az ICMP és az SSH protokollokon keresztül. Gondolnia kell a választott bíró hibabiztosságára is. Van itt egy árnyalat.
A választott feladatátvétel nagyon kívánatos, de nem kötelező. Mi történik, ha a játékvezető rosszkor ütközik?
- A metrocluster működése normál üzemmódban nem változik, mert Az arbtir egyáltalán nincs hatással a metrocluster normál üzemmódban történő működésére (feladata az adatközpontok közötti terhelés időben történő átkapcsolása)
- Sőt, ha a döntőbíró ilyen vagy olyan okból elesik és „átalszik” egy balesetet az adatközpontban, akkor nem történik váltás, mert nem lesz senki, aki kiadja a szükséges kapcsolási parancsokat és megszervezi a határozatképességet. Ebben az esetben a metrocluster egy szokásos replikációs sémává változik, amelyet manuálisan kell váltani egy katasztrófa során, ami hatással lesz az RTO-ra.
Mi következik ebből? Ha valóban biztosítania kell a minimális RTO-t, akkor gondoskodnia kell arról, hogy a döntőbíró hibatűrő legyen. Erre két lehetőség van:
- Indítsunk el egy virtuális gépet egy hibatűrő hipervizor döntőjével, szerencsére minden felnőtt hipervizor támogatja a hibatűrést;
- Ha a harmadik helyen (egy hagyományos irodában) lusta egy normál klaszter telepítéséhez, és nincs meglévő hypervozor klaszter, akkor rendelkezésre bocsátottuk a döntőbíró hardveres verzióját, amely egy 2U-os dobozban készül, amelyben két normál fürt Az x-86 szerverek működnek, és túlélnek egy helyi hibát.
Nyomatékosan javasoljuk a döntőbíró hibatűrésének biztosítását, annak ellenére, hogy normál üzemmódban nincs rá szüksége a metroclusternek. De amint az elmélet és a gyakorlat is mutatja, ha valóban megbízható, katasztrófabiztos infrastruktúrát építesz, akkor jobb, ha biztonságosan játszol. Jobb, ha megvédi magát és vállalkozását az „aljasság törvényétől”, azaz mind a választottbíró, mind a tárolórendszer egyik helyszínének kudarcától.
Megoldás architektúra
A fenti követelményeket figyelembe véve a következő általános megoldási architektúrát kapjuk.
A súlyos túlterhelés elkerülése érdekében az LUN-okat egyenletesen kell elosztani két helyen. Ugyanakkor mindkét adatközpontban a méretezésnél nem csak a dupla mennyiséget kell figyelembe venni (ami az adatok egyidejű tárolásához szükséges két tárolórendszeren), hanem a dupla teljesítményt is IOPS-ben és MB/s-ban, hogy elkerüljük az alkalmazások leromlását. az egyik adatközpont meghibásodása ov.
Külön megjegyezzük, hogy a méretezés megfelelő megközelítésével (vagyis feltéve, hogy biztosítottuk az IOPS és MB/s megfelelő felső határait, valamint a szükséges CPU és RAM erőforrásokat), ha az egyik tárolórendszer a metró klaszter meghibásodik, nem lesz komoly teljesítménycsökkenés egy tárolórendszeren végzett ideiglenes munka mellett.
Ez azzal magyarázható, hogy amikor két hely egyidejűleg működik, a szinkron replikáció az írási teljesítmény felét „megeszi”, mivel minden tranzakciót két tárolórendszerre kell írni (hasonlóan a RAID-1/10-hez). Így ha valamelyik tárolórendszer meghibásodik, a replikáció hatása átmenetileg (amíg a meghibásodott tárolórendszer helyreáll) megszűnik, és az írási teljesítmény kétszeresére nő. Miután a meghibásodott tárolórendszer LUN-jai újraindításra kerülnek a működő tárolórendszeren, ez a kétszeres növekedés megszűnik, amiatt, hogy a másik tárolórendszer LUN-jaiból terhelés jelenik meg, és visszatérünk ugyanarra a teljesítményszintre, mint a korábbi tárolórendszeren. „esik”, de csak egy oldal keretein belül.
A hozzáértő méretezés segítségével olyan körülményeket biztosíthat, amelyek mellett a felhasználók egyáltalán nem érzik egy teljes tárolórendszer meghibásodását. De még egyszer megismételjük, ez nagyon körültekintő méretezést igényel, amihez egyébként ingyen felkereshetsz minket :-).
Metrocluster felállítása
A metrocluster beállítása nagyon hasonlít a szokásos replikáció beállításához, amelyet itt leírtunk . Ezért csak a különbségekre koncentráljunk. A laboratóriumban a fenti architektúra alapján állítottunk fel egy padot, csak minimális változatban: két 10G Etherneten keresztül összekötött tárolórendszer, két 10G switch és egy host, amely átnéz a switcheken mindkét 10G portos tárolórendszeren. A döntőbíró egy virtuális gépen fut.
Ha virtuális IP-címeket (VIP) konfigurál egy replikához, válassza ki a VIP típust - a metroclusterhez.
Létrehoztunk két replikációs hivatkozást két LUN-hoz, és elosztottuk azokat két tárolórendszer között: LUN TEST Elsődleges az 1. tárolórendszeren (METRO hivatkozás), LUN TEST2 Elsődleges a 2. tárolórendszerhez (METRO2 kapcsolat).
Számukra két azonos célt konfiguráltunk (esetünkben iSCSI, de az FC is támogatott, a beállítási logika ugyanaz).
Tárolási rendszer 1:
Tárolási rendszer 2:
A replikációs kapcsolatokhoz minden tárolórendszeren leképezéseket végeztek.
Tárolási rendszer 1:
Tárolási rendszer 2:
Több útvonalat állítottunk be, és bemutattuk a gazdagépnek.
Választottbíró felállítása
Magával az arbitrerrel nem kell semmi különöset tennie, csak engedélyeznie kell a harmadik oldalon, meg kell adnia egy IP-címet, és ICMP-n és SSH-n keresztül konfigurálnia kell a hozzáférést. Maga a beállítás a tárolórendszerekből történik. Ebben az esetben elegendő egyszer konfigurálni az arbitrátort a metrocluster bármelyik tárolóvezérlőjén, ezek a beállítások automatikusan elosztásra kerülnek az összes vezérlőhöz.
A Távoli replikáció>> Metrocluster (bármely vezérlőn)>> szakaszban a „Konfigurálás” gombot.
Megadjuk a döntőbíró IP-jét, valamint két távoli tárolóvezérlő vezérlő interfészét.
Ezt követően engedélyeznie kell az összes szolgáltatást (a „Minden újraindítása” gomb). Ha a jövőben újrakonfigurálják, a szolgáltatásokat újra kell indítani, hogy a beállítások életbe lépjenek.
Ellenőrizzük, hogy minden szolgáltatás fut-e.
Ezzel befejeződik a metrocluster beállítás.
Törésteszt
A hibateszt esetünkben meglehetősen egyszerű és gyors lesz, hiszen a replikációs funkcionalitásról (kapcsolás, konzisztencia stb.) a . Ezért a metrocluster megbízhatóságának teszteléséhez elegendő ellenőriznünk a hibaészlelés, kapcsolás automatizálását és a rögzítési veszteségek (I/O leállások) hiányát.
Ehhez az egyik tárolórendszer teljes meghibásodását emuláljuk úgy, hogy fizikailag kikapcsoljuk mindkét vezérlőjét, miután először elkezdtünk egy nagy fájlt másolni a LUN-ba, amelyet aktiválni kell a másik tárolórendszeren.
Egy tárolórendszer letiltása. A második tárolórendszeren riasztásokat és üzeneteket látunk a naplókban, hogy megszakadt a kapcsolat a szomszédos rendszerrel. Ha az SMTP-n vagy SNMP-n keresztüli értesítések konfigurálva vannak, a rendszergazda megkapja a megfelelő értesítéseket.
Pontosan 10 másodperccel később (mindkét képernyőképen látható) a METRO replikációs kapcsolat (amely a meghibásodott tárolórendszeren elsődleges volt) automatikusan elsődlegesvé vált a működő tárolórendszeren. A meglévő leképezést használva a LUN TEST a gazda számára elérhető maradt, a felvétel kissé visszaesett (a beígért 10 százalékon belül), de nem szakadt meg.
A teszt sikeresen befejeződött.
Összefoglalva
A metrocluster jelenlegi megvalósítása az AERODISK Engine N-sorozatú tárolórendszerekben teljes mértékben lehetővé teszi olyan problémák megoldását, ahol szükség van az IT szolgáltatások leállási idejének kiküszöbölésére vagy minimalizálására, valamint a 24/7/365 folyamatos működés biztosítására minimális munkaerőköltséggel.
Mondhatjuk persze, hogy mindez elmélet, ideális laboratóriumi körülmények, és így tovább... DE számos megvalósult projektünk van, amelyekben katasztrófa-ellenálló funkcionalitást valósítottunk meg, és a rendszerek tökéletesen működnek. Egyik meglehetősen ismert ügyfelünk, aki mindössze két tárolórendszert használ katasztrófabiztos konfigurációban, már beleegyezett a projekttel kapcsolatos információk közzétételébe, így a következő részben a harci megvalósításról lesz szó.
Köszönjük, eredményes beszélgetésre számítunk.
Forrás: will.com