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
