Grasiøs avslutning av VMWare ESXi hypervisor ved kritisk batterinivå for APC UPS

Det er mange artikler der ute om hvordan du konfigurerer PowerChute Business Edition og hvordan du kobler til VMWare fra PowerShell, men på en eller annen måte kunne jeg ikke finne alt dette på ett sted, med en beskrivelse av de subtile punktene. Men de finnes.

1. oppføring

Til tross for at vi har en viss sammenheng med energi, oppstår det noen ganger problemer med elektrisitet. Det er her UPS-en kommer inn i bildet, men batteriene varer dessverre ikke lenge. Hva å gjøre? Skru av!

Mens alle serverne var fysiske, gikk ting bra, PowerChute Business Edition hjalp oss. Gratis, for 5 servere, som var ganske nok. En agent, server og konsoll ble installert på én maskin. Da slutten nærmet seg, utførte agenten ganske enkelt en kommandofil som sendte shutdown.exe /s /m til naboservere, og deretter stengte operativsystemet. Alle er i live.
Så var det tid for virtuelle maskiner.

2. Bakgrunn og refleksjoner

Så hva har vi? Ingenting i det hele tatt - én fysisk server med Windows Server 2008 R2 og én hypervisor med flere virtuelle maskiner, inkludert Windows Server 2019, Windows Server 2003 og CentOS. Og en annen UPS – APC Smart-UPS.

Vi hørte om NUT, men har ikke kommet oss i gang med å studere det ennå; vi brukte bare det som var for hånden, nemlig PowerChute Business Edition.

Hypervisoren kan selv slå av sine virtuelle maskiner; det gjenstår bare å fortelle den at det er på tide. Det er en så nyttig ting VMWare.PowerCLI, dette er en utvidelse for Windows Powershell som lar deg koble til hypervisoren og fortelle den alt du trenger. Det er også mange artikler der ute om PowerCLI-innstillinger.

3. Prosess

UPS-en var fysisk koblet til com-porten til 2008-serveren, heldigvis var den der. Selv om dette ikke er viktig - var det mulig å koble til via en grensesnittomformer (MOXA) til en hvilken som helst virtuell Windows-server. Videre utføres alle handlinger på maskinen som UPS-en er koblet til - Windows Server 2008, med mindre annet er uttrykkelig angitt. PowerChute Business Edition-agenten ble installert på den. Her er det første subtile punktet: agenttjenesten må ikke startes fra systemet, men fra brukeren, ellers vil ikke agenten kunne kjøre cmd-filen.

Deretter installerte vi .Net Framework 4.7. Her kreves en omstart, selv om rammeverket ikke eksplisitt ber om det etter installasjonen, ellers går det ikke lenger. Etterpå kan det fortsatt komme oppdateringer, som også må installeres.

Deretter installerte vi PowerShell 5.1. Krever også omstart, selv om han ikke spør.
Installer deretter PowerCLI 11.5. En ganske fersk versjon, derav de tidligere kravene. Du kan gjøre det via Internett, det er mange artikler om dette, men vi har allerede lastet det ned, så vi har bare kopiert alle filene til moduler-mappen.

Krysset av:

Get-Module -ListAvailable

Ok, vi ser at vi har installert:

Import-Module VMWare.PowerCLI

Ja, Powershell-konsollen lanseres selvfølgelig som administrator.

Powershell-innstillinger.

• Tillat kjøring av alle skript:

Set-ExecutionPolicy Unrestricted

• Eller du kan bare tillate at skriptsertifikater ignoreres:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Tillat PowerCLI å koble til servere med ugyldige (utløpte) sertifikater:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Undertrykk produksjonen av PowerCLI-meldingen om å bli med i erfaringsutvekslingsprogrammet, ellers vil det være mye unødvendig informasjon i loggen:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Lagre brukerlegitimasjonen for å logge på VMWare-verten for ikke å eksplisitt vise dem i skriptet:

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

Kontroll vil vise hvem vi reddet:

Get-VICredentialStoreItem

Du kan også sjekke tilkoblingen: Connect-VIServer-adresse.

Selve skriptet, for eksempel: tilkoblet, slått av, frakoblet i tilfelle, følgende alternativer er mulige:

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

4. Standard.cmd

Den samme batchfilen som lanseres av APC-agenten. Den ligger i "C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles", og inne:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Fil "C:...shutdown_hosts.ps1"
Det virker som om alt ble konfigurert og sjekket, vi lanserte til og med cmd - det fungerer riktig, slår det av.

Vi kjører en kommandofiltest fra APC-konsollen (det er en testknapp der) - den fungerer ikke.

Her er det, det vanskelige øyeblikket når alt arbeidet som er gjort har ført til ingenting.

5. Katarsis

Vi ser på oppgavebehandlingen, vi ser cmd-blinker, powershell-blinker. La oss ta en nærmere titt - cmd *32 og følgelig powershell *32. Det forstår vi APC-agenttjenesten er 32-bit, noe som betyr at den kjører den tilsvarende konsollen.

Vi lanserer powershell x86 som administrator, og installerer og konfigurerer PowerCLI fra trinn 3 igjen.

Vel, la oss endre powershell-anropslinjen:

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

6. God slutt!

Kilde: www.habr.com