Sveiki, Habr!
Po Naujųjų metų atostogų iš naujo paleidome nelaimėms atsparų debesį, pagrįstą dviem svetainėmis. Šiandien mes jums pasakysime, kaip tai veikia, ir parodysime, kas nutinka klientų virtualioms mašinoms, kai sugenda atskiri klasterio elementai ir sugenda visa svetainė (spoileris – viskas su jais gerai).
Nelaimėms atspari debesų saugojimo sistema OST svetainėje.
Kas yra viduje
Po gaubtu klasteryje yra Cisco UCS serveriai su VMware ESXi hipervizoriumi, dvi INFINIDAT InfiniBox F2240 saugojimo sistemos, Cisco Nexus tinklo įranga, taip pat Brocade SAN jungikliai. Klasteris yra padalintas į dvi svetaines – OST ir NORD, t.y. kiekvienas duomenų centras turi identišką įrangos rinkinį. Tiesą sakant, dėl to jis yra atsparus nelaimėms.
Vienoje svetainėje pagrindiniai elementai taip pat dubliuojami (host'ai, SAN komutatoriai, tinklas).
Abi vietos yra sujungtos specialiais šviesolaidiniais maršrutais, taip pat rezervuotais.
Keletas žodžių apie saugojimo sistemas. „NetApp“ sukūrėme pirmąją nelaimėms atsparaus debesies versiją. Čia pasirinkome INFINIDAT ir štai kodėl:
- Aktyvus-aktyvus replikacijos variantas. Tai leidžia virtualiai mašinai ir toliau veikti, net jei viena iš saugojimo sistemų visiškai sugenda. Daugiau apie replikaciją papasakosiu vėliau.
- Trys disko valdikliai, padidinantys sistemos atsparumą gedimams. Paprastai yra du.
- Paruoštas sprendimas. Gavome iš anksto surinktą stovą, kurį tereikia prijungti prie tinklo ir sukonfigūruoti.
- Dėmesingas techninis palaikymas. INFINIDAT inžinieriai nuolat analizuoja saugojimo sistemos žurnalus ir įvykius, diegia naujas programinės įrangos versijas ir padeda konfigūruoti.
Štai keletas nuotraukų iš išpakavimo:
Kaip tai veikia
Debesis jau yra atsparus gedimams. Tai apsaugo klientą nuo atskirų aparatinės ir programinės įrangos gedimų. Atsparus nelaimėms padės apsisaugoti nuo didžiulių gedimų vienoje vietoje: pavyzdžiui, saugojimo sistemos (arba SDS klasterio, kas nutinka gana dažnai 🙂), didelių klaidų saugojimo tinkle ir pan. Na, o svarbiausia: toks debesis gelbsti, kai visa svetainė tampa nepasiekiama dėl gaisro, užtemimo, reiderio perėmimo ar ateivių nusileidimo.
Visais šiais atvejais kliento virtualios mašinos ir toliau veikia, ir štai kodėl.
Klasterio dizainas sukurtas taip, kad bet kuris ESXi pagrindinis kompiuteris su kliento virtualiomis mašinomis galėtų pasiekti bet kurią iš dviejų saugojimo sistemų. Jei OST svetainėje sugenda saugojimo sistema, virtualios mašinos veiks ir toliau: pagrindiniai kompiuteriai, kuriuose jos veikia, pasieks duomenų saugojimo sistemą NORD.
Taip atrodo sujungimo schema klasteryje.
Tai įmanoma dėl to, kad tarp dviejų svetainių SAN audinių yra sukonfigūruotas „Inter-Switch Link“: „Fabric A“ OST SAN jungiklis yra prijungtas prie „Fabric A NORD SAN“ jungiklio ir panašiai su „Fabric B“ SAN jungikliais.
Na, kad visi šie SAN gamyklų sudėtingumai būtų prasmingi, Active-Active replikacija sukonfigūruojama tarp dviejų saugojimo sistemų: informacija beveik vienu metu įrašoma į vietinę ir nuotolinę saugojimo sistemas, RPO = 0. Pasirodo, pirminiai duomenys saugomi vienoje saugojimo sistemoje, o jo kopija – kitoje. Duomenys replikuojami saugyklos apimties lygiu, o VM duomenys (jos diskai, konfigūracijos failas, apsikeitimo failas ir kt.) saugomi juose.
ESXi priegloba mato pirminį tomą ir jo kopiją kaip vieną disko įrenginį (saugyklos įrenginį). Nuo ESXi pagrindinio kompiuterio iki kiekvieno disko įrenginio yra 24 keliai:
12 kelių jungia jį prie vietinės saugojimo sistemos (optimalūs keliai), o likusieji 12 su nuotolinės saugojimo sistema (neoptimalūs keliai). Įprastoje situacijoje ESXi pasiekia duomenis vietinėje saugojimo sistemoje naudodamas „optimalius“ kelius. Kai ši saugojimo sistema sugenda, ESXi praranda optimalius kelius ir persijungia į „neoptimalius“. Taip atrodo diagramoje.
Nelaimėms atsparaus klasterio schema.
Visi klientų tinklai yra prijungti prie abiejų svetainių per bendrą tinklo audinį. Kiekvienoje svetainėje veikia Provider Edge (PE), kurioje baigiami kliento tinklai. PE yra sujungti į bendrą klasterį. Jei PE nepavyksta vienoje svetainėje, visas srautas nukreipiamas į antrąją svetainę. Dėl šios priežasties virtualios mašinos iš svetainės, likusios be PE, klientui lieka pasiekiamos tinkle.
Dabar pažiūrėkime, kas nutiks klientų virtualioms mašinoms įvairių gedimų metu. Pradėkime nuo lengviausių variantų ir baigkime rimčiausiu – visos svetainės gedimu. Pavyzdžiuose pagrindinė platforma bus OST, o atsarginė platforma su duomenų kopijomis bus NORD.
Kas atsitiks su kliento virtualia mašina, jei...
Replikacijos nuoroda nepavyksta. Replikacija tarp dviejų svetainių saugojimo sistemų sustoja.
ESXi veiks tik su vietiniais diskais (optimaliais keliais).
Virtualios mašinos veikia toliau.
ISL (Inter-Switch Link) nutrūksta. Atvejis mažai tikėtinas. Nebent koks išprotėjęs ekskavatorius išraustų kelis optinius maršrutus vienu metu, kurie eina nepriklausomais maršrutais ir atvežami į aikšteles per skirtingus įėjimus. Bet, vis dėlto. Tokiu atveju ESXi kompiuteriai praranda pusę kelių ir gali pasiekti tik savo vietines saugojimo sistemas. Kopijos renkamos, tačiau prieglobos serveriai negalės jų pasiekti.
Virtualios mašinos veikia normaliai.
SAN jungiklis sugenda vienoje iš svetainių. ESXi kompiuteriai praranda kai kuriuos kelius į saugojimo sistemą. Tokiu atveju priegloba svetainėje, kurioje nepavyko perjungti, veiks tik per vieną iš savo HBA.
Virtualios mašinos ir toliau veikia įprastai.
Visi SAN jungikliai vienoje iš svetainių sugenda. Tarkime, tokia nelaimė įvyko OST svetainėje. Tokiu atveju ESXi prieglobos šioje svetainėje praras visus kelius į savo disko įrenginius. Įsijungia standartinis VMware vSphere HA mechanizmas: jis iš naujo paleis visas OST svetainės virtualias mašinas NORD ne ilgiau kaip per 140 sekundžių.
Virtualios mašinos, veikiančios NORD svetainės pagrindiniuose kompiuteriuose, veikia normaliai.
ESXi priegloba sugenda vienoje svetainėje. Čia vSphere HA mechanizmas vėl veikia: virtualios mašinos iš sugedusio pagrindinio kompiuterio paleidžiamos iš naujo kituose pagrindiniuose kompiuteriuose – toje pačioje arba nuotolinėje svetainėje. Virtualios mašinos paleidimo iš naujo laikas yra iki 1 minutės.
Jei visi ESXi prieglobos OST svetainėje sugenda, nėra parinkčių: VM paleidžiamos iš naujo kitoje. Paleisties iš naujo laikas yra tas pats.
Saugojimo sistema sugenda vienoje vietoje. Tarkime, OST svetainėje sugenda saugojimo sistema. Tada OST svetainės ESXi prieglobos pereina prie darbo su saugyklos kopijomis NORD. Sugedusiai saugyklos sistemai vėl pradėjus veikti, įvyks priverstinis replikavimas ir ESXi OST prieglobos vėl pradės pasiekti vietinę saugojimo sistemą.
Virtualios mašinos visą tą laiką veikė normaliai.
Viena iš svetainių neveikia. Tokiu atveju visos virtualios mašinos bus iš naujo paleistos atsarginėje svetainėje naudojant vSphere HA mechanizmą. VM paleidimo iš naujo laikas yra 140 sekundžių. Tokiu atveju visi virtualiosios mašinos tinklo nustatymai bus išsaugoti ir klientui bus pasiekiami tinkle.
Siekiant užtikrinti, kad atsarginės kopijos vietos įrenginiai iš naujo paleidžiami sklandžiai, kiekviena svetainė yra užpildyta tik iki pusės. Antroji pusė yra rezervas, jei visos virtualios mašinos pajudėtų iš antrosios, pažeistos svetainės.
Nuo tokių gedimų apsaugo nelaimėms atsparus debesis, pagrįstas dviem duomenų centrais.
Šis malonumas nėra pigus, nes, be pagrindinių išteklių, antroje vietoje reikia rezervo. Todėl verslui svarbios paslaugos talpinamos į tokį debesį, dėl kurio ilgalaikės prastovos patiriami dideli finansiniai ir reputaciniai nuostoliai arba jeigu informacinei sistemai taikomi atsparumo nelaimėms reikalavimai iš reguliuotojų ar vidinių įmonės nuostatų.
Šaltiniai:
Šaltinis: www.habr.com