Prawidłowe zakończenie pracy hipernadzorcy VMWare ESXi przy krytycznym poziomie naładowania baterii UPS APC

W Internecie znajduje się wiele artykułów o tym, jak skonfigurować PowerChute Business Edition i jak łączyć się z VMWare z PowerShell, ale jakoś nie udało się znaleźć tego wszystkiego w jednym miejscu, z opisem delikatnych kwestii. A te istnieją.

1. Wprowadzenie

Mimo że mamy pewne powiązania z energetyką, problemy z elektrycznością czasami się zdarzają. Wtedy przychodzi z pomocą UPS, ale niestety jego akumulatory również nie są trwałe. Co robić? Wyłączyć!

Dopóki wszystkie serwery były fizyczne, wszystko szło gładko, ratowała nas PowerChute Business Edition. Bezpłatna, na 5 serwerów, co wystarczało. Na jednej maszynie był zainstalowany agent, serwer i konsola. Gdy zbliżał się koniec, agent po prostu uruchamiał plik .cmd, w którym na sąsiednie serwery wysyłano shutdown.exe /s /m, a potem wyłączał swoje OS. Wszystkie serwery przetrwały.
Potem nadszedł czas maszyn wirtualnych.

2. Dane wyjściowe i przemyślenia

Cóż, co mamy? Zaledwie jeden fizyczny serwer z Windows Server 2008 R2 oraz jeden hypervisor z kilkoma maszynami wirtualnymi, w tym Windows Server 2019, Windows Server 2003 i CentOS. I jeszcze UPS – APC Smart-UPS.

Słyszeliśmy o NUT, ale jak dotąd nie mieliśmy czasu, by się nim zająć, używaliśmy tylko tego, co mieliśmy pod ręką, a mianowicie PowerChute Business Edition.

Hypervisor potrafi samodzielnie wyłączać swoje maszyny wirtualne, wystarczy tylko mu to zakomunikować. Jest taka użyteczna rzecz jak VMWare.PowerCLI, to rozszerzenie dla Windows Powershell, które umożliwia połączenie się z hypervisorem i przekazanie mu wszystkich potrzebnych informacji. O ustawieniach PowerCLI również jest wiele artykułów w Internecie.

3. Proces

UPS został fizycznie podłączony do portu com serwera 2008, na szczęście był. Chociaż nie jest to kluczowe – można było połączyć się przez konwerter interfejsów (MOXA) z dowolnym wirtualnym serwerem Windows. Następnie wszystkie działania wykonywane są na maszynie, do której podłączony jest UPS – Windows Server 2008, chyba że wyraźnie zaznaczone jest inaczej. Na niej zainstalowano agenta PowerChute Business Edition. Tu pojawia się pierwszy delikatny problem: usługę agenta należy uruchomić nie jako system, a jako użytkownik, w przeciwnym razie agent nie będzie w stanie wykonać pliku cmd.

Następnie zainstalowano .Net Framework 4.7. Tu wymagana jest ponowna instalacja, nawet jeśli framework nie prosi o nią bezpośrednio po instalacji, bo inaczej nie pójdzie dalej. Po tym mogą nadejść aktualizacje, które również trzeba zainstalować.

Następnie zainstalowano PowerShell 5.1. Również wymagana jest ponowna instalacja, nawet jeśli nie prosi.
Następnie instalacja PowerCLI 11.5. To dość świeża wersja, stąd wcześniejsze wymagania. Można to zrobić przez internet, jest o tym wiele artykułów, ale mieliśmy już pobrane pliki, więc po prostu skopiowaliśmy wszystkie pliki do folderu Modules.

Sprawdzone:

Get-Module -ListAvailable

Ok, widzimy, zainstalowano:

Import-Module VMWare.PowerCLI

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

Ustawienia Powershell.

• Zezwól na wykonywanie dowolnych skryptów:

Set-ExecutionPolicy Unrestricted

• Lub zezwolić na ignorowanie certyfikatów skryptów:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Zezwól PowerCLI na połączenie z serwerami z nieważnymi (przedawnionymi) certyfikatami:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Stłumić komunikat wyjściowy PowerCLI o przystąpieniu do programu wymiany doświadczeń, inaczej w logach będzie dużo niepotrzebnych informacji:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Zachowaj dane uwierzytelniające użytkownika do logowania się na hoście VMWare, aby wyraźnie nie pokazywać ich w skrypcie:

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

Sprawdzenie pokaże, kogo zapisaliśmy:

Get-VICredentialStoreItem

Można również sprawdzić połączenie: Connect-VIServer address.

Sam skrypt, na przykład: połączyliśmy się, wyłączyliśmy, na wszelki wypadek rozłączyliśmy się, możliwe opcje:

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

4. Default.cmd

To ten plik skryptu, który uruchamia agent APC. Znajduje się w "C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles", a w środku:

„C:Windowssystem32WindowsPowerShellv1.0powershell.exe” -File „C:…shutdown_hosts.ps1”
Wygląda na to, że wszystko skonfigurowano i sprawdzono, nawet uruchomiliśmy cmd – działa poprawnie, wyłącza.

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

Oto ten niezręczny moment, kiedy cała praca nie przyniosła rezultatu.

5. Katharsis

Patrzymy na menedżera zadań, widzimy – mignęło cmd, mignęło powershell. Przyglądamy się uważniej – cmd *32 i, odpowiednio, powershell *32. Rozumiemy, że usługa agenta APC jest 32-bitowa, a więc uruchamia odpowiednią konsolę.

Uruchamiamy powershell x86 jako administrator, przeprowadzamy ponownie instalację i konfigurację PowerCLI z punktu 3.

I zmieniamy linię wywołania powershell:

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

6. Szczęśliwe zakończenie!

Źródło: habr.com