Serveurs X86: faut-il virtualiser ou maintenir l'option de 'clusters?

A examiner certains témoignages d'entreprises ayant particulièrement bien avancé dans la virtualisation de leurs traitements informations, il se confirme souvent que la consolidation sur des serveurs de nouvelle génération peut être impressionnante.

Il n'est pas rare, en effet, de voir le nombre de serveurs divisé par 10! Et la consommation d'énergie peut s'inscrire dans cette même proportion. En théorie!.

Mais certains constatent qu'il faut se méfier des règles de trois un peu hâtives.

Car il n'est pas évident, pas facile d'anticiper les comportements des applications lorsqu'elles auront été « migrées » vers des machines virtuelles. L'une des questions clés étant: comment ces applications se comporteront en pleine charge? Ou, en posant la question plus exactement, les comportements sont-ils compatibles ? Si toutes les applications ont leur pointe d'activité au même moment, on prend des risques!

La phase de transition ou migration vers des machines virtuelles n'est pas le résultat d'un coup de baguette magique. C'est une phase qui nécessite un 're-engineering' de l'existant, une remise à plat générale, permettant d'examiner point par point les phases de consolidation, les maillons faibles éventuels - ceci en fonction des options ouvertes.

Certaines entreprises optent plutôt pour la consolidation de leurs bases de données en « sgbd d'entreprise » plutôt que de créer des machines virtuelles. L'une des raisons avancées est que l'installation d'un hyperviseur pour la virtualisation implique une pénalisation sur les performances à cause de l'overhead suscité par l'hyperviseur. Autre raison invoquée: le sgbd ainsi consolidé saura tout seul (sans besoin d'hyperviseur), tirer parti du 'multicoeur'.

Parfois, il ne s'agit pas d'une juxtaposition de petits projets mais de bases de données sous SQL Server qui se cumulent pour obtenir des dizaines de tera-octets.

Mais il est à noter que « virtualisation » et « clusterisation » ne sont pas incompatibles ! « Dans certains cas, ce peut être le « multi-coeur » qui remplace le « cluster ». Pas la virtualisation« , observe Emmanuel Besluau, de Duquesne Research.

Une autre tendance: l'hyperviseur ne coûte rien, il est gratuit pour la totalité de la migration sur les serveurs qui consolident et supportent les 'machines virtuelles'. Cela peut inciter à faire cette migration. Mais certaines questions ne doivent pas être éludées. Ainsi, en est-il de l'impact des systèmes multi-coeurs sur certaines applications. On constate en effet que certaines applications ne peuvent pas 'paralléliser'.

Il y a donc des cas de figure où il est préférable de restreindre le « multi-coeurs » et de privilégier le mono-coeur ou deux-coeurs tout au plus, afin de mieux gérer de gros volumes sur une application unique. sur une application unique. Or, ici, la virtualisation aide car elle segmente la machine en plusieurs partitions.

Là encore, s'agissant de gros volumes de données, la solution de configurations en « clusters » (ou grappes de serveurs) se justifie plutôt qu'une virtualisation à tout crin. Dans le cas de Renault F1 Team - client témoin de cette session en directe - c'est la constitution de 'clusters' qui a primé, par exemple. A vérifier si, dans ce cas, il ne s'agit pas de calcul parallèle, pour lequel le multicoeur est approprié.

Un autre point fait l'objet de débat et de questions diverses. Selon que l'on se place du point de vue du responsable « systèmes serveurs » ou du responsable du datacenter ou de l'hébergeur, les priorités diffèrent.

Celui qui raisonne en hébergeur ne voit que des Kwatts au mètre carrré. Donc, attention: la logique économique est appelée à changer.

La plupart de ces points seront abordés et des réponses seront données, autant que faire se peut, lors de la conférence Web en ligne qui débutera à 11h00 précises, ce mercredi 23 septembre. Pour toutes précisions et inscription, cliquer ici.