Korrektes Herunterfahren des Hypervisors VMWare ESXi bei kritischem Batteriestatus des APC-USV

In den Weiten des Internets gibt es viele Artikel darüber, wie man die PowerChute Business Edition konfiguriert und wie man sich über PowerShell mit VMWare verbindet, aber ich habe das alles nicht an einem Ort mit einer Beschreibung der feinen Details gefunden. Und die gibt es.

1. Einführung

Trotz unseres gewissen Bezuges zur Energiebranche treten manchmal Probleme mit der Elektrizität auf. Hier kommt die USV ins Spiel, aber auch deren Batterien sind leider nicht langlebig. Was tun? Abschalten!

Solange alle Server physisch waren, lief alles gut, uns half PowerChute Business Edition. Kostenlos, für 5 Server, was völlig ausreichte. Auf einem Rechner war der Agent, der Server und die Konsole installiert. Bei Annäherung ans Ende führte der Agent einfach eine Batch-Datei aus, in der an die benachbarten Server shutdown.exe /s /m gesendet wurde, und dann schaltete er sein Betriebssystem aus. Alle leben noch.
Dann war die Zeit gekommen. virtuelle Maschinen.

2. Ausgangsdaten und Überlegungen

Also, was haben wir? Nicht viel – einen physischen Server mit Windows Server 2008 R2 und einen Hypervisor mit mehreren virtuellen Maschinen, darunter Windows Server 2019, Windows Server 2003 und CentOS. Und noch eine USV – APC Smart-UPS.

Von NUT hatten wir gehört, aber bisher hatten wir keine Zeit, uns damit auseinanderzusetzen, wir haben nur das verwendet, was wir zur Hand hatten, nämlich die PowerChute Business Edition.

Der Hypervisor kann seine virtuellen Maschinen selbst herunterfahren, es bleibt nur zu sagen, dass es Zeit ist. Es gibt ein nützliches Tool, VMWare.PowerCLI, ein Erweiterung für Windows PowerShell, das es ermöglicht, sich mit dem Hypervisor zu verbinden und ihm alles Notwendige mitzuteilen. Auch darüber gibt es zahlreiche Artikel im Netz.

3. Prozess

Die USV wurde physisch an den COM-Port des Servers 2008 angeschlossen, was glücklicherweise vorhanden war. Obwohl das nicht entscheidend ist – man könnte sich auch über einen Schnittstellenkonverter (MOXA) mit jedem virtuellen Windows-Server verbinden. Alle weiteren Aktionen werden auf der Maschine durchgeführt, an die die USV angeschlossen ist – Windows Server 2008, sofern nicht ausdrücklich anders angegeben. Auf ihr wurde der Agent der PowerChute Business Edition installiert. Hier liegt der erste feine Punkt: Der Dienst des Agenten muss nicht als Systemdienst, sondern als Benutzer gestartet werden, sonst kann der Agent die CMD-Datei nicht ausführen.

Dann wurde .Net Framework 4.7 installiert. Hier ist ein Restart erforderlich, auch wenn das Framework nach der Installation keinen ausdrücklich anfragt, sonst geht es nicht weiter. Danach können auch Updates kommen, die ebenfalls installiert werden müssen.

Dann wurde PowerShell 5.1 installiert. Auch hier ist ein Restart erforderlich, selbst wenn nicht danach gefragt wird.
Weiter geht es mit der Installation von PowerCLI 11.5. Eine recht aktuelle Version, daher auch die vorherigen Anforderungen. Man kann es über das Internet machen, es gibt viele Artikel dazu, aber wir haben es bereits heruntergeladen, also haben wir einfach alle Dateien in den Ordner Modules kopiert.

Überprüft:

Get-Module -ListAvailable

Okay, wir sehen, es wurde installiert:

Import-Module VMWare.PowerCLI

Ja, die Powershell-Konsole wird natürlich als Administrator ausgeführt.

Powershell-Einstellungen.

• Erlaube die Ausführung aller Skripte:

Set-ExecutionPolicy Unrestricted

• Oder nur erlauben, dass Zertifikate von Skripten ignoriert werden:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Erlaube PowerCLI die Verbindung zu Servern mit ungültigen (abgelaufenen) Zertifikaten:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Unterdrücke die Ausgabe der PowerCLI-Nachricht über die Anmeldung beim Programm zur Teilnahme an der Nutzererfahrung, andernfalls gibt es viel Unnötiges im Log:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Speichere die Anmeldedaten des Benutzers für den Zugang zum VMWare-Host, damit sie im Skript nicht offenbart werden:

New-VICredentialStoreItem -Host address -User user -Password 'password'

Die Überprüfung zeigt, was wir gespeichert haben:

Get-VICredentialStoreItem

Man kann auch die Verbindung überprüfen: Connect-VIServer address.

Das Skript, zum Beispiel: wir haben uns verbunden, abgeschaltet, vorsichtshalber getrennt, es gibt verschiedene Varianten:

    Connect-VIserver -Server $vmhost 
    Stop-VMHost $vmhost -force -Confirm:$false 
    Disconnect-VIserver $vmhost -Confirm:$false

4. Default.cmd

Die besagte Batchdatei, die vom APC-Agenten gestartet wird. Sie befindet sich in "C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles", und darin:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -File "C:…shutdown_hosts.ps1"
Es scheint, dass alles eingerichtet und überprüft wurde, wir haben sogar cmd gestartet - es funktioniert richtig, es schaltet aus.

Wir starten aus der APC-Konsole eine Überprüfung der Batchdatei (es gibt einen Button Test) – funktioniert nicht.

Hier ist er, der ungeschickte Moment, in dem die ganze Arbeit umsonst war.

5. Katharsis

Wir schauen im Task-Manager, sehen – cmd hat kurz geflackert, powershell auch. Wenn wir genauer hinsehen – cmd *32 und entsprechend powershell *32. Wir verstehen, dass der APC-Agent 32-Bit ist, was bedeutet, dass er die entsprechende Konsole startet.

Wir starten powershell x86 als Administrator, führen die Installation und Konfiguration von PowerCLI erneut durch.

Und wir ändern die Zeile zum Aufrufen von powershell:

C:\Windows<b>SysWOW64</b>C:\Windows\PowerShell\v1.0\powershell.exe…

6. Happy end!

Quelle: habr.com