Pareiza VMWare ESXi hipervizora izslēgšana, kad APC UPS akumulatora uzlādes līmenis ir kritisks

Ir daudz rakstu par to, kā konfigurēt PowerChute Business Edition un kā izveidot savienojumu ar VMWare no PowerShell, taču kaut kā es nevarēju to visu atrast vienuviet ar smalko punktu aprakstu. Bet tie pastāv.

1. Ievads

Neskatoties uz to, ka mums ir zināma saistība ar enerģiju, dažkārt rodas problēmas ar elektrību. Šeit tiek izmantots UPS, taču tā akumulatori, diemžēl, nedarbojas ilgi. Ko darīt? Izslēgt!

Kamēr visi serveri bija fiziski, viss noritēja labi, PowerChute Business Edition mums palīdzēja. Bezmaksas, 5 serveriem, kas bija pilnīgi pietiekami. Vienā mašīnā tika instalēts aģents, serveris un konsole. Tuvojoties beigām, aģents vienkārši izpildīja komandas failu, kas nosūtīja shutdown.exe /s /m blakus esošajiem serveriem, un pēc tam izslēdza savu OS. Visi ir dzīvi.
Tad pienāca laiks virtuālajām mašīnām.

2. Fons un pārdomas

Kas tad mums ir? Nekas — viens fizisks serveris ar Windows Server 2008 R2 un viens hipervizors ar vairākām virtuālajām mašīnām, tostarp Windows Server 2019, Windows Server 2003 un CentOS. Un vēl viens UPS – APC Smart-UPS.

Mēs dzirdējām par NUT, bet vēl neesam sākuši to izpētīt; izmantojām tikai to, kas bija pa rokai, proti, PowerChute Business Edition.

Hipervizors pats var izslēgt savas virtuālās mašīnas; atliek tikai pateikt, ka ir pienācis laiks. Ir tāda noderīga lieta VMWare.PowerCLI, tas ir Windows Powershell paplašinājums, kas ļauj izveidot savienojumu ar hipervizoru un pastāstīt tam visu nepieciešamo. Ir arī daudz rakstu par PowerCLI iestatījumiem.

3. Process

UPS bija fiziski savienots ar 2008. gada servera com portu, par laimi tas tur bija. Lai gan tas nav svarīgi – caur interfeisa pārveidotāju (MOXA) bija iespējams pieslēgties jebkuram virtuālajam Windows serverim. Turklāt visas darbības tiek veiktas ar iekārtu, kurai ir pievienots UPS — Windows Server 2008, ja vien nav skaidri norādīts citādi. Tajā tika instalēts PowerChute Business Edition aģents. Šeit ir pirmais smalkais punkts: aģenta pakalpojums ir jāpalaiž nevis no sistēmas, bet no lietotāja, pretējā gadījumā aģents nevarēs izpildīt cmd failu.

Tālāk mēs instalējām .Net Framework 4.7. Šeit ir nepieciešama atsāknēšana, pat ja sistēma pēc instalēšanas to nepārprotami neprasa, pretējā gadījumā tas netiks tālāk. Pēc tam joprojām var nākt atjauninājumi, kas arī jāinstalē.

Tālāk mēs instalējām PowerShell 5.1. Nepieciešama arī atsāknēšana, pat ja viņš nejautā.
Pēc tam instalējiet PowerCLI 11.5. Diezgan nesena versija, tāpēc arī iepriekšējās prasības. To var izdarīt, izmantojot internetu, par to ir daudz rakstu, taču mēs to jau lejupielādējām, tāpēc mēs vienkārši nokopējām visus failus mapē Moduļi.

Pārbaudīts:

Get-Module -ListAvailable

Labi, mēs redzam, ka esam instalējuši:

Import-Module VMWare.PowerCLI

Jā, Powershell konsole, protams, ir palaista kā administrators.

Powershell iestatījumi.

  • Atļaut izpildīt jebkuru skriptu:

Set-ExecutionPolicy Unrestricted

  • Vai arī varat tikai ļaut ignorēt skripta sertifikātus:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

  • Ļaujiet PowerCLI izveidot savienojumu ar serveriem ar nederīgiem (beigušies) sertifikātiem:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

  • Izslēdziet PowerCLI ziņojuma izvadi par pievienošanos pieredzes apmaiņas programmai, pretējā gadījumā žurnālā būs daudz nevajadzīgas informācijas:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

  • Saglabājiet lietotāja akreditācijas datus, lai pieteiktos VMWare resursdatorā, lai tie netiktu skaidri parādīti skriptā:

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

Pārbaudot, tiks parādīts, ko mēs saglabājām:

Get-VICredentialStoreItem

Varat arī pārbaudīt savienojumu: Connect-VIServer adrese.

Pats skripts, piemēram: savienots, izslēgts, atvienots katram gadījumam, ir iespējamas šādas iespējas:


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

4. Default.cmd

Tas pats pakešfails, ko palaiž APC aģents. Tas atrodas mapē “C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles” un iekšpusē:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" - fails "C:...shutdown_hosts.ps1"
Šķiet, ka viss tika konfigurēts un pārbaudīts, mēs pat palaižām cmd - tas darbojas pareizi, izslēdz to.

Mēs palaižam komandu faila pārbaudi no APC konsoles (tur ir poga Test) - tas nedarbojas.

Lūk, tas neveiklais brīdis, kad viss paveiktais nav novedis pie nekā.

5.Katarse

Mēs skatāmies uz uzdevumu pārvaldnieku, mēs redzam cmd mirgo, powershell mirgo. Apskatīsim tuvāk - cmd *32 un attiecīgi powershell *32. Mēs to saprotam APC aģenta pakalpojums ir 32 bitu, kas nozīmē, ka tas palaiž atbilstošo konsoli.

Mēs palaižam Powershell x86 kā administratoru un vēlreiz instalējam un konfigurējam PowerCLI, sākot no 3. darbības.

Mainīsim Powershell zvana līniju:

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

6. Laimīgas beigas!

Avots: www.habr.com

Pievieno komentāru