Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Comprendre la disponibilité
La disponibilité est l'un des principaux moyens de mesurer quantitativement la résilience. Nous définissons la disponibilité, *A*, comme le pourcentage de temps pendant lequel une charge de travail est disponible pour être utilisée. Il s'agit d'un ratio entre son « temps de disponibilité » attendu (disponibilité) et le temps total mesuré (le « temps de disponibilité » attendu plus le « temps d'arrêt » attendu).
![\[Image de l'équation. A = temps de disponibilité/(temps de disponibilité + temps d'arrêt)\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Pour mieux comprendre cette formule, nous verrons comment mesurer le temps de disponibilité et les temps d'arrêt. Tout d'abord, nous voulons savoir combien de temps durera la charge de travail sans échec. C'est ce *que nous appelons le temps moyen entre les défaillances* (MTBF), le temps moyen entre le début du fonctionnement normal d'une charge de travail et sa prochaine défaillance. Ensuite, nous voulons savoir combien de temps il faudra pour récupérer après une panne.
Nous appelons ce *délai moyen de réparation (ou de restauration)* (MTTR), une période pendant laquelle la charge de travail n'est pas disponible pendant que le sous-système défaillant est réparé ou remis en service. Une période importante du MTTR est le délai *moyen de détection* (MTTD), c'est-à-dire le laps de temps entre la survenue d'une panne et le début des opérations de réparation. Le schéma suivant montre comment toutes ces mesures sont liées.
![\[Schéma illustrant la relation entre MTTD, MTTR et MTBF\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
Nous pouvons ainsi exprimer la disponibilité, *A*, en utilisant le MTBF, le temps pendant lequel la charge de travail est en hausse, et MTTR, le temps pendant lequel la charge de travail est réduite.
![\[Image de l'équation. A = MTBF/(MTBF + MTTR)\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
Et la probabilité que la charge de travail soit « réduite » (c'est-à-dire non disponible) est la probabilité d'échec, *F.*
![\[Image de l'équation. F = 1 - A\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
La [fiabilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) est la capacité d'une charge de travail à faire ce qu'il faut, lorsque cela est demandé, dans le délai de réponse spécifié. C'est ce que mesure la disponibilité. Le fait qu'une charge de travail tombe en panne moins fréquemment (MTBF plus long) ou que le temps de réparation soit plus court (MTTR plus court) améliore sa disponibilité.
**Règle 1**
Des défaillances moins fréquentes (MTBF plus long), des temps de détection des défaillances plus courts (MTTD plus court) et des temps de réparation plus courts (MTTR plus court) sont les trois facteurs utilisés pour améliorer la disponibilité dans les systèmes distribués.
**Topics**
+ [Disponibilité du système distribué](distributed-system-availability.md)
+ [Disponibilité avec dépendances](availability-with-dependencies.md)
+ [Disponibilité avec redondance](availability-with-redundancy.md)
+ [Théorème CAP](cap-theorem.md)
+ [Tolérance aux pannes et isolation des pannes](fault-tolerance-and-fault-isolation.md)
# Disponibilité du système distribué
Les systèmes distribués sont composés à la fois de composants logiciels et de composants matériels. Certains composants logiciels peuvent eux-mêmes être un autre système distribué. La disponibilité des composants matériels et logiciels sous-jacents influe sur la disponibilité de votre charge de travail qui en résulte.
Le calcul de la disponibilité à l'aide du MTBF et du MTTR trouve ses racines dans les systèmes matériels. Cependant, les systèmes distribués échouent pour des raisons très différentes de celles d'un élément matériel. Lorsqu'un fabricant peut calculer régulièrement le délai moyen avant qu'un composant matériel ne s'use, les mêmes tests ne peuvent pas être appliqués aux composants logiciels d'un système distribué. Le matériel suit généralement la courbe « baignoire » du taux de défaillance, tandis que le logiciel suit une courbe échelonnée produite par des défauts supplémentaires introduits à chaque nouvelle version (voir [Fiabilité des logiciels](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)).
![\[Schéma illustrant les taux de défaillance du matériel et des logiciels\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
En outre, les logiciels des systèmes distribués évoluent généralement à un rythme exponentiellement supérieur à celui du matériel. Par exemple, un disque dur magnétique standard peut avoir un taux de défaillance annualisé (AFR) moyen de 0,93 %, ce qui, dans la pratique, peut se traduire par une durée de vie d'au moins 3 à 5 ans avant qu'il n'atteigne la période d'usure, voire plus longtemps (voir [Backblaze Hard](https://www.backblaze.com/b2/hard-drive-test-data.html) Drive Data and Stats, 2020). Le disque dur ne change pas de manière significative au cours de cette durée de vie, où, dans 3 à 5 ans, par exemple, Amazon pourrait déployer plus de 450 à 750 millions de modifications dans ses systèmes logiciels. (Voir [Amazon Builders' Library — Automatiser des déploiements sécurisés](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/) et sans intervention directe.)
Le matériel est également soumis au concept d'obsolescence planifiée, c'est-à-dire qu'il a une durée de vie intrinsèque et qu'il devra être remplacé après un certain temps. (Voir [The Great Lightbulb Conspiracy](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy).) En théorie, le logiciel n'est pas soumis à cette contrainte, il n'a pas de période d'usure et peut être utilisé indéfiniment.
Tout cela signifie que les mêmes modèles de test et de prédiction utilisés pour le matériel pour générer les numéros MTBF et MTTR ne s'appliquent pas aux logiciels. Des centaines de tentatives ont été faites pour créer des modèles pour résoudre ce problème depuis les années 1970, mais elles se répartissent généralement en deux catégories : la modélisation prédictive et la modélisation d'estimation. (Voir [la liste des modèles de fiabilité des logiciels](https://en.wikipedia.org/wiki/List_of_software_reliability_models).)
Ainsi, le calcul d'un MTBF et d'un MTTR prospectifs pour les systèmes distribués, et donc d'une disponibilité prospective, sera toujours dérivé d'un certain type de prédiction ou de prévision. Ils peuvent être générés par le biais d'une modélisation prédictive, d'une simulation stochastique, d'une analyse historique ou de tests rigoureux, mais ces calculs ne constituent pas une garantie de disponibilité ou d'indisponibilité.
Les raisons pour lesquelles un système distribué a échoué dans le passé peuvent ne jamais se reproduire. Les raisons pour lesquelles il échouera à l'avenir seront probablement différentes et peut-être inconnaissables. Les mécanismes de restauration requis peuvent également être différents de ceux utilisés dans le passé pour les défaillances futures et prendre des durées très différentes.
De plus, le MTBF et le MTTR sont des moyennes. Il y aura un certain écart entre la valeur moyenne et les valeurs réelles observées (l'écart type, σ, mesure cette variation). Ainsi, les charges de travail peuvent s'écouler plus ou moins longtemps entre les défaillances et les temps de restauration dans le cadre d'une utilisation réelle en production.
Cela dit, la disponibilité des composants logiciels qui constituent un système distribué est toujours importante. Les logiciels peuvent échouer pour de nombreuses raisons (abordées plus en détail dans la section suivante) et ont un impact sur la disponibilité de la charge de travail. Ainsi, pour les systèmes distribués à haute disponibilité, il convient d'accorder autant d'importance au calcul, à la mesure et à l'amélioration de la disponibilité des composants logiciels qu'aux sous-systèmes matériels et logiciels externes.
**Règle 2**
La disponibilité du logiciel dans votre charge de travail est un facteur important de la disponibilité globale de votre charge de travail et doit bénéficier de la même attention que les autres composants.
Il est important de noter que même si le MTBF et le MTTR sont difficiles à prévoir pour les systèmes distribués, ils fournissent tout de même des informations clés sur la manière d'améliorer la disponibilité. La réduction de la fréquence des défaillances (MTBF plus élevé) et la diminution du temps de rétablissement après une défaillance (MTTR plus faible) permettront toutes deux d'améliorer la disponibilité empirique.
## Types de défaillances dans les systèmes distribués
Il existe généralement deux catégories de bogues dans les systèmes distribués qui affectent la disponibilité, appelées affectueusement *Bohrbug et *Heisenbug** (voir [« A Conversation with Bruce Lindsay », ACM Queue vol. 2, n° 8 — novembre 2004).](http://queue.acm.org/detail.cfm?id=1036486)
Un bohrbug est un problème logiciel fonctionnel récurrent. Avec la même entrée, le bogue produira systématiquement la même sortie incorrecte (comme le modèle atomique déterministe de Bohr, qui est solide et facile à détecter). Ces types de bogues sont rares au moment où une charge de travail passe en production.
Un Heisenbug est un bogue transitoire, c'est-à-dire qu'il ne se produit que dans des conditions spécifiques et peu communes. Ces conditions sont généralement liées à des éléments tels que le matériel (par exemple, une défaillance passagère du périphérique ou des spécificités de l'implémentation matérielle, comme la taille du registre), les optimisations du compilateur et l'implémentation du langage, les conditions limites (par exemple, un manque de stockage temporaire) ou les conditions de course (par exemple, ne pas utiliser de sémaphore pour les opérations multithread).
Les Heisenbugs constituent la majorité des bogues en production et sont difficiles à détecter car ils sont insaisissables et semblent changer de comportement ou disparaître lorsque vous essayez de les observer ou de les corriger. Toutefois, si vous redémarrez le programme, l'opération échouée sera probablement couronnée de succès car l'environnement d'exploitation est légèrement différent, éliminant ainsi les conditions à l'origine du Heisenbug.
Ainsi, la plupart des défaillances de production sont transitoires et il est peu probable qu'elle échoue à nouveau lorsque l'opération est tentée à nouveau. Pour être résilients, les systèmes distribués doivent être tolérants aux défaillances face aux Heisenbugs. Nous verrons comment y parvenir dans la section [Augmenter le MTBF des systèmes distribués](increasing-mtbf.md#increasing-mtbf.title).
# Disponibilité avec dépendances
Dans la section précédente, nous avons indiqué que le matériel, les logiciels et éventuellement d'autres systèmes distribués font tous partie de votre charge de travail. Nous appelons ces composants des *dépendances*, c'est-à-dire les éléments dont dépend votre charge de travail pour fournir ses fonctionnalités. Il existe des dépendances *matérielles*, c'est-à-dire des éléments sans lesquels votre charge de travail ne peut fonctionner, et des dépendances *souples* dont l'indisponibilité peut passer inaperçue ou être tolérée pendant un certain temps. Les dépendances strictes ont un impact direct sur la disponibilité de votre charge de travail.
Nous pouvons essayer de calculer la disponibilité maximale théorique d'une charge de travail. C'est le produit de la disponibilité de toutes les dépendances, y compris le logiciel lui-même (*α* *n* est la disponibilité d'un seul sous-système) car chacune d'entre elles doit être opérationnelle.
![\[Image de l'équation. A = α 1 X α 2 X... Indice X n α>\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
Les chiffres de disponibilité utilisés dans ces calculs sont généralement associés à des éléments tels que les SLA ou les objectifs de niveau de service (SLO). Les SLA définissent le niveau de service attendu des clients, les indicateurs permettant de mesurer le service, ainsi que les mesures correctives ou les pénalités (généralement pécuniaires) en cas de non-atteinte des niveaux de service.
En utilisant la formule ci-dessus, nous pouvons conclure que, d'un point de vue purement mathématique, une charge de travail ne peut être plus disponible que n'importe laquelle de ses dépendances. Mais en réalité, ce que nous constatons généralement, c'est que ce n'est pas le cas. Une charge de travail créée à l'aide de deux ou trois dépendances avec des SLA de disponibilité de 99,99 % peut toujours atteindre elle-même une disponibilité de 99,99 %, voire plus.
En effet, comme nous l'avons indiqué dans la section précédente, ces chiffres de disponibilité sont des estimations. Ils estiment ou prédisent la fréquence d'une panne et la rapidité avec laquelle elle peut être réparée. Ils ne constituent pas une garantie de temps d'arrêt. Les dépendances dépassent souvent leur niveau de disponibilité (SLA ou SLO) déclaré.
Les dépendances peuvent également avoir des objectifs de disponibilité interne plus élevés, par rapport auxquels elles ciblent les performances, que les chiffres fournis dans les SLA publics. Cela permet d'atténuer les risques liés au respect des SLA lorsque l'inconnu ou l'inconnaissable se produit.
Enfin, votre charge de travail peut comporter des dépendances dont les SLA ne peuvent pas être connus ou ne proposent pas de SLA ou de SLO. Par exemple, le routage Internet mondial est une dépendance courante pour de nombreuses charges de travail, mais il est difficile de savoir à quel (s) fournisseur (s) de services Internet votre trafic mondial fait appel, s'ils ont des SLA et dans quelle mesure ils sont cohérents entre les fournisseurs.
Tout cela nous indique que le calcul d'une disponibilité théorique maximale n'est susceptible de produire qu'un calcul approximatif de l'ordre de grandeur, mais qu'il n'est probablement pas en soi précis ou ne fournit pas d'informations significatives. Ce que les calculs nous indiquent, c'est que moins votre charge de travail repose sur des éléments sur lesquels repose votre charge de travail, plus le risque global de défaillance est réduit. Moins il y a de nombres inférieurs à un multipliés, plus le résultat est élevé.
**Règle 3**
La réduction des dépendances peut avoir un impact positif sur la disponibilité.
Les calculs aident également à éclairer le processus de sélection des dépendances. Le processus de sélection influe sur la manière dont vous concevez votre charge de travail, sur la manière dont vous tirez parti de la redondance des dépendances pour améliorer leur disponibilité, et sur le fait de savoir si vous considérez ces dépendances comme souples ou strictes. Les dépendances susceptibles d'avoir un impact sur votre charge de travail doivent être choisies avec soin. La règle suivante fournit des indications sur la manière de procéder.
**Règle 4**
En général, sélectionnez les dépendances dont les objectifs de disponibilité sont égaux ou supérieurs aux objectifs de votre charge de travail.
# Disponibilité avec redondance
Lorsqu'une charge de travail utilise plusieurs sous-systèmes indépendants et redondants, elle peut atteindre un niveau de disponibilité théorique plus élevé qu'en utilisant un seul sous-système. Prenons l'exemple d'une charge de travail composée de deux sous-systèmes identiques. Il peut être complètement opérationnel si le sous-système 1 ou le sous-système 2 est opérationnel. Pour que l'ensemble du système soit hors service, les deux sous-systèmes doivent être hors service en même temps.
*Si la probabilité de défaillance d'un sous-système est de 1 − *α*, la probabilité que deux sous-systèmes redondants soient en panne en même temps est le produit de la probabilité de défaillance de chaque sous-système, *F* = (1− *α1) × (1− α*).* 2 Pour une charge de travail comportant deux sous-systèmes redondants, l'équation *(3)* permet d'obtenir une disponibilité définie comme suit :
![\[Image de trois équations\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Ainsi, pour deux sous-systèmes dont la disponibilité est de 99 %, la probabilité que l'un tombe en panne est de 1 % et la probabilité que les deux échouent est de (1− 99 %) × (1− 99 %) = 0,01 %. Cela porte la disponibilité à 99,99 % à l'aide de deux sous-systèmes redondants.
**Cela peut être généralisé pour intégrer également des pièces de rechange redondantes supplémentaires.** Dans l'équation *(5)*, nous n'avons supposé qu'une seule réserve, mais une charge de travail peut en comporter deux, trois ou plus, de sorte qu'elle puisse survivre à la perte simultanée de plusieurs sous-systèmes sans affecter la disponibilité. *Si une charge de travail comporte trois sous-systèmes et que deux sont des sous-systèmes de rechange, la probabilité que les trois sous-systèmes tombent en panne en même temps est de (1− *α) × (1− α*) × (1− *α*) ou (1− *α*) 3.* En général, une charge de travail avec *s* spare échouera uniquement si les sous-systèmes *s* \$1 1 tombent en panne.
*Pour une charge de travail comportant *n* sous-systèmes et *s* pièces de rechange, *f* est le nombre de modes de défaillance ou la manière dont *s* \$1 1 sous-systèmes peuvent tomber en panne sur n.*
***Il s'agit en fait du théorème binomial, du calcul combinatoire qui consiste à choisir *k* éléments dans un ensemble de *n, ou *«* *n** choisit k ».*** Dans ce cas, *k* est *s* \$1 1.
![\[Image de quatre équations\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Nous pouvons ensuite produire une approximation de disponibilité généralisée qui intègre le nombre de modes de défaillance et le nombre de modes d'épargne. (Pour comprendre pourquoi il s'agit d'une approximation, reportez-vous à l'annexe 2 de Highleyman, et al. [Briser la barrière de disponibilité](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331).)
![\[Image de quatre équations\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
L'épargne peut être appliquée à toute dépendance fournissant des ressources défaillantes de manière indépendante. Les instances Amazon EC2 situées dans différentes zones de disponibilité ou les compartiments Amazon S3 situés dans des zones différentes en Régions AWS sont des exemples. L'utilisation de pièces de rechange permet à cette dépendance d'atteindre une disponibilité totale plus élevée afin de répondre aux objectifs de disponibilité de la charge de travail.
**Règle 5**
Utilisez l'épargne pour augmenter la disponibilité des dépendances dans une charge de travail.
Cependant, l'épargne a un coût. Chaque pièce de rechange supplémentaire coûte le même prix que le module d'origine, le coût étant au moins linéaire. La création d'une charge de travail pouvant utiliser des pièces de rechange augmente également sa complexité. Il doit savoir comment identifier les défaillances liées à la dépendance, affecter le travail à une ressource saine et gérer la capacité globale de la charge de travail.
La redondance est un problème d'optimisation. Si le nombre de pièces de rechange est insuffisant, la charge de travail risque d'échouer plus fréquemment que prévu, le nombre de pièces de rechange est trop élevé et l'exécution de la charge de travail est trop coûteuse. Il existe un seuil à partir duquel l'ajout de pièces de rechange coûtera plus cher que la disponibilité supplémentaire pour laquelle elles sont garanties.
**En utilisant notre formule de disponibilité générale avec des pièces de rechange, équation *(7)*, pour un sous-système dont la disponibilité est de 99,5 %, avec deux pièces de rechange, la disponibilité de la charge de travail est *A* ≈ 1 − (1) (1−0,995) 3 = 99,9999875 % (environ 3,94 secondes d'indisponibilité par an), et avec 10 pièces de rechange, nous obtenons *A* ≈ 1 − (1) (1−0,995) 11 = 25,5 9 ′ *s (environ le temps d'arrêt serait de 1,26252 × 10 −15 m s* par an, soit effectivement 0).** En comparant ces deux charges de travail, nous avons multiplié par 5 le coût des pièces de rechange, ce qui nous a permis de réduire de quatre secondes les temps d'arrêt par an. Pour la plupart des charges de travail, l'augmentation des coûts ne serait pas justifiée pour cette augmentation de la disponibilité. La figure suivante illustre cette relation.
![\[Schéma illustrant les rendements décroissants liés à l'augmentation de l'épargne\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
À trois pièces de rechange et plus, le résultat est une fraction de seconde d'indisponibilité prévue par an, ce qui signifie qu'après ce point, vous atteignez la zone des rendements décroissants. Il peut y avoir une envie de « simplement en ajouter » pour atteindre des niveaux de disponibilité plus élevés, mais en réalité, le rapport coût-avantage disparaît très rapidement. L'utilisation de plus de trois pièces de rechange n'apporte aucun gain matériel et notable pour presque toutes les charges de travail lorsque le sous-système lui-même est disponible à au moins 99 %.
**Règle 6**
Il existe une limite supérieure à la rentabilité de l'épargne. Utilisez le moins de pièces de rechange nécessaires pour atteindre la disponibilité requise.
Vous devez tenir compte de l'unité de défaillance lorsque vous sélectionnez le nombre correct de pièces de rechange. Par exemple, examinons une charge de travail qui nécessite 10 instances EC2 pour gérer la capacité maximale et qui sont déployées dans une seule zone de disponibilité.
Les zones Z étant conçues pour être des limites d'isolation des pannes, l'unité de défaillance n'est pas une seule instance EC2, car une instance EC2 complète peut tomber en panne en même temps. Dans ce cas, vous souhaiterez [ajouter de la redondance avec un autre AZ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html), en déployant 10 instances EC2 supplémentaires pour gérer la charge en cas de défaillance d'AZ, pour un total de 20 instances EC2 (suivant le schéma de stabilité statique).
Bien qu'il s'agisse apparemment de 10 instances EC2 de rechange, il ne s'agit en réalité que d'une seule AZ de rechange. Nous n'avons donc pas dépassé le point de baisse des rendements. Cependant, vous pouvez être encore plus rentable tout en augmentant votre disponibilité en utilisant trois AZ et en déployant cinq instances EC2 par AZ.
Cela fournit à une zone de réserve un total de 15 instances EC2 (contre deux zones de 20 instances), tout en fournissant les 10 instances nécessaires pour répondre aux pics de capacité lors d'un événement ayant un impact sur une seule zone de disponibilité. Vous devez donc intégrer l'épargne pour être tolérant aux pannes au-delà de toutes les limites d'isolation des pannes utilisées par la charge de travail (instance, cellule, AZ et région).
# Théorème CAP
Une autre façon de penser à la disponibilité est en relation avec le théorème CAP. Le théorème indique qu'un système distribué, composé de plusieurs nœuds stockant des données, ne peut fournir simultanément plus de deux des trois garanties suivantes :
+ **Cohérence** : chaque demande de lecture reçoit l'écriture la plus récente ou une erreur lorsque la cohérence ne peut être garantie.
+ **Une** disponibilité : chaque demande reçoit une réponse sans erreur, même lorsque les nœuds sont en panne ou indisponibles.
+ **Tolérance de partition : le système continue de fonctionner malgré la perte d'un nombre arbitraire de messages entre les nœuds.**
(Pour plus de détails, voir Seth Gilbert et Nancy Lynch, La [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970) *ACM SIGACT News*, volume 33, numéro 2 (2002), p. 51—59.)
La plupart des systèmes distribués doivent tolérer les défaillances du réseau et, par conséquent, le partitionnement du réseau doit être autorisé. Cela signifie que ces charges de travail doivent choisir entre cohérence et disponibilité lorsqu'une partition réseau se produit. Si la charge de travail choisit la disponibilité, elle renvoie toujours une réponse, mais avec des données potentiellement incohérentes. S'il choisit la cohérence, il renverra une erreur lors d'une partition réseau, car la charge de travail ne peut pas être sûre de la cohérence des données.
Pour les charges de travail dont l'objectif est de fournir des niveaux de disponibilité plus élevés, elles peuvent choisir Availability and Partition Tolerance (AP) pour éviter de renvoyer des erreurs (indisponibilité) lors d'une partition réseau. Cela entraîne la nécessité d'un [modèle de cohérence](https://en.wikipedia.org/wiki/Consistency_model) plus souple, comme une cohérence éventuelle ou une cohérence monotone.
# Tolérance aux pannes et isolation des pannes
Ce sont deux concepts importants lorsque l'on pense à la disponibilité. La tolérance aux pannes est la capacité à [résister aux défaillances des sous-systèmes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) et à maintenir la disponibilité (en faisant le bon choix dans le cadre d'un SLA établi). Pour implémenter la tolérance aux pannes, les charges de travail utilisent des sous-systèmes de rechange (ou redondants). Lorsque l'un des sous-systèmes d'un ensemble redondant tombe en panne, un autre reprend le travail, généralement de manière presque fluide. Dans ce cas, les pièces de rechange constituent de véritables capacités inutilisées ; elles sont disponibles pour assumer 100 % du travail lié au sous-système défaillant. Avec de véritables pièces de rechange, plusieurs défaillances de sous-systèmes sont nécessaires pour avoir un impact négatif sur la charge de travail.
L'isolation des défauts minimise l'ampleur de l'impact en cas de panne. Ceci est généralement mis en œuvre avec la modularisation. Les charges de travail sont réparties en petits sous-systèmes qui tombent en panne indépendamment et peuvent être réparés isolément. La défaillance d'un module [ne se propage pas au-delà du module](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). Cette idée s'étend à la fois verticalement, à travers les différentes fonctionnalités d'une charge de travail, et horizontalement, à travers plusieurs sous-systèmes qui fournissent les mêmes fonctionnalités. Ces modules agissent comme des conteneurs de défaillances qui limitent l'étendue de l'impact lors d'un événement.
Les modèles architecturaux des plans de contrôle, des plans de données et de la stabilité statique soutiennent directement la mise en œuvre de la tolérance aux pannes et de l'isolation des pannes. L'article [Static stability using Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) de la bibliothèque Amazon Builders fournit de bonnes définitions de ces termes et explique comment ils s'appliquent à la création de charges de travail résilientes et hautement disponibles. Ce livre blanc utilise ces modèles dans la section [Conception de systèmes distribués hautement disponibles surAWS,](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) et nous résumons également leurs définitions ici.
+ **Plan de contrôle** : partie de la charge de travail impliquée dans les modifications : ajout de ressources, suppression de ressources, modification des ressources et propagation de ces modifications là où elles sont nécessaires. Les plans de contrôle sont généralement plus complexes et comportent plus de pièces mobiles que les plans de données. Ils sont donc statistiquement plus susceptibles de tomber en panne et ont une disponibilité moindre.
+ **Plan de données** : partie de la charge de travail qui fournit les fonctionnalités day-to-day métier. Les plans de données ont tendance à être plus simples et à fonctionner à des volumes plus élevés que les plans de contrôle, ce qui se traduit par une plus grande disponibilité.
+ **Stabilité statique** : capacité d'une charge de travail à continuer à fonctionner correctement malgré des troubles de dépendance. L'une des méthodes de mise en œuvre consiste à supprimer les dépendances des plans de contrôle des plans de données. Une autre méthode consiste à coupler de manière souple les dépendances de charge de travail. Peut-être que la charge de travail ne voit aucune information mise à jour (telle que de nouveaux éléments, des éléments supprimés ou des éléments modifiés) que sa dépendance était censée fournir. Cependant, tout ce qu'il faisait avant que la dépendance ne devienne inéluctable continue de fonctionner.
Lorsque nous pensons à la réduction d'une charge de travail, il existe deux approches de haut niveau que nous pouvons envisager pour le rétablissement. La première méthode consiste à réagir à cette déficience une fois qu'elle se produit, par exemple AWS Auto Scaling en ajoutant de nouvelles capacités. La deuxième méthode consiste à se préparer à ces défaillances avant qu'elles ne surviennent, par exemple en surprovisionnant l'infrastructure d'une charge de travail afin qu'elle puisse continuer à fonctionner correctement sans avoir besoin de ressources supplémentaires.
Un système statiquement stable utilise cette dernière approche. Il préapprovisionne la capacité de réserve pour qu'elle soit disponible en cas de panne. Cette méthode évite de créer une dépendance à l'égard d'un plan de contrôle dans le chemin de restauration de la charge de travail afin de fournir une nouvelle capacité de restauration après une panne. En outre, le provisionnement de nouvelles capacités pour diverses ressources prend du temps. En attendant de nouvelles capacités, votre charge de travail peut être surchargée par la demande existante et se dégrader davantage, entraînant une « panne » ou une perte totale de disponibilité. Toutefois, vous devez également tenir compte des implications financières liées à l'utilisation de capacités préprovisionnées par rapport à vos objectifs de disponibilité.
La stabilité statique fournit les deux règles suivantes pour les charges de travail à haute disponibilité.
**Règle 7**
Ne prenez pas en compte les dépendances des plans de contrôle de votre plan de données, en particulier lors de la restauration.
**Règle 8**
Couplez les dépendances de manière souple afin que votre charge de travail puisse fonctionner correctement malgré la diminution des dépendances, dans la mesure du possible.