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á.
Padrões de evacuação da zona de disponibilidade
Depois de detectar o impacto em uma única zona de disponibilidade, a próxima etapa é evacuar essa zona de disponibilidade. A evacuação precisa alcançar dois resultados.
Primeiro, você deve parar de enviar trabalhos para a zona de disponibilidade afetada. Isso pode ter significados diferentes em arquiteturas diferentes. Em um workload de solicitação/resposta, isso significaria impedir que solicitações HTTP ou gRPC provenientes de seus clientes fossem enviadas para o balanceador de carga ou outros recursos na zona de disponibilidade. Em um sistema de processamento em lote ou em filas, isso pode significar impedir que os recursos computacionais processem o trabalho na zona de disponibilidade afetada. Você também precisará evitar que recursos nas zonas de disponibilidade não afetadas interajam com recursos na zona de disponibilidade afetada, por exemplo, uma instância do EC2 enviando tráfego para um endpoint da VPC de interface na zona de disponibilidade afetada ou se conectando à instância primária de um banco de dados.
O segundo resultado é impedir que novas capacidades sejam provisionadas na zona de disponibilidade afetada. Isso é importante porque provavelmente os novos recursos, como instâncias do EC2 ou contêineres, que foram provisionados na zona de disponibilidade afetada, terão o mesmo impacto que os recursos existentes. Além disso, como o primeiro resultado impede que o trabalho seja enviado para esses novos recursos, eles não conseguem absorver a carga para a qual foram provisionados. Isso leva ao aumento da carga sobre os recursos existentes, o que pode, em última instância, levar ao apagão ou à indisponibilidade total do workload. Há vários serviços de ajuste de escala automático disponíveis em AWS onde isso se aplica: Amazon EC2 Auto Scaling
Tópicos
