Arrêt de VMware ESXi déclenché par un onduleur APC connecté via USB

J'expédie un tas de serveurs ESXi 5.1 à des bureaux distants où ils seront alimentés via APC UPS.

Je voudrais que l'onduleur déclenche un arrêt du serveur connecté - je compterais alors sur la configuration ESXi pour prendre en charge l'arrêt / la suspension des VM hébergées sur celui-ci.

Je peux voir qu'APC a une solution documentée à l'aide de son arrêt réseau PowerChute , mais cela implique la configuration d'un serveur supplémentaire par bureau et nécessite des cartes réseau sur chaque onduleur. Nous utilisons généralement UPS sans carte réseau (par exemple Back-UPS Pro) - ils sont livrés avec un connecteur USB et ils sont facilement disponibles dans les endroits où se trouvent nos bureaux.

Comment puis-je connecter un onduleur à un hôte ESXi via USB, puis demander à ESXi de détecter une panne de courant et d'agir en conséquence? Quelqu'un a-t-il réussi à le faire?

Selon APC, cela n'est pas possible et vous avez besoin de l'arrêt du réseau Powerchute. Nous avons essayé plusieurs fois avec USB et n'avons trouvé aucune solution.

VMWare a des informations ici sur l'utilisation de la solution approuvée APC.

Penserait également que SmartUPS serait un meilleur choix et vous pouvez vous adapter à la carte réseau. Naturellement plus d'argent, mais si vos serveurs sont importants, ce coût en vaut la peine. Vous offre également plus de surveillance et d'alerte, ce qui pourrait être utile sur un site distant. Vous devez également garantir un temps d'exécution suffisant pour que toutes les machines virtuelles s'arrêtent proprement, puis arrêtent l'hôte

Oui c'est possible. Voici les détails de ma configuration similaire.

Configuration matérielle: APC Smart-UPS 1500 connecté à l'hôte ESXi 5.1 via USB. Une machine virtuelle Linux exécutée sur cet hôte ESXi. L'onduleur est connecté à cette machine virtuelle à l'aide de l'option de transfert USB ESXi.

Configuration logicielle: maître NUT (Network UPS Tools) exécuté sur la machine virtuelle et esclave natif ESXi NUT exécuté sur l'hôte ESXi.

Logique d'arrêt: VM exécute les usbhid-ups du pilote UPS qui est responsable de la communication avec UPS via USB. Le processus upsd se connecte à l'onduleur via le pilote usbhid-ups et surveille l'état de l'onduleur. Le processus maître upsmon exécuté sur la même machine se connecte à l' upsd et lance l'arrêt. L'hôte ESXi exécute la 2e instance de upsmon qui se connecte également à la même machine virtuelle upsd via le réseau interne.

En cas de panne de courant, la séquence suivante a lieu:

1. UPS via usbhid-ups rapporte à upsd une panne de courant.
2. (facultatif, utile si vous souhaitez arrêter en quelques minutes au lieu de batterie faible) upsmon sur la machine virtuelle lance un minuteur de 5 minutes. La minuterie est interrompue si l'alimentation est rétablie.
3. Lorsque la minuterie se déclenche ou lorsque l'onduleur signale une batterie faible, l'upsmon place le drapeau FSD (arrêt forcé) sur upsd.
4. Dans une configuration NUT autonome, l'indicateur FSD arrêterait la machine. Mais ici, la commande d'arrêt est remplacée par une simple journalisation comme "Je devrais arrêter maintenant mais j'attends l'hôte à la place". Et ne fait rien.
5. L'indicateur FSD est également lu par ESXi upsmon, qui initie l'arrêt de l'hôte ESXi.
6. L'hôte ESXi arrête toutes les machines virtuelles une par une. L'important est que la VM qui exécute l'upsd soit arrêtée en dernier (en utilisant la configuration de séquence de démarrage / arrêt ESXi).
7. Important: cette machine virtuelle doit disposer d'outils vmware installés. Lorsqu'il reçoit la commande d'arrêt invité de l'hôte, le script d'arrêt vmware-tools est en cours de démarrage. Ce script vérifie l' indicateur / etc / killpower . Si aucun indicateur, il ne fait rien (cela signifie l'arrêt Linux activé par l'utilisateur, pas l'événement UPS). Mais si l'indicateur existe (FSD actif), alors ce script envoie à l'onduleur la commande de mise hors tension différée (disons, en 3 minutes).
8. Après avoir exécuté le script vmware-tools, la machine virtuelle invitée s'arrête.
9. ESXi voit le dernier état de mise hors tension de la machine virtuelle et s'arrête (cela prend environ 1 minute car il n'y a aucune autre machine en cours d'exécution).
10. Dans les 2 minutes restantes, l'onduleur coupe l'alimentation.
11. Lorsque l'alimentation est rétablie, l'ESXi démarre et met sous tension toutes les machines virtuelles. La machine de surveillance de l'onduleur doit être démarrée en premier (la même configuration que pour l'ordre d'arrêt).

Téléchargements:

Le NUT pour Linux peut être installé à partir du package.

Le client NUT natif pour le serveur ESXi peut être téléchargé en utilisant le dernier lien sur cette page: http://www.networkupstools.org/download.html

Certains de mes scripts et fichiers de conf sont ici (seules les lignes modifiées sont affichées): http://pastebin.com/KkEeanK1

Remarques:

Bien sûr, il y a plus de détails et il m'a fallu un certain temps pour que cela fonctionne comme il se doit. Mais maintenant, il fonctionne très bien. Ce système prend en compte les cas où vous venez d'arrêter la machine virtuelle de surveillance de l'intérieur (le script vmware-tools n'est pas exécuté), ou s'il s'agit d'un arrêt de machine virtuelle lancé par l'hôte ESXi (pas d'indicateur / etc / killpower, donc pas de chargement de l'onduleur), ou s'il s'agit d'un arrêt ESXi (le même). Le seul important est d'avoir cette machine virtuelle exécutée dès que possible après le démarrage de l'hôte, et de l'arrêter en dernier (donc le temps d'arrêt de l'hôte est prévisible - comme dit ci-dessus, c'est environ 1 minute pour moi et 2 minutes de plus je réserve juste au cas où).

Mon UPS surveillant la machine virtuelle Linux est également un serveur de partage Samba / NFS pour le stockage de sauvegarde, le serveur NAT / DHCP pour les machines virtuelles et certains autres services légers. Il prend environ 22 MHz de partages de processeur ESXi et environ 10 Mo de RAM active lorsqu'il est inactif. En raison de l'utilisation du NUT, vous pouvez alimenter plus d'appareils à partir du même onduleur si nécessaire, et tout cela peut être arrêté sans problème. Aucune carte de moniteur réseau PowerChute et / ou coûteuse n'est requise.

Super question. Il est en fait possible de le faire très bien - au moins sur certaines configurations. J'ai essayé la recette suivante sur un certain nombre d'hôtes ESXi 5.5. Fondamentalement, la solution se présente comme suit:

1. Activez l'accès SSH sur votre hôte ESXi
2. Créer une machine virtuelle Linux - j'utilise Ubuntu. Vous n'avez besoin que d'une configuration très minimale - pas d'interface graphique ou quoi que ce soit.
3. Connectez votre appareil APC via USB à l'hôte ESXi et passez-le à la machine virtuelle Linux.
   • Assurez-vous que le contrôleur USB que vous ajoutez à la machine virtuelle correspond au contrôleur USB physique réel auquel le périphérique APC est connecté, c'est-à-dire n'ajoutez un contrôleur XHCI que si le périphérique physique est un périphérique USB3. Les incompatibilités semblent causer des problèmes étranges dans le pilote de périphérique USB Linux.
   • Si les choses ne fonctionnent pas et que vous voyez des erreurs comme ctrl urb status -62dans dmesg, il est probable que le contrôleur physique ne correspond pas à celui de votre machine virtuelle. S'ils correspondent - eh bien, c'est un problème. J'ai une configuration avec ce genre de problème et aucune vraie solution.
4. Installer apcupsdsur la machine virtuelle Linux - dans Ubuntu, vous pouvez faire sudo apt-get install apcupsdpour installer la dernière version. Le projet NUT est également sympa mais je suis un traditionaliste.
5. Installez l'utilitaire plink en faisant sudo apt-get install putty-tools
6. Connectez-vous à votre hôte ESXI en faisant plink root@<your ESXi host IP>. Vous pouvez immédiatement fermer la connexion. L'objectif est de sauvegarder la clé d'hôte afin que plink ne l'invite plus lorsque nous l'exécutons via un script
7. Modifier /etc/apcupsd/apcupsd.confet modifier les éléments ci - dessous afin qu'ils correspondent: UPSNAME < the name you'd like your UPS to have > UPSCABLE usb UPSTYPE usb # DEVICE DIRECTIVE should be blank for USB DEVICE Veillez également à ce que /etc/default/apcupsdaISCONFIGURED=yes
8. Modifiez /etc/apcupsd/apccontrolet faites défiler jusqu'au doshutdowncas. Faites comme ça: doshutdown) echo "UPS ${2} initiated Shutdown Sequence" | ${WALL} # Shut down indirectly by triggering the ESXi host to do the # shutdown via VMWare tools /usr/bin/plink root@< your ESXi host IP > -pw < your root pw > "/sbin/shutdown.sh && /sbin/poweroff" ;;
9. Redémarrez apcupsd en utilisant sudo service apcupsd restartet voyez si les choses fonctionnent en appelant apcaccess. Sinon, vérifiez les journaux et dmesg
10. Assurez-vous que toutes les machines virtuelles qui doivent s'arrêter correctement en cas de panne de courant ont installé VMWare Tools. Assurez-vous également qu'ils font partie de la liste de démarrage / arrêt de la machine virtuelle (dans vSphere Web Client, allez à:) vCenter -> <your host> -> Manage -> Settings -> VM Startup/Shutdown. Assurez-vous que l'action d'arrêt consiste à arrêter le système d'exploitation invité.

Une fois que vous avez ces choses en cours d'exécution, le doshutdownscriptlet de l'étape 8 est appelé en cas de panne de courant. C'est à son tour invoque le script shutdown.sh sur l'hôte ESXi, qui signale au package VMWare Tools dans chaque VM sur votre hôte de faire un arrêt propre via le système d'exploitation invité. D'après mon expérience, cela fonctionne mieux que le logiciel PowerChute d'APC.

Si vous souhaitez surveiller les choses à partir de vos machines virtuelles, vous pouvez configurer sur elles des instances d'apcupsd esclaves qui se connectent à la machine virtuelle Linux de contrôle de l'onduleur maître. Vos fichiers esclaves apcupsd.conf devraient avoir une entrée comme celle-ci: les
UPSTYPE net < your UPS control VM IP >:3551
entrées comme UPSCABLEet telles n'ont pas d'importance dans ce cas. Cela fonctionne également avec la version Windows de apcupsd(disponible ici ). Vous pouvez utiliser le inclus apctray.exepour vérifier l'état actuel des choses.

Je pense que cela le couvre à peu près.

Vous pouvez envisager d'utiliser la fonctionnalité de relais de périphérique USB à un invité exécutant PowerChute ou un autre logiciel capable de surveiller la santé de l'onduleur et capable de déclencher un arrêt sur l'hôte ESXi (par exemple apcupsd ). ESXi ne prend officiellement en charge qu'un nombre très limité de périphériques USB pour le relais , mais les gens ont attaché et traversé différentes classes d'appareils depuis un certain temps déjà avec un succès variable, mais l'APC UPS USB semble fonctionner selon cette procédure pas à pas pour une machine virtuelle Windows ou celui-ci pour une machine virtuelle Linux CentOS .

Jetez un œil à vSphere Management Assistant (vMA) à partir d' ici Nous l'utilisons à mon bureau pour faire ce que vous essayez, cependant avec Smart-UPS connecté via USB plutôt que Back-UPS.

Bien que possible (probablement / généralement), je ne pense pas qu'un arrêt automatisé d'un ordinateur sur batterie soit une bonne idée. Si vous allez faire cela, alors pour la plupart des intentions et des buts pratiques, vous devriez probablement vous épargner l'argent d'un onduleur alimenté par batterie et laisser la perte d'alimentation arrêter votre machine pour vous. (Certes, un arrêt propre est toujours préférable à une perte de puissance, mais vous semblez manquer d'avoir une autonomie de plus de quelques minutes si vous éteignez automatiquement tout lorsque vous perdez l'alimentation électrique. )

La façon dont je l'ai toujours géré est d'avoir une alerte de surveillance des SA lorsque l'alimentation est coupée, afin que les SA puissent utiliser leur matière grise pour décider quand (ou même si) d'arrêter les serveurs. Si c'est une brève panne, ce n'est peut-être pas une bonne idée d'arrêter les serveurs du tout, ou vous pouvez laisser certains serveurs opérationnels aussi longtemps que possible, et les arrêter uniquement avant que la batterie ne meure. Me semble vraiment être une tâche de prise de décision mieux adaptée à l'homme qu'une simple règle.

Dans l' ancien temps des installations baremetal , APC PowerChute Plus était une partie essentielle de mon processus d'installation. En utilisant le simple câble de signalisation série et leur binaire uniquement Red Hat , il était facile de configurer des règles pour gouverner un serveur connecté localement. Des notifications par e-mail de base pour les événements de batterie UPC, les événements d'alimentation de ligne et les actions d'arrêt étaient disponibles:

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

UPS on battery: Blackout 000.0 V. 

et

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

Normal power restored: UPS on line.  

ou

POWERCHUTE MAIL MESSAGE
Message from PowerChute@Bonanza:

Shutdown started.  

Plus une interface raisonnable pour voir ce qui se passait ...

Ce logiciel est finalement devenu commercial (ou a été enterré sur le site Web d'APC). Il y avait quelques approches open source pour fournir quelque chose de similaire. Mais tout cela se complique avec des hôtes VMWare ESXi uniques.

Il semble que c'est quelque chose que VMWare aurait dû intégrer à l'hyperviseur de base. C'est basique et pourrait offrir un niveau de protection décent aux utilisateurs. Les remèdes les plus courants que je vois maintenant sont le transfert USB vers une machine virtuelle dédiée, une approche démon réseau ou faire ce que je fais; ne pas configurer d'arrêt automatique ou de batterie ...

Certes, j'utilise généralement un onduleur qui peut prendre en charge la charge du système pendant une heure ou plus, mais des pannes prolongées se produisent. Une alternative est peut-être de collecter quelques cartes d'interface réseau à faible coût ou remises à neuf et de prévoir au moins d'acheter des appareils SmartUPS ...

Consultez le lien suivant . Pas la solution la plus élégante, mais une solution très pratique et très simple. Il existe des inconvénients possibles en termes de sécurité (en fonction de la conception particulière de votre réseau, des invités chargés sur les hôtes et des accès des utilisateurs à ces invités, mais vous pouvez passer cet appel.

J'ai utilisé la solution MrMajestyk et j'ai seulement changé l'accès ssh via plink avec un accès ssh sans mot de passe en utilisant la clé publique rsa. La clé rsa générée dans la machine virtuelle apcupsd doit être incluse dans / etc / ssh / keys-root / authorized_keys de l'hôte vmware.