Sortie de Proxmox VE 6.0, les nouveautés

Posted by

Proxmox VE 6.0

Ce n’est pas la première fois que j’écris un article sur les mises à jour de Proxmox VE, une distribution Linux pour faire de la virtualisation qui me tient pas mal à cœur car très simple et très efficace. Aujourd’hui, Proxmox VE 6.0 vient de sortir !

Pour info, le blog ainsi que d’autres services fonctionnent depuis des années sur un hyperviseur Proxmox, ce qui pour moi est un exemple de stabilité et de simplicité, même dans des usecases très simples (sinon je serai passé à autre chose). M4vr0x et moi avons beaucoup écrit sur le sujet.

Mais avant ça ?

La dernière fois que j’avais écris un article sur une release de Proxmox c’était la 5.2 il y a un an, qui avait sorti pas mal de choses sympas.

Depuis, je ne vous ai pas parlé de la 5.3 et de la 5.4, quelques modifs sympas (mais que je n’ai personnellement pas utilisé).

  • Ceph Luminous LTS installable depuis la GUI (5.4)
  • Ajout d’un QDevice pour gérer le quorum dans un cluster à 2 hyperviseurs (5.4)
  • U2F dans l’interface web (5.4)
  • Nesting (faire des containers dans des containers) de containers privilégiés ou pas (5.3)
  • Emulation de VMs ARM sur hyperviseur x86_64 (5.3)

Et Proxmox VE 6.0 ???

Comme toute majeure, il faut s’attendre à pas mal de modifs.

La liste des modifications est longue comme le bras, et les ajouts sont à la fois amenés par la mise à jours des composants principaux et par des améliorations sur les composants internes.

Les composants tiers

D’abord, Proxmox VE 6.0 se base sur la toute nouvelle Debian 10.0 (aka Buster). C’est logique pour l’équipe de Proxmox de partir sur le tout dernier OS, puisque la branche 6.x va durer quelques années.

On tire donc un kernel Linux plus récent que celui PVE 5 (c’était le 4.15) et on passe sur un 5.0. De quoi tirer profit des dernières améliorations du Kernel, notamment pour le stockage (on y reviendra) et le réseau.

Ensuite, les gros composants. Proxmox VE étant une plateforme de virtualisation VM + containers, on va évidemment s’intéresser aux 2 composants qui fournissent ça, à savoir qemu et lxc ont bien évidemment droit à une mise à jour (respectivement 4.0.0 et 3.1). Pour LXC (les containers) je n’ai pas su trouver les améliorations. Pour qemu 4.0.0, on a droit à une majeure mais qui ajoute surtout la compatibilité vers de nouveaux matériels et de nouveaux flags CPU (pour des usecases bien précis).

Une plus grosse modif vient peut être de corosync, le composant qui permet de gérer une grosse partie du clustering, qui passe en version 3 avec Kronosnet. Ça, c’est très impactant. J’ai écris plusieurs articles sur le clustering de serveurs Proxmox avec des machines dédiées chez des cloud providers et j’étais souvent gêné par le fait que corosync utilise du multicast, systématiquement bloqué par les providers. Kronosnet utilise de l’unicast ce qui devrait énormément simplifier les futurs setups de clusters (AKA, plus obligatoirement besoin d’un VPN) !!!

Côté stockage, on passe de Ceph 12 vers Ceph 14 et de ZFS (on Linux) en 0.8.1 (encryption des pools + trim, support de ZFS dans l’UEFI)

Les modifs internes

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester. La plupart sont des améliorations de la GUI :

  • Migration des VMs à chaud depuis l’interface, même si on est sur du local storage. On retrouve une promesse déjà présente en 5.x, qui marchait partiellement en ligne de commande, mais qui devrait être ENFIN disponible dans la GUI (cf ce post sur le forum).

  • Améliorations au niveau du Wizard pour créer des clusters. On peut maintenant sélectionner plus facilement quelle(s) interface(s) doit être utilisée pour la communication Corosync. Une amélioration légère par rapport à ce qu’on pouvait faire en 5.4 avec tinc (article qui n’est jamais sorti car je ne l’avais pas terminé… oups). Dans tous les cas, c’est beaucoup plus simple que ce que j’avais pu montrer en 5.2 ou en 5.0.

  • Encore des améliorations pour gérer Ceph dans la GUI. Je ne peux pas trop en parler car je n’avais pas de machines suffisament proches et puissantes pour monter un cluster Ceph sur mes machines Proxmox VE. Cependant, je pense tester dans les jours qui viennent, profitant du fait que les clusters sont plus simple à créer (donc à tester sur des machines temporaires chez Kimsufi par exemple).

  • Possibilité de configurer les backups non plus par VM/container mais par pool entier (nice to have)

Tu nous montres ?

Une fois de plus, je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je vais très probablement faire des articles dans les semaines qui viennent sur le sujet, en premier lieu la migration de la 5.4 (sur laquelle je suis actuellement) vers la 6.0.

Wait and see !!

Sources

12 comments

  1. Merci pour ce récap !
    Je vous suis depuis peu justement, je me suis beaucoup aider de tes articles !
    Merci !!!
    Je suis pour ma part passer en 6.0.4 ce matin.
    Backup de mes VMs réinstallation propre d’un debian buster. Remis en place de mes fichiers de conf et réinjection de mes backup via la commande qmrestore. Le tout m’a pris 1 heure pour un serveur …

  2. Récap cool…
    « …je n’avais pas de machines suffisamment proches et puissantes pour monter un cluster Ceph… »
    Il suffit de les virtualiser !… ;-)
    Sur l’hôte de virtualisation (Proxmox) :
    echo « options kvm-intel nested=Y » >/etc/modprobe.d/kvm_intel.conf
    ou
    echo « options kvm-amd nested=1 » >/etc/modprobe.d/kvm_amd.conf
    (selon CPU)
    puis reboot…
    Et, choisir « host » comme type de CPU lors de la création des 3 futurs serveurs virtuels « proxmox » du cluster de test Ceph…

  3. Oui pour le nested, mais comment tester un outil comme Ceph dans proxmox de manière significative…
    D’un côté, on va avoir des perfs non représentative avec le CPU (+ overhead virtu) et le disque (overhead qcow2), de l’autre, on aura des perfs réseau idéales car en fait tout se passera en local.
    Je vais plutôt attendre d’avoir le temps de me monter un cluster de machines physiques sur un LAN pour pouvoir me faire une idée ;)

  4. Oui, sans doute… mais cela permettra de déjà tester Ceph en termes de fonctionnalités, de reprise sur incidents de convivialité de gestion, etc … voire même, pourquoi pas, en termes de gain de performances relativement aux disques (virtuels) nus, supports des OSD (bench sur les disques virtuels hébergeant les OSD, versus l’espace Ceph, cela au travers d’une machine virtuelle localisée alternativement sur ces différents espaces, par exemple au travers de l’utilitaire « fio »).
    C’est ainsi que j’ai procédé avant de clusteuriser ma prod… ;-)

  5. Bonjour, génial ton blog au passage, j’apprends énormément sur Proxmox.

    Question : j’ai un devoir à rendre en septembre et je dois proposer l’architecture suivante :

    cluster de 3 serveurs bare-metal sous Proxmox
    Création d’un pool de stockage avec Ceph
    Activation de la HA
    VM de Windows Server qui tourne sur le serveur 1 avec basculement sur le serveur 2 ou 3 en cas de panne/interruption

    Plusieurs questions :

    Faut-il que je créer une deuxiéme VM de Windows Server sur le serveur 2 pour qu’il y est du failover (réplication DNS, AD dans les options de WS) ou bien me contenté du duo HA/Ceph qui me permettra en cas de crash de la VM sur le serveur 1 de la récupérer sur le serveur 2 ?
    Est-ce que je peut appliqué à la fois le duo HA/Ceph et le failover de Windows Server en meme temps ? Intéressant ou inutile en terme de ressources ?
    Avec le duo HA/Ceph, si ma VM crash sur le serveur 1 et que je la recupere sur le serveur 2, vu que le serveur s’est éteint brusquement, je vais surement avoir des pertes de données non ?

    Merci d’avance pour ton aide, je suis tout seul sur le projet et je me triture les méninges de dingue pour tout comprendre.

    Cordialement

  6. Il n’y a pas de réponse universelle à ce genre de problème. Je ne vois pas trop ce que je peux te dire de plus, tu as déjà énuméré toutes les bonnes questions ;)

    A toi de positionner le curseur entre ce qui parait nécessaire en terme de disponibilité et ce qui est overkill.

    En revanche, si tu veux savoir comment moi je fais pour répondre à ce genre de question, il faut essayer de déterminer à quel point chaque service rendu est critique et le coût que l’interruption engendre. Par exemple :

    • si mon serveur DNS est down 5 minutes, est ce que cela a un impact sur mon activité ? Et si c’est 1h ?
    • si mon serveur web ne répond pas pendant 5 minutes, je perd XXXXX€ de chiffre d’affaire

    A partir de là, tu peux commencer à lister les causes possibles de pannes (lien réseau HS, lien stockage HS, disque HS, serveur HS, VM HS, …) et le risque qu’elles apparaissent dans une matrice de risque (impact de l’incident sur l’activité vs le risque qu’il apparaisse).

    Une fois que tu as tout ça, tu es capable de dire si monter 2 VMs Windows au lieu d’une vaut le coup ou pas ou si la réplication et la HA de Proxmox suffisent par rapport à la disponibilité attendue de la plateforme.

    Dans tous les cas, cette liste ne peut pas être exhaustive, il y aura forcément des cas non prévus qui arriveront. Et des risques peuvent ne pas être couverts si on les estimes trop cher à prévenir par rapport au risque. L’important est d’en être conscient.

    Voilà comment moi je ferai dans la vraie vie, mais c’est peut être hors sujet par rapport à ton devoir ;-)

  7. Merci pour ta réponse

    Oui en partie. J’ai pas mal avancé dans mon projet dans du coup j’ai d’autres questions.

    Je souhaite profiter de la HA de Proxmox couplé à Ceph pour que si mon serveur 1 est down, la vm bascule sur le serveur 2 et 3.
    J’ai prévu de faire du bonding en faisant une agréation des cartes réseaux du cluster ainsi que plusieurs pool de stockages (ssd, hdd etc).
    Mais je souhaite aussi activé la fonction « cluster failover » de Windows Server qui si j’ai bien compris réplique ou fait du load balancing (dhcp, dns, ad, serveur de fichier etc).

    Ma question est : puis-je à la fois profiter de la HA de Proxmox/Ceph tout en ayant le « cluster failover » activé sur mes deux VM Windows Server.

    J’ai pas vu d’articles semblable sur internet et je me demande si j’en fait pas trop pour mon infra (c’est qu’une maquette) mais je me dis que c’est la seule solution sur Promox ou je peut récupérer la VM master d’un noeud hs en basculant sur un autre (avec coupure de service meme minime) ainsi qu’avoir un basculement de mes services quasi instantané sur la VM 2 grace au cluster « failover » de Windows Server.

    Merci d’avance pour tes éclaircissements

  8. Bon sang, je vient de reposer la meme question ^^

    SI tu pouvait juste me dire si mon idée n’est pas farfelu car sur internet quand tu tape proxmox ha, on pense qu’il y a que la technique du basculement de VM d’un serveur à un autre alors que pour moi la HA c’est justement ne pas avoir de coupure du tout pendant l’incident.

  9. Et je vais te redire exactement la même chose : je ne peux pas répondre pour toi, il n’y a pas de bonne réponse à cette question.
    A toi de déterminer si le coût et la complexité que ça induit sont justifiés par le gain apporté en terme de couverture de risque.

    ;-)

  10. Merci je comprend beaucoup mieux desormais. Il faut avant tout voir par rapport aux services rendu. Rien que le DNS c’est juste tout en haut de la liste d’aprés ce que j’ai compris. Encore merci pour ta « haute disponibilité » haha :)

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.