Korrekt avslutning av hypervisor VMWare ESXi vid kritisk nivå av APC UPS-batteriladdning

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 jag har ännu inte sett allt detta samlat på ett ställe med beskrivningar av viktiga detaljer. Och de finns.

1. Introduktion

Trots att vi har viss koppling till energi kan elproblem ibland uppstå. Här kommer UPS in i bilden, men tyvärr är även dess batterier inte långlivade. Vad gör man? Stänger av!

När alla servrar var fysiska gick det rätt bra, vi räddades av PowerChute Business Edition. Gratis, för 5 servrar, vilket var mer än tillräckligt. På en maskin var agenten installerad, servern och konsolen. När slutet närmade sig utförde agenten helt enkelt ett skript som skickade shutdown.exe /s /m till de närliggande servrarna, och stängde sedan ner sitt eget operativsystem. Alla är vid liv.
Sedan kom tiden virtuella maskiner.

2. Förutsättningar och reflektioner

Så vad har vi? Inte mycket – en fysisk server med Windows Server 2008 R2 och en hypervisor med flera virtuella maskiner, bland vilka finns både Windows Server 2019 och Windows Server 2003, samt CentOS. Och en UPS – APC Smart-UPS.

Vi har hört talas om NUT, men har ännu inte fått tid att läsa in oss, utan har använt det som fanns tillgängligt, nämligen PowerChute Business Edition.

Hypervisorn kan stänga av sina virtuella maskiner, det som kvarstår är att meddela den att det är dags. Det finns en användbar sak som heter VMWare.PowerCLI, ett tillägg för Windows Powershell som gör det möjligt att ansluta till hypervisorn och ge den all nödvändig information. Det finns också många artiklar om PowerCLI-inställningar på nätet.

3. Process

UPS:en anslöts fysiskt till COM-porten på servern 2008, lycka att den fanns. Fast det är inte avgörande – man kunde även ansluta via en gränssnittsomvandlare (MOXA) till vilken virtuell Windows-server som helst. Alla åtgärder utförs på maskinen som UPS:en är ansluten till – Windows Server 2008, om inget annat anges. Där installerades agenten för PowerChute Business Edition. Här ligger den första delikata punkten: agenttjänsten måste köras som användare och inte som system, annars kan inte agenten köra cmd-filen.

Därefter installerade vi .Net Framework 4.7. Här krävs en omstart, även om ramverket inte tydligt ber om det efter installationen, annars går det inte vidare. Efteråt kan det även komma uppdateringar som också måste installeras.

Därefter installerade vi PowerShell 5.1. Det krävs också en omstart, även om det inte begärs.
Vidare installation av PowerCLI 11.5. En ganska ny version, därav de tidigare kraven. Det går att göra via internet, det finns många artiklar om detta, men vi hade redan laddat ner det, så vi kopierade bara alla filer till mappen Modules.

Vi kontrollerade:

Get-Module -ListAvailable

Okej, vi ser att vi har installerat:

Import-Module VMWare.PowerCLI

Ja, PowerShell-konsolen körs förstås som administratör.

Inställningar för PowerShell.

• Tillåt körning av alla skript:

Set-ExecutionPolicy Unrestricted

• Eller tillåt endast att ignorera skriptcertifikat:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

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

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Tysta meddelandet från PowerCLI om att delta i användargrupp, annars kommer det att bli mycket onödig information i loggen:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Spara användarens inloggningsuppgifter för att logga in på VMWare-värden, så att de inte syns i skriptet:

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

Kontrollen visar vilka vi har sparat:

Get-VICredentialStoreItem

Du kan även kontrollera anslutningen: Connect-VIServer address.

Själva skriptet, till exempel: ansluten, stängde av, kopplade från, det finns olika alternativ:

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

4. Default.cmd

Den där kommandofilen som startas av APC-agenten. Den ligger i “C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles”, och inuti:

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Det verkar som vi har konfigurerat och kontrollerat allt, till och med kört cmd – det fungerar korrekt, stänger av.

Vi kör en test av kommandofilen från APC-konsolen (det finns en knapp Test) – det fungerar inte.

Här är den pinsamma situationen, när allt arbete inte har lett till något.

5. Katarsis

Vi tittar på aktivitetshanteraren, ser att – cmd flöt förbi, powershell flöt förbi. Vi ser noggrant – cmd *32 och därmed powershell *32. Vi förstår att APC-agentens tjänst är 32-bitars, vilket innebär att den startar motsvarande konsol.

Vi startar powershell x86 som administratör, går igenom installationen och konfigurationen av PowerCLI igen enligt punkt 3.

Och vi ändrar raden som anropar powershell:

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

6. Lyckligt slut!

Källa: habr.com