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.
Atténuation des défaillances
Lorsque vous planifiez votre ElastiCache implémentation Amazon, vous devez planifier de manière à ce que les défaillances aient un impact minimal sur votre application et vos données. Les rubriques dans cette section présentent les approches que vous pouvez entreprendre pour éviter d'éventuelles défaillances de vos applications et données.
Atténuer les défaillances lors de l'exécution de Redis OSS
Lorsque vous exécutez le moteur Redis OSS, vous disposez des options suivantes pour minimiser l'impact d'une défaillance d'un nœud ou d'une zone de disponibilité.
Atténuation des défaillances de nœuds
Les caches sans serveur atténuent automatiquement les défaillances des nœuds grâce à une architecture multi-AZ de sorte que les défaillances des nœuds soient transparentes pour votre application. Les clusters auto-conçus doivent être configurés de manière appropriée pour atténuer la défaillance d’un nœud individuel.
Pour atténuer l'impact des défaillances des nœuds Redis OSS sur les clusters conçus par vos soins, vous disposez des options suivantes :
Atténuation des défaillances : groupes de réplication Redis OSS
Un groupe de réplication Redis OSS est composé d'un seul nœud principal sur lequel votre application peut à la fois lire et écrire, et de 1 à 5 nœuds de réplication en lecture seule. Chaque fois que des données sont écrites sur le nœud principal, elles sont également mises à jour de façon asynchrone sur les nœuds de réplica en lecture.
Cas d'échec d'un réplica en lecture
ElastiCache détecte l'échec de lecture de la réplique.
ElastiCache met le nœud défaillant hors ligne.
ElastiCache lance et approvisionne un nœud de remplacement dans la même zone de disponibilité.
La nouveau nœud est synchronisé sur le nœud principal.
Pendant ce temps, votre application peut continuer à lire et à écrire en utilisant les autres nœuds.
Redis OSS Multi-AZ
Vous pouvez activer le Multi-AZ sur vos groupes de réplication Redis OSS. Que vous activiez Multi-AZ ou non, un nœud principal défaillant sera détecté et remplacé automatiquement. Ce qui se produit dépend du fait que Multi-AZ soit activé ou pas.
Lorsque Multi-AZ est activé
ElastiCache détecte la défaillance du nœud principal.
ElastiCache promeut le nœud de réplication en lecture avec le moins de retard de réplication vers le nœud principal.
La synchronisation des autres réplicas avec le nouveau nœud principal se produit.
ElastiCache lance une réplique en lecture dans l'AZ du serveur principal défaillant.
La synchronisation du nouveau nœud avec le réplica principal nouvellement promu se produit.
Le basculement vers un nœud de réplica est généralement plus rapide que la création et la mise en service d'un nouveau nœud principal. Cela signifie que votre application peut reprendre l'écriture sur votre nœud principal plus rapidement que si Multi-AZ n'avait pas été activé.
Pour plus d’informations, consultez Minimiser les temps d'arrêt dans ElastiCache (Redis OSS) grâce à la technologie multi-AZ.
Lorsque Multi-AZ est désactivé
ElastiCache détecte une défaillance principale.
ElastiCache met le serveur principal hors ligne.
ElastiCache crée et approvisionne un nouveau nœud principal pour remplacer le nœud principal défaillant.
ElastiCache synchronise le nouveau primaire avec l'une des répliques existantes.
Lorsque la synchronisation est terminée, le nouveau nœud fonctionne en tant que nœud principal du cluster.
Pendant les étapes 1 à 4 de ce processus, votre application ne peut pas écrire sur le nœud principal. Toutefois, votre application peut continuer la lecture à partir de vos nœuds de réplica.
Pour une meilleure protection, nous vous recommandons de lancer les nœuds de votre groupe de réplication dans des zones de disponibilité différentes (AZ). Si vous procédez ainsi, une défaillance de zone de disponibilité affectera uniquement les nœuds figurant dans cette zone et non ceux des autres zones.
Pour plus d’informations, consultez Haute disponibilité avec les groupes de réplication.
Atténuation des défaillances des zones de disponibilité
Les caches sans serveur atténuent automatiquement les défaillances des zones de disponibilité grâce à une architecture multi-AZ répliquée de sorte que les défaillances des zones de disponibilité soient transparentes pour votre application.
Afin d’atténuer l’impact d’une défaillance de zone de disponibilité dans un cluster auto-conçu, recherchez vos nœuds pour chaque partition dans le plus grand nombre possible de zones de disponibilité.
Quel que soit le nombre de nœuds que contient une partition, s’ils sont tous situés dans la même zone de disponibilité, une défaillance catastrophique de la zone de disponibilité entraînera la perte de toutes les données de votre partition. Toutefois, si vous recherchez vos nœuds dans plusieurs zones de disponibilité, une défaillance au niveau d'une zone de disponibilité n'entraînera que la perte des nœuds figurant dans cette zone.
A chaque fois que vous perdez un nœud, vous notez une dégradation des performances puisque les opérations de lecture sont désormais partagées par un plus petit nombre de nœuds. Cette dégradation des performances perdurera tant le nœuds n'auront pas été remplacés.
Pour plus d'informations sur la spécification des zones de disponibilité pour les nœuds Redis OSS, consultezCréation d'un cluster Redis OSS (mode cluster désactivé) (console).
Pour plus d'informations sur les régions et les zones de disponibilité, consultez Choix des régions et des zones de disponibilité.
Recommandations
Nous vous recommandons de créer des caches sans serveur sur des clusters auto-conçus, car vous obtiendrez automatiquement une meilleure tolérance aux pannes sans configuration supplémentaire. Lors de la création d’un cluster auto-conçu, vous devez toutefois prévoir deux types de défaillances : les défaillances au niveau du nœud et les défaillances plus étendues au niveau des zones de disponibilité. Le meilleur plan d'atténuation des risques d'échec traitera deux types de défaillances.
Réduction au maximum de l’impact des défaillances des nœuds
Afin de limiter l'impact d'une défaillance de nœud, nous vous recommandons d'utiliser plusieurs nœuds dans chaque partition et de les répartir entre plusieurs zones de disponibilité. Ce processus est automatique pour les caches sans serveur.
Pour les clusters conçus par vos soins, nous vous recommandons d'activer le mode multi-AZ sur votre groupe de réplication afin que ElastiCache celui-ci bascule automatiquement vers une réplique en cas de défaillance du nœud principal.
Minimiser l'impact des défaillances au niveau des zones de disponibilité
Afin de limiter l'impact d'une défaillance de zone de disponibilité, nous vous recommandons de lancer vos nœuds dans le plus grand nombre de zones de disponibilité disponibles. La répartition de vos nœuds de manière uniforme dans les zones de disponibilité réduira l'impact d'une défaillance peu probable des zones de disponibilité. Ce processus est automatique pour les caches sans serveur.
Autres précautions
Si vous utilisez Redis OSS, en plus de ce qui précède, nous vous recommandons de planifier des sauvegardes régulières de votre cluster. Les sauvegardes (instantanés) créent un fichier .rdb, que vous pouvez utiliser pour restaurer votre cache en cas de défaillance ou d’endommagement. Pour plus d'informations, voir Instantané et restauration.
