USV-Anlagen und die virtuelle Welt
Virtuell rechnen, reell sichern
In den Anfängen der IT-Virtualisierung sah man sie nur in vereinzelten Betrieben - die Host-Systeme. Und dann vielleicht auch nur ein oder zwei Host-Systeme mit wenigen installierten VMs. Bei ein oder zwei Hosts reichte es meist aus, die virtuellen Maschinen nacheinander herunterzufahren und zum Schluss dem Host-System einen Shutdown-Befehl zu senden. Bei der Systemvielfalt heute sollte dagegen auch die unterbrechungsfreie Stromversorgung in das Konzept einbezogen sein.
Die Entwicklung bleibt nicht stehen, und mittlerweile sind es mehrere Host-Systeme, die vielleicht auf mehrere Rechenzentren verteilt sind und mit hunderten virtuellen Maschinen arbeiten. Außerdem sind mittlerweile sowohl bei VMware als auch bei Hyper-V komplexere virtuelle Strukturen mit einem möglicherweise zentralen NAS entstanden. Durch die vielen Vorteile, die eine IT-Virtualisierung heute bietet, kommt sie zudem fast in jedem Unternehmen zum Einsatz.
Vmotion und Live-Migration eröffnen den Anwendern die Möglichkeit, alle virtuellen Maschinen eines Hosts, der in den Maintenance Mode versetzt wird, in Echtzeit und ohne Verluste auf einen anderen zu verschieben.
Doch die Annahme, dass die Software des USV-Anlagen-Herstellers, die zur Überwachung des USV-Status dient, bei Auftreten einer Störung nur alle Hosts des überwachten Rechenzentrums in den Maintenance Mode versetzen muss - den Rest übernimmt die Virtualisierug - ist falsch. Denn was passiert, wenn sich die USV-Anlage im anderen RZ nicht im Normalbetrieb befindet? Ein Verschieben der virtuellen Maschinen könnte nun zu Datenverlust führen. Immerhin besteht die Möglichkeit, dass auch diese Host-Systeme durch die Überwachungssoftware der dortigen USV-Anlage in den Maintenance Mode versetzt wurden.
Daraus ergibt sich die Notwendigkeit, vor der Aktivierung des Maintenance Modes den Status der USV-Anlage im anderen RZ abzufragen. Nur wenn deren Status "Normalbetrieb" lautet, ist der Maintenance Mode zu aktivieren. Andernfalls werden alle VMs und Hosts dieses RZs heruntergefahren.
Der verantwortliche Techniker sollte beachten, dass er eine Reihenfolge beim Herunterfahren einhalten sollte. Ungünstig wäre es zum Beispiel, wenn einer oder mehrere Domain-Controller zuerst abschalten würden. Daher ist eine Tabelle aller derjenigen VMs nötig, die in Abhängigkeit voneinander herunterfahren.
Die Konfiguration der Software bedingt einiges Wissen über die Architektur der virtuellen Umgebung, da der Administrator bestimmte Abhängigkeiten und Merkmale der Systemkomponenten berücksichtigen und während der Installation eingeben muss. Zunächst sind für alle Prozesse Administratorrechte erforderlich.
Damit sich das System bei einem Event richtig verhalten kann, muss in der Software eingetragen sein, ob ein Vcenter Server installiert ist. Ist dies nicht der Fall, kann der Prozess sofort zum Punkt "upsHostShutdown" übergehen und der Shutdown kann beginenn. Ist in der Software eingetragen, dass ein Vcenter Server installiert ist, dann muss auch festgelegt sein, ob Vmotion aktiviert ist. Wenn nicht, dann kann das System wiederum gleich zu "upsHostShutdown" verzweigen und der Shutdown eingeleitet werden.
Ist Vmotion aktiviert, dann muss die Software zunächst eine Abfrage starten, ob die USV-Anlage im anderen RZ im Normalbetrieb läuft. Ist diese nicht im Normalbetrieb, dann darf auf keinen Fall Vmotion starten, sondern der Prozess muss wieder zu "upsHostShutdown" verzweigen. Danach beginnt der Shutdown. Sind jedoch alle drei Abfragen positiv beantwortet, dann verzweigt der Prozess zu "upsHostMaintenance", und durch das Versetzen der Hosts in den Maintenance-Mode startet Vmotion.
Beschreibung des Skripts "upsHostShut-down":
Zuerst prüft das Skript, ob ein "Vcenter Server" konfiguriert ist. Nachfolgend die möglichen Abläufe im groben Überblick:
1. Ablauf bei vorhandenem Vcenter Server:
1.1. Das Skript ermittelt den Host, auf dem die VMA läuft, und trägt dessen Name in eine Variable ein.
1.2. Wurden abhängige VMs konfiguriert?
Wenn ja:
1.2.1. Die Tabelle wird eingelesen und alle darin eingetragenen VMs fahren der Reihe nach herunter.
1.3. Ist Vmotion aktiviert oder gibt es mehrere RZ?
Wenn ja:
1.3.1. Die Tabelle der konfigurierten Hosts wird eingelesen und alle auf ihnen befindlichen VMs werden heruntergefahren, außer es handelt sich um die VMA-VM. Da diese das Skript ausführt, darf sie nicht stoppen.
1.4. Alle VMs werden heruntergefahren, außer es handelt sich um die VMA-VM.
1.5. Alle Hosts werden heruntergefahren, außer es handelt sich um den VMA-Host.
1.6. Zuletzt fährt der VMA-Host herunter
ENDE
2. Ablauf bei nicht vorhandenem Vcenter Server:
2.1. Das Skript loggt sich in jeden Host, der mit "vifp addserver" hinzugefügt ist, ein und fährt alle darauf vorhandenen VMs herunter, außer es handelt sich um die VMA-VM. Da diese das Skript ausführt, darf sie nicht stoppen. Ist der aktuelle Host der VMA-Host, so wird sein Name in eine Variable geschrieben.
2.2. Alle Hosts werden herunter gefahren, außer es handelt sich um den VMA-Host.
2.3. Zuletzt fährt der VMA-Host herunter
ENDE
Beschreibung des Skripts "upsHostMain-tenance":
1. Das Skript ermittelt den Host, auf dem die VMA läuft, und trägt dessen Namen in eine Variable ein.
2. Alle Hosts in der Tabelle gehen in den Maintenance Mode, außer es handelt sich um den VMA-Host (siehe Punkt 1).
3. Danach geht der VMA-Host in den Maintenance Mode.
4. Zuletzt fährt die VMA-VM herunter.
Lesen Sie mehr zum Thema
