Ce n'est pas parce que vous pouvez…

Je vois ce concept apparaître en permanence dans les discussions autour de la virtualisation. Il s’agit d’un concept plus large et plus général, mais la virtualisation est la “nouvelle technologie en vogue” à laquelle sont confrontées de nombreuses organisations informatiques et semble être le domaine où l’on observe actuellement le plus fréquemment les problèmes du type “ce n’est pas parce que vous pouvez que vous devriez” montrer leur vilain visage. Comme pour tout en informatique, il est essentiel que toutes les décisions techniques soient replacées dans un contexte métier afin que nous comprenions pourquoi nous choisissons de faire ce que nous faisons et que nous ne tentions pas de prendre nos décisions aveuglément en nous fondant sur des méthodologies de déploiement populaires ou, pire encore, sur des mythes.

La virtualisation elle-même, je dois le souligner, devrait selon moi être une décision par défaut aujourd’hui pour ceux qui travaillent dans le domaine de l’informatique x64, les systèmes n’étant déployés sans virtualisation que lorsqu’une nécessité claire et évidente existe, telle que des besoins matériels spécifiques, des applications sensibles à la latence, etc. En l’absence de tout besoin spécifique, la virtualisation peut être mise en œuvre gratuitement chez de nombreux fournisseurs et offre de nombreux avantages, tant aujourd’hui que pour pérenniser l’environnement.

Cela étant dit, ce que je vois souvent aujourd’hui, ce sont des entreprises qui déploient la virtualisation non pas comme une bonne pratique mais comme une panacée à tous les problèmes informatiques perçus. Ce qu’elle n’est certainement pas. La virtualisation est un outil très important à avoir dans la boîte à outils informatique et un outil auquel nous aurons très souvent recours, mais elle ne résout pas tous les problèmes et doit être traitée comme tout autre outil que nous possédons et utilisée uniquement lorsque c’est approprié.

Je vois plusieurs choses revenir lorsque les discussions sur la virtualisation sont abordées comme sujet. De nombreuses entreprises se tournent aujourd’hui vers la virtualisation non pas parce qu’elles ont identifié un besoin métier, mais parce que c’est le sujet actuellement à la mode et que les gens estiment que s’ils ne mettent pas en œuvre la virtualisation, ils seront d’une manière ou d’une autre laissés pour compte ou passeront à côté de quelque fonctionnalité mythique. C’est globalement positif car cela accroît l’adoption de la virtualisation, mais c’est négatif car de bons processus de décision informatique et métier sont court-circuités. Ce qui se produit souvent, c’est que, dans la vague de l’engouement pour la virtualisation, les services informatiques estiment qu’ils doivent non seulement mettre en œuvre la virtualisation elle-même, mais le faire de manières qui peuvent ne pas être appropriées pour leur entreprise.

Il y a quatre choses que je vois souvent associées à la virtualisation, souvent acceptées comme des exigences de la virtualisation, qu’elles aient ou non du sens dans un environnement métier donné. Il s’agit de la consolidation des serveurs, des serveurs lames, du stockage SAN et de la haute disponibilité ou bascule à chaud.

La consolidation est si souvent vantée comme l’avantage de la virtualisation que je pense que la plupart des services informatiques oublient qu’il existe d’autres raisons importantes de la mettre en œuvre. De toute évidence, la consolidation est un avantage considérable pour presque tous les déploiements (les résultats peuvent varier, bien entendu) et peut presque toujours être obtenue simplement par une meilleure utilisation des ressources existantes. Il est assez rare qu’une entreprise exploitant plus d’un seul serveur physique ne puisse pas réaliser une certaine économie grâce à une consolidation limitée, et il n’est pas rare de voir des empreintes de centres de données réduites de façon drastique dans les organisations de plus grande taille.

Dans les cas extrêmes, cependant, il n’est pas nécessaire d’abandonner les projets de virtualisation simplement parce que la consolidation s’avère hors de question. Ces cas existent pour les entreprises dotées de systèmes à forte utilisation et disposant de peu de budget pour un investissement préalable de consolidation. Mais ces structures peuvent tout de même virtualiser les systèmes “sur place”, un pour un, afin de tirer dès aujourd’hui d’autres avantages de la virtualisation et envisager de consolider lorsqu’il faudra remplacer le matériel demain ou lorsque des serveurs plus grands et plus puissants deviendront plus rentables à l’avenir. Il est important de ne pas écarter la virtualisation simplement parce que son avantage le plus vanté peut ne pas s’appliquer actuellement à votre environnement.

Les serveurs lames sont souvent considérés comme le choix pour les environnements de virtualisation. Les lames peuvent mieux se comporter dans un environnement de virtualisation standard qu’avec des charges de travail informatiques plus traditionnelles, mais cela est à la fois hautement contestable et ne constitue pas nécessairement une donnée pertinente. Le fait d’être un bon scénario pour les lames elles-mêmes n’en fait pas un bon scénario pour une entreprise. Ce n’est pas parce que les lames se comportent mieux que la normale lorsqu’elles sont utilisées de cette manière que cela implique qu’elles se comportent mieux que les serveurs traditionnels – seulement qu’elles ont potentiellement réduit l’écart.

Les lames doivent être évaluées selon les mêmes critères rigoureux lors de la virtualisation que lorsqu’on ne virtualise pas et, très souvent, elles continueront de ne pas offrir la valeur métier à long terme nécessaire pour les choisir plutôt que des alternatives plus flexibles. Les lames restent loin d’être une nécessité pour la virtualisation et constituent souvent, à mon avis, un très mauvais choix.

L’une des idées fausses les plus répandues est qu’en passant à la virtualisation, on doit également passer à du stockage partagé tel qu’un SAN. Cette mentalité est la réaction évidente au désir d’obtenir également d’autres avantages de la virtualisation qui, s’ils ne nécessitent pas de SAN, en bénéficient grandement. La capacité à répartir la charge ou à basculer entre les systèmes est largement facilitée par la présence d’un stockage partagé en arrière-plan. C’est un mythe que cela soit une exigence absolue, mais le stockage local répliqué apporte ses propres complexités et limitations.

Mais le stockage partagé est loin d’être une nécessité de la virtualisation elle-même et, comme tout, doit être évalué pour ce qu’il est. Si la virtualisation a du sens pour votre environnement mais que vous n’avez besoin d’aucune fonctionnalité nécessitant un SAN, alors virtualisez sans stockage partagé. Il existe de nombreux cas où une virtualisation reposant sur du stockage local constitue un scénario de déploiement idéal. Il n’y a aucune raison d’écarter cette approche sans d’abord l’avoir sérieusement envisagée.

La dernière grande fonctionnalité supposée nécessaire de la virtualisation est la haute disponibilité au niveau du système ou la bascule instantanée de votre système d’exploitation. Sans aucun doute, la haute disponibilité au niveau du système est un avantage phénoménal que nous apporte la virtualisation. Cependant, peu d’entreprises avaient besoin de haute disponibilité à ce niveau avant de mettre en œuvre la virtualisation et le prix de l’infrastructure et des logiciels nécessaires pour la réaliser avec la virtualisation est souvent si élevé qu’il la rend trop coûteuse pour être justifiée.

Les systèmes de haute disponibilité sont complexes et souvent excessifs. Il est très rare qu’un système métier nécessite une bascule transparente, même pour les systèmes les plus critiques, et les entreprises ayant cette exigence disposeraient presque certainement déjà de processus de bascule en place. Je vois des entreprises se tourner vers la haute disponibilité en permanence lorsqu’elles envisagent la virtualisation, simplement parce qu’un fournisseur a vu une occasion de survendre de façon spectaculaire les exigences initiales. Le coût de la haute disponibilité est rarement justifié par la perte potentielle de revenus liée à la réduction de temps d’arrêt associée. Avec une virtualisation sans haute disponibilité, le temps d’arrêt pour un matériel défaillant pourrait se mesurer en minutes si les sauvegardes sont bien gérées. Cela signifie que la haute disponibilité doit justifier son coût en éliminant potentiellement seulement quelques minutes de temps d’arrêt non planifié par an, moins tout risque supplémentaire assumé du fait de la complexité accrue du système. Même dans les plus grandes organisations, cela est rarement justifié à grande échelle et dans une entreprise de taille plus modérée, c’est carrément peu courant. Mais aujourd’hui, nous constatons que de nombreuses petites entreprises mettent en œuvre des systèmes de haute disponibilité à un coût extrême sur des systèmes qui pourraient aisément subir des pannes de plusieurs jours avec une perte financière minimale, simplement parce que les supports marketing ont fait la promotion de ce concept.

Comme tout, la virtualisation et toutes les possibilités qu’elle apporte doivent être évaluées individuellement dans le contexte de l’organisation qui les envisage. Si la fonctionnalité individuelle n’a pas de sens pour votre entreprise, ne supposez pas que vous devez acheter ou mettre en œuvre cette fonctionnalité. De nombreuses organisations virtualisent mais n’utilisent que quelques-unes, voire aucune, de ces fonctionnalités “supposées”. Ne considérez pas la virtualisation comme une boîte noire, examinez ses composants et évaluez-les comme vous évalueriez tout autre projet technologique.

Ce qui se produit souvent, c’est un effet boule de neige dans lequel une fonctionnalité, probablement la haute disponibilité, est supposée nécessaire sans qu’une évaluation métier adéquate soit réalisée. Ensuite, un système de stockage partagé, souvent supposé requis pour la haute disponibilité, est ajouté comme un autre coût présumé. Même si les fonctionnalités de haute disponibilité ne sont pas achetées, la décision d’utiliser un SAN peut déjà être prise et ne pas être réexaminée après que des modifications ont été apportées au plan. Il est très courant, d’après mon expérience, de trouver des projets de cette nature dans lesquels parfois plus de cinquante pour cent de la dépense totale du projet est consacrée à des produits dont l’acheteur est incapable de décrire ne serait-ce que la raison pour laquelle il les a achetés.

Ce concept ne s’arrête pas à la virtualisation. Étendez-le à tout ce que vous faites. Gardez l’informatique en perspective de l’entreprise et ne supposez pas qu’opter pour une technologie suppose automatiquement que vous deviez adopter d’autres technologies qui lui sont communément associées.