Dans le but de pouvoir stopper proprement un hyperviseur VMware et ses machines virtuelles en cas d’alerte onduleur, voici une solution pour intégrer un client NUT (Network UPS Tools) natif à vSphere Hypervisor (ESXi 5.0, 5.1, 5.5, 6.0, 6.5, 6.7, 7.0, 8.0 testés). Le client NUT est installé dans l’hyperviseur et peut être contrôlé et paramétré depuis l’interface de configuration de ESXi ou depuis le vCenter s’il est géré.
Mise en garde 01/11/2023 : Sous ESXi 8.0 et à partir de la version 2.5.0 du client Nut, dans l’interface client HTML, vous ne verrez pas les descriptions associées aux UserVars du client NUT à jour tant que le host ESXi n’aura pas rebooté.
Mise à jour du 19/10/2022 : ESXi 8.0 est sorti ce 11/10/2022, seules les versions du module avec un numéro de version supérieur à 2.3.2 pourront s’installer sur cette nouvelle version de ESXi (abandon du support des binaires 32-bits et checksum SHA256 requis dans la signature du module).
Principe
La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Le schéma classique minimal des connexions entre les éléments d’un réseau électrique protégé par un onduleur est le suivant :
Câblage Onduleur
Cette solution n’est pas officiellement supportée par VMware et elle ne s’applique qu’à des hyperviseurs standalone. Elle ne peut pas convenir pour des fermes d’hyperviseurs en cluster de haute disponibilité sous le contrôle d’un vCenter. Seul le client NUT est ajouté à l’hyperviseur, l’onduleur doit être surveillé par un serveur NUT indépendant.
Caractéristiques et fonctionnalités
- La méthode d’installation utilise un fichier VIB (vSphere Installation Bundle). Il n’y a rien d’autre ce qui permet une installation rapide et sûre et une désinstallation propre en utilisant les standards de VMware.
- La compatibilité du module a été assurée pour qu’il fonctionne sur toutes les versions de ESXi entre 5.0 et 8.0. Cependant pour les versions 5.x l’installation automatique par déploiement de ViB n’est pas possible, il faut l’installer manuellement en suivant les instructions ci-dessous et passer outre les avertissements de sécurité. A partir de la version 6.0 de ESXi il n’y a plus ce soucis.
- C’est un client NUT 2.8.1 qui est inclus dans le paquetage. Il peut se connecter aux serveurs avec une version plus ancienne (disons 2.6.4 mais je n’ai pas testé les serveurs plus anciens).
- Actuellement seule la version pour processeur x86 est disponible. Il n’y a pas de version pour ESXi ARM (je n’ai ni le besoin ni la plateforme de test/développement pour ça).
- Le client (secondary dans la terminologie NUT) peut se connecter au serveur (primary) en privilégiant une connexion SSL/TLS si elle est disponible. Il ne sera pas fait de vérification de validité de certificat serveur et il n’y a pas de certificat client configurable.
- Le client peut envoyer un mail très succinct à une adresse configurable lors de la réception d’un évènement onduleur (perte du secteur, batterie faible, engagement de l’arrêt, retour du secteur). L’outil mail est très simple et il récupère les informations pour l’envoi des messages du DNS (enregistrements MX). Vous pouvez aussi utiliser un relais SMTP personnel.
- Le client peut se connecter à plusieurs serveurs NUT s’il y a plusieurs onduleurs (cas des serveurs avec une redondance d’alimentation). Il utilisera le même compte et le même mot de passe pour se connecter aux différents serveurs NUT. A vous de déclarer ce compte sur tous les serveurs NUT.
- Normalement il est possible de préciser le port TCP de connexion au serveur NUT sous la forme onduleur@serveur:port mais ESXi impose des règles de firewall pour le trafic sortant et seul le port 3493 est autorisé. C’est le port par défaut des serveurs NUT.
- Il est possible de demander l’arrêt du système ESXi après un laps de temps sur batterie configurable. Le client reste à l’écoute de l’évènement batterie faible et le système entamera sa procédure d’arrêt soit après le temps imparti soit sur évènement de batterie faible, au premier des deux qui surviendra quand le système est sur batterie. L’attente est interrompue si le courant secteur est rétabli entre temps, mais si la procédure d’arrêt a déjà été initiée, elle ira jusqu’à l’extinction du host ESXi.
- Le redémarrage du serveur après une coupure de courant est aussi une phase importante mais c’est à vous de le prévoir avec d’autres outils. Personnellement (mais ce n’est qu’une suggestion) j’aime bien l’idée d’un chef d’orchestre qui redémarre automatiquement. Il surveille le retour des services tels que le réseau, le serveur NUT etc… et il envoie des trames WOL pour réveiller les machines dans l’ordre désiré. Configurez votre serveur NUT pour qu’il ordonne à l’onduleur de couper effectivement le courant pendant un petit laps de temps même si le courant est revenu pendant la procédure d’arrêt. La plupart des onduleurs ont cette fonction avec les libellés « Interval to wait after shutdown with delay command » et « Interval to wait before (re)starting the load ». Certains onduleurs ont aussi une valeur « Minimum battery level for restart after power off » qui est interessante pour attendre que l’onduleur ait suffisamment rechargé ses batteries avant de faire redémarrer le système. Le risque est de se retourner dans une situation où un second arrêt propre serait impossible si une nouvelle coupure de secteur se produit juste après le redémarrage (ce qui est plutôt fréquent).
- Le client tourne avec le compte root. C’est habituellement déconseillé par la documentation du projet NUT mais l’hyperviseur a un nombre très limité de comptes locaux. Ce nombre de compte s’est beaucoup réduit au fil des versions. Des comptes restants, root est le seul encore utilisable.
Téléchargement du module
Pour toutes les versions de ESXi, l’installation peut se faire en ligne de commande sur l’hyperviseur : un fichier TAR compressé doit être déposé sur l’hyperviseur.
Téléchargez ici le fichier
Télécharger “NutClient-ESXi (binaires)” NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz – 821,90 Ko
A partir de ESXi 6.0 vous pouvez utiliser le bundle offline pour une installation en ligne de commande en appelant la commande « esxcli software vib install -d » . Ou par le manager de mises à jour du vCenter si vous en avez un.
Téléchargez ici le bundle offline.
Télécharger “NutClient-ESXi (offline bundle)” NutClient-ESXi-2.8.2-2.6.2-offline_bundle.zip – 823,83 Ko
Vous pouvez créer votre propre package personnalisé à partir des sources. Elles sont distribuées sous licence GPLv3 (GNU Public License version 3). Utilisez un environnement de développement linux 64 bits tel que CentOS 7 avec les outils de compilation et développement C habituels. Un fichier INSTALL décrit la procédure. Les sources sont disponibles également dans un dépot git publique : NutClient-ESXi
Téléchargez ici les sources
Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.8.2-2.6.2-src.tar.gz – 121,64 Ko
Installation
Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Cela est fait à partir de l’interface d’administration ESXi ou de la console DCUI. A partir de l’interface d’administration : dans la rubrique gérer de votre hôte, onglet services, dans la liste sélectionnez TSM-SSH et démarrez le service. Le service ssh sera actif jusqu’au prochain reboot de l’hyperviseur ou pendant un temps limité selon la version de votre ESXi.
Copiez le fichier NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz dans le répertoire /tmp du host ESXi. Ici je vous donne l’exemple depuis une machine linux (remplacez 10.0.0.8 par l’adresse IP du host ESXi ou son nom FQDN). Depuis Windows vous pouvez utiliser l’outil gratuit WinSCP.
[root@linux ~]# scp NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz root@10.0.0.8:/tmp The authenticity of host '10.0.0.8 (10.0.0.8)' can't be established. RSA key fingerprint is 89:49:ce:6d:... ...:40:76:7a:4a:fe. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.8' (RSA) to the list of known hosts. Password: (saisir le mot de passe administrateur ESXi) NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz 100% 869KB 1.9MB/s 00:00
Passez votre hyperviseur au niveau d’acceptance Communauté si ce n’est pas déjà fait !
Connectez-vous root en ssh à l’hôte ESXi et tapez la suite de commandes suivantes pour installer le VIB (l’opération peu être longue si votre système est installé sur une clé USB lente) :
~ # cd /tmp /tmp # tar -xzf NutClient-ESXi-2.8.2-2.6.2.x86_64.tar.gz /tmp # sh upsmon-install.sh Installation Result Message: Operation finished successfully. Reboot Required: false VIBs Installed: Margar_bootbank_upsmon_2.8.2-2.6.2 VIBs Removed: VIBs Skipped:
Vous n’avez pas besoin de rebooter pour commencer à utiliser le client NUT sur votre système. Vous devez toutefois le configurer avant son premier lancement.
Vous pouvez supprimer les fichiers qui ont été créés dans /tmp et désactiver le service SSH
Configuration
A l’aide de l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez les paramètres avancés de l’onglet Système et filtrez la liste sur UserVars.Nut, vous avez 8 variables à configurer :
Configuration du client NUT sous ESXi7
- UserVars.NutUpsName : Nom de l’onduleur sur le serveur NUT (sous la forme nom_onduleur@nom_ou_ip_serveur). Plusieurs onduleurs peuvent être saisis séparés par un espace. Il n’y aura pas d’arrêt système tant que le dernier onduleur encore debout n’aura pas donné l’ordre d’arrêt.
- UserVars.NutUser : Nom du compte de connexion au serveur NUT
- UserVars.NutPassword : Mot de passe du compte de connexion au serveur NUT
- UserVars.NutFinalDelay : Secondes qu’il faudra attendre après la réception de l’événement batterie faible pour procéder à l’arrêt du système
- UserVars.NutOnBatteryDelay : Délai en secondes après le début du passage sur batterie de l’onduleur pour stopper le système. Si la valeur est 0 alors le client NUT attendra l’évènement batterie faible pour stopper le système. La valeur par défaut est 0, c’est le fonctionnement normal pour garder le système en fonctionnement le plus longtemps possible. Si l’onduleur repasse sur secteur avant la fin du délai, le système ne sera pas stoppé.
- UserVars.NutSendMail : A mettre à 1 pour que le client NUT envoie un e-mail à chaque évènement important de l’onduleur. La valeur 2 permet d’avoir dans le mail l’état des l’onduleurs lors de l’évènement.
- UsersVars.NutSmtpRelay : Nom ou IP d’un relai SMTP pour y faire transiter le mail. Laisser vide ou saisissez none pour ne pas utiliser de relai (none par défaut).
- UserVars.NutMailTo : Adresse e-mail à laquelle envoyer les évènements de l’onduleur
- UserVars.NutMinSupplies : Pour les systèmes multi onduleurs. Le nombre d’onduleurs qui doivent être en capacité d’alimenter le système avant d’entamer un arrêt. Ce nombre doit être inférieur ou égal au nombre d’onduleurs définis dans UserVars.NutUpsName. Si vous ne respectez pas cette contrainte, le client ne démarrera pas. Avec un seul onduleur, laissez la valeur à 1.
Notez qu’à chaque modification de ces paramètres il sera nécessaire de faire un arrêt/relance du service pour leur prise en compte.
Lancement du service
A l’aide de l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez l’onglet Services, trouvez et sélectionnez le service NutClient dans la liste:
Client NUT dans les services ESXi7
Dans les actions du service, choisissez la stratégie démarrage (Démarrer et arrêter avec l’hôte me semble un bon choix). Vous pouvez également le démarrer immédiatement ou l’arrêter.
Configuration du lancement de NUT Client
Astuces
Utilisez la rubrique démarrage automatique de l’onglet Système de l’hôte ESXi pour décider de l’ordre de démarrage et d’arrêt (ou suspension) des machines virtuelles. Cet ordre sera respecté par la procédure d’arrêt sur alerte onduleur. Un bug de ESXi fait que les valeurs par défaut ne sont pas respectées. Vous devez configurer ces paramètre pour chaque VM au moins une fois (quitte à la dé-configurer ce qui la fera réellement suivre les règles par défaut).
Important : L’arrêt propre des OS dans les machines virtuelles n’est possible que si les vmware tools sont installées. Sinon l’arrêt sera brutal, préférez alors une suspension dans la configuration d’arrêt de la VM.
Là encore je rappelle que cette solution n’est pas adaptées aux fermes cluster avec haute disponibilité. Si HA est activé sur la machine hôte le mécanisme d’arrêt propre des VM n’est plus respecté et l’arrêt sera brutal pour toutes les VM.
UEFI secure boot
Si votre hôte ESXi est configuré pour booter en mode UEFI secure boot, l’installation du ViB restera compatible avec cette configuration. En revanche vous ne pouvez pas descendre le niveau d’acceptation à CommunitySupported quand secure boot est activé. Vous devrez :
- rebooter pour aller dans les paramètres UEFI de votre carte mère
- désactiver le secure boot dans les paramètres UEFI de votre carte-mère
- booter (sans secure boot)
- descendre le niveau d’acceptation à CommunitySupported
- Rebooter une seconde fois pour retourner dans les paramètres UEFI
- réactiver le secure boot
- booter (avec secure boot).
Vous aurez secure boot actif et le niveau d’acceptation minimal à CommunitySupported.
Désinstallation
Pour désinstaller le client NUT, utilisez le script upsmon-remove qui se trouve dans le fichier que vous avez téléchargé :
/tmp # sh upsmon-remove
Test
Pour estimer le temps nécessaire au serveur pour s’éteindre sur alerte onduleur tapez la commande « /opt/nut/sbin/upsmon -c fsd » sur le host ESXi (par ssh ou sur la console). La procédure d’arrêt est immédiatement lancée (ne faites pas ça si vous n’aviez pas prévu d’arrêter votre machine).
Hi I was trying to install NUT Client on my machine. But I get the following error:
Failed to create ramdisk stagebootbank: Errors:
No space left on device
cause = (210, ‘Cannot reserve 210 MB of memory for ramdisk stagebootbank’)
I tried to look up for some solutions online, I found some issue on ESX forums, the do not seem to be related to what I get. Thus I cannot find the solution, and I wounder if anyone here could give me a hint?
As far as I check my ramdisk on /tmp has 256 MB size.
How much RAM do you have in your ESXi box? Which ESXi version are you using?
ESXi Version: 7.0 Update 3
4GB of RAM is installed on system
That’s the problem. On my lab I had to set the RAM to 4.5GB to be able to install the package under 7.0u3. (My ESXi for testing is a nested VM)
Thanks so much. I will upgrade my system.
It is funny that my box is actually on the edge. I would not have noticed if I had 5GB.
BTW great job with this project. Thanks.
Merci René pour cet article fort intéressant. J’ai cependant deux questions.
Comment l’arrêt système est t’il conduit ? Arrêt propre avec arrêt des VMs puis mise en maintenance puis arrêt de l’hôte ou arrêt direct de l’hôte ? Pas de possibilité de mise en veille ?
Sinon concernant le redémarrage des systèmes, quel outil pourrait faire l’affaire afin de communiquer avec l’UPS lors d’un retour secteur ?
Merci d’avance pour tes futures réponses.
Cordialement
C’est un arrêt propre du host ESXi qui va stopper les VM avant l’arrêt de la machine physique. Le host n’est pas mis en mode maintenance sinon au redémarrage il reste en mode maintenance et les VM ne redémarrent pas automatiquement. L’arrêt respectera les réglages de démarrage/arrêt automatique (autostart) programmés dans le host (ou le vCenter). Donc en fonction de l’option choisie pour chaque VM les actions suivantes seront prises :
Arrêter : si les VMware tools sont installés dans la VM c’est un arrêt propre, sinon c’est un arrêt brutal de la VM.
Interrompre: la VM est mise en veille prolongée. Pas besoin des VMware tools.
Mettre hors tension : arrêt brutal systématique de la VM.
Je vous conseille de ne pas faire confiance aux paramètres par défaut et de déclarer l’action pour chaque VM. Par le passé un bug faisait que les nouvelles VM ne prenaient pas les paramètres par défaut et l’arrêt était systématiquement brutal. Je ne sais pas dire si c’est toujours le cas.
Pour le retour secteur un bon onduleur doit avoir une option pour configurer un arrêt systématique de l’alimentation même en cas de retour du courant pendant la procédure d’arrêt, une fois lancée. Certains onduleurs ont en plus une sécurité pour ne rétablir le courant qu’une fois un certain seuil de charge de la batterie atteinte. Je peux vous parler de ma configuration personnelle pour le redémarrage. Une machine physique (mon serveur NUT, qui pourrait être un Raspberry Pi de faible puissance) a sa carte mère configurée pour booter à la mise sous tension. Les hosts ESXi restent éteint mais alimentés. L’option WOL (wake-on-lan) est activée dans leur BIOS. Une fois mon serveur NUT démarré, des tests sont fait pour vérifier si les prérequis sont réunis pour le bon fonctionnement des hosts ESXi (routeur réseau, switch démarrés, serveurs NFS prêt, etc…). Quand c’est enfin le cas il envoie des trames WOL (wake on lan) pour démarrer les hosts dans l’ordre désiré. Les ESXi démarrent et relancent les VM selon la configuration du démarrage/arrêt automatique.
Merci pour ces précisions très utiles et intéressantes. Concernant le redémarrage du RPI avec la séquence d’envoi de trames WOL cela voudrait t’il dire que le RPI a été le dernier rempart qui lui pour le coup s’est éteint brutalement quand l’UPS coupe ses sorties ? Car une commande sudo halt juste avant ne permettra pas un reboot au retour du secteur non ? Quoique je ne vois pas ce qui bloquerait le redémarrage si l’alim a bien été coupée bien sûr.
D’un autre côté un pi qui s’arrête brutalement n’est pas un drame à côté d’autres devices. C’est surtout ce point qui m’interroge. Bonne journée à vous.
J’ai pris pour exemple un RPI car c’est un petit équipement peu gourmand qui ne tire pas beaucoup sur la batterie de l’onduleur. Un RPI de première génération fait parfaitement l’affaire. Si le RPI héberge le serveur NUT il est aussi en liaison directe avec l’onduleur par USB pour lire son état. En principe le serveur NUT envoie l’évènement LOWBATT (batterie faible) à tous ses clients pour leur dire qu’il est temps de s’éteindre. Après ça il attendra que les clients se déconnectent, preuve qu’ils ont fini de s’éteindre, ou que le temps FINALDELAY se soit écoulé (au premier des deux). Il entame alors sa propre séquence d’arrêt et envoie finalement un message à l’onduleur pour lui dire de couper le courant à son tour. Quand le courant revient, le RPI est de nouveau alimenté et redémarre automatiquement. Un serveur NUT est aussi son propre client mais de type primary, alors que les clients distants sont de type secondary. Le primary attend que les secondary soient partis puis il exécute aussi une procédure d’arrêt propre. Il est donc important sur un serveur de correctement configurer le FINALDELAY pour donner le temps aux clients de s’éteindre correctement, choisir un bon seuil de batterie faible sur l’onduleur pour que la charge batterie soit suffisante pour tenir pendant ce FINALDELAY. Définir un délai sur l’onduleur qui permet au serveur NUT de s’éteindre quand il envoie à l’onduleur l’ordre SHUTDOWN_WITH_DELAY (un RPI peut s’éteindre correctement en quelques secondes). Enfin je dirais de configurer aussi sur l’onduleur l’attente minimale avant de remettre le courant pour être sûr qu’il s’écoule au moins une minute par exemple entre l’arrêt et le redémarrage de l’alimentation. Si c’est trop rapide, certains équipement pourraient ne pas redémarrer si les condensateurs des alimentations n’ont pas eu le temps de se décharger complètement. Tout cela dépasse largement le cadre de cet article, il faut plutôt regarder du côté du projet NUT et de sa documentation et du manuel de l’onduleur car chaque constructeur a sa façon de coder tout ça. Certains définissent le seuil de batterie faible sur un % de charge batterie et d’autres sur un laps de temps qui est calculé par l’onduleur pour estimer la durée de la batterie selon la charge en cours.
C’est beaucoup plus clair pour moi. On s’aperçoit vraiment que nut un outil puissant à condition d’avoir accès à la notice complète de l’onduleur, ce qui n’est pas toujours évident.
Merci René pour ces quelques lignes.
Bonjour René,
En pleine configuration de ton outil génial, je me demandais comment paramétrer le serveur mail pour l’envoi de notifications.
Bonne journéé
L’envoi d’un mail n’est pas obligatoire. Dans un premier temps on peut juste mettre 1 ou 2 comme option dans UserVars.NutSendMail selon le degré d’information souhaité et une adresse mail destination dans UserVars.NutMailTo. Il ne faut pas oublier de faire un A/R du service NutClient dans ESXi/vCenter pour prendre en compte le changement des paramètres. Pour tester, il suffit de se connecter au serveur ESXi en ssh et taper
/opt/nut/bin/notify.sh TESTSi le mail de test est reçu il n’y a rien d’autre à faire. Sinon il faudra peut-être préciser un relais mail SMTP dans UserVars.NutSmtpRelay (et refaire un A/R du service)
Justement où faut t’il aller pour le réglage du SMTP et de l’authentification, l’activation de la sécurité (SSL/TLS) et la définition du port ?
Il n’y a aucun réglage de ce type. Pas d’authentification et pas de support de SSL. C’est vraiment un service d’envoi de mail minimaliste plutôt destiné à un réseau interne.
Donc cela veut dire que je dois configurer un relai pour envoyer une notification sur n’importe quelle adresse email. Merci pour l’éclaircissement.
Autre interrogation, je vois que l’hôte s’éteint tout seul à la suite de la réception de l’évènement lowbatt. Ca veut dire qu’en gros ce n’est pas le serveur nut qui initie l’arrêt via un FSD. Dans la configuration du serveur nut (upsmon.conf) on configure l’arrêt du rpi via un shutdown. Par contre comment l’UPS s’éteint par la suite ? Quelle est la commande à envoyer ( avant l’extinction du RPI bien sûr) pour que l’UPS coupe complètement le courant. J’ai beaucoup de mal avec la compréhension cette partie.
FSD n’est jamais envoyé par le serveur. C’est le client qui prend la décision du SHUTDOWN après l’expiration du délai FINALDELAY suivant la réception de LOWBATT. SI vous utilisez un raspberry il y a de fortes chances que la distribution linux soit raspbian, vous avez donc installé les packages nut-client et nut-server. Dans nut.conf le MODE est netserver, dans upsmon.conf il faut POWERDOWNFLAG /etc/killpower. Normalement tout est déjà prêt dans le système pour executer l’ordre ‘upsdrvctl shutdown’ lors de la procédure d’arrêt quand ce le fichier /etc/killpower existe. C’est cette commande exécutée à la toute fin du shutdown qui donne l’ordre à l’onduleur de couper le courant (pas immédiatement mais dans quelques dizaines de secondes pour que le système puisse executer les toutes dernière instructions d’arrêt du système). Ca dépasse largement le cadre de cet article, c’est expliqué dans la documentation de NUT, mais pour un néophyte je comprend que ce n’est pas facile à trouver.
Oui merci beaucoup.
Retour d’expérience après un test « grandeur nature ». Et bien ça n’est pas formidable.
J’ai 3 NUCs à éteindre ainsi qu’un NAS qui lui ne dépend du serveur NUT mais surveille le SNMP pour la consigne LOWBATT.
Sur un des NUCs pas de problème, j’ai réglé l’extinction à 300 secondes et ça fonctionne parfaitement.
En revanche sur le reste j’ai demandé une extinction au passage en LOWBATT + 5 secondes (FinalDelay)
L’onduleur passe bien en LOWBATT en dessous de 20% mais rien ne se passe, ni au niveau des NUCs, ni au niveau du NAS (SNMP).
Par contre l’onduleur se coupe comme prévu à 15 % (réglage sur le 5P 850i directement) mais pour le coup on a eu un superbe arrêt brutal sur le NAS et les NUCs. Heureusement les VMs et le NAS fonctionnent bien après redémarrage mais c’est un peu désagréable.
D’autre part après l’extinction du NUC à 300 secondes il m’a été impossible de le redémarrer via une commande WOL, ce qui d’habitude fonctionne très bien lorsque j’arrête mon hôte manuellement.
Donc pour finir, qu’est ce que j’ai bien pu fabriquer pour que ça ne fonctionne pas ?
Voilà ma conf ci dessous merci.
NOTIFYMSG ONLINE « ONLINE %s »
NOTIFYMSG ONBATT « ONBATT %s »
NOTIFYMSG LOWBATT « LOWBATT %s »
NOTIFYMSG FSD « FSD %s »
NOTIFYMSG COMMBAD « COMMBAD %s »
NOTIFYMSG COMMOK « COMMOK %s »
NOTIFYMSG SHUTDOWN « SHUTDOWN %s »
NOTIFYMSG REPLBATT « REPLBATT %s »
NOTIFYMSG NOCOMM « NOCOMM %s »
NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMBAD SYSLOG+EXEC
NOTIFYFLAG COMMOK SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+EXEC
NOTIFYFLAG NOCOMM SYSLOG+EXEC
#NOTIFYMSG type message
POWERDOWNFLAG /var/lib/nutsoft/killpower
#POWERDOWNFLAG /var/tmp/killpower
#Dans la doc :
#POWERDOWNFLAG /etc/killpower
SHUTDOWNCMD « /sbin/shutdown -h +10 »
FINALDELAY 400
MINSUPPLIES 1
RBWARNTIME 604800
NOCOMMWARNTIME 21600
POLLFREQ 15
POLLFREQALERT 30
HOSTSYNC 15
DEADTIME 45
Avant d’en arriver à LOWBATT, vous recevez bien la notification ONBATT sur chaque client ? Si ce n’est pas le cas c’est que vos clients NUT ne sont pas connectés au serveur NUT. Difficile alors de recevoir les notifications.
Comment vérifier que cette notification ONBATT a été reçue sur chaque client ? J’ai forcément un nuc qui est connecté car il s’éteint à 300 secondes comme demandé donc il reçoit forcément la notif ONBATT. Les autres clients ont aussi un login au même titre que le client qui s’éteint 300 secondes après le ONBATT.
Dans la log systeme vous devriez voir une ligne de type :
2024-01-25T15:36:17.357Z upsmon[134895]: UPS ups2@nutserv on batterySur ESXi c’est dans /var/log/syslog.log
Merci pour cette exploration très instructive. En réalité je pense que mes VMs sont bien arrêtées correctement. Par contre pour l’hôte j’ai un doute.
Pourriez vous me dire si une ligne du type
2024-01-24T14:47:42.055Z In(14) backup.sh[944820]: Using key ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx to encrypt
serait la dernière à apparaitre avant l’extinction de l’hôte car sur les deux clients j’ai cette ligne.
D’autre part j’ai bien la notification onbatt puis lowbatt et enfin
2024-01-24T14:47:38.790Z No(13) VMware.shutdown.[888292]: Stopping VMs
Je suis surpris de la rapidité d’arrêt de l’UPS juste après les VMs et je me demande si mon RPI a bien eu le temps de s’éteindre aussi dans la foulée.
Je viens de voir que votre configuration serveur a un paramètre beaucoup trop bas : HOSTSYNC est à 15 secondes, c’est le temps que donne le primaire aux secondaire pour réaliser leur arrêt avant de passer en force à la suite. Sur ma configuration j’ai 360 car ça représente 6 minutes, le temps maxi que je donne à mon ESXi pour s’arrêter proprement. Habituellement il a besoin de moins de temps car je me contente de mettre mes VM en hibernation et pas de les stopper.
Ah je comprends mieux du coup. Je suis confus aussi avec le FINALDELAY du serveur RPI. Le FINALDELAY est le temps entre la notification lowbatt pour arrêter le RPI ou l’UPS ? Je suis un peu perdu et les explication ici et là ne m’aident pas.
Le FINALDELAY est une pause entre la décision de shutdown et l’exécution réelle de la SHUTDOWNCMD. Cette pause permet à la NOTIFYCMD de s’exécuter sans être interrompue par exemple ou pour tout autre usage. Toutefois il n’est pas recommandé d’avoir une valeur trop élevée car à cet instant la batterie est déjà bien fatiguée.
Bonjour René,
Bon après quelques réglages ça fonctionne beaucoup mieux. Par contre je me demande comment annuler un arrêt quand le secteur revient juste en période LOWBATT et là je sèche un peu. Auriez vous un tuyau là dessus car en plus l’onduleur ne redémarre pas tout seul dans ce cas. Merci
Une fois l’évènement LOWBATT reçu par le client il attendra un délai assez court avant de lancer le SHUTDOWN. A partir de là plus rien ne peut empêcher la procédure d’arrêt d’aller jusqu’à son terme. C’est volontaire, une procédure d’arrêt ne peut pas être annulée. Le serveur NUT doit demander à l’onduleur de s’éteindre en dernier et de couper l’alimentation. Si le secteur est revenu entre temps tout dépendra des capacités de votre onduleur pour gérer cette éventualité. Sur les onduleurs haut de gamme c’est habituellement prévu et configurable. Sur mon APC SmartUPS 3000, il dispose de trois réglages :
– Interval to wait after shutdown with delay command (seconds) : combien de temps attendre pour couper le courant une fois l’ordre de coupure reçu du serveur.
– Interval to wait before (re)starting the load (seconds) : combien de temps attendre pour rétablir le courant une fois le secteur rétabli.
– Minimum battery level for restart after power off (percent) : quel niveau de charge batterie doit-on avoir atteint pour rétablir le courant après un arrêt.
J’ai un Eaton Ellipse 1000 qui dispose des deux premiers réglages mais pas du troisième. Il est aussi beaucoup moins cher, moins précis et moins performant.
Si votre onduleur dispose de ces réglages il est peut-être en train d’attendre d’avoir suffisamment rechargé ses batteries avant de remettre sous tensions les équipements qui y sont attachés. C’est une sécurité dans le cas où une seconde coupure secteur se produirait alors que les équipements sont en train de démarrer.
Je dispose d’un 5P850i, je vais vérifier si l’option existe.
Sinon dernière question car j’ai un comportement étrange pour le redémarrage de mes hôtes.
Il m’est impossible de les redémarrer via WOL alors que lors d’un arrêt via l’interface de vSphere je n’ai aucun problème. Je précise que j’ai désactivé le mode S4-S5 deep dans mon bios. De plus les cartes réseau semblent être en activité mais impossible de redémarrer suite à un arrêt via NUT.
Quelle commande votre script envoie au système pour l’éteindre ( /opt/nut/sbin/upsmon -c fsd ) car j’aimerais régler ce problème ? Merci d’avance.
La commande d’arrêt système ESXi est poweroff
Bonjour,
Bon cette fois mes séquences sont vraiment abouties mais un détail me pose problème. Mon onduleur ne s’éteint pas après l’arrêt du RPI , j’ai bien indiqué un délai killpower a 30 secondes mais rien ne se passe. Ou se trouve la commande d’arrêt dans le pi pour que je voie où ça coince ? Comment configurer l’arrêt de l’UPS ?