Tere Habr!
Pärast uusaastapühi taaskäivitasime kahe saidi põhjal katastroofikindla pilve. Täna räägime teile, kuidas see töötab, ja näitame, mis juhtub klientide virtuaalmasinatega, kui klastri üksikud elemendid ebaõnnestuvad ja kogu sait jookseb kokku (spoiler – nendega on kõik korras).
Katastroofikindel pilvesalvestussüsteem OST saidil.
Mis seal sees on
Kapoti all on klastris Cisco UCS-serverid koos VMware ESXi hüperviisoriga, kaks INFINIDAT InfiniBox F2240 salvestussüsteemi, Cisco Nexuse võrguseadmed, aga ka Brocade SAN-lülitid. Klaster on jagatud kaheks saidiks – OST ja NORD, st igal andmekeskusel on identne seadmete komplekt. Tegelikult teeb see selle katastroofikindlaks.
Ühe saidi piires dubleeritakse ka põhielemendid (hostid, SAN-lülitid, võrgundus).
Need kaks saiti on ühendatud spetsiaalsete fiiberoptiliste marsruutide kaudu, mis on samuti reserveeritud.
Paar sõna salvestussüsteemide kohta. Ehitasime NetAppis katastroofikindla pilve esimese versiooni. Siin valisime INFINIDAT ja siin on põhjus:
- Aktiivne-aktiivne replikatsioonivalik. See võimaldab virtuaalmasinal töötada ka siis, kui üks salvestussüsteemidest täielikult ebaõnnestub. Räägin teile paljundamise kohta hiljem.
- Kolm kettakontrollerit süsteemi tõrketaluvuse suurendamiseks. Tavaliselt on neid kaks.
- Valmis lahendus. Saime kokkupandud racki, mis tuleb lihtsalt võrku ühendada ja seadistada.
- Tähelepanelik tehniline tugi. INFINIDATi insenerid analüüsivad pidevalt salvestussüsteemi logisid ja sündmusi, installivad uusi püsivara versioone ja aitavad konfigureerimisel.
Siin on mõned fotod lahtipakkimisest:
Kuidas see toimib?
Pilv on juba enda sees tõrketaluv. See kaitseb klienti üksikute riist- ja tarkvaratõrgete eest. Katastroofikindel aitab kaitsta massiliste rikete eest ühes kohas: näiteks salvestussüsteemi (või SDS-klastri rike, mida juhtub üsna sageli 🙂), tohutud vead salvestusvõrgus jne. Noh, ja mis kõige tähtsam: selline pilv päästab, kui kogu sait muutub tulekahju, elektrikatkestuse, raideri ülevõtmise või tulnukate maandumise tõttu kättesaamatuks.
Kõigil neil juhtudel jätkavad kliendi virtuaalmasinad tööd ja siin on põhjus.
Klastri disain on loodud nii, et iga kliendi virtuaalmasinatega ESXi host pääseb juurde mõlemale kahest salvestussüsteemist. Kui OST saidi salvestussüsteem ebaõnnestub, jätkavad virtuaalmasinad tööd: hostid, millel need töötavad, pääsevad andmete jaoks juurde NORDi salvestussüsteemile.
Selline näeb välja ühendusskeem klastris.
See on võimalik tänu sellele, et kahe saidi SAN-kangaste vahel on konfigureeritud lülititevaheline link: Fabric A OST SAN-lüliti on ühendatud Fabric A NORD SAN-lülitiga ja samamoodi Fabric B SAN-lülitite jaoks.
Et kõik need SAN-i tehaste keerukused oleksid mõistlikud, on Active-Active replikatsioon konfigureeritud kahe salvestussüsteemi vahel: teave kirjutatakse peaaegu samaaegselt kohalikku ja kaugsalvestussüsteemi, RPO = 0. Selgub, et algandmed on salvestatud ühes salvestussüsteemis ja selle koopia teises. Andmed kopeeritakse salvestusmahtude tasemel ja VM-i andmed (selle kettad, konfiguratsioonifail, vahetusfail jne) salvestatakse neile.
ESXi host näeb esmast köidet ja selle koopiat ühe kettaseadmena (salvestusseadmena). ESXi hostist iga kettaseadmeni on 24 teed:
12 teed ühendavad selle kohaliku salvestussüsteemiga (optimaalsed teed) ja ülejäänud 12 kaugsalvestussüsteemiga (mitteoptimaalsed teed). Tavaolukorras pääseb ESXi ligi kohaliku salvestussüsteemi andmetele "optimaalseid" teid kasutades. Kui see salvestussüsteem ebaõnnestub, kaotab ESXi optimaalsed teed ja lülitub „mitteoptimaalsetele”. See näeb diagrammil välja selline.
Katastroofikindla klastri skeem.
Kõik kliendivõrgud on ühendatud mõlema saidiga ühise võrgukanga kaudu. Igal saidil töötab Provider Edge (PE), mille kaudu kliendi võrgud lõpetatakse. PE-d on ühendatud ühiseks klastriks. Kui PE ühel saidil ebaõnnestub, suunatakse kogu liiklus teisele saidile. Tänu sellele jäävad ilma PEta saidi virtuaalmasinad kliendile võrgu kaudu ligipääsetavaks.
Vaatame nüüd, mis juhtub klientide virtuaalmasinatega erinevate rikete ajal. Alustame kõige kergematest võimalustest ja lõpetame kõige tõsisema - kogu saidi ebaõnnestumisega. Näidetes on põhiplatvormiks OST ja varuplatvormiks koos andmete koopiatega NORD.
Mis juhtub kliendi virtuaalmasinaga, kui...
Replikatsioonilink ebaõnnestub. Replikatsioon kahe saidi salvestussüsteemide vahel peatub.
ESXi töötab ainult kohalike kettaseadmetega (optimaalsete teede kaudu).
Virtuaalmasinad jätkavad tööd.
ISL (Inter-Switch Link) katkeb. Ebatõenäoline sündmus. Kui just mõni hull ekskavaator ei kaeva korraga välja mitu optilist trassi, mis kulgevad iseseisvatel marsruutidel ja tuuakse objektidele erinevate sisendite kaudu. Aga igatahes. Sel juhul kaotavad ESXi hostid pooled teedest ja pääsevad juurde ainult oma kohalikele salvestussüsteemidele. Koopiad kogutakse, kuid hostid ei pääse neile juurde.
Virtuaalmasinad töötavad normaalselt.
SAN-lüliti ei tööta ühel saidil. ESXi hostid kaotavad osa salvestussüsteemi teedest. Sel juhul töötavad selle saidi hostid, kus lülitus ebaõnnestus, ainult ühe oma HBA kaudu.
Virtuaalsed masinad jätkavad normaalset tööd.
Kõik ühel saidil olevad SAN-lülitid ebaõnnestuvad. Oletame, et OST saidil juhtus selline katastroof. Sel juhul kaotavad selle saidi ESXi hostid kõik teed oma kettaseadmetesse. Mängu tuleb standardne VMware vSphere HA mehhanism: see taaskäivitab kõik OST saidi virtuaalmasinad NORDis maksimaalselt 140 sekundiga.
NORD-i saidi hostidel töötavad virtuaalmasinad töötavad normaalselt.
ESXi host ebaõnnestub ühel saidil. Siin töötab vSphere HA mehhanism uuesti: ebaõnnestunud hosti virtuaalmasinad taaskäivitatakse teistel hostidel - samal või kaugsaidil. Virtuaalse masina taaskäivitamise aeg on kuni 1 minut.
Kui kõik OST-saidil olevad ESXi hostid ebaõnnestuvad, pole valikuid: VM-id taaskäivitatakse teisel. Taaskäivitamise aeg on sama.
Salvestussüsteem ebaõnnestub ühes kohas. Oletame, et OST saidi salvestussüsteem ebaõnnestub. Seejärel lülituvad OST-saidi ESXi hostid tööle NORD-i salvestuskoopiatega. Pärast ebaõnnestunud salvestussüsteemi taaskasutamist toimub sunnitud replikatsioon ja ESXi OST-i hostid hakkavad uuesti kohalikule salvestussüsteemile juurde pääsema.
Virtuaalmasinad on kogu selle aja normaalselt töötanud.
Üks saitidest ebaõnnestub. Sel juhul taaskäivitatakse kõik virtuaalsed masinad varundussaidil vSphere HA mehhanismi kaudu. VM-i taaskäivitamise aeg on 140 sekundit. Sel juhul salvestatakse kõik virtuaalmasina võrguseaded ja see jääb kliendile võrgu kaudu juurdepääsetavaks.
Tagamaks, et varunduskoha masinate taaskäivitamine sujuks, on iga sait ainult poolenisti täis. Teine pool on reserv juhuks, kui kõik virtuaalmasinad teisest kahjustatud saidilt kolivad.
Kahel andmekeskusel põhinev katastroofikindel pilv kaitseb selliste rikete eest.
See rõõm pole odav, kuna lisaks põhiressurssidele on teisel saidil vaja reservi. Seetõttu paigutatakse sellisesse pilve ärikriitilised teenused, mille pikaajaline seisak põhjustab suuri rahalisi ja mainekahju või kui infosüsteemile kehtivad regulaatoritelt või ettevõttesisesed regulatsioonid katastroofikindluse nõuded.
Allikad:
Allikas: www.habr.com