# REL11-BP04 Confiar no plano de dados e não no ambiente de gerenciamento durante a recuperação Os ambientes de gerenciamento fornecem as APIs administrativas usadas para criar, ler e descrever, atualizar, excluir e listar recursos (CRUDL), enquanto os planos de dados lidam com o tráfego diário de serviços. Ao implementar respostas de recuperação ou mitigação a eventos potencialmente impactantes na resiliência, concentre-se em usar um número mínimo de operações do ambiente de gerenciamento para recuperar, redimensionar, restaurar, reparar ou realizar o failover do serviço. A ação do plano de dados deve substituir qualquer atividade durante esses eventos de degradação. Por exemplo, estas são ações do ambiente de gerenciamento: iniciar uma nova instância de computação, criar armazenamento em bloco e descrever serviços de fila. Quando você executa instâncias de computação, o ambiente de gerenciamento precisa realizar várias tarefas, como encontrar um host físico com capacidade, alocar interfaces de rede, preparar volumes de armazenamento em blocos locais, gerar credenciais e adicionar regras de segurança. Os ambientes de gerenciamento tendem a ser uma orquestração complicada. **Resultado desejado:** Quando um recurso entra em um estado comprometido, o sistema é capaz de se recuperar automática ou manualmente, transferindo o tráfego de recursos danificados para recursos saudáveis. **Antipadrões comuns:** + Dependência da alteração dos registros DNS para redirecionar o tráfego. + Dependência das operações de escalonamento do ambiente de gerenciamento para substituir componentes danificados devido a recursos insuficientemente provisionados. + Dependência de ações de ambiente de gerenciamento abrangentes, com vários serviços e várias APIs para remediar qualquer categoria de deficiência. **Benefícios de estabelecer esta prática recomendada:** O aumento da taxa de sucesso da remediação automatizada pode reduzir seu tempo médio de recuperação e melhorar a disponibilidade da workload. **Nível de risco exposto se esta prática recomendada não for estabelecida:** médio: para certos tipos de degradação do serviço, os ambientes de gerenciamento são afetados. As dependências do uso extensivo do ambiente de gerenciamento para remediação podem aumentar o tempo de recuperação (RTO) e o tempo médio de recuperação (MTTR). ## Orientação para implementação Para limitar as ações do plano de dados, avalie cada serviço quanto às ações necessárias para restaurar o serviço. Use o Amazon Application Recovery Controller (ARC) para mudar o tráfego de DNS. Esses recursos monitoram continuamente a capacidade da aplicação de se recuperar de falhas, permitindo que você controle a recuperação da aplicação em várias Regiões da AWS, Zonas de Disponibilidade e ambientes on-premises. As políticas de roteamento do Route 53 usam o ambiente de gerenciamento. Portanto, não confie nele para recuperação. Os planos de dados do Route 53 respondem as consultas ao DNS, além de realizarem e avaliarem verificações de integridade. Eles são distribuídos globalmente e projetados para um [Acordo de Serviço (SLA) de 100% de disponibilidade](https://aws.amazon.com/route53/sla/). As APIs e consoles de gerenciamento do Route 53 usados para criar, atualizar e excluir recursos do Route 53 são executados em ambientes de gerenciamento projetados para priorizar a consistência e a durabilidade necessária para gerenciar o DNS. Para que isso aconteça, os ambientes de gerenciamento estão localizados em uma única região: Leste dos EUA (Norte da Virgínia). Embora ambos os sistemas sejam construídos para serem muito confiáveis, os ambientes de gerenciamento não estão incluídos no SLA. Pode ser que ocorram raros eventos onde o design resiliente do plano de dados permita que ele mantenha a disponibilidade, enquanto os ambientes de gerenciamento não. Para mecanismos de recuperação de desastres e failover, use funções de plano de dados para fornecer a melhor confiabilidade possível. Para o Amazon EC2, use designs de estabilidade estática para limitar as ações do ambiente de gerenciamento. As ações do ambiente de gerenciamento incluem a ampliação de recursos individualmente ou usando grupos do Auto Scaling (ASG). Para obter os níveis mais altos de resiliência, provisione capacidade suficiente no cluster usado para failover. Se essa capacidade precisar ser limitada, defina valores no sistema geral completo para definir com segurança o tráfego total que atinge o conjunto limitado de recursos. Para serviços como Amazon DynamoDB, Amazon API Gateway, balanceadores de carga e AWS Lambda sem servidor, o uso aproveita o plano de dados. No entanto, criar novas funções, balanceadores de carga, gateways de API ou tabelas de DynamoDB é uma ação do ambiente de gerenciamento e deve ser concluída antes da degradação, como preparação para um evento e ensaio das ações de failover. Para o Amazon RDS, as ações do plano de dados permitem o acesso aos dados. Para obter mais informações sobre planos de dados, ambientes de gerenciamento e como a AWS cria serviços para atender metas de alta disponibilidade, consulte [Estabilidade estática usando Zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/). Entenda quais operações estão no plano de dados e quais estão no ambiente de gerenciamento. ### Etapas da implementação Para cada workload que precisa ser restaurada após um evento de degradação, avalie o runbook de failover, o projeto de alta disponibilidade, o projeto de recuperação automática ou o plano de restauração de recursos de HA. Identifique cada ação que pode ser considerada uma ação do ambiente de gerenciamento. Considere alterar a ação de gerenciamento para uma ação do plano de dados: + Auto Scaling (ambiente de gerenciamento) em comparação com recursos do Amazon EC2 pré-escalados (plano de dados) + Migre para Lambda e seus métodos de escalabilidade (plano de dados) ou Amazon EC2 e ASG (ambiente de gerenciamento) + Avalie qualquer projeto usando o Kubernetes e a natureza das ações do ambiente de gerenciamento. Adicionar pods é uma ação do plano de dados no Kubernetes. As ações devem se limitar à adição de pods e não adição de nós. O uso de [nós com provisionamento excessivo](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) é o método preferido para limitar as ações do ambiente de gerenciamento Considere abordagens alternativas que permitam que as ações do plano de dados afetem a mesma remediação. + Alteração de registro Route 53 (ambiente de gerenciamento) ou ARC (plano de dados) + [ Verificações de integridade do Route 53 para atualizações mais automatizadas ](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) Se o serviço for essencial, considere alguns serviços em uma região secundária para permitir mais ações no ambiente de gerenciamento e no plano de dados em uma região não afetada. + Amazon EC2 Auto Scaling ou Amazon EKS em uma região primária em comparação com Amazon EC2 Auto Scaling ou Amazon EKS em uma região secundária e roteando o tráfego para a região secundária (ação do ambiente de gerenciamento). + Faça uma réplica de leitura na primária secundária ou tente a mesma ação na região primária (ação do ambiente de gerenciamento). ## Recursos **Práticas recomendadas relacionadas:** + [Definição de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) + [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html) **Documentos relacionados:** + [Parceiro da APN: parceiros que podem ajudar na automação da sua tolerância a falhas](https://aws.amazon.com/partners/find/results/?keyword=automation) + [AWS Marketplace: produtos que podem ser usados para tolerância a falhas](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) + [Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [API do Amazon DynamoDB (ambiente de gerenciamento e plano de dados)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html) + [Execuções do AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (divididas entre o ambiente de gerenciamento e o plano de dados) + [Plano de dados do AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) + [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [Criação de mecanismos de recuperação de desastres usando o Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) + [O que é o Route 53 Application Recovery Controller?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) + [ Ambiente de gerenciamento e plano de dados do Kubernetes ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/) **Vídeos relacionados:** + [ Back to Basics - Using Static Stability (De volta ao básico: uso da estabilidade estática) ](https://www.youtube.com/watch?v=gy1RITZ7N7s) + [ Building resilient multi-site workloads using AWS global services (Criação de workloads resilientes em vários sites usando serviços globais da AWS) ](https://www.youtube.com/watch?v=62ZQHTruBnk) **Exemplos relacionados:** + [Introdução ao Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) + [ Amazon Builders’ Library: evite a sobrecarga em sistemas distribuídos colocando o menor serviço no controle ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/) + [ Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 1: pilha de região única ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/) + [ Criação de aplicações altamente resilientes usando o Amazon Route 53 Application Recovery Controller, parte 2: pilha multirregional ](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/) + [ Estabilidade estática usando Zonas de disponibilidade ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) **Ferramentas relacionadas:** + [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/) + [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)