Ĝusta malŝalto de la hiperviziero VMWare ESXi kiam la APC-UPS-baterio-ŝarga nivelo estas kritika

Estas multaj artikoloj pri kiel agordi PowerChute Business Edition kaj kiel konekti al VMWare de PowerShell, sed iel mi ne povis trovi ĉion ĉi en unu loko, kun priskribo de la subtilaj punktoj. Sed ili ekzistas.

1. Eniro

Malgraŭ tio, ke ni havas ian rilaton kun energio, foje aperas problemoj kun elektro. Ĉi tie intervenas la UPS, sed ĝiaj baterioj, ve, ne daŭras longe. Kion fari? Malŝalti!

Dum ĉiuj serviloj estis fizikaj, aferoj iris bone, PowerChute Business Edition helpis nin. Senpaga, por 5 serviloj, kio sufiĉis. Agento, servilo kaj konzolo estis instalitaj sur unu maŝino. Kiam la fino alproksimiĝis, la agento simple efektivigis komanddosieron kiu sendis shutdown.exe /s /m al najbaraj serviloj, kaj poste fermis ĝian OS. Ĉiuj vivas.
Tiam estis tempo por virtualaj maŝinoj.

2. Fono kaj interkonsiliĝoj

Kion do ni havas? Tute nenio - unu fizika servilo kun Windows Server 2008 R2 kaj unu hiperviziero kun pluraj virtualaj maŝinoj, inkluzive de Windows Server 2019, Windows Server 2003 kaj CentOS. Kaj alia UPS - APC Smart-UPS.

Ni aŭdis pri NUT, sed ankoraŭ ne studis ĝin; ni uzis nur tion, kio estis ĉe mano, nome PowerChute Business Edition.

La hiperviziero povas mem malŝalti siajn virtualajn maŝinojn; restas nur diri al ĝi, ke estas tempo. Estas tia utila afero VMWare.PowerCLI, ĉi tio estas etendo por Windows Powershell, kiu permesas vin konekti al la hiperviziero kaj diri al ĝi ĉion, kion vi bezonas. Ankaŭ ekzistas multaj artikoloj pri PowerCLI-agordoj.

3. Procezo

La UPS estis fizike konektita al la kom-haveno de la servilo de 2008, feliĉe ĝi estis tie. Kvankam tio ne gravas - eblis konekti per interfaca konvertilo (MOXA) al iu virtuala Vindoza servilo. Plue, ĉiuj agoj estas faritaj sur la maŝino al kiu la UPS estas konektita - Windows Server 2008, krom se eksplicite dirite alie. La agento PowerChute Business Edition estis instalita sur ĝi. Jen la unua subtila punkto: la agentservo devas esti lanĉita ne de la sistemo, sed de la uzanto, alie la agento ne povos ekzekuti la cmd-dosieron.

Poste ni instalis .Net Framework 4.7. Ĉi tie necesas rekomenco, eĉ se la kadro ne eksplicite petas ĝin post instalado, alie ĝi ne iros plu. Poste, ĝisdatigoj ankoraŭ povas veni, kiuj ankaŭ devas esti instalitaj.

Poste ni instalis PowerShell 5.1. Ankaŭ postulas rekomencon, eĉ se li ne demandas.
Poste, instalu PowerCLI 11.5. Sufiĉe lastatempa versio, do la antaŭaj postuloj. Vi povas fari ĝin per la Interreto, estas multaj artikoloj pri tio, sed ni jam elŝutis ĝin, do ni simple kopiis ĉiujn dosierojn al la dosierujo Moduloj.

Kontrolita:

Get-Module -ListAvailable

Bone, ni vidas, ke ni instalis:

Import-Module VMWare.PowerCLI

Jes, la Powershell-konzolo kompreneble estas lanĉita kiel Administranto.

Powershell-agordoj.

  • Permesu ekzekuton de iuj skriptoj:

Set-ExecutionPolicy Unrestricted

  • Aŭ vi povas nur permesi skripto-atestojn esti ignoritaj:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

  • Permesu al PowerCLI konektiĝi al serviloj kun nevalidaj (eksvalidiĝintaj) atestiloj:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

  • Subpremu la eliron de la mesaĝo de PowerCLI pri aliĝo al la programo pri interŝanĝo de spertoj, alie estos multaj nenecesaj informoj en la protokolo:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

  • Konservu la uzantajn akreditaĵojn por ensaluti en la VMWare-gastiganto por ne eksplicite montri ilin en la skripto:

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

Kontrolado montros kiun ni savis:

Get-VICredentialStoreItem

Vi ankaŭ povas kontroli la konekton: Connect-VIServer-adreso.

La skripto mem, ekzemple: konektita, malŝaltita, malkonektita ĉiaokaze, la sekvaj opcioj eblas:


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

4. Defaŭlta.cmd

La sama bata dosiero, kiu estas lanĉita de la APC-agento. Ĝi troviĝas en "C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles", kaj ene:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Dosiero "C:...shutdown_hosts.ps1"
Ŝajnas, ke ĉio estis agordita kaj kontrolita, ni eĉ lanĉis cmd - ĝi funkcias ĝuste, malŝaltas ĝin.

Ni faras komanddosieron teston de la APC-konzolo (estas Testbutono tie) - ĝi ne funkcias.

Jen ĝi estas, tiu mallerta momento, kiam la tuta laboro farita nenion kondukis.

5. Katarso

Ni rigardas la taskadministranton, ni vidas cmd-fulmojn, powershell-fulmojn. Ni rigardu pli detale - cmd *32 kaj, sekve, powershell *32. Ni komprenas tion La APC-agenta servo estas 32-bita, kio signifas, ke ĝi funkcias la respondan konzolon.

Ni lanĉas powershell x86 kiel administranto, kaj denove instalas kaj agordas PowerCLI de la paŝo 3.

Nu, ni ŝanĝu la powershell-vokan linion:

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

6. Feliĉa fino!

fonto: www.habr.com

Aldoni komenton