Infrastructure clusterisée vs. vmWare

[plaporte]

Bonjour à tous

Je suis ingénieur d'études dans une SSII, et je travaille sur une analyse comparative entre plusieurs architectures de déploiement

Je ne suis pas encore très familier avec les produits vmWare, à part les gratuits que j'ai pu tester à titre personnel.

Je me pose la problématique suivante :

J'ai vu passer pas mal de projets où, pour assurer une haute disponibilité, une tolérance aux pannes et une répartition de charge, des serveurs d'applications étaient dupliqués puis mis en cluster. Ceci se faisait au prix d'un paramétrage logiciel assez lourd.

Est-ce qu'il ne serait pas possible de remplacer chaque cluster de serveurs d'applications par un seul serveur hébergé dans une machine virtuelle à laquelle suffisamment de ressources sont associées (CPU, RAM, I/O) ?

Typiquement, si dans un cluster de 5 machines, chaque serveur est prévu pour accueillir 2.000 connexions à la seconde, est-ce qu'on peut remplacer ces serveurs par une seule machine virtuelle ? Est-il possible de dimensionner une telle vm pour qu'elle accueille, à elle seule, les 10.000 connexions prévues initialement ?

Si oui, ça veut dire que la problématique de répartition de charge est bouclée. Le produit vmWare vMotion serait-il adapté dans une telle configuration pour assurer la haute disponibilité et la tolérance aux pannes ?

Mon objectif est de déterminer si un passage à un tout-vmWare permettrait de s'affranchir des couts de déploiement et de paramétrage logiciel. Est-ce que vous avez déjà eu des expériences similaires ?

Par avance, merci pour vos réponses

P.Laporte

[FranckRookie · Accepted solution]

Bonjour P.,

Bienvenue sur les forums VMware.

La mise en cluster d'applications répond à deux problématiques distinctes: la haute disponibilité et la répartition de charge.

La haute disponibilité, ou tolérance de panne, consiste en général en la duplication d'une installation et le passage dans un mode dit Actif / Passif. En cas de panne de l'élément actif, le passif est activé et prends le relai pour assurer la continuité de service. Ce mode de protection peut tout à fait être pris en charge par les solutions VMware que sont High Availability et Fault Tolerance. Le choix de l'une ou de l'autre dépend de la sensibilité de l'application, de certaines contraintes techniques et des moyens disponibles. Tu n'as dans ce cas plus rien à faire au niveau de l'application. La fonction de redondance du système est entièrement assurée par la couche de virtualisation.

La répartition de charge répond à une problématique différente. Elle consiste à augmenter la puissance disponible pour une application en utilisant des ressources distribuées sur plusieurs machines. Et là, tu as en environnement virtuel les mêmes contraintes qu'en physique. Si ton application nécessite une ressource en quantité supérieure à ce que tu peux trouver dans une machine physique, aucun produit VMware ne saura agréger les ressources de plusieurs serveurs pour te présenter une "méta-machine" qui disposerait des ressources cumulées de plusieurs serveurs physiques.

Reprenons l'exemple de tes cinq serveurs accueillant chacun 2 000 connexions à la seconde. Supposons que ton facteur limitant soit le nombre de processeurs et qu'il te faille quatre processeurs par machine pour assurer ce nombre de sessions. Si tu ne peux avoir que des machines physiques disposant de quatre processeurs chacune, tu ne peux pas installer VMware sur cinq serveurs de ce type et créer une machine virtuelle qui disposerait de la totalité des vingt processeurs pour satisfaire à une demande de 10 000 connexions par seconde. Tu seras contraint à créer cinq machines virtuelles et constituer un cluster applicatif pour répondre à ton besoin. Dans ce cas, la virtualisation ne présenterait que peu d'intérêt.

Par contre, si tu souhaites remplacer une installation cluster existante constituée de serveurs physiques de faibles capacités, la mise en place d'un serveur plus puissant disposant des ressources nécessaires peut permettre de migrer ton infrastructure en un système plus simple, non "clusterisé". Mais cette évolution ne nécessite pas le passage en virtuel et reste conditionnée par la disponibilité d'une machine ayant les ressources suffisantes.

Une dernière remarque concernant la fonction VMotion. Elle permet de déplacer à chaud une machine virtuelle d'un serveur VMware ESX vers un autre. Elle est utilisée pour répartir la charge au sein d'un groupe de serveurs ESX ou bien pour évacuer des machines virtuelles d'un serveur physique sur lequel on souhaite intervenir. Elle n'est pas utilisée pour des fonctions de tolérance de panne.

Je te souhaite bon courage pour la suite de tes recherches.

A+

Franck

[plaporte]

Bonjour

Merci pour tes réponses, c'est très clair

Si j'ai bien compris, à partir du moment où un seul serveur physique peut répondre aux besoins de performance d'un système, alors VMware HA et FT peuvent remplacer un cluster applicatif.

Des qu'il y a une problématique de répartition de charge, par contre, ce n'est pas possible.

Une dernière question par rapport à FT :

Je pars du principe que j'ai une VM1 sur un serveur ESX1 qui est clonée en tant que VM2 sur l'ESX2.

D'après cette vidéo (http://www.youtube.com/watch?v=NCMMwGC0hD8), le maintient de la VM2 dans un état similaire à VM1 ne consomme que très peu de ressources entre ESX1 et ESX2.

Si je ne me trompe pas, il faut quand même que VMware FT mobilise la RAM et le CPU réservés à VM1 sur le serveur ESX2, au cas où VM1 tombe.

=> Les ressources réservées apparaissent donc comme consommées, non ?

Pierre

[FranckRookie]

Bonjour Pierre,

En effet, si tu peux caser ton application sur une seule machine, tu réponds à ton problème de répartition de charge. HA ou FT peuvent alors assurer la fonction de tolérance de panne. Attention néanmoins aux limites techniques de VMware cette fois ci.

Par exemple, tu ne peux pas avoir plus de huit CPU virtuels dans une VM (et encore, avec la licence Enterprise Plus, sinon c'est quatre maxi). Tu ne peux pas non plus activer le mode FT sur une machine virtuelle multiprocesseurs (pour l'instant...). Et là, c'est plutôt gênant dans ton cas! A moins que ton application ne supporte bien la coupure intempestive, tu peux alors utiliser HA. C'est pourquoi il ne faut pas totalement abandonner la solution cluster applicatif quand on passe en virtuel. Il y a toujours des cas particuliers où cette méthode reste la seule apte à répondre à tes contraintes. Et dans certains cas, il est nécessaire de maintenir une infrastructure physique, non virtualisée.

En ce qui concerne FT, la VM n'est pas totalement clonée sur le second ESX. Seules la mémoire et la pile d'opérations processeur sont dupliquées. Le disque virtuel reste commun aux deux machines. Le processeur et la mémoire sont réellement consommées sur le second ESX qui rejoue les mêmes entrées/sorties que sur la VM primaire. Les ressources transmises entre les deux hôtes dépendent bien sûr du fonctionnement de l'application, comme le montre bien la vidéo que tu indiques. Plus le serveur primaire gère de données, plus les ESX devront échanger de données de synchronisation. Il est de toute façon recommandé par VMware de dédier un lien gigabit entre les hôtes pour assurer cette fonction.

Une dernière remarque à l'ensemble des contributeurs du forum. Ce sujet est très intéressant et beaucoup d'entre nous seront ou ont été confrontés à ce type de situation. Certains ont une grande expérience des clusters applicatifs, certainement meilleure que la mienne. Il est dommage de ne disposer que d'un seul point de vue. Alors n'hésitez-pas à faire vos remarques ou vos corrections.

A+

Franck