Panne d'hyperviseur : relancer vos VM en 5 min au lieu de 4 h

1. Ce qui se passe quand un hyperviseur tombe

Une alimentation lâche, une barrette mémoire part en erreur non corrigible, un noyau se fige. La machine physique s'arrête, et avec elle toutes les machines virtuelles qu'elle hébergeait. Ce qui se passe dans les minutes suivantes ne dépend pas de la panne — elle est identique dans tous les cas — mais uniquement de ce qui a été mis en place avant.

Et le facteur décisif n'est pas celui qu'on croit. Ce n'est ni la vitesse du stockage, ni la bande passante : c'est le temps qu'il faut pour que quelque chose ou quelqu'un s'aperçoive du problème et décide d'agir. Tout le reste en découle.

Le scénario que nous voyons le plus souvent

L'hyperviseur tombe à 2 h 40 du matin. La supervision alerte. Sans astreinte, personne ne lit l'alerte avant 8 h 30. La restauration démarre à 9 h et se termine à 11 h. La panne matérielle a duré quelques secondes ; l'indisponibilité a duré huit heures et vingt minutes, dont près de six à ne rien faire.

2. Sans HA : quelqu'un doit s'en apercevoir

Le délai de détection, là où se joue vraiment le RTO

Dans une infrastructure sans mécanisme de bascule, la remise en service commence par une décision humaine. Le délai avant cette décision est presque toujours plus long que l'opération technique elle-même — et c'est là que se joue l'essentiel du temps de rétablissement. Une astreinte 24/7 ramène ce délai à quelques dizaines de minutes ; son absence peut le porter à une nuit entière.

Le prérequis : une sauvegarde restaurable ailleurs

Pour relancer une machine virtuelle sur un autre nœud, il faut que sa sauvegarde soit restaurable ailleurs — pas seulement sur le matériel d'origine. C'est ce qui rend l'écosystème Proxmox intéressant ici : le format de sauvegarde est natif et neutre, et la même sauvegarde qui vous protège d'une erreur vous permet aussi de repartir sur un autre serveur. Un seul dispositif, deux usages, et vous ne payez pas deux fois. Toute la profondeur du sujet — rétention, immuabilité, isolation — relève de la sauvegarde elle-même : voir NimbusBackup et le plan de reprise avec Proxmox.

Le temps réel : une à quatre heures

Une fois la décision prise, trois facteurs déterminent la durée : la volumétrie à transférer, le débit utile de restauration — rarement celui du lien, souvent celui du stockage — et la disponibilité de quelqu'un pour surveiller l'opération et redémarrer l'applicatif derrière.

Pour donner un ordre de grandeur : 500 Go à 200 Mo/s utiles font une quarantaine de minutes de transfert pur. En ajoutant la préparation du nœud cible, le démarrage du système et celui de l'application, on arrive rarement en dessous de l'heure, et facilement au-delà de trois pour un ensemble de plusieurs machines.

Ce que la GTR change ici

Une garantie de temps de rétablissement encadre ce délai contractuellement, mais elle ne le supprime pas : elle engage un humain à intervenir dans une fenêtre donnée. C'est exactement la différence avec ce qui suit — la haute disponibilité ne raccourcit pas l'intervention, elle la rend inutile.

3. Avec HA : personne n'a besoin de s'en apercevoir

Quand plusieurs hyperviseurs forment un cluster, les survivants constatent qu'un des leurs ne répond plus et redémarrent ses machines virtuelles chez eux. L'opération prend quelques minutes et ne demande aucune décision humaine. Trois prérequis la rendent possible — et l'absence d'un seul suffit à la rendre dangereuse.

1. Au moins trois nœuds

Le troisième n'héberge pas forcément de charge : il tranche. À trois, une majorité existe toujours, donc le groupe qui la détient sait qu'il est légitime. À deux, aucun ne peut faire la différence entre un voisin mort et un câble débranché. Un témoin léger peut remplacer le troisième hyperviseur complet.

2. Un stockage atteignable

La machine virtuelle ne peut redémarrer ailleurs que si son disque y est accessible. Cela passe par un stockage partagé entre les nœuds, ou par une réplication qui en maintient une copie récente. Sans l'un des deux, il n'y a rien à redémarrer.

3. Un mécanisme d'isolation

Avant de relancer une machine ailleurs, il faut la certitude qu'elle ne tourne plus nulle part. Sans cette garantie, deux instances peuvent écrire sur le même disque — et là, la corruption est réelle. C'est le rôle du fencing, et un cluster qui en est dépourvu n'est pas un cluster, c'est un pari.

Le temps réel : deux à cinq minutes

Ce délai se décompose en trois parties, et aucune n'est humaine : la détection de l'absence, qui demande quelques dizaines de secondes pour éviter de réagir à un simple à-coup réseau ; l'isolation et la décision de relance ; puis le démarrage du système et de l'applicatif, qui est souvent la partie la plus longue. Une base volumineuse qui rejoue son journal peut à elle seule consommer plusieurs minutes.

Ces 2 à 5 minutes supposent que la VM démarre proprement

C'est une hypothèse, pas une garantie, et deux cas la font sauter. Une vérification de système de fichiers déclenchée par l'arrêt brutal peut occuper de longues minutes sur un gros volume — le temps dépend de la taille, pas de votre SLA. Et surtout, un disque chiffré qui attend une phrase de passe ne démarrera jamais tout seul : la machine reste bloquée jusqu'à ce qu'un humain la saisisse, ce qui annule exactement le bénéfice qu'on cherchait à 3 h du matin.

Ces deux points se traitent à la conception — déverrouillage automatisé par serveur de clés, systèmes de fichiers à journalisation, volumes de données séparés du système — et pas le jour de la panne. C'est le genre de vérification que nous faisons lors d'un test de bascule, parce qu'un redémarrage volontaire les révèle immédiatement.

Ce que ça ne fait pas — et c'est important

La machine virtuelle redémarre, elle ne bascule pas. La distinction n'est pas cosmétique :

• Les sessions en cours sont perdues. Connexions applicatives, sessions utilisateur, transactions non validées : tout est coupé net, exactement comme lors d'une coupure de courant.
• Un applicatif mort dans une VM allumée n'est jamais détecté. Le cluster surveille les nœuds, pas ce qui tourne dedans. Une machine qui répond avec un service planté est, pour lui, en parfaite santé.
• Une panne de datacenter n'est pas couverte si tous les nœuds sont au même endroit. La redondance s'arrête aux limites du site.

Ces trois limites sont précisément ce que couvrent les niveaux supérieurs — voir les 4 architectures.

4. Le cas sans stockage partagé

Un stockage partagé entre plusieurs nœuds suppose un réseau interne rapide et un budget qui va avec. Beaucoup d'infrastructures s'en passent, et remplacent ce partage par une réplication planifiée : le disque de la machine virtuelle est copié à intervalles réguliers vers un autre hyperviseur, qui devient capable de la redémarrer.

Le mécanisme de relance est le même, mais la conséquence est différente : la machine repart depuis la dernière copie, pas depuis son état au moment de la panne. Les écritures survenues entre-temps sont perdues — typiquement de une à quinze minutes selon la fréquence configurée.

C'est un compromis souvent excellent pour un frontal web, un serveur applicatif sans état ou un environnement de préproduction. Il l'est beaucoup moins pour une base transactionnelle, où perdre dix minutes d'écritures signifie perdre des commandes. Le choix entre les différents modes de réplication et leurs implications est traité en détail sur notre site Proxmox.

5. Comparatif des trois situations

	Aucun dispositif	Restauration organisée	Cluster en HA
Qui détecte	Un utilisateur qui appelle	La supervision, puis l'astreinte	Le cluster lui-même
Temps de reprise	Une journée, parfois plus	1 à 4 h	2 à 5 min
Données perdues	Jusqu'à la dernière sauvegarde	Jusqu'à la dernière sauvegarde	Aucune si stockage partagé
Prérequis	—	Sauvegarde restaurable ailleurs, astreinte	3 nœuds, stockage atteignable, fencing
Surcoût	Nul	Faible	2 nœuds supplémentaires + réseau

La colonne du milieu est celle où se trouvent la plupart des infrastructures que nous reprenons. Ce n'est pas une mauvaise situation — c'est même le minimum sérieux — mais elle plafonne à quelques heures, et aucun effort d'organisation ne la fera descendre en dessous.

6. Ce que nous exploitons ensuite

Un cluster correctement installé se dégrade silencieusement s'il n'est pas surveillé — et pas surveillé au sens habituel du terme. Le service répond, les machines tournent, les graphiques sont verts : rien n'indique que la redondance, elle, a disparu.

• Tests de bascule réguliers. Un basculement qu'on n'a jamais provoqué volontairement est une hypothèse, pas une garantie. Nous les planifions et nous mesurons le temps réel obtenu, qui est la seule valeur qui compte.
• Vérification du mécanisme d'isolation. C'est le composant qui casse le plus discrètement, souvent à l'occasion d'une mise à jour ou d'un changement d'identifiants sur la carte de gestion du serveur.
• Suivi du quorum et de la capacité résiduelle. Un cluster qui tourne durablement avec un nœud absent n'est plus redondant : il attend juste la deuxième panne. Et un cluster dont les nœuds survivants ne pourraient pas absorber la charge du disparu n'est pas redondant non plus, il est optimiste.

Tout cela relève de l'exploitation courante, incluse dans nos forfaits d'infogérance, avec l'astreinte 24/7 pour ce que l'automatisme ne sait pas traiter.

7. Pour qui c'est suffisant

Ça suffit largement si…

• Quelques minutes d'interruption sont tolérables
• Les utilisateurs peuvent se reconnecter sans conséquence
• L'activité est concentrée sur des heures ouvrées
• Un seul site héberge toute l'infrastructure

Ça ne suffit pas si…

• Une session coupée coûte une commande perdue
• L'applicatif peut planter sans que la VM s'arrête
• Le service doit rester joignable pendant la bascule
• La perte d'un site entier fait partie des scénarios

Dans la colonne de droite, la réponse n'est pas « plus d'hyperviseurs » : c'est un changement de granularité. Il faut surveiller le service et non plus la machine, ce qui suppose un cluster applicatif, éventuellement posé sur le cluster d'hyperviseurs décrit ici. Les quatre architectures sont comparées sur la page d'ensemble.

Questions fréquentes

Faut-il vraiment trois hyperviseurs pour de la haute disponibilité ?

Pour que le cluster décide seul, oui. Le troisième nœud ne sert pas à héberger des machines supplémentaires, il sert à trancher : à trois, une majorité existe toujours, et le groupe qui la détient sait qu'il est légitime pendant que l'isolé sait qu'il ne l'est pas. À deux, aucun des deux ne peut faire la différence entre un voisin mort et un lien réseau coupé. Il existe une alternative : un témoin léger, une petite machine qui ne fait qu'arbitrer sans héberger de charge. C'est moins cher qu'un troisième hyperviseur complet et cela suffit à débloquer la décision.

Peut-on faire de la haute disponibilité sans stockage partagé ?

Oui, avec de la réplication planifiée entre les nœuds, mais le résultat n'est pas le même. Le disque de la machine virtuelle est copié à intervalles réguliers sur un autre hyperviseur ; en cas de panne, elle redémarre à partir de la dernière copie. Vous perdez donc les écritures survenues depuis, ce qui représente typiquement de une à quinze minutes de données selon la fréquence choisie. C'est acceptable pour un serveur applicatif ou un frontal web, beaucoup moins pour une base de données transactionnelle.

Combien de temps dure la restauration d'une VM de 500 Go ?

Le calcul de base est simple : 500 Go à 200 Mo/s de débit utile font environ quarante minutes de transfert. Mais le débit utile est rarement celui du lien : il dépend du stockage source, du stockage cible et de la déduplication. Et surtout, ce transfert n'est qu'une partie du délai total, auquel s'ajoutent le temps de détection, la décision, la préparation du nœud cible et le démarrage de l'applicatif. En pratique nous constatons une à quatre heures selon le moment de la journée, la nuit et le week-end étant les pires cas.

Que devient une base de données quand la VM est redémarrée de force ?

C'est l'équivalent exact d'une coupure de courant. Un moteur transactionnel moderne survit à ce traitement : au redémarrage il rejoue son journal, annule les transactions non validées et repart cohérent. Ce qui est perdu, ce sont les transactions en cours au moment de la coupure, et les connexions applicatives, qui devront être rétablies. Le risque réel n'est donc pas la corruption mais la durée du rejeu : sur une base très active, il peut allonger le redémarrage de plusieurs minutes.

La haute disponibilité de l'hyperviseur détecte-t-elle une application plantée ?

Non, et c'est sa limite fondamentale. Le cluster surveille les nœuds, pas ce qui tourne à l'intérieur des machines virtuelles. Une VM allumée dont le service applicatif est mort est, de son point de vue, une VM en parfaite santé : rien ne sera déclenché. Couvrir ce scénario demande une surveillance au niveau du service lui-même, soit par la supervision et l'astreinte, soit par un cluster applicatif qui bascule sur une autre instance.

La haute disponibilité est-elle incluse dans l'infogérance ?

L'exploitation d'un cluster existant est incluse dans le forfait d'infogérance, au tarif par serveur, avec un tarif dégressif à partir du deuxième nœud d'un même cluster. La conception et le déploiement initial sont facturés séparément, sur devis, sur la base de 150 € HT de l'heure : le périmètre dépend du nombre de nœuds, de l'hébergeur et de l'applicatif à rendre disponible. Le matériel, lui, est acheté en direct par le client et lui appartient.

Votre infrastructure survivrait-elle à la perte d'un hyperviseur ?

Nous auditons l'existant, nous chiffrons ce qui manque, et nous vous disons si le troisième nœud vaut son coût dans votre cas.

Demander un devis

Panne d'hyperviseur :
relancer vos VM en 5 min au lieu de 4 h

Sommaire