Arrêt correct de l'hyperviseur VMWare ESXi au niveau critique de la batterie de l'onduleur APC

Dans les espaces ouverts, il existe de nombreux articles sur la configuration de PowerChute Business Edition et sur la connexion à VMWare à partir de PowerShell, mais tout cela n'a pas été trouvé au même endroit, avec une description des points subtils. Et ils sont.

1. Introduction

Malgré le fait que nous ayons quelque chose à voir avec l'énergie, des problèmes d'électricité surviennent parfois. C'est là que l'UPS entre en jeu, mais ses batteries, hélas, ne sont pas durables. Que faire? Éteindre!



Tant que tous les serveurs étaient physiques, tout allait bien, avec PowerChute Business Edition nous aidant. Gratuit, pour 5 serveurs, ce qui était suffisant. L'agent, le serveur et la console ont été installés sur une seule machine. À l'approche de la fin, l'agent a simplement exécuté un fichier de commandes dans lequel shutdown.exe / s / m était envoyé aux serveurs voisins, puis a éteint son système d'exploitation. Tout le monde est vivant.

Puis vint le temps des machines virtuelles.

2. Contexte et réflexions

Alors qu'est-ce que nous avons? Rien du tout - un serveur physique exécutant Windows Server 2008 R2 et un hyperviseur avec plusieurs machines virtuelles, y compris Windows Server 2019, Windows Server 2003 et CentOS. Et un autre UPS - APC Smart-UPS.



Nous avons entendu parler de NUT, mais nous n'avons pas encore mis la main dessus, nous n'avons utilisé que ce qui était à portée de main, à savoir PowerChute Business Edition.



L'hyperviseur est capable d'arrêter ses machines virtuelles tout seul, il ne reste plus qu'à lui dire qu'il est temps. Il y a une telle chose utile VMWare.PowerCLI est une extension pour Windows Powershell, vous permettant simplement de vous connecter à l'hyperviseur et de lui dire tout ce dont vous avez besoin. Il existe également de nombreux articles sur les paramètres PowerCLI dans les espaces ouverts.

3. Processus

L'onduleur était physiquement connecté au port com du serveur 2008, car il était là. Bien que ce ne soit pas essentiel, il était possible de se connecter via le convertisseur d'interface (MOXA) à n'importe quel serveur Windows virtuel. De plus, toutes les actions sont effectuées sur la machine à laquelle l'onduleur est connecté - Windows Server 2008, sauf indication contraire explicite. L'agent PowerChute Business Edition y a été installé. Voici le premier point subtil: le service d'agent doit être démarré non pas depuis le système, mais depuis l'utilisateur, sinon l'agent ne pourra pas exécuter le fichier cmd.



Ensuite, nous avons installé .Net Framework 4.7. Un redémarrage est nécessaire ici , même si le framework ne le demande pas explicitement après l'installation, sinon il n'ira pas plus loin. Après cela, des mises à jour peuvent encore arriver, vous devez également l'installer.



Ensuite, nous avons installé PowerShell 5.1.Un redémarrage est également nécessaire , même s'il n'est pas demandé.

Ensuite, installez PowerCLI 11.5. Une toute nouvelle version, à partir de ceci et des exigences précédentes. C'est possible via Internet, il existe de nombreux articles à ce sujet, mais nous l'avons déjà téléchargé, nous venons donc de copier tous les fichiers dans le dossier Modules.



Vérifié:

Get-Module -ListAvailable

Ok, on voit, installé:

Import-Module VMWare.PowerCLI

Oui, la console Powershell est bien sûr lancée depuis l'administrateur.



Paramètres PowerShell.

• Autoriser l'exécution de tous les scripts:

Set-ExecutionPolicy Unrestricted

• Ou autorisez uniquement les certificats de script ignorés:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

• Autorisez PowerCLI à se connecter aux serveurs avec des certificats non valides (expirés):

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Supprimez la sortie du message PowerCLI concernant la participation au programme d'échange, sinon le journal contiendra beaucoup de choses inutiles:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Enregistrez les informations d'identification de l'utilisateur pour la connexion à l'hôte VMWare afin de ne pas les exposer explicitement dans le script:

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

La vérification montrera qui nous avons sauvé:

Get-VICredentialStoreItem

Vous pouvez également vérifier la connexion: adresse Connect-VIServer.



Le script lui-même, enfin, par exemple: connecté, éteint, déconnecté au cas où, des options sont possibles:

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

4. Default.cmd

Le même fichier de commandes que l'agent APC lance. Se trouve dans «C: \ Program Files [(x86)] \ APC \ PowerChute Business Edition \ agent \ cmdfiles», et à l'intérieur:



«C: \ Windows \ system32 \ WindowsPowerShell \ v1.0 \ powershell.exe» -Fichier «C : \ ... \ shutdown_hosts.ps1 "

Il semble que tout a été configuré et vérifié, même démarré cmd - cela fonctionne correctement, l'éteint.



Nous exécutons la vérification du fichier de commande à partir de la console APC (il y a un bouton Test) - cela ne fonctionne pas.



Le voici, ce moment gênant où tout le travail accompli n'a abouti à rien.

5. Catharsis

Nous regardons le gestionnaire de tâches, nous voyons - cmd flashé, PowerShell flashé. Regardons de plus près - cmd * 32 et, en conséquence, powershell * 32. Nous comprenons que le service d'agent APC est 32 bits, ce qui signifie qu'il démarre la console correspondante.



Lancez powershell x86 en tant qu'administrateur, installez et configurez à nouveau PowerCLI à partir de l'étape 3



et modifiez la ligne pour appeler PowerCLI:

"C:\Windows\<b>SysWOW64</b>\WindowsPowerShell\v1.0\powershell.exe…

6. Bonne fin!