Arrêt correct de l'hyperviseur VMWare ESXi à un niveau critique de charge de la batterie de l'UPS APC

Il existe de nombreux articles sur la configuration de PowerChute Business Edition et la connexion à VMWare via PowerShell, mais je ne les ai pas trouvés tous réunis au même endroit, avec des descriptions des détails subtils. Et il y en a.

1. Introduction

Bien que nous ayons un lien avec l'énergie, des problèmes d'électricité surviennent parfois. C'est là qu'intervient l'onduleur, mais ses batteries, hélas, ne sont pas durables. Que faire ? Éteindre !

Tant que tous les serveurs étaient physiques, les choses se passaient plutôt bien, PowerChute Business Edition nous aidait. C'était gratuit, sur 5 serveurs, ce qui était largement suffisant. Sur une machine, un agent, un serveur et une console étaient installés. À l'approche de la fin, l'agent exécutait simplement un fichier de commandes, qui envoyait shutdown.exe /s /m aux serveurs voisins, avant d'éteindre son propre OS. Tout le monde est en vie.
Puis est venu le moment machines virtuelles.

2. Données de base et réflexions

Alors, que avons-nous ? Pas grand-chose – un serveur physique avec Windows Server 2008 R2 et un hyperviseur avec plusieurs machines virtuelles, dont Windows Server 2019, Windows Server 2003 et CentOS. Et un onduleur – APC Smart-UPS.

Nous avons entendu parler de NUT, mais nous n'avons pas encore eu le temps de l'étudier, nous avons seulement utilisé ce qui était à portée de main, à savoir PowerChute Business Edition.

L'hyperviseur peut éteindre ses machines virtuelles lui-même, il ne reste plus qu'à lui faire savoir que c'est le moment. Il existe un outil utile appelé VMWare.PowerCLI, une extension pour Windows PowerShell, qui permet de se connecter à l'hyperviseur et de lui transmettre toutes les informations nécessaires. Il y a aussi beaucoup d'articles sur la configuration de PowerCLI sur internet.

3. Processus

L'onduleur a été physiquement connecté au port com du serveur 2008, heureusement qu'il était présent. Bien que ce ne soit pas essentiel – il aurait été possible de se connecter via un convertisseur d'interface (MOXA) à n'importe quel serveur Windows virtuel. Par la suite, toutes les actions se déroulent sur la machine à laquelle l'onduleur est connecté – Windows Server 2008, sauf indication contraire. L'agent PowerChute Business Edition y a été installé. C'est ici qu'intervient le premier détail subtil : le service de l'agent doit être lancé non pas par le système, mais par un utilisateur, sinon l'agent ne pourra pas exécuter le fichier cmd.

Ensuite, nous avons installé .Net Framework 4.7. Un redémarrage est requis, même si le framework ne le demande pas explicitement après l'installation, sinon la suite ne pourra pas se poursuivre. D'autres mises à jour peuvent également être proposées, et il faudra les installer.

Nous avons ensuite installé PowerShell 5.1. Un redémarrage est également nécessaire, même s'il ne le demande pas.
Ensuite, installez PowerCLI 11.5. C'est une version relativement récente, d'où les exigences précédentes. On peut le faire via Internet, de nombreux articles en parlent, mais nous l'avions déjà téléchargé, donc nous avons juste copié tous les fichiers dans le dossier Modules.

Vérifié :

Get-Module -ListAvailable

D'accord, nous voyons que nous avons installé :

Import-Module VMWare.PowerCLI

Oui, la console Powershell est bien lancée en tant qu'administrateur.

Paramètres Powershell.

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

Set-ExecutionPolicy Unrestricted

• Ou permettre seulement d'ignorer les certificats des scripts :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 

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

Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false

• Supprimer le message de PowerCLI concernant la participation à un programme de retour d'expérience, sinon le journal sera encombré :

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

• Sauvegarder les identifiants utilisateur pour se connecter à l'hôte VMWare afin de ne pas les révéler explicitement dans le script :

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

La vérification montrera qui nous avons sauvegardé :

Get-VICredentialStoreItem

On peut aussi vérifier la connexion : Connect-VIServer address.

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

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

4. Default.cmd

Le fameux fichier de commande qui est lancé par l'agent APC. Se trouve dans “C:Program Files[(x86)]APCPowerChute Business Editionagentcmdfiles”, et à l'intérieur :

«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
Il semble que nous avons tout configurer et vérifier, même lancé cmd – cela fonctionne correctement, il éteint.

Nous lançons depuis la console APC le test du fichier de commande (il y a un bouton Test) – cela ne fonctionne pas.

Voici ce moment gênant où tout le travail accompli n'a eu aucun résultat.

5. Catharsis

Nous regardons le gestionnaire des tâches, nous voyons – cmd a clignoté, powershell a clignoté. Nous regardons de plus près – cmd *32 et, par conséquent, powershell *32. Nous réalisons que le service d'agent APC est en 32 bits, ce qui signifie qu'il lance la console correspondante.

Nous lançons powershell x86 en tant qu'administrateur, faisons encore une fois l'installation et la configuration de PowerCLI du point 3.

Et nous changeons la ligne d'appel à powershell :

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

6. Fin heureuse !

Source : habr.com