Korrekt avstängning av VMWare ESXi hypervisor när APC UPS batteriladdningsnivå är kritisk

Det finns många artiklar där ute om hur man konfigurerar PowerChute Business Edition och hur man ansluter till VMWare från PowerShell, men på något sätt kunde jag inte hitta allt detta på ett ställe, med en beskrivning av de subtila punkterna. Men de finns.

1. Introduktion

Trots att vi har viss koppling till energi så uppstår ibland problem med el. Det är här UPS:en kommer in i bilden, men dess batterier håller tyvärr inte länge. Vad ska man göra? Stäng av!

Medan alla servrar var fysiska gick det bra, PowerChute Business Edition hjälpte oss. Gratis, för 5 servrar, vilket var ganska tillräckligt. En agent, server och konsol installerades på en dator. När slutet närmade sig körde agenten helt enkelt en kommandofil som skickade shutdown.exe /s /m till angränsande servrar och stängde sedan av dess operativsystem. Alla är vid liv.
Sedan var det dags för virtuella maskiner.

2. Bakgrund och reflektioner

Så vad har vi? Ingenting alls - en fysisk server med Windows Server 2008 R2 och en hypervisor med flera virtuella maskiner, inklusive Windows Server 2019, Windows Server 2003 och CentOS. Och en annan UPS – APC Smart-UPS.

Vi hörde talas om NUT, men har inte hunnit studera det än, vi använde bara det som fanns till hands, nämligen PowerChute Business Edition.

Hypervisorn kan själv stänga av sina virtuella maskiner; allt som återstår är att berätta att det är dags. Det finns en så användbar sak VMWare.PowerCLI, det här är ett tillägg för Windows Powershell som låter dig ansluta till hypervisorn och berätta allt du behöver. Det finns också många artiklar där ute om PowerCLI-inställningar.

3. Process

UPS:en var fysiskt ansluten till com-porten på 2008 års server, som tur var fanns den där. Även om detta inte är viktigt - det var möjligt att ansluta via en gränssnittsomvandlare (MOXA) till vilken virtuell Windows-server som helst. Vidare utförs alla åtgärder på den maskin som UPS:en är ansluten till - Windows Server 2008, om inte annat uttryckligen anges. PowerChute Business Edition-agenten installerades på den. Här är den första subtila punkten: agenttjänsten måste inte startas från systemet utan från användaren, annars kommer agenten inte att kunna köra cmd-filen.

Därefter installerade vi .Net Framework 4.7. En omstart krävs här, även om ramverket inte uttryckligen ber om det efter installationen, annars går det inte längre. Efteråt kan det fortfarande komma uppdateringar som också måste installeras.

Därefter installerade vi PowerShell 5.1. Kräver också en omstart, även om han inte frågar.
Installera sedan PowerCLI 11.5. En ganska ny version, därav de tidigare kraven. Du kan göra det via Internet, det finns många artiklar om detta, men vi har redan laddat ner det, så vi kopierade bara alla filer till mappen Moduler.

Kontrollerade:

Get-Module -ListAvailable

Ok, vi ser att vi har installerat:

Import-Module VMWare.PowerCLI

Ja, Powershell-konsolen lanseras givetvis som administratör.

Powershell-inställningar.

• Tillåt körning av alla skript:

Set-ExecutionPolicy Unrestricted

• Eller så kan du bara tillåta att skriptcertifikat ignoreras:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Tillåt PowerCLI att ansluta till servrar med ogiltiga (utgångna) certifikat:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Undertryck utmatningen av PowerCLI-meddelandet om att gå med i erfarenhetsutbytesprogrammet, annars kommer det att finnas mycket onödig information i loggen:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Spara användaruppgifterna för att logga in på VMWare-värden för att inte explicit visa dem i skriptet:

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

Kontroll kommer att visa vem vi räddade:

Get-VICredentialStoreItem

Du kan också kontrollera anslutningen: Connect-VIServer-adress.

Själva skriptet, till exempel: ansluten, avstängd, frånkopplad ifall följande alternativ är möjliga:

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

4. Default.cmd

Samma batchfil som startas av APC-agenten. Den finns i "C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles", och inuti:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Fil "C:...shutdown_hosts.ps1"
Det verkar som att allt var konfigurerat och kontrollerat, vi lanserade till och med cmd - det fungerar korrekt, stänger av det.

Vi kör ett kommandofiltest från APC-konsolen (det finns en testknapp där) - det fungerar inte.

Här är det, det där obekväma ögonblicket när allt arbete som gjorts inte har lett till någonting.

5. Katarsis

Vi tittar på aktivitetshanteraren, vi ser cmd-blixtar, powershell-blixtar. Låt oss ta en närmare titt - cmd *32 och följaktligen powershell *32. Det förstår vi APC-agenttjänsten är 32-bitars, vilket innebär att den kör motsvarande konsol.

Starta powershell x86 som administratör, installera och konfigurera PowerCLI från steg 3 igen.

Nåväl, låt oss ändra powershell-anropslinjen:

"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…

6. Lyckligt slut!

Källa: will.com