[Tutoriel] Démonter proprement un cluster Proxmox VE

Posted by

Faire et défaire des clusters Proxmox VE, c’est toujours travailler

Si vous avez lu et appliqué à la lettre mon article précédent sur les clusters Proxmox VE quand on a pas de multicast (ou autre si vous n’êtes pas bridé sur le multicast), vous devriez être l’heureux propriétaire d’un cluster Proxmox VE fonctionnel.

Mille bravo !

Mais personne n’est parfait et n’est à l’abris d’une faute de frappe, d’un oubli ou d’une erreur, et je me suis retrouvé devant un cluster en vrac, complètement bloqué, avec une partie des nœuds fonctionnels et l’autre marqués « failed ».

OK… J’avoue. Je suis un bourrin quand je bidouille. Ça m’est arrivé… plusieurs fois…

Dans cet article, je vais donc vous donner la marche à suivre pour supprimer complètement toute trace des configurations du cluster et ainsi repartir à zéro pour recommencer (sans avoir à tout réinstaller car ça marche aussi mais bon…)

[Aparté]Une fois encore, si vous ne connaissez pas ProxMox VE je vous invite à consulter les articles que M4vr0x et moi avons écris à ce sujet, il commence à y en avoir pas mal[/Aparté]

Sous le capot

D’abord, je voudrais rapidement rappeler que Proxmox VE est un logiciel de virtualisation qui est majoritairement déployé via un ISO contenant une Debian modifiée. Le cœur du clustering dans ProxMox se base sur Corosync (depuis la version 4+), avec l’ajout d’un filesystem distribué maison pour ce qui est gestion de configuration cohérent sur tous les nœuds (pmxcfs).

On peut récupérer beaucoup d’informations sur le cluster simplement en allant consulter les fichiers de configuration présents dans les dossiers de corosync. C’est d’ailleurs comme ça que je m’en suis sorti quand j’avais tout cassé dans mon article précédent.

Sortir proprement un nœud

La documentation officielle donne la marche à suivre dans le cas où vous souhaitez juste sortir un nœud de votre cluster. Si ce n’est pas vraiment notre but ici, ça peut quand même vous servir et surtout, c’est une des étapes dont nous aurons besoin pour la suite.

ATTENTION ! Si je n’ai peut être pas été assez clair (cf les commentaires), je vais écrire en gras et rouge maintenant pour qu’il n’y ait plus de doute. Couper les services pve-* ne devrait pas impacter vos VMs (qui continuent à tourner), mais supprimer un nœud du cluster SI (elles tournent toujours, mais ont disparues de l’interface) ! 

Read carefully the procedure before proceeding, as it could not be what you want or need.

Move all virtual machines from the node, just use the Central Web-based Management to migrate or delete all VM´s. Make sure you have no local backups you want to keep, or save them accordingly.

Et c’est bien normal : au même titre que Proxmox a réinitialisé la configuration de votre nœud lors de la création du cluster, la même opération est réalisée fait lors de sa sortie. Donc, s’il vous plait, ne jouez pas avec les clusters si vous avez des VMs qui tournent sur vos machines…

Pour la suite de l’article, je vais appeler nœud srv1 le serveur que nous allons garder jusqu’à la fin, et srv2, srv3, etc… tous les autres serveurs du cluster.

Sur le nœud srv1

La première chose à faire est de réduire le nombre de nœuds expected par le cluster corosync. L’idée étant qu’à un moment donné, corosync s’attend à avoir au minimum X nœuds, X étant le nombre de serveurs du cluster. S’il en a moins, le cluster se bloque pour empêcher toute modification dans le cas où on serait en « mode dégradé ». On va donc réduire ce nombre de 1 pour que le cluster ne soit pas trop surpris par la suppression d’un nœud.

Dans mon exemple je n’ai que deux serveurs. Cependant, si on a plus de nœuds, il faudra reproduire la procédure jusqu’à ce qu’il ne reste plus qu’un nœud.

pvecm expected 1

pvecm delnode srv2
    Killing node 2

Sur le nœud à supprimer

A partir de maintenant, pour tout le reste du cluster, le nœud srv2 (ou tout autre à supprimer) n’en fait plus parti. Cependant, la procédure n’agit pas (ou pas entièrement) sur le nœud 2 en lui même : il reste quand même du ménage à faire. Et si on ne le fait pas, et qu’on essaye de le réintégrer dans le cluster, il y aura des restes et l’intégration risque d’échouer à nouveau.

Assurez vous que rien de critique ne tourne sur ce nœud avant retrait du cluster.

systemctl stop pvestatd.service
systemctl stop pvedaemon.service
systemctl stop pve-cluster.service
systemctl stop corosync

A noter que dans Proxmox VE, au delà du simple fichier texte présent sur le filesystem, la configuration est également stockée dans une base sqlite. Si on se contente de supprimer la configuration dans les fichiers, elle sera régénérée dès qu’on redémarrera les services. On va donc devoir la vider à la main :

sqlite3 /var/lib/pve-cluster/config.db
    SQLite version 3.8.7.1 2014-10-29 13:59:56
    Enter ".help" for usage hints.

sqlite> select * from tree where name = 'corosync.conf';
    2|0|3|0|1500655311|8|corosync.conf|logging {
    debug: off
    to_syslog: yes
    }
    nodelist {
        node {
            name: srv1
            nodeid: 1
            quorum_votes: 1
            ring0_addr: 10.9.0.1
        }
        node {
            name: srv2
            nodeid: 2
            quorum_votes: 1
            ring0_addr: 10.9.0.2
        }
    }
    quorum {
        provider: corosync_votequorum
    }
    totem {
        cluster_name: kimsufi
        config_version: 5
        ip_version: ipv4
        secauth: on
        version: 2
        interface {
            bindnetaddr: 10.9.0.2
            ringnumber: 0
        }
    }

sqlite> delete from tree where name = 'corosync.conf';
sqlite> select * from tree where name = 'corosync.conf';
sqlite> .quit

Maintenant qu’on a supprimé la configuration de corosync de la base sqlite, on peut supprimer la configuration définitivement (ou juste en faire un copie, si on est prudent) :

mv /var/lib/corosync/ /var/lib/corosync.$(date +%y%m%d%H%M)
mkdir /var/lib/corosync
mv /var/lib/pve-cluster/ /var/lib/pve-cluster.$(date +%y%m%d%H%M)
mv /etc/corosync /etc/corosync.$(date +%y%m%d%H%M)

Et enfin redémarrer les services :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service

On a donc un serveur qui a retrouvé son état initial (à savoir un serveur hors d’un cluster) sans avoir à le réinstaller complètement.

Pour la suite, je le rappelle : L’idée ici est donc d’appliquer cette procédure sur tous les nœuds sauf un (le dernier, srv1).

Détruire le cluster entier

Nous avons maintenant un cluster contenant une seule machine : srv1. Nous pouvons reproduire la même procédure que précédemment, à un détail près : pas besoin de réduire le nombre de votes expected, déjà descendu à 1.

Et on peut recommencer à jouer en redémarrer les services suivants sur srv1 :

systemctl start pvestatd.service
systemctl start pvedaemon.service
systemctl start pve-cluster.service
systemctl start corosync

TADAM !!!! Vous pouvez re-tout casser ;-)

Source

25 comments

  1. Je vais faire une supposition et me dire que vous avez tenté de supprimer un noeud qui avait encore des VMs dessus (en production ?!? ), sans test préalable et en sans lire ma mise en garde dans l’article… Mais ne vous en faites pas, c’est aussi comme ça qu’on apprend !

  2. tout pareil :( mes VMs n’apparaissent plus et je ne peux meme plus me reloguer :(

    je ne me plains pas :) mais y’a t’il un moyen de restaurer la conf ?

    j’ai tj l’output dans sqlite avant la deletion et j’ai aussi tj les fichiers de conf (car j’ai respecté le tuto a la lettre)

  3. Pour info, je ne fais que traduire le post sur le forum de proxmox et la doc officielle (cf le lien que je donne dans l’article). Donc si ça ne marche pas ou plus, je ne peux pas y faire grand chose (ça vaut surtout pour l’autre personne).
    En revanche, je peux attester que moi, j’ai réussi à le faire, tel que je le décris, avec un cluster en version 4.

    « je ne peux meme plus me reloguer » Qu’est ce que vous voulez dire par là ?
    – Si vous ne pouvez pas vous connecter du tout sur le serveur, je vois mal ce qu’on peut faire.
    – Si c’est sur les VMs, il faut vérifier si elles tournent encore ou pas. Est ce que les processus qemu tournent quand on fait un « ps » ?

    Si on voit les VMs avec un « ps », il faut tout enregistrer quelque part. On pourra reconstruire les fichiers de définitions de la VM à partir des options passées en argument. Ex :
    /usr/bin/kvm -id 111 -name CentOS7 -chardev socket,id=qmp,path=/var/run/qemu-server/111.qmp,server,nowait -mon chardev=qmp,mode=control -pidfile /var/run/qemu-server/111.pid ……

    Quant aux disques des VMs en elles même, elles sont toujours sur le disque donc rien n’est perdu de ce côté là.

  4. Merci pour la réponse rapide , je voulais dire que je ne pouvais plus me loguer via l’interface (mdp refusé) mais bizarrement ce matin je peux a nouveau.
    donc la situation est : je peux me loguer via l’interface , via ssh , ma VM et mon container tourne toujours mais plus rien n’apparait dans l’interface (ca fait comme si je venais juste d’installer proxmox)

    Pourrais vous m’aiguiller comment repopuler l’interface ?
    Sachant que j’ai encore la conf du cluster , y’i aurait il moyen d’importer quelque chose ?

    Sinon , mon idée serait d’exporter puis de réimporter les VMs mais je prefere eviter en raison de la taile des disks .. ma VM est un XPenology avec quelque teras derriere …

    Merci !

  5. Juste pour bien comprendre, sur quel serveur proxmox sont les vms ? Le serveur qui a été retiré du clusteur (via pve delnode) ou le dernier serveur qui est resté ?

  6. en fait , j’ai plusieurs proxmox : 1 chez moi (la ou j’ai fait la boulette) et 2 chez OVH , pour l’instant ils sont indépendant , et hier soir j’ai voulu faire mumuse et tenter de creer un cluster entre chez moi et un des serveurs chez OVH (je loue des kimsufi)

    donc sur le proxmox chez moi j’ai fait « create cluster » puis j’ai voulu faire un « join cluster » depuis OVH , puis je sais plus pq , j’ai décidé de faire l’inverse : creer cluster depuis OVH puis join cluster depuis chez moi mais du coup je pouvais plus faire de join depuis chez moi car j’avais déja crée d’ou ma recherche d’ou ce billet :)

    donc j’ai appliqué ce tuto sur le proxmox chez moi dans l’espoir de virer les informations pour ensuite pouvoir faire un join cluster

    j’ai relu votre commentaire ci dessus et je crois que vous m’avez donné une piste pour repopuler les VMs , je peux m’en sortir comme ca ?
    j’insiste mais sachant que j’ai gardé trace de la conf avant la boulette , y’a pas moyen de reimporter ?

    en résumé , la seule chose que j’ai perdu (a priori) c’est la visibilité des VMs dans l’interface

    Merci !

  7. Si vous avez gardé le fichier de base de données config.db à un moment où les VMs étaient encore visibles, oui ça peut se tenter. Il faut couper les services comme pour la procédure de cet article, copier le fichier « sain », puis redémarrer les services. Les VMs devraient ne pas être impactées et avec de la chance, réapparaitre.

    Si ce n’est pas le cas, un procédure qui marche à coup sur est de recréer à la main les VMs une par une, en remettant les mêmes options que celles qu’on trouve en faisant le « ps » comme je le disais dans mon commentaire d’hier soir. Effectivement c’est pénible mais ça fonctionne, en dernier recours (je l’ai fais une fois)

  8. euh , je ne suis pas sur d’avoir ce fichier config.db dans un etat valide pour la restauration , ce que j’ai c’est l’output donné par select * from tree where name = ‘corosync.conf’ et également le resultant de vos commandes
    mv /var/lib/corosync/ /var/lib/corosync.$(date +%y%m%d%H%M)
    mv /var/lib/pve-cluster/ /var/lib/pve-cluster.$(date +%y%m%d%H%M)
    mv /etc/corosync /etc/corosync.$(date +%y%m%d%H%M)

    en fait j’ai scrupuleusement suivi le tuto , est ce que ca suffit a restaurer la config ?
    a quoi servent ces commandes justement ?

    root@pve:/var/lib/pve-cluster.1805282347# ls -ll
    -rw——- 1 root root 26624 May 28 23:47 config.db

    root@pve:/var/lib/pve-cluster# ls -ll
    -rw——- 1 root root 28672 May 29 10:44 config.db

    EDIT : ok je pense que je peux pas restaurer , si je peux me permettre une derniere question , pouvez vous étendre un tout pitit peu ce que vous entendez par ps ?
    ps pour moi liste les processus donc je vois pas le lien entre ps et le faite de connaitre le détail des VMs

    Merci !

  9. Vu les manipulation de création de cluster dans un sens puis dans l’autre que vous avez fait, je ne sais pas si la base était dans un état correct au moment où elle a été sauvegardée (vu que vous avez déjà des soucis de cohérence).

    Pour ce qui est de « ps », voilà un exemple :

     ps -ef | grep kvm
    root     21179     1  4 May28 ?        00:35:52 /usr/bin/kvm -id 102 -name CentOS7 -chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait -mon chardev=qmp,mode=control -pidfile /var/run/qemu-server/102.pid -daemonize -smbios type=1,uuid=a99fd0d5-869a-4100-8dd9-de0ef43d3f62 -smp 6,sockets=1,cores=6,maxcpus=6 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg -vga std -vnc unix:/var/run/qemu-server/102.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 4096 -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:3927f1cecdb2 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -device virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 -drive file=/dev/pve/vm-102-disk-2,if=none,id=drive-scsi0,format=raw,cache=none,aio=native,detect-zeroes=on -device scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100 -netdev type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=E2:21:DA:24:04:72,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 -machine type=pc-i440fx-2.11 -incoming unix:/run/qemu-server/102.migrate -S
    

    Ici, je sais que ma machine CentOS7 avait l’id 102, une carte réseau virtio-net-pci avec pour adresse MAC E2:21:DA:24:04:72, 6 vCPU en mode « kvm64 », et tout un tas d’autres informations qui seront utiles pour la recréer à l’identique. Certains paramètres (comme kvm64 ou virtio-net-pci) sont important car si on ne les recréé par à l’identique on peut avoir des effets de bords.

  10. ok merci.

    En attendant j’ai essayer de reimporter la conf (stopper les services , copier ce qui a été sauvegardé a l’emplacement d’origine ,demarrer les services) mais no way , no luck , de nouveau je ne peux plus me loguer dans l’interface et dans sqlite le select * from tree where name = ‘corosync.conf’ ne retourne rien.

    Je me demande donc bien a quoi peut bien servir ces backups ?
    Ces fichiers ne devraient t’il pas être sauvegardé AVANT qu’on efface dans sqlite ?

  11. Sur le nœud 1, on supprime le nœud 2 avec le « pve delnode ». Pour autant, ça ne change rien sur le nœud 2, c’est pour ça qu’on est obligé de supprimer le fichier (car il est toujours à l’état AVANT suppression du cluster, c’est tout le but de ce tuto).
    [EDIT] Pour autant, par principe, je ne supprime jamais un fichier de conf (règle personnelle), encore moins une base de données.
    Effectivement dans ce cas précis, le fichier db du noeud 2 n’est pas immédiatement exploitable en état. C’est pour ça que je dis qu’il faut le supprimer dans l’article.
    Cependant, en théorie, on pourrait très bien passer du temps à requêter la bdd et reconstruire une conf propre avec ce fichier. C’est juste du SQL, et on a toutes les infos nécessaires entre la conf du noeud 1 et la sauvegarde de la conf du noeud 2.
    En pratique, il serait probablement plus simple d’avoir la base du nœud 1 en plus, pour que la restauration soit plus « simple ».

  12. Pour ceux qui perdrait leurs VM/CT: en fait ce sont simplement les .conf à recréer dans /etc/pve/lxc/ pour les CT et /etc/pve/qemu-server/ pour les VM.
    Pour voir quelles confs étaient présentent avant modification:
    sqlite3 /var/lib/pve-cluster.YYMMDDHHMM/config.db
    sqlite> select * from tree;

    Et la il suffit de copier les différentes confs dans les dossiers /etc/pve/lxc/ et /etc/pve/qemu-server/

    Il est possible que la configuration du stockage est disparue, celle-ci est aussi visible sur la requête SQLite.

  13. avant de commencer sauvegardez vos confs de vm et containers:
    containers: /etc/pve/nodes/nam-of-the-node/lxc/
    vm: /etc/pve/nodes/nam-of-the-node/qemu-server
    Une fois votre cluster déglingué, vos vm et containers vont disparaitre de l’interface de gestion proxmox. pour les faire réapparaitre, remettez vos confs à leur place.
    Ensuite recréez vos storages à l’identique (cluster -> storage) puis redémrrez vos vm / containers

    Je suggère à l’admin de ce site de l’intégrer en warning en début de tutos histoire d’éviter à certains de suer à grosses gouttes. Perso en bon cascadeur qui se respecte j’ai effectué le tuto sur un cluster en prod, j’ai moins rigolé qu’en écrivant ces lignes….

  14. Wow, merci pour le tuto; jusqu’a maintenant je ré-installais systématiquement le nœud car je n’arrivait pas a tout nettoyer proprement.
    C’est le premier tuto que je vois ou on parle de la base sqlite… Je comprend maintenant d’ou corosync re-sortai sa config!!

    Un grand merci

  15. Bonsoir ,
    je doit sortir un nœud (Proxmox 2.13) , d’un cluster (de 4 nœuds) pour qu’il refonctionner en stand-alone (il reste deux VM en PROD dessus) dans un autre Datacenter.

    apres avoir sauvegarder mes conf , je peux utiliser ce modop ?

    Merci d’avance

  16. Attention, qu’on soit bien sûr de se comprendre : les VMs, elles sont sur le noeud à sortir ? Si oui, elle vont « disparaitre » de l’UI. Cependant elle seront toujours présente sur le stockage. Si vous avez les confs, théoriquement vous pourrez retrouver les disques et recréer les VMs à partir de là. Le mieux serait de pouvoir les déplacer sur le cluster mais je pense comprendre que ce n’est pas le but.

    Dans tous les cas, je n’ose plus rien dire. Moi ça a bien marché les deux fois que je l’ai fais. Mais en commentaire, j’ai eu plusieurs personnes qui sont venues se plaindre que pour eux ça n’avait pas fonctionné correctement.

    Et là on parle de prod donc c’est quand même un peu chaud.

    Je n’ai pas refais la procédure depuis l’article, qui est tirée directement du site de proxmox et les développeurs de la solutions, sur le forum de proxmox. Si vous ne pouvez pas tester à part (avec un cluster de test), je vous conseille plutôt de demander sur le forum de proxmox. Ils sauront vous dire avec plus de certitude que moi.

  17. Bonjour,

    J’aimerai savoir si il y a une contre-indication à enlever un node et par la suite le re-mettre dans le cluster avec le même nom et la même adresse IP

    Merci d’avance,

  18. Non aucune contre-indication. J’ai utilisé cette technique pour éviter de devoir tout réinstaller lorsque j’ai écris d’autres tutos :)

  19. Bonjour,
    merci pour ce tutoriel.
    Existe-t-il un moyen de récupérer les vm détachées via cette suite d’instruction ?
    Merci !

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.