Hallo, Habr!
Nach den Neujahrsfeiertagen haben wir die katastrophensichere Cloud auf der Basis von zwei Standorten neu gestartet. Heute erklÀren wir, wie das funktioniert, und zeigen, was mit den virtuellen Maschinen der Kunden passiert, wenn einzelne Elemente des Clusters ausfallen und ein ganzes GelÀnde zusammenbricht (Spoiler: Es geht ihnen gut).
SAN der katastrophensicheren Cloud am Standort OST.
Was steckt drin
Im Kern des Clusters befinden sich Cisco UCS-Server mit dem Hypervisor VMware ESXi, zwei INFINIDAT InfiniBox F2240 SAN-Systeme, Cisco Nexus-NetzwerkausrĂŒstung sowie Brocade SAN-Switches. Das Cluster ist auf zwei Standorte verteilt â OST und NORD, d. h. in jedem Rechenzentrum gibt es einen identischen Satz von GerĂ€ten. Das macht es auch katastrophensicher.
Innerhalb eines Standorts sind auch die Hauptkomponenten (Hosts, SAN-Switches, Netzwerk) dupliziert.
Die beiden Standorte sind durch dedizierte Glasfaserverbindungen verbunden, die ebenfalls redundant sind.
Ein paar Worte zu den SAN-Systemen. Die erste Variante der katastrophensicheren Cloud haben wir auf NetApp aufgebaut. Hier haben wir uns fĂŒr INFINIDAT entschieden, und das sind die GrĂŒnde dafĂŒr:
- Active-Active-Replikationsoption. Sie ermöglicht es der virtuellen Maschine, auch bei einem vollstĂ€ndigen Ausfall eines Speichersystems funktionsfĂ€hig zu bleiben. Ich werde spĂ€ter mehr ĂŒber die Replikation erzĂ€hlen.
- Drei Speichercontroller zur Erhöhung der Systemausfallsicherheit. Normalerweise gibt es zwei.
- Fertige Lösung. Bei uns ist bereits ein vollstÀndig montierter Rack angekommen, das nur noch mit dem Netzwerk verbunden und konfiguriert werden muss.
- Aufmerksamer Support. Die Ingenieure von INFINIDAT analysieren stÀndig die Protokolle und Ereignisse des Speichersystems, installieren neue Firmware-Versionen und helfen bei der Konfiguration.
Hier sind ein paar Fotos vom Unboxing:
Wie es funktioniert
Die Cloud ist bereits intern ausfallsicher. Sie schĂŒtzt den Kunden vor einzelnen Hardware- und SoftwareausfĂ€llen. Die katastrophensichere Lösung hilft jedoch, sich vor massiven AusfĂ€llen innerhalb eines Standorts zu schĂŒtzen: zum Beispiel beim Ausfall eines Speichersystems (oder eines SDS-Clusters, was nicht selten vorkommt đ), massiven Fehlern im Speichernetzwerk und so weiter. Und das Wichtigste: Eine solche Cloud rettet, wenn ein gesamter Standort aufgrund von Feuer, Stromausfall, Ăbernahme durch Dritte oder sogar Alien-Landung nicht mehr erreichbar ist.
In all diesen FĂ€llen arbeiten die Kunden-VMs weiter, und das ist der Grund.
Das Cluster-Layout ist so gestaltet, dass jeder ESXi-Host mit Client-VMs auf jedes der beiden SANs zugreifen kann. Wenn das SAN am OST-Standort ausfÀllt, werden die virtuellen Maschinen weiter betrieben: die Hosts, auf denen sie laufen, greifen auf die SAN am NORD-Standort zu.
So sieht das Anschlussdiagramm im Cluster aus.
Das ist möglich, weil zwischen den SAN-Fabriken der beiden Standorte ein Inter-Switch-Link eingerichtet ist: Der SAN-Switch Fabric A OST ist mit dem SAN-Switch Fabric A NORD verbunden, ebenso fĂŒr die SAN-Switches Fabric B.
Um diese komplizierten Verbindungen der SAN-Fabriken sinnvoll zu gestalten, ist zwischen den beiden SANs eine Active-Active-Replikation eingerichtet: Informationen werden praktisch gleichzeitig auf das lokale und das entfernte SAN geschrieben, RPO=0. Das bedeutet, dass auf einem SAN das Original der Daten gespeichert ist, wÀhrend auf dem anderen dessen Replikat liegt. Die Daten werden auf Volumenebene der SANs repliziert, und darauf liegen die Daten der VMs (deren Festplatten, Konfigurationsdateien, Swap-Dateien usw.).
Der ESXi-Host sieht das Hauptvolume und dessen Replikat als ein einziges SpeichergerĂ€t (Storage Device). Von dem ESXi-Host zu jedem SpeichergerĂ€t fĂŒhren 24 Pfade:
12 Wege verbinden es mit der lokalen SAN (optimale Wege), und die anderen 12 mit der entfernten (nicht optimale Wege). In der Regel greift ESXi auf die Daten der lokalen SAN ĂŒber die "optimalen" Wege zu. Bei einem Ausfall dieser SAN verliert ESXi die optimalen Wege und wechselt zu den "nicht optimalen". So sieht das schematisch aus.
Schema des katastrophensicheren Clusters.
Alle Kundennetze sind ĂŒber eine gemeinsame Netzwerkfabrik auf beiden Standorten verbunden. An jedem Standort arbeitet ein Provider Edge (PE), an dem die Kundennetze terminieren. Die PEs sind in einem gemeinsamen Cluster vereint. Bei einem Ausfall des PE an einem Standort wird der gesamte Traffic auf den zweiten Standort umgeleitet. Dadurch bleiben die virtuellen Maschinen am Standort ohne PE ĂŒber das Netzwerk fĂŒr den Kunden erreichbar.
Schauen wir uns nun an, was mit den virtuellen Maschinen des Kunden bei verschiedenen AusfĂ€llen passiert. Wir beginnen mit den mildesten FĂ€llen und enden mit dem gravierendsten â dem Ausfall des gesamten Standorts. In den Beispielen wird der Hauptstandort OST und der Backup-Standort mit den Datenreplikationen NORD sein.
Was passiert mit der virtuellen Maschine des Kunden, wennâŠ
die Replikationsverbindung ausfÀllt. Die Replikation zwischen den SAN-Systemen zweier Standorte wird eingestellt.
ESXi arbeitet nur mit lokalen FestplattengerĂ€ten (ĂŒber optimale Pfade).
Die virtuellen Maschinen laufen weiter.
Es erfolgt eine Unterbrechung des ISL (Inter-Switch Link). Ein solcher Fall ist höchst unwahrscheinlich. Es sei denn, ein verrĂŒckter Bagger grĂ€bt gleichzeitig mehrere optische Strecken um, die ĂŒber unabhĂ€ngige Routen verlaufen und an die Standorte ĂŒber verschiedene Einspeisungen angeschlossen sind. Dennoch. In diesem Fall verlieren die ESXi-Hosts die HĂ€lfte der Pfade und können nur auf ihre lokalen SAN-Systeme zugreifen. Die Replikate werden gesammelt, aber die Hosts können nicht darauf zugreifen.
Die virtuellen Maschinen arbeiten normal.
Ein SAN-Switch fĂ€llt an einem der Standorte aus. Die ESXi-Hosts verlieren einen Teil der Pfade zum SAN. In diesem Fall arbeiten die Hosts an dem Standort, an dem der Switch ausgefallen ist, nur ĂŒber einen ihrer HBAs.
Die virtuellen Maschinen laufen dabei weiterhin normal.
Alle SAN-Switches an einem der Standorte fallen aus. Angenommen, es tritt ein Problem auf der OST-Plattform auf. In diesem Fall verlieren die ESXi-Hosts auf dieser Plattform alle Verbindungen zu ihren Speichereinheiten. Hier kommt der Standardmechanismus von VMware vSphere HA ins Spiel: Er startet alle virtuellen Maschinen der OST-Plattform innerhalb von maximal 140 Sekunden neu.
Die virtuellen Maschinen, die auf den Hosts der NORD-Plattform betrieben werden, arbeiten einwandfrei.
Ein ESXi-Host auf einer Plattform fĂ€llt aus. Hier greift erneut der vSphere HA-Mechanismus: Die virtuellen Maschinen des ausgefallenen Hosts werden auf anderen Hosts â entweder auf derselben oder auf einer anderen Plattform â neu gestartet. Die Wiederherstellungszeit der virtuellen Maschine betrĂ€gt bis zu 1 Minute.
Wenn alle ESXi-Hosts der OST-Plattform ausfallen, gibt es keine Wahl: Die VMs werden auf einer anderen Plattform neu gestartet. Die Wiederherstellungszeit bleibt gleich.
Ein SAN auf einer Plattform fÀllt aus. Angenommen, das SAN auf der OST-Plattform ist ausgefallen. In diesem Fall wechseln die ESXi-Hosts der OST-Plattform auf die Replikate des SAN in der NORD-Plattform. Nach der Wiederherstellung des ausgefallenen SAN erfolgt eine erzwungene Replikation, und die ESXi-Hosts der OST-Plattform beginnen wieder, auf das lokale SAN zuzugreifen.
Die virtuellen Maschinen arbeiten wÀhrenddessen einwandfrei.
Eine der Plattformen fĂ€llt aus. In diesem Fall werden alle virtuellen Maschinen ĂŒber den vSphere HA-Mechanismus auf der Notfallstation neu gestartet. Die Zeit fĂŒr den Neustart der VM betrĂ€gt 140 Sekunden. Dabei bleiben alle Netzwerkeinstellungen der virtuellen Maschine erhalten, und sie bleibt im Netzwerk fĂŒr den Kunden erreichbar.
Damit der Neustart der Maschinen auf der Notfallstation reibungslos verlĂ€uft, ist jede Station nur zur HĂ€lfte ausgelastet. Die andere HĂ€lfte dient als Reserve fĂŒr den Fall, dass alle virtuellen Maschinen von der zweiten, betroffenen Station umziehen mĂŒssen.
Vor solchen AusfĂ€llen schĂŒtzt die katastrophensichere Cloud, die auf zwei Rechenzentren basiert.
Das VergnĂŒgen ist nicht billig, da neben den Hauptressourcen auch eine Reserve an der zweiten Station benötigt wird. Daher werden in einer solchen Cloud geschĂ€ftskritische Dienste untergebracht, deren lĂ€ngere Ausfallzeiten erhebliche finanzielle und reputationsbezogene Verluste verursachen, oder wenn an das Informationssystem Anforderungen an die Katastrophensicherheit von Regulierungsbehörden oder internen Richtlinien gestellt werden.
Quellen:
Quelle: habr.com
