Übergeben der Shutdownkontrolle an RCCMD bei Verwendung eines vSAN

Dieser Artikel enthält Folgendes:

Erforderliche Zeitfenster aufgrund geänderter Abschaltsequenzen bei einer vSAN sicherstellen:

DRS innerhalb des vSAN-Clusters berücksichtigen

RCCMD für die vSAN vorbereiten

Sonderrolle: Der Witness-Server

Tutorial: Wenn ein Shutdown auf einer vSAN einmal abgebrochen werden muss …

Was ist beim Abbrechen eines vSAN-Shutdowns außerdem wichtig

Wie lang ist die geschätzte Abschaltzeit?

Bitte lesen Sie vor dem Start die folgenden Konfigurationshinweise sorgfältig, um Abschaltprobleme durch eine falsche Konfiguration von RCCMD zu vermeiden.

RCCMD kann vSAN-VMware-Umgebungen handhaben.

Da eine vSAN sehr komplex ist und die Betriebsbedingungen einer vSAN im Vergleich zu einem einzelnen Host oder einem Standard-Cluster abweichen, müssen einige Voraussetzungen erfüllt sein, bevor RCCMD eine vSAN herunterfahren kann:

Der vSAN verwaltende RCCMD-Client darf nicht innerhalb einer vSAN installiert sein.

Jeder Host einer vSAN muss in den Wartungsmodus versetzt werden, bevor er ausgeschaltet werden kann. Solange noch eine virtuelle Maschine läuft, ist es nicht möglich, die Hosts abzuschalten.

Das die vSAN verwaltende vCenter ist stets die erste und die letzte virtuelle Maschine.

Das vCenter ist die Steuereinheit einer vSAN. Es ist zulässig, das vCenter innerhalb der vSAN zu installieren oder auf einem einzelnen Host zu betreiben, der nicht Teil des Clusters ist. Die wesentliche Funktion des vCenters ist die Verwaltung der Datensynchronisation innerhalb einer vSAN, nachdem alle anderen virtuellen Maschinen heruntergefahren sind. Sie müssen sicherstellen, dass das vCenter diesen Vorgang abschließen kann.

Wenn Sie einen Witness-Server als virtuelle Maschine innerhalb einer vSAN betreiben.

Der Witness-Server hat eine Sonderaufgabe. Wenn zwei Hosts sich nicht einig sind, welcher Host die aktuellsten Daten hält, fragen sie den Witness-Server. Der Witness-Server verhält sich wie ein vollständiger Host, kann jedoch keine virtuellen Maschinen betreiben.

Aus diesem Grund kann der Witness-Server auch in der vSAN virtualisiert werden und dennoch als eigenständiger Host agieren. In diesem Fall müssen Sie zwischen der IP-Adresse des Witness-Servers und der virtuellen Maschine des Hosts unterscheiden, auf dem die virtuelle Maschine des Witness-Servers liegt.

Der Witness-Server wird regulär innerhalb des vSAN-Clusters heruntergefahren.

Der Host, der die virtuelle Maschine mit dem Witness-Server bereitstellt, benötigt einen zweiten RCCMD-Client, um den Wartungsmodus zu aktivieren, nachdem der Witness-Server ausgeschaltet wurde. Technisch kann ein RCCMD-Client nur die vSAN oder den Host, auf dem er läuft, steuern:

Wenn Sie also einen Einzelhost und einen vSAN-Cluster haben, benötigen Sie mindestens 2 RCCMD-Clients: RCCMD 1 verwaltet das Herunterfahren des vSAN-Clusters und RCCMD 2 verwaltet das Herunterfahren des Einzelhosts. Die Abschaltroutine wird dann in 2 unterschiedliche Befehle für den CS141 aufgeteilt:

• vSAN-Cluster herunterfahren
• Einzelhost herunterfahren

Da die beiden RCCMD-Clients parallel laufen:
Achten Sie bei der Wahl des richtigen Zeitfensters für Abschaltaufgaben darauf, dass die vSAN alle Hosts vollständig ausgeschaltet hat, bevor der letzte verbleibende Einzelhost abgeschaltet wird – andernfalls kann der RCCMD-Client, der das Herunterfahren der vSAN verwaltet, die Abschaltroutine möglicherweise nicht abschließen, weil der zweite RCCMD-Client ein lokales VM-Shutdown ausführt.

Hinweis: Appliance vs. Appliance – Was ist eine virtuelle Maschine und was ist der RCCMD-Client?

Beide Appliances sind im Kern gleich: Jede ist eine virtuelle Maschine. Da Sie jedoch zwei Appliances betreiben, unterscheidet sich der Name der virtuellen Maschine, auf der sie laufen. Die Angabe des VM-Namens verhindert, dass ein RCCMD-Client sich selbst voreilig herunterfährt.

Wenn Sie z. B. RCCMD 2 den Namen seiner eigenen virtuellen Maschine mitteilen, behandelt es RCCMD 1 als eine weitere virtuelle Maschine und fährt diese herunter. Bei Verwendung einer vSAN synchronisieren die Abschaltbefehle des CS141 das Abschaltverhalten beider Appliances.

Erforderliche Zeitfenster aufgrund geänderter Abschaltsequenzen bei einer vSAN sicherstellen:

Ziel bei der Nutzung einer vSAN ist es, die Ressourcenverfügbarkeit mit Datenredundanz zu kombinieren und zu maximieren. Das System eignet sich daher nicht gut für ein schnelles Herunterfahren ohne strenge Verfahren. Da ein systemweiter Komplett-Shutdown eher die Ausnahme ist, ist schwer abzuschätzen, wie viel Zeit das vCenter innerhalb einer vSAN benötigt, um alle Hosts in den Wartungsmodus zu versetzen.

Grundsätzlich verläuft ein vSAN-Shutdown in drei Schritten. 

Der zeitkritische Teil ist die Nachsynchronisationsphase, da diese Phase schwer abzuschätzen ist. 

Der Wartungsmodus kann erst erreicht werden, nachdem die Synchronisation der Daten zwischen allen Hosts abgeschlossen ist. Dieser Prozess ist dynamisch und ändert sich in Abhängigkeit von verfügbarer Hardware, der Anzahl virtueller Maschinen sowie Menge und Art der Daten innerhalb der VMs, die letztlich zwischen allen Hosts synchronisiert werden müssen. 

Erschwerend kommt hinzu, dass dieser Prozess innerhalb der vSAN stattfindet — irgendwann befinden sich die Hosts im Wartungsmodus, was bedeutet, dass der Prozess abgeschlossen ist.

Dem gegenüber steht die maximale Betriebszeit der USV. 

RCCMD benötigt klar definierte Zeitfenster für das Herunterfahren, die sich neben den berechneten Zeiten für einen Shutdown auch an der Betriebszeit der USV orientieren müssen. RCCMD benötigt daher ein reserviertes Zeitfenster, um das Herunterfahren durchzuführen:

• damit die IT rechtzeitig heruntergefahren werden kann,

• um einen Zeitpuffer bereitzustellen, falls sich die Nachsynchronisationsphase ändert,

• um Abschaltprozeduren innerhalb des Sicherheitsbereichs der Laufzeit der USV durchzuführen,

• um sicherzustellen, dass genügend Zeit bleibt, den Host außerhalb des Clusters herunterzufahren.

DRS innerhalb des vSAN-Clusters berücksichtigen

Entgegen landläufiger Meinung sind DRS und vCenter unabhängige Systemdienste, die lediglich miteinander kommunizieren. Es ist sogar möglich, einen HA-Cluster ohne DRS einzurichten, was jedoch nicht unbedingt sinnvoll ist, da der HA-Cluster DRS eigentlich impliziert.

Im Gegensatz zu einem HA-Cluster ist DRS in einer vSAN ein essenzieller Bestandteil, da dieser Dienst ungenutzte Speicherressourcen im Hintergrund erkennen und für eine virtuelle Maschine bündeln kann. Dieses intelligente Ressourcenmanagement in Echtzeit erlaubt den Betrieb von mehr virtuellen Maschinen als in einem normalen Cluster:

Virtuelle Maschinen, die nun diesen verteilten Zustand annehmen, sind besonders anfällig für einen hostbasierten Cluster-Shutdown, weil vCenter und DRS den Cluster-Shutdown nur dann sauber umsetzen, wenn ein Administrator dies explizit über das vCenter anweist.

Obwohl VMware ein Cluster-Herunterfahren über den Wartungsmodus empfiehlt, kann es sein, dass der DRS-Dienst die notwendigen Ressourcen für eine interne Migration von VM-Daten nicht sofort ermitteln kann, wenn die Hosts zu schnell in den Wartungsmodus versetzt werden, und es nach einer Art Warte­schleife erneut versucht. Virtuelle Maschinen, deren zugewiesener Speicher in diesem Fall entzogen wird, weil die Hardware nicht mehr verfügbar ist, sind akut von einem Ausfall betroffen. Ob und in welchem Umfang Betriebssystem und Daten beschädigt werden, hängt stark vom Speicherzustand und der Nutzung des Betriebssystems ab.

Das neue RCCMD Shutdown Management mit seiner angepassten Abschaltprozedur kann nicht nur sensible Systeme in voneinander abhängiger Weise herunterfahren, sondern auch wertvolle Systemressourcen sparen, sobald der allgemeine Shutdown greift.

Wichtig:

Eine Übersicht über das Zeitfenster, das die USV bereitstellen kann, ist für einen geordneten Shutdown zwingend erforderlich. Dies bestimmt nicht nur den konkreten Ablaufplan, sondern auch den spätesten Zeitpunkt für den Start des System-Shutdowns:

Das Herunterfahren einer vSAN ist aufgrund seiner technischen Natur ein sehr systemkritischer Prozess. Eine vSAN reagiert empfindlich, wenn sie nicht ordnungsgemäß heruntergefahren wird.

RCCMD für die vSAN vorbereiten

Aktivieren Sie unter VMware Settings „Hosts are also vSAN nodes“

Stellen Sie zur Verwaltung der Abschaltroutine sicher, dass sich die RCCMD-Appliance außerhalb des vSAN-Clusters befindet.

Nach Aktivierung des vSAN-Modus erhalten Sie zusätzliche Menüs:

Modus zur Außerbetriebnahme von vSAN-Knoten

Lassen Sie den Außerbetriebnahme-Modus auf „No data evacuation“ – dieser Modus ist die schnellste Methode, einen vSAN-Cluster herunterzufahren:

Die virtuellen Maschinen werden strukturiert heruntergefahren und anschließend werden alle Daten auf allen betroffenen Hosts synchronisiert.

Definition des vSAN-Resync-Timeouts

Anders als im Standardverfahren wird das vCenter nach dem Herunterfahren der virtuellen Maschinen aktiv und beginnt, sämtliche Datensätze innerhalb des Clusters zu synchronisieren.

Diese Nachsynchronisationsphase definiert die kritische Phase der Abschaltprozedur:

Alle Datensätze der virtuellen Maschinen müssen mit den auf anderen Hosts gespiegelt abgelegten Daten im Gleichklang sein.

Solange dieser synchrone Systemzustand nicht erreicht ist, kann kein Host in den Wartungsmodus wechseln.

 Hinweis:

Dieser Prozess ist stark dynamisch und hängt von der Art der zu synchronisierenden Daten ab. Das Erstellen mehrerer neuer VMs kann die Synchronisationszeit nur geringfügig beeinflussen. Es kann jedoch auch vorkommen, dass das Hinzufügen einer einzelnen VM die Nachsynchronisationszeit deutlich erhöht. Ebenso können Daten innerhalb einer VM durch die Nutzung organisch wachsen, was wiederum die benötigte Zeit beeinflusst.

Dieser Wert kann nicht einmalig bei der Erstinstallation als fester Wert definiert werden; er muss regelmäßig auf Aktualität überprüft und bei Bedarf angepasst werden.

Das vCenter nimmt sich für diesen Prozess die erforderliche Zeit. Leider steht diese relative Zeitspanne in direktem Gegensatz zu einem klar definierten Zeitfenster, das die USV im Notstrombetrieb bereitstellen kann. Sie müssen ein ausreichend großes Zeitfenster kalkulieren, um dem vCenter eine Zeitreserve zu geben, falls die berechnete Dauer nicht ausreicht.

Definition des Wartungsmodus für das vCenter.

Diese Einstellung definiert, wie viel Zeit dem vCenter bleibt, um sich nach der Datensynchronisation selbst herunterzufahren. Läuft das vCenter als VM innerhalb der vSAN, wird dieser Zeitpunkt interessant: Nach Ablauf dieses Zeitfensters werden die Hosts in den Wartungsmodus versetzt und das vCenter von seinem Host ausgeschaltet.

Daten für das die vSAN verwaltende vCenter eintragen

Da RCCMD sich über den gesamten Prozess mit dem vCenter abstimmen muss, sind die Zugangsdaten für das die vSAN verwaltende vCenter zwingend erforderlich.

Tragen Sie in diesem Konfigurationsdialog keine Anmeldedaten für einzelne Hosts ein.

Den die vSAN verwaltenden RCCMD-Client definieren:

RCCMD hat die Aufgabe, alle virtuellen Maschinen herunterzufahren und die Hosts am Ende auszuschalten. Da innerhalb eines vCenters nicht nur eine vSAN, sondern auch weitere Hosts abgebildet sein können, kann RCCMD diese ebenfalls herunterfahren. Es gibt zwei Ausnahmen, die besondere Beachtung benötigen:

Informationen über die virtuelle Maschine, auf der RCCMD läuft

Obwohl RCCMD selbst nicht in der herunterzufahrenden vSAN laufen darf, kann das die vSAN verwaltende vCenter weitere Hosts in seiner Liste führen. Die RCCMD-Appliance ist eine VM, die den Steuerbefehlen des Hosts, auf dem sie selbst läuft, Folge leisten muss – weist der Host das Herunterfahren an, führt die Appliance dies aus. Um zu verhindern, dass RCCMD sich versehentlich selbst einen Shutdown-Befehl erteilt, geben Sie den von Ihnen gewählten Namen der VM ein, auf der RCCMD läuft. Die VM mit diesem Namen wird dann vom Abschaltprozess ausgeschlossen.

Die VM definieren, die das die vSAN verwaltende vCenter enthält

Innerhalb des vSAN-Systems übernimmt das vCenter spezielle administrative Aufgaben, ist aber ebenfalls eine VM. Während des Shutdowns verschafft sich RCCMD zunächst einen Überblick über aktive VMs und fährt diese dann herunter, migriert sie usw. Mit dieser Einstellung weiß RCCMD, welche VM das vCenter ist, und fährt es exklusiv als letzte Maschine in der vSAN-Abschaltprozedur herunter.

Definition der vSAN-ESXi-Host-Knoten

Definieren Sie die Hosts, die von RCCMD heruntergefahren werden sollen. Die VMs können über das vCenter auf andere Hosts verschoben werden. Um einen Host herunterzufahren, benötigt RCCMD die folgenden Informationen:

HOST-/IP-Name

Wir empfehlen an dieser Stelle die IP-Adresse des Hosts zu verwenden, um Adressierungsprobleme zu vermeiden, wenn Teile der IT-Infrastruktur ausgefallen sind.

Da RCCMD Hostnamen unterstützt, können Sie alternativ auch einen Hostnamen eintragen.

Benutzer

Ein Benutzer mit den entsprechenden Systemrechten, um die VMware-Umgebung entsprechend herunterzufahren. Denken Sie daran, einen lokalen Host-Administrator mit Root-Rechten zu verwenden, um dem Shutdown-Befehl die erforderlichen Berechtigungen zu geben!

Passwort

Das dem Benutzer zugewiesene Passwort, mit dem sich RCCMD als berechtigt authentifizieren kann.

Abschaltverzögerung

Im nächsten Schritt wird festgelegt, wie viel Zeit RCCMD den VMs für das Herunterfahren einräumen soll, bevor der ESXi-Host alle Operationen beendet und ausschaltet:

Die vSAN besitzt gegenüber anderen Betriebsarten eine Besonderheit:

Die Abschaltdauer definiert typischerweise das Zeitfenster, das ein Host den Betriebssystemen innerhalb der VMs gewährt, bevor die VM einfach ausgeschaltet wird. Dabei spielt es keine Rolle, ob ein vCenter zuvor versucht hat, Maschinen zu migrieren oder nicht.

Wenn dieser Befehl an die in einer vSAN laufenden Hosts erteilt wird, gibt es keine VMs mehr, die ausgeschaltet werden müssen:

- Alle Hosts müssen sich im Wartungsmodus befinden

- Ein Host kann sich nur im Wartungsmodus befinden, wenn alle VMs verschoben oder ausgeschaltet sind.

Für die Hosts in der vSAN bedeutet dies, dass die Abschaltzeit der VMs auf 1 Sekunde gesetzt werden kann:

Die Abschaltroutine auf einer vSAN hat bereits alle Hosts in den Wartungsmodus gebracht. Folglich ist kein Zeitfenster erforderlich, um Betriebssystemen innerhalb einer VM Zeit für ein Herunterfahren einzuräumen.

Sonderrolle: Der Witness-Server

Kleine vSAN-Systeme verfügen nicht über die notwendigen Ressourcen, um alle Datenbestände eigenständig anpassen zu können.

Um Probleme bei der Datensynchronisation in minimalistischen vSAN-Systemen zu vermeiden, wird ein Witness-Server eingesetzt:

Dieser Witness-Server agiert in der vSAN als eigenständiger Host, ist jedoch nicht für das Hosten und Verwalten von VMs zuständig – sobald Hosts sich nicht über die Aktualität ihrer Datensätze einigen können, entscheidet der Witness-Server, welcher Host die Daten zu synchronisieren hat.

Der Witness-Server kann sowohl eine echte physische Maschine mit eigener Hardware sein als auch wie ein physischer Host agieren, jedoch in einer VM laufen. Die vSAN-Knoten erkennen keinen Unterschied zwischen den verschiedenen Setup-Strategien eines Witness-Servers. Dieser Unterschied wirkt sich jedoch auf die RCCMD-Konfiguration aus:

Wenn ein realer Witness-Server als eigenständige Maschine betrieben wird:

Weisen Sie in diesem Fall den Witness-Server und alle Hosts zu, die Sie herunterfahren möchten. Die Hosts wechseln entsprechend in den Wartungsmodus:

- VMs herunterfahren

- Das vCenter führt die Resynchronisation durch

- Die Hosts wechseln in den Wartungsmodus

- Die Hardware kann ausgeschaltet werden.

Beim Einsatz einer virtuellen Maschine zum Betrieb eines Witness-Servers

Wenn Sie den Witness-Server als VM in der vSAN betreiben, müssen Sie zwischen dem Host, auf dem der Witness-Server gespeichert ist, und dem Witness-Server als eigenständigem Host unterscheiden. Da der Witness-Server innerhalb der vSAN wie ein Host agiert, wird er entsprechend wahrgenommen und behandelt – die Art der Installation spielt keine Rolle:

Während der Host, der die VM des Witness intern bereitstellt, nur „irgendeine Art von System“ als VM wahrnimmt, akzeptiert er den Witness-Server im Netzwerk als eigenständigen Host und Netzknoten. Wenn nun die falsche IP-Adresse angegeben wurde, reagiert der für die VM zuständige Host korrekt:

- Der Host stoppt den Betrieb der VM

- Der Host wechselt in den Wartungsmodus

Da der (wenn auch virtualisierte) Witness-Server jedoch einen vollwertigen Host und Netzknoten darstellt, muss er folglich wie ein echter Host behandelt und vor dem Ausschalten in den Wartungsmodus versetzt werden. Formal benötigen Sie zwei RCCMD-Appliances, um eine vSAN herunterzufahren. Wenn Sie einen virtualisierten Witness-Server verwenden, können Sie den zweiten RCCMD nutzen, um regelmäßig den Host auszuschalten, der den virtuellen Witness-Server verwaltet.

Tutorial: Wenn ein Shutdown auf einer vSAN einmal abgebrochen werden muss …

Ein normaler ESXi-Cluster mit vCenter unterscheidet sich von einer vSAN:

Während ein normaler Cluster mit einzelnen Hosts letztlich seine VMs eigenständig herunterfahren und ausschalten kann, wenn der Wartungsmodus nicht möglich ist, kann eine vSAN nur dann ausgeschaltet werden, wenn absolut keine VMs außer dem vCenter auf der vSAN laufen. Der zweite große Unterschied ist, dass der die vSAN verwaltende RCCMD-Client logischerweise nicht innerhalb des vSAN-Clusters laufen kann – er muss ihn von außen steuern. Der dritte Punkt ist, dass die vSAN nach dem Herunterfahren aller VMs eine Nachlaufzeit benötigt, in der alle Bestandsdaten synchronisiert werden; erst dann dürfen die Hosts sicher ausgeschaltet werden.

Aufgrund dieser Unterschiede gibt es logische Abschnitte, zwischen denen das Abbrechen der Abschaltsequenz durchaus möglich ist. Dieses Tutorial zeigt eine Möglichkeit, wie ein automatischer Shutdown abgebrochen werden könnte. Bitte beachten Sie: Dies ist nicht die beabsichtigte Verwendung von RCCMD, und Sie handeln auf eigenes Risiko …

In diesem Beispiel sind die Rahmenbedingungen erfüllt, die einen Betrieb ohne Witness-Server erlauben:

Problem:

Sobald ein Stromausfall eintritt, wird RCCMD 1 aktiv und startet rechtzeitig den Abschaltvorgang. Messungen haben ergeben, dass der gesamte Shutdown etwa 38 Minuten dauert. Da die USV bis zu 45 Minuten abdecken kann, muss der Shutdown daher spätestens nach 5 Minuten initiiert werden, andernfalls kann das System nicht korrekt heruntergefahren werden. Mit einem Zeitfenster von 20 Minuten ergibt es sich nun, dass die Netzversorgung zurückkehrt und ein weiteres Herunterfahren nicht mehr notwendig ist.

Da die RCCMD-Appliance definitionsgemäß die Abschaltsequenz nicht zurücknehmen oder stoppen kann, wird RCCMD 1 diese auch zu Ende führen und die vSAN sauber herunterfahren. Der CS141 kann kein „clear all pending commands“-Signal an RCCMD 1 senden.

Grundsatzentscheidung treffen

Da die USV bereits 20 Minuten gelaufen ist, hätte ein weiterer Netzausfall voraussichtlich fatale Folgen. Es sollte daher erwogen werden, ob ein Herunterfahren mit anschließendem Warten bis zur minimalen 40-minütigen Sperrzeit oder ein Abbruch des Shutdowns eine Option ist. Die Befehle sind an diesem Punkt identisch, aber das Ereignis ändert sich. In diesem Beispiel wurde ein Abbruch des Shutdowns gewählt. Wie der Shutdown wird auch die Beendigung über den CS141 ausgelöst – nur mit dem Ereignis „Power Restored“.

Wichtig ist stets: Der Shutdown selbst ist bereits eine Notmaßnahme – über einen erzwungenen Abbruch der Notmaßnahme nachzudenken, ist legitim, aber immer mit zusätzlichen Risiken verbunden.

Die Abschaltsequenz unterbrechen

Beim Ereignis „Power restored“ wird ein Shutdown-Signal an RCCMD 2 angelegt – das den letzten Einzelhost herunterfahren soll – einschließlich des sofortigen Herunterfahrens aller VMs. RCCMD 1 wird sich als VM an diese Vorgabe halten und entsprechend herunterfahren und ausschalten – und dabei vergessen, dass noch gültige Steuerbefehle ausstehen, die die vSAN betreffen.

Das vCenter verarbeitet die letzten Befehle und wartet anschließend entsprechend auf weitere Anweisungen. Da die Steuerbefehle an Zeitfenster gebunden sind, die in RCCMD 1 hinterlegt wurden, lässt sich so schnell herausfinden, was bereits erledigt wurde.

1. vMotion ist aktiv und versucht standardmäßig, die VMs zu verschieben.
2. vSAN-Shutdown ist aktiv und die VMs werden heruntergefahren oder verschoben.
3. Die Nachsynchronisationsphase läuft.

Dieses Verfahren beendet die aktuell laufende Phase, und wenn anschließend kein neuer Befehl eingeht, verbleibt die vSAN in diesem Systemzustand und wartet auf weitere Anordnungen.

Strukturierter Neustart: RCCMD-Schutz reaktivieren

Senden Sie das WOL-Signal an den ESXi-Einzelhost – er startet über das WOL-Signal, und entsprechend starten auch die RCCMD-Appliances und nehmen ihre Ausgangsposition ein. Der RCCMD-Schutz ist nun aktiv.

Start der stromlosen Hosts

Senden Sie nun ein WOL-Signal an jeden einzelnen Host – es spielt keine Rolle, ob dieser Host bereits ausgeschaltet wurde oder nicht: Läuft der Host, verpufft das WOL-Signal wirkungslos und wird am Ziel ignoriert.

Start der virtuellen Maschinen (VMs)

Je nach Systemkonfiguration können VMs, die ausgeschaltet wurden, per WOL-Signal gestartet werden. Senden Sie dazu ein WOL-Signal an die MAC-Adresse der jeweiligen VM.

Hinweis:
Beachten Sie, dass WOL-Signale an die MAC-Adresse gesendet werden; der CS141 muss sich im selben Netzwerksegment befinden oder das Signal muss entsprechend geroutet werden.

Da Sie die zeitliche Steuerung frei definieren können, ist es sogar möglich, eine besondere Reihenfolge festzulegen, in der VMs starten. So kann das Basisnetzwerk automatisch hochfahren.

Was ist beim Abbrechen eines vSAN-Shutdowns außerdem wichtig

Starten Sie den RCCMD-Client nicht einfach über die Weboberfläche neu

RCCMD verfügt über einen Schutzmechanismus, der einen gültigen Shutdown auch dann ausführt, wenn jemand den RCCMD-Dienst über die Weboberfläche stoppt, nachdem der Shutdown ausgelöst wurde. Das System wird dennoch sauber heruntergefahren und ausgeschaltet. Deshalb müssen Sie die verwaltende RCCMD-Appliance herunterfahren – ein Klick auf „restart“ in der Weboberfläche unterbricht den Vorgang nicht.

Eine vSAN kann das Zeitfenster ändern und erfordert daher möglicherweise eine regelmäßige Anpassung der Zeitparameter:

Abhängig von der aktuellen Datensituation und dem Ausbaugrad der vSAN kann sich dieser Shutdown sehr in die Länge ziehen, und das Verfahren muss entsprechend früh gestartet werden. Wenn während dieser Zeit die Netzversorgung oder ein Notstromaggregat verfügbar wird, ändert dies nichts an der Abschaltroutine – RCCMD folgt einer Anweisung und organisiert deren Umsetzung.

Und natürlich gilt: Wenn ein laufender Shutdown gestoppt werden muss …

Dieser Prozess lässt sich am Ende nicht vollständig automatisieren, da RCCMD die Anweisungen und deren Zeitfenster koordiniert, aber vom vCenter keine Rückmeldungen über logische Abschnitte erhält. Daher muss ein Administrator abwägen, ob der Shutdown bis zum Ende durchlaufen und das System anschließend neu gestartet wird oder ob ein Abbruch innerhalb einer Abschaltroutine provoziert wird:

Beides hat jeweils Vor- und Nachteile.

Um den Shutdown-Prozess zu stoppen und die zugehörigen Skripte wieder auf 0 zu setzen, stoppen Sie die Appliance-VM auf dem Host. Sobald dies geschieht, werden keine weiteren Befehle an die Hosts übertragen und das System beendet den Shutdown-Prozess, nachdem der letzte Befehl erfolgreich übermittelt wurde. Sie sparen möglicherweise Zeit, aber ein klarer Neustart kann für manche Server-Operationen auch der bessere Weg sein.

WICHTIG:
Stellen Sie für einen Abbruch des Shutdowns sicher, dass die VM durch die Appliance heruntergefahren wird – auch wenn Sie RCCMD in der Weboberfläche auf „Stop“ setzen und der Dienst laut Weboberfläche gestoppt wurde.
Die Abschaltsequenz wird dennoch ausgeführt.

Wie lang ist die geschätzte Abschaltzeit?

Grundlegende Abschaltzeit

Nach Eingabe aller Daten wird eine geschätzte Zeit angezeigt, die RCCMD für einen vollständigen Shutdown benötigen könnte.

Sie sehen die geschätzte Abschaltzeit unterhalb der ESXi-Host-Einstellungen.

Bitte beachten Sie, dass dieser Wert eine anhand der eingegebenen Daten berechnete Richtgröße ist.

Dieser Wert soll Ihnen helfen, den optimierten Auslösezeitpunkt für einen Notfall-Shutdown zu finden, falls ein Stromausfall auftritt.

Hinweis:
Jede USV kann nur ein vordefiniertes Zeitfenster Notstrom bereitstellen. Wenn die Batterien entladen sind, schaltet sich die USV selbst ab, um die Batterien nicht zu beschädigen. Im Allgemeinen hilft es nicht, wenn Sie in RCCMD lediglich mit Zahlen „spielen“, bis die geschätzte Abschaltzeit mit dem Datenblatt der USV übereinstimmt:

Darüber hinaus sind diese Werte nur eine Momentaufnahme Ihres Systems, basierend auf den von Ihnen eingegebenen Daten! Bitte prüfen Sie regelmäßig, ob die eingetragenen Werte im Notfall den tatsächlichen Abschaltbedingungen entsprechen.

Beachten Sie, dass sich zwischen zwei Shutdown-Tests die Abschaltbedingungen ändern können. Bei der Berechnung und Anpassung der durchschnittlichen Abschaltzeit empfehlen wir, etwas mehr Zeit als die erforderliche Mindestzeit einzuplanen.