Коректне завершення роботи гіпервізора VMWare ESXi при критичному рівні заряду батарей ДБЖ APC

На просторах є багато статей про те, як налаштовувати PowerChute Business Edition, і як підключатися до VMWare з PowerShell, але не зустрілося все це в одному місці, з описом тонких моментів. А вони є.

1. вступ

Незважаючи на те, що ми маємо деяке відношення до енергетики, проблеми з електроенергією іноді виникають. Тут у справу вступає ДБЖ, але і його батареї, на жаль, не довговічні. Що робити? Вимикати!

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

2. Вихідні дані та роздуми

Отже, що ми маємо? Всього нічого – один фізичний сервер з Windows Server 2008 R2 та один гіпервізор з кількома віртуальними машинами, серед яких є і Windows Server 2019, і Windows Server 2003 та CentOS. І ще ДБЖ – APC Smart-UPS.

Про NUT ми чули, але руки поки що до його вивчення не дійшли, використовували тільки те, що було під рукою, а саме PowerChute Business Edition.

Гіпервізор вміє сам завершувати роботу своїх віртуальних машин, залишилося тільки йому повідомити, що настав час. Є така корисна штука VMWare.PowerCLI, це розширення для Windows Powershell, що дозволяє підключатися до гіпервізора і повідомити йому все що треба. Про налаштування PowerCLI також є багато статей на просторах.

3. Процес

ДБЖ фізично підключили до com-порту сервера 2008, благо він був. Хоча це не важливо – можна було підключитися через перетворювач інтерфейсів (MOXA) до будь-якого віртуального Windows сервера. Далі всі дії здійснюються на машині, до якої підключено ДБЖ – 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

Додати коментар або відгук