Einstieg in RCCMD mit Windows PowerShell und Hyper-V

Dieser Artikel beinhaltet folgendes:

Fall 1: Das Stand-alone Betriebsszenario ohne interne Abhängigkeiten:

Fall 2: Interne Abhängigkeiten für virtuelle Server auf einem Hyper-V

Shutdown Befehlskette mit RCCMD auf einem Hyper-V mit 3 virtuellen Maschinen

Wie Sie die Shutdown.bat in RCCMD anpassen:

Eine Einführung in Hyper-V

HYPER-V ist Microsofts Virtualisierungstechnologie, mit der nicht nur einzelne Workstations, sondern auch komplette Serverinfrastrukturen innerhalb einer virtuellen Umgebung betrieben werden können. Der Unterschied zu VMware besteht darin, dass es bei Hyper-V kein komfortables vCenter gibt, sondern direkt über PowerShell und Skripte bzw. Skriptbefehle administriert wird. Dadurch ergeben sich ganz eigene Vor- und Nachteile.

Fall 1: Das Stand-alone Betriebsszenario ohne interne Abhängigkeiten:

Es gibt eine beliebige Anzahl an Hyper-V Servern, die nicht miteinander verbunden sind. Theoretisch wäre es hier sogar möglich, die gesamte Hyper-V Umgebung mit einem RCCMD Client und den passenden Skripten herunterzufahren, das ist in dieser Konstellation aber nur bedingt zu empfehlen, da das Vertrauensverhältnis zwischen den Servern sehr sensibel reagiert, sobald versucht wird, ein Skript von einem Knoten auf einem anderen auszuführen.

Sinnvoller ist es hier, auf jedem Hyper-V Knoten einen eigenen RCCMD Client zu installieren, der die notwendigen Skripte direkt mit lokalen Administratorrechten ausführt (in einem Failover Cluster ändern sich die Spielregeln ein wenig, dazu später mehr).

Wenn Sie einen Hyper-V Server lokal in seiner Standardkonfiguration herunterfahren, werden die virtuellen Maschinen angehalten, der jeweilige Betriebszustand wird gespeichert und anschließend der Hauptserver heruntergefahren. Beim nächsten Start werden die Betriebsdaten wieder geladen und der Server arbeitet weiter. Ob Anhalten und Speichern funktioniert, hängt davon ab, was in der virtuellen Maschine läuft:

• Speicherabbilder können sehr groß werden

Es kann passieren, dass der verfügbare Speicherplatz auf dem Hauptserver nicht ausreicht, um die Betriebsdaten aller virtuellen Maschinen aufzunehmen.

• Durch das Programm nicht möglich.

Buchungssysteme, Renderingsysteme, Programme mit speziellen Shutdown Routinen usw. Es gibt viele Anwendungen, die bei einem Shutdown gezielt und sauber beendet und heruntergefahren werden müssen.

Einen sauberen Shutdown einleiten

Erhält RCCMD die Anweisung von einem CS141 / BACS System, gibt es dem lokalen Rechner den Shutdown Befehl, hat jedoch keinen Einfluss darauf, was mit den virtuellen Maschinen passiert, wenn das Hostbetriebssystem die Shutdown Prozedur startet.

Wenn Sie Windows PowerShell nicht installiert oder deaktiviert haben, können Sie die Shutdown Kontrolle an den Hyper-V Manager übergeben und dort einstellen, was beim Herunterfahren des Servers passieren soll:

Zustand der virtuellen Maschine speichern

Im Shutdown Fall wird ein vollständiger Speicherabbild erstellt. Bitte prüfen Sie zwei Dinge: Erstens, ob der Server genügend Speicherplatz bereitstellen kann, und zweitens, ob die Programme innerhalb der virtuellen Maschine diese Funktion generell unterstützen.

Virtuelle Maschine ausschalten

Das klassische harte Ausschalten der virtuellen Maschine kann je nach Betriebssystem und Nutzung zu verschiedenen Problemen führen.

Gastbetriebssystem herunterfahren

Das Betriebssystem innerhalb der virtuellen Maschine wird angewiesen, sich selbst herunterzufahren.

Fall 2: Interne Abhängigkeiten für virtuelle Server auf einem Hyper-V

Im Grunde handelt es sich hier um die logische Erweiterung von Fall 1: Was passiert, wenn mehrere virtualisierte Systeme auf einem Hyper-V Knoten laufen, die voneinander abhängig sind oder eine spezielle Reihenfolge beim Herunterfahren benötigen?

Hier wird der Unterschied zu VMware deutlich: Anstelle eines grafischen Administrationsmenüs, wie es bei VMware verwendet wird, setzt Hyper-V auf PowerShell, um solche Konfigurationen umzusetzen.

In diesem Beispiel laufen nun 3 virtuelle Systeme:

Wenn Sie den Hyper-V herunterfahren würden, würden alle 3 Betriebssysteme auf jeden Fall herunterfahren. Zwei werden heruntergefahren, während Windows 7 „speichert und beendet“. Für Anwender macht PowerShell das Ganze relativ einfach:

Mit dem Befehl Get-VM erhalten Sie zunächst eine Übersicht über alle aktuell laufenden virtuellen Maschinen:

Die Maschinen können dann mit dem Befehl Stop-VM [machine name] heruntergefahren werden:

Um individuelle Shutdown Abläufe umzusetzen, bietet RCCMD 3 Befehle, mit denen Sie einen strukturierten Server Shutdown realisieren können:

• Hyper-V VM herunterfahren: Eine VM benennen, die heruntergefahren werden soll.
• Einige Sekunden warten: Ein Zeitfenster bis zum nächsten Job definieren.
• Alle Hyper-V VMs herunterfahren: Alle virtuellen Maschinen herunterfahren.
• System herunterfahren: Den Server herunterfahren.

Mit der korrekten Reihenfolge und passenden Zeitfenstern können Sie alle virtuellen Maschinen strukturiert herunterfahren und anschließend den Server ausschalten.

Die einzige Voraussetzung: Windows PowerShell muss installiert und aktiviert sein.

Hyper-V mit Clustermanagement (PowerShell wird benötigt)

Die Kommunikation in Hyper-V ist sehr strukturiert aufgebaut, sodass RCCMD ohne weitere Probleme betrieben werden kann:

Die übergeordnete Instanz wird immer zuerst informiert und entsprechend auf die Freigabe gewartet. Im Fall eines Shutdowns über RCCMD bedeutet das, dass das Betriebssystem den Shutdown in Hyper-V ankündigt. Hyper-V organisiert daraufhin das strukturierte Herunterfahren der virtuellen Maschinen. Das Trägersystem wird anschließend heruntergefahren.

Gibt es einen Hyper-V Cluster Manager, informiert Hyper-V zuerst diesen. Der Cluster Manager kommuniziert mit den anderen Cluster Managern und organisiert die Migration der virtuellen Maschinen. Sobald alle Maschinen auf einen anderen Server verschoben wurden, speichert Hyper-V die verbleibenden virtuellen Maschinen und fährt sie herunter. Erst danach wird das Trägersystem normal heruntergefahren.

Geplanter vs. ungeplanter Failover – Vorbereitung auf einen gleichzeitigen Shutdown auf 2 Hosts

Komplizierter wird es, wenn Sie im Falle eines Stromausfalls beide Knoten (oder Hosts) herunterfahren möchten:

Dazu müssen Sie verstehen, wie virtuelle Maschinen zwischen zwei Knoten migrieren:

Bei zwei Knoten gibt es Zugriff auf den VM Speicher, Kommunikation zwischen den Clusterknoten und einen Witness Server, über den beide Knoten bestimmen, wer das sogenannte „Quorum“ hält, also wer den aktuelleren Betriebszustand zur Verfügung stellt.

In einem Failover Cluster wird in der Regel ein primärer Server konfiguriert, auf dem die VM laufen soll, und ein Gast, auf dem sie aktuell laufen kann. In einem Failover Cluster wird die VHD Datei, die für den virtuellen Server zuständig ist, repliziert und an den registrierten Gast übertragen und regelmäßig mit aktuellen Betriebsdaten abgeglichen. Der ausführende Knoten sendet die Daten dabei an seine registrierten Partner:

• Im Fall eines geplanten Failovers (zum Beispiel einer Live Migration oder dem Herunterfahren eines der beiden Knoten) bekommt der Cluster Manager genügend Zeit, seine Betriebsdaten zu übertragen, und erst anschließend wird der Shutdown durchgeführt.
• Bei einem ungeplanten Failover wird der letzte verfügbare Stand zugrunde gelegt, sodass ein gewisser Datenverlust auftreten kann.
• Wenn beide Knoten ungeplant „down“ gehen, gilt gemäß Quorum der letzte gespeicherte Betriebszustand, der noch verfügbar ist.

Das Problem steckt im Detail:

Die Standardkonfiguration eines Failover Clusters geht nicht davon aus, dass beide Knoten geplant herunterfahren. Bei einem geplanten Shutdown durch das Betriebssystem sind ungefähr 120 Sekunden eingeplant, bevor sich das Betriebssystem herunterfährt, damit die Betriebsdaten aktualisiert und die virtuelle Maschine auf einen anderen Knoten verschoben werden kann. Der Haken: Wenn beide Knoten zum gleichen Zeitpunkt herunterfahren sollen, entsteht zwangsläufig ein Interessenkonflikt: Knoten A versucht, alle seine Maschinen und Betriebsdaten auf Knoten B zu verschieben, und umgekehrt. Das kann dazu führen, dass Maschinen im „Nirgendwo“ hängen bleiben und dann beim Shutdown des Betriebssystemknotens abrupt abgewürgt werden. Abhängig von Größe und Komplexität gibt es unterschiedliche Vorgehensweisen:

Beispiel: Der sehr einfache Fall

Im einfachen Fall gibt es zwei Knoten, die zusammen einen Failover Cluster bilden, und beide Knoten könnten alle virtuellen Maschinen hosten (oder einzelne Maschinen sind von der Migration ausgeschlossen). Wenn Sie PowerShell nicht installiert oder aktiviert haben, fahren Sie die Knoten nacheinander herunter: Knoten A überträgt seine Daten an Knoten B, übergibt die virtuellen Maschinen und fährt dann herunter. Danach stellt Knoten B fest, dass der Cluster zusammengebrochen ist (Knoten A ist bereits aus oder im Shutdown) und wird gar nicht erst versuchen, die virtuellen Maschinen zu migrieren. Mit dem RCCMD Befehl „Shut down all virtual machines“ können dann alle virtuellen Maschinen heruntergefahren und der Server ausgeschaltet werden.

Empfehlung: Shutdown über PowerShell

Um individuelle Shutdown Abläufe umzusetzen, bietet RCCMD 3 Befehle, mit denen Sie einen strukturierten Server Shutdown realisieren können:

• Hyper-V VM herunterfahren: Eine VM benennen, die heruntergefahren werden soll.
• Einige Sekunden warten*: Ein Zeitfenster bis zum nächsten Job definieren.
• Alle Hyper-V VMs herunterfahren: Alle virtuellen Maschinen herunterfahren.
• Einige Sekunden warten*: Zeitfenster für die virtuellen Maschinen.
• RCCMD Shutdown Relay: Senden des Shutdowns an den 2. Knoten**
• System herunterfahren: Den Server herunterfahren.

*Definieren Sie die Zeitfenster so, dass die virtuellen Maschinen genügend Zeit haben, um sich selbst herunterzufahren und auszuschalten. Ob die virtuellen Maschinen gespeichert oder heruntergefahren werden, legen Sie in den Eigenschaften der virtuellen Maschine fest.

**Auf dem zweiten Server benötigen Sie nur den Job „System herunterfahren“, da alle virtuellen Maschinen bereits sauber heruntergefahren wurden und nur noch der Server ausgeschaltet werden muss.

Advanced: Eigene Hyper-V Befehle für das Herunterfahren virtueller Maschinen auf mehreren Knoten und Quorum erstellen

Die folgenden Befehle setzen die Installation/Aktivierung von PowerShell voraus:

PowerShell hat sich als zentrale Komponente in der Microsoft Umgebung etabliert und ist für Administratoren und Entwickler gleichermaßen unverzichtbar. Die Automatisierung administrativer Aufgaben durch Skripte ermöglicht ein effizienteres und zeitsparenderes Arbeiten. PowerShell 7 / Core erweitert die Möglichkeiten der Skripterstellung und Ausführung um neue Funktionen, die speziell auf die Serveradministration zugeschnitten sind. Die plattformübergreifende Verfügbarkeit und die Integration mit anderen Microsoft Produkten machen PowerShell zu einem universellen Werkzeug zur Automatisierung und Optimierung von IT Prozessen.

Aktuell sind folgende Versionen im Umlauf:

Windows Server 2012 R2: PowerShell 3.0 ist vorinstalliert, aber standardmäßig nicht aktiviert.

Windows Server 2016: PowerShell 5.1 ist standardmäßig installiert und aktiviert.

Windows Server 2019: PowerShell 5.1 ist standardmäßig installiert und aktiviert.

Windows Server 2022: PowerShell 7.0 ist standardmäßig installiert und aktiviert.

Hinweis:

Windows Server 2012 und frühere Versionen enthalten PowerShell nicht standardmäßig. Sie können PowerShell auf diesen Systemen jedoch manuell installieren.

Die aktuelle Version von PowerShell kann jederzeit auf jedem Windows System manuell installiert werden, unabhängig von der Serverversion.

Nachdem Sie PowerShell installiert haben, können Sie zwei spezielle Hyper-V Befehle nutzen, die RCCMD zur Verwaltung virtueller Maschinen innerhalb einer Hyper-V Umgebung anbietet:

Eine spezifische Hyper-V VM herunterfahren

Mit diesem PowerShell Befehl können Sie eine bestimmte virtuelle Maschine herunterfahren. Der Name der virtuellen Maschine wird im Eingabedialog angegeben.

Es gibt hier zwei unterschiedliche Anwendungsfälle:

1. Lokaler Hyper-V

Der lokale Hyper-V Manager fährt genau diese eine VM herunter und beendet sie.

2. RCCMD ist auf dem Cluster Manager installiert

Wenn der Cluster Manager aktiv ist, wird dieser Befehl in das Hyper-V Netzwerk übertragen, und der Knoten, auf dem die VM aktuell läuft, führt den Befehl aus.

Wenn die virtuelle Maschine auf einen Knoten migriert, der nicht Teil dieses Clusters ist, wird die Maschine nicht mehr heruntergefahren, selbst wenn der Cluster Manager weiß, wo sich die virtuelle Maschine aktuell befindet.

Alle virtuellen Maschinen herunterfahren

Der Unterschied zu einer einzelnen virtuellen Maschine besteht darin, dass der Hyper-V Manager eine Liste aller virtuellen Maschinen mit dem Status „running“ abfragt und sie anschließend mit dem Befehl „Stop-VM“ herunterfährt.

Auch hier gibt es zwei Anwendungsmöglichkeiten:

1. Lokaler Hyper-V (ohne Cluster Manager)

In diesem Fall werden alle lokal laufenden virtuellen Maschinen strukturiert heruntergefahren und ordnungsgemäß beendet.

2. Auf dem Cluster Manager

Der Cluster Manager fragt alle virtuellen Maschinen ab, die den Status „running“ haben. Mit dem Stop-VM Befehl werden diese virtuellen Maschinen im Cluster regulär heruntergefahren und beendet.

Tipp: Hyper-V arbeitet kontextbezogen

Diese beiden Befehle ermöglichen einen strukturierten Shutdown aller virtuellen Maschinen auf einem Hyper-V Server oder eines gesamten Hyper-V Clusters. Was konkret ausgeführt wird, hängt stark vom jeweiligen Kontext ab.

Shutdown Befehlskette mit RCCMD auf einem Hyper-V mit 3 virtuellen Maschinen

Auf einem einzelnen Hyper-V Server

In dieser Konstellation wird auf jedem Windows Host ein separater RCCMD Client benötigt. Der Shutdown wird lokal ausgelöst und die virtuellen Maschinen sollen heruntergefahren werden:

1. Hyper-V VM herunterfahren

Dies wäre zum Beispiel der Management Server, der vor dem Datenbankserver heruntergefahren werden muss. Geben Sie den Namen der virtuellen Maschine ein, den Sie bei der Erstellung vergeben haben.

2. Einige Sekunden warten

In diesem Beispiel wurden 90 Sekunden eingetragen. RCCMD gibt dem Betriebssystem also 90 Sekunden Zeit, bevor der nächste Eintrag in der Liste gestartet wird.

3. Alle Hyper-V VMs herunterfahren

RCCMD fordert den Hyper-V Manager auf, alle virtuellen Maschinen mit dem Status „Running“ aufzulisten und weist den Hyper-V Manager an, die Betriebssysteme herunterzufahren.

4. Einige Sekunden warten

Geben Sie den Betriebssystemen Zeit, den Shutdown zu organisieren und die virtuellen Maschinen geordnet zu beenden.

5. System herunterfahren

Der Hyper-V PC fährt herunter und der Server schaltet sich aus. Bitte beachten Sie, dass dieser Befehl die noch laufenden virtuellen Maschinen hart ausschaltet. Planen Sie unter Punkt 5 ein entsprechend großes Zeitfenster ein.

Wenn Sie eine VM betreiben, die eine spezielle Shutdown Routine benötigt

Leiten Sie vorbereitend das RCCMD Signal direkt an das Betriebssystem der entsprechenden virtuellen Maschine weiter und verzögern Sie den Shutdown um ein passendes Zeitfenster. In diesem Fall konfigurieren Sie den individuellen Shutdown innerhalb des RCCMD Clients, an den Sie den Shutdown weitergeleitet haben.

Bitte beachten Sie, dass für diese Funktion auf dem Gastsystem ein RCCMD Client installiert sein muss.

In diesem Fall wird ein Gastsystem zunächst angewiesen, herunterzufahren, bevor der oben beschriebene lokale Shutdown greift.

Für einen Hyper-V Cluster mit mehreren Knoten und Cluster Manager

Wenn es mehrere Knoten mit einem Cluster Manager gibt, ist es wichtig, von wo die Shutdown Befehle kommen: Ein einfaches lokales Herunterfahren von Knoten in einem Cluster ist nicht zu empfehlen, da dies zu Datenverlust und Schäden an den auf dem Knoten laufenden virtuellen Maschinen sowie dem Betriebssystem führen kann. Das Problem verstärkt sich mit der Anzahl der Knoten, die einfach heruntergefahren werden.

In diesem Fall wird empfohlen, den Cluster Manager zu nutzen, der – im Gegensatz zu VMware zum Beispiel – als Dienst auf jedem Knoten läuft: Sie können daher für jeden Knoten, der Mitglied des Clusters ist, einen strukturierten Cluster Shutdown einleiten.

Wichtig ist dabei nicht, von welchem Knoten der Cluster Manager seine Befehle erhält, sondern in welcher Reihenfolge die Befehle eingegeben werden:

1. Alle Hyper-V VMs herunterfahren

Get-VM | Where-Object {$_.State -eq "Running"} |Stop-VM

Der Cluster Manager fordert alle virtuellen Maschinen mit dem Status „running“ von den Knoten in diesem Cluster an und organisiert einen lokalen Shutdown.

2. Clusterstatus sichern:

Save-ClusterCheckpoint <Production_1>

Dieser Befehl sichert den Zustand des Clusters, damit er bei Bedarf später wiederhergestellt werden kann.

3. Cluster stoppen und Knoten lokal herunterfahren

Get-ClusterNode | Where-Object {$_.State -eq "Up"} |Stop-ClusterNode

Nachdem alle virtuellen Maschinen heruntergefahren wurden, können Sie den Hyper-V Cluster sicher stoppen und die Knoten mit Stop-ClusterNode herunterfahren.

Tipp: Achten Sie auf geladene Module

Einige Befehle können nur ausgeführt werden, wenn die entsprechenden Windows PowerShell Module installiert und geladen sind.

Wie Sie die Shutdown.bat in RCCMD anpassen:

Teil 1: Den ersten Hyper-V Befehl erstellen:

1. Verwenden Sie in den RCCMD Shutdown Optionen den Hyper-V Befehl „Hyper-V VM herunterfahren“ und tragen Sie unter VM Name den Namen einer VM ein.

2. Backups ändern

3. Erstellen Sie den Job „Einige Sekunden warten“ und vergeben Sie zum Beispiel 90 Sekunden.

4. Klicken Sie oben rechts auf Speichern, um Ihre Änderungen in die Batchdatei zu schreiben. In diesem Fall ist ein Neustart von RCCMD nicht notwendig, da Sie noch weitere Einstellungen vornehmen müssen.

5. Drücken Sie F5, um die Webanzeige zu aktualisieren.

Sie können die Einstellungsdatei anschließend direkt im Webbrowser bearbeiten, indem Sie auf „Datei bearbeiten“ klicken.

Teil 2: Shutdown Reihenfolge anpassen.

Die Befehlskette sollte jetzt 3 Zeilen enthalten:

1. Hyper-V VM „XXXX“ herunterfahren.

2. 90 Sekunden warten

3. System herunterfahren

Diese Befehle werden in exakt dieser Reihenfolge von oben nach unten ausgeführt. Wichtig zu wissen: Alles, was nach dem System Shutdown geschrieben wird, kann nicht mehr ausgeführt werden, da das lokale Betriebssystem herunterfährt. Klicken Sie dann auf Datei bearbeiten und fügen Sie die gewünschten Befehle hinzu – die zuvor eingetragenen Befehle können als Vorlage zur Erweiterung dienen:

Fügen Sie einfach die Befehle hinzu, die Sie benötigen.

Beispiel 1: Hyper-V ohne Cluster Manager

Die Befehlskette würde von oben nach unten in folgender Reihenfolge ausgeführt:

Beispiel 2: Hyper-V mit mehreren Knoten und Cluster Manager

Hier wären einige zusätzliche Anpassungen notwendig:

Der Befehl ExitWin.exe shutdown force ist nicht notwendig, da der Server über Stop-ClusterNode heruntergefahren wird.

Tipp: Zeitfenster planen

Diese Beispiele gehen von idealisierten Zeitfenstern (gxSleep.exe) aus. Passen Sie die Zeitfenster an die tatsächlichen Shutdown Zeiten an, um Probleme zu vermeiden.