Szia Habr!
Az újévi ünnepek után két helyszínre alapozva indítottuk újra a katasztrófabiztos felhőt. Ma elmondjuk, hogyan működik, és megmutatjuk, mi történik az ügyfelek virtuális gépeivel, ha a fürt egyes elemei meghibásodnak, és az egész webhely összeomlik (spoiler – minden rendben van velük).
Katasztrófaálló felhőtároló rendszer az OST oldalon.
Mi van benne?
A fürtben a burkolat alatt Cisco UCS szerverek találhatók VMware ESXi hypervisorral, két INFINIDAT InfiniBox F2240 tárolórendszer, Cisco Nexus hálózati berendezések, valamint Brocade SAN switchek. A fürt két telephelyre oszlik - OST és NORD, azaz minden adatközpont azonos berendezéssel rendelkezik. Valójában ez teszi katasztrófabiztossá.
Egy oldalon belül a fő elemek is megkettőződnek (hostok, SAN-kapcsolók, hálózat).
A két helyszínt dedikált optikai szálak kötik össze, szintén fenntartva.
Néhány szó a tárolórendszerekről. Megépítettük a katasztrófabiztos felhő első verzióját a NetApp-on. Itt az INFINIDAT-ot választottuk, és ez az oka:
- Aktív-aktív replikációs lehetőség. Lehetővé teszi, hogy a virtuális gép akkor is működőképes maradjon, ha az egyik tárolórendszer teljesen meghibásodik. A replikációról később fogok többet mondani.
- Három lemezvezérlő a rendszer hibatűrésének növelése érdekében. Általában kettő van.
- Kész megoldás. Kaptunk egy előre összeszerelt racket, amit csak csatlakoztatni kell a hálózathoz és be kell állítani.
- Figyelmes technikai támogatás. Az INFINIDAT mérnökei folyamatosan elemzik a tárolórendszer naplóit és eseményeit, új firmware-verziókat telepítenek, és segítenek a konfigurációban.
Íme néhány kép a kicsomagolásról:
Hogyan működik
A felhő már önmagában is hibatűrő. Megvédi a klienst az egyes hardver- és szoftverhibáktól. A katasztrófaálló segít megvédeni a hatalmas hibákat egy helyen: például egy tárolórendszer (vagy egy SDS-fürt meghibásodása, ami elég gyakran előfordul 🙂), hatalmas hibák a tárolóhálózatban stb. Nos, és ami a legfontosabb: egy ilyen felhő akkor ment meg, ha egy egész oldal elérhetetlenné válik tűz, áramszünet, portyázó hatalomátvétel vagy idegen landolás miatt.
Ezekben az esetekben az ügyfél virtuális gépei továbbra is működnek, és itt van az ok.
A fürt kialakítása úgy van megtervezve, hogy bármely ESXi-gazdagép ügyfél virtuális gépekkel hozzáférhessen a két tárolórendszer bármelyikéhez. Ha az OST webhelyen lévő tárolórendszer meghibásodik, a virtuális gépek továbbra is működnek: azok a gazdagépek, amelyeken futnak, hozzáférnek a NORD tárolórendszeréhez adatokért.
Így néz ki a kapcsolódási diagram egy fürtben.
Ez annak köszönhető, hogy a két hely SAN szövetei között egy Inter-Switch Link van konfigurálva: a Fabric A OST SAN kapcsoló a Fabric A NORD SAN kapcsolóhoz csatlakozik, és hasonlóan a Fabric B SAN kapcsolókhoz.
Nos, hogy a SAN-gyárak mindezen bonyolultságai értelmet kapjanak, az Active-Active replikáció a két tárolórendszer között van konfigurálva: az információk szinte egyszerre íródnak a helyi és a távoli tárolórendszerbe, RPO = 0. Kiderült, hogy az eredeti adatok az egyik tárolórendszeren, a másolata pedig a másikon. Az adatok replikálása a tárolókötetek szintjén történik, és a virtuális gép adatai (lemezei, konfigurációs fájlja, cserefájlja stb.) ezeken tárolódnak.
Az ESXi gazdagép az elsődleges kötetet és annak replikáját egyetlen lemezeszközként (tárolóeszközként) tekinti. 24 útvonal van az ESXi gazdagéptől minden lemezeszközhöz:
12 útvonal köti össze a helyi tárolórendszerrel (optimális útvonalak), a maradék 12 pedig a távoli tárolórendszerrel (nem optimális elérési utak). Normál helyzetben az ESXi „optimális” útvonalakon éri el a helyi tárolórendszer adatait. Ha ez a tárolórendszer meghibásodik, az ESXi elveszíti az optimális útvonalakat, és „nem optimális” útvonalakra vált. Így néz ki a diagramon.
A katasztrófabiztos klaszter sémája.
Minden klienshálózat közös hálózati hálón keresztül kapcsolódik mindkét telephelyhez. Minden oldalon fut egy Provider Edge (PE), amelyen az ügyfél hálózatai le vannak zárva. A PE-k egy közös klaszterbe egyesülnek. Ha egy PE meghibásodik az egyik oldalon, akkor az összes forgalom a második webhelyre kerül átirányításra. Ennek köszönhetően a PE nélkül maradt webhely virtuális gépei a hálózaton keresztül elérhetőek maradnak a kliens számára.
Lássuk most, mi lesz a kliens virtuális gépekkel a különféle hibák során. Kezdjük a legkönnyebb lehetőségekkel, és fejezzük be a legsúlyosabb - az egész webhely kudarcával. A példákban a fő platform az OST, a biztonsági mentési platform pedig az adatreplikákkal a NORD lesz.
Mi történik az ügyfél virtuális gépével, ha...
A replikációs hivatkozás sikertelen. A két hely tárolórendszerei közötti replikáció leáll.
Az ESXi csak helyi lemezeszközökkel működik (optimális útvonalakon).
A virtuális gépek továbbra is működnek.
Az ISL (Inter-Switch Link) megszakad. Az eset nem valószínű. Hacsak valami őrült kotrógép nem ás ki egyszerre több optikai útvonalat, amelyek független útvonalakon futnak, és különböző bemeneteken keresztül jutnak el a helyszínekre. De egyébként is. Ebben az esetben az ESXi gazdagépek elveszítik az útvonalak felét, és csak a helyi tárolórendszereikhez férhetnek hozzá. A replikákat gyűjtik, de a gazdagépek nem férhetnek hozzájuk.
A virtuális gépek normálisan működnek.
A SAN-kapcsoló meghibásodik az egyik oldalon. Az ESXi gazdagépek elveszítik a tárolórendszerhez vezető útvonalak egy részét. Ebben az esetben azon a helyen lévő gazdagépek, ahol a váltás meghiúsult, csak az egyik HBA-n keresztül fognak működni.
A virtuális gépek továbbra is a megszokott módon működnek.
Az egyik oldalon az összes SAN-kapcsoló meghibásodik. Tegyük fel, hogy az OST oldalán történt egy ilyen katasztrófa. Ebben az esetben az ezen a webhelyen található ESXi gazdagépek elveszítik a lemezeszközeikhez vezető összes útvonalat. A szabványos VMware vSphere HA mechanizmus lép működésbe: maximum 140 másodpercen belül újraindítja az OST webhely összes virtuális gépét a NORD-ban.
A NORD telephelyein futó virtuális gépek normálisan működnek.
Az ESXi gazdagép meghibásodik az egyik oldalon. Itt a vSphere HA mechanizmus újra működik: a meghibásodott gazdagép virtuális gépei újraindulnak más gazdagépeken - ugyanazon vagy távoli helyen. A virtuális gép újraindítási ideje legfeljebb 1 perc.
Ha az OST webhelyen lévő összes ESXi-állomás meghibásodik, akkor nincs lehetőség: a virtuális gépek újraindulnak egy másikon. Az újraindítási idő ugyanaz.
A tárolórendszer egy helyen meghibásodik. Tegyük fel, hogy a tárolórendszer meghibásodik az OST webhelyen. Ezután az OST webhely ESXi gazdagépei átváltanak a NORD-ban lévő tárolóreplikákkal való együttműködésre. Miután a meghibásodott tárolórendszer újra üzembe áll, kényszerreplikáció következik be, és az ESXi OST gazdagépei ismét hozzáférnek a helyi tárolórendszerhez.
A virtuális gépek mindeddig normálisan működtek.
Az egyik webhely nem működik. Ebben az esetben az összes virtuális gép újraindul a biztonsági mentés helyén a vSphere HA mechanizmuson keresztül. A virtuális gép újraindítási ideje 140 másodperc. Ebben az esetben a virtuális gép összes hálózati beállítása elmentésre kerül, és az ügyfél számára elérhető marad a hálózaton keresztül.
Annak érdekében, hogy a biztonsági mentés helyén lévő gépek újraindítása zökkenőmentesen menjen, minden oldal csak félig van tele. A második fele tartalék arra az esetre, ha az összes virtuális gép elköltözne a második, sérült helyről.
A két adatközponton alapuló katasztrófaálló felhő véd az ilyen hibák ellen.
Ez az öröm nem olcsó, mivel a fő források mellett tartalékra van szükség a második oldalon. Ezért olyan felhőbe helyezik az üzlet szempontjából kritikus szolgáltatásokat, amelyek hosszú távú leállása nagy anyagi és hírnévveszteséget okoz, vagy ha az információs rendszerre a szabályozói vagy belső vállalati szabályzatok katasztrófa-tűrőképességi követelményei vonatkoznak.
Forrás:
Forrás: will.com