Грациозно изключване на хипервайзора VMWare ESXi при критично ниво на батерията на APC UPS

Има много статии за това как да конфигурирате PowerChute Business Edition и как да се свържете с VMWare от PowerShell, но някак си не можах да намеря всичко това на едно място, с описание на фините точки. Но те съществуват.

1. влизане

Въпреки факта, че имаме някаква връзка с енергията, понякога възникват проблеми с електричеството. Тук влиза в действие UPS-ът, но батериите му, уви, не издържат дълго. Какво да правя? Изключи!

Въпреки че всички сървъри бяха физически, нещата вървяха добре, PowerChute Business Edition ни помогна. Безплатно, за 5 сървъра, което беше напълно достатъчно. На една машина бяха инсталирани агент, сървър и конзола. С наближаването на края агентът просто изпълни команден файл, който изпрати shutdown.exe /s /m до съседни сървъри и след това изключи своята операционна система. Всички са живи.
Тогава дойде време за виртуални машини.

2. Фон и отражения

И така, какво имаме? Абсолютно нищо - един физически сървър с Windows Server 2008 R2 и един хипервизор с няколко виртуални машини, включително Windows Server 2019, Windows Server 2003 и CentOS. И още един UPS – APC Smart-UPS.

Чухме за NUT, но все още не сме се заели да го изучаваме; използвахме само това, което ни беше под ръка, а именно PowerChute Business Edition.

Хипервайзорът може сам да изключи своите виртуални машини; остава само да му кажете, че е време. Има такова полезно нещо VMWare.PowerCLI, това е разширение за Windows Powershell, което ви позволява да се свържете с хипервайзора и да му кажете всичко, от което се нуждаете. Има и много статии за настройките на PowerCLI.

3. Процес

UPS-ът беше физически свързан към com порта на сървъра 2008, за щастие беше там. Въпреки че това не е важно - беше възможно да се свържете чрез интерфейсен конвертор (MOXA) към всеки виртуален Windows сървър. Освен това всички действия се извършват на машината, към която е свързан UPS - Windows Server 2008, освен ако изрично не е посочено друго. На него беше инсталиран агентът PowerChute Business Edition. Ето първата фина точка: услугата на агента трябва да се стартира не от системата, а от потребителя, в противен случай агентът няма да може да изпълни cmd файла.

След това инсталирахме .Net Framework 4.7. Тук е необходимо рестартиране, дори ако рамката не го изисква изрично след инсталирането, в противен случай няма да продължи. След това все още може да идват актуализации, които също трябва да бъдат инсталирани.

След това инсталирахме PowerShell 5.1. Също така изисква рестартиране, дори и да не пита.
След това инсталирайте PowerCLI 11.5. Съвсем нова версия, следователно и предишните изисквания. Можете да го направите чрез интернет, има много статии за това, но ние вече го изтеглихме, така че просто копирахме всички файлове в папката Modules.

Проверено:

Get-Module -ListAvailable

Добре, виждаме, че сме инсталирали:

Import-Module VMWare.PowerCLI

Да, конзолата Powershell разбира се стартира като администратор.

Настройки на Powershell.

• Разрешете изпълнението на всякакви скриптове:

Set-ExecutionPolicy Unrestricted

• Или можете само да разрешите сертификатите на скриптове да бъдат игнорирани:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Разрешаване на PowerCLI да се свързва със сървъри с невалидни (изтекли) сертификати:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Потиснете изхода на съобщението PowerCLI за присъединяване към програмата за обмен на опит, в противен случай ще има много ненужна информация в дневника:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Запазете потребителските идентификационни данни за влизане в хоста на VMWare, за да не ги показвате изрично в скрипта:

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

Проверката ще покаже кой сме запазили:

Get-VICredentialStoreItem

Можете също да проверите връзката: Connect-VIServer адрес.

Самият скрипт, например: свързан, изключен, прекъснат за всеки случай, възможни са следните опции:

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

4. Default.cmd

Същият пакетен файл, който се стартира от APC агента. Той се намира в „C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles“ и вътре:

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Файл "C:...shutdown_hosts.ps1"
Изглежда, че всичко беше конфигурирано и проверено, дори стартирахме cmd - работи правилно, изключва го.

Пускаме тест на командния файл от конзолата на APC (там има бутон Тест) - не работи.

Ето го онзи неудобен момент, когато цялата свършена работа не доведе до нищо.

5. Катарзис

Гледаме диспечера на задачите, виждаме cmd мига, powershell мига. Нека да разгледаме по-отблизо - cmd *32 и съответно powershell *32. Ние разбираме това Агентската услуга на APC е 32-битова, което означава, че изпълнява съответната конзола.

Стартираме powershell x86 като администратор и инсталираме и конфигурираме PowerCLI от стъпка 3 отново.

Е, нека променим линията за повикване на powershell:

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

6. Щастлив край!

Източник: www.habr.com