Hej Habr!
Efter nytårsferien relancerede vi en katastrofesikker sky baseret på to websteder. I dag vil vi fortælle dig, hvordan det fungerer, og vise, hvad der sker med virtuelle klientmaskiner, når individuelle elementer i klyngen fejler, og hele webstedet går ned (spoiler - alt er fint med dem).
Katastrofebestandigt skylagersystem på OST-webstedet.
Hvad er inde
Under hætten har klyngen Cisco UCS-servere med en VMware ESXi-hypervisor, to INFINIDAT InfiniBox F2240-lagringssystemer, Cisco Nexus-netværksudstyr samt Brocade SAN-switche. Klyngen er opdelt i to steder - OST og NORD, det vil sige, at hvert datacenter har et identisk sæt udstyr. Det er faktisk det, der gør den katastrofesikker.
Inden for ét websted er hovedelementerne også duplikeret (værter, SAN-switche, netværk).
De to steder er forbundet med dedikerede fiberoptiske ruter, også reserveret.
Et par ord om lagersystemer. Vi byggede den første version af en katastrofesikker sky på NetApp. Her valgte vi INFINIDAT, og her er hvorfor:
- Aktiv-aktiv replikeringsmulighed. Det gør det muligt for den virtuelle maskine at forblive operationel, selvom et af lagersystemerne fejler fuldstændigt. Jeg fortæller dig mere om replikering senere.
- Tre diskcontrollere for at øge systemets fejltolerance. Normalt er der to.
- Klar løsning. Vi modtog et færdigmonteret rack, der blot skal tilsluttes netværket og konfigureres.
- Opmærksom teknisk support. INFINIDAT-ingeniører analyserer konstant lagersystemlogfiler og hændelser, installerer nye firmwareversioner og hjælper med konfigurationen.
Her er nogle billeder fra udpakningen:
Sådan virker det
Skyen er allerede fejltolerant i sig selv. Det beskytter klienten mod enkelt hardware- og softwarefejl. Katastrofebestandig vil hjælpe med at beskytte mod massive fejl inden for ét websted: for eksempel fejl i et lagersystem (eller en SDS-klynge, hvilket sker ret ofte 🙂), massive fejl i et lagernetværk osv. Nå, og vigtigst af alt: sådan en sky redder, når et helt websted bliver utilgængeligt på grund af en brand, blackout, raider-overtagelse eller rumvæsenlanding.
I alle disse tilfælde fortsætter klientens virtuelle maskiner med at arbejde, og her er hvorfor.
Klyngedesignet er designet således, at enhver ESXi-vært med virtuelle klientmaskiner kan få adgang til et hvilket som helst af de to lagersystemer. Hvis lagersystemet på OST-stedet svigter, vil de virtuelle maskiner fortsætte med at arbejde: de værter, som de kører på, vil få adgang til lagersystemet på NORD for data.
Sådan ser forbindelsesdiagrammet i en klynge ud.
Dette er muligt på grund af det faktum, at en Inter-Switch Link er konfigureret mellem SAN-strukturerne på de to steder: Fabric A OST SAN-switchen er forbundet til Fabric A NORD SAN-switchen, og tilsvarende for Fabric B SAN-switcherne.
Nå, så alle disse forviklinger af SAN-fabrikker giver mening, er Active-Active-replikering konfigureret mellem de to lagersystemer: information skrives næsten samtidigt til de lokale og eksterne lagersystemer, RPO = 0. Det viser sig, at de originale data er gemt på det ene lagringssystem, og dets replika er gemt på det andet. Data replikeres på niveau med lagervolumener, og VM-dataene (dens diske, konfigurationsfil, swap-fil osv.) gemmes på dem.
ESXi-værten ser den primære diskenhed og dens replika som én diskenhed (Storage Device). Der er 24 stier fra ESXi-værten til hver diskenhed:
12 stier forbinder det med det lokale lagersystem (optimale stier), og de resterende 12 til fjernlagersystemet (ikke-optimale stier). I en normal situation får ESXi adgang til data på det lokale lagersystem ved hjælp af "optimale" stier. Når dette lagersystem fejler, mister ESXi optimale stier og skifter til "ikke-optimale". Sådan ser det ud på diagrammet.
Ordning af en katastrofesikker klynge.
Alle klientnetværk er forbundet til begge steder gennem et fælles netværksstruktur. Hvert websted kører en Provider Edge (PE), hvor klientens netværk afsluttes. PE'er er forenet i en fælles klynge. Hvis en PE fejler på et sted, omdirigeres al trafik til det andet sted. Takket være dette forbliver virtuelle maskiner fra webstedet uden PE tilgængelige over netværket for klienten.
Lad os nu se, hvad der vil ske med virtuelle klientmaskiner under forskellige fejl. Lad os starte med de letteste muligheder og slutte med de mest alvorlige - fejl på hele webstedet. I eksemplerne vil hovedplatformen være OST, og backup-platformen, med datareplikaer, vil være NORD.
Hvad sker der med klientens virtuelle maskine, hvis...
Replikeringslink mislykkes. Replikering mellem lagersystemerne på de to steder stopper.
ESXi vil kun fungere med lokale diskenheder (via optimale stier).
Virtuelle maskiner fortsætter med at arbejde.
ISL (Inter-Switch Link) går i stykker. Sagen er usandsynlig. Medmindre en eller anden skør gravemaskine graver flere optiske ruter op på én gang, som kører på uafhængige ruter og bringes til pladserne gennem forskellige input. Men alligevel. I dette tilfælde mister ESXi-værter halvdelen af stierne og kan kun få adgang til deres lokale lagersystemer. Replikaer indsamles, men værter vil ikke kunne få adgang til dem.
Virtuelle maskiner fungerer normalt.
SAN-switchen fejler på et af webstederne. ESXi-værter mister nogle af stierne til lagersystemet. I dette tilfælde vil værterne på det sted, hvor skiftet mislykkedes, kun fungere gennem en af deres HBA'er.
De virtuelle maskiner fortsætter med at fungere normalt.
Alle SAN-kontakter på et af webstederne fejler. Lad os sige, at en sådan katastrofe skete på OST-webstedet. I dette tilfælde vil ESXi-værter på dette websted miste alle stier til deres diskenheder. Standard VMware vSphere HA-mekanismen kommer i spil: den genstarter alle virtuelle maskiner på OST-stedet i NORD på maksimalt 140 sekunder.
Virtuelle maskiner, der kører på NORD-websteder, fungerer normalt.
ESXi-værten fejler på ét sted. Her virker vSphere HA-mekanismen igen: virtuelle maskiner fra den fejlbehæftede vært genstartes på andre værter - på samme eller fjerntliggende websted. Genstarttiden for den virtuelle maskine er op til 1 minut.
Hvis alle ESXi-værter på OST-webstedet fejler, er der ingen muligheder: VM'erne genstartes på en anden. Genstartstiden er den samme.
Lagersystemet fejler på ét sted. Lad os sige, at lagersystemet fejler på OST-stedet. Så skifter ESXi-værterne på OST-stedet til at arbejde med lagerreplikater i NORD. Efter at det fejlbehæftede lagersystem vender tilbage til tjeneste, vil tvungen replikering forekomme, og ESXi OST-værterne vil igen begynde at få adgang til det lokale lagersystem.
Virtuelle maskiner har fungeret normalt hele tiden.
Et af webstederne fejler. I dette tilfælde vil alle virtuelle maskiner blive genstartet på sikkerhedskopieringsstedet gennem vSphere HA-mekanismen. VM genstartstid er 140 sekunder. I dette tilfælde vil alle netværksindstillinger for den virtuelle maskine blive gemt, og den forbliver tilgængelig for klienten over netværket.
For at sikre, at genstarten af maskiner på backup-stedet forløber problemfrit, er hvert websted kun halvt fyldt. Anden halvdel er en reserve, hvis alle virtuelle maskiner flytter fra det andet, beskadigede sted.
En katastrofebestandig sky baseret på to datacentre beskytter mod sådanne fejl.
Denne fornøjelse er ikke billig, da der ud over de vigtigste ressourcer er behov for en reserve på det andet sted. Derfor placeres forretningskritiske tjenester i en sådan sky, hvis langsigtede nedetid forårsager store økonomiske og omdømmetab, eller hvis informationssystemet er underlagt krav om katastrofemodstandsdygtighed fra regulatorer eller interne virksomhedsbestemmelser.
Kilder:
Kilde: www.habr.com