Quand envisager la haute disponibilité ?

« La haute disponibilité, ce n'est pas quelque chose que l'on achète, c'est quelque chose que l'on fait. » — John Nicholson

Peu de choses sont plus universellement désirées dans l'informatique que les solutions de haute disponibilité (HA). Vraiment, prononcez ces mots et n'importe quel professionnel de l'informatique dira aussitôt qu'il en veut. De la HA pour ses serveurs, ses applications, son stockage et, bien sûr, même ses postes de travail. S'il existait une case à cocher à côté de chaque système indiquant simplement « HA », pourquoi ne la cocherions-nous pas ? Nous le ferions, évidemment. Personne ne veut volontairement d'un système qui tombe souvent en panne. La panne, c'est mauvais ; le bon fonctionnement, c'est bien.

Tout d'abord, cependant, nous devons définir la HA. La HA peut signifier bien des choses. Au minimum, la HA doit signifier que la disponibilité du système en question doit être supérieure à la « normale ». Qu'est-ce que la normale ? Cela seul est déjà assez difficile à définir. La HA est un terme vague, au mieux. Dans le contexte de son usage le plus courant, toutefois, à savoir des applications courantes s'exécutant sur du matériel d'entreprise standard, je proposerais ce point de départ pour les discussions sur la HA :

La disponibilité normale ou standard (SA) se définirait comme la disponibilité d'un serveur grand public courant exécutant un système d'exploitation d'entreprise courant faisant tourner une application d'entreprise courante, dans un environnement conforme aux bonnes pratiques et bénéficiant d'un support d'entreprise. De bons exemples pourraient inclure Exchange tournant sur Windows Server lui-même exécuté sur un HP Proliant DL380 (le serveur grand public le plus répandu). Ou bien BIND (le serveur DNS) tournant sur Red Hat Enterprise Linux sur un Dell PowerEdge R730. Ce ne sont là que des exemples destinés à établir une référence approximative. Il n'existe aucune méthode parfaite pour mesurer cela, mais avec un bon contrat de support et une réparation ou un remplacement rapides dans le monde réel, on estime que la fiabilité d'un système de cette nature se situe entre quatre et cinq neuf de fiabilité (99,99 % de disponibilité ou plus) lorsque la défaillance humaine n'est pas prise en compte.

La haute disponibilité (HA) devrait communément se définir comme le fait de présenter une disponibilité nettement supérieure à celle de la disponibilité standard. Nettement supérieure devrait correspondre à une augmentation d'au moins un ordre de grandeur. Donc au moins cinq neuf de fiabilité, et plus probablement six neuf (99,9999 % de disponibilité).

La faible disponibilité (LA) se définirait communément comme le fait de présenter une disponibilité nettement inférieure à celle de la disponibilité standard, nettement signifiant là encore au moins un ordre de grandeur. Ainsi, on supposerait généralement que la LA se situe autour de 99 % à 99,9 % de disponibilité, ou moins.

La mesure est ici très difficile, car les facteurs humains, environnementaux et autres jouent un rôle considérable dans la détermination de la disponibilité des différentes configurations. Le même matériel utilisé dans un rôle donné pourrait atteindre cinq neuf, tandis que dans un autre il ne parviendrait même pas à en atteindre un seul. La qualité du centre de données, la compétence du personnel de support, la rapidité de remplacement des pièces, la granularité de la supervision et une multitude d'autres facteurs influeront de manière significative sur la fiabilité globale. Ce n'est cependant pas nécessairement un problème pour nous. Dans la plupart des cas, nous pouvons évaluer les portions d'une conception de système que nous maîtrisons de telle sorte que la fiabilité relative puisse être déterminée, afin qu'au moins nous puissions démontrer qu'une approche sera supérieure à une autre, ce qui nous permet ensuite de nous appuyer sur une prise de décision bien éclairée, même si des modèles précis de taux de défaillance ne peuvent être facilement construits.

Il est important de noter que, hormis le fait de fournir un ensemble d'exemples de référence à partir desquels travailler, rien dans les définitions de la haute disponibilité ou de la faible disponibilité ne traite de la manière dont ces niveaux devraient être atteints — ce n'est pas ce que signifient ces termes. Les termes désignent des ensembles de fiabilité résultants par rapport à la référence, et rien d'autre. Il existe de nombreuses façons d'atteindre la haute disponibilité sans recourir aux approches communément supposées, et un nombre pratiquement illimité de façons d'atteindre la faible disponibilité.

Bien entendu, la HA peut se définir à chaque couche. Nous pouvons disposer de plateformes ou de systèmes d'exploitation en HA tout en ayant des applications fragiles par-dessus. Il est donc très important de comprendre à quel niveau nous nous situons à tout moment donné. En fin de compte, une entreprise ne se souciera que de la livraison hautement disponible des services, indépendamment de la manière dont elle est obtenue, ou de l'endroit. Le résultat final est ce qui compte, et non les détails « sous le capot » de la manière dont il a été obtenu ou, comme toujours, la fin justifie les moyens.

Il est extrêmement courant aujourd'hui que les services informatiques se laissent distraire par de nouveaux outils de HA tape-à-l'œil au niveau de la couche plateforme et oublient de rechercher la HA plus haut et plus bas dans la pile afin de garantir que nous fournissons des services hautement disponibles à l'entreprise ; au lieu de cela, ils ne considèrent qu'une seule couche tout en laissant l'entreprise tout aussi vulnérable, voire davantage, qu'auparavant.

Dans le monde réel, cependant, la HA n'est pas toujours une option et, lorsqu'elle l'est, elle a un coût. Ce coût est presque toujours monétaire et s'accompagne généralement d'une complexité supplémentaire. Et comme nous le savons bien, toute complexité comporte également un risque supplémentaire, et ce risque pourrait, si nous n'y prenons garde, faire qu'une tentative d'atteindre la HA échoue en réalité et pourrait même nous laisser avec de la LA, ou faible disponibilité.

Une fois que nous comprenons ce langage nécessaire pour décrire ce que nous entendons, nous pouvons commencer à discuter du moment où la haute disponibilité, la disponibilité standard et même la faible disponibilité peuvent nous convenir. Nous employons ce niveau élevé de granularité parce qu'il est si difficile de mesurer la fiabilité d'un système qu'entrer dans trop de détails finit par n'avoir aucune valeur.

Sur le plan conceptuel, tous les systèmes comportent un risque d'indisponibilité et rien ne peut être disponible en permanence, c'est impossible. La fiabilité coûte de l'argent, en général, toutes choses égales par ailleurs. Ainsi, pour déterminer quel niveau de disponibilité est le plus approprié pour une charge de travail, nous devons déterminer le coût de l'atténuation du risque (la somme d'argent qu'il faut dépenser pour modifier la durée moyenne d'indisponibilité) et le comparer au coût de l'indisponibilité elle-même.

Cela devient délicat et compliqué, car déterminer le coût de l'indisponibilité est déjà assez difficile, et déterminer ensuite le risque d'indisponibilité l'est plus encore. Dans bien des cas, l'indisponibilité ne représente pas un chiffre fixe, mais cela pourrait être le cas. Ce coût pourrait s'exprimer sous la forme de 5 $/minute ou de 20 000 $/jour, ou de quelque chose de similaire. Mais un outil encore meilleur consisterait à créer une « courbe d'impact des pertes » qui montre comment l'argent est perdu au fil du temps (sur un intervalle raisonnable).

Par exemple, une entreprise pourrait aisément ne subir aucune perte du tout durant les cinq premières minutes, avec des pertes lentement croissantes, mais faibles, jusqu'à environ quatre heures, moment où le travail s'arrête parce que les gens ne peuvent plus recourir au papier ou à quoi que ce soit, et où les pertes passent alors de presque zéro à considérables. Ou bien certaines entreprises pourraient subir une perte énorme au moment même où les systèmes tombent en panne, mais les pertes se dissipent lentement au fil du temps. La perte pourrait n'avoir d'impact qu'à certaines heures de la journée. Peut-être que des interruptions la nuit ou pendant le déjeuner sont insignifiantes, mais qu'en milieu de matinée ou en milieu d'après-midi elles sont majeures. L'impact, le risque et la capacité à atténuer ce risque sont différents pour chaque entreprise, souvent de manière spectaculaire.

Parfois, tout dépend des personnes qui travaillent dans l'entreprise. Prendront-elles toutes volontiers les pauses nécessaires (toilettes, café, collation, voire déjeuner) au moment où un système tombe en panne, afin de pouvoir reprendre le travail une fois celui-ci réparé ? Les gens rentreront-ils plus tôt et arriveront-ils plus tôt le lendemain pour rattraper une panne majeure ? Y a-t-il des machines qui vont rester inactives ? La capacité à répondre aux clients sera-t-elle affectée ? Des systèmes de maintien des fonctions vitales tomberont-ils en panne ? Il existe d'innombrables impacts potentiels et d'innombrables façons potentielles d'atténuer différents types de défaillances. Tout cela doit être pris en compte. Le coût de l'indisponibilité pourrait représenter une fraction des revenus de l'entreprise sur une base minute par minute, ou bien l'indisponibilité pourrait entraîner une perte de clients ou de confiance plus lourde de conséquences que les revenus générés minute par minute.

Une fois que nous disposons de quelques chiffres de pertes approximatifs sur lesquels travailler, nous avons au moins un point de départ. Même si nous savons seulement que le revenu est d'environ 10 $/minute et que les pertes devraient avoisiner les 5 $/minute, nous avons une sorte de point de départ. Si nous disposons d'une courbe complète ou d'une étude réalisée avec des chiffres plus détaillés, c'est encore mieux. Maintenant, nous devons déterminer approximativement quelle sera notre référence. Un serveur bien entretenu, fonctionnant sur site, avec un bon contrat de support ainsi que de bonnes procédures de sauvegarde et de restauration, peut assez facilement atteindre quatre neuf de fiabilité. Cela signifie que nous connaîtrions environ cinq heures d'indisponibilité tous les cinq ans. C'est en réalité moins que l'indisponibilité généralement attendue de la SA dans la plupart des environnements, et potentiellement bien moins que les niveaux attendus dans d'excellents environnements tels que des centres de données de haute qualité disposant de pièces et de services à proximité.

Ainsi, en nous fondant sur notre exemple de référence d'environ cinq heures tous les cinq ans, nous pouvons déterminer notre risque potentiel. Si nous perdons environ 5 $/minute et que nous prévoyons environ 300 minutes d'indisponibilité tous les cinq ans, nous envisageons une perte potentielle de 1 500 $ par demi-décennie.

Cela signifie qu'au plus extrême, nous ne pourrions jamais dépenser 1 500 $ pour atténuer ce risque, ce serait financièrement absurde. Cela tient à plusieurs raisons. L'une des plus importantes est qu'il ne s'agit que d'un risque ; dépenser 1 500 $ pour se protéger contre la perte de 1 500 $ n'a guère de sens, mais c'est une erreur très courante lorsque les gens n'analysent pas ces chiffres avec soin.

Le facteur le plus déterminant est qu'aucune technique d'atténuation n'est totalement efficace. Si nous parvenons à faire passer notre système de quatre neuf à un système de cinq neuf, nous ne réduirions que 90 % de l'indisponibilité moyenne, nous faisant passer de 1 500 $ de perte à 150 $ de perte. Si nous dépensions 1 500 $ pour cette réduction, la « perte » totale s'élèverait tout de même à 1 650 $ (le coût de la protection est une forme de perte financière). Le coût de l'atténuation du risque, combiné à l'impact résiduel anticipé, doit, pris dans son ensemble, rester inférieur au coût anticipé du risque sans atténuation, faute de quoi l'atténuation elle-même est inutile, voire activement préjudiciable.

Beaucoup pourraient se demander pourquoi le coût total de l'atténuation du risque doit être inférieur et non simplement égal, car cela signifierait sûrement que nous nous trouvons à un point de « seuil de rentabilité du risque » ? Cela paraît vrai en surface, mais parce que nous avons affaire à du risque, ce n'est pas le cas. L'atténuation du risque est un coût certain — un dommage financier que nous encaissons d'emblée dans l'espoir de réduire des pertes futures. Mais le risque de demain est une supposition, espérons-le bien fondée, mais une supposition tout de même. Le coût d'aujourd'hui, lui, est certain. Encaisser un dommage certain aujourd'hui dans l'espoir de réduire un dommage possible demain n'a de sens que lorsque le dommage d'aujourd'hui est faible, que le dommage attendu ou possible de demain est très important, et que l'efficacité de l'atténuation est significative.

Inclus dans l'idée de « coût certain d'emblée » pour réduire un « coût possible demain » se trouve le concept de la valeur temporelle de l'argent. Même si une panne était d'une ampleur et d'une durée connues, nous ne dépenserions pas la même somme aujourd'hui pour l'atténuer demain, car notre argent a plus de valeur aujourd'hui.

Dans les cas les plus spectaculaires, nous voyons parfois des services informatiques exiger que des dizaines ou des centaines de milliers de dollars soient dépensés d'emblée pour éviter de perdre quelques milliers de dollars, peut-être, un jour, peut-être dans de nombreuses années. Une stratégie que l'on pourrait qualifier de « se tirer une balle dans la tête aujourd'hui pour éviter d'avoir peut-être mal au crâne demain ».

Cela est inclus dans le concept d'évaluation de l'atténuation du risque, mais il convient de mentionner spécifiquement que, dans le cas des équipements informatiques, il existe de nombreux exemples de tentatives d'atténuation du risque qui pourraient ne pas être aussi efficaces qu'on le croit. Par exemple, disposer de deux serveurs installés dans la même baie sera potentiellement très efficace pour atténuer le risque de défaillance matérielle de l'hôte, mais n'atténuera pas les catastrophes naturelles, la perte du site, l'incendie, la plupart des cas de surtension électrique, le déclenchement du système d'extinction d'incendie, les interruptions réseau, la plupart des défaillances applicatives, les attaques par rançongiciel ou d'autres catastrophes raisonnablement possibles.

Il est courant que les dispositifs de stockage soient équipés de « doubles contrôleurs », ce qui donne une forte impression de haute fiabilité, mais ces contrôleurs se trouvent généralement à l'intérieur d'un châssis unique avec des composants partagés et, même si les composants ne sont pas partagés, le micrologiciel l'est souvent et les communications entre composants sont complexes ; cela conduit fréquemment à des défaillances où la panne d'un composant déclenche la panne d'un autre — ce qui en fait bien souvent des dispositifs LA plutôt que SA, ou que la HA que les gens attendaient lors de leur achat. Il est donc très crucial de se demander si la stratégie d'atténuation du risque atténuera effectivement quels risques et si la technique d'atténuation est susceptible d'être efficace. Aucune technique n'est totalement efficace, il y a toujours une possibilité de défaillance, mais certaines stratégies et techniques sont plus largement efficaces que d'autres, et certaines sont tout simplement trompeuses, voire réellement contre-productives. Si nous n'y prenons garde, nous pourrions mettre en œuvre des produits ou des techniques coûteux qui sapent activement nos objectifs.

Certaines techniques et certains produits employés dans la recherche de la haute disponibilité sont plutôt coûteux, ce qui peut inclure l'achat de matériel redondant, la location d'un autre bâtiment, l'installation de générateurs onéreux ou l'acquisition de licences pour des logiciels spécialisés. Il existe aussi des techniques et des logiciels peu coûteux, mais dans la plupart des cas, tout mouvement vers la haute disponibilité se traduira par une mise de fonds d'investissement relativement importante pour y parvenir. Il est absolument essentiel de garder à l'esprit que la haute disponibilité est un processus ; il n'existe aucun moyen d'acheter purement et simplement la haute disponibilité. Atteindre la HA requiert une bonne documentation, des procédures, de la planification, du support, des équipements, de l'ingénierie et davantage encore. Dans le monde des systèmes, la HA est normalement abordée d'abord sous un angle environnemental, avec des générateurs de secours, des systèmes de CVC redondants, le conditionnement de l'alimentation, la filtration de l'air, des systèmes d'extinction d'incendie et davantage encore, afin de garantir que l'environnement propice à la disponibilité est bien présent. Cela seul peut souvent rendre tout investissement supplémentaire inutile, car cela peut produire des résultats incroyables. Vient ensuite la conception de systèmes en HA, garantissant que non pas une seule couche d'une pile technologique soit hautement disponible, mais que l'ensemble de la pile le soit, permettant aux applications, données ou services critiques de demeurer fonctionnels durant le plus de temps possible. Puis vient l'examen de la redondance de site à site afin de pouvoir résister aux inondations, ouragans, blizzards, etc. Bien entendu, il existe des techniques entièrement différentes, telles que le recours à des services de cloud computing hébergés à distance pour notre compte. Ce qui importe, c'est que la haute disponibilité requiert une réflexion et une planification de grande ampleur, qu'elle ne peut être simplement achetée comme une ligne budgétaire, et qu'elle se juge à la capacité de ramener un facteur de risque à un niveau procurant une disponibilité résultante, ou une probabilité de disponibilité, bien supérieure à ce qu'offrirait une conception de système « standard ».

Ce qui surprend souvent, presque jusqu'à la stupéfaction, de nombreuses entreprises et tout particulièrement les professionnels de l'informatique, qui entreprennent rarement une analyse financière du risque et à qui l'on répète constamment que la HA est une nécessité pour toute entreprise et qu'acheter les derniers produits de HA est incontestablement la façon dont leurs budgets devraient être dépensés, c'est que, lorsque les chiffres sont passés au crible et que la réalité des coûts et de l'efficacité des stratégies d'atténuation du risque est prise en compte, la haute disponibilité a très peu sa place dans une organisation, en particulier celles qui sont petites ou qui présentent des charges de travail très hétérogènes. Sur le marché des petites et moyennes entreprises, il est presque universel de constater que le coût et la complexité (qui à leur tour engendrent un risque, principalement sous la forme d'un manque d'expérience en matière de techniques et d'évaluation des risques) des approches de haute disponibilité sont bien trop élevés pour jamais compenser les dommages potentiels de la panne contre laquelle on espère que l'atténuation protégera. Il existe des exceptions, bien entendu, et il y a de nombreuses entreprises pour lesquelles les solutions de haute disponibilité sont tout à fait sensées, mais ce sont là des exceptions, très loin de constituer la norme.

Il est également judicieux de concevoir les besoins en haute disponibilité sur la base d'une charge de travail, et non à l'échelle d'un département, d'une entreprise ou d'une technologie. Dans une petite entreprise, il est courant que toutes les charges de travail partagent une plateforme commune, et le besoin d'une seule charge de travail en matière de haute disponibilité peut entraîner avec lui d'autres charges de travail moins critiques. C'est parfaitement acceptable et c'est un excellent moyen de compenser le coût de l'atténuation du risque de la charge de travail critique grâce au bénéfice annexe apporté aux charges de travail moins critiques. Dans une organisation plus grande, où une pléthore d'approches de plateforme est utilisée pour différentes charges de travail, il est courant que seules certaines charges de travail, à la fois hautement critiques (en termes de risque lié à l'impact de l'indisponibilité) et dont le risque peut être atténué de manière pratique (la capacité à atténuer le risque peut varier considérablement entre différents types de charges de travail), bénéficient de la haute disponibilité, les autres charges de travail étant laissées aux techniques standard.

Parmi les exemples de charges de travail pouvant être critiques et pouvant être efficacement traitées par la haute disponibilité, on pourrait citer un système de commande en ligne où la latence créée par la réplication multirégionale a peu d'impact sur le système global, mais où la perte de commandes pourrait être très lourde de conséquences financières en cas de défaillance d'un système. Un exemple de charge de travail pour laquelle la haute disponibilité pourrait être facile à mettre en œuvre mais inefficace serait un site intranet interne répondant aux questions RH couramment posées ; il ne serait tout simplement pas rentable d'éviter de faibles durées d'indisponibilité occasionnelle pour un système de ce type. Un exemple de système où le risque est élevé mais où le coût ou l'efficacité de l'atténuation du risque la rend impraticable, voire impossible, pourrait être une base de données financière de « ticks » nécessitant l'ingestion de volumes massifs de données à faible latence, et où la capacité à maintenir une réplique serait non seulement incroyablement coûteuse, mais pourrait introduire une latence qui saperait la capacité du système à fonctionner de manière adéquate. Chaque entreprise et chaque charge de travail sont uniques et devraient être évaluées avec soin.

Bien entendu, les techniques de haute disponibilité peuvent être mises en œuvre par étapes ; ce n'est pas une entreprise du tout ou rien. Il pourrait être pratique d'atténuer le risque de défaillance au niveau du système en disposant d'une tolérance aux pannes au niveau de la couche applicative afin de se protéger contre la défaillance du matériel système, de la plateforme de virtualisation ou du stockage. Mais pour cette même charge de travail, il pourrait ne pas être utile de se protéger contre la perte d'un site unique. Si une charge de travail ne dessert qu'un site particulier ou n'a tout simplement pas une valeur suffisante pour justifier l'investissement important nécessaire pour la faire basculer entre sites, elle pourrait aisément se situer « entre les deux ». Il est très courant que les charges de travail ne mettent en œuvre que des solutions partiellement hautement disponibles, souvent parce qu'un service informatique peut n'être responsable que d'une partie d'entre elles et n'avoir aucun mot à dire sur des aspects tels que l'alimentation de secours et le CVC, mais probablement le plus souvent parce que certaines techniques de haute disponibilité sont perçues comme très visibles et faciles à vendre à la direction, tandis que d'autres, telles qu'une alimentation et une climatisation de haute qualité, ne le sont souvent pas, alors même qu'elles peuvent aisément offrir un meilleur rapport qualité-prix. Il existe de bonnes raisons pour lesquelles certaines techniques peuvent être choisies et d'autres non, car elles affectent différentes composantes du risque et certains risques peuvent avoir un impact différent sur une entreprise ou une charge de travail donnée.

La haute disponibilité exige une réflexion attentive quant à savoir si elle vaut la peine d'être envisagée, et une réflexion plus attentive encore quant à sa mise en œuvre. Construire de véritables systèmes en HA requiert une quantité considérable d'efforts et d'expertise, et généralement un coût substantiel. Comprendre quelles composantes de la HA ont de la valeur et lesquelles n'en ont pas requiert non seulement une vaste expertise technique, mais aussi des compétences financières et managériales. Les départements doivent collaborer étroitement pour véritablement comprendre comment la HA affectera une organisation et quand elle vaudra l'investissement. Il est essentiel de garder à l'esprit que le besoin de haute disponibilité dans une organisation ou pour une charge de travail est tout sauf une conclusion acquise d'avance et il ne devrait nullement être surprenant de constater que des pratiques de haute disponibilité poussées, ou même une haute disponibilité sommaire, s'avèrent économiquement impraticables.

À bien des égards, cela tient au fait que la disponibilité standard a atteint un tel niveau qu'il y a continuellement de moins en moins de risque à atténuer. Les composants technologiques utilisés dans l'infrastructure d'une entreprise, notamment les serveurs, les équipements réseau et le stockage, sont devenus si fiables que la quantité d'indisponibilité contre laquelle nous devons nous protéger est tout à fait faible. L'essentiel de la croyance dans le besoin d'une haute disponibilité réflexe provient d'une autre époque, où le matériel fiable était hors de prix et où même les équipements les plus coûteux étaient plutôt peu fiables selon les standards modernes. Ce sentiment de catastrophe imminente, selon lequel n'importe quel appareil pourrait tomber en panne à tout moment, provient d'une époque révolue, et non de l'époque actuelle. Le matériel moderne, bien qu'il comporte évidemment encore des risques, est étonnamment fiable.

Outre les autres risques, le surinvestissement dans les solutions de haute disponibilité comporte des risques financiers et commerciaux qui peuvent être substantiels. Il accroît la dette technique face à l'incertitude commerciale. Que se passe-t-il si l'entreprise connaît une croissance soudaine ou, pire, si elle se contracte soudainement, change de cap, est rachetée ou cesse complètement ses activités ? L'investissement dans la haute disponibilité est déjà engagé, même si le besoin de la protection qu'elle offre disparaît. Que se passe-t-il si la technologie ou l'emplacement change ? Une partie ou la totalité d'un investissement en haute disponibilité pourrait être perdue avant le terme de sa durée de vie prévue.

En tant que praticiens de l'informatique, évaluer les bénéfices, les risques et les coûts des solutions technologiques est au cœur de ce que nous faisons. Comme pour tout le reste dans l'infrastructure d'entreprise, déterminer le type d'atténuation du risque, la valeur de la protection et le montant financièrement approprié est notre responsabilité essentielle et ne peut être survolé ni ignoré. Nous ne pouvons jamais simplement présumer que la haute disponibilité est nécessaire, ni qu'elle peut être purement et simplement écartée. C'est dans une analyse de cette nature que l'informatique apporte une partie de sa plus grande valeur aux organisations. C'est ici que nous avons le potentiel de briller le plus.