Récupération du cluster après une panne électrique totale
Procédure de récupération et bonnes pratiques pour les clusters VergeOS après une perte de courant totale imprévue - y compris l’ordre de mise sous tension, la vérification de l’intégrité vSAN et les recommandations de prévention.
Vue d’ensemble
Portée
Ce guide couvre la remise sous tension d’un cluster VergeOS après un arrêt non gracieux — lorsque le cluster a perdu l’alimentation brutalement à cause d’une panne de courant, de l’épuisement de l’onduleur, d’une défaillance du site ou d’un événement similaire. Pour les procédures planifiées et contrôlées d’arrêt et de remise sous tension, voir Procédure correcte d'arrêt du système VergeOS et Séquence d'alimentation correcte.
Éviter autant que possible les arrêts brutaux
Bien que VergeOS inclue plusieurs protections intégrées pour préserver l’intégrité des données, aucun système de stockage distribué ne peut garantir totalement l’absence de corruption lorsque des nœuds perdent l’alimentation brutalement et simultanément.
Les écritures en cours au moment de la perte d’alimentation peuvent être incomplètes ou incohérentes entre les pairs, et dans certains cas, le seul moyen de rétablir l’intégrité consiste à restaurer un volume à partir d’un instantané récent.
De plus, des problèmes matériels, du système d’exploitation invité et des applications sont fréquents après des arrêts brutaux.
Une infrastructure d’alimentation appropriée — couverture UPS dimensionnée pour un arrêt gracieux, alimentations redondantes et arrêt automatisé sur batterie faible — est la protection la plus efficace ; voir la Prévention section pour plus d’informations.
Lorsqu’un arrêt brutal se produit malgré ces précautions, la procédure ci-dessous est conçue pour remettre le cluster en ligne en toute sécurité et faire ressortir tout problème d’intégrité nécessitant une intervention.
Prérequis
Accès physique ou IPMI/BMC à chaque nœud
Connaissance du nœud qui est Node1 (Node1 devra être démarré en premier.)
Confirmation que l’alimentation en amont, le réseau (commutateurs du cœur du fabric) et l’IPMI sont rétablis et stables
Un instantané local récent ou répliqué à distance en cas de problèmes d’intégrité détectés
Familiarité avec le tableau de bord de niveau vSAN / parcours du journal
Étapes
À quoi s’attendre
VergeFS inclut plusieurs protections intégrées pour aider à préserver l’intégrité des données lors d’événements liés à l’alimentation — notamment le journal d’écriture, la réplication entre pairs, les serveurs de réparation (ioGuardian) et la vérification au démarrage. Au démarrage du contrôleur, VergeFS déclenche un parcours complet du journal pour vérifier chaque bloc et le réconcilier avec les pairs. Ces protections sont efficaces dans la plupart des cas, mais aucun système de stockage distribué ne peut garantir totalement l’absence de corruption après une perte d’alimentation brutale ; la vérification après le démarrage est importante, en particulier après un arrêt non gracieux.
vSAN nécessite Nombre minimal de nœuds en ligne avant de pouvoir être monté (par exemple, dans un cluster à 4 nœuds avec protection N+1, le vSAN se monte tant que 3 nœuds sont en ligne). Tant que ce seuil n’est pas atteint, le stockage reste hors ligne et les VM ne démarrent pas.
Node1 démarrera, mais s’arrêtera avant de monter le vSAN jusqu’à ce qu’assez de pairs rejoignent le cluster.
Un nombre non nul Réparations après la récupération est normal et devrait diminuer à mesure que le parcours progresse.
Vérifications avant la mise sous tension
Vérifier d’abord que l’infrastructure est prête
Avant de mettre sous tension un quelconque nœud du cluster, confirmez que deux conditions critiques sont réunies. Elles sont abordées dans les prérequis, mais il est utile de les rappeler ici — les ignorer peut causer des dommages bien plus importants que l’arrêt initial :
L’alimentation du site est entièrement rétablie et stable. Remettre le cluster en service pendant une instabilité électrique persistante — variations, baisses de tension ou seconde panne — risque d’aggraver le problème initial et peut entraîner d’autres problèmes d’intégrité des données.
Les commutateurs réseau principaux sont sous tension et complètement démarrés. Les commutateurs d’entreprise peuvent mettre plusieurs minutes à terminer leur démarrage, comme un serveur. Si les nœuds du cluster se mettent en ligne avant que le réseau soit prêt, ils ne pourront pas détecter leurs pairs, ce qui peut provoquer des problèmes de réconciliation.
Confirmez l’alimentation en amont est stable. Mettre les nœuds sous tension sur une alimentation instable risque une seconde panne en pleine récupération.
Confirmez les commutateurs réseau principaux sont en ligne, complètement démarréset que le fabric inter-nœuds est opérationnel. vSAN ne peut pas se reconstituer sans cela, et les commutateurs avancés peuvent mettre plusieurs minutes à finir leur démarrage.
Vérifiez IPMI/BMC l’accès sur chaque nœud afin de pouvoir surveiller le démarrage à distance si nécessaire.
Notez tout nœud présentant des défauts matériels visibles (alimentation défaillante, voyants de disque, alarmes des ventilateurs) — ceux-ci peuvent nécessiter une intervention avant d’être réintégrés.
Séquence de mise sous tension
Une fois l’alimentation et l’infrastructure réseau confirmées prêtes :
Mettez Node1 sous tension.
Surveillez la console/IPMI. Node1 démarrera l’OS, mais s’arrêtera avant de monter le vSAN jusqu’à ce qu’assez de pairs rejoignent le cluster.
Attendez 30 secondes à une minute.
Cette courte pause permet à Node1 de commencer son initialisation avant l’arrivée du reste du cluster. Il n’est pas nécessaire d’attendre que Node1 atteigne complètement son état d’arrêt avant de poursuivre.
Mettez sous tension les nœuds restants.
Les nœuds restants peuvent être mis sous tension ensemble (ou à très courte succession) ; il n’est pas nécessaire de les démarrer un par un.
Le vSAN se monte automatiquement dès qu’un nombre minimal de nœuds est en ligne (par exemple, tous sauf un nœud dans une configuration N+1 par défaut).
Environnements multi-clusters : mettez entièrement en ligne le cluster contrôleur avant de mettre sous tension des clusters supplémentaires.
Conseil pro
Node1 démarre en premier et attend pendant que vous mettez le reste du cluster sous tension — c’est normal, ce n’est pas un blocage. Le vSAN se monte tout seul dès qu’assez de pairs sont en ligne, et VergeOS gère automatiquement la réconciliation ; aucune commande de réparation manuelle n’est nécessaire.
Vérification après récupération
Une fois que tous les nœuds sont en ligne et que le cluster a eu le temps de se stabiliser, vérifiez que tout est revenu à un état sain. Comme le cluster a été arrêté brutalement, effectuez ces vérifications avec une vigilance accrue — une perte d’alimentation brutale peut laisser des problèmes que le cluster ne peut pas entièrement résoudre seul. Recherchez attentivement des erreurs vSAN persistantes, des charges de travail en échec ou en boucle de crash, et toute erreur de système de fichiers au niveau invité. Si une corruption irrémédiable est détectée, il peut être nécessaire de restaurer un volume à partir d’un instantané récent.
Confirmer l’état de santé global du système
Une perte d’alimentation brutale augmente le risque de problèmes matériels. Il est important de vérifier toute anomalie :
Consultez les Alarmes tableau de bord. Confirmez qu’aucune nouvelle alarme n’a été déclenchée.
Consultez les journaux système (tableau de bord principal) pour détecter des erreurs pendant le démarrage ou le montage initial.
Vérifier l’état de santé du vSAN
Ouvrez le tableau de bord principal — tous les voyants d’état doivent être verts.
Accédez à Système → vSAN → Niveaux et double-cliquez sur chaque niveau.
Consultez les tuile sur le tableau de bord de chaque niveau. L’article de base de connaissances Comprendre les états des niveaux vSAN / les parcours du journal fournit un guide pour lire les champs d’état des niveaux vSAN.
Vérifier l’état des disques
Accédez à Système → vSAN → Disques.
Recherchez tout disque affichant des erreurs, des avertissements ou des alertes SMART — cela peut se produire lorsque les disques ne reviennent pas proprement après une perte d’alimentation brutale.
Remplacez les disques défectueux rapidement afin de maintenir la protection des données vSAN.
Vérifier les charges de travail
Comportement de démarrage automatique des VM
Par défaut, les VM sont configurées pour démarrer automatiquement lorsque l’alimentation est rétablie sur le cluster. Les VM avec un En cas de perte d'alimentation paramètre différent devront être démarrées manuellement.
Vérifiez les VM critiques : console réactive, système d’exploitation invité sain, services applicatifs opérationnels. Les arrêts brutaux peuvent provoquer des problèmes dans le système d’exploitation invité et les applications installées — surveillez les erreurs de système de fichiers, les services qui ne démarrent pas et les applications qui plantent au lancement.
Identifiez le plus tôt possible les candidats potentiels à une restauration — idéalement avant que les applications ne reprennent une utilisation intensive.
Les décisions de restauration d’instantané sont sensibles au facteur temps
Si le système global ou des VM individuelles montrent des signes de dommages dus à l’arrêt brutal qui ne peuvent pas être réparés en place, la restauration à partir d’un instantané pré-panne peut être le seul moyen de revenir à un état sain. Cette décision doit être prise aussi rapidement que possible, pour deux raisons :
La rétention des instantanés est limitée. Un instantané pré-panne exploitable peut expirer et devenir indisponible si trop de temps s’écoule avant la prise de décision.
Les données plus récentes sont perdues lors de la restauration. Plus la VM affectée reste en production après l’incident, plus le travail légitime effectué après la récupération est perdu lors de la restauration.
Dépannage
Problèmes courants
Problème : Un nœud ne parvient pas à rejoindre le cluster.
Solution : Vérifiez la sortie IPMI/console pour détecter des erreurs de démarrage. Vérifiez que l’interface réseau principale du nœud est opérationnelle et joignable depuis les pairs. Consultez Système → Nœuds → [nœud] pour l’état et les horodatages de dernière détection. Si le nœud démarre mais ne rejoint pas le cluster, ne pas le retirez pas de force — contactez le support.
Problème : vSAN ne se monte pas / stockage hors ligne.
Solution : Confirmez Le nombre minimal de nœuds vSAN est en ligne sous Système → Nœuds (par exemple, dans une configuration par défaut : 3 sur 4 dans un cluster à 4 nœuds, 5 sur 6 dans un cluster à 6 nœuds). Confirmez la connectivité inter-nœuds (commutateurs du fabric principal, état des liens, MTU). Si le seuil est atteint mais que le stockage ne se monte toujours pas, capturez un sysdiag et contactez le support.
Problème : Le nombre de réparations est bloqué ou augmente.
Solution : Un faible nombre, en diminution Réparations est normal après la récupération. Un nombre qui cesse de diminuer ou augmente indique des blocs que le vSAN ne peut pas reconstruire à partir des pairs. Ne redémarrez aucun nœud. Faites appel au support avant de prendre des mesures correctives.
Problème : Suspicion de split-brain ou d’état de cluster incohérent.
Solution : Pendant la récupération, un problème réseau peut faire démarrer deux sous-ensembles de nœuds incapables de se voir. Si vous voyez des signes de formation de deux clusters indépendants (rare, mais possible après une restauration partielle du réseau), n’essayez pas de les fusionner vous-même. Capturez des sysdiags sur chaque nœud et contactez immédiatement le support.
Prévention/atténuation
Dimensionnement et couverture de l’UPS — dimensionnez l’UPS pour couvrir la durée d’un arrêt gracieux avec une marge pour chaque nœud. Incluez les commutateurs réseau principaux dans la même couverture. Testez chaque année l’autonomie de l’UPS — les batteries se dégradent.
Arrêt gracieux automatisé — Utilisez le logiciel de gestion de l’UPS (NUT, scripts IPMI ou l’agent de votre fournisseur d’UPS sur un hôte de gestion) pour détecter un événement de batterie faible et déclencher un arrêt gracieux du cluster — soit via l’action Mettre hors tension du tableau de bord du cluster, l’API VergeOS (
POST /v4/cluster_actionsavec le corps{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}), ou notre VRG CLI wrapper, qui peut automatiser le même appel d’arrêt depuis un hôte Linux/macOS/Windows. Validez l’automatisation dans une fenêtre de maintenance avant de vous y fier.Paramètres « En cas de perte d’alimentation » des VM — configurez délibérément le comportement de chaque VM afin que l’état après récupération soit prévisible. Trois options :
Dernier état — la VM ne démarre que si elle était allumée au moment de la perte d’alimentation
Laisser éteint — la VM reste éteinte lorsque l’alimentation est rétablie, quel que soit son état précédent
Mise sous tension — la VM démarre lorsque l’alimentation est rétablie, quel que soit son état précédent
Serveur de réparation (ioGuardian) — un serveur de réparation fournit à VergeFS une source de repli pour les blocs manquants si les nœuds pairs ne peuvent pas les fournir après une panne. Il est construit à partir d’une configuration de synchronisation sortante de site existante et récupère les blocs nécessaires depuis un système VergeOS distant synchronisé. Les serveurs de réparation sont fortement recommandés pour tout déploiement de production.
Rotation adéquate des instantanés — conservez une politique de rétention des instantanés qui garde disponibles des instantanés récents, antérieurs à l’événement, pour une restauration en cas de besoin. La réplication des instantanés vers un site distant est également recommandée dans le cadre d’une stratégie complète de protection des données.
Quand contacter le support
Ouvrez un ticket de support avant de redémarrer des nœuds ou d’effectuer tout autre changement important, si l’une des conditions suivantes est vraie :
vSAN ne se monte pas après la mise en ligne de N nœuds (par exemple, le nombre total de nœuds moins un dans une redondance N+1 par défaut)
Un niveau affiche Redondant : faux pendant une période prolongée après la fin des parcours complets
Le Réparations le nombre est bloqué ou augmente
Une alerte de réparations bloquées est présente (VergeOS v26+)
Plusieurs disques signalent des erreurs après la récupération
Vous suspectez un split-brain ou un état de cluster incohérent
Un nœud ne parvient pas à rejoindre à nouveau le cluster et la cause n’est pas manifestement matérielle
Générer un diagnostic système pour le support
Avant d’ouvrir le ticket, capturez un sysdiag et joignez-le (ou envoyez-le directement au support) :
Voir Génération des diagnostics système et la référence complète Diagnostics système .
Ressources supplémentaires
Retour
Mis à jour
Ce contenu vous a-t-il été utile ?