web-dev-qa-db-fra.com

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 machines virtuelles hébergées sur celui-ci.

Je peux voir qu'APC a une solution documentée à l'aide de leur arrêt réseau PowerChute , mais cela implique de configurer 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?.

vmware-esxielectrical-powerapc-smart-ups
18
dunxd

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 contient des informations sur l'utilisation de la solution approuvée par 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

5
Dave M

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é à ce VM à l'aide de l'option de passage USB ESXi.

Configuration logicielle: Maître NUT (Network UPS Tools) en cours d'exécution dans la machine virtuelle et esclave ESXi NUT natif en cours d'exécution sur l'hôte ESXi.

Logique d'arrêt: VM exécute le pilote UPS usbhid-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 à upsd et lance l'arrêt. L'hôte ESXi exécute la 2ème instance de upsmon qui se connecte également au même VM 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 le VM initie upssched 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. Le drapeau FSD est également lu par ESXi upsmon, qui initie l'arrêt de l'hôte ESXi.
  6. ESXi Host arrête toutes les machines virtuelles une par une. L'important est que VM qui exécute l'upsd soit arrêté en dernier (en utilisant la configuration de séquence de démarrage/arrêt d'ESXi).
  7. Important: ce VM doit avoir installé les outils vmware. 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), 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, l'invité VM s'arrête.
  9. ESXi voit le dernier VM état de mise hors tension 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 UPS 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 surveillance VM de l'intérieur (le script vmware-tools n'est pas exécuté), ou s'il s'agit d'un arrêt initié par l'hôte ESXi VM arrêt (non/etc./killpower, donc pas de chargement de l'onduleur), ou s'il s'agit d'un arrêt ESXi (le même). La seule chose importante est d'avoir ce VM en cours d'exécution 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, il me reste environ 1 minute et 2 minutes de plus je réserve juste au cas où).

Mon UPS surveillant Linux VM 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 faut environ 22 MHz de partages de processeur ESXi et environ 10 Mo de RAM actifs 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.

21
Oleg Semyonov

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 un Linux VM - 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 périphérique APC via USB à l'hôte ESXi et passez-le à la machine virtuelle Linux.
    • Assurez-vous que le contrôleur USB que vous ajoutez au VM 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. 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 -62 Dans 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 apcupsd sur Linux VM - dans Ubuntu, vous pouvez faire Sudo apt-get install apcupsd Pour installer la dernière version. Le projet NUT est aussi sympa mais je suis 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é Host afin que Plink ne l'invite plus lorsque nous l'exécutons via un script
  7. Modifiez /etc/apcupsd/apcupsd.conf Et modifiez les éléments ci-dessous pour 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 Assurez-vous également que /etc/default/apcupsd A ISCONFIGURED=yes
  8. Modifiez /etc/apcupsd/apccontrol Et faites défiler jusqu'au cas doshutdown. Faites en sorte que cela ressemble à ceci: 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 restart Et 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 VM (dans vSphere Web Client, accédez à: vCenter -> <your Host> -> Manage -> Settings -> VM Startup/Shutdown). Assurez-vous que l'action d'arrêt doit être fermée sur le système d'exploitation invité.

Une fois que ces choses sont en cours d'exécution, le scriptlet doshutdown 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 le package VMWare Tools dans chaque VM sur votre hôte pour effectuer un arrêt propre via le système d'exploitation invité. D'après mon expérience, il 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 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:
UPSTYPE net < your UPS control VM IP >:3551
Les entrées comme UPSCABLE et telles n'ont pas d'importance dans ce cas. Cela fonctionne également avec la version Windows de apcupsd (disponible ici ). Vous pouvez utiliser le apctray.exe Inclus pour vérifier l'état actuel des choses.

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

14
MrMajestyk

Vous pourriez 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 officiellement ne prend en charge qu'un nombre très limité de périphériques USB pour le passthrough , mais les gens ont attaché et passé à travers différentes classes de périphériques 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 celle-ci pour une machine virtuelle Linux CentOS .

4
the-wabbit

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

2
deveneyi

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.

1
HopelessN00b

Dans les temps anciens de 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 Red Hat uniquement , il était facile de configurer des règles pour gouverner un serveur connecté localement. Des notifications par e-mail de base pour UPC événements de batterie, événements d'alimentation de ligne et 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 ...

enter image description here

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 relais 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, je vais généralement avec 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 l'achat d'appareils SmartUPS au minimum ...

1
ewwhite

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 apcupsd VM doit être incluse dans/etc/ssh/keys-root/authorized_keys de l'hôte vmware.

0
Norberto Altalef

Consultez le lien suivant . Pas la solution la plus élégante, mais une solution très pratique et très simple. Il y a 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.

0
user207685