Prawidłowe wyłączenie hypervisora ​​VMWare ESXi, gdy poziom naładowania akumulatora UPS APC jest krytyczny

Istnieje wiele artykułów o tym, jak skonfigurować PowerChute Business Edition i jak połączyć się z VMWare z PowerShell, ale jakoś nie mogłem znaleźć tego wszystkiego w jednym miejscu, z opisem subtelnych punktów. Ale istnieją.

1. Wstęp

Pomimo tego, że mamy pewne połączenie z energią, czasami pojawiają się problemy z prądem. Tutaj w grę wchodzi UPS, ale jego baterie, niestety, nie wytrzymują długo. Co robić? Wyłączyć coś!

Chociaż wszystkie serwery były fizyczne, wszystko szło dobrze, PowerChute Business Edition pomógł nam. Za darmo, na 5 serwerów, co w zupełności wystarczyło. Na jednej maszynie zainstalowano agenta, serwer i konsolę. Gdy zbliżał się koniec, agent po prostu wykonał plik poleceń, który wysłał plik Shutdown.exe /s /m do sąsiednich serwerów, a następnie zamknął system operacyjny. Wszyscy żyją.
Potem przyszedł czas na maszyny wirtualne.

2. Tło i refleksje

Co więc mamy? Zupełnie nic - jeden serwer fizyczny z Windows Server 2008 R2 i jeden hypervisor z kilkoma maszynami wirtualnymi, w tym Windows Server 2019, Windows Server 2003 i CentOS. I kolejny UPS – APC Smart-UPS.

Słyszeliśmy o NUT, ale jeszcze nie zabraliśmy się za jego studiowanie; korzystaliśmy tylko z tego, co było pod ręką, a mianowicie PowerChute Business Edition.

Hiperwizor może sam wyłączyć swoje maszyny wirtualne; wystarczy tylko powiedzieć mu, że nadszedł czas. Jest taka przydatna rzecz VMWare.PowerCLI, jest to rozszerzenie dla Windows PowerShell, które pozwala połączyć się z hiperwizorem i powiedzieć mu wszystko, czego potrzebujesz. Istnieje również wiele artykułów na temat ustawień PowerCLI.

3. Proces

UPS był fizycznie podłączony do portu com serwera 2008, na szczęście tam był. Choć nie jest to istotne – możliwe było połączenie się poprzez konwerter interfejsu (MOXA) z dowolnym wirtualnym serwerem Windows. Ponadto wszystkie czynności wykonywane są na komputerze, do którego podłączony jest UPS - Windows Server 2008, chyba że wyraźnie zaznaczono inaczej. Został na nim zainstalowany agent PowerChute Business Edition. Oto pierwszy subtelny punkt: usługa agenta musi zostać uruchomiona nie z systemu, ale od użytkownika, w przeciwnym razie agent nie będzie mógł wykonać pliku cmd.

Następnie zainstalowaliśmy .Net Framework 4.7. Tutaj wymagane jest ponowne uruchomienie, nawet jeśli framework nie poprosi o to wyraźnie po instalacji, w przeciwnym razie nie pójdzie dalej. Później mogą nadal pojawiać się aktualizacje, które również należy zainstalować.

Następnie zainstalowaliśmy PowerShell 5.1. Wymaga także ponownego uruchomienia, nawet jeśli nie pyta.
Następnie zainstaluj PowerCLI 11.5. Całkiem nowa wersja, stąd poprzednie wymagania. Można to zrobić przez Internet, jest wiele artykułów na ten temat, ale my już go pobraliśmy, więc po prostu skopiowaliśmy wszystkie pliki do folderu Moduły.

Sprawdzony:

Get-Module -ListAvailable

OK, widzimy, że zainstalowaliśmy:

Import-Module VMWare.PowerCLI

Tak, konsola Powershell jest oczywiście uruchamiana jako Administrator.

Ustawienia PowerShell.

• Zezwalaj na wykonywanie dowolnych skryptów:

Set-ExecutionPolicy Unrestricted

• Możesz też pozwolić na ignorowanie certyfikatów skryptów:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Zezwól PowerCLI na łączenie się z serwerami z nieprawidłowymi (wygasłymi) certyfikatami:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Pomiń wyjście komunikatu PowerCLI o dołączeniu do programu wymiany doświadczeń, w przeciwnym razie w logu będzie dużo niepotrzebnych informacji:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Zapisz dane logowania użytkownika do hosta VMWare, aby nie pokazywać ich jawnie w skrypcie:

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

Sprawdzenie pokaże, kogo uratowaliśmy:

Get-VICredentialStoreItem

Możesz także sprawdzić połączenie: Adres Connect-VIServer.

Sam skrypt np. podłączony, wyłączony, odłączony na wszelki wypadek, możliwe są następujące opcje:

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

4. Domyślny.cmd

Ten sam plik wsadowy, który jest uruchamiany przez agenta APC. Znajduje się w „C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles”, a wewnątrz:

„C:Windowssystem32WindowsPowerShellv1.0powershell.exe” — plik „C:...shutdown_hosts.ps1”
Wygląda na to, że wszystko zostało skonfigurowane i sprawdzone, nawet uruchomiliśmy cmd - działa poprawnie, wyłącza się.

Uruchamiamy test pliku poleceń z konsoli APC (jest tam przycisk Test) – nie działa.

Oto ten niezręczny moment, kiedy cała wykonana praca nie doprowadziła do niczego.

5. Katharsis

Patrzymy na menedżera zadań, widzimy błyski cmd, błyski PowerShell. Przyjrzyjmy się bliżej - cmd *32 i odpowiednio PowerShell *32. Rozumiemy to Usługa agenta APC jest 32-bitowa, co oznacza, że ​​uruchamia odpowiednią konsolę.

Uruchamiamy PowerShell x86 jako administrator i ponownie instalujemy i konfigurujemy PowerCLI od kroku 3.

Cóż, zmieńmy linię wywołania PowerShell:

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

6. Szczęśliwe zakończenie!

Źródło: www.habr.com