DR para a Plataforma de Dados do Azure - Recomendações

Lições aprendidas

1. Certifique-se de que todas as partes envolvidas entendam a diferença entre alta disponibilidade (HA) e recuperação de desastres (DR): uma armadilha comum é confundir os dois conceitos e incombinar as soluções associadas a eles.
2. Discuta com os stakeholders do negócio sobre suas expectativas em relação aos seguintes aspectos para definir os RPOs (objetivos de ponto de recuperação) e os RTOs (objetivos de tempo de recuperação:
   1. Quanto tempo de inatividade eles podem tolerar, tendo em mente que, geralmente, quanto mais rápida a recuperação, maior o custo.
   2. O tipo de incidentes dos quais eles querem ser protegidos, mencionando a probabilidade relacionada a tal evento. Por exemplo, a probabilidade de um servidor ficar inativo é maior do que um desastre natural que afeta todos os datacenters em uma região.
   3. Qual o impacto da indisponibilidade do sistema nos seus negócios?
   4. O orçamento de despesas operacionais (OPEX) para a solução no futuro.
3. Considere quais opções de serviço degradadas seus usuários finais podem aceitar. Isso pode incluir:
   1. Ainda ter acesso aos painéis de visualização mesmo sem os dados mais atualizados, ou seja, se os pipelines de ingestão não funcionarem, os usuários finais ainda terão acesso aos seus dados.
   2. Ter acesso de leitura, mas sem acesso de gravação.
4. As métricas de RTO e RPO de destino podem definir qual estratégia de recuperação de desastres você escolhe implementar:
   1. Ativo/Ativo.
   2. Ativo/Passivo.
   3. Ativo/Reimplantar em caso de desastre.
   4. Considere seu próprio SLO (objetivo de nível de serviço) composto para levar em consideração os tempos de inatividade toleráveis.
5. Verifique se você entendeu todos os componentes que podem afetar a disponibilidade dos seus sistemas, como:
   1. Gerenciamento de identidades.
   2. Topologia de rede.
   3. Gerenciamento de segredos/chaves.
   4. Fontes de dados.
   5. Automação/agendador de trabalhos.
   6. Repositório de origem e pipelines de implantação (GitHub, Azure DevOps).
6. A detecção precoce de interrupções também é uma maneira de diminuir significativamente os valores de RTO e RPO. Aqui estão alguns aspectos que devem ser abordados:
   1. Defina o que é uma interrupção e como ela é mapeada para a definição de interrupção da Microsoft. A definição da Microsoft está disponível na página Contrato de nível de serviço do Azure (SLA) no nível de produto ou serviço.
   2. Um sistema eficiente de monitoramento e alerta com equipes responsáveis para revisar essas métricas e alertas em tempo hábil ajuda a atingir a meta.
7. Em relação ao design da assinatura, a infraestrutura adicional para recuperação de desastres pode ser armazenada na assinatura original. Os serviços de PaaS (plataforma como serviço), como o Azure Data Lake Storage Gen2 ou o Azure Data Factory, normalmente têm recursos nativos que permitem o failover para instâncias secundárias em outras regiões, permanecendo contidos na assinatura original. Alguns clientes podem querer considerar ter um grupo de recursos dedicado para recursos usados apenas em cenários de DR para fins de custo.
   1. Deve-se notar que os limites de assinatura podem atuar como uma restrição para essa abordagem.
   2. Outras restrições podem incluir a complexidade do design e os controles de gerenciamento para garantir que os grupos de recursos de DR não sejam usados para fluxos de trabalho BAU (negócios como de costume).
8. Crie o fluxo de trabalho de DR com base na importância e nas dependências de uma solução. Por exemplo, não tente recompilar uma instância do Azure Analysis Services antes que seu data warehouse esteja em execução, pois isso dispara um erro. Saia dos laboratórios de desenvolvimento mais tarde no processo, recupere as principais soluções corporativas primeiro.
9. Tente identificar tarefas de recuperação que podem ser paralelizadas entre soluções, reduzindo o RTO total.
10. Se o Azure Data Factory for usado em uma solução, não se esqueça de incluir tempos de execução de integração auto-hospedados no escopo. O Azure Site Recovery é ideal para esses computadores.
11. As operações manuais devem ser automatizadas o máximo possível para evitar erros humanos, especialmente quando sob pressão. É recomendável:
    1. Adote o provisionamento de recursos por meio de modelos Bicep, ARM ou scripts do PowerShell.
    2. Adote o controle de versão do código-fonte e a configuração de recursos.
    3. Use pipelines de lançamento de CI/CD em vez de operações de clique.
12. Como você tem um plano de failover, considere os procedimentos para fazer fallback para as instâncias primárias.
13. Defina indicadores e métricas claros para validar se o failover foi bem-sucedido e se as soluções estão em execução ou se a situação voltou ao normal (também conhecido como funcional primário).
14. Decida se seus SLAs (contratos de nível de serviço) devem permanecer os mesmos após um failover ou se você permite um serviço degradado.
    1. Essa decisão dependerá muito do suporte do processo de serviço de negócios. Por exemplo, o failover para um sistema de reserva de salas será muito diferente de um sistema operacional principal.
15. Uma definição de RTO/RPO deve ser baseada em cenários de usuário específicos, e não no nível da infraestrutura. Isso lhe dará mais granularidade sobre quais processos e componentes devem ser recuperados primeiro se houver uma interrupção ou desastre.
16. Certifique-se de incluir verificações de capacidade na região de destino antes de avançar com um failover: se houver um grande desastre, lembre-se de que muitos clientes tentarão fazer failover para a mesma região emparelhada ao mesmo tempo, o que pode causar atrasos ou contenção no provisionamento dos recursos.
    1. Se esses riscos forem inaceitáveis, uma estratégia de DR Ativa/Ativa ou Ativa/Passiva deve ser considerada.
17. Um plano de recuperação de desastres deve ser criado e mantido para documentar o processo de recuperação e os proprietários da ação. Além disso, considere que as pessoas podem estar de licença, portanto, certifique-se de incluir contatos secundários.
18. Exercícios regulares de recuperação de desastres devem ser realizados para validar o fluxo de trabalho do plano de DR, se ele atende ao RTO/RPO necessário e para treinar as equipes responsáveis.
    1. Os backups de dados e configuração também devem ser testados regularmente para garantir que estejam "adequados à finalidade" para dar suporte a quaisquer atividades de recuperação.
19. A colaboração antecipada com equipes responsáveis pela rede, identidade e provisionamento de recursos permitirá um acordo sobre a solução mais ideal em relação a:
    1. Como redirecionar usuários e tráfego do site primário para o secundário. Conceitos como redirecionamento de DNS ou o uso de ferramentas específicas, como o Gerenciador de Tráfego do Azure, podem ser avaliados.
    2. Como fornecer acesso e direitos ao site secundário de maneira oportuna e segura.
20. Durante um desastre, a comunicação eficaz entre as muitas partes envolvidas é fundamental para a execução eficiente e rápida do plano. As equipes podem incluir:
    1. Decisores.
    2. Equipe de resposta a incidentes.
    3. Usuários e equipes internas afetadas.
    4. Equipes externas.
21. A orquestração dos diferentes recursos no momento certo garantirá a eficiência na execução do plano de recuperação de desastres.

Considerações

Antipadrões

• Copiar/colar esta série de artigos Esta série de artigos destina-se a fornecer diretrizes aos clientes que procuram o próximo nível de detalhes para um processo de DR específico do Azure. Como tal, ela se baseia no IP genérico da Microsoft e nas arquiteturas de referência, e não em qualquer implementação do Azure específica do cliente.

Embora os detalhes fornecidos ajudem a dar suporte a um bom entendimento fundamental, os clientes devem aplicar seu próprio contexto, implementação e requisitos específicos antes de obter uma estratégia e um processo de DR "adequados ao propósito".

• Tratar a DR como um processo somente de tecnologia Os stakeholders de negócios desempenham um papel crítico na definição dos requisitos para DR e na conclusão das etapas de validação de negócios necessárias para confirmar uma recuperação de serviço. Garantir que os stakeholders de negócios estejam envolvidos em todas as atividades de DR proporcionará um processo de DR que seja "adequado ao propósito", represente valor comercial e seja executável.

• Planos de DR "Definir e esquecer" O Azure está em constante evolução, assim como o uso de vários componentes e serviços por clientes individuais. Um processo de DR "adequado ao propósito" deve evoluir com eles. Seja por meio do processo de ciclo de vida de desenvolvimento de software (SDLC) ou revisões periódicas, os clientes devem revisitar regularmente seu plano de DR. O objetivo é garantir a validade do plano de recuperação do serviço e que quaisquer deltas entre componentes, serviços ou soluções tenham sido contabilizados.

• Avaliações baseadas em papel Embora a simulação de ponta a ponta de um evento de DR seja difícil em um ecossistema de dados moderno, esforços devem ser feitos para chegar o mais próximo possível de uma simulação completa em todos os componentes afetados. Exercícios programados regularmente construirão a "memória muscular" exigida pela organização para poder executar o plano de DR com confiança.

• Confiar na Microsoft para fazer tudo Nos serviços do Microsoft Azure, há uma clara divisão de responsabilidade, ancorada pela camada de serviço de nuvem usada: Mesmo que uma pilha completa de software como serviço (SaaS) seja usada, o cliente ainda manterá a responsabilidade de garantir que as contas, as identidades e os dados estejam corretos/atualizados, além dos dispositivos usados para interagir com os serviços do Azure.

Escopo e estratégia do evento

Escopo do evento de desastre

Eventos diferentes terão um escopo de impacto diferente e, portanto, uma resposta diferente. O diagrama a seguir ilustra isso para um evento de desastre:

Opções de estratégia de desastres

Há quatro opções de alto nível para uma estratégia de recuperação de desastres:

• Esperar pela Microsoft - Como o nome sugere, a solução fica offline até a recuperação completa dos serviços na região afetada pela Microsoft. Uma vez recuperada, a solução é validada pelo cliente e, em seguida, atualizada para recuperação do serviço.
• Reimplantar em caso de desastre - A solução é reimplantada manualmente em uma região disponível do zero, evento pós-desastre.
• Reposição morna (ativo/passivo) - Uma solução hospedada secundária é criada em uma região alternativa e componentes são implantados para garantir a capacidade mínima; no entanto, os componentes não recebem tráfego de produção. Os serviços secundários na região alternativa podem ser "desativados" ou executados em um nível de desempenho inferior até que ocorra um evento de DR.
• Reposição quente (Ativo/Ativo) - A solução é hospedada em uma configuração ativa/ativa em várias regiões. A solução hospedada secundária recebe, processa e fornece dados como parte do sistema maior.

Impactos da estratégia de DR

Embora o custo operacional atribuído aos níveis mais altos de resiliência de serviço geralmente domine as Principais decisões de design (KDD) para uma estratégia de DR. Há outras considerações importantes.

O cenário de DR para este exemplo trabalhado é uma interrupção regional completa do Azure que afeta diretamente a região primária que hospeda a Contoso Data Platform. Para esse cenário de paralisação, o impacto relativo nas quatro estratégias de DR de alto nível são:

Chave de classificação

• RTO (objetivo de tempo de recuperação): o tempo decorrido esperado desde o evento de desastre até a recuperação do serviço de plataforma.
• Complexidade a ser executada: a complexidade para a organização executar as atividades de recuperação.
• Complexidade a ser implementada: a complexidade para a organização implementar a estratégia de DR.
• Impacto para os clientes: o impacto direto para os clientes do serviço de plataforma de dados da estratégia de DR.
• Custo OPEX acima da linha: o custo extra esperado da implementação dessa estratégia, como o aumento da cobrança mensal do Azure para componentes adicionais e recursos adicionais necessários para dar suporte.

Próximas etapas

Agora que você aprendeu sobre as recomendações relacionadas aos ao cenário, saiba mais sobre como implantar esse cenário

Recursos relacionados

• DR para a Plataforma de Dados do Azure - Visão geral
• DR para a Plataforma de Dados do Azure - Arquitetura
• DR para a Plataforma de Dados do Azure - Detalhes de cenário
• DR para a Plataforma de Dados do Azure – Resumo