REL10-BP03 Automatizar a recuperação de componentes restritos a um único local
Se os componentes da workload só puderem ser executados em uma única zona de disponibilidade ou datacenter on-premises, você deverá implementar capacidade suficiente para fazer uma recompilação completa da workload em conformidade com os objetivos de recuperação definidos.
Nível de risco exposto se esta prática recomendada não é estabelecida: médio
Orientações para a implementação
Se a melhor prática para implantar a carga de trabalho em vários locais não for possível devido a restrições tecnológicas, você deverá implementar um caminho alternativo para a resiliência. Você deve automatizar a capacidade de recriar a infraestrutura necessária, reimplantar aplicativos e recriar os dados necessários para esses casos.
Por exemplo, o Amazon EMR executa todos os nós de um determinado cluster na mesma zona de disponibilidade, pois a execução de um cluster na mesma zona melhora a performance dos fluxos de trabalho, pois fornece uma taxa de acesso a dados mais alta. Se esse componente for necessário para a resiliência da workload, você deverá ter uma maneira de reimplantar o cluster e seus dados. Além disso, para o Amazon EMR, você deve provisionar redundância de maneiras diferentes de usar o Multi-AZ. Você pode provisionar vários nós. Usando o EMR File System (EMRFS), os dados no EMR podem ser armazenados no Amazon S3, que, por sua vez, podem ser replicados em várias zonas de disponibilidade ou Regiões da AWS.
Da mesma forma, o Amazon Redshift, por padrão, provisiona o cluster em uma zona de disponibilidade escolhida aleatoriamente dentro da Região da AWS selecionada. Todos os nós de cluster são provisionados na mesma zona.
Para workloads com estado baseadas em servidor e implantadas em um datacenter on-premises, é possível usar o AWS Elastic Disaster Recovery para proteger as workloads na AWS. Se você já estiver hospedado na AWS, poderá usar o Elastic Disaster Recovery para proteger a workload em uma zona de disponibilidade ou região alternativa. O Elastic Disaster Recovery usa a replicação contínua no nível de bloco para uma área de preparação leve visando fornecer recuperação rápida e confiável de aplicações on-premises e na nuvem.
Etapas da implementação
-
Implemente a autorreparação. Quando possível, use a escalabilidade automática para implantar instâncias ou contêineres. Quando não for possível, use a recuperação automática de instâncias do EC2 ou implemente a automação de autorreparação com base nos eventos de ciclo de vida do contêiner do Amazon EC2 ou do ECS.
-
Use os grupos do Amazon EC2 Auto Scaling para workloads de contêiner e instâncias que não têm requisitos para um endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados da instância.
-
Os dados do usuário do modelo de execução podem ser usados para implementar uma automação que pode recuperar automaticamente a maioria das workloads.
-
-
Use a recuperação automática de instâncias do Amazon EC2 para workloads que exijam um único endereço de ID da instância, endereço IP privado, endereço IP elástico e metadados da instância.
-
A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada.
-
-
Use os eventos do ciclo de vida da instância do Amazon EC2 ou os eventos do Amazon ECS para automatizar a autorreparação, em que não seja possível usar a escalabilidade automática ou a recuperação do EC2.
-
Use os eventos para chamar a automação que recuperará seu componente de acordo com a lógica do processo necessária.
-
-
Proteja workloads com estado que são limitadas a um único local usando o AWS Elastic Disaster Recovery.
-
Recursos
Documentos relacionados: