As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Como a mudança automática de zona e as execuções práticas funcionam
A capacidade de mudança automática zonal no Amazon Application Recovery Controller (ARC) permite AWS transferir o tráfego de um recurso para fora de uma zona de disponibilidade, em seu nome, quando AWS determina que há uma deficiência que poderia afetar os clientes na zona de disponibilidade. O deslocamento automático zonal foi projetado para um recurso pré-escalado em todas as zonas de disponibilidade em um Região da AWS, para que um aplicativo possa operar normalmente com a perda de uma zona de disponibilidade.
Com a mudança automática de zona, é necessário configurar execuções práticas, nas quais o ARC move regularmente o tráfego do recurso para fora de uma zona de disponibilidade. O ARC programa execuções práticas semanais para todos os recursos que têm uma configuração de execução prática associada a ele. As execuções práticas são agendadas de forma independente para cada recurso.
Para cada execução prática, o ARC registra um resultado. Se uma execução prática for interrompida por uma condição de bloqueio, o resultado da execução não será marcado como bem-sucedido. Para obter mais informações sobre os resultados das execuções práticas, consulte [Resultados das execuções práticas](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
Você pode configurar EventBridge as notificações da Amazon para enviar informações sobre turnos automáticos e treinos. Para obter mais informações, consulte [Usando o deslocamento automático zonal com a Amazon EventBridge](eventbridge-zonal-autoshift.md).
**Topics**
+ [Sobre a mudança automática de zona](arc-zonal-autoshift.how-it-works.about.md)
+ [Quando AWS inicia e para as mudanças automáticas](arc-zonal-autoshift.how-it-works.start-stop-auto.md)
+ [Quando o ARC programa, inicia e encerra execuções práticas](arc-zonal-autoshift.how-it-works.scheduled-practice-runs.md)
+ [Verificações de capacidade para execuções práticas](arc-zonal-autoshift.how-it-works.capacity-check.md)
+ [Notificação para execuções práticas e mudanças automáticas](arc-zonal-autoshift.how-it-works.notifications.md)
+ [Precedência das mudanças de zona](arc-zonal-autoshift.how-it-works.precedence.md)
+ [Interrupção de uma mudança automática ou execução prática ativa](arc-zonal-autoshift.how-it-works.stop-shift.md)
+ [Como o tráfego é transferido](arc-zonal-autoshift.how-it-works.how-traffic-shifted.md)
+ [Alarmes para execuções práticas](arc-zonal-autoshift.how-it-works.alarms.md)
+ [Janelas bloqueadas e janelas permitidas (em UTC)](arc-zonal-autoshift.how-it-works.blocked-windows.md)
# Sobre a mudança automática de zona
O deslocamento automático zonal é um recurso que AWS retira o tráfego de recursos do aplicativo de uma zona de disponibilidade, em seu nome. AWS inicia um deslocamento automático quando a telemetria interna indica que há uma deficiência na zona de disponibilidade que pode afetar potencialmente os clientes. A telemetria interna incorpora métricas de várias fontes, incluindo a AWS rede e os serviços Amazon EC2 e Elastic Load Balancing.
Você deve ativar manualmente o deslocamento automático zonal para os recursos compatíveis AWS .
Quando você implanta e executa AWS aplicativos em balanceadores de carga em vários (normalmente três) AZs em uma região e pré-dimensiona para oferecer suporte à estabilidade estática, é AWS possível recuperar rapidamente os aplicativos do cliente em uma AZ reduzindo o tráfego com um deslocamento automático. Ao transferir o tráfego de recursos para outros AZs na região, AWS pode reduzir a duração e a gravidade do impacto potencial causado por quedas de energia, problemas de hardware ou software em uma AZ ou outras deficiências.
Os recursos compatíveis com o ARC fornecem integrações que marcam a AZ especificada como não íntegra, o que faz com que o tráfego seja desviado da AZ comprometida.
Ao ativar a mudança automática de zona para um recurso, você também deve configurar uma execução prática para o recurso. A AWS realiza execuções práticas cerca de uma vez por semana, durante 30 minutos, para garantir que haja capacidade suficiente para executar a aplicação sem uma das zonas de disponibilidade na região.
Assim como no caso da mudança de zona, há alguns cenários específicos em que a mudança automática de zona não transfere o tráfego para fora da AZ. Por exemplo, se os grupos-alvo do balanceador de carga no AZs não tiverem nenhuma instância ou se todas as instâncias não estiverem íntegras, o balanceador de carga estará em um estado de falha aberta e você não poderá transferir uma delas. AZs
Para saber mais sobre a mudança automática de zona, consulte [Mudança automática de zona no ARC](arc-zonal-autoshift.md).
# Quando AWS inicia e para as mudanças automáticas
Ao habilitar o deslocamento automático zonal para um recurso, você AWS autoriza a transferência do tráfego de recursos de um aplicativo de uma zona de disponibilidade durante eventos, em seu nome, para ajudar a reduzir o tempo de recuperação.
Para conseguir isso, o deslocamento automático zonal usa a AWS telemetria para detectar, o mais cedo possível, que há uma deficiência na zona de disponibilidade que poderia impactar os clientes. Quando a AWS inicia uma mudança automática, o tráfego para os recursos configurados começa imediatamente a se deslocar da zona de disponibilidade prejudicada, capaz de impactar os clientes.
A mudança automática de zona é um recurso projetado para clientes que ajustaram previamente a escala dos recursos da aplicação para todas as zonas de disponibilidade em uma Região da AWS. Você não deve depender da escalabilidade sob demanda quando uma mudança automática ou um treino começa.
AWS encerra um deslocamento automático quando determina que a zona de disponibilidade foi recuperada.
# Quando o ARC programa, inicia e encerra execuções práticas
O ARC programa uma execução prática para um recurso semanalmente, por cerca de 30 minutos. O programa, inicia e gerencia as execuções práticas para cada recurso de forma independente. O ARC não agrupa execuções práticas para recursos na mesma conta. Você também pode iniciar exercícios sob demanda para verificar se sua configuração é segura para um evento de mudança automática de zona.
Quando uma execução prática acontece pela duração esperada, sem interrupção, ela é marcada com um resultado `SUCCESSFUL`. Existem vários outros resultados possíveis: `FAILED`, `INTERRUPTED`, `CAPACITY_CHECK_FAILED` e `PENDING`. Os valores e as descrições dos resultados estão incluídos na seção [Resultados das execuções práticas](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
Há alguns cenários em que o ARC interrompe uma execução prática e a encerra. Por exemplo, se uma mudança automática começar durante uma execução prática, o ARC interromperá a execução prática e a encerrará. Como outro exemplo, digamos que o recurso tenha uma resposta adversa a uma execução prática e faça com que um alarme que você especificou para monitorar a execução prática entre em um estado `ALARM`. Nesse cenário, o ARC também interromperá a execução prática e a encerrará.
Além disso, há vários cenários em que o ARC não inicia uma execução prática programada para um recurso.
Em resposta às execuções práticas interrompidas e bloqueadas de um recurso, o ARC faz o seguinte:
+ Se a execução prática de um recurso for interrompida enquanto estiver em andamento, o ARC considerará que a execução prática semanal terminou e programará uma nova execução prática para o recurso na semana seguinte. O resultado da prática semanal será `INTERRUPTED` nesse cenário, não `FAILED`. O resultado da execução prática é definido como `FAILED` somente quando o alarme de resultado que monitora a execução prática entra em um estado `ALARM` durante a execução prática.
+ Se houver uma restrição de bloqueio quando a execução prática de um recurso estiver programada para ser iniciada, o ARC não iniciará a execução prática. O ARC continua realizando o monitoramento regularmente para determinar se ainda há uma ou mais restrições de bloqueio. Quando não houver nenhuma restrição de bloqueio, o ARC iniciará a execução prática do recurso.
Veja a seguir exemplos de restrições de bloqueio que impedem que o ARC inicie ou dê continuidade à execução prática de um recurso:
+ O ARC não inicia nem continua os treinos quando há um AWS Fault Injection Service experimento em andamento. Se um AWS FIS evento estiver ativo quando o ARC tiver agendado o início de uma corrida de treinos, o ARC não iniciará a corrida de treinos. O ARC monitora durante todo o treino as restrições de bloqueio, incluindo um AWS FIS evento. Se um AWS FIS evento começar enquanto um treino estiver ativo, o ARC encerrará o treino e não tentará iniciar outro até a próxima corrida de treinos regularmente agendada para o recurso.
+ Se houver um AWS evento atual em uma região, o ARC não inicia os treinos para obter recursos e encerra os treinos ativos na região.
Quando a execução prática termina sem ser interrompida, o ARC programa a próxima execução prática semanal, como de costume. Se uma execução prática não for iniciada devido a uma restrição de bloqueio, como um AWS FIS experimento ou uma janela de tempo bloqueada que você especificou, o ARC continuará tentando iniciar uma execução prática até que a execução prática possa ser iniciada.
# Verificações de capacidade para execuções práticas
Quando uma execução prática é iniciada, para mover temporariamente o tráfego para fora de uma zona de disponibilidade, o ARC executa uma verificação para confirmar se você tem capacidade suficiente em outras zonas de disponibilidade para desviar o tráfego com segurança da AZ. Se não houver capacidade suficiente disponível, a mudança de tráfego da execução prática não será iniciada, mas encerrada.
Além disso, o ARC executa uma verificação de capacidade dos recursos do balanceador de carga quando uma mudança automática de zona é concluída, antes que o ARC encerre a mudança de tráfego iniciada pelo recurso de mudança automática. Se a verificação de capacidade falhar quando a mudança automática terminar, o tráfego não será transferido de volta para a zona de disponibilidade da qual ele foi desviado.
As verificações de capacidade balanceada só são concluídas para balanceadores de carga e grupos de Auto Scaling.
Para um recurso de balanceador de carga, as verificações de capacidade validam se os hosts íntegros associados ao balanceador de carga estão distribuídos por todas as zonas de disponibilidade. Especificamente, as verificações de capacidade garantem que o número de hosts íntegros em todas as zonas de disponibilidade em que o recurso está registrado seja balanceado. No caso das verificações de capacidade, o termo "balanceado" significa que a capacidade íntegra de cada zona de disponibilidade está em paridade com as outras zonas, respeitando uma pequena variação.
Observe que as verificações de capacidade não são aplicadas a balanceadores de carga com grupos de destino do tipo Lambda nem a Application Load Balancers, porque esses destinos não são configurados por zona.
As verificações de capacidade também são concluídas para grupos de Auto Scaling. Para um grupo de Auto Scaling, as verificações de capacidade validam que a capacidade zonal total íntegra de um grupo de Auto Scaling, ou seja, o número total de hosts íntegros em todas as zonas de disponibilidade, atende ao conjunto de capacidades desejado para esse grupo de Auto Scaling.
**Quando uma verificação de capacidade falha**
Quando uma verificação de capacidade determina que a capacidade disponível não está balanceada para um recurso, o resultado da execução prática é `CAPACITY_CHECK_FAILED`. Para saber mais sobre por que uma verificação de capacidade falhou, consulte o campo de comentários de `ZonalShiftSummary`. Para encontrar o campo de comentários da mudança de zona para execução prática, faça o seguinte:
1. Usando o AWS CLI, liste as mudanças de zona para o recurso que você especificou na execução prática usando a operação da [ListZonalShifts](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListZonalShifts.html)API.
FOr exemplo, para retornar as mudanças zonais, você pode executar um comando semelhante ao seguinte:
```
aws arc-zonal-shift start-practice-run
--resource-identifier="arn:aws:elasticloadbalancing:Region:111122223333:ExampleALB123456890"
```
1. Analise a matriz de objetos `ZonalShiftSummary` retornados para encontrar a mudança de zona da execução prática que falhou devido às verificações de capacidade.
1. Para a mudança de zona aplicável, analise as informações no campo `Comment`.
# Notificação para execuções práticas e mudanças automáticas
Você pode optar por ser notificado sobre ensaios e mudanças automáticas para seu recurso configurando as notificações da Amazon EventBridge . Você pode configurar EventBridge notificações mesmo quando não tiver ativado o deslocamento automático zonal para nenhum recurso, conhecido como notificação do observador de *mudança automática*. Com a notificação do observador de mudança automática, você é notificado sobre todas as mudanças automáticas que o ARC inicia quando uma zona de disponibilidade está potencialmente comprometida. Observe que você deve configurar essa opção em cada uma Região da AWS das quais deseja receber notificações.
Para ver as etapas para ativar a notificação do observador de mudança automática, consulte [Ativação ou desativação da notificação do observador de mudança automática](arc-zonal-autoshift.enable-autoshift-observer.md). Para saber mais sobre as opções de notificação e como configurá-las EventBridge, consulte[Usando o deslocamento automático zonal com a Amazon EventBridge](eventbridge-zonal-autoshift.md).
# Precedência das mudanças de zona
Não pode haver mais de uma mudança de zona aplicado em um determinado momento. Ou seja, apenas uma prática executa mudança zonal, mudança zonal iniciada pelo cliente, mudança automática ou AWS FIS experimento para o recurso. Quando uma segunda mudança de zona for iniciada, o ARC seguirá uma precedência para determinar qual tipo de mudança de zona estará em vigor para um recurso.
O princípio geral de precedência é que as mudanças de zona que você inicia como cliente têm precedência sobre outros tipos de mudança. No entanto, esteja ciente de que uma execução prática AWS iniciada atualmente impede que você inicie uma execução prática sob demanda.
Para ilustrar a precedência no ARC, veja a seguir como a precedência funciona em alguns cenários de exemplo:
| Tipo de mudança de zona aplicado | Tipo de mudança de zona iniciado | Resultado |
| --- | --- | --- |
| AWS FIS experimento | Execução prática | A execução prática não será iniciada, pois o AWS FIS experimento tem precedência. |
| AWS FIS experimento | Mudança manual de zona | O AWS FIS experimento será cancelado e a mudança de zona manual será aplicada. |
| AWS FIS experimento | Mudança automática zonal | O AWS FIS experimento será cancelado e o deslocamento automático zonal será aplicado. |
| AWS FIS experimento | AWS FIS experimento | O AWS FIS experimento iniciado não será iniciado porque há um experimento em execução que acionou a ação de AWS FIS mudança automática. |
| Execução prática | Mudança manual de zona | A execução prática será cancelada, o resultado será definido como INTERRUPTED e a mudança de zona será aplicada. |
| Execução prática | AWS FIS experimento | A execução prática será cancelada, o resultado será definido como INTERRUPTED e o experimento do AWS FIS será aplicado. |
| Execução prática | Mudança automática zonal | A execução prática será cancelada, o resultado será definido como INTERRUPTED e a mudança automática de zona será aplicada. |
| Mudança manual de zona | Execução prática | A execução prática não será iniciada. |
| Mudança manual de zona | AWS FIS experimento | O AWS FIS experimento não será iniciado ou falhará se já estiver em andamento. |
| Mudança manual de zona | Mudança automática zonal | A mudança automática de zona será definida como ACTIVE, mas não como APPLIED, no recurso. A mudança manual de zona tem precedência. |
| Mudança automática zonal | AWS FIS experimento | O AWS FIS experimento não começará ou falhará se estiver em andamento. |
| Mudança automática zonal | Mudança manual de zona | A mudança automática de zona será definida como ACTIVE, mas não como APPLIED, no recurso. A mudança manual de zona tem precedência. |
| Mudança automática zonal | Execução prática | A execução prática não será iniciada, pois a mudança automática de zona tem precedência. |
A mudança de tráfego atualmente em vigor para o recurso tem um status de mudança de zona definido como `APPLIED`. Somente uma mudança é definida como `APPLIED` por vez. Outras mudanças que estão em andamento são definidas como `NOT_APPLIED`, mas permanecem com o status `ACTIVE`.
# Interromper uma mudança automática ativa ou uma execução prática de um recurso
Para interromper uma mudança automática em andamento para um recurso, você deve cancelar a mudança de zona.
As execuções práticas regulares ainda ocorrem para o recurso, no mesmo cronograma. Se quiser interromper as execuções práticas além de desabilitar as mudanças automáticas, será necessário excluir a configuração de execução prática associada ao recurso.
Quando você exclui uma configuração de execução prática, AWS interrompe a execução de execuções práticas que afastam o tráfego do recurso de uma zona de disponibilidade a cada semana. Além disso, como a mudança automática de zona exige execuções práticas, quando você exclui uma configuração de execução prática usando o console do ARC, essa ação também desativa a mudança automática de zona para o recurso. No entanto, observe que, se você usar a API de mudança automática de zona para excluir uma execução prática, primeiro desabilite a mudança automática de zona para o recurso.
Para obter mais informações, consulte [Cancelamento de uma mudança automática de zona](arc-zonal-autoshift.canceling-an-autoshift.md) e [Ativação e trabalho com a mudança automática de zona](arc-zonal-autoshift.start-cancel.md).
# Como o tráfego é transferido
Para mudanças automáticas e mudanças de zona para execuções práticas, o tráfego é movido para fora de uma zona de disponibilidade com o mesmo mecanismo que o ARC utiliza para mudanças de zona iniciadas pelo cliente. Se uma verificação de integridade for definida como não íntegra, o Amazon Route 53 retirará do DNS os endereços IP correspondentes ao recurso, de modo que o tráfego seja redirecionado da zona de disponibilidade. Em vez Região da AWS disso, novas conexões são roteadas para outras zonas de disponibilidade.
Com um deslocamento automático, quando uma zona de disponibilidade se recupera e AWS decide encerrar o deslocamento automático, o ARC reverte o processo de verificação de saúde, solicitando que as verificações de saúde do Route 53 sejam revertidas. Depois, os endereços IP de zona originais são restaurados e, se as verificações de integridade continuarem retornando o resultado "íntegra", a zona de disponibilidade será incluída novamente no roteamento da aplicação.
É importante estar ciente de que as mudanças automáticas não se baseiam em verificações de integridade que monitoram a integridade subjacente dos balanceadores de carga ou das aplicações. O ARC usa verificações de integridade para mover o tráfego para fora das zonas de disponibilidade, solicitando que as verificações de integridade sejam definidas como "não íntegras". Em seguida, ele restaura as verificações de integridade como normais novamente quando encerra uma mudança automática ou mudança de zona.
# Alarmes para execuções práticas
Você pode especificar dois tipos de CloudWatch alarmes para exercícios em deslocamento automático zonal: alarmes de resultado e alarmes de bloqueio.
**Alarmes de resultado (obrigatório)**
Para o primeiro tipo de alarme, o *alarme de resultado*, é necessário especificar pelo menos um alarme. Você deve configurar os alarmes de resultado para monitorar a integridade da aplicação quando o tráfego é movido para fora de uma zona de disponibilidade durante cada execução prática de 30 minutos.
Para que uma execução prática seja eficaz, especifique como alarmes de resultado pelo menos um CloudWatch alarme que atenda aos dois critérios a seguir:
O alarme monitora as métricas do recurso ou da sua aplicação
E
O alarme responde com o estado `ALARM` quando a aplicação é prejudicada pela perda de uma das zonas de disponibilidade.
Para obter mais informações, consulte a seção **Alarmes que você especifica para execuções práticas** em [Práticas recomendadas ao configurar a mudança automática de zona](arc-zonal-autoshift.considerations.md).
O alarme de resultado também fornece informações sobre o *resultado da execução prática* que o ARC reporta para cada execução prática. Se um alarme de resultado entrar no estado `ALARM`, o ARC encerrará a execução prática e retornará o resultado `FAILED`. Se a execução prática concluir o período de teste de 30 minutos e nenhum alarme de resultado especificado entrar no estado `ALARM`, o resultado retornado será `SUCCEEDED`. Uma lista de todos os valores de resultados, com descrições, é fornecida na seção [Resultados das execuções práticas](arc-zonal-autoshift.considerations.md#ZAConsiderationsPracticeRunOutcomes).
**Alarmes de bloqueio (opcional)**
Se desejar, você pode especificar um segundo tipo de alarme, o *alarme de bloqueio*. Os alarmes de bloqueio impedem o início ou a continuidade das execuções práticas quando um ou mais alarmes estão no estado `ALARM`. Esses alarmes impedem as mudanças de tráfego da execução prática e interrompem todas as execuções práticas em andamento, quando pelo menos um dos alarmes está no estado `ALARM`.
Por exemplo, em uma arquitetura grande com vários microsserviços, quando um microsserviço está enfrentando um problema, você normalmente deseja interromper todas as outras alterações no ambiente da aplicação, incluindo o bloqueio de execuções práticas. Você pode adicionar um alarme de bloqueio no ARC para fazer isso.
# Janelas bloqueadas e janelas permitidas (em UTC)
Você tem a opção de *bloquear* ou *permitir* as execuções práticas em datas específicas do calendário ou em janelas de tempo específicas, ou seja, dias e horários especificados em UTC.
Por exemplo, se você tiver uma atualização de aplicação agendada para ser lançada em 1.º de maio de 2024 e não quiser que as execuções práticas movam o tráfego naquele momento, poderá definir uma data de bloqueio para `2024-05-01`.
Por outro lado, digamos que você faça resumos de relatórios comerciais três dias por semana. Nesse cenário, você pode definir os seguintes dias e horários recorrentes como janelas bloqueadas, por exemplo, em UTC: `MON-20:30-21:30 WED-20:30-21:30 FRI-20:30-21:30`.
Como alternativa, você pode decidir que as quartas e sextas-feiras, do meio-dia às 5h, são os melhores horários para o ARC iniciar as execuções práticas para testar sua configuração. Nesse cenário, você pode definir os seguintes dias e horários recorrentes como janelas permitidas, por exemplo, em UTC: `WED-12:00-17:00 FRI-12:00-17:00`.