A VMWare ESXi hypervisor korrekciója kritikus UPS APPC töltöttségi szintnél

Rengeteg cikk található a PowerChute Business Edition beállításáról és a VMware-hez való csatlakozásról PowerShell-ből, de valahogy nem találkoztam mindezzel egy helyen, a finom részletek leírásával. Pedig vannak.

1. Bevezetés

Bár van némi kapcsolatunk az energiakérdésekkel, az árammal néha problémák adódnak. Itt jön képbe az UPS, de sajnos a akkumulátorai sem tartanak örökké. Mi a teendő? Kikapcsolni!

Amíg minden szerver fizikális volt, a dolgok jól mentek, a PowerChute Business Edition segített minket. Ingyenes, 5 szerverek, ami bőven elegendő volt. Egy gépen volt telepítve az ügynök, a szerver és a konzol. Amikor közeledett a vég, az ügynök egyszerűen végrehajtotta a parancsfájlt, amely a szomszédos szervereknek elküldte a shutdown.exe /s /m parancsot, majd leállította a saját operációs rendszerét. Mindenki életben maradt.
Aztán eljött az idő virtuális gépekhez.

2. Kiindulási adatok és gondolatok

Tehát mit is tartalmazunk? Csak egy fizikai szerver Windows Server 2008 R2-vel és egy hipervizor több virtuális géppel, köztük Windows Server 2019, Windows Server 2003 és CentOS. És van egy UPS is – APC Smart-UPS.

A NUT-ról hallottunk, de eddig még nem jutottunk el a tanulmányozásáig, csak azt használtuk, ami kéznél volt, mégpedig a PowerChute Business Edition-t.

A hipervizor képes magának leállítani a virtuális gépeit, csak meg kell mondani neki, hogy itt az ideje. Van egy hasznos dolog, a VMWare.PowerCLI, ez egy kiterjesztés a Windows Powershellhez, amely lehetővé teszi a hipervizorhoz való csatlakozást és a szükséges információk közlését. A PowerCLI beállításairól is sok cikk található a neten.

3. Folyamat

Az UPS-t fizikálisan csatlakoztattuk a 2008-as szerver com-portjához, hála Istennek, hogy volt. Bár ez nem lényeges – akár interfészkonverteren (MOXA) keresztül is csatlakozhatunk bármely virtuális Windows szerverhez. A továbbiakban minden műveletet azon a gépen hajtunk végre, amelyhez az UPS csatlakoztatva van – Windows Server 2008, hacsak kifejezetten mást nem jelezünk. Itt telepítettük a PowerChute Business Edition ügynökét. Ez itt a legelső finom részlet: az ügynök szolgáltatását nem a rendszerből, hanem felhasználói módban kell indítani, különben az ügynök nem tudja végrehajtani a cmd fájlt.

Ezután telepítettük a .Net Framework 4.7-et. Itt újraindítás szükséges, még ha a keretrendszer nem is kéri ezt a telepítés után, különben nem haladunk tovább. Ezt követően frissítések is érkezhetnek, azokat is telepíteni kell.

Ezután telepítettük a PowerShell 5.1-et. Szintén szükséges a rendszer újraindítása, még ha nem is kérik.
A PowerCLI 11.5 telepítése. Elég új verzió, ezért az előző követelmények is változtak. Lehetőség van interneten keresztül is, erről sok cikk íródott, de nekünk már le volt töltve, így csak átmásoltuk az összes fájlt a Modules mappába.

Ellenőriztük:

Get-Module -ListAvailable

Rendben, látjuk, telepítettük:

Import-Module VMWare.PowerCLI

Igen, a Powershell konzolt természetesen rendszergazdaként indítottuk.

Powershell beállítások.

• Engedélyezni kell a script-ek futtatását:

Set-ExecutionPolicy Unrestricted

• Vagy csak a tanúsítványok figyelmen kívül hagyása engedélyezett:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Engedélyezni kell a PowerCLI csatlakozást az érvénytelen (lejárt) tanúsítványú szerverekhez:

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• A PowerCLI üzeneteinek elnyomása a tapasztalatcsere programhoz való csatlakozáskor, különben a naplóban sok felesleges információ lesz:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• A felhasználói hitelesítő adatok tárolása a VMWare hosztra való bejelentkezéshez, hogy ne legyenek nyilvánosan láthatóak a scriptben:

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

Az ellenőrzés megmutatja, kit tároltunk el:

Get-VICredentialStoreItem

A csatlakozást is ellenőrizhetjük: Connect-VIServer address.

A script, például: csatlakozunk, leállítjuk, úgyhogy elzárkózunk, lehetnek variációk:

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

4. Default.cmd

Ez az a parancsfájl, amelyet az APC ügynök indít. A „C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles” mappában található, és belül:

„C:Windowssystem32WindowsPowerShellv1.0powershell.exe” -File „C:…shutdown_hosts.ps1”
Úgy tűnik, mindent beállítottunk és ellenőriztünk, még a cmd-t is elindítottuk – helyesen működik, lekapcsol.

Az APC konzolból teszteljük a parancsfájlt (ott van a Teszt gomb) – nem működik.

Itt van az a kínos pillanat, amikor az összes elvégzett munka eredménytelen volt.

5. Katarzis

Nézzük a feladatkezelőt, és látjuk – felbukkant a cmd, felbukkant a powershell. Különösen figyelmesen nézzük – cmd *32 és ennek megfelelően powershell *32. Rájövünk, hogy az APC ügynök szolgáltatás 32 bites, ezért a megfelelő konzolt indítja.

Rendszergazdapéldányban indítjuk el a powershell x86-ot, és újra elvégezzük a PowerCLI telepítését és beállítását a 3. pontból.

Nos, és módosítjuk a powershell hívásának sorát:

"C:Windows<b>64-bites rendszerek esetén).</b>WindowsPowerShellv1.0powershell.exe…

6. Boldog befejezés!

Forrás: habr.com