Ambientes de gerenciamento e planos de dados - Padrões de resiliência multi-AZ avançados

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

Ambientes de gerenciamento e planos de dados

Antes de chegarmos aos padrões reais que você pode usar para realizar a evacuação de uma zona de disponibilidade, precisamos discutir os conceitos de ambientes de gerenciamento e planos de dados. AWS faz uma distinção entre ambientes de gerenciamento e planos de dados em nossos serviços. Os ambientes de gerenciamento são o mecanismo envolvido em fazer alterações em um sistema — adicionar recursos, excluir recursos, modificar recursos — e fazer com que essas alterações sejam propagadas para onde devam entrar em vigor, como atualizar uma configuração de rede para um ALB ou criar uma função de AWS Lambda.

Os planos de dados são a função principal desses recursos, como por exemplo, executar uma instância do EC2 ou obter itens de uma tabela do Amazon DynamoDB ou colocar itens na tabela. Para uma discussão mais detalhada sobre ambientes de gerenciamento e planos de dados, consulte Estabilidade estática usando zonas de disponibilidade e Limites de isolamento de falhas AWS.

Para os fins deste documento, considere que os ambientes de gerenciamento tendem a ter mais partes móveis e dependências que os planos de dados. Isso torna estatisticamente mais provável que o ambiente de gerenciamento fique prejudicado em comparação com o plano de dados. Isso é especialmente relevante para serviços que fornecem AZI, como Amazon EC2 e EBS, porque partes desses serviços têm ambientes de gerenciamento que também são independentes de zona e podem ser afetados durante um evento em uma única ZD.

Embora as ações do ambiente de gerenciamento possam ser usadas para realizar a evacuação da ZD, com base nas informações anteriores, elas podem ter uma probabilidade menor de sucesso, especialmente durante um evento de falha. Para aumentar a probabilidade de mitigar o impacto com sucesso, você pode usar dois padrões diferentes. O primeiro padrão depende apenas das ações do plano de dados para mitigar inicialmente o impacto, impedindo que o trabalho seja encaminhado ou impedindo que o trabalho seja feito na zona de disponibilidade afetada. Em seguida, pode-se tentar o segundo padrão para atualizar a configuração dos recursos com ações do ambiente de gerenciamento para impedir que a capacidade seja provisionada na zona de disponibilidade afetada, bem como interromper a comunicação entre zonas de disponibilidade com a zona de disponibilidade afetada.

Os padrões de recuperação discutidos nesta seção são grandes alertas vermelhos. Eles são os mecanismos que você usará para realizar ações em grande escala, rapidamente, semelhantes a puxar um cabo Andon em uma linha de montagem. Tais mecanismos assumem que os workloads já tentaram estratégias como tentar novamente com recuo exponencial com jitter no código para superar erros transitórios. Isso significa que, quando um impacto isolado na zona de disponibilidade é detectado, seus efeitos na disponibilidade ou na latência são graves o suficiente para exigir a evacuação da zona de disponibilidade para uma mitigação eficaz.