Hey Habr!
Nach den Neujahrsfeiertagen haben wir eine katastrophensichere Cloud basierend auf zwei Standorten neu gestartet. Heute erklären wir Ihnen, wie es funktioniert und zeigen, was mit virtuellen Client-Maschinen passiert, wenn einzelne Elemente des Clusters ausfallen und die gesamte Site abstürzt (Spoiler – bei ihnen ist alles in Ordnung).
Katastrophensicheres Cloud-Speichersystem auf der OST-Site.
Was ist drin
Unter der Haube des Clusters befinden sich Cisco UCS-Server mit einem VMware ESXi-Hypervisor, zwei INFINIDAT InfiniBox F2240-Speichersysteme, Cisco Nexus-Netzwerkausrüstung sowie Brocade SAN-Switches. Der Cluster ist in zwei Standorte unterteilt – OST und NORD, d. h. jedes Rechenzentrum verfügt über eine identische Ausstattung. Genau das macht es katastrophenresistent.
Innerhalb eines Standorts sind auch die Hauptelemente dupliziert (Hosts, SAN-Switches, Netzwerk).
Die beiden Standorte sind durch ebenfalls reservierte dedizierte Glasfaserstrecken verbunden.
Ein paar Worte zu Speichersystemen. Wir haben die erste Version einer katastrophensicheren Cloud auf NetApp erstellt. Hier haben wir uns für INFINIDAT entschieden, und hier ist der Grund:
- Aktiv-Aktiv-Replikationsoption. Dadurch bleibt die virtuelle Maschine auch dann betriebsbereit, wenn eines der Speichersysteme komplett ausfällt. Ich werde Ihnen später mehr über die Replikation erzählen.
- Drei Festplatten-Controller zur Erhöhung der Systemfehlertoleranz. Normalerweise sind es zwei.
- Fertige Lösung. Wir haben ein vormontiertes Rack erhalten, das nur noch an das Netzwerk angeschlossen und konfiguriert werden muss.
- Aufmerksamer technischer Support. Die Ingenieure von INFINIDAT analysieren ständig die Protokolle und Ereignisse des Speichersystems, installieren neue Firmware-Versionen und helfen bei der Konfiguration.
Hier ein paar Fotos vom Auspacken:
Wie es funktioniert
Die Cloud ist in sich bereits fehlertolerant. Es schützt den Client vor einzelnen Hardware- und Softwareausfällen. Katastrophenresistent schützt vor massiven Ausfällen an einem Standort: zum Beispiel dem Ausfall eines Speichersystems (oder eines SDS-Clusters, was recht häufig vorkommt 🙂), massiven Fehlern in einem Speichernetzwerk usw. Nun, und das Wichtigste: Eine solche Cloud speichert, wenn ein gesamter Standort aufgrund eines Brandes, eines Stromausfalls, einer Raider-Übernahme oder einer außerirdischen Landung nicht mehr zugänglich ist.
In all diesen Fällen funktionieren die virtuellen Clientmaschinen weiterhin, und hier erfahren Sie, warum.
Das Cluster-Design ist so konzipiert, dass jeder ESXi-Host mit virtuellen Client-Maschinen auf jedes der beiden Speichersysteme zugreifen kann. Wenn das Speichersystem auf der OST-Site ausfällt, funktionieren die virtuellen Maschinen weiter: Die Hosts, auf denen sie ausgeführt werden, greifen für Daten auf das Speichersystem auf NORD zu.
So sieht das Verbindungsdiagramm in einem Cluster aus.
Dies ist möglich, weil zwischen den SAN-Fabrics der beiden Standorte ein Inter-Switch-Link konfiguriert ist: Der OST-SAN-Switch von Fabric A ist mit dem SAN-Switch von Fabric A NORD verbunden, und das gilt auch für die SAN-Switches von Fabric B.
Damit all diese Feinheiten von SAN-Fabriken einen Sinn ergeben, wird die Aktiv-Aktiv-Replikation zwischen den beiden Speichersystemen konfiguriert: Informationen werden fast gleichzeitig in die lokalen und Remote-Speichersysteme geschrieben, RPO = 0. Es stellt sich heraus, dass die Originaldaten auf einem Speichersystem gespeichert sind und ihre Replik auf dem anderen. Die Daten werden auf der Ebene der Speichervolumes repliziert und die VM-Daten (seine Festplatten, Konfigurationsdatei, Auslagerungsdatei usw.) werden darauf gespeichert.
Der ESXi-Host betrachtet das primäre Volume und sein Replikat als ein Festplattengerät (Speichergerät). Es gibt 24 Pfade vom ESXi-Host zu jedem Festplattengerät:
12 Pfade verbinden es mit dem lokalen Speichersystem (optimale Pfade) und die restlichen 12 mit dem Remote-Speichersystem (nicht optimale Pfade). Im Normalfall greift ESXi über „optimale“ Pfade auf Daten im lokalen Speichersystem zu. Wenn dieses Speichersystem ausfällt, verliert ESXi die optimalen Pfade und wechselt zu „nicht optimalen“ Pfaden. So sieht es auf dem Diagramm aus.
Schema eines katastrophensicheren Clusters.
Alle Client-Netzwerke sind über eine gemeinsame Netzwerkstruktur mit beiden Standorten verbunden. Jeder Standort betreibt einen Provider Edge (PE), auf dem die Netzwerke des Kunden terminiert sind. PEs sind zu einem gemeinsamen Cluster zusammengefasst. Fällt ein PE an einem Standort aus, wird der gesamte Datenverkehr zum zweiten Standort umgeleitet. Dadurch bleiben virtuelle Maschinen von der Site ohne PE über das Netzwerk für den Client zugänglich.
Sehen wir uns nun an, was bei verschiedenen Fehlern mit den virtuellen Client-Maschinen passiert. Beginnen wir mit den einfachsten Optionen und enden mit der schwerwiegendsten – dem Ausfall der gesamten Website. In den Beispielen ist die Hauptplattform OST und die Backup-Plattform mit Datenreplikaten NORD.
Was passiert mit der virtuellen Clientmaschine, wenn...
Replikationslink schlägt fehl. Die Replikation zwischen den Speichersystemen der beiden Standorte wird beendet.
ESXi funktioniert nur mit lokalen Festplattengeräten (über optimale Pfade).
Virtuelle Maschinen funktionieren weiterhin.
Der ISL (Inter-Switch Link) bricht zusammen. Der Fall ist unwahrscheinlich. Es sei denn, irgendein verrückter Bagger gräbt mehrere optische Routen auf einmal aus, die auf unabhängigen Routen verlaufen und über verschiedene Eingänge zu den Standorten gebracht werden. Aber wie auch immer. In diesem Fall verlieren ESXi-Hosts die Hälfte der Pfade und können nur noch auf ihre lokalen Speichersysteme zugreifen. Replikate werden gesammelt, Hosts können jedoch nicht darauf zugreifen.
Virtuelle Maschinen funktionieren normal.
Der SAN-Switch fällt an einem der Standorte aus. ESXi-Hosts verlieren einige Pfade zum Speichersystem. In diesem Fall funktionieren die Hosts am Standort, an dem der Switch ausgefallen ist, nur über einen ihrer HBAs.
Die virtuellen Maschinen funktionieren normal weiter.
Alle SAN-Switches an einem der Standorte fallen aus. Nehmen wir an, auf der OST-Site ist eine solche Katastrophe passiert. In diesem Fall verlieren ESXi-Hosts auf dieser Site alle Pfade zu ihren Festplattengeräten. Der standardmäßige VMware vSphere HA-Mechanismus kommt ins Spiel: Er startet alle virtuellen Maschinen der OST-Site in NORD in maximal 140 Sekunden neu.
Virtuelle Maschinen, die auf NORD-Site-Hosts ausgeführt werden, funktionieren normal.
Der ESXi-Host fällt auf einer Site aus. Hier funktioniert der vSphere HA-Mechanismus wieder: Virtuelle Maschinen vom ausgefallenen Host werden auf anderen Hosts neu gestartet – auf demselben oder einem Remote-Standort. Die Neustartzeit der virtuellen Maschine beträgt bis zu 1 Minute.
Wenn alle ESXi-Hosts auf der OST-Site ausfallen, gibt es keine Optionen: Die VMs werden auf einer anderen neu gestartet. Die Neustartzeit ist dieselbe.
Das Speichersystem fällt an einem Standort aus. Nehmen wir an, das Speichersystem fällt am OST-Standort aus. Anschließend wechseln die ESXi-Hosts der OST-Site zur Arbeit mit Speicherreplikaten in NORD. Nachdem das ausgefallene Speichersystem wieder in Betrieb genommen wurde, erfolgt eine erzwungene Replikation und die ESXi OST-Hosts beginnen wieder mit dem Zugriff auf das lokale Speichersystem.
Virtuelle Maschinen haben die ganze Zeit normal funktioniert.
Eine der Websites schlägt fehl. In diesem Fall werden alle virtuellen Maschinen auf der Backup-Site über den vSphere HA-Mechanismus neu gestartet. Die VM-Neustartzeit beträgt 140 Sekunden. In diesem Fall werden alle Netzwerkeinstellungen der virtuellen Maschine gespeichert und sie bleibt für den Client über das Netzwerk zugänglich.
Um sicherzustellen, dass der Neustart der Maschinen am Backup-Standort reibungslos verläuft, ist jeder Standort nur halb voll. Die zweite Hälfte dient als Reserve für den Fall, dass alle virtuellen Maschinen vom zweiten, beschädigten Standort verschoben werden.
Vor solchen Ausfällen schützt eine katastrophensichere Cloud auf Basis zweier Rechenzentren.
Dieses Vergnügen ist nicht billig, da zusätzlich zu den Hauptressourcen eine Reserve auf dem zweiten Standort benötigt wird. Daher werden geschäftskritische Dienste in einer solchen Cloud abgelegt, deren langfristiger Ausfall zu großen finanziellen und Reputationsverlusten führt oder wenn das Informationssystem Anforderungen an die Katastrophenresistenz von Aufsichtsbehörden oder unternehmensinternen Vorschriften unterliegt.
Quellen:
Source: habr.com