Salut,
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti. Avez vous un retour d’expérience sur ce soft ?
Dans l'état actuel de mes recherches ce que j'envisage pour un cluster HA (sous Linux avec quelques services internet de base) ça serait ce genre de composantes : - Debian Squeeze - XEN (KVM ???) - Ganeti - LVM - DRBD
Je ne fais pas trop fausse route ?
Salut,
Je te conseillerai de jeter un oeil du côté de Proxmox VE, basé sur Debian également avec KVM et OpenVZ.
Pas testé Ganeti par contre donc je ne peux pas te dire ce que j'en pense.
Val.
Le 20 juillet 2012 17:28, Artur frsag@pydo.org a écrit :
Salut,
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti. Avez vous un retour d’expérience sur ce soft ?
Dans l'état actuel de mes recherches ce que j'envisage pour un cluster HA (sous Linux avec quelques services internet de base) ça serait ce genre de composantes :
- Debian Squeeze
- XEN (KVM ???)
- Ganeti
- LVM
- DRBD
Je ne fais pas trop fausse route ?
--
Cordialement,
Artur.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
On Fri, Jul 20, 2012 at 07:04:27PM +0200, Valentin FERON wrote:
Salut,
Je te conseillerai de jeter un oeil du côté de Proxmox VE, basé sur Debian également avec KVM et OpenVZ.
Je soutiens proxmox VE en version > 2.0. C'est une superbe plateforme, que cela soit au niveau de l'interface d'administration ou des solutions techniques utilisées. Ça donne une solution vraiment sympa à administrer et plutôt robuste pour le moment (6 mois d'utilisation perso, 3 mois d'utilisation pro pour une plateforme ISP).
Pas testé Ganeti par contre donc je ne peux pas te dire ce que j'en pense.
Non plus. Le plus simple serait de tester proxmox, étant une solution clé en main super simple à déployer (iso prête pour install sur du bare metal). Ganeti à ma connaissance nécessite d'être déployé au dessus d'une infra de virt existante. Concernant le besoin de HA, il y a des migrations online/offline, possibilité d'agencer du DRBD (mais manuellement apparemment), LVM/NFS/iSCI via l'interface web. Pour du HA au sens heartbeat/corosync+fencing, il y a une "certaine" intégration de ces composants mais je n'ai pas poussé plus loin pour ma part, iirc c'est un peu "roots".
Artur: N'hésite pas à préciser tes besoins :)
++
Bonjour, je réagis juste à:
Le 20/07/2012 19:04, Valentin FERON a écrit :
…basé sur Debian également avec KVM et OpenVZ. …
Attention: amha, OpenVZ est à éviter pour les nouveaux déploiements, car ce n'est plus dans Debian à partir de Wheezy. (cf http://wiki.debian.org/OpenVz )
Ici, on s'oriente sur une migration vers LXC sur les machines utilisant OpenVZ, mais ce sera pour 2013, une fois Wheezy stabilisée. ;-)
Si vous avez des retours d'expérience sur du virtuel léger niveau ressources, je suis preneur. ^_^
@+
Bonjour je connais très bien LXC, j'ai bossé sur plusieurs projets dessus - c'est très stable j'avais une Debian comme OS sur le Host et des Centos 6 comme VM Les seuls problèmes venaient des cas limites ( mémoire, CPU ) , mais les cgroups évoluent très vite. De mon point de vue ,par rapport à un VMWARE ou QEMU - il n'y a que linux qui fonctionne bien sur. - il y a pas d'overlap ( donc pas ou peu de pertes ), pour moi le principale avantage par rapport à Vmware et Qemu ou je trouve l'overlap énorme. 5 VM sous Vmware qui dorment sur un HOST bouffent plein de CPU alors que 100 VM LXC qui dorment bouffe presque rien. - de vrais accès disques ... une VM Vmware Mysql qui carbure, bouffe les IO des autres - En enfin un vrai accès au host avec de bon outils ( du ZFS snapshot et clone qui gaz, du raid soft, du cacti , tout ce que tu veux, etc... ) contrairement au busybox like de Vmware (je connais que le Esxi 4... ) bref (hors la virtualisation de windows, freebsd, openbsd etc.. ) c'est à conseiller. Par contre , le déplacement a chaud d'un host a l'autre, n'existe pas ( à ma connaissance ) lien vers des outils de gestion des cgroups: http://lxc.sourceforge.net/ bye Hugues.
Le 21/07/2012 01:12, Fernando a écrit :
Bonjour, je réagis juste à:
Le 20/07/2012 19:04, Valentin FERON a écrit :
...basé sur Debian également avec KVM et OpenVZ. ...
Attention: amha, OpenVZ est à éviter pour les nouveaux déploiements, car ce n'est plus dans Debian à partir de Wheezy. (cf http://wiki.debian.org/OpenVz )
Ici, on s'oriente sur une migration vers LXC sur les machines utilisant OpenVZ, mais ce sera pour 2013, une fois Wheezy stabilisée. ;-)
Si vous avez des retours d'expérience sur du virtuel léger niveau ressources, je suis preneur. ^_^
@+
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Le 21 juil. 2012 10:26, "Hugues" huguesmax@gmail.com a écrit :
Bonjour
- il y a pas d'overlap ( donc pas ou peu de pertes ), pour moi le
principale avantage par rapport à Vmware et Qemu
ou je trouve l'overlap énorme.
Vous parlez de Qemu, ou KVM ?
Cdlt, Rémi Bouhl.
A mon avis les 2, a partir du moment ou on a un nouveau kernel lancé...
Le 21/07/2012 10:51, Rémi Bouhl a écrit :
Bonjour,
Le 21 juil. 2012 10:26, "Hugues" <huguesmax@gmail.com mailto:huguesmax@gmail.com> a écrit :
Bonjour
- il y a pas d'overlap ( donc pas ou peu de pertes ), pour moi le
principale avantage par rapport à Vmware et Qemu
ou je trouve l'overlap énorme.
Vous parlez de Qemu, ou KVM ?
Cdlt, Rémi Bouhl.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Je plussoie fortement pour LXC, et par ailleurs je déconseille fortement OpenVZ.
Concernant OpenVZ, je l'ai utilisé pour fournir des VMs light sur un serveur (hébergement web et consors), je n'ai jamais réussi à obtenir une conf correcte qui ne fasse pas régulièrement killer les processus pour cause d'OOM. Après je n'ai sûrement pas compris toutes les subtilités de la chose mais bon, passons.
Quant à LXC, ayant été initié aux containers il y a un peu plus d'un an (merci Maxence, notamment ! ;)), je commence à l'utiliser en remplacement pour ce genre de services qui n'ont pas besoin d'une virtualisation lourde, et c'est juste génial. Cela permet de choisir assez finement les parties à "virtualiser" et les parties à ne pas "virtualiser". Dans mon cas par exemple, j'ai pu isoler tout le système (arborescence, utilisateurs, processus, etc) sauf la pile réseau que je voulais commune. Inversement, à des fins d'expérimentations réseau, je me prépare un environnement où je ne virtualise que la pile réseau. Et tout ça est d'une impressionnant stabilité.
Cordialement
Le 21 juil. 2012 à 10:26, Hugues a écrit :
Bonjour je connais très bien LXC, j'ai bossé sur plusieurs projets dessus - c'est très stable j'avais une Debian comme OS sur le Host et des Centos 6 comme VM Les seuls problèmes venaient des cas limites ( mémoire, CPU ) , mais les cgroups évoluent très vite. De mon point de vue ,par rapport à un VMWARE ou QEMU
- il n'y a que linux qui fonctionne bien sur.
- il y a pas d'overlap ( donc pas ou peu de pertes ), pour moi le principale avantage par rapport à Vmware et Qemu
ou je trouve l'overlap énorme. 5 VM sous Vmware qui dorment sur un HOST bouffent plein de CPU alors que 100 VM LXC qui dorment bouffe presque rien.
- de vrais accès disques ... une VM Vmware Mysql qui carbure, bouffe les IO des autres
- En enfin un vrai accès au host avec de bon outils ( du ZFS snapshot et clone qui gaz, du raid soft, du cacti , tout ce que tu veux, etc... ) contrairement au busybox like de Vmware (je connais que le Esxi 4... )
bref (hors la virtualisation de windows, freebsd, openbsd etc.. ) c'est à conseiller. Par contre , le déplacement a chaud d'un host a l'autre, n'existe pas ( à ma connaissance ) lien vers des outils de gestion des cgroups: http://lxc.sourceforge.net/ bye Hugues.
Le 21/07/2012 01:12, Fernando a écrit :
Bonjour, je réagis juste à:
Le 20/07/2012 19:04, Valentin FERON a écrit :
…basé sur Debian également avec KVM et OpenVZ. …
Attention: amha, OpenVZ est à éviter pour les nouveaux déploiements, car ce n'est plus dans Debian à partir de Wheezy. (cf http://wiki.debian.org/OpenVz )
Ici, on s'oriente sur une migration vers LXC sur les machines utilisant OpenVZ, mais ce sera pour 2013, une fois Wheezy stabilisée. ;-)
Si vous avez des retours d'expérience sur du virtuel léger niveau ressources, je suis preneur. ^_^
@+
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Le 21 juillet 2012 10:26, Hugues huguesmax@gmail.com a écrit :
Bonjour je connais très bien LXC, j'ai bossé sur plusieurs projets dessus - c'est très stable j'avais une Debian comme OS sur le Host et des Centos 6 comme VM Les seuls problèmes venaient des cas limites ( mémoire, CPU ) , mais les cgroups évoluent très vite. De mon point de vue ,par rapport à un VMWARE ou QEMU
- il n'y a que linux qui fonctionne bien sur.
- il y a pas d'overlap ( donc pas ou peu de pertes ), pour moi le
principale avantage par rapport à Vmware et Qemu ou je trouve l'overlap énorme. 5 VM sous Vmware qui dorment sur un HOST bouffent plein de CPU alors que 100 VM LXC qui dorment bouffe presque rien.
Heuu... j'était pas au courant qu'on pouvait mettre 20x plus de VM sur LXC que sur VMware (niveau conso CPU) ! ha moins que se soit un coup du "kernel timer" !
De plus n'oubliez pas que LXC n'est pas un hyperviseur mais un "conteneur" de VM !
- de vrais accès disques ... une VM Vmware Mysql qui carbure, bouffe les
IO des autres
Pour info : VMware te permet de réserver/limiter les IO disques en fonction des VM...
- En enfin un vrai accès au host avec de bon outils ( du ZFS snapshot et
clone qui gaz, du raid soft, du cacti , tout ce que tu veux, etc... ) contrairement au busybox like de Vmware (je connais que le Esxi 4... ) bref (hors la virtualisation de windows, freebsd, openbsd etc.. ) c'est à conseiller. Par contre , le déplacement a chaud d'un host a l'autre, n'existe pas ( à ma connaissance ) lien vers des outils de gestion des cgroups: http://lxc.sourceforge.net/ bye Hugues.
Le 21/07/2012 01:12, Fernando a écrit :
Bonjour, je réagis juste à:
Le 20/07/2012 19:04, Valentin FERON a écrit :
…basé sur Debian également avec KVM et OpenVZ. …
Attention: amha, OpenVZ est à éviter pour les nouveaux déploiements, car ce n'est plus dans Debian à partir de Wheezy. (cf http://wiki.debian.org/OpenVz )
Ici, on s'oriente sur une migration vers LXC sur les machines utilisant OpenVZ, mais ce sera pour 2013, une fois Wheezy stabilisée. ;-)
Si vous avez des retours d'expérience sur du virtuel léger niveau ressources, je suis preneur. ^_^
@+
Liste de diffusion du FRsAGhttp://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Mon, 2012-07-23 at 10:22 +0200, Manuel OZAN wrote:
Heuu... j'était pas au courant qu'on pouvait mettre 20x plus de VM sur LXC que sur VMware (niveau conso CPU) ! ha moins que se soit un coup du "kernel timer" !
Pour une bonne raison, ça n'est pas le cas.
De plus n'oubliez pas que LXC n'est pas un hyperviseur mais un "conteneur" de VM !
Ce n'est pas un conteneur, c'est un gestionnaire de conteneurs. Techniquement, le principe est d'une simplicité exemplaire : tu définis des identifiants de contexte/conteneur par processus, etc. Par ailleurs, tu peux ajouter des règles/quota sur les ressources limitées par contexte, groupe de contextes, etc. Une bonne image pour le sysadmin débutant est celle des VLAN sur un commut : tout le monde est bien directement sur le switch, les trames ne sont pas analysées par des chips différents, juste tu as des VID qui entrent en jeu et donnent l'illusion de plusieurs commutateurs.
Résultat ? Ca ressemble du point de vue de l'utilisateur à une machine à part : il voit ses processus dans son /proc, il voit son interface réseau, il a une quantité de RAM limitée, même si il exécute au final des processus directement sur la machine.
C'est aussi la raison pour laquelle c'est "moins gourmand en processeur". Comprendre que le seul overhead est la gestion des identifiants de conteneur et des quotas côté kernel. En utilisation intensive, la différence relative diminue sensiblement ; toutefois en idle, la différence d'overhead se fait bien sentir à l'avantage de l'isolation de contexte.
Hello,
De plus n'oubliez pas que LXC n'est pas un hyperviseur mais un "conteneur" de VM !
Ce n'est pas un conteneur, c'est un gestionnaire de conteneurs. Techniquement, le principe est d'une simplicité exemplaire : tu définis des identifiants de contexte/conteneur par processus, etc. Par ailleurs, tu peux ajouter des règles/quota sur les ressources limitées par contexte, groupe de contextes, etc. Une bonne image pour le sysadmin débutant est celle des VLAN sur un commut : tout le monde est bien directement sur le switch, les trames ne sont pas analysées par des chips différents, juste tu as des VID qui entrent en jeu et donnent l'illusion de plusieurs commutateurs.
Résultat ? Ca ressemble du point de vue de l'utilisateur à une machine à part : il voit ses processus dans son /proc, il voit son interface réseau, il a une quantité de RAM limitée, même si il exécute au final des processus directement sur la machine.
C'est aussi la raison pour laquelle c'est "moins gourmand en processeur". Comprendre que le seul overhead est la gestion des identifiants de conteneur et des quotas côté kernel. En utilisation intensive, la différence relative diminue sensiblement ; toutefois en idle, la différence d'overhead se fait bien sentir à l'avantage de l'isolation de contexte.
Dans la serie truc de la meme chose que LXC/OpenVZ, il y a jail qui tourne sur FreeBSD... depuis longtemps (et qui a la chance de ne pas etre un nieme patch du noyau).
Sans la version 9.0 avec l'option VIMAGE, chaque jail peut avoir son propre firewall dedie.... et des tables de routages separes par exemple...
M'enfin c'est du FreeBSD donc pas du Linux aussi...
Xavier
Le 23 juillet 2012 15:09, Xavier Beaudouin kiwi@oav.net a écrit :
Hello,
De plus n'oubliez pas que LXC n'est pas un hyperviseur mais un
"conteneur" de VM !
Ce n'est pas un conteneur, c'est un gestionnaire de conteneurs. Techniquement, le principe est d'une simplicité exemplaire : tu définis des identifiants de contexte/conteneur par processus, etc. Par ailleurs, tu peux ajouter des règles/quota sur les ressources limitées par contexte, groupe de contextes, etc. Une bonne image pour le sysadmin débutant est celle des VLAN sur un commut : tout le monde est bien directement sur le switch, les trames ne sont pas analysées par des chips différents, juste tu as des VID qui entrent en jeu et donnent l'illusion de plusieurs commutateurs.
Résultat ? Ca ressemble du point de vue de l'utilisateur à une machine à part : il voit ses processus dans son /proc, il voit son interface réseau, il a une quantité de RAM limitée, même si il exécute au final des processus directement sur la machine.
C'est aussi la raison pour laquelle c'est "moins gourmand en processeur". Comprendre que le seul overhead est la gestion des identifiants de conteneur et des quotas côté kernel. En utilisation intensive, la différence relative diminue sensiblement ; toutefois en idle, la différence d'overhead se fait bien sentir à l'avantage de l'isolation de contexte.
Dans la serie truc de la meme chose que LXC/OpenVZ, il y a jail qui tourne sur FreeBSD... depuis longtemps (et qui a la chance de ne pas etre un nieme patch du noyau).
Sans la version 9.0 avec l'option VIMAGE, chaque jail peut avoir son propre firewall dedie.... et des tables de routages separes par exemple...
M'enfin c'est du FreeBSD donc pas du Linux aussi...
Xavier
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Il y a aussi les zones solaris avec pas mal de choses sexy pour paramétrer les ressources (et encore plus si on couple tout ça avec ZFS).
Salut,
Le 20/07/2012 19:04, Valentin FERON a écrit :
Je te conseillerai de jeter un oeil du côté de Proxmox VE, basé sur Debian également avec KVM et OpenVZ.
Au vu des messages, je vais approfondir Proxmox VE + KVM + DRBD. Pour éviter de polluer ce thread je vais un faire un nouveau si je m'en sors pas tout seul. :)
Merci à tous !
Salut,
Le 24 juil. 2012 12:08, "Artur" frsag@pydo.org a écrit :
Salut,
Le 20/07/2012 19:04, Valentin FERON a écrit :
Je te conseillerai de jeter un oeil du côté de Proxmox VE, basé sur Debian également avec KVM et OpenVZ.
Au vu des messages, je vais approfondir Proxmox VE + KVM + DRBD.
Vu que personne n'en a parlé j'envoi Openstack :) Debian a même un petit howto pour faire un cluster de deux machines.
http://wiki.debian.org/OpenStackHowto
Au $travail on a également parlé d'hadoop mais pas encore eu le courage de m'y mettre. Si certain on un retour sur hdfs ça m'intéresse (pour stocker plein de fichiers (millions) d'entre 1 et 2 Mega).
Yop,
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti.
Avant que j'oublie, sans jamais avoir utilisé, je sais qu'il y a proxmox aussi. De ce que j'en ai vu/compris, c'est plus "à la plesk", comprendre une interface qui fait des choses derrières mais tu sais pas trop quoi. (je peux me tromper aussi).
Avez vous un retour d’expérience sur ce soft ?
Un peu, j'ai pas mal touché à ganeti y'a ~ 2 ans, et y retouche depuis (très) peu de temps. Ce qui est dessous est donc à prendre avec des pincettes.
Dans l'état actuel de mes recherches ce que j'envisage pour un cluster HA (sous Linux avec quelques services internet de base) ça serait ce genre de composantes :
- Debian Squeeze
- XEN (KVM ???)
- Ganeti
- LVM
- DRBD
Je ne fais pas trop fausse route ?
Je pense pas. Ca correspond à ce que j'avais monté: un cluster de virtu "du pauvre" (pas de shared storage, petits serveurs, etc). Le worflow "habituel" de ganeti c'est effectivement générer une vm suivant certains paramètres, sur du xen ou kvm (en para ou full virt, kernel hote ou guest au choix), en mettant tes disques sur du drbd qui sont eux meme du lvm, avec des possibilités de placer ses vm à la main ou automatiquement (htools).
Attention au coté HA, Ganeti fait et ne fait pas certaines choses : Il fait : - migrer une vm à la mano vers son secondaire - déplacer le secondaire d'une vm d'un noeud X à un noeud Y - évacuer un noeud (pratique pour de la maintenance) - détecter périodiquement les vm arrêtées par erreur et les relancer - hot & cold migration Il ne fait pas : - migration de vm en FO.
Comprendre que Ganeti est capable de voir qu'une vm/qu'un node est down, mais il ne prendra jamais la décision de la/les redémarrer sur leur(s) slave(s).
En bref, si tu cherches un outil qui gère le drbd/lvm pour toi, avec un certain confort, Ganeti est peut-être ce qu'il te faut. Si tu veux un truc qui fait la HA tout seul, raté. Et de mémoire (tu as tes pincettes ?) ganeti permet pas facilement de placer un hook quand une vm est détectée down. Il faut donc un outil extérieur pour déclencher la migration.
Pour info, mon setup était pour majoritairement de l'hébergement web, une quinzaine de noeud, xen ou kvm, sur des *box (ovh, free, en lan, etc ...) avec un kernel host ou guest suivant les besoins. On a un haproxy en frontal sur chaque noeud. C'est assez efficace, on peut migrer une vm d'un noeud X à un noeud Y sans coupure (merci haproxy). On a aussi de l'ospf dans le cluster pour que les hosts mettent leur route à jour quand une vm migre (sans changer d'ip).
Maxence
Le Fri, Jul 20, 2012 at 07:15:26PM +0200, Maxence Dunnewind [maxence@dunnewind.net] a écrit:
Yop,
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti.
Avant que j'oublie, sans jamais avoir utilisé, je sais qu'il y a proxmox aussi. De ce que j'en ai vu/compris, c'est plus "à la plesk", comprendre une interface qui fait des choses derrières mais tu sais pas trop quoi. (je peux me tromper aussi).
Oui, proxmox, c'est une jolie WUI pour les frustrés de vmware.
[...]
Attention au coté HA, Ganeti fait et ne fait pas certaines choses : Il fait :
- migrer une vm à la mano vers son secondaire
- déplacer le secondaire d'une vm d'un noeud X à un noeud Y
- évacuer un noeud (pratique pour de la maintenance)
- détecter périodiquement les vm arrêtées par erreur et les relancer
- hot & cold migration
Il ne fait pas :
- migration de vm en FO.
Comprendre que Ganeti est capable de voir qu'une vm/qu'un node est down, mais il ne prendra jamais la décision de la/les redémarrer sur leur(s) slave(s).
Nous, on utilise pas mal Ganeti, ici. Et le fait qu'il n'y ait pas de failover automagique, ça fait partie des choses qu'on aime bien. Typiquement, la plupart des pannes qu'on ait eu, qui ont nécessité de basculer des vms, un bidule automatique aurait surement fait pire que bien.
Quelques points à avoir en vue, pour le choix :
- Ganeti utilisant drbd, les i/o sont en partie limitées par ça. Ie, les écritures n'étant considérées consistantes qu'une fois écrites sur les 2, la partie réseau introduit un peu de latence.
- Actuellement (mais ça arrive, dans les prochaines versions), ça ne sait bien gérer que les utilisationsa avec drbd. Pour du shared-storage sur SAN, ça n'est pas vraiment adapté. (un peu testé avec les version de dev, y'a quelques mois, c'était presque-pret)
Salut,
Je l'utilise depuis 3 ans à présent sans aucun soucis. J'ai surchargé Ganeti pour avoir d'autres fonctionnalités, cela me permet depuis plusieurs années de proposer des solutions de cloud sans nas/san hébergé sur plusieurs machines de loueurs de serveur. Les hyperviseurs communiquent entre eux par tunnel vpn, les machines sont déplaçables à chaud, elles sont redémarrées automatiquement si tu n'as pas donné un ordre strict d'extinction. En gros une solution de vmWare VSA mais en Open source et sans limite ridicule de 3 serveurs.
Tu peux aussi l'utiliser avec un espace partagé, opté pour un subnet normal.
Par chez nous on déploit en Debian Wheezy avec un kernel préparé pour Xen de la branche 3.4. Des mesures de performances faites entre une Debian de base non virtualisée et le même OS dans une vm Xen HVM on perd 3-4% de performance ce qui est plus que tolérable surtout pour des machines d'entrée de gamme.
On fait des prestations d'installation et d'infogérance de cette solution auprès de TPE/PME qui ne veulent pas partir dans un schéma de licence et de nas/san tout le monde est content.
L'avantage que j'y trouve c'est une souplesse hors du commun, la mixité de la virtualisation dans les locaux pour l'usage bureautique avec un PCA/PRA hors site, un budget infrastructure très inférieur aux prérequis vmware,
On a fait une petite page de présentation http://www.digdeo.fr/services/hebergement-serveur-machine-virtuelle pour montrer un peu les différents cas rencontrés.
Donc au final une très bonne base pour faire un cluster ou un cluster hybride de virtualisation.
Le 20/07/2012 17:28, Artur a écrit :
Salut,
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti. Avez vous un retour d’expérience sur ce soft ?
Dans l'état actuel de mes recherches ce que j'envisage pour un cluster HA (sous Linux avec quelques services internet de base) ça serait ce genre de composantes :
- Debian Squeeze
- XEN (KVM ???)
- Ganeti
- LVM
- DRBD
Je ne fais pas trop fausse route ?
Hello,
Excerpts from Artur's message of Fri Jul 20 17:28:07 +0200 2012:
Dans ma recherche de solutions de haute disponibilité basées sur la virtualisation je suis tombé sur Ganeti. Avez vous un retour d’expérience sur ce soft ?
Dans l'état actuel de mes recherches ce que j'envisage pour un cluster HA (sous Linux avec quelques services internet de base) ça serait ce genre de composantes :
- Debian Squeeze
- XEN (KVM ???)
- Ganeti
- LVM
- DRBD
Je ne fais pas trop fausse route ?
Il y a eu une présentation d'un des développeurs Ganeti aux RMLL cette année: http://rmll.ubicast.tv/videos/virtualizationgoogle/
Où Ganeti semble se distinguer, c'est qu'il permet d'utiliser le stockage local (pas besoin de SAN/NAS) tout en offrant de la haute-dispo (grâce à DRBD) et permet de déplacer les machines virtuelles d'une machine physique à l'autre sans les arrêter.
À+, Marc
-
Artur -
David H. -
Dominique Rousseau -
Emmanuel Thierry -
Fernando -
Hugues -
Manuel OZAN -
Marc Fournier -
Maxence Dunnewind -
Pierre Jaury -
Romain Boissat -
Rémi Bouhl -
seb astien -
Valentin FERON -
Wallace -
Xavier Beaudouin