4

Proxmox cluster Ceph : migration 4.4 vers 5.1

Un mémo sur comment mettre à niveau la version de Proxmox 4.4 vers 5.1 la dernière version stable disponible à ce jour.

A savoir, ici dans cet article la mise à niveau va être un poil plus complexe qu’une simple monté de version d’un seul serveur Proxmox, car dans mon cas c’est un cluster de haute disponibilité avec du Ceph.
La première étape sera une mise à niveau de la verson Ceph Jewel vers Luminous.

La migration de Proxmox 4.4 vers 5.1 va se faire sur chaque nœud du cluster l’un après l’autre sans coupure de service.

Mise à niveau de Ceph Jewel vers Luminous

Avant de migrer la version de Proxmox vers la version 5.1, il faut au préalable mettre à jour Ceph vers la version Luminous.

  • A faire sur un seul noeud du cluster Ceph :
    • Définir le drapeau « sortbitwise » afin de préserver toutes les données écrites sur le Ceph :
    • ceph osd set sortbitwise
    • Définir à non le rééquilibrage automatique pendant le processus de mise à niveau :
    • ceph osd set noout
    • Autoriser explicitement la possibilité de supprimer un pool sous la version de Luminous en ajoutant dans le fichier /etc/pve/ceph.conf et dans la section [global] :
    • mon allow pool delete = true
  • A faire sur chaque nœud du cluster Ceph, changer le nom de version du paquet Ceph dans le dépôt :
  • sed -i 's/jewel/luminous/' /etc/apt/sources.list.d/ceph.list
  • Exécuter la mise à niveau de Ceph sur chaque noeud du cluster, les uns après les autres :
  • apt update && apt full-upgrade
  • Une fois que la version de Ceph a été mise à jour, relancer les services sur chaque nœud du cluster :
  • root@pve-01:~# systemctl restart ceph-mon@0.service
    root@pve-02:~# systemctl restart ceph-mon@1.service
    root@pve-03:~# systemctl restart ceph-mon@2.service
  • Ensuite, désactiver le noout :
  • ceph osd unset noout
  • Vérifier l’état de Ceph :
    ceph -s
    • Résultat sur mon cluster :
    • root@pve-01:~# ceph -s
        cluster:
          id:     fc76a7cc-58c0-4b59-a89d-6387e46f537e
          health: HEALTH_WARN
                  all OSDs are running luminous or later but require_osd_release < luminous
       
        services:
          mon: 3 daemons, quorum 0,1,2
          mgr: 0(active), standbys: 1, 2
          osd: 18 osds: 18 up, 18 in
       
        data:
          pools:   2 pools, 320 pgs
          objects: 406k objects, 1617 GB
          usage:   4825 GB used, 62110 GB / 66936 GB avail
          pgs:     319 active+clean
                   1   active+clean+scrubbing+deep
       
        io:
          client:   679 B/s rd, 999 kB/s wr, 0 op/s rd, 73 op/s wr
      
    • Pour corriger l’erreur « all OSDs are running luminous or later but require_osd_release < luminous« , exécuter la commande suivante :
    • ceph osd require-osd-release luminous
    • Revérifier l’état du Ceph :
    • ceph -s
    • Résultat sur mon cluster Ceph :
    • cluster:
          id:     fc76a7cc-58c0-4b59-a89d-6387e46f537e
          health: HEALTH_OK
       
        services:
          mon: 3 daemons, quorum 0,1,2
          mgr: 0(active), standbys: 1, 2
          osd: 18 osds: 18 up, 18 in
       
        data:
          pools:   2 pools, 320 pgs
          objects: 406k objects, 1617 GB
          usage:   4825 GB used, 62110 GB / 66936 GB avail
          pgs:     318 active+clean
                   2   active+clean+scrubbing+deep
       
        io:
          client:   67552 B/s rd, 873 kB/s wr, 4 op/s rd, 51 op/s w
      

Basculer toutes les VMs d’un nœud Proxmox vers les deux autres

Pour ma part, je vais mettre à niveau chacun des nœuds les uns derrière les autres pour ne pas avoir de coupure de service. Pour chaque nœud que je souhaite migrer vers Proxmox 5.1, je vais basculer toutes les VMs de ce nœuds vers les deux autres via le menu HA.

Mise à niveau de Proxmox 4.4 vers 5.1

  • Modifier les dépôts Jessie par Stretch :
  • sed -i 's/jessie/stretch/g' /etc/apt/sources.list
    sed -i 's/jessie/stretch/g' /etc/apt/sources.list.d/pve-enterprise.list
    echo "deb http://download.proxmox.com/debian/ceph-luminous stretch main" > /etc/apt/sources.list.d/ceph.list
  • Dans mon cas, j’ai OpenManage d’installé avec les dépôts Jessie, à ce jour le dépôt pour Stretch n’existe pas. Pour éviter des problèmes, je désactive le dépôt :
  • sed -i 's/^/#/g' /etc/apt/sources.list.d/linux.dell.com.sources.list
  • Mettre à jour la liste des dépôts :
  • apt update
  • Dans mon cas, je rencontre un problème de clé :
  • W: There is no public key available for the following key IDs:
    EF0F382A1A7B6500

    Ce problème est un bug qui vient avec Debian 9, pour le résoudre il faut installer le paquet debian-archive-keyring :

    apt install debian-archive-keyring
  • Relancer là mise à jour des dépôts :
  • apt update
  • Mettre à niveau le système :
    apt full-upgrade
    • Répondre aux différents questions posées lors de la mise à niveau
  • Lorsque la mise à niveau est terminée, redémarrer Proxmox :
  • reboot
  • Une fois le serveur Proxmox mis à niveau vers la version 5.1, refaire la manipulation sur le second nœud, jusqu’au dernier.

Conclusion

Juste un mot : Proxmox c’est magique !
Ma migration de version c’est déroulé sans accros et sans coupure de service :-)

Ressources

Partager l'article :





fred

"Dire que l'on s'en fiche du droit à la vie privée sous prétexte qu'on a rien à cacher, c'est comme déclarer que l'on se fiche du droit à la liberté d'expression sous prétexte qu'on a rien à dire." Edward Snowden

4 commentaires

  1. Bonjour,

    Deux petites questions relatives à cette migration.

    Vous dites « je vais basculer toutes les VMs de ce nœuds vers les deux autres via le menu HA ». Mais qu’est ce qui vous permet de le faire dans ce menu ? Hormis définir des groups et des resources je ne vois rien qui permette de faire une migration. Il y a bien le menu « Bulk action » (au niveau du node) qui permet de faire un « Bulk migrate » mais qui ne m’aide pas vraiment car il migre aussi les templates et les VMs stoppées. je le fais donc via script pour ne sélectionner que le VMs qui sont up & running …

    Seconde question, une fois le premier, voir aussi le second node upgradé en 5.0, pas de soucis pour migrer les VMs du node 4.0 vers les nodes 5.0 ? Il me semblait qu’à l’époque du passage de PM3.x vers 4.0 ce n’était pas possible …

    Merci d’avance !

  2. Bonjour bel-O-kan,
    pour répondre à la première question, je change simplement le groupe appartenance des VM.
    Pour la seconde question, aucun soucis et c’est ce qui m’a agréablement surpris…

  3. Ah OK merci, je n’avais jamais activé le flag « restricted » sur mes HA groups. En effet c’est bien pratique :-)

Laisser un commentaire

Votre adresse e-mail 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.