Hey Habr!
No der Neijoerschvakanz hu mir eng Katastrophebeständeg Wollek op zwou Siten relancéiert. Haut wäerte mir Iech soen wéi et funktionnéiert a weisen wat mat Client virtuelle Maschinnen geschitt wann eenzel Elementer vum Stärekoup versoen an de ganze Site crasht (Spoiler - alles ass gutt mat hinnen).
Katastrophebeständeg Cloud Storage System op der OST Site.
Wat ass dobannen
Ënnert der Hood huet de Cluster Cisco UCS Server mat engem VMware ESXi Hypervisor, zwee INFINIDAT InfiniBox F2240 Späichersystemer, Cisco Nexus Netzwierkausrüstung, souwéi Brocade SAN Schalter. De Stärekoup ass an zwee Site opgedeelt - OST an NORD, dh all Datenzenter huet eng identesch Formatioun vun Ausrüstung. Eigentlech ass dat wat et katastrofebeständeg mécht.
Bannent engem Site sinn d'Haaptelementer och duplizéiert (Hosten, SAN Schalter, Netzwierker).
Déi zwee Siten sinn duerch engagéierten Léngen OPTIC routes verbonnen, och reservéiert.
E puer Wierder iwwer Späichersystemer. Mir hunn déi éischt Versioun vun enger Katastrophebeständeger Wollek op NetApp gebaut. Hei hu mir INFINIDAT gewielt, an hei ass firwat:
- Aktiv-Aktiv Replikatiounsoptioun. Et erlaabt der virtueller Maschinn operationell ze bleiwen, och wann ee vun de Späichersystemer komplett ausfällt. Ech soen Iech méi spéit iwwer Replikatioun.
- Dräi Disk Controller fir Systemfehler Toleranz ze erhéijen. Normalerweis ginn et zwee.
- Fäerdeg Léisung. Mir kruten e pre-montéierte Rack deen just mam Netz verbonne muss a konfiguréiert sinn.
- Opgepasst technesch Ënnerstëtzung. INFINIDAT Ingenieuren analyséieren permanent Stockage System Logbicher an Evenementer, installéiert nei Firmware Versiounen, an hëllefen mat Configuratioun.
Hei e puer Fotoen vum Auspaken:
Wéi et schafft
D'Wollek ass scho Feelertolerant a sech selwer. Et schützt de Client virun eenzel Hardware- a Softwarefehler. Katastrophen-resistent hëlleft géint massiv Feeler bannent engem Site schützen: Zum Beispill, Echec vun engem Stockage System (oder engem SDS Stärekoup, déi geschitt zimlech oft 🙂), massive Feeler an engem Stockage Reseau, etc. Gutt, an am wichtegsten: sou eng Wollek spuert wann e ganze Site onzougänglech gëtt wéinst engem Feier, Blackout, Raider Iwwernahm oder Auslännerlandung.
An all dëse Fäll schaffen de Client virtuelle Maschinnen weider, an hei ass firwat.
De Stärekoup Design ass sou entworf datt all ESXi Host mat Client virtuell Maschinnen Zougang zu all vun deenen zwee Stockage Systemer kann. Wann de Späichersystem op der OST-Site feelt, wäerten d'virtuelle Maschinnen weider schaffen: d'Hosten, op deenen se lafen, ginn Zougang zum Späichersystem op NORD fir Daten.
Dëst ass wéi de Verbindungsdiagramm an engem Cluster ausgesäit.
Dëst ass méiglech wéinst der Tatsaach, datt en Inter-Switch Link tëscht de SAN Stoffer vun deenen zwee Site konfiguréiert ass: de Stoff A OST SAN Schalter ass mat dem Fabric A NORD SAN Schalter verbonnen, an ähnlech fir d'Fabrik B SAN Schalter.
Gutt, sou datt all dës Schwieregkeete vu SAN Fabriken Sënn maachen, ass Active-Active Replikatioun tëscht den zwee Späichersystemer konfiguréiert: Informatioun gëtt bal gläichzäiteg un déi lokal a Fernspeichersystemer geschriwwe, RPO = 0. Et stellt sech eraus datt déi ursprénglech Donnéeën op engem Späichersystem gespäichert sinn, a seng Replika gëtt op deem aneren gespäichert. D'Daten ginn um Niveau vun de Späichervolumen replizéiert, an d'VM-Daten (seng Disken, Konfiguratiounsdatei, Tauschdatei, asw.) ginn op hinnen gespäichert.
Den ESXi Host gesäit de primäre Volumen a seng Replika als een Diskapparat (Storage Device). Et gi 24 Weeër vum ESXi Host op all Diskapparat:
12 Weeër verbannen et mam lokalen Späichersystem (optimal Weeër), an déi reschtlech 12 mam Fernspeichersystem (net optimal Weeër). An enger normaler Situatioun, Zougang ESXi Daten op der lokal Stockage System benotzt "optimal" Weeër. Wann dës Stockage System klappt, verléiert ESXi optimal Weeër a schalt op "Net-optimal". Dëst ass wéi et am Diagramm ausgesäit.
Schema vun engem Katastrophen-Beweis Stärekoup.
All Client Netzwierker si mat béide Site duerch e gemeinsame Reseau Stoff verbonnen. All Site leeft e Provider Edge (PE), op deem d'Netzwierker vum Client ofgeschloss ginn. PEs sinn an engem gemeinsame Cluster vereenegt. Wann e PE op engem Site feelt, gëtt all Traffic op déi zweet Säit ëmgeleet. Dank dëser, virtuell Maschinnen aus dem Site lénks ouni PE bleiwen iwwer de Reseau fir de Client zougänglech.
Loosst eis elo kucken wat mat Client virtuelle Maschinnen wärend verschiddene Feeler geschitt. Loosst eis mat de liichtste Optiounen ufänken a mat de seriösten Enn - Echec vum ganze Site. An de Beispiller wäert d'Haaptplattform OST sinn, an d'Backupplattform, mat Datenrepliken, wäert NORD sinn.
Wat geschitt mat der virtueller Clientsmaschinn wann ...
Replikatiounslink feelt. Replikatioun tëscht de Späichersystemer vun den zwee Site stoppt.
ESXi wäert nëmme mat lokal Scheif Apparater Aarbecht (via optimal Weeër).
Virtuell Maschinnen schaffen weider.
Den ISL (Inter-Switch Link) brécht. De Fall ass onwahrscheinlech. Ausser wann e verréckten Bagger e puer optesch Strecken gläichzäiteg gräift, déi op onofhängege Strecken lafen an duerch verschidden Inputen op d'Siten bruecht ginn. Awer souwisou. An dësem Fall verléieren ESXi Hosten d'Halschent vun de Weeër a kënnen nëmmen op hir lokal Späichersystemer kommen. Replicas gi gesammelt, awer Hosten kënnen net op hinnen zougoen.
Virtuell Maschinnen funktionnéieren normal.
De SAN-Schalter feelt op engem vun de Siten. ESXi Hosten verléieren e puer vun de Weeër fir de Stockage System. An dësem Fall funktionnéieren d'Hosts op der Plaz wou de Schalter gescheitert ass nëmmen duerch eng vun hiren HBAs.
Déi virtuell Maschinnen funktionnéieren weider normal.
All SAN schalt op ee vun de Siten versoen. Loosst eis soen datt esou eng Katastroph um OST Site geschitt ass. An dësem Fall wäert ESXi Provider op dësem Site all Weeër op hir Scheif Apparater verléieren. De Standard VMware vSphere HA Mechanismus kënnt an d'Spill: et wäert all virtuell Maschinnen vun der OST Site am NORD an engem Maximum vun 140 Sekonnen nei starten.
Virtuell Maschinnen déi op NORD Site Hosten lafen, funktionnéieren normalerweis.
Den ESXi Host feelt op engem Site. Hei funktionnéiert de vSphere HA Mechanismus erëm: virtuelle Maschinnen vum gescheitert Host ginn op anere Hosten nei gestart - op derselwechter oder Remote Site. Déi virtuell Maschinn Restartzäit ass bis zu 1 Minutt.
Wann all ESXi Hosten op der OST Site versoen, ginn et keng Optiounen: d'VMs ginn op engem aneren nei gestart. Restart Zäit ass déi selwecht.
De Späichersystem feelt op engem Site. Loosst eis soen datt de Späichersystem op der OST Site feelt. Dann wiesselen d'ESXi Hosten vum OST Site fir mat Späicherrepliken an NORD ze schaffen. Nom gescheitert Stockage System nees Service, gezwongen Replikatioun geschéien an der ESXi OST Providere wäert erëm ufänken Zougang zu der lokal Stockage System.
Virtuell Maschinnen hunn all dës Zäit normal geschafft.
Ee vun de Siten feelt. An dësem Fall ginn all virtuell Maschinnen op der Backupsatellit duerch de vSphere HA Mechanismus nei gestart. VM Restart Zäit ass 140 Sekonnen. An dësem Fall ginn all Netzwierkastellunge vun der virtueller Maschinn gespäichert, an et bleift fir de Client iwwer dem Netz zougänglech.
Fir sécherzestellen datt de Restart vun de Maschinnen op der Backup-Site glat geet, ass all Site nëmmen hallef voll. Déi zweet Halschent ass eng Reserve am Fall wou all virtuell Maschinnen vun der zweeter, beschiedegter Säit plënneren.
Eng Katastrophebeständeg Wollek baséiert op zwee Datenzentere schützt géint esou Feeler.
Dëse Genoss ass net bëlleg, well nieft den Haaptressourcen ass eng Reserve op der zweeter Plaz gebraucht. Dofir gi geschäftlech kritesch Servicer an esou enger Wollek plazéiert, déi laangfristeg Ausbrieche vun deenen grouss finanziell a renomméiert Verloschter verursaacht, oder wann d'Informatiounssystem ënner Katastrophe-Widerstandsfuerderunge vu Reguléierer oder intern Firmereglementer ënnerleien.
Quell:
Source: will.com