Œufs virtuels et paniers

En discutant avec les professionnels de l'informatique des petites entreprises, l'un des facteurs clés de réticence à déployer la virtualisation provient de ce que l'on décrit comme « ne pas mettre tous ses œufs dans le même panier ».

Je comprends d'où vient cette préoccupation. La virtualisation permet de contenir de nombreux systèmes d'exploitation invités dans un seul système physique qui, en cas de panne matérielle, provoque la défaillance simultanée de tous les systèmes invités qui y résident, tous d'un coup. Cela paraît mauvais, mais ce n'est peut-être pas aussi grave que nous le présumerions au premier abord.

L'idée derrière l'expression des œufs et des paniers est que nous ne devrions pas mettre en péril toutes nos ressources en même temps. Cela s'applique généralement à l'investissement, en encourageant les investisseurs à se diversifier et à investir dans de nombreuses entreprises et types de titres différents, comme les obligations, les actions, les fonds et les matières premières. Dans le cas des œufs (ou de l'argent), nous parlons d'un bien interchangeable. Un œuf en vaut un autre. Un ensemble d'œufs est naturellement redondant.

Si nous avons une douzaine d'œufs et que nous en cassons six, nous pouvons toujours faire une omelette, peut-être plus petite, mais nous pouvons quand même manger. Manger une omelette plus petite est susceptible d'être presque aussi satisfaisant qu'une plus grande – nous ne resterons affamés dans aucun des cas. Répartir nos œufs déjà redondants dans plusieurs paniers nous permet de limiter nos risques. Certes, porter deux paniers signifie que nous avons moins de temps à consacrer à chacun, ce qui augmente le risque de perdre quelques œufs mais réduit les chances de les perdre tous. Dans le cas des œufs, une proposition fort sage en effet. De même, une manière intelligente de préparer votre retraite.

Cette théorie, parce qu'elle est répétée comme un dicton sans analyse rigoureuse ni compréhension appropriée, est ensuite appliquée à des domaines sans rapport, tels que la virtualisation des serveurs. Les serveurs, cependant, ne sont pas comme des œufs. Les serveurs, surtout dans les petites entreprises, sont rarement des biens interchangeables où en avoir six qui fonctionnent, au lieu des douze habituels, suffit. En général, chaque serveur joue un rôle unique et tous sont relativement critiques pour le fonctionnement de l'entreprise. Si un serveur n'est pas critique, il est peu probable qu'il puisse justifier le coût de son acquisition et de sa maintenance en premier lieu, et il n'existerait donc probablement pas. Lorsque les serveurs sont interchangeables, comme dans une grande ferme web sans état ou une grappe de calcul, ils sont configurés ainsi comme moyen d'étendre la capacité au-delà des limites d'une seule machine physique et sortent donc du cadre de cette discussion.

Les services informatiques d'une entreprise constituent généralement, du moins dans une certaine mesure, une « dépendance en chaîne ». C'est-à-dire qu'ils sont interdépendants et que la perte d'un seul service peut avoir un impact sur d'autres services, soit parce qu'ils sont techniquement interdépendants (comme une application métier dépendante d'une base de données), soit parce qu'ils sont interdépendants au niveau du flux de travail (comme un employé de bureau ayant besoin que le serveur de fichiers fonctionne afin de fournir un fichier qu'il doit modifier avec des informations provenant d'un courriel tout en discutant des changements par téléphone ou messagerie instantanée). Dans ces cas, la perte d'un seul service clé tel que la messagerie, l'authentification réseau ou les services de fichiers peut entraîner une perte disproportionnée de capacité de travail. S'il y a dix services clés et qu'un seul tombe en panne, la productivité de l'entreprise du point de vue des services informatiques chute probablement de bien plus de dix pour cent, frôlant peut-être les cent pour cent dans les cas extrêmes. Ce n'est pas toujours vrai ; dans certains cas particuliers, les employés parviennent à « contourner » efficacement un service perdu, mais c'est très peu courant. Même si les gens peuvent continuer à travailler, ils sont probablement bien moins productifs que d'habitude.

Lorsqu'il s'agit de serveurs physiques, chaque serveur représente son propre point de défaillance. Ainsi, si nous avons dix serveurs, nous avons dix fois plus de risques de panne que si nous n'avions qu'un seul de ces mêmes serveurs. Chaque serveur que nous ajoutons apporte avec lui son propre risque. Si chaque panne a un facteur d'interruption de 2,5 – c'est-à-dire un impact financier sur l'entreprise correspondant à vingt-cinq pour cent du chiffre d'affaires pour, disons, une journée, alors notre impact moyen total sur une décennie équivaut à deux interruptions et demie de la totalité du site. J'utilise ici le concept de facteurs et de moyennes pour simplifier ; déterminer la durée d'une interruption moyenne ou l'impact d'une interruption moyenne n'est pas nécessaire, car nous n'avons besoin de déterminer que l'impact relatif dans ce cas pour comparer les scénarios. C'est simplement un moyen de comparer l'impact financier cumulé des interruptions d'un type d'événement par rapport à un autre sans avoir besoin de chiffres précis – cela ne vous aide pas à déterminer quel devrait être votre budget, juste la fiabilité relative.

Avec la virtualisation, nous avons l'évidente capacité de consolider. Dans cet exemple, nous supposerons que nous pouvons regrouper la totalité de ces dix serveurs existants en un seul serveur. Lorsque nous faisons cela, nous déclenchons souvent la réaction « tous nos œufs dans le même panier ». Mais si nous réalisons une analyse de risque, nous verrons qu'il ne s'agit généralement que de peur et d'incertitude, et non d'un risque étayé par les mathématiques. Si nous supposons les mêmes risques que dans l'exemple ci-dessus, notre serveur unique subira, en moyenne, une seule interruption totale du site, une fois par décennie.

Comparez cela au premier exemple qui causait des dommages équivalant à deux interruptions et demie de la totalité du site – le risque de la solution virtualisée et consolidée ne représente que quarante pour cent de celui de la solution traditionnelle.

Gardez maintenant à l'esprit que cela repose sur l'hypothèse selon laquelle perdre certains services entraîne une perte financière supérieure à la stricte valeur du service perdu, ce qui est presque toujours le cas. Même si le service perdu ne représente pas plus que la perte d'un service individuel, nous sommes seulement à l'équilibre et n'avons pas à nous inquiéter. Dans de rares cas, l'impact de la perte d'un seul système peut être inférieur à sa « part du gâteau », normalement parce que les gens sont flexibles et peuvent contourner le système défaillant – comme lorsque la messagerie instantanée tombe en panne et que les gens passent simplement à l'utilisation du courriel jusqu'à ce que la messagerie instantanée soit rétablie, mais ces cas sont rares et se limitent normalement à quelques systèmes parmi un grand nombre, la majorité des systèmes, disons l'ERP, le CRM et la messagerie, ayant des impacts disproportionnellement importants en cas d'interruption.

Ce que nous constatons ici, c'est que dans des circonstances normales, déplacer dix services de dix serveurs vers dix services sur un seul serveur abaissera généralement notre risque, au lieu de l'augmenter – en contradiction directe avec la théorie des « œufs dans le même panier ». Et ceci uniquement du point de vue des pannes matérielles. La consolidation offre cependant plusieurs autres facteurs de fiabilité importants qui peuvent avoir un impact significatif sur notre étude de cas.

Avec la consolidation, nous réduisons la quantité de matériel qui doit être surveillée et gérée par le service informatique. Moins de serveurs signifie que davantage de temps et d'attention peuvent être consacrés à ceux qui restent. Plus d'attention signifie de meilleures chances de détecter les problèmes tôt et davantage d'occasions de garder des pièces sous la main. Une meilleure surveillance et une meilleure maintenance conduisent à une meilleure fiabilité.

Le facteur le plus important, cependant, avec la consolidation, est peut-être qu'elle génère des économies de coûts substantielles et que cela, si on l'aborde correctement, peut offrir des occasions d'améliorer la fiabilité. Avec la réduction spectaculaire du coût total des serveurs, il peut être tentant de continuer à maintenir des budgets serrés et de tenter de tirer parti des économies de coûts de manière purement directe. C'est compréhensible et, pour certaines entreprises, ce peut être la bonne approche. Mais ce n'est pas l'approche que je recommanderais lorsque l'on lutte contre la notion des œufs et des paniers.

Au contraire, en adoptant une approche plus modérée, qui conserve des économies de coûts substantielles tout en dépensant néanmoins davantage, relativement parlant, sur un seul serveur, vous pouvez acquérir un serveur haut de gamme (comprendre : plus fiable), utiliser de meilleures pièces, disposer de pièces de rechange sur site, etc. Les économies de coûts de la virtualisation peuvent souvent être directement converties en une fiabilité accrue, faisant encore davantage pencher la balance en faveur de l'approche du serveur unique.

Comme je l'ai affirmé dans un autre article, une seule maison en briques a plus de chances de survivre à une tempête de vent qu'une ou même deux maisons en paille. Avoir davantage de quelque chose n'en fait pas nécessairement le choix le plus fiable.

Ces avantages proviennent purement de l'aspect consolidation de la virtualisation et non de la virtualisation elle-même. La virtualisation offre également séparément des fonctionnalités étendues d'atténuation des risques. La création d'images système et les restaurations rapides, ainsi que les restaurations vers du matériel différent, sont des avantages majeurs de presque toute plateforme de virtualisation. Cela peut jouer un rôle important dans une stratégie de reprise après sinistre.

Bien entendu, tous ces concepts visent uniquement à démontrer que la virtualisation et la consolidation sur une seule machine peuvent surpasser l'ancienne approche « une application par serveur » tout en permettant des économies – montrant que l'exemple des œufs et des paniers est trompeur et ne s'applique pas dans ce scénario. Il devrait y avoir peu d'appréhension à passer d'un environnement traditionnel directement à un environnement virtualisé sur la base de ces facteurs.

Il convient de noter que la virtualisation peut ensuite étendre la fiabilité du matériel grand public traditionnel en offrant des fonctionnalités de basculement de type mainframe qui vont bien au-delà de ce que les plateformes non virtualisées sont en mesure de fournir. Cela aligne plus fermement le matériel grand public sur les plateformes RISC, plus grandes et plus coûteuses. Ces fonctionnalités peuvent apporter un niveau de protection extrême mais dépassent souvent ce qui est approprié pour les services informatiques qui migrent initialement depuis un environnement de serveurs matériels traditionnel sans basculement. La haute disponibilité est une excellente fonctionnalité mais elle est souvent coûteuse et très souvent inutile, surtout à mesure que les entreprises passent, comme nous l'avons vu, d'environnements relativement peu fiables par le passé à des environnements plus fiables aujourd'hui. Étant donné que nous avons déjà accru la fiabilité au-delà de ce qui était considéré comme nécessaire par le passé, il y a de très bonnes chances qu'un bond extrême en matière de fiabilité ne soit pas nécessaire aujourd'hui, mais en raison de la forte baisse du coût de la haute disponibilité, il est tout à fait possible qu'elle soit justifiée sur le plan des coûts là où elle ne l'était pas auparavant.

Dans le même ordre d'idées, la virtualisation est souvent redoutée parce qu'elle est perçue comme une technologie nouvelle et non éprouvée. C'est assurément faux, mais cette impression existe dans le monde des petites entreprises et des serveurs grand public. En réalité, cependant, la virtualisation a été introduite pour la première fois par IBM dans les années 1960 et, depuis lors, elle est un pilier des mainframes et des serveurs RISC haut de gamme – ces systèmes qui exigent la meilleure fiabilité. Dans le monde des serveurs grand public, la virtualisation représentait un défi technique plus important et il a fallu très longtemps avant qu'elle puisse être mise en œuvre assez efficacement pour qu'il soit utile de l'employer dans le monde réel. Mais même dans le monde des serveurs grand public, la virtualisation est disponible depuis la fin des années 1990 et a donc aujourd'hui environ quinze ans, ce qui dépasse de très loin le stade d'une technologie naissante – dans le monde de l'informatique, elle est positivement vénérable. La virtualisation sur plateforme grand public est un domaine mature comptant plusieurs fournisseurs et produits hautement respectés et extrêmement avancés. L'utilisation de la virtualisation comme norme pour toutes ou presque toutes les applications serveur est un « modèle d'entreprise » établi et accepté de longue date, et qui peut désormais être facilement adopté par des entreprises de toutes tailles.

La virtualisation, peut-être de manière contre-intuitive, est en réalité un composant très critique d'une stratégie de fiabilité. Au lieu d'ajouter du risque, la virtualisation peut presque être abordée comme une plateforme d'atténuation des risques – une boîte à outils pour accroître la fiabilité de vos plateformes informatiques par de multiples voies.