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

Lições aprendidas

1. Garantir 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 descombinar as soluções associadas a eles.
2. Discuta com as partes interessadas do negócio sobre suas expectativas em relação aos seguintes aspetos para definir os RPOs (Recovery Point Objetives, objetivos de ponto de recuperação) e RTOs (Recovery Time Objetives, 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 contra os quais querem ser protegidos, mencionando a probabilidade relacionada de tal evento. Por exemplo, a probabilidade de um servidor ficar inativo é maior do que um desastre natural que afeta todos os datacenters de uma região.
   3. Que impacto o facto de o sistema estar indisponível tem 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. Estes podem incluir:
   1. Ainda tendo 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. Suas 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 objetivo de nível de serviço composto (SLO) para considerar os tempos de inatividade toleráveis.
5. Certifique-se de entender todos os componentes que podem afetar a disponibilidade de seus sistemas, como:
   1. Gestão de identidades.
   2. Topologia de rede.
   3. Gestão de segredos/chaves.
   4. Origem de dados.
   5. Automação/agendador de tarefas.
   6. Repositório de origem e pipelines de implantação (GitHub, Azure DevOps).
6. A deteção precoce de interrupções também é uma maneira de diminuir significativamente os valores de RTO e RPO. Aqui estão alguns aspetos que devem ser cobertos:
   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 SLA (contrato de nível de serviço) do Azure no nível do 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 plataforma como serviço (PaaS), como o Azure Data Lake Storage Gen2 ou o Azure Data Factory, normalmente têm recursos nativos que permitem 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. Note-se que os limites de subscrição podem funcionar como uma restrição para esta abordagem.
   2. Outras restrições podem incluir a complexidade do projeto e os controles de gerenciamento para garantir que os grupos de recursos de DR não sejam usados para fluxos de trabalho de negócios como de costume (BAU).
8. Projete o fluxo de trabalho de DR com base na criticidade e nas dependências de uma solução. Por exemplo, não tente reconstruir uma instância do Azure Analysis Services antes que seu data warehouse esteja instalado e em execução, pois isso dispara um erro. Saia dos laboratórios de desenvolvimento mais tarde no processo, recupere primeiro as principais soluções empresariais.
9. Tente identificar tarefas de recuperação que possam 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 essas máquinas.
11. As operações manuais devem ser automatizadas tanto quanto possível para evitar erros humanos, especialmente quando sob pressão. Recomenda-se:
    1. Adote o provisionamento de recursos por meio de Bicep, modelos ARM ou scripts do PowerShell.
    2. Adote o versionamento do código-fonte e a configuração de recursos.
    3. Use pipelines de liberação de CI/CD em vez de click-ops.
12. Como você tem um plano para failover, deve considerar procedimentos para fallback para as instâncias principais.
13. Defina indicadores e métricas claras para validar que o failover foi bem-sucedido e as soluções estão funcionando ou que a situação está de volta ao normal (também conhecido como funcional principal).
14. Decida se seus contratos de nível de serviço (SLAs) devem permanecer os mesmos após um failover ou se você permite um serviço degradado.
    1. Essa decisão dependerá muito do processo de serviço comercial que está sendo suportado. Por exemplo, o failover de um sistema de reserva de quartos 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 desastre de grandes proporções, 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 estes riscos forem inaceitáveis, deve ser considerada uma estratégia de DR Ativa/Ativa ou Ativa/Passiva.
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, por isso 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, para que ele atenda ao RTO/RPO necessário e para treinar as equipes responsáveis.
    1. Os backups de dados e configurações também devem ser testados regularmente para garantir que sejam "adequados à finalidade" para dar suporte a quaisquer atividades de recuperação.
19. A colaboração antecipada com as equipes responsáveis pela rede, identidade e provisionamento de recursos permitirá chegar a um acordo sobre a solução mais ideal em relação a:
    1. Como redirecionar usuários e tráfego do site principal 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 forma 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 equipas podem incluir:
    1. Decisores.
    2. Equipa de resposta a incidentes.
    3. Usuários internos e equipes afetados.
    4. Equipas 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 orientação aos clientes que procuram o próximo nível de detalhe para um processo de DR específico do Azure. Como tal, baseia-se no IP genérico da Microsoft e nas arquiteturas de referência, em vez de qualquer implementação do Azure específica do cliente.

Embora os detalhes fornecidos ajudem a apoiar uma sólida compreensão 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 à finalidade".

• Tratando a DR como um processo somente de tecnologia As partes interessadas de negócios desempenham um papel crítico na definição dos requisitos de 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 as partes interessadas do negócio estejam envolvidas em todas as atividades de DR fornecerá 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 à finalidade" deve evoluir com eles. Por meio do processo de ciclo de vida de desenvolvimento de software (SDLC) ou de revisões periódicas, os clientes devem rever regularmente seu plano de DR. O objetivo é garantir a validade do plano de recuperação de serviços e que quaisquer deltas entre componentes, serviços ou soluções tenham sido contabilizados.

• Avaliações 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 perto possível de uma simulação completa entre os componentes afetados. Treinos programados regularmente irão construir a "memória muscular" exigida pela organização para poder executar o plano de DR com confiança.

• Confiando 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, identidades e dados estejam corretos/atualizados, juntamente com os dispositivos usados para interagir com os serviços do Azure.

Âmbito e estratégia do evento

Escopo do evento de desastre

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

Opções de estratégia para catástrofes

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

• Aguarde 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.
• Warm Spare (Ativo/Passivo) - Uma solução hospedada secundária é criada em uma região alternativa e os componentes são implantados para garantir uma 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 estar "desligados" ou em execução em um nível de desempenho mais baixo até que ocorra um evento de DR.
• Hot Spare (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 serve 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 a Decisão de Design Chave (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 Plataforma de Dados Contoso. Para este cenário de interrupção, o impacto relativo nas quatro estratégias de DR de alto nível são:

Chave de classificação

• RTO (Recovery Time Objetive, objetivo de tempo de recuperação): o tempo esperado decorrido entre o evento de desastre e a recuperação do serviço de plataforma.
• Complexidade a executar: A complexidade para a organização executar as atividades de recuperação.
• Complexidade a implementar: 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 da 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 por componentes adicionais e recursos adicionais necessários para dar suporte.

Próximos passos

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

Recursos relacionados

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