Bonjour, Dans la catégorie bonne pratique, je vous propose de discuter de l'installation d'une plateforme virtualisée dans le but d'héberger une application SaaS standard. Je vous détaille mon plan d'action point par point, à vous de le commenter. Tout d'abord, le serveur est en location chez un hébergeur, il est somme toute assez véloce, à savoir: - Proc 6 coeur 3Ghz - 32G de ram - 2 SAS 900G - 2 SSD 140G - Raid hard Le plan d'action serait le suivant: * Installation d'ESXi 5, bs=2M pour le datastore, en raid1, sur les SAS. Cela me laisse donc la possibilité de créer des disques virtuels jusqu'à 512G, tout en ayant la sécurité du raid. IP publique, mais firewall en amont. ** Comment monitorer le raid, et meme l'esxi, depuis un nagios par exemple ? J'ai bien vu quelques checks, mais cela semble bien moins souple qu'un linux. On a déjà du vmware et je cherche à rationaliser. Les vms maintenant: * Installation d'un openbsd, en ip publique, pour faire du nat, et avoir pf. Une patte en ip privée pour alimenter les briques du dessous, à savoir web, tomcat etc. Pas accessible en ssh depuis le ternet. * Installation d'une vm dite d'administration, ip publique. Accessible en ssh, et offrant rebond aux autres vms. Hébergeant d'éventuels interfaces d'administration (script, frontend, backuppc). * Installation d'un nginx, pour équilibrer, ou balancer, la charge, sur deux serveurs web derrière. Pouvoir en isoler un, avoir du failover, je n'ai pas approfondi ce point. Dans l'immédiat il n'y aura qu'un nginx en reverse proxy. * et/ou installation d'un haproxy, au dessus, à côté ou en dessous du nginx, pour équilibrer les tomcats. Je n'ai pas approfondi ce point non plus. * Installation d'un postgresql, avec la BDD sur les SAS, monté via le vmware. Au prix des SSD c'est ma priorité. ** Ce point me pose le plus de souci. Le SSD a été choisi pour ses très bonnes performances. Que faire ? Mettre les SAS en raid1 hard ? Installer deux vms, chacune héritant d'un sas ? Et créer une réplication pgII ou pgIII de mémoire, ou un serveur est dédié à l'écriture, l'autre à la lecture ? Un autre type de réplication ? Sachant que pour l'instant, l'application est peu gourmande mais je prévois. Je fais du capacity-planning. Ou du performance-management ? Bref, je prévois pour ne pas etre emmerdé dans un an. Coté stockage, nfs/zfs, mais cela fera l'objet d'un autre mail. Merci pour vos retours. Sébastien
Bonjour, Le 11/04/2012 20:56, seb astien a écrit :
Je vous détaille mon plan d'action point par point, à vous de le commenter.
je vais commenter une partie alors :)
Tout d'abord, le serveur est en location chez un hébergeur, il est somme toute assez véloce, à savoir: - Proc 6 coeur 3Ghz - 32G de ram - 2 SAS 900G - 2 SSD 140G - Raid hard
d'après mon experience, le SSD moyen et bas de gamme n'est pas terrible niveau perf et fiabilité. Un hdparm donne de meilleure perf sur un RAID10 6x disques SAS @15krpm, qui sera pourtant moins cher pour plus de capa. Le gain en conso est minime, j'ai été surpris et déçu... Faut taper dans le haut de gamme, voir Fusion IO, pour avoir un réel gain de perf (et pas des moindres d'après ce qu'on peut lire ! )
Le plan d'action serait le suivant:
[...snip...tout pleins de VMs...] Le tout redondé avec un 2ème serveur, en DRBD ou technos VMware ou autre, et ça me parait pas mal :) -- Greg
Salut, D'accord avec Greg, les SSD en prod, moyen bof, faut vraiment taper dans le haut de gamme pour voir une vraie différence. Sinon, effectivement, une redondance avec un second serveur me parait être une bonne idée. Et pourquoi plus ESXi plutôt que Xen ou KVM ? Le 12 avril 2012 15:49, Gregory Duchatelet <greg-frsag@duchatelet.net> a écrit :
Bonjour,
Le 11/04/2012 20:56, seb astien a écrit :
Je vous détaille mon plan d'action point par point, à vous de le
commenter.
je vais commenter une partie alors :)
Tout d'abord, le serveur est en location chez un hébergeur, il est somme
toute assez véloce, à savoir: - Proc 6 coeur 3Ghz - 32G de ram - 2 SAS 900G - 2 SSD 140G - Raid hard
d'après mon experience, le SSD moyen et bas de gamme n'est pas terrible niveau perf et fiabilité. Un hdparm donne de meilleure perf sur un RAID10 6x disques SAS @15krpm, qui sera pourtant moins cher pour plus de capa. Le gain en conso est minime, j'ai été surpris et déçu...
Faut taper dans le haut de gamme, voir Fusion IO, pour avoir un réel gain de perf (et pas des moindres d'après ce qu'on peut lire ! )
Le plan d'action serait le suivant:
[...snip...tout pleins de VMs...]
Le tout redondé avec un 2ème serveur, en DRBD ou technos VMware ou autre, et ça me parait pas mal :)
-- Greg
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Ludovic Cartier
Salut, Ont vois de plus en plus de personnes utiliser ESXI, je trouve cela dommage. Xen à tres bonne réputation en production,ont l'utilise d'ailleurs beaucoup, alors que celui de Vmware juste un peu (installé par un ancien admin) Je suis l'idée de Ludovic sur ce point. Le 12 avril 2012 16:17, Ludovic Cartier <cartier.ludovic@gmail.com> a écrit :
Salut,
D'accord avec Greg, les SSD en prod, moyen bof, faut vraiment taper dans le haut de gamme pour voir une vraie différence.
Sinon, effectivement, une redondance avec un second serveur me parait être une bonne idée.
Et pourquoi plus ESXi plutôt que Xen ou KVM ?
Le 12 avril 2012 15:49, Gregory Duchatelet <greg-frsag@duchatelet.net> a écrit :
Bonjour,
Le 11/04/2012 20:56, seb astien a écrit :
Je vous détaille mon plan d'action point par point, à vous de le
commenter.
je vais commenter une partie alors :)
Tout d'abord, le serveur est en location chez un hébergeur, il est somme
toute assez véloce, à savoir: - Proc 6 coeur 3Ghz - 32G de ram - 2 SAS 900G - 2 SSD 140G - Raid hard
d'après mon experience, le SSD moyen et bas de gamme n'est pas terrible niveau perf et fiabilité. Un hdparm donne de meilleure perf sur un RAID10 6x disques SAS @15krpm, qui sera pourtant moins cher pour plus de capa. Le gain en conso est minime, j'ai été surpris et déçu...
Faut taper dans le haut de gamme, voir Fusion IO, pour avoir un réel gain de perf (et pas des moindres d'après ce qu'on peut lire ! )
Le plan d'action serait le suivant:
[...snip...tout pleins de VMs...]
Le tout redondé avec un 2ème serveur, en DRBD ou technos VMware ou autre, et ça me parait pas mal :)
-- Greg
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Ludovic Cartier
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut, entièrement d'accord avec tout ce qui a été dit avant. Pareil de notre côté, iscsi-san en RAID10 sur du SATA 1Tb@7.2k, et arrive quand même à avoir beaucoup d'IO et des performances. Par contre, pourquoi ESXi niveau debuggage et "bidouillage" c'est pas le top. Xen ou KVM a déjà montré ses performances avec une communauté très active. Déjà eu de gros problème sur le backup des VMs sous ESXi qu'on a mis plus d'un mois à débugger. Le 12/04/2012 16:29, Sébastien Mureau a écrit :
Salut,
Ont vois de plus en plus de personnes utiliser ESXI, je trouve cela dommage.
Xen à tres bonne réputation en production,ont l'utilise d'ailleurs beaucoup, alors que celui de Vmware juste un peu (installé par un ancien admin)
Je suis l'idée de Ludovic sur ce point.
Le 12 avril 2012 16:17, Ludovic Cartier <cartier.ludovic@gmail.com <mailto:cartier.ludovic@gmail.com>> a écrit :
Salut,
D'accord avec Greg, les SSD en prod, moyen bof, faut vraiment taper dans le haut de gamme pour voir une vraie différence.
Sinon, effectivement, une redondance avec un second serveur me parait être une bonne idée.
Et pourquoi plus ESXi plutôt que Xen ou KVM ?
Le 12 avril 2012 15:49, Gregory Duchatelet <greg-frsag@duchatelet.net <mailto:greg-frsag@duchatelet.net>> a écrit :
Bonjour,
Le 11/04/2012 20:56, seb astien a écrit :
Je vous détaille mon plan d'action point par point, à vous de le commenter.
je vais commenter une partie alors :)
Tout d'abord, le serveur est en location chez un hébergeur, il est somme toute assez véloce, à savoir: - Proc 6 coeur 3Ghz - 32G de ram - 2 SAS 900G - 2 SSD 140G - Raid hard
d'après mon experience, le SSD moyen et bas de gamme n'est pas terrible niveau perf et fiabilité. Un hdparm donne de meilleure perf sur un RAID10 6x disques SAS @15krpm, qui sera pourtant moins cher pour plus de capa. Le gain en conso est minime, j'ai été surpris et déçu...
Faut taper dans le haut de gamme, voir Fusion IO, pour avoir un réel gain de perf (et pas des moindres d'après ce qu'on peut lire ! )
Le plan d'action serait le suivant:
[...snip...tout pleins de VMs...]
Le tout redondé avec un 2ème serveur, en DRBD ou technos VMware ou autre, et ça me parait pas mal :)
-- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Ludovic Cartier
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Merci à tous pour vos réponses. Pour le choix d'ESXi, je reprends une infra qui a migré de Xen vers ESXi. Je n'ai pas eu d'explication précise si ce n'est que l'ancien adminsys a reçu une formation vmware, qu'il est plus aisé de configurer un vlan via vsphere, vcenter pour controler trois ESXi d'un coup et surtout, que ça fait mieux sur les plaquettes. Ayant une forte expérience de Xen, j'étais déçu mais je ne me vois pas revenir en arrière. Je vais etre ennuyer cependant pour controler l'état du raid. Je vous rejoins donc tous sur ce point. En comparaison, j'ai refusé un poste car l'infra migrait de Debian à Centos sans d'autre argument que saymieux, autant là l'utilisation de vmware n'avait qu'un impact minime. Concernant les SSD, mon questionnement était raid1 vs réplication postgresql. J'avais peur que le raid1 ne fasse mourrir prématurément les SSD. Vu que l'un d'entre nous le fait au moins (laurent) je vais donc les mettre en raid, ce qui est selon moi plus sécurisant. Ce sont les disques fournis avec les R710, à plus de 2000 euros les 140G, j'espère que la qualité est au rendez vous. Pour la redondance c'est en réflexion (la production a déjà un serveur similaire et celui là vient en renforcement). Pas d'objections pour la vm d'admin dédié et le fw standalone je suppose donc que c'est la bonne solution. Bonne journée, c'est vendredi ! Sébastien.
Le 13/04/2012 08:28, seb astien a écrit :
Bonjour,
Je vais etre ennuyer cependant pour controler l'état du raid.
Pourquoi ? Ici que ça soit sur les serveurs ou sur les baies de disques j'ai des sondes qui vérifie l’état du raid. (L'un en Esx(i), l'autre directement intégré dans le "software" de la baie. Tristan.
Salut, Le 13 avril 2012 09:24, Tristan Larouanne <larouanne@idm.fr> a écrit :
Le 13/04/2012 08:28, seb astien a écrit :
Bonjour,
Je vais etre ennuyer cependant pour controler l'état du raid.
Pourquoi ? Ici que ça soit sur les serveurs ou sur les baies de disques j'ai des sondes qui vérifie l’état du raid. (L'un en Esx(i), l'autre directement intégré dans le "software" de la baie.
Si tu as des liens cela m'intéresse pour le check nagios depuis l'esxi, à priori ça serait du controleur PERC standard
Le 13/04/2012 13:28, seb astien a écrit :
Salut,
Le 13 avril 2012 09:24, Tristan Larouanne <larouanne@idm.fr <mailto:larouanne@idm.fr>> a écrit :
Le 13/04/2012 08:28, seb astien a écrit :
Bonjour,
Je vais etre ennuyer cependant pour controler l'état du raid.
Pourquoi ? Ici que ça soit sur les serveurs ou sur les baies de disques j'ai des sondes qui vérifie l'état du raid. (L'un en Esx(i), l'autre directement intégré dans le "software" de la baie.
Si tu as des liens cela m'intéresse pour le check nagios depuis l'esxi, à priori ça serait du controleur PERC standard
http://www.claudiokuenzler.com/nagios-plugins/check_esxi_hardware.php (qui fonctionne tres bien au moins pour le raid sur mes serveur Dell.) J'ai du rajouter un compte pour ça (pour pas avoir le root dans la conf nagios) manuelement sur chaque esx(i). Vcenter ne le permettant pas.
On Fri, Apr 13, 2012 at 08:28:04AM +0200, seb astien wrote:
Concernant les SSD, mon questionnement était raid1 vs réplication postgresql. J'avais peur que le raid1 ne fasse mourrir prématurément les SSD. Vu que l'un d'entre nous le fait au moins (laurent) je vais donc les mettre en raid, ce qui est selon moi plus sécurisant. Ce sont les disques fournis avec les R710, à plus de 2000 euros les 140G, j'espère que la qualité est au rendez vous.
Pour la redondance c'est en réflexion (la production a déjà un serveur similaire et celui là vient en renforcement).
Bonjour, J'ai fait le choix suivant: - Acheter 2 serveurs (actuellement des blades HP qui seront remplacées par 2 x R510 (Dell) courant de semaine prochaine). - Ne prendre que 2 disques de la plus petite capacité dispo (disques mécaniques livrés avec le serveur). - Acheter des SSD dans le commerce pour 5 à 10 fois moins cher (le R510 (Dell) en chassis 12 disques 3.5" a l'avantage de disposer d'une cage interne permettant de disposer 2 disques 2.5"). - Utiliser DRBD/Heartbeat. - La machine qui est primaire pour PostgreSQL est secondaire pour Redis/Memcache (et vice versa). L'"inconvénient" est de devoir gérer le SAV (le cas échéant) des SSD en dehors du circuit du constructeur du serveur. Cet inconvénient est bien mineur, et tu peux (eu égard au prix des SSD chez les grossistes) d'en acheter 1 ou 2 en plus au cas où... 36-15 ma vie: Je n'ai, pour le moment, pas remplacé de SSD suite à une panne. Mon experience sur des SSD dans des serveurs reste toutefois assez limitée (quelques VM, base essbase, postgresql, mysql.
Le 13 avril 2012 09:34, Laurent CARON <lcaron@unix-scripts.info> a écrit :
J'ai fait le choix suivant: - Acheter 2 serveurs (actuellement des blades HP qui seront remplacées par 2 x R510 (Dell) courant de semaine prochaine). - Ne prendre que 2 disques de la plus petite capacité dispo (disques mécaniques livrés avec le serveur).
Hello, (je ne bosse pas chez Dell), Tu ne pars pas sur du R720 (avec les nouveaux CPU E7 et RAM @1600 MHz sans penalty suivant les configs... donc config single socket équivalente à un dual socket R710 pour moins cher est possible) pour une question de coût j'imagine? Ils ont maintenant deux slots SD intégrés, comme il y avait sur le R810 (mais pas le R710), ce qui offre une redondance au niveau de l'installation d'ESXi (ou tout autre hyperviseur intégrable) et laisse tous les disques internes faire ce qu'ils ont à faire. Et puisque tu es dans le stockage local, regarde aussi la densité disque des R720 et R720XD... jusqu'à 26 x 2,5" ou 12 x 3,5" + 2 x 2,5" pour la version XD. Un peu plus "future proof"? Cordialement, -- Marien
On Fri, Apr 13, 2012 at 11:16:14AM +0200, Marien LEBRETON wrote:
Hello,
(je ne bosse pas chez Dell),
Tu ne pars pas sur du R720 (avec les nouveaux CPU E7 et RAM @1600 MHz sans penalty suivant les configs... donc config single socket équivalente à un dual socket R710 pour moins cher est possible) pour une question de coût j'imagine?
Le R720 dispose, comme le R510 que j'ai choisi, de 2 socket CPU. Le stockage interne n'est pas un critère dans mon cas (bien qu'il soit possible de placer 12x3.5" dans un R510). La consommation est à prendre en compte (nous sommes limités en consommation électrique *et* en dégagement thermique). J'ai donc opté pour un R510 avec des Xeon L ayant un TDP de 40W (chacun) contre 60W (minimum) pour des Xeon E5 (je ne parle pas des E7). Je réserve les R810 comme hôtes de virtualisation (KVM). Les 40 coeurs et 256G de RAM offrant une bonne densité dans ce cas.
Ils ont maintenant deux slots SD intégrés, comme il y avait sur le R810 (mais pas le R710), ce qui offre une redondance au niveau de l'installation d'ESXi (ou tout autre hyperviseur intégrable) et laisse tous les disques internes faire ce qu'ils ont à faire. Et puisque tu es dans le stockage local, regarde aussi la densité disque des R720 et R720XD... jusqu'à 26 x 2,5" ou 12 x 3,5" + 2 x 2,5" pour la version XD. Un peu plus "future proof"?
Tant qu'à être "future proof" autant déporter le stockage (afin de ne pas devoir remplacer tous tes disques à chaque fois que tu souhaite faire évoluer la capacité de tes machines). Le coût n'est alors certes plus le même...
Bonjour, On Fri, Apr 13, 2012 at 8:28 AM, seb astien <krionux@gmail.com> wrote:
Concernant les SSD, mon questionnement était raid1 vs réplication postgresql. J'avais peur que le raid1 ne fasse mourrir prématurément les SSD. Vu que l'un d'entre nous le fait au moins (laurent) je vais donc les mettre en raid, ce qui est selon moi plus sécurisant. Ce sont les disques fournis avec les R710, à plus de 2000 euros les 140G, j'espère que la qualité est au rendez vous.
Je trouve un peu "overkill" de mettre la totalité de la base sur les SSD. Si ta base génère tant d'I/O que ça, il y a peut être des optimisations à faire au niveau du modèle de données et des requêtes. Du coup je garderais les SSD pour stocker les tables les plus fréquemment utilisée et les journaux de transaction (si leur écriture est synchrone dans Postgre?). Oracle offre la possibilité d'utiliser des SSD pour stocker un cache de second niveau ("Flash Cache"), je ne sais pas si Postgre offre un système similaire, mais si c'est le cas, c'est clairement un truc à mettre en place. Et si il te reste de la place sur les SSD, tu peux également y placer les fichiers d'échange des différentes VM.
Pas d'objections pour la vm d'admin dédié et le fw standalone je suppose donc que c'est la bonne solution. Je ne suis pas super enthousiaste à l'idée de virtualiser les FW mais ce n'est pas vraiment mon domaine donc je passe..
Bonne journée, c'est vendredi ! Bon Trolldi!
-- Benoit
On Thu, Apr 12, 2012 at 03:49:32PM +0200, Gregory Duchatelet wrote:
d'après mon experience, le SSD moyen et bas de gamme n'est pas terrible niveau perf et fiabilité. Un hdparm donne de meilleure perf sur un RAID10 6x disques SAS @15krpm, qui sera pourtant moins cher pour plus de capa. Le gain en conso est minime, j'ai été surpris et déçu...
Faut taper dans le haut de gamme, voir Fusion IO, pour avoir un réel gain de perf (et pas des moindres d'après ce qu'on peut lire ! )
Bonjour, Nous avons testé le passage disques SAS 15k (RAID 1) à des SSD intel X25E (toujours en RAID1) avec des gains significatifs selon les applications. - PostgreSQL: Certaines requètes (certes, il serait plus intelligent d'optimiser la DB que d'investir dans des SSD...) Division du temps d'execution de certaines requètes par 3 à 4 - Hyperion / Essbase: Le temps de calcul a été divisé par 3 (SSD intel de 250Go) N'ayant pas de besoins démentiels de capa sur ces 2 applis, des SSD de 64Go/250Go suffisent pour le moment. Le coût est modeste (si tu n'a pas besoin de 10To de SSD) et les perfs au rendez-vous.
Ne connaissant pas j'ai posé la question à un ex-collègue : que du bon...même mieux en xen, alors comparé à Vmware... Le 12 avril 2012 16:41, Laurent CARON <lcaron@unix-scripts.info> a écrit :
On Thu, Apr 12, 2012 at 04:29:04PM +0200, Sébastien Mureau wrote:
Ont vois de plus en plus de personnes utiliser ESXI, je trouve cela dommage.
Xen à tres bonne réputation en production,ont l'utilise d'ailleurs beaucoup, alors que celui de Vmware juste un peu (installé par un ancien admin)
Quid de KVM ?
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On est totalement hors-sujet là :-) Personnellement, j'ai préféré Xen à KVM sur un gros projet en cours car Xen me semble quand même beaucoup plus mature et surtout stable ! C'est dommage, parce que KVM dépôte bien en terme de perfs ! Le 12 avril 2012 17:19, Sébastien Mureau <sebastien.mureau@gmail.com> a écrit :
Ne connaissant pas j'ai posé la question à un ex-collègue : que du bon...même mieux en xen, alors comparé à Vmware...
Le 12 avril 2012 16:41, Laurent CARON <lcaron@unix-scripts.info> a écrit :
On Thu, Apr 12, 2012 at 04:29:04PM +0200, Sébastien Mureau wrote:
Ont vois de plus en plus de personnes utiliser ESXI, je trouve cela dommage.
Xen à tres bonne réputation en production,ont l'utilise d'ailleurs beaucoup, alors que celui de Vmware juste un peu (installé par un ancien admin)
Quid de KVM ?
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Ludovic Cartier
Le 12 avr. 2012 à 17:21, Ludovic Cartier a écrit :
On est totalement hors-sujet là :-)
Personnellement, j'ai préféré Xen à KVM sur un gros projet en cours car Xen me semble quand même beaucoup plus mature et surtout stable ! C'est dommage, parce que KVM dépôte bien en terme de perfs !
Oui, enfin cela a beau être hors-sujet, cela reste super intéressant ! Je m'apprête à mettre des KVM en prod. Tu as constaté des problèmes particuliers sur KVM ? Merci.
Bonjour, T'as intérêt d'utiliser les virtios sur KVM, sinon les perfs vont faire mal... D'un point de vue de réseau PUR, KVM est *tres* mauvais par rapport à tous les autres hyperviseurs. Je parle bien d'un point de vue réseau, on n'a pas benché le reste. En fait, Je bosse dans un boite qui édite un LB qui a la particularité de tourner sur TOUS les hyperiseurs, on s'est donc attelé à connaître l'impact de la couche hyperviseur sur nos LBs. Le résultat parle de lui même: sur les sessions courtes, vsphere et hyperv (oui, oui, mais vsphere reste en tête) sont loin devant. Pour les sessions longues, ça se tasse et l'impact de l'hyperviseur devient négligeable pour hyperv et vsphere (moins de 5% de perte de perf). Nous n'avions pas testé les IOs disques, puisqu'un LB ne s'n sert pas :) Nous avions testé la vCPU pure (à travers la generation de clefs SSL) et là, pas trop de différences non plus, même si vsphere reste en tête, mais de peu. Tout celà fera l'objet d'un article sur un blog bientôt. a+ Baptiste
On 13/04/2012 07:05, Baptiste wrote:
Bonjour,
T'as intérêt d'utiliser les virtios sur KVM, sinon les perfs vont faire mal... D'un point de vue de réseau PUR, KVM est *tres* mauvais par rapport à tous les autres hyperviseurs.
Je parle bien d'un point de vue réseau, on n'a pas benché le reste. En fait, Je bosse dans un boite qui édite un LB qui a la particularité de tourner sur TOUS les hyperiseurs, on s'est donc attelé à connaître l'impact de la couche hyperviseur sur nos LBs. Le résultat parle de lui même: sur les sessions courtes, vsphere et hyperv (oui, oui, mais vsphere reste en tête) sont loin devant. Pour les sessions longues, ça se tasse et l'impact de l'hyperviseur devient négligeable pour hyperv et vsphere (moins de 5% de perte de perf).
Nous n'avions pas testé les IOs disques, puisqu'un LB ne s'n sert pas :) Nous avions testé la vCPU pure (à travers la generation de clefs SSL) et là, pas trop de différences non plus, même si vsphere reste en tête, mais de peu.
Tout celà fera l'objet d'un article sur un blog bientôt.
a+
Baptiste _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut, marrant ça, j'utilise KVM depuis 2008, les perfs se sont plutôt bien améliorées, effectivement virtio oblige. Côté perf réseau, aucuns soucis, j'ai une palanquée de firewall qui tournent sous kvm, de portails captifs, etc Les meilleures perfs sont rencontrées avec les noyaux les plus récents (3.x), et les derniers qemu-kvm (1.x). Pour les perfs réseaux: modprobe vhost_net avant de démarrer ton invité. Maintenant, j'utilise aussi LXC depuis un an et demi, en production. ça utilise les cgroup et la couche réseau est virtualisée, les perfs sont natives. A+ -- Jean-Philippe Menil - Pôle réseau Service IRTS DSI Université de Nantes jean-philippe.menil@univ-nantes.fr Tel : 02.53.48.49.27 - Fax : 02.53.48.49.09
participants (12)
-
Baptiste -
Benoit Garcia -
Emmanuel Thierry -
Gaëtan FEREZ -
Gregory Duchatelet -
Jean-Philippe Menil -
Laurent CARON -
Ludovic Cartier -
Marien LEBRETON -
seb astien -
Sébastien Mureau -
Tristan Larouanne