Discussion :

[FlexFlex]

Bonsoir à tous,


Je suis employé par une petite pme : 4 serveurs linux et 2 serveurs windows server 2008R2 et 2012 .

Mon chef me demande de réaliser une étude comparative entre les différentes solutions principales d' hyperviseurs de type 1 du marché (virtualisation de serveurs)

- vSphere
- Hyper -V
- Xen Server

Les critères de comparaison sont : l'aspect économique ( prix des licences, support etc) , la fiabilité, la haute dispo, la migration à chaud , la capacité d'évolution,les performances des produits, la gestion des drivers, la compatibilité avec les OS.

Je vous serait très reconnaissant si vous pouviez éclairer ma lanterne sur le sujet.

PS : pourriez vous aussi m'expliquer s'il vous plait aussi les principales différences entre les éditions (standard, entreprise, etc)

merci d'avance

[chrtophe]

Je peux te donner mon avis :

- fiablilité : les 3 se valent je pense mais ceci est à pondérer par le fait que j n'ai utilisé que VMWare, et que j'en fait peu.

- Aspect économique : Xen server est gratuit (il y a peut-être des versions payantes),les produits VMWare sont chers (mais ESXi est gratuit, et puis tout est relatif, c'est cher pour un particulier, pour une entreprise ...), hyper-v, je ne sais pas

- support : Aucune idée du prix et du sérieux pour les 3 produits

- Migration à chaud : Je l'ai fait une fois sur VMWAre en réel mais pas depuis, pour les autres je ne pense pas que tu es de solution incorporé, par contre tu as des produits tiers. Si tu veux faire du P2V, jettes un oeil sur mon tuto la-dessus (lien dans ma signature)

Quand aux différentes versions standard, entreprises etc ..., je pense que c'est selon le nombre de CPUs, de VM dans l'hyperviseur etc .. mais je ne peux pas t'en dire plus.

Les produits VMWare me paraissent les plus compatibles avec tout OS. Mais sur les systèmes les plus utilisés, tu ne devrais pas rencontrer de problèmes.

Pour de la haute dispo, il te faut plutôt voir des produits spécialisés (j'en site quelques un dans mon tuto). Et voir sinon du coté de VMWare cloud.

[jlliagre]

- Migration à chaud : Je l'ai fait une fois sur VMWAre en réel mais pas depuis, pour les autres je ne pense pas que tu es de solution incorporé

vSphere, Hyper-V et XEN supportent nativement tous les trois la migration de VM à chaud.

[chrtophe]

Ok, Merci pour la correction jlliagre.

[Invité]

Salut,

voilà qui va sans doute t'aider

http://www.virtualizationmatrix.com/...l&free_based=1


Steph

[FlexFlex]

Merci à vous tous ça m'apporte des élements de réponse.
Si quelqu'un d'autres connaissances à partager , n'hésitez pas

Bon dimanche!

[Community Management]

Bonjour,
Tous les trois couvrent les fonctionnalités que tu recherches, mais pour une vraie comparaison, il faut coupler HyperV à SCVMM (System Center Virtual Machine Manager).
Côté licence, VMware est le plus cher, mais le plus stable et le plus fourni en termes de fonctionnalités et de performance.

[macslan]

Bonjour,
Tous les trois couvrent les fonctionnalités que tu recherches, mais pour une vraie comparaison, il faut coupler HyperV à SCVMM (System Center Virtual Machine Manager).
Côté licence, VMware est le plus cher, mais le plus stable et le plus fourni en termes de fonctionnalités et de performance.

Et pour l'édition des gold image avec Hyper-v

[Community Management]

Et pour l'édition des gold image avec Hyper-v

Chacun de ses hyperviseurs a son format propre de machine virtuelle et de disque virtuel qu'il peut éditer.

[chrtophe]

Chacun de ses hyperviseurs a son format propre de machine virtuelle et de disque virtuel qu'il peut éditer.

Pour le formât de VM, tu as l'OVF : Open Virtual machine Format :

https://fr.wikipedia.org/wiki/Open_V...Machine_Format

Par contre, à l'usage, je suis pas sûr que se soit exploitable pour le moment. Après, il y a des produits permettant de migrer d'un hyperviseur vers un autre.

Virtualbox par exemple permet l'utilisation d'image disque vmdk, d'images vhd. VMWare ouvre les fichiers .vhd. Pour les autres interopérabilités, à voir au cas par cas.

[Invité]

Côté licence, VMware est le plus cher, mais le plus stable et le plus fourni en termes de fonctionnalités et de performance.

Notamment dans les overlays, VMWare est en train de prendre une avance considérable avec NSX/VXLAN qui va s'imposer, je pense, comme le standard de fait pour la gestion des flux Est/Ouest (microsegmentation).

Steph

[sevyc64]

Pour ce qui de Hyper-V vs vmWare, concernant les versions autonomes (poste bureautique), pas les versions serveur que je ne connais pas, il y a une fonctionnalité qui est très bien dans Hyper-v, c'est la gestion dynamique de la ram. Il y aurait la même chose dans vmware workstation, ça serait nickel.

--> Lorsque tu as une vm, à qui tu as alloué par exemple 4Go de ram, si à un instant t elle n'a besoin que de 1,5Go, sous Hyper-v, à cet instant t elle ne consomme que les 1,5Go dans la ram de l'hote, tandis que sous vmware, 4go da ram sont malgré tout alloués dans la mémoire de l'hote. C'est très pratique quand on est limité en ram sur l'hote.

Par contre, sur les versions serveurs je sais pas comment ça se passe. Mais en général on fait en sorte qu'il y ait suffisamment de ram

Mais c'est le seul point que j'attribue à Hyper-V, ma préférence va aussi à vmWare.


Ip_Steph > Qu'appelle-tu overlay exactement ?

[chrtophe]

--> Lorsque tu as une vm, à qui tu as alloué par exemple 4Go de ram, si à un instant t elle n'a besoin que de 1,5Go, sous Hyper-v, à cet instant t elle ne consomme que les 1,5Go dans la ram de l'hote, tandis que sous vmware, 4go da ram sont malgré tout alloués dans la mémoire de l'hote. C'est très pratique quand on est limité en ram sur l'hote.

Intéressant cette fonction.

[Invité]

Ip_Steph > Qu'appelle-tu overlay exactement ?

Pas vraiment facile d'expliquer ce concept
Un overlay désigne une technique permettant de virtualiser des fonctions réseau.
Ca relève du SDN (Software Defined Network), ça n'a pas vraiment d'intérêt pour les PME/PMI. Enfin pour l'instant.
Pour les grosses infras à base de datacenters, la virtualisation, c'est très intéressant.

De façon générale, la virtualisation réseau "masque" la complexité des couches basses.

Je vais prendre l'exemple d'OpenVPN.
Quand tu montes un tunnel IPSec avec une machine distante sur Internet, tu passes par plusieurs gateways.
Mais quand tu es inséré dans le tunnel, et que tu fais un traceroute vers la machine distante, tu ne verras qu'un seul saut. D'un point de vue fonctionnel, OpenVPN est une forme d'overlay. Il a virtualisé la fonction réseaux qui permet à deux machines nomades sur Internet de causer de façon encryptée en utilisant des adresses RFC1918.
Et comme c'est virtualisé, c'est scriptable et automatisable. Donc facilement industrialisable, ce qui est crucial d'un point de vue run.
Si j'ai un serveur OpenVPN opérationnel et que mon business consiste à accueillir des nomades, j'ai juste à monter un script en mettant l'adresse IP publique du nomade en input pour créer l'accès en moins de deux.

J'ai déjà abordé le Software Defined Network, et la façon dont il va révolutionner la façon de construire et de maintenir de grosses infrastructures :

http://www.developpez.net/forums/d15...k/#post8183344

La machine est maintenant en marche...

NSX/VXLAN de VMWare répond à la problématique des flux dits "Est/Ouest" des datacenters.
Le principe consiste à utiliser un réseau de transit IP entre bare-metals pour transporter les flux L2 entre VM. Tout le traffic L2 est encapsulé dans des tunnels UDP. Les tunnels sont déclenchés à la demande par les serveurs ESX, ça s'appuie sur VTEP et sur l'IP Multicast. Chaque VTEP neighbor agit comme le port d'un switch avec ses fonctions usuelles de learning/ageing/flooding de MAC addresses.
Et pour continuer l'analogie avec OpenVPN, on peut dire que NSX/VXLAN est un overlay qui virtualise la fonction réseau qui permet à deux "VM nomades" de se voir sur le même câble mais en réalité séparées par une infra IP. Ainsi, un traceroute entre deux VM "connectées" via un VXLAN donnerait un seul saut. Finalement, la connaissance seule d'une adresse IP cible n'est plus suffisante pour connaitre l'emplacement physique du bare-metal qui l'embarque, c'est un pas supplémentaire dans la dématérialisation.

A grande échelle, je parle ici de milliers de VM disséminées sur plusieurs datacenters, cet overlay devient objet de design pour les architectes. En particulier, ça a pour impact de descendre le routage dans les couches distribution/accès. Ca libère donc énormément de bande passante au niveau des coeurs de réseaux puisqu'on n'a plus besoin de tirer les vlans jusqu'à cet endroit. D'autre part, l'introduction de VXLAN permet de contourner la limitation classique des 4094 VLANs. Le VLAN est en effet codé sur 12 bits dans l'en-tête 802.1q, alors que les VNI (VXLAN Network Identifier) le sont sur 24 bits, ce qui permet en théorie de tirer plus de 16 millions de VLANs Est/Ouest.

Les concurrents de VXLAN utilisent des tunnels IP de type GRE (NVGRE chez Microsoft par exemple). Mais ça n'est pas aussi abouti que VTEP/VXLAN.
Tout d'abord, les paquets NVGRE intègrent un champ flow ID théoriquement utilisable pour modifier le "flow-based entropy" (policies, QoS, access-lists, etc). Mais ça impose des pré-requis dans le transit des paquets parce qu'il faut des équipements capables de switcher/router très vite tout en inspectant le contenu des paquets NVGRE.
D'autre part, NVGRE ne standardise pas la méthode permettant aux extrémités des tunnels de se découvrir mutuellement et de façon dynamique, comme c'est le cas avec VTEP pour la solution VXLAN (fonctionnellement, VTEP est similaire à IGMP dans le monde IP Multicast). NVGRE part de l'hypothèse que les tunnels doivent être provisionnés à l'avance par les archis réseau alors que VTEP/VXLAN crée les tunnels de façon réellement dynamique.

Voilà les différences essentielles qui annoncent la pénétration rapide de VXLAN dans les datacenters...

Pour en savoir plus,

https://tools.ietf.org/html/rfc7348 (VXLAN)
https://tools.ietf.org/html/draft-sr...ation-nvgre-00 (Draft NVGRE)

Steph

[sevyc64]

Ok, je vois grosso-modo ce que ça fait, même si je n'ai pas tout compris Ce domaine dépasse mes compétences réseau et probablement pour longtemps.

Je l’interprète, même si c'est probablement pas très juste, comme une sorte de VLAN virtuel sur un réseau "physique" virtuel qui relierait les esxi entre-eux et permettant de s'affranchir des contraintes liées à la structure du vrai réseau physique.

J'ai déjà vu un truc du genre sur une petite structure (2 hôtes) ou, pour éviter de saturer le routeur avec le trafic inter-vlan des serveurs virtuels, les 2 hôtes étaient directement reliés entre eux par une seconde carte réseau et un lien optique. Pour le détail de la configuration ensuite, je sais pas comment c'était fait au sein des esxi/vm.

[Invité]

Je l’interprète, même si c'est probablement pas très juste, comme une sorte de VLAN virtuel sur un réseau "physique" virtuel qui relierait les esxi entre-eux et permettant de s'affranchir des contraintes liées à la structure du vrai réseau physique.

Oui, c'est à peu près ça.
On transporte du L2 entre VM en l'encapsulant dans un réseau IP.

Steph

[Cafeinoman]

Pour répondre à la question de base, je bosse dans le même cadre que toi, avec à peu près l'équivalent en machines. On est passé sous Xen l'année dernière pour un budget ridicule, pas de soucis de fiabilité, migration aisée et des perfs au top au vue des besoins. Pour le support il y a des presta très compétents dont je peux te filer les coordonnes si tu veux.

[macslan]

Chacun de ses hyperviseurs a son format propre de machine virtuelle et de disque virtuel qu'il peut éditer.

Je parle de créer et d'éditer une image gold/master pour hyper-v sans faire un sysprep forcement à chaque modification pour créer une collection de bureaux