Sok cikk található a PowerChute Business Edition konfigurálásáról és a PowerShell VMWare-hez való csatlakozásáról, de valahogy nem találtam mindezt egy helyen, a finom pontok leírásával. De léteznek.
1. belépés
Annak ellenére, hogy kapcsolatban állunk az energiával, néha felmerülnek problémák az elektromossággal. Itt jön képbe az UPS, de akkumulátorai sajnos nem bírják sokáig. Mit kell tenni? Kikapcsolni!
Míg az összes szerver fizikai volt, a dolgok jól mentek, a PowerChute Business Edition segített nekünk. Ingyenes, 5 szerverre, ami bőven elég volt. Egy ügynököt, szervert és konzolt telepítettek egy gépre. A végéhez közeledve az ügynök egyszerűen végrehajtott egy parancsfájlt, amely elküldte a shutdown.exe /s /m fájlt a szomszédos kiszolgálóknak, majd leállította az operációs rendszerét. Mindenki él.
Aztán eljött a virtuális gépek ideje.
2. Háttér és reflexiók
Szóval mi van nálunk? Egyáltalán semmi – egy fizikai szerver Windows Server 2008 R2-vel és egy hypervisor több virtuális géppel, beleértve a Windows Server 2019-et, a Windows Server 2003-at és a CentOS-t. És egy másik UPS – APC Smart-UPS.
Hallottunk a NUT-ról, de 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 hypervisor maga is leállíthatja a virtuális gépeit; nem kell mást tennie, mint közölni vele, hogy itt az ideje. Van egy ilyen hasznos dolog a VMWare.PowerCLI, ez a Windows Powershell kiterjesztése, amely lehetővé teszi, hogy csatlakozzon a hypervisorhoz, és elmondjon neki mindent, amire szüksége van. A PowerCLI beállításairól is sok cikk található.
3. Folyamat
Az UPS fizikailag csatlakozott a 2008-as szerver com portjához, szerencsére ott volt. Bár ez nem fontos – interfész konverteren (MOXA) keresztül lehetett csatlakozni bármely virtuális Windows szerverhez. Továbbá minden művelet azon a gépen történik, amelyhez az UPS csatlakozik – Windows Server 2008, kivéve, ha kifejezetten másként jelezzük. A PowerChute Business Edition ügynök telepítve volt rá. Itt az első finom pont: az ügynök szolgáltatást nem a rendszerből, hanem a felhasználótól kell elindí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, akkor is, ha a keretrendszer kifejezetten nem kéri a telepítés után, különben nem megy tovább. Utána még jöhetnek frissítések, amiket szintén telepíteni kell.
Ezután telepítettük a PowerShell 5.1-et. Szintén újraindítást igényel, még ha nem is kérdez.
Ezután telepítse a PowerCLI 11.5-öt. Egészen friss verzió, innen a korábbi követelmények. Interneten keresztül is megteheti, sok cikk van erről, de már letöltöttük, így az összes fájlt átmásoltuk a Modules mappába.
Ellenőrizve:
Get-Module -ListAvailableRendben, látjuk, hogy telepítettük:
Import-Module VMWare.PowerCLIIgen, a Powershell konzol természetesen rendszergazdaként indul.
Powershell beállítások.
- Bármilyen szkript végrehajtásának engedélyezése:
Set-ExecutionPolicy Unrestricted- Vagy csak a parancsfájl-tanúsítványok figyelmen kívül hagyását engedélyezheti:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned - A PowerCLI csatlakozásának engedélyezése érvénytelen (lejárt) tanúsítvánnyal rendelkező szerverekhez:
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false- Tiltsa le a PowerCLI üzenet kimenetét a tapasztalatcsere programhoz való csatlakozásról, különben sok felesleges információ lesz a naplóban:
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false- Mentse el a felhasználói hitelesítő adatokat a VMWare gazdagépre való bejelentkezéshez, hogy ne jelenjenek meg kifejezetten a szkriptben:
New-VICredentialStoreItem -Host address -User user -Password 'password'Az ellenőrzés megmutatja, hogy kit mentettünk:
Get-VICredentialStoreItemA kapcsolatot is ellenőrizheti: Connect-VIServer címe.
Maga a szkript, például: csatlakoztatva, kikapcsolva, leválasztva minden esetre, a következő lehetőségek lehetségesek:
Connect-VIserver -Server $vmhost
Stop-VMHost $vmhost -force -Confirm:$false
Disconnect-VIserver $vmhost -Confirm:$false
4. Alapértelmezett.cmd
Ugyanaz a kötegfájl, amelyet az APC-ügynök indított el. A „C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles” mappában található, és a következőkben:
"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -"C:...shutdown_hosts.ps1" fájl
Úgy tűnik, mindent beállítottak és ellenőriztek, még a cmd-t is elindítottuk - megfelelően működik, kikapcsolja.
Parancsfájltesztet futtatunk az APC konzolról (ott van egy Teszt gomb) - nem működik.
Itt van az a kínos pillanat, amikor az elvégzett munka nem vezetett semmihez.
5. Katarzis
Nézzük a feladatkezelőt, látunk cmd flasheket, powershell flasheket. Nézzük meg közelebbről - cmd *32 és ennek megfelelően powershell *32. Ezt megértjük Az APC ügynökszolgáltatás 32 bites, ami azt jelenti, hogy a megfelelő konzolt futtatja.
Rendszergazdaként elindítjuk a powershell x86-ot, majd a 3. lépéstől újra telepítjük és konfiguráljuk a PowerCLI-t.
Nos, változtassuk meg a powershell hívóvonalat:
"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…6. Happy end!
Forrás: will.com