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

Il existe de nombreux articles sur la façon de configurer PowerChute Business Edition et de se connecter à VMWare à partir de PowerShell, mais je n'ai pas pu trouver tout cela au même endroit, avec une description des points subtils. Mais ils existent.

1. Introduction

Malgré le fait que nous ayons un certain lien avec l'énergie, des problèmes d'électricité surviennent parfois. C'est ici qu'intervient l'onduleur, mais ses batteries, hélas, ne durent pas longtemps. Ce qu'il faut faire? Éteindre!

Même si tous les serveurs étaient physiques, tout se passait bien, PowerChute Business Edition nous a aidé. Gratuit, pour 5 serveurs, ce qui était largement suffisant. Un agent, un serveur et une console ont été installés sur une seule machine. À l'approche de la fin, l'agent a simplement exécuté un fichier de commandes qui a envoyé shutdown.exe /s /m aux serveurs voisins, puis a arrêté son système d'exploitation. Tout le monde est vivant.
Puis vint l’heure des machines virtuelles.

2. Contexte et réflexions

Alors qu'est-ce que nous avons? Rien du tout : 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 autre UPS – APC Smart-UPS.

Nous avons entendu parler de NUT, mais n’avons pas encore eu l’occasion de l’étudier ; nous avons uniquement utilisé ce qui était à notre disposition, à savoir PowerChute Business Edition.

L’hyperviseur peut arrêter lui-même ses machines virtuelles, il ne reste plus qu’à lui dire que c’est le moment. Il existe une chose tellement utile VMWare.PowerCLI, c'est une extension pour Windows Powershell qui vous permet 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.

3. Le processus

L'onduleur était physiquement connecté au port com du serveur 2008, heureusement il était là. Bien que cela ne soit pas important, vous pouvez vous connecter via un convertisseur d'interface (MOXA) à n'importe quel serveur virtuel Windows. 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 agent doit être lancé 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 requis ici, même si le framework ne le demande pas explicitement après l’installation, sinon il n’ira pas plus loin. Par la suite, des mises à jour peuvent encore arriver, qui doivent également être installées.

Ensuite, nous avons installé PowerShell 5.1. Nécessite également un redémarrage, même s'il ne le demande pas.
Ensuite, installez PowerCLI 11.5. Version assez récente, d'où les exigences précédentes. Vous pouvez le faire via Internet, il existe de nombreux articles à ce sujet, mais nous l'avons déjà téléchargé, nous avons donc simplement copié tous les fichiers dans le dossier Modules.

Vérifié:

Get-Module -ListAvailable

Ok, nous voyons que nous avons installé :

Import-Module VMWare.PowerCLI

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

Paramètres PowerShell.

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

Set-ExecutionPolicy Unrestricted

• Ou vous pouvez uniquement autoriser l'ignorance des certificats de script :

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 l'adhésion au programme d'échange d'expériences, sinon il y aura beaucoup d'informations inutiles dans le journal :

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false

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

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

La vérification montrera qui nous avons enregistré :

Get-VICredentialStoreItem

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

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

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

4. Par défaut.cmd

Le même fichier batch lancé par l'agent APC. Il se trouve dans « C:Program Files[ (x86)]APCPowerChute Business Editionagentcmdfiles » et à l'intérieur :

"C:Windowssystem32WindowsPowerShellv1.0powershell.exe" -Fichier "C:...shutdown_hosts.ps1"
Il semble que tout ait été configuré et vérifié, nous avons même lancé cmd - cela fonctionne correctement, l'éteint.

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

Voilà ce moment gênant où tout le travail accompli n’a abouti à rien.

5. Catharsis

On regarde le gestionnaire de tâches, on voit des flashs cmd, des flashs powershell. Regardons de plus près - cmd *32 et, par conséquent, powershell *32. Nous comprenons cela Le service de l'agent APC est 32 bits, ce qui signifie qu'il exécute la console correspondante.

Nous lançons PowerShell x86 en tant qu'administrateur, puis installons et configurons à nouveau PowerCLI à partir de l'étape 3.

Eh bien, changeons la ligne d'appel PowerShell :

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

6. Fin heureuse !

Source: habr.com