Beispiel eines vmware High Availabe Stretched Clusters
Auch wenn dieses Thema schon weit ausgedehnt wurde, z.B. von Duncan Epping und Frank Denneman in Ihrem Deep Dive Buch , möchte ich ein Design Beispiel aus meiner Vergangenheit hier gerne wiedergeben.
Beim Aufräumen alter Dokumente bin ich auf ein Konzeptpapier gestossen welches Grundlage dieses Artikels ist. Es diente damals dazu eine ältere vmware Produktionsumgebung die neu aufgebaut werden sollte so zu designen, das alle üblichen High Availability (HA) Fälle von der Umgebung möglichst automatisch bzw. mit geringem administrativen Eingriffen verfügbar bleibt. Also die üblichen Ziele: Hohe Verfügbarkeit mit möglichst minimalen Downtimes für alle Unternehmenswichtigen Services.
Ich denke das dieses Beispiel gut aufzeigt wie mit „normalen“, heute verfügbaren Mitteln, ohne Exorbitantem finanziellem Aufwand dieses Anforderung erfüllbar ist.
Ausgangssituation
Im genannten Umfeld war eine alte vmware 3.5 Umgebung sowohl Server- als auch Storage-seitig durch neues Equipment zu ersetzen. Um dem erwarteten Datenzuwachs Rechung zu tragen sollte goßzügig genug geplant werden. Ausserdem stand der Aspekt des möglichst einfachen, zeitlich kurzem und für die Anwender nicht spürbaren Umzugs auf die neue Umgebung im Anforderungs Katalog.
Die vmware 3.5 Umgebung war auf zwei Gebäude verteilt, die über Glasfaserleitungen miteinander verbunden sind (Distanz ca. 50 – 100 m). Somit kam das Konzept für einen sogenannten „Stretched Cluster“ zum Einsatz.
Bei einem Stretched Cluster sprechen wir von einer vmware vSphere Umgebung die sich auf zwei Räume / Gebäude / Brandabschnitte verteilt, aber von einem einzigen vCenter Server verwaltet wird.
Bild 1: Komplette Übersicht – vmware vSphere Stretched Cluster
Diese Bild zeigt den Architekturplan des gesamten Projektes und nimmt natürlich einige Elemente der Lösung vorweg.
Die Komponenten der Lösung
Wie man am Bild 1 sicher erkennen kann, besteht die Lösung aus folgenden Komponenten (ich nenne Hersteller nur dann wenn es für die Erklärung zwingend notwendig ist, anderfalls sind hier verschiedene Hersteller als Lieferanten einsetzbar):
- Auf Seite A und aus Seite B werden jeweils eine gleiche Anzahl gleicher Server als ESXi Hosts aufgesetzt.
- Auf beiden Seiten werden gleiche Storage Systeme installiert.
- Auf jeder Seite wird eine DataCore SDS mit SanSymphony V installiert
Zu den Details: In beiden Server Räumen der Seite A und Seite B werden praktisch indentische Hardware Umgebungen aufgebaut, beide Seiten sind autark betreibbar! Die Server und Storage Systeme sind so auszulegen das im Worst-Case eine Seite allein die gesamte Last tragen kann.
Verbunden sind hierbei die Storage Systeme via Fibre Channel (in diesem Fall 8GB, es könnte aber auch mit iSCSI gearbeitet werden. Da DataCore in der planten Version kein NFS unterstützte sähe eine NFS basierte Lösung etwas anders aus). Die DataStores werden jeweils via synchronem Spiegel auf die andere Seite gespiegelt und stehen auch dort zur Verfügung.
Bitte denken Sie daran auch das vSphere Management Netz so redundant auszulegen, das später alle Ausfall Scenarien abgedeckt werden (warum heiß der „Single Point of Failure“ nur so ;-))
Das die Storage Verbindungen und natürlich auch das Produktivnetz (im Bild Hausnetz) redundant ausgelegt werden ist sicher selbstverständlich.
Die ganze Lösung wurde als sog. Non-Uniform stretched vSphere Cluster realisiert.
Uniform stretched Cluster
Ein Uniform stretched Cluster bedeutet das alle Hosts und alle Storage Systeme so verbunden sind das alle alles zu jederzeit „sehen“. Das heisst die ESXi Hosts haben permanent Zugriff auf alle Datastores jeder Seite.
Non-Uniform stretched Cluster
Ein Non-Uniform stretched Cluste bedeutet das die Hosts einer Seite auch nur „aktiv“ mit den Datastores der Storage Systeme dieser Seite verbunden sind. Im Fehlerfall muß nun eine, wie auch immer geartete Lösung dafür sorgen das auf die jeweils andere Seite geschwenkt wird. Die Daten werden also „nur“ auf Storage Ebene repliziert (synchron oder asynchron). Hier bieten viele große Storage Hersteller eigene Plugins für „gutes“ Geld an.
Ausfall Scenarien
Betrachten wir nun nacheinander die verschiedenen Ausfall Scenarien und wie sich die Umgebung dann jeweils verhalten soll.
Ausfall eines Hostes auf einer Seite
Fällt ein Host einer Seite des Clusters aus, so greift vmware vSphere HA und startet die gecrashten VMs auf den verbleibenden Hosts dieser Seite neu. Damit das funktioniert sollte via DRS Rules und den dort konfigurierbaren Affiniti Rules über Gruppen eine „Sollte immer auf dieser Hostgruppe laufen“ Regel definiert werden. Diese erkläre ich jetzt hier nicht, vielleicht in einem anderen Artikel irgendwann. Kurzgesagt bedeutet diese Regel, das VMs im Normalfall möglichst auf bestimmten ESXi Hosts einer Gruppe laufen sollen. DRS sorgt dann dafür das dieses so ist. In unserem Fall haben wir zwei Hostgruppe: Hosts der Seite A und Hosts der Seite B. Hintergrund: Wir arbeiten mit einem Non-Uniform Cluster und die VMs auf den Hosts der Seite A sollen auch das Storage der Seite A nutzen um z.B. mögliche Laufzeiten (und Latenzen) zur anderen Seite zu minimieren.
Bild 2: HA-Host einer Seite fällt aus
Ausfall eines Datastores einer Seite
Falls ein Datastore einer Seite ausfällt (siehe Bild 3) so kommt es darauf an was genau unter „Ausfall“ zu verstehen ist. Fällt „nur“ eine Platte des Storage Systems aus, so haben wir hoffentlich kein direktes Problem für unsere VMs da dort durch RAID usw. der Fehler für den Host und die VMs transparent abgefangen wird. Sollte es dagegen zu einem Totalausfall eines Storage Bereiches dieser Seite kommen, fallen die VMs herunter und vmware HA kann zum Einsatz kommen, allerdings nur dann, wenn jetzt auf die gespiegelten Daten der anderen Seite zugegriffen werden kann!
Dazu muss jetzt, wie vorher (unter Non-Uniform Cluster) beschrieben, jemand die Storage Pfade „umschalten“, sprich die gespigelten Datastores der Seite B nun als aktiv an die Seite A anbinden. Unsere Lösung die hier projektiert wurde basiert auf DataCore SANsymphony, welches einen transparenten Failover bereitstellt. Dieser schaltet im Normalfall so schnell um, das vmware HA garnicht erst zum Einsatz kommen muss. DataCore sorgt in unserem Fall auch für den Synchronen Spiegel.
Bild 3: HA Datastore einer Seite fällt aus
Ausfall einer gesamten Host Cluster Seite
Kommen wir nun zu dem Fall das uns eine gesamte vmware Cluster Seite ausfällt. Hier greift wieder vmware HA, denn wir haben ja in unserer DRS Rule gesagt „sollte“, nicht „darf nur“. HA versucht nun die VMs der Seite A die ja mit den Hosts gestorben sind auf der Seite B neu zu starten. Geht das? Tja in unserem Fall müssen die Synchronen Datastores die von Seite A auf Seite B gespiegelt wurden dort „aktiv“ sein, oder kurz gesagt müsste jemand die Datastores der Seite A auf den Hosts der Seite B „aktiv“ schalten! Somit haben wir zwei Möglichkeiten. Diese können gern im Anschluß diskutiert werden.
Bild 4: Komplette ESXi Cluster Seite fällt aus
Bitte daran denken, daß in diesem Fall auch die vCenter Server VM betroffen sein kann. Das bedeutet allerdings nur, das für die Zeit des wideranstartens durch vmware vSphere HA kein DRS läuft! DRS ist eines der wenigen Funktionen die nur funktionieren wenn der vCenter Server läuft.
Ausfall einer Seite ohne virtuelle Storage Pools
Betrachten wir im Anschluß an den vorhergehenden Failure Fall nun den Ausfall einer ganzen Seite, sowohl Hosts als auch Storage. Was hier passiert ist etwas aufwändiger. In diesem Fall haben wir keine virtuellen Storage Pools, sondern „klassische“ Anbindung. Es läuft so ähnlich wie unter „Ausfall eines Datastores einer Seite“ ab. Irgendjemand (z.B. via Skript) muß die Synchon gespiegelten Datastores der Seite A auf Seite B den Hosts der Seite B „aktiv“ schalten. Nun sehen diese Hosts die VMs und vSphere HA kann mit dem Restart der VM beginnen. Knackpunkt ist hier die Umschaltung der Storage Pfade. Wie gesagt „Irgendjemand“ muss das tun! Nur ist der Irgendjemand dann auch da und sieht das Chaos kommen ;-( ?
Bild 5: Ausfall einer kompletten Seite – Hosts und Storage
Ich selbst bin KEIN Freund von solchen „Desaster-Skripten“ denn die wollen gepflegt sein (bei jedem Storage Umbau usw. muss nachgepflegt werden). Storage Pfade sind auch nicht gerade „lesefreundlich“ und entsprechendes KnowHow sollte vorrätig sein.
Ausfall einer Seite mit virtuellen Storage Pools
Aus den genannten Gründen im letzten Abschnitt habe ich damals die Lösung mit sogenannten virtuellen Pools favorisiert. Hierbei sollte in diesem Konzept, DataCore einer der Pioniere der Storage Virtualisierung zum Einsatz kommen. DataCore stellt den angebunden ESXi Hosts virtuelle Datastores zur Verfügung die auf virtuellen Storage Pools beruhen. Diese virtuellen Pools bestehen aus Storage Bereichen beider Seiten und beinhalten unter anderem den Synchronen Spiegel von Seite A auf Seite B. Somit ist für die ESXi Host der komplette Storage Aufbau intransparent. Sie sehen nur den Pool. Fällt uns nun das Storage System einer Seite, oder die gesamte Seite aus, so sorgt DataCore dafür das die ESXi Hosts weiter den Pools so sehen als sei alles in Ordnung! Im Fall des Ausfalls der gesammten Seite muss allerdings vSphere HA auch noch arbeiten. Da dieses aber, bei korrekter Implementierung (siehe z.B. hier) absolut zuverlässig arbeitet, sollte die tatsächliche Downtime selbst in diesem Extrem-Fall relativ kurz sein. Das Schöne dabei ist, das eigentlich niemand „geweckt“ werden muss. Das System arbeitet alleine an der Wiederherstellung.
Bild 6: Totalausfall einer Seite mit virtuellen Pools
Abschussbemerkungen
Auch wenn ich selbst hier DataCore präferiere, kann das gezeigte Scenario auch mit anderen Storage Lösungen ähnlich aufgebaut werden. Ausserdem sollte trotz solch einer Lösung NIE auf ein funktionierendes Backup Konzept mit entsprechender Lösung verzichtet werden (soll es tatsächlich geben 😉 )
Übrigens kann DataCore durch seine „Proxied Volume“ Funktion auch beim Umzug einer alten- auf eine neue Storage Lösung sehr gute Dienste leisten.
Über eine Diskussion dieser Lösung würde ich mich freuen, denn soweit mir bekannt ist wurde diese Konzept aus verschiedenen Gründen nie umgesetzt. Schade oder?
Somit ist es mir gelungen durch ein paar „Nachteinsätze“ doch wieder einen Artikel zu erstellen.
dervirtuellewirt 