La sortie récente de la version 3.6 de Xen Orchestra (XO) est l'occasion de vous présenter cet outil de gestion de votre infrastructure Xen, qu'elle soit basée sur Xen+XAPI ou XenServer. Cette interface permet donc de créer des machines virtuelles, les migrer, déplacer à chaud, accéder à leurs consoles, etc. Le tout, depuis un navigateur web.
C'est Vates, une petite startup française, qui est derrière ce logiciel libre (AGPLv3).
Introduction
Basée sur des technologies récentes et performantes (NodeJS, AngularJS…) cette interface est claire et rapide. Le but initial était d'offrir la capacité à gérer ses serveurs virtualisés simplement depuis un navigateur. Cependant, comme le montre la roadmap, de nombreuses fonctionnalités vont progressivement faire entrer l'outil dans un rôle plus large.
Bien sûr, le public visé n'est pas celui d'OpenStack ou de CloudStack, mais l'ajout des permissions utilisateurs pour déléguer des ressources va permettre de répondre à beaucoup de besoins tout en restant très simple à installer et utiliser (cf la partie « Pas d'agents »). C'est même la fonctionnalité la plus attendue par la communauté !
Concepts
Modularité
XO utilise un architecture modulaire :
Cela permet d'utiliser uniquement les « briques » qui répondent à ses propres besoins :
-
xo-serverest le moteur qui s'occupe de communiquer avec les nœuds via XML-RPC ; -
xo-webpropose l'interface web ; -
xo-clis'occupe de la gestion en ligne de commande (avec la notion d'introspection pour exposer très simplement toutes les fonctionnalités dexo-server).
Mais aussi d'autres modules en cours de développement, comme xo-backup, qui permet pour l'instant de faire des Snapshots automatiques des machines en cours d'exécution, mais dont l'objectif à terme est aussi de proposer de faciliter des exports complets (pour faire de la PRA par exemple).
Pas d'agents
Pour rester sur une solution la plus simple possible, il a été choisi de ne pas utiliser du tout le moindre agent. Autrement dit, pas de démon ou autre à installer sur les hôtes Xen ou XenServer. Ceci est possible grâce à une utilisation complète de la XAPI, qui possède beaucoup de fonctionnalités, dont un système d'événements. C'est d'ailleurs ce dernier qui permet à XO d'être vraiment réactif, sur le principe du schéma ci dessous :
Les nouveautés de la version 3.6
Beaucoup de nouvelles choses! Déjà, l'import et l'export de machine virtuelle directement via le navigateur. Sous le capot, le concept de flux NodeJS joue ici parfaitement son rôle et permet de « streamer » le contenu des disques à xo-web via xo-server: ce qui permet de ne pas exposer vos hyperviseurs directement. Il est aussi possible d'exporter ses snapshots en un seul clic, ce qui peut être utile pour les garder dans un coin ou même les distribuer.
Autre nouveauté, la possibilité d'uploader vos patchs via l'interface web. Il est même prévu de vérifier automatiquement la présence de nouveaux correctifs et de proposer de les appliquer automatiquement (ceux qui se souviennent de la faille Xen XSA-108 s'en trouveront rassurés)
Vient ensuite la capacité de l'interface à proposer la « Live Storage Migration », permettant de déplacer une machine virtuelle à chaud même sans stockage partagé. La liste des ajouts ne s'arrête pas là, on peut noter en vrac :
- la possibilité d'allumer un serveur en un clic grâce à la gestion du Wake On LAN présent dans la XAPI
- Permettre d'activer la haute disponibilité des machines virtuelles en cochant simplement une case
- Et beaucoup d'autres choses présentées dans le changelog officiel.
Modèle commercial
Le logiciel est entièrement libre (aGPLv3 donc). Cependant, pour travailler sur le projet à temps plein, Vates propose le modèle commercial suivant :
- un produit en mode « clef en main », XOA (Xen Orchestra virtual Appliance), qu'il est possible de télécharger et d'importer en 1 minute ;
- du support avec garantie de temps de réponse et système de tickets privés.
Pour les autres, tout est disponible sur Github.
En savoir plus
Quelques liens :
- une démo (login et pass : demo) qui est reliée à un petite architecture de test ;
- des vidéos montrant XO en action et ses fonctionnalités ;
- la documentation sur la partie architecture ;
- le dernière conférence donnée au Xen User Summit.
Et voici à quoi cela ressemble, d'abord la vue principale :
Puis une vue sur un hôte :
Cette dépêche a été rédigée avec l'aide de Plam, créateur du projet.
Aller plus loin
- Site officiel (914 clics)
- Le dépôt principal sur GitHub (188 clics)
- Démo en ligne (login et pass : demo) (557 clics)
- Présentation de XO au dernier Xen User Summit (89 clics)
# Ça donne envie de tester
Posté par Raphael R . Évalué à 2.
Car c'est parfois le genre de chose qu'il faut "montrer" si l'on veut que Xen s'impose dans certains SI à la place de mastodontes assez connus.
[^] # Re: Ça donne envie de tester
Posté par RoyalPanda . Évalué à 4.
Clairement, ça donne envie de pousser derrière. Par contre, le prix me semble un peu élevé. Passer de 0€ à 70€ par mois, ça fait un sacré fossé.
[^] # Re: Ça donne envie de tester
Posté par XaT . Évalué à 5.
C'est pas grand chose pour une entreprise (surtout comparé aux autres solutions :D)
[^] # Re: Ça donne envie de tester
Posté par Plam . Évalué à 2.
Bonjour,
Les prix sont en $, donc ça fait moins ;) Et puis il y a du support avec.
On verra si jamais on sort une version moins chère sans support, ça peut être une piste.
[^] # Re: Ça donne envie de tester
Posté par Mali (site web personnel) . Évalué à 3.
70€/mois pour une entreprise, faut relativiser, c'est pas énorme non plus.
[^] # Re: Ça donne envie de tester
Posté par flan (site web personnel) . Évalué à 2.
C'est même rien par rapport au prix du matériel (la plupart du temps). En revanche, c'est souvent un obstacle pour tester. C'est souvent plus facile de justifier une dépense en disant qu'on a comparé avec le reste et que ça vaut largement le prix qu'en se basant uniquement sur le site web (on a souvent des déceptions).
[^] # Re: Ça donne envie de tester
Posté par Julien Fontanet (site web personnel) . Évalué à 1.
Pour tester il y a soit l'installation à la main via le dépôt soit la version Basic qui est gratuite :)
[^] # Re: Ça donne envie de tester
Posté par FantastIX . Évalué à 2.
Attention, hein car quand on pousse derrière, on a souvent besoin de papier frais…
# Xen
Posté par newic . Évalué à 1.
Xen c'est une technologie de virtualisation/hypervision qui vient de chez Citrix, est opensource et est une alternative à la virtualisation selon Microsoft et VMWare.
Et donc XOA serait à Xen ce que vspĥere/vmotion est a ESX(i) ?
[^] # Re: Xen
Posté par XaT . Évalué à 1.
Ce serait comme vCenter Server Appliance yep.
# xen versions
Posté par Xavier Poinsard . Évalué à 1.
A priori ça semble pas supporter la version 3.0.3 de Xen :-(
[^] # Re: xen versions
Posté par Plam . Évalué à 2.
Hello,
C'est plus une histoire de compatibilité entre XAPI et Xen. XO fait « que » discuter avec la XAPI et ne communique jamais directement avec Xen.
# [HS] Schémas
Posté par Storm . Évalué à 2.
Bonjour,
Une question qui n'a rien a voir avec le sujet: les schémas sont-ils dessinés à la main (sur papier puis scannés ou sur un logiciel de dessin), ou bien réalisés avec un logiciel particulier qui utilise un rendu "écriture manuscrite"?
[^] # Re: [HS] Schémas
Posté par Plam . Évalué à 1.
C'est un soft sur iPad, je ne connais pas le nom c'est mon associée qui s'en occupe (j'ai aucun iTruc moi). Je vais lui demander dès que je la vois :)
[^] # Re: [HS] Schémas
Posté par Plam . Évalué à 1.
Réponse : « Paper » sur iOS
[^] # Re: [HS] Schémas
Posté par BAud (site web personnel) . Évalué à 2.
Il y avait eu un journal sur LinuxFr.org parlant de XKCDize et réutilisant http://nbviewer.ipython.org/gist/juhasch/3835181 permettant de faire des schémas à main levé, mais je ne l'ai pas retrouvé :/ (je crois que c'est haypo qui en avait parlé, mais je ne suis pas sûr…).
# [HS] Xen par rapport aux conteneurs légers
Posté par matteli . Évalué à 2.
Je profite de ce sujet pour faire un peu de hors sujet.
J'administre un serveur Proxmox avec des conteneurs openvz.
Comment se situe Xen (avec XOA) par rapport à cette solution (j'ai bien compris que ce n'est pas le même principe de "virtualisation") :
Merci
Matt
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Kioob (site web personnel) . Évalué à 6.
J'utilise beaucoup Xen et pas du tout OpenVZ, mais je vais essayer de répondre.
Déjà, Xen a trois modes de fonctionnement, dans les grandes lignes :
- PV (= ParaVirtualisé) : full software.
- HVM (= Hardware Virtual Machine) : full hardware (et son petit frère «PV on HVM», c'est à dire HVM avec des drivers PV)
- PVH (= ParaVirtualisation Hardware) : une version software qui s'aide des avancées hardware pour améliorer les perfs, mais n'a pas encore toutes les fonctionnalités (pas de migration à chaud, par exemple).
Du coup, ça complique un peu les comparaisons de perf. Dans le mode PV 64bits, les appels système sont plutôt lent par rapport à une machine sans virtualisation (genre 20 fois plus sur un sysbench CPU), mais selon les workloads ça ne se ressent pas forcément (sur de l'Apache/PHP par exemple, je n'ai pas mesuré de différence sensible.
Je n'ai pas testé le mode HVM, n'étant pas spécialement fan.
Par contre le mode PVH en terme de perfs est assez impressionnant, suffisamment pour que je ne remarque pas de différence au score sysbench CPU entre mes VMs et cette même machine sans virtualisation.
Tout ça pour dire qu'en terme de performances & ressources, j'estime Xen plutôt efficace. Là où il se démarque d'un conteneur c'est typiquement sur la gestion de la mémoire : par défaut la RAM allouée à une VM Xen lui est réservée, pas d'overcommit («sur-allocation» ?) à ce niveau, pour le meilleur et pour le pire. Par contre on a accès à la «transcendant memory», pour mutualiser la RAM inutilisée de l'host. Bref, gestion mémoire très différente.
Coté «flexibilité» c'est un grand mot… on peut déplacer des VM à chaud oui, on peut même faire de la «tolérance de panne» via Remus, c'est à dire que l'état de la RAM est synchronisée en temps réel (ou presque) vers un autre host physique, pour que cette seconde VM prenne le relais (sous 300ms je crois) en cas de plantage. Sans reboot donc. Par contre si tu veux partager des fichiers entre tes VMs, c'est plus compliqué…
Quant à la dernière question concernant les interfaces, je serais bien incapable de répondre, n'utilisant ni l'une ni l'autre.
alf.life
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par claudex . Évalué à 4.
Quels sont les impact sur les perfs (parce que des accès mémoires à 0,5ms, ça doit un peut tout tuer) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Kioob (site web personnel) . Évalué à 1.
Je n'ai jamais testé, mais c'est une réplication mémoire asynchrone, par «checkpoint». Je n'en sais pas beaucoup plus, le fait de devoir utiliser un noyau spécifique a été un gros frein pour moi, toutefois sur le site d'Andrew Warfield il y a trois publications très complètes concernant le fonctionnement interne de Remus, dont «SecondSite: Disaster Tolerance as a Service» qui compare notamment les perfs.
Sinon de manière plus générale il y a le Wiki Xen Remus, mais que je trouve nettement moins complet.
alf.life
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Plam . Évalué à 1.
XenServer gère aussi la haute dispo de machines virtuelles (pas au niveau de la RAM par contre), mais c'est trivial à utiliser, cf cet article. Qui plus est avec XO, c'est une case à cocher sur la VM que l'on veut avoir en HA :)
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Kioob (site web personnel) . Évalué à 1.
Yep enfin du coup il s'agit juste de redémarrer la VM ailleurs en cas de plantage complet de l'host physique. Toutes les technos de virtualisation le gèrent, dès lors qu'on utilise un stockage partagé (iSCSI, RBD, etc).
alf.life
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Plam . Évalué à 2.
Techniquement tous le monde le gère, mais packagé et simple d'utilisation avec XenServer tout en étant Open Source et gratuit, j'en suis moins sûr.
Ceci dit, en général, je serai plus partisan de laisser la « très haute dispo » (< 1 ou 2 secs de coupure) au niveau applicatif (services redondés etc.). Mais ce n'est que mon opinion ;)
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Kioob (site web personnel) . Évalué à 1.
Je suis entièrement d'accord, si l'applicatif le gère, c'est très certainement plus efficace que via Xen.
Là où j'y ai recours (mais pas via Remus donc), c'est justement quand l'applicatif le gère pas ou mal.
Genre un serveur MySQL, avant d'avoir du «Galera Cluster» il fallait soit débouler du DRBD+Heartbeat, soit se fier à la réplication asynchrone. Il m'est donc arrivé d'opter pour du Xen over RBD.
Ou bien des sites Web avec un tel taux d'écriture disque qu'une solution NFS ou rsync tenait très mal la charge.
alf.life
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Plam . Évalué à 1.
MySQL :(
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.