Proxmox v6: Migration de VM à chaud via stockage Ceph

Proxmox v6: Migration de VM à chaud via stockage Ceph

15 mars 2020 0 Par Mairien Anthony

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 !