Retour d'expérience sous Proxmox - blog.lrdf.fr

[Ldfa]

(Dis comme ça, on dirait le nom d'une nouvelle drogue... mais non !)

Si ces dernières années il y a bien un outil dont je suis tombé amoureux, c'est bien Proxmox (bon, ZFS aussi, mais ça fera l'objet d'un autre article).

Proxmox supporte nativement plusieurs "backends" de stockage (plusieurs technologies) pour stocker les VM et les conteneurs : des répertoires locaux, du LVM, des exports NFS, des volumes GlusterFS, des pools ZFS, des LUN présentés en iSCSI, ainsi que du Ceph. En gros, tout ce qui peut exister aujourd'hui, ou presque. Petite pensée émue pour HyperV qui ne supporte pas grand chose, ou encore oVirt qui, si je ne me trompe pas, se limite à du local, du NFS et du iSCSI... Certaines fonctionnalités vont également être implémentées différemment selon le backend, pour tenir compte des spécificités de chacun : je pense par exemple aux snapshots, qui utiliseront les fonctionnalités offertes par LVM ou ZFS quand disponibles, et qui à l'inverse pourront être indisponibles pour les conteneurs LXC stockés dans des répertoires locaux ou des exports NFS. ZFS permettra aussi de compresser de manière transparente les VM/conteneurs, ce qui peut être un véritable argument économique (j'ai personnellement des ratios de compression de 2 en moyenne, sur des jeux de données et des environnements applicatifs variés (hormis multimédia)).

Concernant Ceph, il s'agit d'un véritable parti pris par la société Proxmox elle-même, qui mise sur une solution hyperconvergée, fusionnant les couches de "computing" (CPU, RAM) et de stockage en un tout unifié et évolutif. Bien que je n'ai pas suffisamment de recul sur cette solution, ni sur Ceph d'ailleurs, je trouve cette approche intéressante, car elle permet vraiment de tirer partie de toutes les ressources disponibles (souvent, les disques d'un hyperviseurs sont "perdus", se limitant à l'OS). Concernant les prérequis physiques, on pourrait se dire que Ceph va être gourmand côté réseau, mais comme nous sommes en 2018, vous aurez de toute façon un réseau 10G dédié pour votre stockage, n'est-ce pas ? :)
 

 

KVM + LXC = miam !

Autre intérêt de Proxmox, c'est qu'il offre nativement de la virtualisation traditionnelle (basée sur KVM), pour faire tourner des Linux, des Windows, ou tout autre machin exotique, ainsi que de la conteneurisation (LXC). L'avantage est ici que les 2 technologies sont disponibles au sein du même environnement, administrées depuis la même interface, et ça, c'est méga méga cool (argument technique pointu @inside). Plus besoin donc d'avoir deux (ou plus) infrastructures pour héberger nos services ! Attention toutefois, Docker n'est par exemple pas supporté, mais qui met du Docker en production de toute façon ? (je troll si j'en ai envie, je suis chez moi). Si ce besoin est clairement identifié, il sera toujours possible de s'appuyer sur des VM pour en héberger.

Et donc, qu'en est-il de du côté des autres produits ? oVirt : KVM only ; VMWare ESX : virtualisation traditionnelle only ; HyperV, idem. Oui, on peut greffer des produits supplémentaires pour amener ce genre de fonctionnalités, mais ça n'est pas embarqué nativement (donc surcoût + complexification).
 

J'aime mon manager

Alors là, THE argument en faveur de Proxmox (en plus de tous les autres "THE argument" évoqués jusqu'ici) : l'interface d'administration de nos clusters n'est pas un SPOF ! (Single Point Of Failure). C'est simple : sur VMWare ou oVirt, par exemple, vous avez UN manager (de base (et même si vous pouvez quand même vous connecter sur chacun des ESX individuellement au cas où)). Si vous ne mettez pas en place une solution de repli ou si vous ne payez pas la licence qui va bien pour en déployer un autre, débrouillez-vous le jour où le manager tombe en panne et où un incident se produit à ce même instant sur votre production. Bonne chance pour essayer d'intervenir, les minutes de restauration de votre manager vont vous paraître affreusement longues... Et arrêtez tout de suite avec vos analyses de risque ou vos taux de probabilité : la loi de Murphy, c'est la SEULE qui importe dans un datacenter.

Proxmox, dans sa génialitude, offre une interface d'administration distribuée : chaque hôte intégré au cluster offre la même interface, et peut contrôler tous les autres. En cas de perte d'un hôte... Et bien on s'en fout, on utilise les autres. JUSTE MA-GIQUE. Ah, et j'ai mentionné que l'interface est accessible via un simple navigateur ? Pas de client lourd, pas d'outil à distance (sauf SSH, si vous préférez la CLI), pas de Java, pas de Flash... Console virtuelle pour les VM/LXC, monitoring des ressources, gestion des droits utilisateurs, des pools de ressources, des mises à jour... tout y est, sans rien à installer. Encore une pensée émue pour VMWare vCenter, où la DERNIERE version de Flash est indispensable, celle que même le Chrome disponible sous Linux n'embarque pas...
 

Power up !

Bon, de ce côté-là c'est d'une difficulté insurmontable : on Debian-ise un nouveau serveur, on lui greffe Proxmox (en 5 min chrono), on l'intègre au cluster, et c'est tout. On peut déjà profiter des nouvelles ressources, migrer nos VM, etc. Toujours sans coûts de licence supplémentaires, sans modification d'une quelconque configuration (si vous avez bien pensé en amont vos backends de stockage et vos configurations réseaux).

Ah oui, petit apparté sur un sujet qui me sort un peu par les oreilles : nous sommes en 2018, arrêtez d'utiliser des bridges Linux ! Juste, STOP ! OpenVSwitch, c'est stable, ça juste marche, et c'est infiniment plus simple à maintenir ! Avec des bridges Linux, chaque hôte doit être configuré à la main, tout nouveau VLAN doit être monté à la main sur tous les membres du cluster... Et ne me parlez pas d'automatisation, c'est clairement mettre un pansement sur une architecture old-school de vos clusters. Vous aggrégez (bonding) vos interfaces de production, vous en faites un OVS, et basta. Par défaut, c'est un trunk, c'est-à-dire que tous vos VLAN sont autorisés (du moins ceux que vous laissez passer depuis vos switchs de distribution) : aucune configuration à modifier pour un ajout ou une suppression, déployez juste vos VM, assignez-leur des interfaces taguées (ou non, si vous voulez le gérer dans vos VM), et zou. KEEP-IT-SIM-PLE ! (alors oui, la sécurité nianiania, tous les hôtes sont connectés dans tous les VLAN, #ceylemal : alors non, désolé, mais c'est à vous de ne délivrer que les VLAN pertinents à vos hôtes de virtu, configurez vos switchs, automatisez-les avec Ansible, faites du SDN si ça vous tente, mais vos hôtes de virtu sont JE-TABLES. Vous les déployez, en 5 min c'est opérationnel, vous les décommissionnez en 5 min aussi, ça doit se limiter à ça).

Aparté n°2 : ça, c'est dans le cas d'un backbone layer2 traditionnel. Pour un backbone layer3 (avec de l'OSPF ou du BGP, as you want) + VxLAN par exemple, ça sera un poil plus compliqué niveau configuration. Je rêve de travailler sur ce type d'architecture, d'entrer dans le 21e siècle... :'(
 

Je t'aime moi non plus

Fonctionnalité offerte par je suppose la plupart des produits évoqués jusqu'ici : l'affinité des VM, c'est-à-dire les règles de leur répartition sur les noeuds de vos clusters. Exemple simple : vous avez 3 hôtes et 3 frontaux Web dessus, vous les configurez pour qu'ils ne tournent jamais sur le même hôte au même moment et ainsi garantir un minimum la disponibilité de votre service en cas de perte d'un hôte. Enfin, sur Proxmox c'est plutôt une préférence que vous définissez : vous préférez que les VM XX, YY et ZZ tournent sur l'hôte 1, puis sur l'hôte 2 si perte du 1, puis sur l'hôte 3 si perte du 2, et vous préférez que les VM XX2, YY2 et ZZ2 fassent l'inverse (l'hôte 3 en priorité, etc). Les VM sont donc à la fois réparties selon vos préférences, et également redémarrées automatiquement en cas d'incident sur un hôte : c'est 2 en 1 !

Petit bémol toutefois : il faut BIEN penser cette configuration pour ne pas tout transformer en usine à gaz. Personnellement, je trouve que ça mérite une sacrée gymnastique des neurones pour répartir toute une production sur ce schéma, et que Proxmox gagnerait en accessibilité sur ce point en permettant de juste définir des affinités/répulsivités entre 2 VM, et que le cluster se débrouille tout seul pour les mettre sur deux hôtes différents. Peut-être un jour sur la roadmap ?
 

---

 
Mais tout n'est pas rose pour autant dans le merveilleux monde des Bisounours qui tournent sous Proxmox. Passons à ce qui fâche (toujours d'après mon humble avis).
 

Live-migration or not live-migration ?

Alors, le premier truc vraiment dommageable (même si plus haut j'ai dédouané Proxmox pour ce choix, oui j'aime me contredire moi-même) : depuis Proxmox 4 et le passage d'OpenVZ à LXC, il n'est plus possible (pour le moment ?) de migrer à chaud des conteneurs d'un hôte à l'autre. Ce qui nécessite tout de même de sérieusement revoir certaines architectures.

Je vais toutefois nuancer ce point, comme déjà fait plus haut :

• d'une part, cette problématique part déjà du constat que les kernels supportés par OpenVZ avaient un sacré retard, et que Proxmox voulaient aller de l'avant ;
• ensuite, [argument invalide car je ne suis pas du tout un expert LXC/OpenVZ, donc je me tais et passe au suivant] ;
• et enfin, si on a une archi haute dispo avec plusieurs frontaux, plusieurs BDD, etc, on peut se permettre une interruption de quelques secondes sur l'un d'entre eux (hormis si vous avez des BDD de plusieurs centaines de Go, là ça risque de prendre un petit moment au reboot/à la resynchro...). Bon, semi-argument dédouanant, ça reste un impact à considérer sur sa production. Sinon, mettez le plus critique sur du KVM.

 

LXC, c'est bien mais... non, en fait rien

Un truc qui pouvait être pratique aussi avec OpenVZ, c'était le montage des conteneurs dans l'arborescence des hôtes : vous pouviez les gérer en mode fichier à l'envie, et pour la sauvegarde ça pouvait se révéler pratique (on pouvait sauvegarder l'hôte et les conteneurs en même temps, même si je n'aime pas cette méthode). Depuis LXC (sous Proxmox), les conteneurs sont en mode "RAW", c'est-à-dire que vous avez juste devant vous un fichier image, bien dur, bien opaque. Ou un volume ZFS, ou un VG, selon vos backends de stockage. Mais dans tous les cas, vos conteneurs ne sont plus accessibles en "mode fichier", ce qui a amené pas mal de personnes à rouspéter. Personnellement, je n'en ai cure. Vraiment. Je gère mes LXC en SSH, comme n'importe quelle VM, ça ne change pas ma vie.

Donc bon, critique légère car je ne me sens pas vraiment concerné.
 

Renommer un node

Ah, en voilà un exercice sympathique : renommer un node Proxmox dans un cluster ! Alors, un bon conseil : NE le faites PAS. Juste, non, JAMAIS. Virez le du cluster, réinstallez-le au propre sous un autre nom et réintégrez-le, ça vous économisera un temps précieux. Dans les cas où ce n'est pas possible, préparez-vous à pas mal de manipulations audacieuses, des renommages de fichiers, des modifications dans des bases SQLite, les services de clustering qui ne redémarrent pas correctement car l'ID du node est en conflit avec un autre du cluster qui nianianiania.... Il y a eu plusieurs procédures sur le Wiki de Proxmox pour cette opération au fil des ans, mais aucune n'était 100% safe, tout dépendait de vos versions de Debian/Proxmox, de la chronologie de vos manipulations, etc.

(Après, je suis à peu près sûr que cette manipulation est tout autant déconseillée (voire impossible) sous du oVirt/VMWare).
 

Gratuit = instable ?

Dépôt gratuit obligent, vous aimez vivre dans la peur. Chaque mise à jour est peut-être celle de trop, celle qui flinguera irrémédiablement vos VM, votre production, vos nuits (que vous passerez à restaurer...).

#oupas. Bien que gratuits, les dépôts sont toutefois suffisament stables pour de la production, pour peu que vous preniez quand même la peine de les valider sur un environnement de test pendant quelques jours, mais comme toute mise à jour qui se doit. Si vous utilisez les dépôts de "test", alors là oui bien sûr, mais c'est un choix à assumer :)

Il m'est toutefois arrivé de vivre certaines périodes... disons "intenses" avec Proxmox, en particulier suite à des mises à jour du kernel (il faut savoir que c'est un kernel "custom", les équipes de Proxmox backportant certains patchs depuis des sources RedHat, ou compilant en amont les modules ZFS, par exemple). Il y a ainsi eu des périodes où mes machines KVM crashaient systématiquement sans raison, où mes conteneurs pouvaient ne pas démarrer... Périodes qui donnaient généralement lieu à des fix en "live" sur les forums, testés par la communauté puis reportés dans les dépôts, justement. Ca permet de rapprocher un peu les administrateurs et la communauté, on peut le voir comme ça !

Mais encore une fois, si on valide ça en environnement de test, qu'on évite les dépôts de test et qu'on surveille les forums durant les quelques jours qui précèdent/suivent nos mises à jour, ça reste tout à fait correct (pas plus compliqué que toute distribution Linux, quoi).
 

Répartition auto-magique des VM

Un point en passant sur la gestion des "spares" (hôtes gardés de côté en cas d'incident, pour absorber la production) et de la maintenance des hôtes. Sur Proxmox, quand on souhaite vider un hôte pour effectuer une maintenance (mise à jour, par exemple), on migre toutes ses VM sur un autre. Il n'est pas possible, comme sur oVirt par exemple, de répartir automatiquement les VM sur le reste du cluster, simplement et sans jouer au Tetris.

Un petit quelque chose qui changerait pourtant grandement la vie... :'(
 

La sauvegarde, ce n'est pas accessoire

Allez, cet article est déjà suffisament long comme ça, un petit dernier pour la route : la gestion des sauvegardes des VM.

Alors, points positifs : c'est inclus nativement dans la solution, et ça marche. En revanche, si vous n'avez pas réfléchi et/ou consulté la doc avant de monter votre cluster, vous pouvez parfaitement vous retrouver à faire des sauvegardes de vos conteneurs en mode snapshot (par exemple), et qu'à chaque fois ceux-ci soient éteints puis rallumés pour que la sauvegarde s'effectue... Pourquoi le mode snapshot ne fonctionne pas ? Parce que vous n'avez pas le bon backend de stockage ! Eh oui, il faudra y penser avant, quand vous construirez vos clusters. Mais sinon, ça fonctionne juste out-of-the-box.

Et donc, me direz-vous, qu'est-ce qui ne va pas avec cette solution de sauvegarde ? Deux choses, d'après moi :

• Premièrement, il n'est pas possible (nativement) de faire de l'incrémental. On sauvegarde donc l'intégralité de chaque VM à chaque fois, ce qui est ultra-couteux en terme de temps, de volumétrie, et de bande passante. Et ce sujet est conflictuel depuis plusieurs années : c'est une demande de la communauté qu'on retrouve régulièrement sur les forums, la librairie utilisée par Proxmox en est parfaitement capable... Mais non. Du coup, on peut quand même trouver un script qui active cette "incrémentalité" (oui, je trouvais que ça sonnait bien), mais il faut le réappliquer à chaque mise à jour. J'avoue ne pas du tout comprendre le pourquoi du comment de cette histoire : ça ne coûterait rien aux équipes de Proxmox, et ça ravirait tous ceux qui utilisent cette solution... Bref.
• Et la seconde, c'est du côté de la rétention des sauvegardes : bien qu'il soit possible de définir autant de jeux de sauvegarde qu'on le souhaite, pour toutes ou partie des VM, il n'est pas possible de définir la rétention pour chacun de ces jeux. Elle est définie AU NIVEAU DU BACKEND DE STOCKAGE !!! Je... Je n'ai jamais compris cette logique... Qu'est-ce que ça amène de le faire à ce niveau ? RIEN. Et ça empêche JUSTE de créer des jeux de sauvegarde adaptés à nos besoins, à nos différents envionnements... Même point que précédemment, ça fait des années que c'est remonté, mais aucune évolution. Juste, POUR-QUOI ?

 

 

---

 

En conclusion

Bref, quoiqu'il en soit, Proxmox reste un excellent produit. C'est simple, ça marche, c'est "beau", et ça convient à une très grande variété d'usages. Je connais des environnements de production qui s'appuyent dessus depuis plusieurs années, ça ne bronche pas (enfin, pas plus que d'autres). Malgré les quelques points négatifs évoqués en seconde partie de l'article, je recommande chaudement l'étude de cette solution à tous ceux qui ne la connaissent pas, ou à ceux qui hésite depuis longtemps. Mettez-là en concurrence avec vos oVirt, vos ESX, vos Hyper-V. Oui, il y aura des différences, mais il est parfaitement possible que les fonctionnalités manquantes (s'il y en a) ne soient au final pas indispensables, ou facilement compensables.

Si vous avez eu une autre expérience de cette solution ou si vous avez un point de vue différent, je suis tout ouïe ! Je crois vraiment en celle-ci, j'aimerais la voir se développer davantage dans les catalogues de services des DSI et venir proposer une alternative crédible et simple aux malheureusement trop répandus et onéreux M$/VMWare, notamment dans le public.

Qui sait ? :)

Afficher l’article complet