Tere, Habr!
Pärast uut aastat käivitasime katastroofikindla pilve kahes asukohas. Täna räägime, kuidas see korraldatud on, ja näitame, mis juhtub kliendi virtuaalmasinate kanssa, kui klastris eraldi elemendid nurjuvad ja terve asukoht kokku kukub (spoiler – nendega on kõik hästi).
Katastroofikindla pilve salvestusseade OST platvormil.
Mis on sees
Kluster koosneb Cisco UCS serveritest, VMware ESXi hüperviisorist, kahest INFINIDAT InfiniBox F2240 salvestusseadmest, Cisco Nexus võrguseadmest ning Brocade SAN-lülititest. Kluster on jagatud kahe asukoha – OST ja NORD – vahel, st igas andmekeskuses on identne seadmete komplekt. Just see mitmekesisus teebki sellest katastroofikindla süsteemi.
Ühe asukoha sees on põhielemendid samuti dubleeritud (hostid, SAN-lülitid, võrgud).
Kaks asukohta on ühendatud eraldatud kiudoptiliste radadega, mis on samuti reserveeritud.
Natuke infot salvestusseadmest. Esimene katastroofikindla pilve variant ehitati NetAppil. Siin valisime INFINIDATi ja siit ka põhjus:
- Active-Active replikatsiooni võimalus. See võimaldab virtuaalsel masinal jääda tööolekusse isegi siis, kui üks salvestusseade täielikult ebaõnnestub. Räägin replikatsioonist lähemalt hiljem.
- Kolm ketta kontrollerit süsteemi töökindluse suurendamiseks. Tavaliselt on neid kaks.
- Valmis lahendus. Meile toodi juba kokku pandud rack, mis tuleb lihtsalt võrku ühendada ja seadistada.
- Hoolikas tehniline tugi. INFINIDATi insenerid analüüsivad pidevalt logisid ja salvestusseadmest tulenevaid sündmusi, paigaldavad uut tarkvara ning aitavad seadistamisel.
Siin on mõned pildid unpacking'ust:
Kuidas see töötab
Pilv on juba enda sees katastroofikindel. See kaitseb klienti üksikute riist- ja tarkvara tõrgete eest. Katastroofikindel lahendus aitab kaitsta massiliste tõrgete eest ühe asukoha piires: näiteks salvestusseadmest (või SDS klastrist, mis ei ole haruldane 🙂), massilised vead salvestusvõrgus ja muu sarnane. Ning kõige tähtsam: selline pilv päästab, kui terve asukoht muutub kättesaamatuks tulekahju, elektrikatkestuse, röövimise või välismaalaste sissetungi tõttu.
Kõigil neil juhtudel jätkavad kliendi virtuaalsed masinad töötamist, ja siin on põhjus.
Klastri skeem on korraldatud nii, et igasugune ESXi host, millel on kliendi virtuaalsed masinad, saab pöörduda ühe kahe salvestusseadmest. Kui OST platvormil asuv salvestusseade ebaõnnestub, jätkavad virtuaalsed masinad töötamist: hostid, millel nad töötavad, pöörduvad andmete saamiseks NORDi salvestusseadmest.
Nii näeb välja klastris ühenduse skeem.
See on võimalik tänu sellele, et kahe asukoha SAN-id seotakse Inter-Switch Linkiga: SAN-lüliti Fabric A OST on ühendatud SAN-lülitiga Fabric A NORD, sama kehtib ka Fabric B SAN-lülitite kohta.
Kuna need keerulised SAN-ide struktuurid omavad mõtet, on kahe salvestusseadmest seadistatud Active-Active replikatsioon: teave kirjutatakse peaaegu samaaegselt kohaliku ja kaugel asuva salvestusseadmest, RPO=0. Tulemuseks on see, et ühes salvestusseadmest hoitakse andmete originaali, teises – nende koopiat. Andmeid replitakse salvestusseadmest koostisosade tasandil, ja nende peal hoitakse VM andmeid (oma kettad, konfiguratsioonifail, vahetusfail jne).
ESXi-host näeb peamist mahtu ja selle koopiat üheks kettaseadmeks (Storage Device). Iga kettaseadmest on ESXi-hostilt 24 teed:
12 teed ühendavad selle kohaliku salvestusseadmest (optimaalsed teed), ja ülejäänud 12 – kaugele (mitte optimaalsed teed). Tavaolukorras pöördub ESXi andmete poole kohaliku salvestusseadmest, kasutades "optimaalseid" teid. Kui see salvestusseade ebaõnnestub, kaotab ESXi optimaalsed teed ja lülitub "mitteoptimaalsetele". Nii näeb see skeemist välja.
Katastroofikindla klastri skeem.
Kõik kliendi võrgud on ühendatud kahe asukoha kaudu ühise võrgufabriku kaudu. Igas asukohas töötab Provider Edge (PE), kus kliendi võrgud lõpetatakse. PE-d on ühendatud ühiseks klastriks. Kui ühes asukohas PE ebaõnnestub, suunatakse kogu liiklus teisele asukohale. Selle tulemusena jäävad virtuaalsed masinad asukohast, kus PE-d pole, kliendi jaoks võrgu kaudu kättesaadavaks.
Vaadakem nüüd, mis juhtub kliendi virtuaalmasinatega erinevate tõrgete korral. Alustame kõige kergematest variantidest ja lõpetame kõige tõsisema – kogu asukoha tõrke. Näidetes on põhi asukoha nimi OST ja varukoht, kus on andmete koopiad, NORD.
Mis juhtub kliendi virtuaalmasinaga, kui…
Ebaõnnestub Replikatsiooni Link. Replikatsioon kahe asukoha salvestusseadmest katkeb.
ESXi töötavad ainult kohalike ketta seadmetega (optimaalsetel teedel).
Virtuaalsed masinad jätkavad töötamist.
Toimub ISL (Inter-Switch Link) katkestamine. Tegujuv juhtum. Ainult juhul, kui mõni raevukalt kaevur sõidab üle mitme optilise trassi, mis kulgevad sõltumatute marsruutide kaudu ja on ühendatud eri sisendite kaudu. Kuid siiski. Sellisel juhul kaotavad ESXi hostid poole marsruutidest ja saavad ühendust ainult oma kohalike andmesalvestusseade. Kopeerimised luuakse, kuid hostid ei saa neile juurde pääseda.
Virtuaalmasinad töötavad normaalselt.
SAN-lüliti ebaõnnestub ühel platvormil. ESXi hostid kaotavad osa ühendustest andmesalvestusseadmega. Sellisel juhul töötavad platvormi hostid, kus lüliti ebaõnnestus, ainult ühe oma HBA kaudu.
Virtuaalmasinad töötavad siiski normaalselt.
Kõik SAN-lülitid ebaõnnestuvad ühel platvormil. Oletame, et selline probleem juhtus OST platvormil. Sellisel juhul kaotavad selle platvormi ESXi hostid kõik ühendused oma kõvakettaseadmetega. Tööle astub standardne VMware vSphere HA mehhanism: ta taaskäivitab kõik virtuaalmasinad OST platvormil maksimaalselt 140 sekundi pärast NORD-is.
Platvormi NORD hostides töötavad virtuaalmasinad normaalselt.
ESXi host ebaõnnestub ühel platvormil. Siin katkestab taas vSphere HA mehhanism: rikke saanud hosti virtuaalmasinad taaskäivituvad teistel hostidel – kas samal või kaugemal platvormil. Virtuaalmasina taaskäivitamise aeg – kuni 1 minut.
Kui kõik OST platvormi ESXi hostid ebaõnnestuvad, siis siin ei ole valikuid: virtuaalmasinad taaskäivituvad teisel platvormil. Taaskäivitamise aeg on sama.
Andmesalvestusseade ebaõnnestub ühel platvormil. Oletame, et andmesalvestusseade ebaõnnestus OST platvormil. Siis lülituvad OST platvormi ESXi hostid üle replikatsioonide kasutamisele NORD-is. Pärast rikke saanud andmesalvestusseadmest taastumist toimub sundreplikatsioon, OST hostid hakkavad taas kasutama oma kohalikke andmesalvestusseadmeid.
Virtuaalmasinad töötavad kogu selle aja normaalsetes tingimustes.
Üks platvorm ebaõnnestub. Sellisel juhul taaskäivituvad kõik virtuaalmasinad varuplaanile, kasutades vSphere HA mehhanismi. Virtuaalmasina taaskäivitamise aeg on 140 sekundit. Samal ajal hoitakse kõik virtuaalmasina võrgu seaded ja see jääb klientide jaoks võrku kergesti kättesaadavaks.
Et masinate taaskäivitamine varuplaanil kulgeks probleemideta, on iga platvorm jagatud ainult pooleks. Teine pool on reserveeritud kõigi virtuaalmasinate üleviimise juhtumi jaoks teiselt, kahjustatud platvormilt.
Katastroofide eest kaitseb selline pilv, mis põhineb kahel andmekeskusel.
See naljakas ei ole odav, kuna lisaks peamistele ressurssidele on vajalik ka reserve teisel platvormil. Seetõttu paigutatakse sellisesse pilve äri jaoks kriitilised teenused, mille pikaajaline seiskumine toob kaasa suuri rahalisi ja mainekaotusi, või kui teabe süsteemile esitatakse katastroofitunnelduse nõuded reguleerijatelt või ettevõtte siseeeskirjadelt.
Allikad:
Allikas: habr.com
