Tolérance aux pannes et isolation des pannes - Disponibilité et au-delà : comprendre et améliorer la résilience des systèmes distribués sur AWS

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.

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 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. 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 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, 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.