Exercice 5 — Migrer à chaud pendant une vente

Durée : ~30 min · En équipe · Théorie associée : Migration à chaud et haute disponibilité

Le mandat

Le serveur 3 doit recevoir une mise à jour qui demande un redémarrage. Aria Airlines refuse toute interruption de la vente en ligne, même de quelques minutes, et le comptoir de l'aéroport enregistre des passagers en ce moment même. Vous allez vider le serveur 3 sans que personne ne s'en aperçoive.

Objectif

Les VM d'Aria changent de nœud pendant qu'elles servent des clients. Le serveur 3 se retrouve vide et prêt pour sa maintenance.

Prérequis

• L'exercice 4 terminé : les quatre VM tournent, et les trois sites répondent depuis votre poste.

Au départ, les VM sont placées ainsi :

Nœud	VM
serveur 1	aria-db
serveur 2	aria-web, aria-formation
serveur 3	aria-staff

Étape 1 — Lancer un ping continu vers le site de vente

Ouvrez le Shell du serveur 1 (ou sur votre PC de la classe - le Wifi eduroam ne permet pas d'accéder au réseau 10.70.0.0/16).

Bash

ping -i 0.2 10.70.8E.11

Le ping envoie cinq paquets par seconde vers aria-web. Laissez-le tourner pendant les trois étapes suivantes : c'est votre chronomètre.

Étape 2 — Commencer un achat

Depuis votre poste, ouvrez http://10.70.8E.11. Cherchez un vol pour Oslo demain, choisissez un siège, inscrivez votre nom, et cliquez sur Continuer vers le paiement.

Arrêtez-vous sur la page de paiement, sans cliquer sur Payer. Notez le nom du conteneur affiché après servi par, en bas de la page.

Vous jouez un client qui hésite avant de payer. Tout ce qu'il a choisi n'existe encore que dans son navigateur et dans la mémoire de la VM.

Étape 3 — Migrer aria-web vers le serveur 3

Dans l'interface web, faites un clic droit sur aria-web, puis Migrate.

Champ	Valeur
Target node	serveur 3
Mode	Online

Cliquez sur Migrate. La fenêtre de tâche s'ouvre et affiche la progression.

Étape 4 — Lire le journal de migration

Attendez la fin de la tâche.

La première ligne avertit conntrack state migration not supported or disabled, active connections might get dropped : ignorez-la, elle concerne le pare-feu de Proxmox, qui n'est pas activé ici.

Le journal montre ensuite la mémoire copiée en plusieurs passes, de plus en plus courtes : ce sont les pages modifiées pendant la copie précédente. Vers la fin, la ligne average migration speed: ... - downtime 58 ms donne la durée de la pause finale, en millisecondes. Aucune ligne ne parle du disque : il est resté sur nfs-aria, où le serveur 3 le voyait déjà.

Étape 5 — Arrêter le ping

Revenez au Shell du serveur 1 et tapez Ctrl+C.

Lisez la ligne de résumé. Sur plusieurs centaines de paquets, il en manque zéro, un ou deux : la pause finale a duré moins de temps qu'un aller-retour sur cinq.

Étape 6 — Terminer l'achat

Sur votre poste, cliquez sur Payer.

La réservation est confirmée. Comparez le nom après servi par avec celui de l'étape 2 : c'est le même. Le conteneur n'a pas redémarré, ni la VM qui le contient. Le même processus nginx, avec la même mémoire, tourne maintenant sur un autre serveur physique.

Étape 7 — Ouvrir un dossier au comptoir

Sur le poste d'enregistrement, http://10.70.8E.12, choisissez le vol AR 118 d'aujourd'hui et ouvrez le dossier de LEFEBVRE/HUGO. Cliquez sur Lire la bande MRZ.

Les documents sont validés : cette information vient d'être écrite dans aria-db.

Étape 8 — Migrer la base de données vers le serveur 2

Faites un clic droit sur aria-db, puis Migrate, avec le serveur 2 en Target node et le mode Online. Cliquez sur Migrate et attendez TASK OK.

Pendant ce temps, le comptoir reste ouvert sur le dossier de Hugo Lefebvre. Laissez votre navigateur ouvert sur cette page.

Étape 9 — Accepter un bagage

Au comptoir, appuyez sur F7 pour poser un bagage sur la balance. Quand le poids est stable, appuyez sur F8.

L'étiquette s'affiche avec son numéro. Ce numéro vient de la base de données, qui vient de changer de serveur au milieu de la conversation. Le comptoir n'a rien remarqué.

Étape 10 — Vider le serveur 3

Le serveur 3 porte maintenant aria-web et aria-staff. Faites un clic droit sur le nœud serveur 3 dans l'arborescence, puis Bulk Migrate.

Champ	Valeur
Target node	serveur 2
VM	les deux VM cochées

Cliquez sur Migrate. Les deux VM partent l'une après l'autre.

Étape 11 — Constater le résultat

Dépliez les trois nœuds dans l'arborescence de gauche :

Nœud	VM
serveur 1	(aucune)
serveur 2	710 (aria-db), 711 (aria-web), 712 (aria-staff), 720 (aria-formation)
serveur 3	(aucune)

La même vérification se fait depuis le shell de n'importe quel nœud. La colonne node indique où se trouve chaque VM :

Bash

pvesh get /cluster/resources --type vm --output-format text

Le serveur 3 est vide : il peut maintenant être redémarré, mis à jour, ou même recevoir une nouvelle barrette de mémoire. Pendant ce temps, Aria a continué de vendre des billets et d'enregistrer des passagers.

Le serveur 2 porte maintenant les quatre VM d'Aria, et le serveur 1 aucune. Laissez-les ainsi : c'est la situation de départ de l'exercice 6.

Vérification finale

• aria-web a migré sans que la page de paiement soit perdue
• Le résumé du ping montre au plus deux paquets perdus
• Le nom du conteneur en pied de page est le même avant et après la migration
• Un bagage a été accepté au comptoir après la migration de aria-db
• Le serveur 3 ne porte plus aucune VM ; le serveur 2 porte les quatre

Question 1

Après la migration, le pied de page du site affiche le même nom de conteneur qu'avant. Que prouve ce nom identique ?

• a) Que la migration a échoué et que la VM est restée sur le serveur 2.
• b) Que la VM n'a pas redémarré : le même conteneur, avec la même mémoire, a continué de tourner sur un autre serveur.
• c) Que Docker a recréé le conteneur à l'identique sur le serveur 3.

Voir la réponse

**b) Que la VM n'a pas redémarré.** Le nom affiché est l'identifiant du conteneur, attribué une fois pour toutes au `docker run`. Si la VM avait redémarré, le conteneur aurait gardé son identifiant mais aurait perdu tout ce qu'il avait en mémoire. Ici, rien n'a été perdu : la migration a recopié la mémoire de la VM, conteneur compris. Le choix c) prête à Docker un rôle qu'il n'a pas joué. Docker ne sait même pas que sa VM a changé de serveur : pour lui, il ne s'est rien passé.

Question 2

Vous tentez de migrer à chaud une VM et Proxmox refuse : can't migrate local disk 'local-lvm:vm-105-disk-0'. Que faut-il faire ?

• a) Passer la migration en mode Offline, ce qui règle le problème sans délai.
• b) Déplacer d'abord le disque sur nfs-aria avec Disk Action > Move Storage, puis migrer.
• c) Créer un disque vide du même nom sur le nœud de destination.

Voir la réponse

**b) Déplacer d'abord le disque sur `nfs-aria`, puis migrer.** Le disque est enfermé dans le nœud source. Une fois sur le stockage partagé, les deux nœuds le voient et la migration n'a plus qu'à copier la mémoire. Le déplacement de disque se fait lui-même à chaud, sans arrêter la VM. Le choix a) fonctionne, mais pas sans délai : la VM doit être arrêtée, puis son disque est recopié en entier par le réseau. Pour un disque de plusieurs dizaines de gigaoctets, c'est une interruption de plusieurs minutes.

En cas de problème

Symptôme	Cause probable	Correction
can't migrate local disk	Un disque de la VM est sur local-lvm	Hardware, sélectionner le disque, Disk Action > Move Storage vers nfs-aria
can't migrate VM which uses local devices ou mention de local:iso	Un ISO local est monté dans le lecteur CD	Hardware > CD/DVD Drive > Edit, choisir Do not use any media
La migration s'arrête sur une erreur de CPU	Type de CPU host sur des serveurs différents	Hardware > Processors, remettre le type x86-64-v2-AES
Le ping perd plusieurs secondes de paquets	Le mode Offline a été choisi, ou la VM a redémarré	Vérifier le mode dans la fenêtre Migrate
Le comptoir affiche « BASE DE DONNÉES INJOIGNABLE » quelques secondes	La pause finale de aria-db a coïncidé avec un rafraîchissement	Aucune : le bandeau disparaît au rafraîchissement suivant