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 da empresa sobre suas expectativas em relação aos seguintes aspetos para definir os RPOs (Recovery Point Objetives, objetivos de ponto de recuperação) e RTO (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 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. Confie no SLA da Microsoft
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 redes
   3. Gestão de segredos/chaves
   4. Origens 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 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 ajudará a atingir a meta
7. SLAs compostos significam que quanto mais componentes você tiver em sua arquitetura, maior a probabilidade de uma falha. Você pode usar o SLA composto para definir as chances de uma interrupção de componente.
8. Em relação ao design da assinatura, a infraestrutura adicional para recuperação de desastres pode ser armazenada na assinatura original. Serviços de PaaS como ADLS Gen2 ou 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 BAU
9. Projete o fluxo de trabalho de DR com base na criticidade e nas dependências de uma solução. Por exemplo, não tente recriar uma instância do Azure Analysis Services antes que seu data warehouse esteja instalado e em execução, pois isso acionará um erro. Deixe os laboratórios de desenvolvimento mais tarde no processo, recupere as principais soluções corporativas primeiro
10. Tente identificar tarefas de recuperação que possam ser paralelizadas entre soluções, reduzindo o RTO total
11. 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
12. 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 controle de versão do código-fonte e a configuração de recursos
    3. Use pipelines de liberação de CI/CD em vez de click-ops
13. Como você tem um plano para failover, deve considerar procedimentos para fallback para as instâncias principais
14. Definir indicadores/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)
15. Decida se seus 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 para um sistema de reserva de quartos será muito diferente de um sistema operacional principal
16. Uma definição de RTO/RPO deve basear-se em cenários/soluções de utilizadores específicos e não ao nível da infraestrutura. Ele lhe dará mais granularidade sobre quais processos e componentes devem ser recuperados primeiro se houver uma interrupção ou desastre
17. 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
18. 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
19. 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
20. 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 Azure Traffic Manager , podem ser avaliados
    2. Como fornecer acesso e direitos ao site secundário de forma atempada e segura
21. Durante um desastre, a comunicação eficaz entre as muitas partes envolvidas é fundamental para a execução eficiente e rápida do plano:
    1. Decisores
    2. Equipa de resposta a incidentes
    3. Público interno impactado
    4. Equipas externas
22. 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

Anti-padrõ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. Seja por meio do processo 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 Dentro dos 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 SaaS completa 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 ser "desligados" ou executados em um nível de desempenho mais baixo até que ocorra um evento 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 entre o evento de desastre e a recuperação do serviço da plataforma
• Complexidade a ser executada – 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 desta estratégia, como o aumento da faturação mensal do Azure para componentes adicionais e recursos adicionais necessários para suportar

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