Închidere corectă a hypervisorului VMWare ESXi la nivel critic al încărcării bateriei UPS APC

Există multe articole pe internet despre cum să configurăm PowerChute Business Edition și cum să ne conectăm la VMWare din PowerShell, dar nu am găsit toate aceste informații într-un singur loc, împreună cu descrierea detaliilor. Iar acestea există.

1. Introducere

Deși avem o legătură cu sectorul energetic, problemele legate de electricitate apar uneori. Aici intervine UPS-ul, dar bateriile sale, din păcate, nu sunt durabile. Ce să facem? Să le închidem!

Până acum, toate serverele erau fizice, și lucrurile mergeau bine, fiind ajutați de PowerChute Business Edition. Versiunea gratuită, pentru 5 servere, ceea ce era suficient. Pe o mașină a fost instalat agentul, serverul și consola. Pe măsură ce se apropia sfârșitul, agentul rula pur și simplu un fișier de comandă, trimițând shutdown.exe /s /m către serverele adiacente, apoi își închidea sistemul de operare. Toate sunt în siguranță.
Apoi a venit timpul mașini virtuale.

2. Date de bază și considerații

Deci, ce avem? Nimic rău – un server fizic cu Windows Server 2008 R2 și un hypervisor cu mai multe mașini virtuale, printre care se numără Windows Server 2019, Windows Server 2003 și CentOS. Și, de asemenea, UPS – APC Smart-UPS.

Am auzit de NUT, dar nu am avut încă ocazia să-l studiem, am folosit doar ceea ce aveam la îndemână, și anume PowerChute Business Edition.

Hypervisorul poate închide singur mașinile sale virtuale, rămâne doar să-i comunicăm că este timpul. Există un instrument util numit VMWare.PowerCLI, aceasta este o extensie pentru Windows Powershell, care permite conectarea la hypervisor și comunicarea tuturor informațiilor necesare. Există și multe articole despre configurarea PowerCLI pe internet.

3. Procesul

UPS-ul a fost conectat fizic la portul com al serverului 2008, noroc că acesta exista. Deși nu este esențial – s-ar fi putut conecta printr-un convertor de interfețe (MOXA) la orice server Windows virtual. Toate acțiunile ulterioare se desfășoară pe mașina la care este conectat UPS-ul – Windows Server 2008, cu excepția cazului în care se specifică altceva. Pe aceasta a fost instalat agentul PowerChute Business Edition. Aici apare primul detaliu important: serviciul agentului trebuie să fie pornit nu de sistem, ci de utilizator, altfel agentul nu va putea executa fișierul cmd.

Apoi am instalat .Net Framework 4.7. Este necesară o repornire, chiar dacă framework-ul nu o cere în mod explicit după instalare, altfel nu va funcționa mai departe. După aceea, pot veni actualizări, care de asemenea trebuie instalate.

Apoi am instalat PowerShell 5.1. De asemenea, este necesară o repornire, chiar dacă nu cere.
Apoi instalarea PowerCLI 11.5. O versiune destul de nouă, din această cauză și cerințele anterioare. Poate fi făcută prin internet, despre asta sunt multe articole, dar noi deja l-am descărcat, așa că doar am copiat toate fișierele în dosarul Modules.

Am verificat:

Get-Module -ListAvailable

Bine, vedem, a fost instalat:

Import-Module VMWare.PowerCLI

Da, consola Powershell este desigur rulată ca Administrator.

Setările Powershell.

• Permiteți execuția oricăror scripturi:

Set-ExecutionPolicy Unrestricted

• Sau permiteți doar ignorarea certificatelor scripturilor:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Permiteți PowerCLI să se conecteze la servere cu certificate invalide (expirate):

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Suprimați mesajul de ieșire PowerCLI despre participarea la programul de schimb de experiență, altfel în log va fi mult zgomot:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Salvați credențialele utilizatorului pentru conectarea la gazda VMWare, pentru a nu le face vizibile în script:

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

Verificarea va arăta pe cine am salvat:

Get-VICredentialStoreItem

Puteți verifica și conexiunea: Connect-VIServer address.

Scriptul în sine, de exemplu: ne-am conectat, am oprit, de dragul precauției ne-am deconectat, sunt diverse opțiuni:

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

4. Default.cmd

Acela este fișierul de comandă care este rulat de agentul APC. Se află în “C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles”, și în interior:

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Se pare că totul este configurat și verificat, chiar am rulat cmd – funcționează corect, oprește.

Rulăm din consolă APC verificarea fișierului de comandă (acolo este un buton Test) – nu funcționează.

Iată, acel moment awkward, când toată munca depusă nu a dus nicăieri.

5. Catharsis

Ne uităm la managerul de sarcini, vedem – a trecut cmd, a trecut powershell. Ne uităm mai atent – cmd *32 și, respectiv, powershell *32. Înțelegem că serviciul agentului APC este pe 32 de biți, ceea ce înseamnă că pornește consola corespunzătoare.

Rulăm powershell x86 ca administrator, facem din nou instalarea și configurarea PowerCLI din punctul 3.

Și schimbăm linia de apelare a powershell:

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

6. Final fericit!

Sursa: habr.com