Quand l'absence de redondance est plus fiable – Le mythe de la redondance

Le risque est un concept difficile et son évaluation correcte dans des scénarios donnés exige beaucoup de formation, de réflexion et d'analyse. Souvent, parce que les évaluations de risque sont si difficiles, nous substituons à l'analyse de risque le simple ajout d'une redondance de base en supposant que nous avons atténué le risque de manière appropriée. Mais bien souvent, ce n'est pas le cas. L'introduction de complexité ou de modes de défaillance supplémentaires accompagne souvent l'ajout de redondance, et ces nouvelles formes de défaillance ont le potentiel d'ajouter plus de risque que la redondance ajoutée n'en élimine. Les systèmes de stockage sont particulièrement enclins à ces processus de décision, ce qui est regrettable car peu de systèmes, voire aucun, sont à la fois aussi sensibles à la défaillance et aussi importants à protéger.

Le RAID est un excellent exemple de la façon dont un manque de réflexion holistique sur le risque peut conduire à des prises de décision étranges. Si nous examinons un scénario qui n'a rien d'inhabituel, nous verrons comment l'objectif de se protéger contre la défaillance d'un disque peut en réalité conduire à une augmentation du risque, même lorsqu'une redondance supplémentaire est appliquée. Dans ce scénario, nous comparerons une grappe de douze disques composée de douze disques durs SATA de trois téraoctets au sein d'une seule grappe. Il n'est pas rare d'entendre parler de personnes choisissant le RAID 5 pour ce scénario afin d'obtenir une “capacité et des performances maximales” tout en bénéficiant d'une “protection adéquate contre la défaillance.”

L'idée ici est que le RAID 5 protège contre la perte d'un seul disque, qui peut être remplacé, et que la grappe se reconstruira avant qu'un second disque ne tombe en panne. C'est formidable en théorie, mais les risques réels d'une grappe de cette taille, trente-six téraoctets de capacité disque, ne proviennent pas de défaillances multiples de disques, comme on le soupçonne généralement, mais d'une incapacité à reconstruire de manière fiable la grappe après la défaillance d'un seul disque, ou d'une défaillance de la grappe elle-même sans qu'aucun disque individuel ne tombe en panne. Le risque qu'un second disque tombe en panne est faible, non pas inexistant, mais bien faible. Les disques d'aujourd'hui sont hautement fiables. Une fois qu'un disque tombe en panne, cela augmente bel et bien la probabilité qu'un second disque tombe en panne, ce qui est bien documenté, mais je ne veux pas que ce risque nous détourne de l'examen des véritables risques – le risque d'une opération de reconstruction échouée.

Ce qui nous effraie lors d'une opération de reconstruction RAID 5, c'est qu'une erreur de lecture irrécupérable (URE) peut survenir. Lorsque cela se produit, l'opération de reconstruction s'interrompt et la grappe se retrouve dans un état inutilisable – toutes les données de la grappe sont perdues. Sur les disques SATA courants, le taux d'URE est de 10^14, soit une fois toutes les douze téraoctets d'opérations de lecture. Cela signifie qu'une grappe de six téraoctets en cours de reconstruction a une probabilité d'environ cinquante pour cent de rencontrer une URE et d'échouer. Une probabilité d'échec de cinquante pour cent est follement élevée. Imaginez que votre voiture ait une chance sur deux de perdre ses roues chaque fois que vous la conduisez. Ainsi, avec une petite grappe RAID 5 de six téraoctets (selon les normes actuelles) utilisant des disques SATA à 10^14 URE, si nous venions à perdre un seul disque, nous n'aurions qu'une chance sur deux que la grappe se rétablisse, en supposant que le disque soit remplacé immédiatement. Cela ne tient pas compte du risque qu'un second disque tombe en panne, mais uniquement du risque d'une défaillance par URE. Cela suppose également que le disque soit complètement inactif en dehors de l'opération de reconstruction. Si les disques sont activement utilisés pour d'autres tâches en même temps, les probabilités qu'un événement fâcheux se produise, qu'il s'agisse d'une URE ou d'une défaillance d'un second disque, commencent à augmenter de manière spectaculaire.

Avec une grappe de douze téraoctets, les probabilités de perte totale de données au cours d'une opération de reconstruction commencent à approcher les cent pour cent – ce qui signifie que le RAID 5 n'offre alors absolument aucune fonctionnalité. Il existe toujours une chance de survie, mais elle est très faible. À six téraoctets, vous pouvez comparer une opération de reconstruction à une partie de roulette russe avec une balle et six chambres, où vous devez appuyer trois fois sur la détente. À douze téraoctets, vous devez appuyer six fois ! Ce ne sont pas de bonnes chances.

Mais nous ne parlons pas d'une grappe de douze téraoctets. Nous parlons d'une grappe de trente-six téraoctets – ce qui semble grand, mais c'est une taille que l'on pourrait facilement avoir chez soi aujourd'hui, sans parler d'une entreprise. Tous les grands fabricants de serveurs, ainsi que la quasi-totalité des fournisseurs de stockage à bas coût, proposent aujourd'hui des systèmes de stockage de moins de 10 000 $ dans cette gamme de capacité. Reconstruire une grappe RAID 5 après la défaillance d'un seul disque sur une grappe de trente-six téraoctets revient à jouer à la roulette russe avec une balle, six chambres, et à appuyer dix-huit fois sur la détente ! Vos données n'ont pas beaucoup de chances. Ajoutez à cela le temps considérable nécessaire pour reconstruire une grappe de cette taille, et le risque qu'un second disque tombe en panne pendant cette fenêtre de reconstruction commence à devenir une menace plutôt importante. J'ai vu des estimations de durées de reconstruction grimpant jusqu'à des semaines ou des mois sur certains systèmes. C'est une longue période pendant laquelle on ne peut se permettre de perdre un autre disque. Lorsque l'on parle d'heures ou de jours, les risques sont assez faibles, mais bel et bien présents. Lorsque l'on parle de semaines ou de mois de sollicitation continue, les opérations de reconstruction étant extrêmement éprouvantes pour les disques, les taux de défaillance grimpent de manière spectaculaire.

Avec une grappe de cette taille, nous pouvons effectivement supposer que la perte d'un seul disque signifie la perte de la grappe complète, nous laissant sans aucune protection contre la défaillance de disque. Or, si nous examinons un disque de performance identique ou supérieure et de capacité identique ou supérieure en RAID 0, qui n'offre lui non plus aucune protection contre la perte de disque, nous n'avons besoin d'utiliser que onze des mêmes disques dont nous avions besoin au nombre de douze pour notre grappe RAID 5. Cela signifie qu'au lieu de douze disques durs, chacun présentant environ trois pour cent de probabilité de défaillance annuelle, nous n'en avons que onze. Cela suffit à rendre notre grappe RAID 0 plus fiable, car il y a moins de disques susceptibles de tomber en panne. Non seulement nous avons moins de disques, mais il n'est pas nécessaire d'écrire le bloc de parité ni de sauter les blocs de parité lors de la relecture, ce qui réduit, très légèrement, l'usure mécanique de la grappe RAID 0 pour une même utilisation, lui conférant un très léger avantage supplémentaire en matière de fiabilité. La grappe RAID 0 de onze disques sera de capacité identique à la grappe RAID 5 de douze disques, mais offrira un débit légèrement meilleur et une latence légèrement moindre. Un gain sur toute la ligne. Et ce, en plus de l'économie réalisée en n'ayant pas besoin d'un disque supplémentaire.

Ce que nous constatons ici, c'est donc que dans les grandes grappes (grandes en capacité, et non en nombre de disques) le RAID 0 dépasse en réalité le RAID 5 dans certains scénarios. Lors de l'utilisation de disques SATA courants, cela se produit à des capacités atteintes même par les utilisateurs avancés à domicile et par de nombreuses petites entreprises. Si nous passons à des disques SATA d'entreprise ou à des disques SAS, le chiffre de capacité auquel cela se produit devient très élevé et ne constitue pas une préoccupation aujourd'hui, mais le deviendra dans quelques années seulement, lorsque les capacités des disques seront encore plus grandes. Mais cela met en évidence à quel point le RAID 5 est dangereux dans les tailles que nous voyons aujourd'hui. Tout le monde comprend les risques considérables du RAID 0, mais il peut être difficile de mettre en perspective le fait que les problèmes du RAID 5 sont si extrêmes qu'il pourrait en réalité être moins fiable que le RAID 0.

Que le RAID 5 puisse être moins fiable que le RAID 0 dans une grappe de cette taille, sur la seule base des opérations de reconstruction, n'est qu'un début. Dans une grappe aussi massive, le temps de reconstruction peut être si long et éprouver si durement les disques que la défaillance d'un second disque commence elle aussi à devenir un risque mesurable. Et puis il y a des risques supplémentaires causés par des erreurs du contrôleur de la grappe qui peuvent exploiter les algorithmes de reconstruction pour détruire une grappe entière même lorsqu'aucune défaillance de disque ne s'est produite. Comme le RAID 0 (ou le RAID 1, ou le RAID 10) ne dispose pas d'algorithmes de reconstruction, il ne subit pas ce risque supplémentaire. Ce sont des risques difficiles à quantifier, mais l'important est qu'il s'agit de risques supplémentaires qui s'accumulent lors de l'utilisation d'un système plus complexe alors qu'un système plus simple, sans la redondance, était plus fiable dès le départ.

Maintenant que nous avons établi que le RAID 5 peut être moins fiable que le RAID 0, je vais souligner les dangers évidents du RAID 0. Le RAID en général est utilisé pour atténuer le risque de défaillance d'un disque dur unique et isolé. Nous redoutons tous qu'un seul disque tombe simplement en panne et que toutes les données soient perdues. Le RAID 0, étant une grande bande de disques dépourvue de toute forme de redondance, prend le risque de perte de données d'un seul disque défaillant et le multiplie sur un certain nombre de disques, où la défaillance de n'importe quel disque entraîne la perte totale des données de tous les disques. Ainsi, dans notre exemple à onze disques ci-dessus, si l'un quelconque des onze disques tombe en panne, tout est perdu. Il est aisé de voir en quoi cela est nettement plus dangereux que d'utiliser un seul disque, tout seul.

Ce que je tente de souligner ici, c'est que la redondance ne signifie pas la fiabilité. Le simple fait que quelque chose soit redondant, comme le RAID 5, ne fournit aucune garantie qu'il sera toujours plus fiable que quelque chose qui n'est pas redondant.

Mon analogie préférée à ce sujet consiste à observer des maisons dans une tornade. Dans un premier scénario, nous construisons une maison en briques et en mortier. Dans le second scénario, nous construisons deux maisons redondantes, faites de paille (nos bâtisseurs sont des cochons, apparemment). Lorsque la tornade (ou le grand méchant loup) survient, laquelle est la plus susceptible de nous laisser une maison encore debout ? De toute évidence, une seule maison en briques et en mortier présente des avantages de fiabilité significatifs par rapport à des maisons en paille redondantes. La redondance n'a pas compté ; c'est la fiabilité qui a compté en fin de compte.

La redondance est souvent trompeuse parce qu'elle est facile à quantifier mais difficile à qualifier. La redondance est une question en noir et blanc : est-ce redondant ? Oui ou non. Simple. La fiabilité n'est pas si simple. La fiabilité est une affaire de taux de défaillance et de probabilités. C'est une affaire de statistiques et d'analyse. Comme il est difficile de quantifier la fiabilité de manière significative, en particulier lorsqu'il s'agit de vendre un projet aux décideurs de l'entreprise, la redondance devient souvent un simple substitut à ce concept complexe.

Le concept consistant à utiliser la redondance pour détourner les questions de fiabilité finit également par s'appliquer aux sous-systèmes de manières très alambiquées. Au lieu de rendre redondant un “système”, il est devenu courant de rendre redondant un sous-système hautement fiable et à faible coût, et de traiter la redondance de ce sous-système comme si elle s'appliquait au système tout entier. L'exemple le plus courant en est celui des contrôleurs RAID dans les produits SAN. Plutôt que de disposer d'un SAN redondant (c'est-à-dire deux SAN), les fabricants rendent souvent redondant ce seul composant qui ne l'est pas souvent dans les serveurs ordinaires, puis qualifient le SAN de redondant – entendant par là un SAN qui contient de la redondance, ce qui n'est pas du tout la même chose.

Une bonne analogie ici consisterait à comparer le fait de disposer de voitures redondantes, c'est-à-dire de deux voitures complètes et fonctionnelles, et le fait de disposer d'une seule voiture avec une pompe à eau de rechange dans le coffre au cas où la principale tomberait en panne. De toute évidence, une pompe à eau de rechange n'est pas une mauvaise chose. Mais c'est aussi une protection dérisoire contre une panne de voiture comparée au fait d'avoir une seconde voiture prête à partir. Dans un cas, c'est l'ensemble du système qui est redondant, châssis compris. Dans l'autre, nous ne rendons redondant qu'un seul composant, hautement fiable, à l'intérieur du châssis. Ce n'est même pas comparable au fait d'avoir un pneu de secours qui, lui au moins, est un composant de la voiture présentant une probabilité de défaillance plus élevée.

Tout comme le mythe de la fiabilité du RAID 5 et de la fiabilité système/sous-système, les technologies de stockage partagé telles que les SAN et les NAS sont souvent traitées de la même manière, en particulier en ce qui concerne la virtualisation. Il existe un scénario courant où un projet de virtualisation est entrepris et où les gens paniquent instinctivement parce qu'un hôte de virtualisation unique représente un point de défaillance unique où, s'il tombe en panne, de nombreux systèmes tomberont en panne tous en même temps.

L'emploi de l'expression “point de défaillance unique” provoque un sentiment de panique et constitue un excellent moyen d'orienter une conversation. Mais un SPOF, comme nous aimons l'appeler, bien qu'il s'agisse de quelque chose que nous aimons éliminer lorsque c'est possible, n'est peut-être pas la fin du monde. Pensez à notre maison en briques. C'est un SPOF. Nos deux maisons en paille n'en sont pas. Pourtant, un seul souffle de vent abat nos solutions redondantes plus vite que notre fiable SPOF. Rechercher les SPOF est une excellente façon de repérer les points de fragilité d'un système, mais n'ayez pas le sentiment que chaque SPOF doit être rendu redondant dans chaque scénario. La plupart des entreprises trouveront leur meilleur rapport qualité-prix en conservant de nombreux SPOF en place. Notre véritable objectif est la fiabilité à un coût approprié ; la redondance, comme nous l'avons vu, n'est pas un substitut à la fiabilité, c'est simplement un outil que nous pouvons utiliser pour atteindre la fiabilité.

La théorie que beaucoup de gens suivent lorsqu'ils virtualisent consiste à prendre leur hôte de virtualisation et à dire “Cet hôte est un SPOF, je dois donc en avoir deux et utiliser les fonctionnalités de haute disponibilité pour permettre un basculement transparent !” Ceci est encouragé par le fait que le principal fournisseur de virtualisation gagne son argent, d'une part, en vendant des produits complémentaires de haute disponibilité onéreux et, d'autre part, en étant détenu par un grand fournisseur de stockage – de sorte que vendre du stockage partagé supplémentaire inutile, voire dangereux, représente pour lui une importante manne financière et pourrait fort bien être la raison pour laquelle il a défendu l'espace de la virtualisation depuis le tout début. Des hôtes de virtualisation redondants avec stockage partagé, cela sonne bien, mais peut être extrêmement malavisé pour plusieurs raisons.

La première raison est que la suppression du SPOF initial, l'hôte de virtualisation, se traduit par son remplacement par un nouveau SPOF, le stockage partagé. Cela n'accomplit rien. En supposant que nous utilisions des serveurs et un stockage partagé de qualité comparable, tout ce que nous avons fait, c'est déplacer l'endroit où se situe le risque, et non en changer l'ampleur. La probabilité que le système de stockage tombe en panne est à peu près égale à la probabilité que le serveur d'origine tombe en panne. Mais en plus de déplacer le SPOF d'un endroit à l'autre comme dans un jeu de bonneteau, nous avons aussi fait quelque chose de bien, bien pire – nous avons introduit des dépendances de défaillance enchaînées ou en cascade.

Dans notre scénario d'origine, nous avions un seul serveur. Si le serveur restait fonctionnel, tout allait bien ; s'il tombait en panne, non. Simple. Désormais, nous avons deux hôtes de virtualisation, un seul serveur de stockage (SAN, NAS, peu importe) et un réseau qui les relie entre eux. Nous avons déjà déterminé que le risque de défaillance du stockage partagé est approximativement égal au risque total du système dans notre scénario d'origine. Mais nous avons à présent les dépendances supplémentaires que constituent le réseau et les deux nœuds de virtualisation frontaux. Chacun de ces composants est plus fiable que le fragile stockage partagé (tout ce qui comporte des disques mécaniques sera fragile), mais le fait qu'ils présentent un risque plus faible n'est pas la question ; la question est que les risques sont combinatoires.

Si l'un quelconque de ces trois composants (le stockage, le réseau ou les nœuds frontaux) tombe en panne, alors tout tombe en panne. La solution à cela consiste à rendre le stockage partagé redondant en lui-même et à rendre le réseau redondant en lui-même. Avec suffisamment d'efforts, nous pouvons surmonter la fragilité et le risque que nous avons introduits en ajoutant du stockage partagé, mais le stockage partagé en lui-même n'est pas une forme d'atténuation du risque : il constitue un risque en soi qui doit être atténué. La spirale de la complexité s'amorce, et le coût associé à l'élévation de ce nouveau système au niveau de fiabilité du système d'origine, à serveur unique, peut être astronomique.

Maintenant que nous disposons de toute cette redondance, nous avons un risque supplémentaire à craindre. Gérer toute cette redondance, toutes ces pièces mobiles, exige bien plus de connaissances, de compétences et de préparation que de gérer un système simple à serveur unique. Nous sommes passés d'une solution simple à une solution très complexe. Selon ma propre expérience anecdotique, les véritables dangers de solutions de ce type ne proviennent pas de la défaillance du matériel, mais de l'erreur humaine. Non seulement peu de choses ont été faites pour éviter que l'erreur humaine ne fasse tomber ce nouveau système en panne, mais nous avons ajouté d'innombrables points où une personne pourrait accidentellement faire s'effondrer le système tout entier, redondance comprise. Je l'ai vu de mes propres yeux ; j'ai entendu les récits d'horreur. Plus le système est complexe, plus il est probable qu'une personne casse accidentellement tout.

Il est essentiel qu'en tant que professionnels de l'informatique nous prenions du recul pour considérer les systèmes dans leur ensemble, réfléchir à la fiabilité et au risque, et concevoir la redondance simplement comme un outil à utiliser dans la quête de la fiabilité. La redondance n'est pas en soi une panacée. La simplicité non plus. La fiabilité est un problème complexe à résoudre. Éviter les substitutions simplistes est une première étape importante pour passer de la dissimulation des problèmes de fiabilité à leur prise en charge et à leur résolution.