Proxmox v6: Migration de VM à chaud via stockage Ceph

Proxmox v6: Migration de VM à chaud via stockage Ceph

Continuité du précédent article Proxmox où nous allons tester la migration de VM à chaud !

I) Migration de VM à la main

Comme dit en introduction, cet article fait suite au précédent (disponible juste ici) où nous avions mis en place un cluster de trois noeuds Proxmox avec stockage distribué Ceph. Ici, nous allons simplement voir comment se passe la fameuse migration à chaud de machine virtuelle, qui consiste donc à migrer une machine virtuelle d’un hôte à l’autre sans l’arrêt de celle-ci.

Bien, on va donc partir sur une machine virtuelle classique avec une Debian 10 Buster installé sur notre stockage Ceph, et démarrée. On clique en haut à droite sur Migration et on peut donc choisir le noeud sur lequel la VM va être migrée, ici ce sera le node 2 :

On peut lancer un ping 1.1.1.1 pour voir si une coupure se produit pendant la migration :

Et hop là ! Comme on peut le voir, la migration n’a pas coupé l’activité de notre VM ! Elle aura durée environ 30s, en sachant que c’est une Debian en installation minimale bien entendu, et que le délai varie en fonction de votre réseau et des disques utilisés, ainsi que des performances serveur.

Bien entendu, c’est une migration “classique”, ici l’intérêt d’avoir réalisé tout un cluster c’est de pouvoir basculer automatiquement les machines virtuelles si un des noeuds venait à tomber…

II) Haute-disponibilité et “migration automatique”

Pour cela on se rend sur Datacenter, puis sur l’onglet HA et Groupes :

On créer donc un groupe de noeuds qui seront utilisés pour notre Haute-Disponibilité. Ici j’ai choisi mes trois hôtes, avec pour chacun une priorité. Ensuite on peut se rendre sur l’onglet HA :

Ici on choisi donc la machine virtuelle qui doit profiter de la haute disponibilité offerte par notre cluster. Dans notre exemple ce sera notre machine virtuelle debian. On choisi ensuite le nombre maximum de redémarrage du service avant de considérer celui-ci comme défaillant. Puis le nombre de “max_relocate”, c’est-à-dire le nombre maximum d’essai de migration du service quand celui-ci est défaillant.

Concernant l’état de la demande, en général on le laissera à started, qui va faire en sorte de garder la ressource en ligne, sinon on peut le passer à stopped pour que la migration garde la ressource éteinte, mais dans le cadre de la HA ça n’a pas grand intérêt.

Bien, on peut donc démarrer la machine virtuelle debian se trouvant sur notre hôte n°2 et si nous le stoppons, la VM devrait être migrée sur un des deux autres noeuds sans s’éteindre…

Et c’est bien le cas ! La machine virtuelle a migré automatiquement quelques secondes après l’arrêt de notre hôte pve-02, et le ping lancé avant la migration n’a pas flanché ! On peut d’ailleurs voir que la VM est maintenant passée sur le noeud pve-01, c’est donc un succès !

On peut donc dire que la migration de vm à chaud en utilisant un stockage distribué est belle et bien fonctionnel avec cette nouvelle mouture de Proxmox 😉

Et bien voilà voilà, ceci conclut déjà la fin de cet article qui j’espère vous aura appris quelques petites bricoles. Mine de rien, notre cluster commence doucement à ressembler à quelque chose… un hôte avec un pool de stockage ZFS en RAID-Z, les trois hôtes en cluster avec pour chacun deux cartes réseaux en aggrégation de liens, reliés à un stockage distribué Ceph permettant de la HA… pas mal !

2 commentaires

comments user
Pascal

Bonjour,
Tout d’abord merci pour vos articles, entre autre ceux avec Proxmox 6. Mais j’ai aussi découvert un nouveau logiciel intéressant, WireGuard. Au niveau professionnel, j’ai un parc d’une dizaine de Proxmox en version 4 et 5 pour différents clients. J’aimerais bien sûr, mettre à jour ces serveurs et les optimiser pour une gestion avec Ceph.

J’aimerais vous poser quelques questions essentiellement pour version 6.

Le premier point, c’est dans le cas ou il y a une coupure brutale d’un Hote où se trouve la VM. Car dans votre cas ci-dessus, vous préciser le mot “stopper”, donc je suppose que vous donnez l’ordre a l’hôte de s’arrêter ou de redémarrer, ce qui lui donne le temps de faire la bascule de la VM. Mais quand est-il quand l’hôte disparaît brutalement ? La VM doit, il me semble, redémarrer sur un 2e hôte et non basculer sans coupure. Me confirmez-vous ? Et combien de temps cela peut prendre entre la coupure et le démarrage fonctionnel ?

Le deuxième point, c’est peut-on faire un raid logiciel (essentiellement un miroir sur deux disques) lors de l’installation, uniquement sur les partitions systèmes, laissant les autres disques pour Ceph ? C’est très utile pour ne pas ré-installer un hôte !!!

Le dernier point, on parle souvent de sauvegarde des VMs, mais quand est-il des paramètres des hôtes Proxmox ? Sans doute moins utile s’ils sont en cluster, mais utile en cas de mauvaise manipulation des fichiers. (Pour ma part, je rajoute systématiquement, dans ma procédure de sauvegarde, tous les dossiers dans lesquels je modifie un fichier.)

Merci d’avance pour vos réponses.
Et bon réveillon,
Pascal

comments user
Mairien Anthony

Merci pour votre commentaire Pascal !

Cela fait pas mal de questions à répondre haha, il serait plus facile de passer par mail pour cela. Pour ce qui est du délai entre la coupure et le démarrage fonctionnel de la VM, je peux d’ores et déjà vous dire que je ne sais pas vous répondre ; cela dépend de beaucoup de facteurs (vitesse de votre réseau LAN, performances des hôtes Proxmox eux-même, taille de la VM etc).

Enfin, pour la sauvegarde des paramètres des hôtes Proxmox je vous avoue que je n’y avais même pas réfléchi, j’en ai parlé à quelques connaissances et ils procèdent comme moi actuellement, c’est-à-dire qu’avant chaque mise à jour ou autre nous réalisons des tests avant de réaliser les dites opérations en production, pour voir les effets que cela engendrerait.

Laisser un commentaire

You May Have Missed