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.
# Comment fonctionnent l'autoshift zonal et les courses d'entraînement
La fonctionnalité de transfert automatique zonal d'Amazon Application Recovery Controller (ARC) permet de AWS transférer le trafic d'une ressource hors d'une zone de disponibilité, en votre nom, lorsqu'il est AWS déterminé qu'une déficience est susceptible d'affecter les clients de la zone de disponibilité. L'autoshift zonal est conçu pour une ressource pré-dimensionnée dans toutes les zones de disponibilité d'un an Région AWS, afin qu'une application puisse fonctionner normalement en cas de perte d'une zone de disponibilité.
Avec l'autoshift zonal, vous devez configurer des séances d'entraînement, au cours desquelles l'ARC déplace régulièrement le trafic vers la ressource hors d'une zone de disponibilité. L'ARC planifie des séances d'entraînement environ une fois par semaine pour chaque ressource associée à une configuration d'exécution d'entraînement. Les séances d'entraînement pour chaque ressource sont planifiées indépendamment.
Pour chaque séance d'entraînement, l'ARC enregistre un résultat. Si un essai est interrompu par une condition bloquante, le résultat de l'essai n'est pas marqué comme réussi. Pour plus d'informations sur les résultats des essais, consultez la section [Résultats des essais](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
Vous pouvez configurer les EventBridge notifications Amazon pour qu'elles vous envoient des informations sur les changements automatiques et les entraînements. Pour de plus amples informations, veuillez consulter [Utilisation de l'autoshift zonal avec Amazon EventBridge](eventbridge-zonal-autoshift.md).
**Topics**
+ [À propos de Zonal Autoshift](arc-zonal-autoshift.how-it-works.about.md)
+ [Quand AWS démarre et arrête les changements automatiques](arc-zonal-autoshift.how-it-works.start-stop-auto.md)
+ [Quand l'ARC planifie, commence et termine les entraînements](arc-zonal-autoshift.how-it-works.scheduled-practice-runs.md)
+ [Contrôles de capacité pour les essais](arc-zonal-autoshift.how-it-works.capacity-check.md)
+ [Notification pour les essais et les changements automatiques](arc-zonal-autoshift.how-it-works.notifications.md)
+ [Priorité pour les décalages de zone](arc-zonal-autoshift.how-it-works.precedence.md)
+ [Arrêt d'un passage automatique actif ou d'une course d'entraînement](arc-zonal-autoshift.how-it-works.stop-shift.md)
+ [Comment le trafic est redirigé](arc-zonal-autoshift.how-it-works.how-traffic-shifted.md)
+ [Alarmes pour les séances d'entraînement](arc-zonal-autoshift.how-it-works.alarms.md)
+ [Fenêtres bloquées et fenêtres autorisées (en UTC)](arc-zonal-autoshift.how-it-works.blocked-windows.md)
# À propos de Zonal Autoshift
L'autoshift zonal est une fonctionnalité qui AWS déplace le trafic des ressources applicatives hors d'une zone de disponibilité, en votre nom. AWS lance un changement automatique lorsque la télémétrie interne indique une altération de la zone de disponibilité susceptible d'avoir un impact sur les clients. La télémétrie interne intègre des métriques provenant de plusieurs sources, notamment le AWS réseau et les services Amazon EC2 et Elastic Load Balancing.
Vous devez activer manuellement le changement automatique de zone pour les ressources prises en charge AWS .
Lorsque vous déployez et exécutez AWS des applications sur des équilibreurs de charge dans plusieurs (généralement trois) AZs d'une région, et que vous les dimensionnez à l'avance pour garantir une stabilité statique, vous AWS pouvez rapidement récupérer les applications clients dans une zone AZ en transférant le trafic grâce à un transfert automatique. En transférant le trafic des ressources vers d'autres AZs sites de la région, AWS vous pouvez réduire la durée et la gravité de l'impact potentiel causé par des pannes de courant, des problèmes matériels ou logiciels dans une AZ ou d'autres déficiences.
Les ressources prises en charge par l'ARC fournissent des intégrations qui marquent l'AZ spécifié comme étant en mauvais état, ce qui entraîne le déplacement du trafic vers l'AZ altéré.
Lorsque vous activez l'autoshift zonal pour une ressource, vous devez également configurer un exercice d'entraînement pour la ressource. AWS effectue des séances d'entraînement environ une fois par semaine, pendant 30 minutes, afin de vous assurer que vous disposez d'une capacité suffisante pour exécuter votre application sans l'une des zones de disponibilité de la région.
Comme dans le cas du changement de zone, il existe quelques scénarios spécifiques dans lesquels le changement automatique de zone n'éloigne pas le trafic de l'AZ. Par exemple, si les groupes cibles de l'équilibreur de charge AZs ne possèdent aucune instance, ou si toutes les instances ne fonctionnent pas correctement, l'équilibreur de charge est dans un état d'ouverture défaillante et vous ne pouvez pas déplacer l'un des. AZs
Pour en savoir plus sur l'autoshift zonal, voir. [Changement de zone automatique dans ARC](arc-zonal-autoshift.md)
# Quand AWS démarre et arrête les changements automatiques
Lorsque vous activez le transfert automatique zonal pour une ressource, vous autorisez AWS le transfert du trafic des ressources d'une application depuis une zone de disponibilité lors d'événements, en votre nom, afin de réduire le délai de restauration.
Pour ce faire, l'autoshift zonal utilise la AWS télémétrie pour détecter, le plus tôt possible, toute altération de la zone de disponibilité susceptible d'avoir un impact sur les clients. Lorsqu'un transfert automatique AWS démarre, le trafic vers les ressources configurées commence immédiatement à s'éloigner de la zone de disponibilité altérée, ce qui pourrait avoir un impact sur les clients.
L'autoshift zonal est une fonctionnalité conçue pour les clients qui ont prédimensionné leurs ressources applicatives pour toutes les zones de disponibilité d'un. Région AWS Vous ne devez pas vous fier à la mise à l'échelle à la demande lorsqu'un passage automatique ou un entraînement commence.
AWS met fin à un changement automatique lorsqu'il détermine que la zone de disponibilité est rétablie.
# Quand l'ARC planifie, commence et termine les entraînements
L'ARC planifie une séance d'entraînement pour une ressource chaque semaine, pendant environ 30 minutes. L'ARC planifie, démarre et gère les essais pour chaque ressource de manière indépendante. L'ARC ne regroupe pas les essais d'entraînement pour les ressources d'un même compte. Vous pouvez également démarrer vous-même des séances d'entraînement à la demande, afin de vérifier que votre configuration est sûre pour un événement de changement automatique zonal.
Lorsqu'une séance d'entraînement se poursuit pendant la durée prévue, sans interruption, elle est marquée par un résultat de`SUCCESSFUL`. Plusieurs autres résultats sont possibles :`FAILED`,`INTERRUPTED`, `CAPACITY_CHECK_FAILED` et`PENDING`. Les valeurs et les descriptions des [résultats sont incluses dans la section Résultats des essais](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
Dans certains cas, l'ARC interrompt une séance d'entraînement et y met fin. Par exemple, si un changement automatique démarre pendant un exercice d'entraînement, ARC interrompt le cycle d'entraînement et y met fin. Autre exemple, supposons que la ressource réagit négativement à un entraînement et déclenche une alarme que vous avez spécifiée pour surveiller le passage à un `ALARM` état de l'entraînement. Dans ce scénario, ARC interrompt également l'entraînement et y met fin.
En outre, il existe plusieurs scénarios dans lesquels ARC ne lance pas d'entraînement de planification pour une ressource.
En réponse à des exercices d'entraînement interrompus ou bloqués pour une ressource, ARC effectue les opérations suivantes :
+ Si un entraînement pour une ressource est interrompu alors qu'il est en cours, l'ARC considère que le cycle d'entraînement hebdomadaire est terminé et planifie un nouvel entraînement pour la ressource pour la semaine suivante. Le résultat de l'entraînement hebdomadaire correspond `INTERRUPTED` à ce scénario, non`FAILED`. Le résultat de l'entraînement est défini sur `FAILED` uniquement lorsque l'alarme de résultat qui surveille l'entraînement passe à un `ALARM` état pendant l'entraînement.
+ S'il existe une contrainte de blocage lorsqu'il est prévu de démarrer un exercice d'entraînement pour une ressource, ARC ne démarre pas le cycle d'entraînement. L'ARC poursuit une surveillance régulière, afin de déterminer s'il existe toujours une ou plusieurs contraintes de blocage. Lorsqu'il n'y a aucune contrainte de blocage, ARC lance l'entraînement pour la ressource.
Voici des exemples de contraintes de blocage qui empêchent l'ARC de démarrer ou de poursuivre un entraînement pour une ressource :
+ L'ARC ne démarre ni ne poursuit les essais lorsqu'une AWS Fault Injection Service expérience est en cours. Si un AWS FIS événement est actif alors que l'ARC a planifié le début d'un exercice d'entraînement, ARC ne démarre pas le cycle d'entraînement. L'ARC surveille tout au long des essais les contraintes de blocage, y compris un AWS FIS événement. Si un AWS FIS événement commence alors qu'un entraînement est actif, l'ARC met fin à l'entraînement et n'essaie pas d'en démarrer un autre avant le prochain entraînement régulier prévu pour la ressource.
+ S'il y a un AWS événement en cours dans une région, l'ARC ne lance pas de courses d'entraînement pour les ressources et met fin aux séries d'entraînement actives dans la région.
Lorsque la course d'entraînement se termine sans être interrompue, l'ARC planifie la prochaine course d'entraînement dans une semaine, comme d'habitude. Si un exercice d'entraînement n'est pas démarré en raison d'une contrainte bloquante, telle qu'une AWS FIS expérience ou une fenêtre temporelle bloquée que vous avez spécifiée, ARC continue de tenter de démarrer un exercice d'entraînement jusqu'à ce que celui-ci puisse être démarré.
# Contrôles de capacité pour les essais
Lorsqu'une séance d'entraînement commence, pour déplacer temporairement le trafic hors d'une zone de disponibilité, ARC vérifie que vous disposez d'une capacité suffisante dans les autres zones de disponibilité pour déplacer le trafic en toute sécurité hors de l'AZ. Si la capacité disponible est insuffisante, le transfert de trafic pour le cycle d'entraînement n'est pas lancé et le cycle d'entraînement prend fin.
En outre, l'ARC effectue un contrôle de capacité pour les ressources de l'équilibreur de charge lorsqu'un changement automatique de zone est terminé, avant que l'ARC ne mette fin au changement de trafic entamé par le changement automatique. Si le contrôle de capacité échoue à la fin du transfert automatique, le trafic n'est pas redirigé vers la zone de disponibilité dont il a été éloigné.
Les contrôles de capacité équilibrée ne sont effectués que pour les équilibreurs de charge et les groupes Auto Scaling.
Pour une ressource d'équilibreur de charge, les contrôles de capacité permettent de vérifier que les hôtes sains associés à l'équilibreur de charge sont répartis entre les zones de disponibilité. Plus précisément, les contrôles de capacité garantissent que le nombre d'hôtes sains dans toutes les zones de disponibilité où la ressource est enregistrée est équilibré. Pour les contrôles de capacité, équilibré signifie que la capacité saine de chaque zone de disponibilité est égale à celle des autres zones, avec un léger écart.
Notez que les contrôles de capacité ne sont pas appliqués aux équilibreurs de charge avec des groupes cibles de type Lambda ni aux équilibreurs de charge d'application, car ces cibles ne sont pas configurées par zone.
Les contrôles de capacité sont également effectués pour les groupes Auto Scaling. Pour un groupe Auto Scaling, les contrôles de capacité valident que la capacité zonale saine totale d'un groupe Auto Scaling, c'est-à-dire le nombre total d'hôtes sains dans toutes les zones de disponibilité, correspond à la capacité définie pour ce groupe Auto Scaling.
**En cas d'échec d'une vérification de capacité**
Lorsqu'un contrôle de capacité révèle que la capacité disponible n'est pas équilibrée pour une ressource, le résultat de l'essai est le suivant`CAPACITY_CHECK_FAILED`. Pour en savoir plus sur les raisons pour lesquelles un contrôle de capacité a échoué, consultez le champ de commentaire du`ZonalShiftSummary`. Pour trouver le champ de commentaire correspondant à votre exercice de course par zone, procédez comme suit :
1. À l'aide de AWS CLI, listez les décalages de zone pour la ressource que vous avez spécifiée lors de l'entraînement effectué à l'aide de l'opération [ListZonalShifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListZonalShifts.html)API.
FOr Par exemple, pour renvoyer les décalages de zone, vous pouvez exécuter une commande similaire à la suivante :
```
aws arc-zonal-shift start-practice-run
--resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890"
```
1. Passez en revue le tableau d'`ZonalShiftSummary`objets renvoyé pour trouver le décalage de zone correspondant à l'essai qui a échoué en raison de contrôles de capacité.
1. Pour connaître le décalage de zone applicable, consultez les informations du `Comment` champ.
# Notification pour les essais et les changements automatiques
Vous pouvez choisir d'être informé des essais et des changements automatiques pour votre ressource en configurant EventBridge les notifications Amazon. Vous pouvez configurer EventBridge des notifications même si vous n'avez activé le décalage automatique zonal pour aucune ressource, ce que l'on appelle la notification *automatique par les observateurs*. Avec la notification Autoshift Observer, vous êtes informé de tous les changements automatiques lancés par ARC lorsqu'une zone de disponibilité est potentiellement altérée. Notez que vous devez configurer cette option dans chaque cas pour Région AWS lequel vous souhaitez recevoir des notifications.
Pour connaître les étapes à suivre pour activer la notification automatique des observateurs, reportez-vous [Activation ou désactivation de la notification automatique des observateurs](arc-zonal-autoshift.enable-autoshift-observer.md) à. Pour en savoir plus sur les options de notification et sur la façon de les configurer EventBridge, consultez[Utilisation de l'autoshift zonal avec Amazon EventBridge](eventbridge-zonal-autoshift.md).
# Priorité pour les décalages de zone
Il ne peut y avoir qu'un seul décalage de zone appliqué à un moment donné. En d'autres termes, un seul cabinet exécute un changement de zone, un changement de zone initié par le client, un décalage automatique ou AWS FIS un test pour la ressource. Lorsqu'un deuxième décalage de zone est lancé, l'ARC suit une priorité pour déterminer le type de décalage de zone en vigueur pour une ressource.
Le principe général de priorité est que les changements de zone que vous commencez en tant que client ont priorité sur les autres types de quarts de travail. Sachez toutefois qu'un exercice d'entraînement AWS initié en cours d'exécution vous empêche de démarrer un entraînement à la demande.
Pour illustrer la priorité dans ARC, voici comment fonctionne la priorité dans des exemples de scénarios :
| Type de décalage zonal appliqué | Type de changement de zone initié | Résultat |
| --- | --- | --- |
| AWS FIS expérience | Course d'entraînement | Le cycle d'entraînement ne pourra pas démarrer, car l' AWS FIS expérience a la priorité. |
| AWS FIS expérience | Déplacement de zone manuel | L' AWS FIS expérience sera annulée et le décalage de zone manuel sera appliqué. |
| AWS FIS expérience | Changement de zone automatique | L' AWS FIS expérience sera annulée et l'autoshift zonal sera appliqué. |
| AWS FIS expérience | AWS FIS expérience | L' AWS FIS expérience initiée ne pourra pas démarrer car une expérience en cours d'exécution a déclenché l'action de AWS FIS changement automatique. |
| Course d'entraînement | Déplacement de zone manuel | La séance d'entraînement sera annulée, le résultat fixé àINTERRUPTED, et le décalage de zone sera appliqué. |
| Course d'entraînement | AWS FIS expérience | La séance d'entraînement sera annulée, le résultat fixé àINTERRUPTED, et l' AWS FIS expérience sera appliquée. |
| Course d'entraînement | Changement de zone automatique | La séance d'entraînement sera annulée et le résultat défini surINTERRUPTED, et le changement automatique de zone sera appliqué. |
| Déplacement de zone manuel | Course d'entraînement | La course d'entraînement ne démarrera pas. |
| Déplacement de zone manuel | AWS FIS expérience | L' AWS FIS expérience ne démarrera pas ou échouera si elle est déjà en cours. |
| Déplacement de zone manuel | Changement de zone automatique | L'autoshift zonal se fera ACTIVE mais pas APPLIED sur la ressource. Le décalage de zone manuel est prioritaire. |
| Changement de zone automatique | AWS FIS expérience | L' AWS FIS expérience ne démarrera pas ou échouera si elle est en cours. |
| Changement de zone automatique | Déplacement de zone manuel | L'autoshift zonal se fera ACTIVE mais pas APPLIED sur la ressource. Le décalage de zone manuel est prioritaire. |
| Changement de zone automatique | Course d'entraînement | La séance d'entraînement ne démarrera pas, car l'autoshift zonal a la priorité. |
Le changement de trafic actuellement en cours pour la ressource a un statut de changement de zone appliqué défini sur `APPLIED`. Un seul quart de travail est défini sur `APPLIED` à la fois. Les autres changements en cours sont définis comme tels`NOT_APPLIED`, mais restent `ACTIVE` inchangés.
# Arrêt d'un changement automatique actif ou d'un entraînement pour une ressource
Pour arrêter un changement automatique en cours pour une ressource, vous devez annuler le changement de zone.
Des séances d'entraînement régulières ont toujours lieu pour la ressource, selon le même calendrier. Si vous souhaitez arrêter les essais en plus de désactiver les changements automatiques, vous devez supprimer la configuration des essais associés à la ressource.
Lorsque vous supprimez une configuration d'entraînement, AWS cesse d'effectuer des essais qui déplacent le trafic de la ressource hors d'une zone de disponibilité chaque semaine. En outre, étant donné que le décalage automatique zonal nécessite des essais, lorsque vous supprimez une configuration d'entraînement à l'aide de la console ARC, cette action désactive également le décalage automatique zonal pour la ressource. Notez toutefois que si vous utilisez l'API zonal autoshift pour supprimer un exercice d'entraînement, vous devez d'abord désactiver le décalage automatique zonal pour la ressource.
Pour plus d’informations, consultez [Annulation d'un changement automatique zonal](arc-zonal-autoshift.canceling-an-autoshift.md) et [Activation et utilisation de l'autoshift zonal](arc-zonal-autoshift.start-cancel.md).
# Comment le trafic est redirigé
Dans le cas des changements de zone automatiques et des changements de zone effectués par entraînement, le trafic est transféré hors d'une zone de disponibilité en utilisant le même mécanisme que celui utilisé par l'ARC pour les changements de zone initiés par le client. En cas de mauvais état de santé, Amazon Route 53 retire du DNS les adresses IP correspondantes à la ressource, de sorte que le trafic est redirigé depuis la zone de disponibilité. Les nouvelles connexions sont désormais routées vers d'autres zones de disponibilité Région AWS .
Avec un changement automatique, lorsqu'une zone de disponibilité se rétablit et AWS décide de mettre fin au changement automatique, l'ARC inverse le processus de vérification de l'état, demandant que les contrôles de santé de la Route 53 soient annulés. Ensuite, les adresses IP zonales d'origine sont restaurées et, si les bilans de santé continuent de fonctionner correctement, la zone de disponibilité est à nouveau incluse dans le routage de l'application.
Il est important de savoir que les changements automatiques ne sont pas basés sur des contrôles de santé qui surveillent l'état sous-jacent des équilibreurs de charge ou des applications. L'ARC utilise des bilans de santé pour éloigner le trafic des zones de disponibilité, en demandant que les bilans de santé soient définis sur un état défectueux, puis rétablit les bilans de santé à la normale lorsqu'il met fin à un changement automatique ou à un changement de zone.
# Alarmes pour les séances d'entraînement
Vous pouvez spécifier deux types d' CloudWatch alarmes pour les essais en mode automatique zonal : les alarmes de résultat et les alarmes de blocage.
**Alarmes de résultat (obligatoire)**
Pour le premier type d'alarme, l'*alarme de résultat*, au moins une alarme doit être spécifiée. Vous devez configurer les alarmes de résultat pour surveiller l'état de votre application lorsque le trafic est déplacé hors d'une zone de disponibilité au cours de chaque essai de 30 minutes.
Pour qu'un essai soit efficace, spécifiez comme alarmes de résultat au moins une CloudWatch alarme répondant aux deux critères suivants :
L'alarme surveille les métriques de la ressource ou de votre application
AND
L'alarme émet un `ALARM` état lorsque votre application est affectée par la perte d'une zone de disponibilité.
Pour plus d'informations, consultez la section **Alarmes que vous spécifiez pour les séances d'entraînement** dans[Bonnes pratiques lors de la configuration de l'autoshift zonal](arc-zonal-autoshift.considerations.md).
Les alarmes de résultat fournissent également des informations sur le *résultat de l'exercice* d'entraînement que l'ARC rapporte pour chaque entraînement. Si une alarme de résultat passe à un `ALARM` état, ARC met fin à l'essai et renvoie le résultat d'un essai de`FAILED`. Si l'essai pratique termine la période de test de 30 minutes et qu'aucune des alarmes de résultat que vous avez spécifiées n'entre dans un `ALARM` état, le résultat renvoyé est`SUCCEEDED`. Une liste de toutes les valeurs de résultats, avec des descriptions, est fournie dans la section [Résultats des essais](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
**Alarmes de blocage (facultatif)**
Vous pouvez éventuellement définir un deuxième type d'alarme, l'*alarme de blocage*. La pratique du blocage des alarmes commence à démarrer ou à se poursuivre lorsqu'une ou plusieurs alarmes sont en `ALARM` état. Les alarmes de blocage bloquent la pratique d'exécuter les changements de trafic dès le démarrage et d'arrêter toute exécution d'entraînement en cours lorsqu'au moins une des alarmes est active. `ALARM`
Par exemple, dans une architecture de grande envergure comportant plusieurs microservices, lorsqu'un microservice rencontre un problème, vous souhaitez généralement arrêter toutes les autres modifications apportées à l'environnement de l'application, y compris le blocage des exécutions pratiques. Pour ce faire, vous pouvez ajouter une alarme de blocage dans ARC.
# Fenêtres bloquées et fenêtres autorisées (en UTC)
Vous avez la possibilité de *bloquer* ou d'*autoriser* les séances d'entraînement pour des dates calendaires spécifiques, ou pour des créneaux horaires spécifiques, c'est-à-dire des jours et des heures, spécifiés en UTC.
Par exemple, si le lancement d'une mise à jour de l'application est prévu pour le 1er mai 2024 et que vous ne souhaitez pas que les séances d'entraînement entraînent une diminution du trafic à ce moment-là, vous pouvez définir une date de blocage pour`2024-05-01`.
Ou imaginons que vous publiez des résumés de rapports commerciaux trois jours par semaine. Pour ce scénario, vous pouvez définir les jours et heures récurrents suivants comme fenêtres bloquées, par exemple, en UTC :`MON-20:30-21:30 WED-20:30-21:30 FRI-20:30-21:30`.
Vous pouvez également décider que les mercredis et vendredis de midi à 17 h sont les meilleurs moments pour que l'ARC commence ses essais, afin de tester votre configuration. Pour ce scénario, vous pouvez définir les jours et heures récurrents suivants comme fenêtres autorisées, par exemple, en UTC :`WED-12:00-17:00 FRI-12:00-17:00`.