Haai Habr!
Na die Nuwejaarsvakansie het ons 'n rampbestande wolk wat op twee werwe gebaseer is, weer bekendgestel. Vandag sal ons jou vertel hoe dit werk en wys wat gebeur met virtuele kliëntmasjiene wanneer individuele elemente van die groep misluk en die hele werf ineenstort (bederf – alles is in orde met hulle).
Rampbestande wolkbergingstelsel op die OST-werf.
Wat is binne
Onder die enjinkap het die groep Cisco UCS-bedieners met 'n VMware ESXi-hipervisor, twee INFINIDAT InfiniBox F2240-bergingstelsels, Cisco Nexus-netwerktoerusting, sowel as Brocade SAN-skakelaars. Die groepering is in twee werwe verdeel - OST en NORD, dit wil sê elke datasentrum het 'n identiese stel toerusting. Eintlik is dit wat dit rampbestand maak.
Binne een webwerf word die hoofelemente ook gedupliseer (gashere, SAN-skakelaars, netwerk).
Die twee terreine word verbind deur toegewyde optieseveselroetes, ook gereserveer.
'N Paar woorde oor bergingstelsels. Ons het die eerste weergawe van 'n rampbestande wolk op NetApp gebou. Hier het ons INFINIDAT gekies, en dit is hoekom:
- Aktief-aktiewe replikasie opsie. Dit laat die virtuele masjien toe om operasioneel te bly, selfs al misluk een van die bergingstelsels heeltemal. Ek sal jou later meer oor replikasie vertel.
- Drie skyfbeheerders om stelselfouttoleransie te verhoog. Gewoonlik is daar twee.
- Klaar oplossing. Ons het 'n vooraf saamgestelde rek ontvang wat net aan die netwerk gekoppel en gekonfigureer moet word.
- Oplettende tegniese ondersteuning. INFINIDAT-ingenieurs ontleed voortdurend stoorstelsellogboeke en -gebeurtenisse, installeer nuwe firmwareweergawes en help met konfigurasie.
Hier is 'n paar foto's van die uitpak:
Hoe werk dit?
Die wolk is reeds in homself foutverdraagsaam. Dit beskerm die kliënt teen enkele hardeware- en sagtewarefoute. Rampbestand sal help om teen grootskaalse mislukkings binne een webwerf te beskerm: byvoorbeeld mislukking van 'n bergingstelsel (of 'n SDS-groepering, wat redelik gereeld gebeur 🙂), massiewe foute in 'n bergingnetwerk, ens. Wel, en die belangrikste: so 'n wolk red wanneer 'n hele webwerf ontoeganklik word as gevolg van 'n brand, verduistering, raider-oorname of uitheemse landing.
In al hierdie gevalle gaan die kliënt virtuele masjiene voort om te werk, en dit is hoekom.
Die groepontwerp is so ontwerp dat enige ESXi-gasheer met virtuele kliëntmasjiene toegang tot enige van die twee bergingstelsels kan kry. As die stoorstelsel op die OST-werf misluk, sal die virtuele masjiene aanhou werk: die gashere waarop hulle loop, sal toegang tot die stoorstelsel op NORD kry vir data.
Dit is hoe die verbindingsdiagram in 'n groep lyk.
Dit is moontlik as gevolg van die feit dat 'n Inter-Switch Skakel gekonfigureer is tussen die SAN stowwe van die twee terreine: die Fabric A OST SAN skakelaar is gekoppel aan die Fabric A NORD SAN skakelaar, en soortgelyk vir die Fabric B SAN skakelaars.
Wel, sodat al hierdie ingewikkeldhede van SAN-fabrieke sin maak, word Active-Active replikasie gekonfigureer tussen die twee bergingstelsels: inligting word amper gelyktydig na die plaaslike en afgeleë bergingstelsels geskryf, RPO = 0. Dit blyk dat die oorspronklike data op een stoorstelsel gestoor word, en die replika daarvan word op die ander gestoor. Die data word gerepliseer op die vlak van bergingsvolumes, en die VM-data (sy skywe, konfigurasielêer, ruillêer, ens.) word daarop gestoor.
Die ESXi-gasheer sien die primêre volume en sy replika as een skyftoestel (stoortoestel). Daar is 24 paaie vanaf die ESXi-gasheer na elke skyftoestel:
12 paaie verbind dit met die plaaslike bergingstelsel (optimale paaie), en die oorblywende 12 met die afgeleë bergingstelsel (nie-optimale paaie). In 'n normale situasie kry ESXi toegang tot data op die plaaslike bergingstelsel deur "optimale" paaie te gebruik. Wanneer hierdie bergingstelsel misluk, verloor ESXi optimale paaie en skakel oor na "nie-optimale" paaie. Dit is hoe dit op die diagram lyk.
Skema van 'n rampvaste groepering.
Alle kliëntnetwerke is deur 'n gemeenskaplike netwerkweefsel aan beide werwe gekoppel. Elke webwerf bestuur 'n Provider Edge (PE), waarop die kliënt se netwerke beëindig word. PE's word in 'n gemeenskaplike groepering verenig. As 'n PE op een webwerf misluk, word alle verkeer na die tweede webwerf herlei. Danksy dit bly virtuele masjiene van die webwerf wat sonder PE gelaat word, toeganklik oor die netwerk vir die kliënt.
Kom ons kyk nou wat sal gebeur met virtuele kliëntmasjiene tydens verskeie mislukkings. Kom ons begin met die ligste opsies en eindig met die ernstigste - mislukking van die hele webwerf. In die voorbeelde sal die hoofplatform OST wees, en die rugsteunplatform, met data replikas, sal NORD wees.
Wat gebeur met die kliënt virtuele masjien as...
Replikasieskakel misluk. Replikasie tussen die stoorstelsels van die twee terreine stop.
ESXi sal slegs met plaaslike skyftoestelle werk (via optimale paaie).
Virtuele masjiene werk steeds.
Die ISL (Inter-Switch Link) breek. 'n Onwaarskynlike gebeurtenis. Tensy een of ander mal graafmasjien verskeie optiese roetes op een slag opgrawe, wat op onafhanklike roetes loop en deur verskillende insette na die terreine gebring word. Maar in elk geval. In hierdie geval verloor ESXi-gashere die helfte van die paaie en het hulle slegs toegang tot hul plaaslike bergingstelsels. Replikas word versamel, maar gashere sal nie toegang daartoe kan kry nie.
Virtuele masjiene werk normaalweg.
Die SAN-skakelaar misluk op een van die werwe. ESXi-gashere verloor sommige van die paaie na die bergingstelsel. In hierdie geval sal die gashere by die werf waar die skakelaar misluk het, slegs deur een van hul HBA's werk.
Die virtuele masjiene gaan voort om normaal te werk.
Alle SAN-skakelaars op een van die werwe misluk. Kom ons sê so 'n ramp het op die OST-werf gebeur. In hierdie geval sal ESXi-gashere op hierdie webwerf alle paaie na hul skyftoestelle verloor. Die standaard VMware vSphere HA-meganisme kom in die spel: dit sal alle virtuele masjiene van die OST-werf in NORD binne 'n maksimum van 140 sekondes herbegin.
Virtuele masjiene wat op NORD-werfgashere loop, werk normaalweg.
Die ESXi-gasheer misluk op een webwerf. Hier werk die vSphere HA-meganisme weer: virtuele masjiene van die mislukte gasheer word op ander gashere herbegin - op dieselfde of afgeleë webwerf. Die herbegintyd van die virtuele masjien is tot 1 minuut.
As alle ESXi-gashere op die OST-werf misluk, is daar geen opsies nie: die VM's word op 'n ander een herbegin. Herbegin tyd is dieselfde.
Die bergingstelsel faal op een plek. Kom ons sê die bergingstelsel misluk by die OST-werf. Dan skakel die ESXi-gashere van die OST-werf oor na werk met bergingsreplikas in NORD. Nadat die mislukte bergingstelsel weer in diens is, sal gedwonge replikasie plaasvind en die ESXi OST-gashere sal weer toegang tot die plaaslike bergingstelsel begin verkry.
Virtuele masjiene werk al die tyd normaal.
Een van die werwe misluk. In hierdie geval sal alle virtuele masjiene herbegin word op die rugsteunwerf deur die vSphere HA-meganisme. VM herbegin tyd is 140 sekondes. In hierdie geval sal alle netwerkinstellings van die virtuele masjien gestoor word, en dit bly toeganklik vir die kliënt oor die netwerk.
Om te verseker dat die herbegin van masjiene by die rugsteunwerf glad verloop, is elke webwerf net halfvol. Die tweede helfte is 'n reserwe ingeval alle virtuele masjiene van die tweede, beskadigde werf beweeg.
’n Rampbestande wolk wat op twee datasentrums gebaseer is, beskerm teen sulke mislukkings.
Hierdie plesier is nie goedkoop nie, aangesien, benewens die hoofbronne, 'n reservaat op die tweede terrein nodig is. Daarom word besigheidskritiese dienste in so 'n wolk geplaas, waarvan die langtermyn stilstand groot finansiële en reputasieverliese veroorsaak, of as die inligtingstelsel onderhewig is aan rampweerbaarheidsvereistes van reguleerders of interne maatskappyregulasies.
Bronne:
Bron: will.com