Pozdravljeni, Habr!
Po novoletnih praznikih smo ponovno zagnali disaster-proof oblak, ki temelji na dveh straneh. Danes vam bomo povedali, kako deluje, in pokazali, kaj se zgodi z odjemalskimi virtualnimi stroji, ko posamezni elementi gruče odpovejo in se celotno spletno mesto zruši (spojler – z njimi je vse v redu).
Sistem za shranjevanje v oblaku, odporen proti katastrofam, na spletnem mestu OST.
Kaj je notri
Pod pokrovom ima gruča strežnike Cisco UCS s hipervizorjem VMware ESXi, dva sistema za shranjevanje INFINIDAT InfiniBox F2240, omrežno opremo Cisco Nexus in stikala Brocade SAN. Grozd je razdeljen na dve lokaciji - OST in NORD, kar pomeni, da ima vsak podatkovni center enak nabor opreme. Pravzaprav je zaradi tega odporen na nesreče.
Znotraj ene strani se podvajajo tudi glavni elementi (gostitelji, SAN stikala, mreženje).
Obe lokaciji sta povezani z namenskimi optičnimi vlakni, ki so tudi rezervirane.
Nekaj besed o sistemih za shranjevanje. Na NetApp smo zgradili prvo različico oblaka, odpornega na nesreče. Tukaj smo izbrali INFINIDAT in tukaj je razlog:
- Možnost Active-Active podvajanja. Omogoča, da virtualni stroj ostane operativen, tudi če eden od sistemov za shranjevanje popolnoma odpove. Več o replikaciji vam bom povedal kasneje.
- Trije krmilniki diskov za večjo toleranco sistemskih napak. Ponavadi sta dva.
- Pripravljena rešitev. Prejeli smo že sestavljeno stojalo, ki ga je treba le priklopiti v omrežje in konfigurirati.
- Pozorna tehnična podpora. INFINIDAT inženirji nenehno analizirajo dnevnike in dogodke sistema za shranjevanje, nameščajo nove različice vdelane programske opreme in pomagajo pri konfiguraciji.
Tukaj je nekaj fotografij iz razpakiranja:
Kako deluje?
Oblak je že sam po sebi odporen na napake. Odjemalca ščiti pred posameznimi okvarami strojne in programske opreme. Odpornost proti katastrofam bo pomagala zaščititi pred množičnimi okvarami na enem mestu: na primer okvara sistema za shranjevanje (ali gruče SDS, kar se zgodi precej pogosto 🙂), množične napake v omrežju za shranjevanje itd. No, in kar je najpomembnejše: takšen oblak rešuje, ko celotna stran postane nedostopna zaradi požara, izpada električne energije, napadalskega prevzema ali pristanka nezemljanov.
V vseh teh primerih odjemalski virtualni stroji še naprej delujejo in tukaj je razlog.
Zasnova gruče je zasnovana tako, da lahko vsak gostitelj ESXi z odjemalskimi virtualnimi stroji dostopa do katerega koli od dveh sistemov za shranjevanje. Če sistem za shranjevanje na mestu OST odpove, bodo virtualni stroji še naprej delovali: gostitelji, na katerih se izvajajo, bodo dostopali do sistema za shranjevanje na NORD za podatke.
Tako izgleda povezovalni diagram v gruči.
To je mogoče zaradi dejstva, da je povezava Inter-Switch konfigurirana med spleti SAN obeh mest: stikalo Fabric A OST SAN je povezano s stikalom Fabric A NORD SAN in podobno za stikala Fabric B SAN.
No, da bi bile vse te zapletenosti tovarn SAN smiselne, je replikacija Active-Active konfigurirana med obema sistemoma za shranjevanje: informacije se skoraj istočasno zapišejo v lokalne in oddaljene sisteme za shranjevanje, RPO = 0. Izkazalo se je, da so izvirni podatki shranjeni na enem sistemu za shranjevanje, njegova replika pa na drugem. Podatki se replicirajo na ravni pomnilniških količin, na njih pa so shranjeni podatki VM (njegovi diski, konfiguracijska datoteka, izmenjalna datoteka itd.).
Gostitelj ESXi vidi primarni nosilec in njegovo repliko kot eno diskovno napravo (shranjevalna naprava). Obstaja 24 poti od gostitelja ESXi do vsake diskovne naprave:
12 poti ga povezuje z lokalnim sistemom za shranjevanje (optimalne poti), preostalih 12 pa z oddaljenim sistemom za shranjevanje (neoptimalne poti). V normalnih razmerah ESXi dostopa do podatkov v lokalnem pomnilniškem sistemu po »optimalnih« poteh. Ko ta sistem za shranjevanje odpove, ESXi izgubi optimalne poti in preklopi na »neoptimalne«. Tako je videti na diagramu.
Shema grozda, odpornega na nesreče.
Vsa omrežja odjemalcev so povezana z obema mestoma prek skupne omrežne strukture. Vsako spletno mesto izvaja ponudnikov rob (PE), na katerem so zaključena omrežja odjemalca. PE so združeni v skupni grozd. Če PE odpove na enem mestu, se ves promet preusmeri na drugo mesto. Zahvaljujoč temu virtualni stroji s spletnega mesta, ki ostane brez PE, ostanejo odjemalcu dostopni prek omrežja.
Poglejmo zdaj, kaj se bo zgodilo z odjemalskimi virtualnimi stroji med različnimi okvarami. Začnimo z najlažjimi možnostmi in končajmo z najresnejšimi - odpovedjo celotnega mesta. V primerih bo glavna platforma OST, rezervna platforma z replikami podatkov pa NORD.
Kaj se zgodi z virtualnim strojem odjemalca, če...
Replikacijska povezava ne uspe. Podvajanje med sistemi za shranjevanje obeh mest se ustavi.
ESXi bo deloval samo z lokalnimi diskovnimi napravami (prek optimalnih poti).
Virtualni stroji še naprej delujejo.
ISL (Inter-Switch Link) se prekine. Malo verjeten dogodek. Razen, če kakšen nor bager ne razkoplje več optičnih poti naenkrat, ki potekajo po neodvisnih trasah in se na najdišča pripeljejo preko različnih vhodov. Ampak vseeno. V tem primeru gostitelji ESXi izgubijo polovico poti in lahko dostopajo le do svojih lokalnih sistemov za shranjevanje. Replike so zbrane, vendar gostitelji ne bodo mogli dostopati do njih.
Virtualni stroji delujejo normalno.
Stikalo SAN odpove na enem od mest. Gostitelji ESXi izgubijo nekaj poti do sistema za shranjevanje. V tem primeru bodo gostitelji na mestu, kjer stikalo ni uspelo, delovali samo prek enega od svojih HBA.
Virtualni stroji še naprej normalno delujejo.
Vsa stikala SAN na enem od mest ne uspejo. Recimo, da se je takšna katastrofa zgodila na mestu OST. V tem primeru bodo gostitelji ESXi na tem mestu izgubili vse poti do svojih diskovnih naprav. V poštev pride standardni mehanizem VMware vSphere HA: znova zažene vse virtualne stroje mesta OST v NORD v največ 140 sekundah.
Virtualni stroji, ki se izvajajo na gostiteljih spletnih mest NORD, delujejo normalno.
Gostitelj ESXi ne uspe na enem mestu. Tukaj mehanizem vSphere HA ponovno deluje: navidezni stroji iz okvarjenega gostitelja se znova zaženejo na drugih gostiteljih – na istem ali oddaljenem mestu. Čas ponovnega zagona virtualnega stroja je do 1 minute.
Če vsi gostitelji ESXi na spletnem mestu OST odpovejo, ni nobenih možnosti: VM se znova zaženejo na drugem. Čas ponovnega zagona je enak.
Sistem za shranjevanje odpove na enem mestu. Recimo, da sistem za shranjevanje odpove na mestu OST. Nato gostitelji ESXi mesta OST preklopijo na delo z replikami pomnilnika v NORD. Ko se okvarjeni sistem za shranjevanje vrne v delovanje, bo prišlo do prisilne replikacije in gostitelji OST ESXi bodo znova začeli dostopati do lokalnega sistema za shranjevanje.
Virtualni stroji ves ta čas delujejo normalno.
Ena od strani ne uspe. V tem primeru se bodo vsi virtualni stroji znova zagnali na mestu za varnostno kopiranje prek mehanizma vSphere HA. Čas ponovnega zagona VM je 140 sekund. V tem primeru se vse omrežne nastavitve navideznega stroja shranijo in odjemalcu ostane dostopen prek omrežja.
Da bi zagotovili nemoten ponovni zagon strojev na rezervnem mestu, je vsako mesto samo napol polno. Druga polovica je rezerva, če se vsi virtualni stroji preselijo z drugega, poškodovanega mesta.
Oblak, odporen na katastrofe, ki temelji na dveh podatkovnih centrih, ščiti pred takšnimi okvarami.
Ta užitek ni poceni, saj je poleg glavnih virov potrebna rezerva na drugem mestu. Zato so v takšen oblak postavljene poslovno kritične storitve, katerih dolgotrajni izpadi povzročajo velike finančne izgube in izgubo ugleda ali če za informacijski sistem veljajo zahteve regulatorjev ali notranjih predpisov podjetja glede odpornosti na nesreče.
Vir:
Vir: www.habr.com