Fase 10: Projetar alta disponibilidade e recuperação de desastres

Nesta fase, você desenvolve estratégias de alta disponibilidade (HA) e recuperação de desastres (DR) para garantir a continuidade e a resiliência dos negócios.

Alta disponibilidade (HA) e recuperação de desastres (DR) são aspectos importantes do lakehouse, e muitas organizações implementam ambos para colocar em produção casos de uso críticos no Databricks.

Projetar uma estratégia de alta disponibilidade

Alta disponibilidade é a capacidade de se recuperar de uma interrupção que afeta uma única zona cloud com impacto mínimo e de forma transparente para os usuários. É medido como tempo de atividade consistente ou percentagem de tempo de atividade (SLA), com recuperação normalmente em segundos ou minutos.

Alta disponibilidade do plano de controle

O plano de controle Databricks consiste em dezenas de serviços, desde hospedagem e autenticação de front-end até gerenciamento cluster e implantação endpoint . No início de 2025, os serviços principais do plano de controle seriam multizonais, o que significa que, se uma única zona dentro de uma região cloud falhasse, o plano de controle poderia recuperar esses serviços em outra zona e continuar operando.

Características do plano de controle HA

• Failover automático : o serviço alterna automaticamente para zonas íntegras durante o failover.
• Tempo de recuperação de 15 minutos : A recuperação em caso de falha geralmente é concluída em 15 minutos.
• 0 RPO : Sem perda de dados durante falhas zonais.
• Cobertura multizona : Funciona para regiões cloud com várias zonas de disponibilidade.

nota

Isso não se aplica a regiões cloud com uma única zona. Em regiões de zona única, uma interrupção zonal é equivalente a uma interrupção regional.

alta disponibilidade do plano de computação

Alta disponibilidade compute clássica

• Implante sub-redes workspace em pelo menos 2 zonas de disponibilidade (recomendado: 3).
• O Databricks distribui automaticamente os nós do cluster entre as zonas de disponibilidade.
• Configure novas tentativas de tarefas com recuo exponencial para falhas transitórias.
• Monitore a integridade da zona de disponibilidade e redistribua as cargas de trabalho durante a degradação da zona.

compute sem servidor de alta disponibilidade

• compute sem servidor fornece automaticamente failover em várias zonas.
• Nenhuma configuração adicional é necessária.
• Redistribui automaticamente as cargas de trabalho durante falhas de zona.

Melhores práticas para alta disponibilidade compute

• Utilize compute serverless para failover automático em várias zonas.
• Para compute clássica, assegure-se de que as sub-redes abranjam várias zonas de disponibilidade.
• Configure novas tentativas automáticas de tarefas para falhas transitórias.
• Teste os procedimentos de failover regularmente para validar as configurações de alta disponibilidade.
• Monitorar as métricas de saúde da zona e ajustar o planejamento de capacidade de acordo.

Elabore uma estratégia de recuperação de desastres.

A recuperação de desastres é a capacidade de se recuperar de uma interrupção que afeta toda uma região cloud e continuar as operações comerciais em uma região secundária. É medido pelo tempo de inatividade aceitável (RTO) e pela perda de dados (RPO), normalmente em horas.

Considerações sobre recuperação de desastres por camada

É necessário considerar a recuperação de desastres em todas as camadas de uma plataforma de dados:

Clientes

• Os clientes devem poder mudar para os URLs workspace de failover.
• Atualize as configurações de DNS ou balanceador de carga para failover automático.

Objetos de código e workspace

• Utilize IaC/Terraform para implantar a infraestrutura da plataforma.
• Utilize controle de versão para todo o código, como por exemplo, um Notebook.
• implantado em ambos os sites usando CI/CD.
• Automatize a implantação na região secundária.

Identidades

• Usuários, entidade de serviço, grupos.
• Utilize a sincronização SCIM no nível account .
• A federação de identidades garante acesso consistente em todas as regiões.

Unity Catalog

• Terraform ou scripts para implantar ou copiar a infraestrutura Unity Catalog .
• Terraform ou scripts para copiar metadados (definições de tabelas, ACLs, etc.).
• Terraform ou scripts para copiar a configuração Delta Sharing .
• implantar metastores tanto nas regiões primárias quanto nas secundárias.

Dados

• Dados externos e gerenciamento de dados : Replicação geo-redundante (por exemplo, dados brutos, fonte de dados).
• Tabelas Delta : Clonagem profunda Delta para replicar tabelas entre regiões.
• Zonas de aterrissagem : Replicar dados da zona de aterrissagem para a região secundária.

ponto final

• As informações dos pontos de verificação precisam ser sincronizadas entre as regiões.
• Configure gravações duplas ou replicação de ponto de verificação.

Padrões de projeto de DR

DR ativa-passiva

• A região principal atende todo o tráfego de produção.
• Região secundária em modo de espera para failover.
• Os dados são replicados periodicamente (por exemplo, a cada hora, diariamente).
• Reversão manual ou automática em caso de falha da região primária.

DR ativa-ativa

• Ambas as regiões atendem ao tráfego de produção.
• Dados replicados continuamente ou em tempo real próximo ao tempo real.
• Distribuição de carga equilibrada entre as regiões.
• Custo mais elevado, mas melhor desempenho e RTO (tempo de recuperação).

Fazer backup e restaurar

• Cópias de segurança regulares para uma região secundária.
• Processo de restauração manual em caso de falha na região primária.
• Custo mais baixo, porém com RTO e RPO mais altos.
• Adequado para cargas de trabalho não críticas.

Defina os requisitos de RTO e RPO.

Objetivo de Tempo de Recuperação (RTO)

• Por quanto tempo a empresa pode tolerar períodos de inatividade?
• Determina os requisitos de automação de failover.
• Influencia o investimento em infraestrutura.

Objetivo de Ponto de Recuperação (RPO)

• Qual o nível aceitável de perda de dados?
• Determina a frequência de replicação.
• Influencia a estratégia de backup e replicação.

Exemplos de requisitos de RTO/RPO

• Cargas de trabalho críticas : RTO < 1 hora, RPO < 15 minutos (ativo-ativo ou ativo-passivo com replicação contínua).
• Cargas de trabalho importantes : RTO < 4 horas, RPO < 1 hora (ativo-passivo com replicação horária).
• Cargas de trabalho padrão : RTO < 24 horas, RPO < 24 horas (backup e restauração).

Desenhar uma estratégia de teste de DR

Os procedimentos de radiologia diagnóstica devem ser testados regularmente para garantir que funcionem quando necessário. Elabore uma estratégia de teste de recuperação de desastres (DR) adequada aos seus requisitos de RTO/RPO.

padrões de teste DR

• Testes trimestrais de recuperação de desastres : failover completo para a região secundária, validação de todos os sistemas.
• Validação mensal do manual de procedimentos : Revisar e atualizar os procedimentos de recuperação de desastres.
• Testes automatizados contínuos : Teste componentes individuais regularmente.
• Exercícios de simulação : Simule cenários de recuperação de desastres com as partes interessadas.

Melhores práticas para testes de DR

• Documente planos de recuperação de desastres detalhados com procedimentos passo a passo.
• Realizar testes de DR fora dos horários de pico.
• Valide a integridade dos dados após o failover.
• Meça o RTO e o RPO reais durante os testes.
• Atualizar procedimentos com base nos resultados dos testes.
• ensinar as equipes de transporte sobre procedimentos de DR.

Recomendações de HA e DR

Recomendado

• Utilize IaC (Terraform) para implantar infraestrutura tanto nas regiões primárias quanto nas secundárias.
• Implantação compute clássica em múltiplas zonas de disponibilidade para alta disponibilidade.
• Utilize compute serverless para failover automático em várias zonas.
• Implementar replicação geo-redundante para dados brutos e fonte de dados.
• Utilize o Delta Deep Clone para replicar tabelas críticas entre regiões.
• Utilize a sincronização SCIM para uma gestão de identidades consistente em todas as regiões.
• Documente os requisitos de RTO e RPO para todas as cargas de trabalho críticas.
• Automatize os procedimentos de failover de recuperação de desastres sempre que possível.
• Teste os procedimentos de recuperação de desastres regularmente (pelo menos trimestralmente).
• Documente os planos de recuperação de desastres em detalhes.

Avaliar com base nos requisitos

• Avalie a recuperação de desastres ativa-ativa para cargas de trabalho de missão crítica com requisitos rigorosos de tempo de recuperação (RTO).
• Equilibre o investimento em recuperação de desastres com a criticidade do negócio e os requisitos de RTO/RPO.
• Considere uma solução de recuperação de desastres em váriascloud para obter a maior resiliência (mas também a maior complexidade e custo).

Resultados da Fase 10

Após concluir a Fase 10, você deverá ter:

• Estratégia de alta disponibilidade projetada (implantação em várias zonas para compute clássica).
• Características do plano de controle HA compreendidas (RTO de 15 minutos, RPO de 0).
• Estratégia de recuperação de desastres projetada (ativa-passiva, ativa-ativa ou backup/restauração).
• Requisitos de RTO e RPO definidos para cargas de trabalho críticas.
• Padrões de projeto de recuperação de desastres selecionados com base nos requisitos.
• Estratégia de teste de recuperação de desastres definida com programador de testes regulares.
• Abordagem IaC definida para implantação em regiões primárias e secundárias.
• Estratégia de replicação de dados projetada (por exemplo, armazenamento georredundante, Delta Deep Clone).
• Estratégia de gerenciamento de identidade projetada (sincronização SCIM).
• Manuais de recuperação de desastres documentados com procedimentos detalhados.

Você concluiu todas as fases do guia de implantação do Databricks.