Pourquoi le signal d’arrêt de l’onduleur atteint-il l’hôte, mais pas ses machines virtuelles ?

Un signal d’arrêt d’un onduleur peut parvenir à l’hôte de virtualisation sans atteindre ses machines virtuelles, car la détection de l’alimentation et l’orchestration de l’arrêt des invités sont deux étapes distinctes.

Commencez par vérifier que l’hôte reçoit bien l’événement de l’onduleur, puis testez si chaque machine virtuelle importante réagit à un arrêt normal de l’hyperviseur. Examinez l’action en cas de batterie faible, le comportement de l’agent invité ou d’ACPI, l’ordre d’arrêt et la marge d’autonomie. L’état final sûr est le suivant : les invités s’arrêtent d’abord, l’hôte en dernier, avec suffisamment de batterie pour absorber les délais.

Vérifiez quel composant reçoit l’événement de l’onduleur

Déclenchez un événement de test pris en charge ou consultez les journaux d’une transition récente vers la batterie, puis notez si NUT, apcupsd, la supervision SNMP ou un autre démon installé sur l’hôte le détecte.

Un processus d’arrêt d’un onduleur avec Proxmox distingue la détection de l’onduleur sur un hôte Proxmox des actions ultérieures nécessaires pour arrêter les charges de travail et éteindre la machine.

Si l’hôte ne reçoit jamais l’événement, concentrez-vous sur la communication avec l’onduleur. S’il le reçoit, ne supposez pas que l’arrêt des invités est automatique : examinez l’étape d’orchestration suivante.

Testez l’arrêt des invités sans l’onduleur

Depuis l’hyperviseur, demandez un arrêt normal et propre de chaque machine virtuelle critique et mesurez le temps nécessaire. Vérifiez l’état de l’agent invité, le comportement d’ACPI et les applications qui retardent l’arrêt.

Une installation de NUT avec Proxmox montre pourquoi NUT peut être la source de l’événement, tandis que Proxmox doit malgré tout disposer d’un chemin de réponse défini pour les charges de travail virtualisées qu’il héberge.

Corrigez les invités qui ignorent un arrêt normal demandé par l’hyperviseur avant de tester les situations d’urgence liées à la batterie. L’automatisation de l’onduleur ne peut pas forcer un invité qui ne répond pas à s’arrêter soudainement et proprement.

Faites en sorte que l’action de l’onduleur appelle la couche de virtualisation

Examinez le script ou le service qui gère la batterie faible. Un arrêt direct de l’hôte peut contourner l’ordre normal d’arrêt des machines virtuelles s’il n’appelle pas le processus d’arrêt des invités de l’hyperviseur.

Une autre solution d’orchestration de NUT avec Proxmox montre qu’il est nécessaire de relier l’état de NUT à des actions système explicites, plutôt que de considérer le démon de l’onduleur lui-même comme un gestionnaire des invités.

Utilisez l’orchestration d’arrêt prise en charge par la plateforme ou un hook limité qui demande d’abord l’arrêt des invités. Évitez les commandes personnalisées d’arrêt forcé qui contournent l’arrêt des applications à l’intérieur de la machine virtuelle.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prévoyez du temps pour les invités lents et pour l’hôte

Mesurez le temps total d’arrêt des invités, le temps d’arrêt de l’hôte, l’autonomie de l’onduleur en charge et le seuil de batterie faible. Gardez une marge au cas où un invité prendrait plus de temps que d’habitude.

Un service d’arrêt d’un onduleur Proxmox dédié existe parce qu’un arrêt ordonné de Proxmox nécessite une stratégie et une gestion du temps, et pas seulement la preuve qu’un signal SNMP ou USB est parvenu à l’hôte.

Définissez des délais d’attente limités pour les invités et un ordre d’escalade afin qu’une machine virtuelle non critique bloquée ne vide pas la batterie. Les invités critiques, comme ceux qui hébergent le stockage ou une base de données, peuvent nécessiter un arrêt prioritaire.

Effectuez un test contrôlé de bout en bout

Pendant une fenêtre de maintenance, simulez ou déclenchez la condition de l’onduleur prise en charge, observez l’ordre d’arrêt des invités, confirmez que l’hôte s’éteint en dernier, puis rétablissez le secteur et vérifiez que les démarrages s’effectuent correctement.

Les recommandations destinées aux environnements de test domestiques sur la résilience d’un environnement de test domestique face aux coupures de courant rappellent que la résilience dépend du test de toute la séquence de panne, et pas uniquement de la collecte des données de l’onduleur. Le guide ZimaSpace associé sur la préparation des sauvegardes de machines virtuelles complète cette démarche avec les aspects liés aux sauvegardes et à la restauration.

Le processus n’est terminé que lorsque chaque machine virtuelle requise s’arrête proprement avant l’hôte, que la batterie conserve une marge de sécurité et que la même séquence fonctionne à nouveau après toute modification de configuration.

Foire aux questions

Les machines virtuelles ont-elles besoin de leur propre client NUT si l’hôte en possède déjà un ?

Pas toujours. L’hôte peut orchestrer l’arrêt des invités par l’intermédiaire de l’hyperviseur, mais cette étape d’arrêt des invités doit être configurée, testée et disposer de suffisamment de temps avant l’extinction de l’hôte.

Que se passe-t-il si une machine virtuelle refuse de s’arrêter ?

Utilisez un délai d’attente limité et une stratégie d’escalade. Un seul invité bloqué ne doit pas consommer toute la batterie de l’onduleur jusqu’à ce que l’hôte perde brutalement son alimentation.

Comment tester l’arrêt de l’onduleur en toute sécurité ?

Utilisez une fenêtre de maintenance, des sauvegardes valides, un événement contrôlé de batterie faible ou simulé lorsque cela est pris en charge, puis vérifiez l’ordre d’arrêt des invités, l’arrêt de l’hôte et la reprise correcte après le retour du courant.