J’ai monté un cluster mais les machines ne bougent pas : ce qui manque, c’est le stockage

Monter le cluster ne rend pas les machines déplaçables. Ce qui rend la migration possible n’est pas le réseau mais l’endroit où se trouve le disque. Et les conteneurs ne se déplacent pas comme les machines virtuelles.

AtlasPVE ·

Cette fiche répond à

  • proxmox migration échouée
  • proxmox live migration ne marche pas
  • proxmox stockage partagé obligatoire
  • proxmox migration lxc
  • proxmox migrer stockage local

Vous avez monté le cluster, les nœuds se voient, ils apparaissent tous côte à côte dans l’interface. Puis vous voulez déplacer une machine vers un autre nœud et cela ne marche pas.

Ce qui manque n’est pas le cluster, c’est le stockage.

Ce qui se déplace n’est pas la machine, c’est la mémoire

Déplacer une machine virtuelle en marche revient à copier l’état de sa mémoire vers l’autre nœud. Cela passe par le réseau et c’est rapide.

Mais il faut aussi le disque de la machine, et le disque est bien plus gros que la mémoire. Si le disque ne se trouve que sur le lecteur propre du premier nœud, le second ne peut pas l’atteindre. La migration soit ne démarre jamais, soit doit copier le disque aussi, ce qui ne prend alors plus des secondes mais des minutes voire des heures.

La réponse tient donc en une phrase : le disque doit être visible depuis les deux nœuds.

Deux façons d’y arriver

Stockage partagé. Le disque se trouve à un endroit commun auquel les deux nœuds se connectent : un stockage réseau, un serveur de stockage ou une couche de stockage répartie. Au moment de la migration le disque n’est pas copié du tout, puisqu’il est déjà là. C’est la voie la plus rapide et la plus propre.

Réplication. Le disque reste local mais est copié vers l’autre nœud à intervalles réguliers. Au moment de la migration, seul ce qui a changé depuis la dernière copie est envoyé, d’où la rapidité. Le prix est celui-ci : comme la copie se fait selon un rythme, vous pouvez perdre les dernières minutes. Lors d’une migration planifiée ce n’est pas un problème ; lors d’une panne soudaine cela peut en être un.

La question qui décide de ce qui vous convient est celle-ci : si un nœud meurt d’un coup, combien de minutes de perte acceptez-vous ? Si la réponse est « zéro », il vous faut du stockage partagé. Si la réponse est « quelques minutes, ça va », la réplication suffit et coûte bien moins cher.

Les conteneurs ne se déplacent pas comme les machines virtuelles

C’est là que ceux qui montent leur premier cluster sont le plus souvent surpris. Une machine virtuelle peut être déplacée en marche. Un conteneur non : on l’arrête, on le déplace, on le redémarre.

Il n’existe donc pas de migration sans interruption pour vos conteneurs, même avec un cluster. Ce n’est pas un défaut mais la nature d’un conteneur : une machine virtuelle emporte son propre noyau, un conteneur utilise celui du serveur, et ce noyau ne peut pas voyager.

Conséquence pratique : tenez-en compte au moment de décider quel travail va dans un conteneur et lequel dans une machine virtuelle. Si un travail qui ne tolère aucune interruption se trouve dans un conteneur, ce travail s’arrêtera les nuits de maintenance.

Établissez l’ordre à l’avance

La nuit où vous mettez un nœud à jour, les réponses à ces questions doivent déjà être prêtes : combien de machines sont sur ce nœud, combien peuvent être déplacées, combien doivent être arrêtées, et vers quel nœud vont les déplaçables.

Calculer cela le soir même est une mauvaise idée. Écrivez-le une fois et gardez-le de côté.

Ce que fait Atlas

Avant qu’un nœud soit mis à jour, Atlas liste les machines qui y tournent et vous propose un ordre de déplacement : quelle machine vers quel nœud. La proposition les répartit à tour de rôle sur les nœuds disponibles.

La distinction des conteneurs est faite explicitement ici. Pour les machines virtuelles, la méthode proposée est le déplacement en marche ; pour les conteneurs, la chaîne arrêter, déplacer, démarrer. Le produit ne présente pas cela comme une option, il constate qu’un conteneur ne peut pas être déplacé autrement.

Les machines laissées à la gestion de haute disponibilité sont également signalées, car les déplacer à la main et les laisser à la décision propre du gestionnaire sont deux choses différentes.

Et la proposition reste une proposition : la commande de déplacement ne s’exécute pas toute seule, c’est vous qui appuyez sur le bouton.

Une limite honnête : aujourd’hui Atlas considère toute machine virtuelle en marche comme déplaçable et ne vérifie pas si son disque est réellement visible depuis l’autre nœud. Le produit ne répond donc pas à la question du stockage à votre place, c’est à vous d’y répondre une fois. Lisez la proposition en le sachant.

Sources

La documentation officielle de Proxmox. En anglais, et c’est elle qui a le dernier mot sur ce sujet.

Fiches liées

À quoi cela ressemble dans Atlas ?

Aller à la page produit