Aller au contenu

Semaine 7 — Migration à chaud et haute disponibilité

Durée estimée : 45 min · Prérequis : Le cluster Proxmox et le stockage partagé

Objectifs d'apprentissage

  • Décrire les étapes d'une migration à chaud et dire pourquoi la VM ne s'arrête pas.
  • Identifier ce qui empêche une VM de migrer à chaud.
  • Distinguer une migration planifiée d'une reprise après panne.
  • Expliquer le fencing et dire pourquoi il est indispensable avant de redémarrer une VM ailleurs.
  • Décider quels services méritent la haute disponibilité, et justifier ceux qui ne la méritent pas.

1. Deux situations très différentes

Le serveur 2 d'Aria Airlines doit recevoir une mise à jour du noyau, qui demande un redémarrage. Le site de vente tourne dessus. Vous savez à l'avance ce qui va arriver, et le serveur fonctionne encore : c'est une opération planifiée.

Une semaine plus tard, l'alimentation du serveur 2 grille à 3 h du matin. Personne n'est là, et le serveur ne répond plus à rien : c'est une panne.

Proxmox a un outil pour chaque situation. La migration à chaud déplace une VM vivante d'un nœud qui fonctionne vers un autre. La haute disponibilité redémarre les VM d'un nœud mort sur les nœuds qui restent. Le premier ne coupe pas le service ; le second le coupe le moins longtemps possible.

2. La migration à chaud

Une migration à chaud (live migration, ou online migration) déplace une VM d'un nœud à l'autre pendant qu'elle tourne. Le système invité ne redémarre pas, les connexions réseau restent ouvertes, et un client en train de remplir un formulaire ne remarque rien.

Ce qui voyage

Grâce au stockage partagé, le disque ne bouge pas : les deux nœuds le voient déjà. Ce qui doit voyager, c'est l'état de la VM en mémoire : le contenu de sa mémoire vive et l'état de ses processeurs virtuels.

La difficulté : la VM continue d'écrire dans sa mémoire pendant la copie. Proxmox procède donc en plusieurs passes :

  1. Le nœud de destination démarre une VM vide, en pause, qui attend son contenu.
  2. Le nœud source copie toute la mémoire vers la destination. La VM continue de tourner.
  3. Pendant cette copie, la VM a modifié certaines pages de mémoire. Ces pages, dites sales (dirty pages), sont recopiées.
  4. Chaque passe est plus courte que la précédente, parce qu'il reste moins de pages à recopier.
  5. Quand le reste est assez petit pour partir en quelques millisecondes, la VM source est mise en pause, les dernières pages partent, et la VM de destination reprend.

La pause finale dure généralement bien moins d'une seconde. Le journal de la migration indique la durée de cette pause (downtime). Un ping lancé pendant la migration perd au pire un ou deux paquets.

sequenceDiagram
    participant S as Serveur 2 (source)
    participant D as Serveur 3 (destination)
    S->>D: démarre une VM vide en pause
    S->>D: copie de toute la mémoire (la VM tourne)
    S->>D: pages modifiées entre-temps
    S->>D: pages modifiées entre-temps (moins)
    Note over S: pause de quelques millisecondes
    S->>D: dernières pages + état des processeurs
    Note over D: la VM reprend ici

Le réseau suit la VM

La VM garde son adresse MAC et son adresse IP. Il faut seulement que le switch apprenne qu'elle est maintenant branchée sur un autre port. Dès la reprise, la VM envoie une trame qui l'annonce, et le switch met sa table d'adresses MAC à jour.

Pour y arriver, le nœud de destination doit avoir le même bridge, avec les mêmes VLAN, que le nœud source. Une VM branchée sur vmbr1 ne peut pas migrer vers un nœud qui n'a pas de vmbr1.

Le VLAN de la VM doit lui aussi exister à l'arrivée, à deux endroits :

  • Sur le bridge de destination. Un bridge VLAN aware avec bridge-vids 2-4094, la valeur écrite par Proxmox, accepte n'importe quel VLAN : il n'y a rien à créer. Si l'administrateur a réduit cette liste, par exemple à bridge-vids 460, une VM taguée en VLAN 20 voit ses trames jetées sans message d'erreur (semaine 3).
  • Sur le switch physique. Le port trunk où est branché le nœud de destination doit transporter ce VLAN. Sinon, le switch jette les trames.

Dans les deux cas, la migration se termine sans erreur. C'est la VM qui n'a plus de réseau en arrivant, ce qui rend la panne difficile à trouver.

Ce qui empêche une migration à chaud

Une VM ne peut pas quitter son nœud si elle dépend de quelque chose qui n'existe que sur ce nœud.

Obstacle Pourquoi Correction
Disque sur local-lvm l'autre nœud ne le voit pas déplacer le disque vers le stockage partagé (Move Storage), ou accepter de le copier pendant la migration, ce qui est long
ISO monté depuis local le lecteur CD pointe vers un fichier absent de l'autre nœud éjecter le CD (Do not use any media)
Snippet cloud-init sur local Proxmox reconstruit le lecteur cloud-init au démarrage, sur le nœud où la VM démarre ranger les snippets sur le stockage partagé
Carte PCI ou clé USB passée à la VM le matériel est physiquement dans le serveur source aucune : la VM migre éteinte, ou pas du tout
Type de CPU host sur des serveurs différents la VM utilise des instructions que l'autre processeur n'a peut-être pas garder le type par défaut, x86-64-v2-AES

Le type de CPU mérite une explication. Par défaut, Proxmox présente à la VM un processeur générique, x86-64-v2-AES, que tous les serveurs récents savent imiter. Avec le type host, la VM voit le vrai processeur du nœud et peut utiliser toutes ses instructions. Si la destination n'a pas exactement les mêmes, la VM plante à son arrivée.

Les conteneurs LXC, eux, ne migrent jamais à chaud. Proxmox les arrête, les déplace et les redémarre : c'est une migration avec redémarrage (restart mode).

3. La haute disponibilité

La migration à chaud suppose que le nœud source fonctionne encore. Quand un nœud meurt, il n'y a plus de mémoire à copier : son contenu a disparu au moment où le courant s'est coupé. Il ne reste que le disque, sur le stockage partagé.

La haute disponibilité (High Availability, HA) fait la seule chose encore possible : redémarrer la VM sur un autre nœud, à partir de son disque. Pour la VM, c'est exactement comme un cordon d'alimentation arraché, puis rebranché. Le système redémarre, vérifie ses disques, relance ses services.

La HA n'est pas une migration à chaud automatique

Une VM protégée par la HA s'arrête quand son nœud tombe. Elle redémarre ailleurs deux à quatre minutes plus tard. Ce qui était en mémoire est perdu : un panier d'achat pas encore enregistré, une transaction pas encore écrite sur le disque. La HA réduit l'interruption de plusieurs heures à quelques minutes ; elle ne la supprime pas.

Qui décide

Le gestionnaire de HA de Proxmox s'appelle ha-manager. Il a deux pièces :

  • Le CRM (Cluster Resource Manager) prend les décisions pour tout le cluster : où chaque VM doit tourner, laquelle redémarrer après une panne. Un seul nœud à la fois joue ce rôle, appelé master.
  • Le LRM (Local Resource Manager) tourne sur chaque nœud et exécute les ordres sur ce nœud : démarrer, arrêter, migrer.

Une VM confiée au gestionnaire devient une ressource HA, notée vm:711. Chaque ressource a un état demandé : started (elle doit tourner), stopped (elle doit rester arrêtée), disabled ou ignored (la HA la laisse tranquille). Une ressource started que quelqu'un éteint à la main est redémarrée par la HA.

Le fencing : être sûr que le nœud est vraiment mort

Avant de redémarrer une VM ailleurs, il faut une certitude : l'ancienne copie ne tourne plus. Un nœud qui a seulement perdu son câble réseau est peut-être encore bien vivant, sa VM toujours en train d'écrire sur le stockage partagé. Démarrer une deuxième copie, c'est deux machines qui écrivent dans le même disque, et une base de données détruite.

Isoler un nœud pour être certain qu'il ne touche plus aux disques s'appelle le fencing (clôture). Proxmox le fait avec un watchdog, une minuterie que chaque nœud doit réarmer régulièrement :

  1. Un nœud qui perd le quorum arrête de réarmer son watchdog.
  2. Après 60 secondes, le watchdog redémarre le nœud de force. Ses VM s'arrêtent avec lui.
  3. Les nœuds qui ont gardé le quorum attendent ce délai. Ils savent alors que le nœud isolé s'est forcément arrêté, et redémarrent ses VM.

C'est un nœud qui se clôture lui-même (self-fencing). Que le nœud soit mort ou seulement isolé, la règle donne le même résultat : ses VM ne tournent qu'à un seul endroit. C'est aussi ce qui explique le délai d'environ deux minutes avant la reprise.

flowchart LR
    A["Serveur 2<br/>hors tension"] --> B["Serveurs 1 et 3<br/>gardent le quorum"]
    B --> C["Délai du watchdog<br/>le serveur 2 est<br/>forcément arrêté"]
    C --> D["Le CRM redémarre<br/>vm:711 et vm:712<br/>sur 1 et 3"]

Arrêter un nœud proprement

Un arrêt planifié n'est pas une panne. Le réglage Datacenter > Options > HA Settings dit à Proxmox quoi faire des ressources HA à l'arrêt ou au redémarrage d'un nœud :

Politique À l'arrêt du nœud
conditional un arrêt déplace les ressources ailleurs ; un redémarrage les fige jusqu'au retour du nœud
migrate les ressources migrent à chaud vers les autres nœuds avant l'arrêt
failover les ressources s'arrêtent, puis repartent ailleurs si le nœud tarde à revenir
freeze les ressources s'arrêtent et attendent le retour du nœud

Pour une maintenance, le plus propre est le mode maintenance du nœud : ha-manager crm-command node-maintenance enable <nœud> migre toutes ses ressources HA ailleurs, et les y laisse tant que le mode est actif.

Depuis Proxmox VE 9.0, la préférence d'une ressource pour certains nœuds s'écrit dans des règles d'affinité, dans le panneau HA du Datacenter. Elles remplacent les groupes HA des versions précédentes. Vous ne les utiliserez pas cette semaine : sans règle, la HA choisit elle-même le nœud le moins chargé.

4. Tout ne mérite pas la HA

Il serait tentant de cocher la HA pour chaque VM. Ce serait une erreur, parce que la HA a un coût.

  • De la capacité en réserve. Si le serveur 2 tombe, ses VM doivent tenir dans la mémoire des serveurs 1 et 3. Chaque nœud doit donc garder assez de mémoire libre pour accueillir sa part des VM d'un nœud mort. Le reste du temps, cette mémoire ne sert à rien.
  • Du stockage partagé, plus cher et plus lent que des disques locaux.
  • Des redémarrages inattendus. Une VM HA peut se retrouver sur un autre nœud sans que personne ne l'ait décidé. Tout ce qui dépend du nœud doit être prévu en conséquence.

La bonne question n'est donc pas « ce service est-il important ? ». C'est « combien coûte une heure d'arrêt de ce service ? ».

Service d'Aria Une heure d'arrêt, c'est... HA
aria-web, la vente en ligne des billets non vendus, des clients chez un concurrent oui
aria-staff, l'enregistrement des passagers bloqués au comptoir, un avion qui part en retard oui
aria-db, la base de données les deux services précédents à l'arrêt en même temps oui
aria-formation, la formation des agents de bord une formatrice qui reporte son cours à l'après-midi non

Le portail de formation peut attendre qu'un technicien arrive le lendemain matin. Lui réserver de la mémoire sur chaque nœud, jour et nuit, coûterait plus cher que l'arrêt ainsi évité.

Note

La HA protège contre la panne d'un serveur. Elle ne protège ni contre la panne du stockage partagé, ni contre une erreur dans l'application, ni contre une base de données supprimée par mégarde. Une VM corrompue redémarre ailleurs tout aussi corrompue. La sauvegarde de la semaine 4 reste indispensable.

Pièges fréquents

  • Laisser un ISO dans le lecteur CD. La migration échoue avec un message qui parle d'une ressource locale. Éjectez le média avant de migrer.
  • Migrer vers un nœud dont le switch ne transporte pas le VLAN de la VM. La migration réussit, mais la VM n'a plus de réseau à l'arrivée. Vérifiez le trunk du port de chaque nœud avant de migrer.
  • Ranger les snippets cloud-init sur local. La VM fonctionne, jusqu'au jour où la HA la redémarre sur un nœud qui n'a pas le fichier : elle refuse alors de démarrer.
  • Éteindre une VM HA avec le bouton Shutdown et s'étonner qu'elle redémarre. L'état demandé est toujours started. Pour arrêter une ressource HA, passez son état à stopped.
  • Simuler une panne avec un arrêt propre. Un Shutdown du nœud applique la politique d'arrêt, ce qui n'a rien à voir avec une panne. Pour tester la HA, coupez l'alimentation.
  • Oublier --restart unless-stopped sur les conteneurs Docker. La VM redémarre sur un autre nœud, Docker démarre, mais le conteneur, lui, reste arrêté.

Vérification des acquis

Question 1

Pendant une migration à chaud de aria-web, un client remplit le formulaire de paiement. Que se passe-t-il pour lui ?

  • a) Rien de visible : la VM fait une pause de quelques millisecondes, et son navigateur ne s'en aperçoit pas.
  • b) Sa page se recharge et il doit recommencer, parce que la VM redémarre sur l'autre nœud.
  • c) Sa connexion est coupée environ deux minutes, le temps que le disque soit recopié.
Voir la réponse **a) Rien de visible.** La mémoire est copiée pendant que la VM tourne, en plusieurs passes. Seule la toute dernière passe demande une pause, qui dure bien moins d'une seconde. Les connexions TCP en cours survivent à une pause aussi courte. Le choix c) confond la migration à chaud avec la reprise HA. Les deux minutes, c'est le temps du fencing après une **panne**. Et grâce au stockage partagé, aucun disque n'est recopié pendant une migration.

Question 2

Pourquoi la HA attend-elle environ une minute avant de redémarrer les VM d'un nœud qui ne répond plus ?

  • a) Pour laisser au nœud le temps de redémarrer, au cas où il reviendrait seul.
  • b) Pour être certaine que le watchdog du nœud isolé l'a arrêté, et qu'aucune copie de la VM ne tourne encore.
  • c) Pour recopier les disques des VM vers les nœuds restants.
Voir la réponse **b) Pour être certaine qu'aucune copie de la VM ne tourne encore.** Vu de l'extérieur, un nœud mort et un nœud isolé du réseau se ressemblent. Si le nœud est seulement isolé, ses VM écrivent encore sur le stockage partagé. Le délai garantit que son watchdog l'a redémarré de force avant qu'une seconde copie ne démarre ailleurs. Le choix a) est tentant, mais la HA n'attend pas le retour du nœud : elle attend sa mort certaine. Un nœud qui revient après le délai trouve ses VM déjà reparties ailleurs.

Question 3

Vous migrez à chaud une VM et obtenez une erreur qui mentionne local:iso/debian-13.iso. Quelle est la cause ?

  • a) Le nœud de destination n'a pas assez de place pour recevoir l'ISO.
  • b) Un ISO rangé sur le stockage local d'un nœud est encore monté dans le lecteur CD de la VM.
  • c) La VM a été installée à partir d'un ISO, ce qui interdit définitivement la migration.
Voir la réponse **b) Un ISO local est encore monté dans le lecteur CD de la VM.** Le fichier n'existe que sur le stockage `local` du nœud source. La destination ne pourrait pas présenter le même lecteur CD à la VM, donc Proxmox refuse. Éjecter le média suffit à débloquer la migration. Le choix c) est faux : la façon dont le système a été installé ne compte pas. Seuls comptent les fichiers et le matériel dont la VM dépend **au moment** de la migration.

Question 4

Le serveur qui héberge aria-formation tombe en panne pendant la nuit. Cette VM n'est pas une ressource HA. Que se passe-t-il ?

  • a) La HA la redémarre quand même, parce qu'elle fait partie du cluster.
  • b) Elle reste arrêtée, rattachée au nœud mort, jusqu'à ce qu'un administrateur intervienne.
  • c) Elle est supprimée du cluster et doit être restaurée depuis une sauvegarde.
Voir la réponse **b) Elle reste arrêtée, rattachée au nœud mort.** Le cluster permet la HA, mais ne l'active pas pour chaque VM. Seules les ressources confiées à `ha-manager` sont reprises ailleurs. La configuration de `aria-formation` reste dans le dossier du nœud mort, dans `/etc/pve`, et son disque reste intact sur le stockage partagé. Au retour du nœud, la VM est toujours là, arrêtée. Le choix a) est l'idée la plus répandue : être dans un cluster suffirait à être protégé. Ce n'est pas le cas, et c'est voulu, puisque chaque ressource HA consomme de la capacité en réserve.

Pour aller plus loin