Коректно изключване на хипервизора VMWare ESXi при критично ниво на заряд на UPS APC

В интернет пространството има много статии за това как да конфигурирате 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 address.

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

    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» -File «C:…shutdown_hosts.ps1»
Изглежда, че всичко е настроено и проверено, дори стартирахме cmd – работи правилно, изключва.

Стартираме от конзолата APC проверка на командния файл (там има бутон Test) – не работи.

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

5. Катарзис

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

Стартираме powershell x86 от администратора, правим отново инсталация и настройка на PowerCLI от пункт 3.

И променяме реда на извикване на powershell:

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

6. Happy end!

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