Există multe articole despre cum să configurați PowerChute Business Edition și despre cum să vă conectați la VMWare din PowerShell, dar cumva nu am putut găsi toate acestea într-un singur loc, cu o descriere a punctelor subtile. Dar ele există.
1. Introducere
În ciuda faptului că avem o anumită legătură cu energia, uneori apar probleme cu electricitatea. Aici intervine UPS-ul, dar bateriile sale, din păcate, nu țin mult. Ce să fac? Opriți!
Deși toate serverele erau fizice, lucrurile mergeau bine, iar PowerChute Business Edition a fost salvatorul nostru. Este gratuit, pentru 5 servere, ceea ce a fost suficient. Un agent, un server și o consolă au fost instalate pe o singură mașină. Când se apropia sfârșitul, agentul executa pur și simplu un fișier de comenzi care trimitea fișierul shutdown.exe /s /m către serverele vecine, apoi închidea propriul sistem de operare. Toată lumea a supraviețuit.
Apoi a venit momentul mașini virtuale.
2. Fundal și reflecții
Deci, ce avem? Nimic special – 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 și Windows Server 2003 și CentOSȘi un alt UPS – APC Smart-UPS.
Am auzit despre NUT, dar nu am apucat să-l studiem încă; am folosit doar ceea ce era la îndemână, și anume PowerChute Business Edition.
Hipervizorul își poate opri automat mașinile virtuale; trebuie doar să îi spui că e timpul. Există un lucru util numit VMWare.PowerCLI, o extensie pentru Windows Powershell, care vă permite să vă conectați la hypervisor și să comunicați cu acesta. Există, de asemenea, numeroase articole despre setările PowerCLI disponibile online.
3. Proces
UPS-ul era conectat fizic la portul COM al serverului 2008, din fericire exista unul. Deși acest lucru nu era esențial, era posibilă conectarea la orice mașină virtuală prin intermediul unui convertor de interfață (MOXA). Windows server. Toate acțiunile ulterioare sunt efectuate pe mașina la care este conectat UPS-ul – Windows Server 2008, dacă nu se specifică altfel. Are instalat agentul PowerChute Business Edition. Iată primul punct subtil: serviciul agent trebuie lansat nu din sistem, ci de la utilizator, altfel agentul nu va putea executa fișierul cmd.
Apoi am instalat .Net Framework 4.7. Este necesară o repornire aici, chiar dacă cadrul nu o cere în mod explicit după instalare, altfel nu va merge mai departe. Ulterior, este posibil să vină în continuare actualizări, care trebuie, de asemenea, instalate.
Apoi am instalat PowerShell 5.1. Necesită și o repornire, chiar dacă nu întreabă.
Apoi, instalați PowerCLI 11.5. O versiune destul de recentă, de unde și cerințele anterioare. O poți face prin internet, există multe articole despre asta, dar l-am descărcat deja, așa că doar am copiat toate fișierele în folderul Modules.
Verificat:
Get-Module -ListAvailableOk, vedem că am instalat:
Import-Module VMWare.PowerCLIDa, consola Powershell este, desigur, lansată ca Administrator.
Setări Powershell.
- Permite executarea oricăror scripturi:
Set-ExecutionPolicy Unrestricted- Sau puteți permite doar ignorarea certificatelor de script:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned - Permiteți PowerCLI să se conecteze la servere cu certificate nevalide (expirate):
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false- Suprimați rezultatul mesajului PowerCLI despre aderarea la programul de schimb de experiență, altfel vor fi multe informații inutile în jurnal:
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false- Salvați acreditările utilizatorului pentru conectarea la gazda VMWare pentru a nu le afișa explicit în script:
New-VICredentialStoreItem -Host address -User user -Password 'password'Verificarea va arăta pe cine am salvat:
Get-VICredentialStoreItemDe asemenea, puteți verifica conexiunea: adresa Connect-VIServer.
Scriptul în sine, de exemplu: conectat, oprit, deconectat pentru orice eventualitate, sunt posibile următoarele opțiuni:
Connect-VIserver -Server $vmhost
Stop-VMHost $vmhost -force -Confirm:$false
Disconnect-VIserver $vmhost -Confirm:$false
4. Default.cmd
Același fișier batch care este lansat de agentul APC. Se află în „C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles”, iar în interiorul:
"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" - Fișierul "C:...shutdown_hosts.ps1"
Se pare că totul a fost configurat și verificat, chiar am lansat cmd - funcționează corect, îl oprește.
Executăm un test de fișier de comandă din consola APC (există un buton Test acolo) - nu funcționează.
Iată, acel moment ciudat în care toată munca depusă nu a dus la nimic.
5. Catharsis
Ne uităm la managerul de activități, vedem flash-uri cmd, flash-uri powershell. Să aruncăm o privire mai atentă - cmd *32 și, în consecință, powershell *32. Înțelegem asta Serviciul de agent APC este pe 32 de biți, ceea ce înseamnă că rulează consola corespunzătoare.
Lansăm powershell x86 ca administrator și instalăm și configuram din nou PowerCLI de la pasul 3.
Ei bine, să schimbăm linia de apel Powershell:
"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…6. Sfârșit fericit!
Sursa: www.habr.com
