Die Notwendigkeit von hochverfügbarem Management

Das Management von virtuellen Infrastrukturen ist manchmal das schwächste Glied in der Kette. In einer VMware Umgebung stellt das vCenter die meisten Betriebsabläufe zur Verfügung. Fällt dieses aus, können wichtige Funktionen, welche zum Betrieb notwendig sind, nicht mehr ausgeführt werden.  Hierzu zählt z.b. Dynamic Ressource Scheduling (DRS), vMotion oder auch Storage vMotion. Genauso ist der Zugriff auf die Distributed Netzwerk Switche eingeschränkt.

Unter anderen aus diesen Gründen besteht bei unseren Kunden immer wieder die Notwendigkeit, Lösungsszenarien dazustellen,  welche die wichtigen Management Komponenten Hoch verfügbar machen.

Wo liegt das Problem?

Grundlegend gibt es vier Fehlerszenarien, die den Betrieb des vCenter unterbrechen können.

Dabei wird jeweils der Betrieb des Applikationsservers mit allen vCenter-Komponenten (vCenter Server, Inventory Service, Orchestrator, SSO, Update Manager) sowie einer externen MSSQL-Datenbank angenommen. Alle Szenarien lassen sich aber ebenso für verteilte vCenter-Komponenten, sprich verteilt auf verschiedenen Server, anwenden.

Folgende Ausfallszenarien können eintreten:

  1. Probleme auf Betriebssystem- und Software-Komponentenebene (Update)
  2. Ausfall oder Störung eines Blades im Enclosure
  3. Ausfall oder Störung des gesamten Enclosures
  4. Ausfall oder Störung des gesamten Datacenters

Szenario Eins kann beispielsweise beim Einspielen von Windows Patches und dem Update von vCenter-Komponenten auf einen neuen Release-Stand eintreten. Hiergegen sollte man sich vor einem Updat,e mit Backups der Datenbanken (SQL und ADAM) sowie einem zusätzlichen Snapshot der VM’s, vor dem Update absichern.

Szenario Zwei skizziert den Wegfall des ESXi-Host, der im dem Moment des Ausfalls die vCenter-VM(s) oder die Datenbank bzw. mehrere vCenter Komponenten ausführt. Um die Komponenten in diesen Fall möglichst schnell wieder in den normalen Betrieb zu nehmen, sollte man auf ein, bei der Inbetriebnahme des Clusters aktiviertes, vSphere HA setzen. Dieser startet nach dem Ausfall die VM’s des ESXi-Hosts auf anderen Hosts im Cluster neu solange die nötigen Ressourcen hierfür vorhanden sind.

Für Szenario Drei muss bei Blade-Umgebungen auf das vorliegende Cluster-Design geachtet werden. Bestmöglichst, erstreckt sich ein vSphere Cluster über mindestens zwei Blade-Enclosures. Darauf zu achten ist auch, das die nicht ausgefallenen Enclosure genug Failover-Kapazität (Admission Control) bereit halten. So lassen sich die ausgefallenen VM’s, wie in Szenario 2, dort neustarten und so eine möglichst geringe Ausfallzeit garantieren. Vorsicht ist geboten, wenn alle vSphere Hosts (Blades) im Cluster in nur einen Enclosurer sind. In diesen Fall muss über eine andere Lösung zur schnellen Wiederaufnahme des Betriebs gesetzt werden, da vSphere HA in dieser Situation nicht greift.. Erschwerend kann hinzukommen, dass die Datastores/LUN’s auf denen die entsprechenden VM’s liegen, lediglich den ESXi-Hosts dieses Clusters präsentiert werden (z. B. Fibre Channel Zoning). Für dieses Szenario muss also eine Replikation der Daten auf ESXi-Host-Ebene (Block-based; Host based Replication) oder auf Applikationsebene erfolgen. Für beide Szenarien bietet VMware jeweils ein Produkt an. Für beide Ansätze wird kein zusätzliche Array-basierte Replikation (z.B. EMC SRDF) benötigt.

Eine Lösung ist VMware vCenter Heartbeat. VMware vCenter Server Heartbeat arbeitet auf Applikationsebene und spiegelt die Dienste auf eine „Failover“-VM. Im Falle des Ausfalls der primären Seite, kann die Failover-Seite nahezu unterbrechungsfrei den Betrieb aufnehmen.

Eine kostengünstigere Alternative mit einer etwas höheren Wiederherstellungszeit und manuellen Eingriff bietet die Lösung „vSphere Replication“. Diese ist bereits in allen vSphere-Paketen ab der „Essentials Plus“-Variante mit Lizenziert. Weitere Details zu dieser Lösung finden sich im zweiten Abschnitt.

Szenario vier, bspw. verursacht durch einen Stromausfall im gesamten Datacenter, stellt eine Situation dar, in der zumeist der Betrieb des vCenter’s obsolet ist, da alle verwalteten Ressourcen auch ausgefallen sind.

vSphere Replication
Eine Replikation mit vSphere Replication unterscheidet sich gegenüber vCenter Server Heartbeat (nachfolgend Heartbeat genannt) grundlegend in zwei Merkmalen. Es findet entgegen Heartbeat eine Replikation von Speicherblöcken auf vSphere Hypervisor-Ebene statt und zusätzlich ist die Replikation nicht synchron. Im Unterschied zu Heartbeat kann diese Replikation aber für alle VM’s angewendet werden, da sie für das Betriebssystem transparent ist. VMware Heartbeat beschränkt zusätzlich nur auf Windows-Systeme.
vSphere Replication erlaubt eine periodische Replikation der geänderten Speicherblöcke einer VM in einem Abstand von 15 min bis zu 24 h, der sogenannten RPO (Recovery Point Objective). Dabei werden am Ende der Periodendauer mittels CBT (Changed Block Tracking) alle geänderten Blöcke aus dem CBT-Log auf eine „Failover“-Seite übertragen. Diese Mthode entlastet die Replikationsstrecke und ermöglicht kürzere Replikations-Zyklen.
Voraussetzung für die Replikation der vCenter-Komponenten sind zwei vCenter-Instanzen, die sich später idealerweise über Kreuz replizierten. Zusätzlich wird für beide vCenter-Instanzen jeweils eine vSphere Replication Appliance benötigt, die an das vCenter als vService gebunden wird. Beide vCenter müssen vSphere-Ressourcen verwalten, die später als Quelle und Ziel für die Replikationen dienen. Dabei werden die Blöcke einer VM vom ESXi-Host auf dem die VM ausgeführt zur vSphere Replication-Appliance des zweiten vCenters repliziert, die wiederum die Blöcke über einen ESXi-Host auf den gewählten Datastore der anderen Seite herunterschreibt. Nachfolgende Grafik soll dies verdeutlichen:
vSphere Replication architecture

Der Hauptgrund für das Vorhandensein einer zweiten vCenter-Instanz ist der Recovery-Prozess. Für die Inbetriebnahme der ausgefallenen VM’s ist das vSphere Replication-Plugin im Webclient nötig. Ist dies gegeben, lässt sich relativ einfach über den Webclient der Betrieb der VM’s wieder aufnehmen. Nutzt man man nur ein vCenter und eine vSphere Replication-Appliance kann man zwar die VM’s auf andere Datastores und Cluster replizieren, jedoch hat man das Henne-Ei-Problem, der Dienste die zum Wiederherstellen der VM’s gebraucht werden. Man sollte nicht unerwähnt lassen, dass solange die VM-Dateien (VMX, VMDK) vorhanden sind sich der Betrieb auch wieder per Hand aufnehmen lässt. Nur ist diese Möglichkeit wesentlich komplizierter und erfordert eine gut dokumentierte Anleitung.
vSphere Replication ist nicht auf Szenario drei begrenzt. Es eignet sich auch für Szenario eins. Hier kann die Replikation, der zu aktualisierenden VM’s auch pausiert werden, sodass etwaige Fehler nicht in das Replikat übertragen werden. In diesem Falle kann ein einfach Rollback über die Recovery-Funktion des vSphere Replication gemacht werden. Dies stellt eine weitere Alternative zu Snapshots dar.

Die Einrichtung sowie die spätere Konfiguration erfolgt ausschließlich über den vSphere Webclient. Über das Plugin, im vCenter „1“, lässt sich das gegenüberliegende „vCenter 2“ als zweite „Site“ hinzufügen und umgekehrt. Die Konfiguration der Replikation auf VM-Basis erfolgt über das Kontextmenü in der gewohnten Inventory-Sicht. Besonders zu erwähnen ist im Falle von SQL-Datenbankservern die VSS-Funktionalität. Mit dieser lassen sich die Datenbanken zum Zeitpunkt der Replikation in einen konsistenten Zustand versetzten. Der Status und die initiale Synchronisation der eingerichtete Replikation kann dann wieder über das vSphere Replication-Plugin im Webclient begutachtet werden. Nachfolgende Videos sollen die Installation und Konfiguration der Umgebung verdeutlichen.

Diese Lösung wurde durch VMware validiert und als „supported“ gekennzeichnet. VMware wird hierzu in Kürze ein Whitepaper/KB-Artikel veröffentlichen.Ausfallszenarien
Für ein Kunden-Datacenter galt es Lösungen für die Ausfallsicherheit des vCenter’s innerhalb eines Datacenters zu erarbeiten. Grundlegend gibt es vier Fehlerszenarien, die den Betrieb des vCenter unterbrechen können. Dabei wird jeweils der Betrieb des Applikationsservers mit allen vCenter-Komponenten (vCenter Server, Inventory Service, Orchestrator, SSO, Update Manager) sowie einer externen MSSQL-Datenbank angenommen. Alle Szenarien lassen sich aber ebenso für verteilte vCenter-Komponenten anwenden):

  1. Probleme auf Betriebssystem- und Software-Komponentenebene (Update)
  2. Ausfall oder Störung eines Blades im Enclosure
  3. Ausfall oder Störung des gesamten Enclosures
  4. Ausfall oder Störung des gesamten Datacenters

Szenario eins kann beispielsweise beim Einspielen von Windows Patches und dem Update von vCenter-Komponenten auf einen neuen Release-Stand eintreten. Hiergegen sollte man sich vor einem Update mit Backups der Datenbanken (SQL und ADAM) sowie einem zusätzlichen Snapshot der VM’s vor dem Update absichern.
Szenario zwei skizziert den Wegfall des ESXi-Host, der im dem Moment des Ausfalls die vCenter-VM(s) oder die Datenbank bzw. mehrere Komponenten ausführt. Um die Komponenten in diesen Fall möglichst schnell wieder in den normalen Betrieb zu überführen, sollte man auf ein, bei der Inbetriebnahme des Clusters aktiviertes, vSphere HA setzen, das nach dem Ausfall die VM’s des ESXi-Hosts auf anderen Hosts im Cluster neustartet insofern die nötigen Ressourcen vorhanden sind.
Für Szenario drei muss bei Blade-Umgebungen auf das vorliegende Cluster-Design geachtet werden. Erstreckt sich ein vSphere Cluster über mindestens zwei Blade-Enclosures bzw. Teile dieser Enclosure und nicht ausgefallenen Enclosure halten genug Failover-Kapazität (Admission Control) bereit, so lassen sich die ausgefallenen VM’s wie in Szenario zwei dort neustarten und so eine möglichst geringe Ausfallzeit garantieren. Bildet ein vSphere Cluster allerdings alle Blades eines Enclosures bzw. Teile dieses ab, so muss über eine andere Lösung zur schnellen Wiederaufnahme des Betriebs gesetzt werden, da vSphere HA in dieser Situation nicht greift. Erschwerend kann hier hinzukommen, dass die Datastores/LUN’s auf denen die entsprechenden VM’s liegen lediglich den ESXi-Hosts dieses Clusters präsentiert werden (z. B. Fibre Channel Zoning). Für dieses Szenario muss also eine Replikation der Daten auf ESXi-Host-Ebene (Block-based; Host based Replication) oder auf Applikationsebene erfolgen. Für beide Szenarien bietet VMware jeweils ein Produkt an. Beide Produkte nutzen das Shared Storage nicht für eine Array-basierte Replikation (z. B. EMC SRDF). VMware vCenter Server Heartbeat arbeitet auf Applikationsebene und spiegelt die Dienste auf eine „Failover“-VM. Im Falle des Ausfalls der primären Seite, kann die Failover-Seite nahezu unterbrechungsfrei den Betrieb aufnehmen. Eine kostengünstige Alternative mit einer etwas höheren Wiederherstellungszeit und manuellen Eingriff bietet vSphere Replication. Diese ist bereits in allen vSphere-Paketen ab der Essentials Plus-Variante mitlizenziert. Weitere Details zu dieser Lösung finden sich im zweiten Abschnitt.
Szenario vier, bspw. verursacht durch einen Stromausfall im gesamten Datacenter, stellt eine Situation dar, in der zumeist der Betrieb des vCenter’s obsolet ist, da alle verwalteten Ressourcen auch ausgefallen sind.

vSphere Replication
Eine Replikation mit vSphere Replication unterscheidet sich gegenüber vCenter Server Heartbeat (nachfolgend Heartbeat genannt) grundlegend in zwei Merkmalen. Es findet entgegen Heartbeat eine Replikation von Speicherblöcken auf ESXi-Host-Ebene statt und die Replikation ist nicht synchron. Im Unterschied zu Heartbeat kann diese Replikation für alle VM’s angewendet werden, da sie für das Betriebssystem transparent ist. Heartbeat beschränkt sich hier auf Windows-Systeme.
vSphere Replication erlaubt eine periodische Replikation der geänderten Speicherblöcke einer VM in einem Abstand von 15 min bis zu 24 h, der sogenannten RPO (Recovery Point Objective). Dabei werden am Ende der Periodendauer mittels CBT (Changed Block Tracking) alle geänderten Blöcke aus dem CBT-Log auf eine „Failover“-Seite übertragen. Dies entlastet die Replikationsstrecke und ermöglicht kürzere Replikations-Zyklen.
Voraussetzung für die Replikation der vCenter-Komponenten sind zwei vCenter-Instanzen, die sich später idealerweise über Kreuz replizierten. Zusätzlich wird für beide vCenter-Instanzen jeweils eine vSphere Replication Appliance benötigt, die an das vCenter als vService gebunden wird. Beide vCenter müssen vSphere-Ressourcen verwalten, die später als Quelle und Ziel für die Replikationen dienen. Dabei werden die Blöcke einer VM vom ESXi-Host auf dem die VM ausgeführt zur vSphere Replication-Appliance des zweiten vCenters repliziert, die wiederum die Blöcke über einen ESXi-Host auf den gewählten Datastore der anderen Seite herunterschreibt. Nachfolgende Grafik soll dies verdeutlichen:
vSphere Replication architecture
Der Hauptgrund für Vorhandensein einer zweiten vCenter-Instanz ist der Recovery-Prozess. Für die Inbetriebnahme der ausgefallenen VM’s ist das vSphere Replication-Plugin im Webclient nötig. Ist dies gegeben, lässt sich relativ einfach über den Webclient der Betrieb der VM’s wieder aufnehmen. Nutzt man man nur ein vCenter und eine vSphere Replication-Appliance kann man zwar die VM’s auf andere Datastores und Cluster replizieren, jedoch hat man das das Henne-Ei-Problem, da die VM’s gerade die Dienste enthalten, die zum Wiederherstellen der VM’s gebraucht werden. Man sollte nicht unerwähnt lassen, dass solange die VM-Dateien (VMX, VMDK) vorhanden sind sich der Betrieb auch wieder per Hand aufnehmen lässt, nur ist die wesentlich komplizierter und erfordert eine gut dokumentierte Anleitung.
vSphere Replication ist nicht auf Szenario drei begrenzt. Es eigenet sich auch für Szenario eins. Hier kann die Replikation der zu aktualisierenden VM’s auch pausiert werden, sodass etwaige Fehler nicht in das Replikat übertragen werden. In diesem Falle kann ein einfach Rollback über die Recovery-Funktion von vSphere Replication gemacht werden. Dies stellt nur eine weitere Alternative zu Snapshots dar.

Die Einrichtung sowie die spätere Konfiguration erfolgt ausschließlich über den vSphere Webclient. Über das Plugin im vCenter 1 lässt sich das gegenüberliegende vCenter 2 als zweite „Site“ hinzufügen und umgekehrt. Die Konfiguration der Replikation auf VM-Basis erfolgt über das Kontextmenü in der gewohnten Inventory-Sicht. Besonders zu erwähnen ist im Falle von SQL-Datenbankservern die VSS-Funktionalität. Mit dieser lassen sich die Datenbanken zum Zeitpunkt der Replikation in einen konsistenten Zustand versetzten. Der Status und die initiale Synchronisation der eingerichtete Replikation kann dann wieder über das vSphere Replication-Plugin im Webclient begutachtet werden. Nachfolgende Videos sollen die Installation und Konfiguration der Umgebung verdeutlichen.

Diese Lösung wurde durch VMware validiert und als „supported“ gekennzeichnet. VMware wird hierzu in Kürze ein Whitepaper/KB-Artikel veröffentlichen.

Ein Gedanke zu „Die Notwendigkeit von hochverfügbarem Management

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.