Hei Habr!
Etter nyttårsferien relanserte vi en katastrofesikker sky basert på to nettsteder. I dag skal vi fortelle deg hvordan det fungerer og vise hva som skjer med virtuelle klientmaskiner når individuelle elementer i klyngen feiler og hele nettstedet krasjer (spoiler – alt er bra med dem).
Katastrofebestandig skylagringssystem på OST-siden.
Hva er inni
Under panseret har klyngen Cisco UCS-servere med en VMware ESXi hypervisor, to INFINIDAT InfiniBox F2240 lagringssystemer, Cisco Nexus nettverksutstyr, samt Brocade SAN-svitsjer. Klyngen er delt inn i to steder - OST og NORD, det vil si at hvert datasenter har et identisk sett med utstyr. Det er faktisk dette som gjør den katastrofebestandig.
Innenfor ett nettsted er hovedelementene også duplisert (verter, SAN-svitsjer, nettverk).
De to nettstedene er forbundet med dedikerte fiberoptiske ruter, også reservert.
Noen få ord om lagringssystemer. Vi bygde den første versjonen av en katastrofesikker sky på NetApp. Her valgte vi INFINIDAT, og her er grunnen:
- Aktiv-aktiv replikeringsalternativ. Det lar den virtuelle maskinen forbli operativ selv om et av lagringssystemene svikter fullstendig. Jeg skal fortelle deg mer om replikering senere.
- Tre diskkontrollere for å øke systemfeiltoleransen. Vanligvis er det to.
- Klar løsning. Vi fikk et forhåndsmontert stativ som bare må kobles til nettverket og konfigureres.
- Oppmerksom teknisk støtte. INFINIDAT-ingeniører analyserer kontinuerlig lagringssystemlogger og hendelser, installerer nye fastvareversjoner og hjelper til med konfigurasjonen.
Her er noen bilder fra utpakkingen:
Slik fungerer det
Skyen er allerede feiltolerant i seg selv. Den beskytter klienten mot enkelt maskinvare- og programvarefeil. Katastrofebestandig vil bidra til å beskytte mot massive feil på ett sted: for eksempel feil i et lagringssystem (eller en SDS-klynge, som skjer ganske ofte 🙂), massive feil i et lagringsnettverk, etc. Vel, og viktigst av alt: en slik sky redder når et helt nettsted blir utilgjengelig på grunn av brann, blackout, overtakelse av raider eller romvesenlanding.
I alle disse tilfellene fortsetter de virtuelle klientmaskinene å fungere, og her er grunnen.
Klyngedesignet er designet slik at enhver ESXi-vert med virtuelle klientmaskiner kan få tilgang til alle de to lagringssystemene. Hvis lagringssystemet på OST-siden svikter, vil de virtuelle maskinene fortsette å fungere: vertene de kjører på vil få tilgang til lagringssystemet på NORD for data.
Slik ser koblingsdiagrammet i en klynge ut.
Dette er mulig på grunn av det faktum at en Inter-Switch Link er konfigurert mellom SAN-strukturene til de to stedene: Fabric A OST SAN-bryteren er koblet til Fabric A NORD SAN-bryteren, og tilsvarende for Fabric B SAN-bryterne.
Vel, slik at alle disse vanskelighetene med SAN-fabrikker gir mening, er Active-Active-replikering konfigurert mellom de to lagringssystemene: informasjon skrives nesten samtidig til de lokale og eksterne lagringssystemene, RPO = 0. Det viser seg at de originale dataene er lagret på det ene lagringssystemet, og replikaen er lagret på det andre. Data blir replikert på nivå med lagringsvolumer, og VM-dataene (diskene, konfigurasjonsfilen, byttefilen osv.) lagres på dem.
ESXi-verten ser det primære volumet og dets replika som én diskenhet (lagringsenhet). Det er 24 baner fra ESXi-verten til hver diskenhet:
12 baner kobler den til det lokale lagringssystemet (optimale baner), og de resterende 12 til det eksterne lagringssystemet (ikke-optimale baner). I en normal situasjon får ESXi tilgang til data på det lokale lagringssystemet ved å bruke "optimale" baner. Når dette lagringssystemet svikter, mister ESXi optimale baner og bytter til "ikke-optimale". Slik ser det ut på diagrammet.
Opplegg for en katastrofesikker klynge.
Alle klientnettverk er koblet til begge nettstedene gjennom en felles nettverksstruktur. Hvert nettsted kjører en Provider Edge (PE), der klientens nettverk avsluttes. PE-er er samlet i en felles klynge. Hvis en PE feiler på ett sted, blir all trafikk omdirigert til det andre stedet. Takket være dette forblir virtuelle maskiner fra nettstedet uten PE tilgjengelig over nettverket for klienten.
La oss nå se hva som vil skje med virtuelle klientmaskiner under forskjellige feil. La oss starte med de letteste alternativene og avslutte med de mest alvorlige - feil på hele nettstedet. I eksemplene vil hovedplattformen være OST, og backupplattformen, med datareplikaer, vil være NORD.
Hva skjer med klientens virtuelle maskin hvis...
Replikeringskobling mislykkes. Replikering mellom lagringssystemene til de to nettstedene stopper.
ESXi vil bare fungere med lokale diskenheter (via optimale baner).
Virtuelle maskiner fortsetter å fungere.
ISL (Inter-Switch Link) bryter. En usannsynlig hendelse. Med mindre en gal gravemaskin graver opp flere optiske ruter samtidig, som kjører på uavhengige ruter og bringes til anleggene gjennom forskjellige innganger. Men uansett. I dette tilfellet mister ESXi-verter halvparten av banene og kan bare få tilgang til deres lokale lagringssystem. Replikaer samles inn, men verter vil ikke kunne få tilgang til dem.
Virtuelle maskiner fungerer normalt.
SAN-bryteren svikter på et av nettstedene. ESXi-verter mister noen av banene til lagringssystemet. I dette tilfellet vil vertene på stedet der svitsjen mislyktes, bare fungere gjennom en av deres HBA-er.
De virtuelle maskinene fortsetter å fungere normalt.
Alle SAN-brytere på et av nettstedene mislykkes. La oss si at en slik katastrofe skjedde på OST-siden. I dette tilfellet vil ESXi-verter på denne siden miste alle stier til diskenhetene sine. Standard VMware vSphere HA-mekanisme kommer inn i bildet: den vil starte alle virtuelle maskiner på OST-siden i NORD på nytt i løpet av maksimalt 140 sekunder.
Virtuelle maskiner som kjører på NORDs nettstedverter fungerer normalt.
ESXi-verten svikter på ett sted. Her fungerer vSphere HA-mekanismen igjen: virtuelle maskiner fra den mislykkede verten startes på nytt på andre verter - på samme eller eksternt nettsted. Den virtuelle maskinens omstartstid er opptil 1 minutt.
Hvis alle ESXi-verter på OST-nettstedet mislykkes, er det ingen alternativer: VM-ene startes på nytt på en annen. Omstartstiden er den samme.
Lagringssystemet svikter på ett sted. La oss si at lagringssystemet feiler på OST-stedet. Deretter bytter ESXi-vertene til OST-siden til å jobbe med lagringsreplikaer i NORD. Etter at det mislykkede lagringssystemet går tilbake til tjeneste, vil tvungen replikering skje og ESXi OST-vertene vil igjen begynne å få tilgang til det lokale lagringssystemet.
Virtuelle maskiner har fungert normalt hele denne tiden.
En av sidene mislykkes. I dette tilfellet vil alle virtuelle maskiner startes på nytt på sikkerhetskopieringsstedet gjennom vSphere HA-mekanismen. VM omstartstid er 140 sekunder. I dette tilfellet vil alle nettverksinnstillingene til den virtuelle maskinen lagres, og den forblir tilgjengelig for klienten over nettverket.
For å sikre at omstart av maskiner på sikkerhetskopieringsstedet går problemfritt, er hver side bare halvfull. Den andre halvdelen er en reserve i tilfelle alle virtuelle maskiner flytter fra den andre, skadede siden.
En katastrofebestandig sky basert på to datasentre beskytter mot slike feil.
Denne gleden er ikke billig, siden det i tillegg til hovedressursene trengs en reserve på det andre stedet. Derfor plasseres forretningskritiske tjenester i en slik sky, hvis langsiktige nedetid forårsaker store økonomiske tap og omdømmetap, eller hvis informasjonssystemet er underlagt katastrofebestandighetskrav fra regulatorer eller interne selskapsbestemmelser.
Kilder:
Kilde: www.habr.com