Proxmox est une distribution Linux qui gagne à être reconnue. Créée en 2008 par la société Proxmox Server Solutions GmbH, la dernière version 2.2 est sortie le 24 octobre 2012. Cette distribution orientée serveur est basée sur Debian Squeeze avec un noyau personnalisé pour inclure le support OpenVZ (noyau repris de RedHat).
Elle peut être installée en mode "standalone" sur un serveur unique ou en mode cluster sur plusieurs noeuds. Cette dernière solution offrant des possibilités intéressantes telle que la migration de machines virtuelles à froid ou à chaud (!). La distribution Proxmox intègre deux technologies de virtualisation que sont KVM et OpenVz, les deux solutions sont parfaitement intégrées aux interfaces web et ligne de commande.
Pour rappel, la solution KVM est une solution de virtualisation complète, (hardware compris), permettant de virtualiser d'autres OS, tels que Solaris, ou Windows par exemple. Tandis qu'OpenVZ ne permet de virtualiser que des systèmes Linux, c'est une solution de gestion de conteneurs (comme les jails de BSD, zones de Solaris, et LXC de Linux). Cette technologie souvent utilisée lorsque l'on parle de Serveur Privé Virtuel (VPS), a l'avantage d'être plus rapide et moins gourmande en ressources systèmes.
Il n'y a qu'une seule version libre et gratuite de la distribution, la société Proxmox Server Solutions proposant du support payant à ceux qui en auraient besoin.
Les fonctionnalités sont impressionnantes :
- une interface en ligne de comande et web (disponible en francais) permettant de gérer les machines virtuelles tant au format kvm que des conteneurs openvz
- une belle intégration de la couche cluster de linux, permettant de reproduire les fonctionnalités comme HA (High Availability à la vmware), et la migration à chaud
- la prise en charge simplifiée des sauvegardes et des restaurations
- les snapshots de machine virtuelle (disque & ram)
- l'intégration de l'authentification avec un annuaire ldap
- le support de stockages partagés (nfs, iscsi, SAN, drbd)
- le support du bonding en natif
- la gestion de l'ordre de démarrage des VM
- activation de KSM, (déduplication des pages mémoires KVM, démon ksmd)
- Gestion du déport de console graphique en vnc/applet java sur https intégré de base dans l'interface web
Ce qui m'a plu
On peut passer aisément de l'interface web aux commandes cli spécifiques proxmox (pve*), tout en modifiant les fichiers de configuration standards (/etc/network/interface, cluster.conf, …) qui sont rechargés et réanalysés automatiquement. (ce qui est assez rare pour être signalé !)
Il est clair que Proxmox s'est fortement inspiré de l'interface web de l'acteur principal du marché, pour les néophytes l'adaptation est rapide.
La possibilité d'installer Proxmox depuis un iso amorçable ou de migrer depuis une Debian déjà installée (procédure).
Les risques à terme
La virtualisation par conteneur openvz, est-elle pérenne ?
- Proxmox évoluera-t-elle vers LXC ? Sous quelle forme se passera la migration ?
- OpenVz fonctionne bien sur ext3 et ext4, les autres systèmes de fichiers ne sont pas conseillés pour l'instant.
- Il n'y a pas de noyau ultérieur au 2.6.32 supportant openvz.
- Le mélange de la distribution Debian et d'un noyau RedHat peut sembler « original ».
Merci aux contributeurs et relecteurs de la dépêche : Sébastien Stoetzer, Marc Quinton, NeoX
Aller plus loin
- Proxmox Virtual Environnement (Proxmox-VE) (1906 clics)
- Proxmox sur Wikipédia France (3951 clics)
- Site officiel de la technologie OpenVZ (372 clics)
- Site officiel de KVM (497 clics)
# Proxmox évoluera-t-elle vers LXC ? Sous quelle forme se passera la migration ?
Posté par NeoX . Évalué à 3.
j'ai recemment fait la migration inverse (LXC -> OpenVZ sous Proxmox) cherchant une solution container/cluster/migration à chaud et gerable par des non-informaticiens.
ca c'est passé sans probleme.
un conteneur VZ etant un chroot modifié, tout comme LXC.
mais je n'ai pas encore essayé de retourner à LXC à partir d'un containeur VZ.
[^] # Re: Proxmox évoluera-t-elle vers LXC ? Sous quelle forme se passera la migration ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Sauf si on utilise trop de truc noyau (type NFS), le passage d'un système de virtualisation à un autre est globalement assez facile. J'ai transformé des machines physiques en machines réels en moins d'une heure… Idem pour le passage de domU XEN en container LXC.
Globalement, à chaque fois, on doit modifier quelques fichiers (genre inittab, fstab, network/interfaces…) et adapter le fichier de config coté hyperviseur et pas grand chose de plus.
Par contre, attention aux services en mode noyau comme un serveur NFS, là ça marche pas bien voire pas du tout dans les containers ;-(
[^] # Re: Proxmox évoluera-t-elle vers LXC ? Sous quelle forme se passera la migration ?
Posté par CrEv (site web personnel) . Évalué à 10.
En même temps, vu la quantité de travail à réaliser pour passer d'une machine physique en machine réelle…
# Vrai solution à pousser dans les entreprises
Posté par Gilles Mocellin . Évalué à 7.
J'utilise Proxmox depuis 2009, principalement au boulot, mais pas que.
En effet, on peut avoir du Proxmox sur Dedibox.
Et d'ailleurs, sur le premier modèle, OpenVZ prend tout son sens vu la faible puissance et faible quantité de mémoire (2Go).
Je n'ai pas eu la chance de migrer mon premier cluster de 6 machines en version 2.x.
Il est en 1.9 (installé en 1.4, puis upgrade sans soucis).
Mais j'ai pu en installer un petit de 2 nœuds en v2.2, mais sans HA. Il y a vraiment de belles avancées.
Concernant la communauté, il y a un forum et une mailing list.
Les développeurs accueillent évidement les patchs.
Depuis pas très longtemps, il y a un repository Git et un bug tracker.
Bon, comme je ne sais pas m’empêcher de voir les petits défauts, j'aurais deux reproches :
L'aspect HA/Cluster est encore trop compliquée à mettre en œuvre, trop proche de ce qu'est la solution sous-jacente : RedHat Cluster Suite.
L'interface est une représentation du fichier de configuration cluster.conf, pas plus.
Il faut bien connaitre les notions de fencing, failover domain…
Les migration à chaud, à chaque fois que j'en ai eu besoin, ça n'a pas marché. Enfin, surtout sous OpenVZ.
Maintenant, le plus excitant est à venir :
le support de systèmes de stockage distribués : Ceph et sheepdog.
Là, on s'approche du Graal (enfin pour moi) :
Un cluster de VM Hautement Disponible, simplement extensible, sans SPOF, sans composant onéreux (baie de stockage, NAS…).
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 3.
Je suis aussi utilisateur de proxmox depuis 2009,
actuellement je gère un cluster de 5 serveur en 1.9 (ils sont sur 3 site différents), un cluster de deux serveurs en 2.1 chez ovh, deux serveurs seul en 2.1 et un serveur en 1.9.
Bon le problème avec le passage de la version 1.9 à la version 2 c'est le mode cluster, avant un simple lien ssh suffisait, donc chez ovh un petit échange de clés et c'était bon.
Maintenant j'ai du faire un vpn avec openvpn pour mettre les deux serveur 2.1 en cluster chez ovh.
Autrement c'est vraiment stable, j'ai un de mes serveurs dans le cluster en 1.9 qui aura bientôt deux ans de uptime.
J'utilise autant du kvm (pour des windows server 2008 r2 et 2003) qui de l'openvz.
Pour la migration à chaud, en faisant des test on à explosé une base mysql (bon pendant la migration on faisait des reload d'une page sur l'apache qui était dans ce container). Donc comme conseil moi je préconise d'arrêter le container avant.
Un petit conseil pour ceux qui font tourner des os en kvm, utilisez les drivers virtio, vous aurez de meilleures perf
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Maxime G (site web personnel) . Évalué à 1.
Pour un migration de vm, de toute manière, chez dédi ou ovh, il faut aller changer l'ip de serveur dans leur interface, non ?
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 2.
Oui pour les dédiés, mais le cluster de 5 machines n'est pas chez OVH mais dans les mûres d'une entreprise, sur principalement le même subnet (un des trois sites est sur un autre subnet).
Donc dans ce cas ça fonctionne sans problème, enfin ça devrait
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Anonyme . Évalué à 10.
Woaw ! après le Raspberry Pi, le serveur qui tient dans une mûre :)
mais jusqu'où iront-ils ?!
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Gilles Mocellin . Évalué à 1.
Tien, c'est aussi manuel chez OVH ? Parce que c'est le cas avec les dedibox, et c'est dommage. On a pas de haute disponibilité automatique…
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par aderumier . Évalué à 1.
Pour sheepdog et rbd, c'est deja fonctionnel, mais pas encore supporté officielement (il manque les backups).
il faut juste ajouter les stockages dans le fichier de conf /etc/pve/storage.cfg.
(ca sera dispo via l'interface web quand le backup seront en place, pour la prochaine version de proxmox)
les snapshots sont également fonctionnel sur sheepdog et rbd.
les clones devraient arriver pour la prochaine version de proxmox également.
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Frédéric Massot (site web personnel) . Évalué à 1.
Sheepdog est-il stable et utilisable en production ou c'est juste pour le tester ?
Sur le site Sheepdog il est indiqué que c'est expérimental.
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par Antoine . Évalué à 2.
Par rbd, tu veux dire drbd ?
[^] # Re: Vrai solution à pousser dans les entreprises
Posté par moula . Évalué à 1.
Non, ceux sont deux technologies différentes
drbd : disk Replication Bloc device : c'est du RAID1 entre deux machines par le réseau, pas plus de deux pour l'instant.
rbd : Rados Bloc Devise : il y'a plusieurs projets , Ceph, Sheepdog, Haadop…
C'est illimité, plusieurs machines et plusieurs disques… et c'est évolutif.
Merci.
# Des retours sur l'utilisation avec libvirt?
Posté par vlamy (site web personnel) . Évalué à 2.
Bonjour, comme pas mal de commentaires laissent à penser qu'il y a des utilisateurs dans l'assistance, je me permet de poser la question :
Est-ce que quelqu'un a des retours sur l'utilisation de promox avec libvirt ou des outils basés sur libvirt (_virt-manager_, virt-clone,…etc?)
On trouve pas grand chose la dessus et je suis intéressé pour savoir si libvirt fait partie de la philosophie de la distribution ou non.
Merci d'avance pour les réponse, ou pour le moinssage sinon :)
[^] # Re: Des retours sur l'utilisation avec libvirt?
Posté par aderumier . Évalué à 4.
Etant contributeur proxmox, je peux te répondre:
non proxmox n'utilise pas libvirt.
Toute l'implementation est faite from strach, en perl.
Je suis entrain d'implementer le clonage des vms (copy et clone) pour la prochaines version.
D'ailleurs les contributions sont les bienvenues !
Mailing de dev : pve-devel@pve.proxmox.com
[^] # Re: Des retours sur l'utilisation avec libvirt?
Posté par vlamy (site web personnel) . Évalué à 1.
Je ne m'attendais pas à une réponse aussi précise : merci !
Je suis, pour le moment, engagé sur libvirt.
Mais je vais garder un oeil sur l'évolution de proxmox.
[^] # Re: Des retours sur l'utilisation avec libvirt?
Posté par Gilles Mocellin . Évalué à 1.
Ça fait plaisir de voir des contributeurs français !
Bravo !
# question sur la HA justement.
Posté par NeoX . Évalué à 2.
J'ai actuellement 3 serveurs v2.2 en cluster avec un stockage sur NAS via NFS.
Je peux faire les migrations à chaud à conditions d'avoir iptables installés dans les containers.
(parfois je dois quand meme demarrer le container à la main)
par contre je n'arrive pas à activer la HA pour un container apparemment faute de "fencing device".
Apres avoir lu pas mal de chose, j'ai cru comprendre que le "fence device" permet de couper un serveur par son alim (si le fence est un onduleur) ou par le reseau (si le fence est un switch).
Seulement moi, je voudrais surtout que mon node2 demarre le container si node1 est indisponible.
Alors j'ai mal compris la definition du fencing device ?
ou c'est juste que j'ai rien compris à la HA ?
[^] # Re: question sur la HA justement.
Posté par aderumier . Évalué à 1.
Les fencing devices, sont des périphériques externes au serveurs (ipmi, dell drac, hp ilo, ou switchs electrique apc …) qui permettent d'être certain que ton serveur soit éteint avant de redémarrer ta vm automatiquement sur un autre noeud.
(une commande shutdown est envoyée sur ces périphérique)
Imagine que tu ais un problème réseau entre tes nodes. (node1 n'est plus vu par node2 et node3), mais que ta vm tourne encore dessus. (san operationnel).
Sans fencing device, ta vm pourrait être redémarrée sur node2, alors qu'elle tourne encore sur node1.
Et là, c'est la cata.
[^] # Re: question sur la HA justement.
Posté par NeoX . Évalué à 2.
mais qui va envoyer la demande de shutdown sur le fence et pour quel motif ?
ex avec ton exemple :
probleme reseau isolant node1 de node2/3,
qui decide de couper quoi ?
est-ce node1 va demander au fence d'eteindre node2 et node3, ou bien node2 qui va demander à eteindre node1, mais pour quelle raison ce ne serait pas node3 qui fait la demande ?
parce qu'autant avec du CARP ou du heartbeat, on reprend la main si l'autre n'est pas joignable,
autant là, je ne vois pas (j'ai surement encore des choses à lire)
[^] # Re: question sur la HA justement.
Posté par aderumier . Évalué à 1. Dernière modification le 23 novembre 2012 à 15:16.
si jamais node1 n'est plus visible dans le quorum de corosync. (c'est checké en multicast)
node2 ou node3, c'est corosync qui gère ca.
que veux-tu dire par reprendre la main ? sur l'interface web ? (parce que chaque node gère l'interface, c'est master-master, il n'y a pas de bascule du service web). la HA sert uniquement a redémarrer les vms et rien d'autre.
[^] # Re: question sur la HA justement.
Posté par Olivier Giroire . Évalué à 1.
À noter tout de même qu'il existe dans stonith (oui, à des fins de test, surtout pas en prod, toussa toussa) un périphérique virtuel de fencing (type=dummy ou un truc du genre, c'est un simple script du genre "return true" ) qui permet d'évaluer les solutions HA en économisant dans un premier temps l'achat d'un powerswitch si les machines (de test) ne sont pas équipées de contrôleurs hors ligne type idrac ou ilo … on parle d'évaluation de solutions, hein …
[^] # Re: question sur la HA justement.
Posté par Gilles Mocellin . Évalué à 0.
Quand je disais que le cluster à la mode RedHat / Corosync c'était pas facile…
J'aimerais bien savoir comment se débrouille VMware pour sa HA… sans Fencing.
[^] # Re: question sur la HA justement.
Posté par mr_unichs . Évalué à 2.
Le clustering (Actif/Actif ou Actif/Passif) de par sa nature même "n'est pas facile" à mettre en oeuvre.
Pour ma part, je n'ai jamais eu l'occasion de travailler avec VMware.
Mais de prime abord je suis sceptique sur la capacité d'un cluster à fonctionner correctement, en garantissant la cohérence des données en cas de crash d'un noeud, sans fencing.
Je n'ai rien trouvé via google mais j'ai peut-être mal cherché.
[^] # Re: question sur la HA justement.
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
En fait, c'est possible. Le procédé est décrit en page 6 de ce document, la description qui suit est ce que j'en ai retenu (on a un cluster au bureau, mais VMware me gonfle, donc je n'ai jamais trop fouillé) :
Ceci évite d'avoir à configurer une usine à gaz supplémentaire sous la forme d'équipements d'isolation (prises commandées, etc.), qui laisse toujours les utilisateurs dubitatifs. D'ailleurs, les devs de ProxMox s'en rendent compte : lors d'une recherche antérieure, j'étais tombé sur ces messages où l'un d'eux explorait la possibilité d'avoir un mécanisme similaire. D'ailleurs, aderumier, puisque tu contribues à PVE, sais-tu si quelque chose a bougé de ce côté ? Ce serait vraiment classe d'avoir un cluster sans besoin d'équipements externes qui ont tendance à ressembler à des SPOF…
Envoyé depuis mon PDP 11/70
[^] # Re: question sur la HA justement.
Posté par NeoX . Évalué à 2.
j'allais justement posé la question apres le 1er point : comment le poste isolé supprime les verrous s'il est isolé.
admettons qu'on ait 2 reseaux, il faudrait faire du heartbeat entre les machines mais aussi entre la machine et le NAS ?
ou bien avoir les serveurs en connexion directe avec le NAS ? ca limite les possibilités en terme de baie…
[^] # Re: question sur la HA justement.
Posté par rictus (site web personnel) . Évalué à 1.
En général pourtant l'état de l'art veut justement que tu aies un "réseau" dédié de tes noeuds vers le stockage des VM : interfaces réseaux dédiées en NFS ou iscsi dans un plan d'adressage différent ou bien idéalement du SAN…
Mais sinon, c'est sûr que tu fais avec les moyens que tu peux avoir… et proxmox se débrouille assez bien avec de petits moyens.
[^] # Re: question sur la HA justement.
Posté par NeoX . Évalué à 2.
oui mais imaginons,
j'ai 2 baies de 42U,
une pleine de serveurs de VMs
une pleine de Serveur de stockage
il faudrait que je tire des cables directements entre les serveur de VMs et les Stockages (nfs/iscsi) ?
ou bien que je melande des Serveurs de VMs et des Serveurs de stockage dans la meme baie pour les cabler en direct ?
parce que sinon, si le switch entre les deux tombent, le serveur de VM ne peut plus ecrire sur le Stockage pour lever les verrous,
et du coup y a plus de HA.
remarque, il faudrait peut-etre simplement tout doubler.
- 2 cartes reseaux sur le serveur de VM
- 2 switchs (un par carte reseau)
- 2 cartes reseaux sur le serveur de stockage
et ca multiplier par le nombre de serveur (les switchs pouvant etre mutualisés evidemment)
[^] # Re: question sur la HA justement.
Posté par ondex2 . Évalué à 2.
C'est la bonne solution. Si tu fais de l'ISCSI, tu as donc 2 fois le block device qui apparait sur ton système (ex: sdf et sdh), ce qui te permet de faire du multipath. C'est simple à déployer et très robuste si bien configuré. Attention, le channel bonding n'est pas une bonne solution car il ne teste pas l'applicatif, il ne fait que vérifier que l'interface est UP (il y a bien une possibilité de ping ARP mais je n'ai jamais testé).
Dernier conseil : l'ISCSI c'est de l'IP, donc attention à la table de routage. Avoir deux interfaces c'est bien, si tout est routé par la même interface, ça ne sert plus à rien.
[^] # Re: question sur la HA justement.
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Je ne sais pas, mais si j'avais à écrire un tel truc, je n'autoriserais la pose d'un verrou que pour un temps limité mais renouvelable. Si le nœud ne peut plus communiquer avec le stockage, les verrous sautent à la fin du temps d'attente, et les autres nœuds ont le champ libre pour agir.
Envoyé depuis mon PDP 11/70
# Comparaison des solutions
Posté par snotling0 . Évalué à 2.
Je serais d'ailleurs curieux d'avoir des avis sur les forces / faiblesses des différentes solutions de virtualisation sur Linux. Notamment celles dites "légères", genre LXC.
Parce que justement j'utilise LXC depuis peu sur une Ubuntu 12.04 et je dois dire que ça me semble encore peu mature.
Je pense surtout au facteur "d'isolation" entre les invités et l'hôte.
Exemple n°1 : dans un simple "top" ou "ps", le "user ID" des applications tournant dans les invités est "résolu" en utilisant la base utilisateurs de l'hôte. Super pour administrer / surveiller ce qui ce passe…
Exemple n°2 : instancier 2 conteneurs LXC et installer "avahi-daemon", logiciel de base, qui utilise "setrlimit(2)" dans sa configuration de base. Bam, encore un problème, tous les conteneurs semblent participer à un même pool de ressources !?
Bref, deux cas très concrets, rien de sorcier et pourtant ça ne marche pas (comme il faudrait).
À comparer également à la virtualisation légère sur d'autres systèmes d'exploitation. Je pense à "jails" sur BSD et "zones" sur Solaris.
Je viens notamment de découvrir le projet Illumos, construit sur les "cendres" d'OpenSolaris.
Couplé à ZFS, Crossbow (virtualisation réseau) et DTrace, ça m'a l'air bien plus avancé et carré que LXC par exemple.
Alors, ça tient vraiment la route Linux vis-à-vis de la concurrence ?
[^] # Re: Comparaison des solutions
Posté par Kerro . Évalué à 2.
LXC n'est pas de la virtualisation. Comme indiqué sur le site du projet LXC, c'est un chroot aux stéroïdes.
La virtualisation se fait avec Xen, KVM, Proxmox, OpenVZ, VmWare, Virtual PC, Hyper-V. J'en oublie ?
Également avec Bochs mais c'est un autre domaine.
[^] # Re: Comparaison des solutions
Posté par rictus (site web personnel) . Évalué à 2.
Proxmox, ce n'est qu'une surcouche à KVM et OpenVZ, pour les "manager", ce n'est pas un système de virtualisation à proprement parler.
Pour l'exemple 1 : avec OpenVZ, c'est exactement pareil, tu vois sur l'hôte avec top ou ps les process de tes conteneurs, avec les propriétaires de l'hôte.
Je pense que c'est plus les commandes top ou ps qui ne sont adaptés à ce système de conteneur.
[^] # Re: Comparaison des solutions
Posté par rictus (site web personnel) . Évalué à 1.
Bon newbie que je suis en openVZ, je viens de découvrir les commandes vztop et vzps qui te permettent justement de faire le trie entre les process hôtes et ceux de tes conteneurs…
Donc voilà, c'est bien ça : il faut utiliser ces nouvelles commandes à la place des traditionnelles top et ps non prévues pour fonctionner sur un noyau openVZ.
[^] # Re: Comparaison des solutions
Posté par karmab . Évalué à -1.
oui, tu en oublies deux :
-ovirt( version upstream de rhev). Depuis la 3.0 et maintenant la 3.1, je pense perso que c est la meilleure solution libre de virtualisation , directement en concurrence avec vsphere
-y aussi oracle virtual manager, mais, oracle, c est le mal…
[^] # Re: Comparaison des solutions
Posté par Kerro . Évalué à 1.
ovirt et Oracle Virtual Manager ne sont pas des solutions de virtualisation. Ce sont des solutions pour gérer les précédentes.
[^] # Re: Comparaison des solutions
Posté par snotling0 . Évalué à 2.
Et pourtant c'est bel et bien considéré comment de la virtualisation. Une simple recherche sur Google le prouvera très rapidement.
Mais, au-delà de jouer sur les mots, ça ne répond à mon questionnement sur LXC.
# Avenir proche de proxmox
Posté par rictus (site web personnel) . Évalué à 1.
Est-ce que quelqu'un sait ce que va faire proxmox avec la sortie prochaine (disons 1er semestre 2013) de debian wheezy ? Abandon de openVZ au profit de LXC ? Bascule sur wheezy avec toujours un noyau 2.6.32 ? Rien ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.