Recuperação de desastre

A recuperação de desastres (DR) do Azure Databricks replica workspaces, dados e configurações entre regiões de nuvem para que suas equipes continuem trabalhando quando uma interrupção regional tira sua implantação principal do ar. Um plano de recuperação de desastre completo abrange não apenas Azure Databricks mas as fontes de dados, as ferramentas de ingestão, as ferramentas de BI e os agendadores aos quais ele se conecta.

Esta página aborda os conceitos, estratégias, ferramentas e procedimentos de teste necessários para projetar e executar uma solução de DR entre regiões.

Novo em planejamento de DR? Comece com a terminologia do setor de recuperação de desastres para definições de RPO e RTO.

Importante

Use a recuperação de desastre gerenciada. Azure Databricks recomenda a recuperação de desastre gerenciada para DR entre regiões no AWS e Azure. Replica metadados do Unity Catalog, dados de tabelas gerenciadas e ativos do workspace de forma contínua, fornece um URL estável que continua válido após o failover e permite acionar o failover pelo console da conta. Não há scripts de replicação para escrever ou manter. Use as diretrizes DIY desta página somente para recursos que a DR gerenciada não replica ou se você precisar de topologias ativas ativas, replicação entre nuvens ou controle refinado sobre o pipeline de replicação.

Garantias de alta disponibilidade intra-região

O restante desta página aborda a DR entre regiões, mas Azure Databricks também fornece alta disponibilidade (HA) dentro de uma única região. Entenda essas garantias primeiro. Eles determinam se você precisa de uma estratégia de recuperação de desastre separada.

Ha e DR resolvem problemas diferentes:

HA utiliza redundância de zona de disponibilidade (AZ) em uma região. Se uma zona falhar, os serviços continuarão em execução nas outras.
A DR usa a replicação entre regiões. Você executa workspaces do Azure Databricks secundários em outra região e replica dados e configurações para eles e, em seguida, faz failover durante uma interrupção regional.

Se você não precisar de DR de várias regiões, Azure Databricks ha pode ser suficiente. A HA evita a complexidade entre regiões, mas não protege contra uma interrupção de região inteira. Se você depender apenas da HA para DR, verifique a separação e a redundância da região de nuvem.

As garantias de HA intra-região abrangem o plano de controle de segurança e o plano de computação.

Disponibilidade do plano de controle Azure Databricks

O plano de controle Azure Databricks é resiliente a falhas de zona e se recupera automaticamente em aproximadamente 15 minutos após uma falha de zona. Testes regulares de falha de zona validam isso.

Todos os serviços do plano de controle de segurança sem estado podem perder VMs individuais ou todas as VMs em uma zona inteira, sem desativar o serviço. Os dados do workspace são armazenados em bancos de dados replicados entre zonas da região. As contas de armazenamento que hospedam as imagens do Databricks Runtime também são redundantes dentro da região, e todas as regiões têm contas de armazenamento secundárias que assumem a operação quando a conta primária fica indisponível.

Observação

As garantias acima do plano de controle se aplicam à infraestrutura gerenciada por Azure Databricks. Você é responsável pela redundância de zona do plano de computação, por exemplo, escolhendo o armazenamento com redundância entre zonas para o bucket raiz do workspace e usando pools de instâncias que se estendem por zonas de disponibilidade.

Algumas regiões do Azure usam um plano de controle implantado em uma região emparelhada. Consulte as regiões do Azure Databricks.

A resiliência a falhas de zona suporta, no máximo, a indisponibilidade de uma zona e está disponível apenas em regiões do Azure que oferecem suporte a várias zonas.

Disponibilidade do plano de computação

A disponibilidade do workspace depende da disponibilidade do plano de controle.

Os dados raiz do DBFS não serão afetados se a conta de armazenamento estiver configurada com ZRS (armazenamento com redundância de zona) ou GZRS (armazenamento com redundância de zona geográfica). O padrão é GRS (armazenamento com redundância geográfica).

Os nós do cluster são obtidos de diferentes zonas de disponibilidade ao solicitar nós do provedor de computação do Azure, desde que haja capacidade suficiente nas zonas restantes. Se um nó for perdido, o gerenciador de cluster solicitará nós de substituição do provedor de computação do Azure, que os extrai das AZs disponíveis. A exceção é quando o nó do driver é perdido. Nesse caso, o gerenciador de cluster reinicia o trabalho e o cluster.

Para confirmar o suporte a vários AZ, consulte a lista de regiões Azure. Para a resiliência multi-AZ do plano de computação, use o armazenamento com redundância de zona.

Terminologia

Use essas definições de forma consistente ao discutir a DR com sua equipe.

Terminologia de região

Esta página usa as seguintes definições de região:

Região primária: a região em que os usuários executam cargas de trabalho de análise de dados interativas e automatizadas diárias.
Região secundária: a região em que as equipes de TI movem cargas de trabalho temporariamente durante uma interrupção de região primária.
Armazenamento com redundância geográfica: replicação assíncrona entre regiões do armazenamento persistente. Consulte a documentação da nuvem:

Armazenamento com redundância geográfica entre regiões (Azure).

Importante

Não dependa do armazenamento com redundância geográfica para duplicar o armazenamento raiz do Azure Databricks (como o ADLS (para workspaces criados antes de 6 de março de 2023, o Armazenamento de Blobs do Azure) que o Azure Databricks cria para cada workspace) entre regiões. Para replicar dados de tabelas gerenciadas, use o Delta Deep Clone e, para dados que não são Delta, converta-os primeiro para Delta, sempre que possível.

Terminologia do status da implantação

Terminologia de status de implantação

Esta página usa as seguintes definições de status de implantação:

Implantação ativa (às vezes chamada de implantação a quente): os usuários se conectam a ela e executam cargas de trabalho. Trabalhos e fluxos de dados são executados aqui dentro do cronograma.
Implantação passiva (às vezes chamada de implantação a frio): nenhum processo é executado aqui. As equipes de TI mantêm-no pronto automatizando a implantação de código, configuração e outros objetos Azure Databricks nele. Uma implantação passiva só se torna ativa quando a implantação ativa fica inoperante.

Importante

Um projeto pode incluir várias implantações passivas em regiões diferentes para resiliência adicional.

A maioria das equipes mantém uma implantação ativa por vez, a estratégia ativa-passiva. A estratégia ativa-ativa menos comum executa duas implantações ativas simultâneas.

Terminologia do setor de recuperação de desastre

Defina estes dois termos do setor com sua equipe:

RPO (objetivo de ponto de recuperação): o período máximo de perda de dados que seu serviço pode tolerar durante um incidente importante. Consulte RPO.

Azure Databricks não armazena seus dados primários do cliente. Isso reside no ADLS (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou em outros sistemas que você controla. O plano de controle Azure Databricks armazena alguns objetos (como trabalhos e notebooks), portanto, o RPO Azure Databricks é o período máximo em que as alterações nesses objetos podem ser perdidas. Você é responsável por definir o RPO para os dados do cliente no ADLS (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) e outras fontes de dados que você controla.
RTO (objetivo de tempo de recuperação): o tempo máximo no qual um processo de negócios deve ser restaurado após um desastre. Consulte RTO.

Recuperação de desastre e corrupção de dados

Recuperação de desastre e dados corrompidos

Uma solução de DR não mitiga a corrupção de dados. Os dados corrompidos na região primária são replicados para a região secundária, ficando corrompidos em ambas as regiões. Para mitigar esse tipo de falha, use Delta time travel, ferramentas semelhantes ou ferramentas de backup.

Fluxo de trabalho típico de recuperação

Um cenário de recuperação de desastre Azure Databricks normalmente é executado da seguinte maneira:

Uma falha atinge um serviço crítico em sua região primária: uma fonte de dados, uma rede ou outra dependência na qual a implantação Azure Databricks depende.
Você investiga com seu provedor de nuvem.
Se a espera for inaceitável, você decidirá fazer failover para sua região secundária.
Confirme se o mesmo problema não afeta sua região secundária.
Faça failover (para conhecer as etapas detalhadas, consulte Failover de teste):
1. Interrompa todas as atividades do workspace. Os usuários interrompem as cargas de trabalho e fazem backup das alterações recentes, sempre que possível. Os trabalhos serão encerrados (se a interrupção já não os tiver feito falhar).
2. Execute o procedimento de recuperação de região secundária para atualizar o roteamento e redirecionar conexões e tráfego de rede.
3. Redirecione os sistemas dependentes (ferramentas de BI, agendadores, integrações de terceiros) para o espaço de trabalho secundário e restabeleça as conexões.
4. Após o teste, declara que a região secundária está operacional. Os usuários fazem login na implantação que agora está ativa, e você aciona novamente as tarefas agendadas ou adiadas.
Depois que o problema da região primária for mitigado, confirme a correção.
Faça failback (para obter detalhes, consulte Testar restauração (failback)):
1. Pare todo o trabalho na região secundária.
2. Execute o procedimento de recuperação da região primária para redirecionar o roteamento de volta.
3. Replique os novos dados de volta para a região primária. Minimize o que precisa ser replicado. Por exemplo, trabalhos somente leitura executados na implantação secundária podem não exigir write-back.
4. Teste a implantação na região primária.
5. Declare a região primária ativa e retome as cargas de trabalho de produção.

Importante

Algumas perdas de dados podem ocorrer durante essas etapas. Defina a quantidade de perda aceitável para sua organização e como você a atenua.

Etapa 1: entender as necessidades de negócios

Identifique quais serviços de dados são críticos e defina o RPO de destino e o RTO. Pesquise a tolerância real de cada sistema.

DR, failover e failback trazem custos e riscos reais, incluindo corrupção de dados, duplicação de dados (gravação no local de armazenamento errado) e usuários fazendo alterações na região errada.

Mapeie cada ponto de integração Azure Databricks que afeta sua empresa e escolha as ferramentas e os canais de comunicação que seu plano usa.

Pontos de integração a serem mapeados

Sua solução de recuperação de desastre precisa acomodar processos interativos, processos automatizados ou ambos?
Quais serviços de dados você usa? Alguns podem estar no local.
Como os dados de entrada vão para a nuvem?
Quem consome esses dados? Quais processos os consomem posteriormente?
Há integrações de terceiros que precisam estar cientes das alterações de DR?

Ferramentas e comunicação para planejar

Você pode predefinir sua configuração e torná-la modular para acomodar soluções de recuperação de desastre de maneira natural e mantenedível?
Quais ferramentas e canais de comunicação notificarão as equipes internas e de terceiros (integrações, consumidores de downstream) sobre o failover de DR e as alterações do failback? Como você confirma a confirmação deles?
Quais serviços, se houver, você interromperá até que a recuperação completa seja restabelecida?

Etapa 2: escolher um processo que atenda às necessidades de negócios

Usar recuperação de desastres gerenciada como padrão. Ele lida com a replicação de workspace, os metadados do Unity Catalog, os dados de tabelas gerenciadas e a orquestração de failover sem scripts personalizados. Use as orientações DIY abaixo somente se o seu caso estiver fora do escopo delas, por exemplo: recursos que a DR gerenciada não replica, topologias ativo-ativo, replicação entre nuvens ou controle granular sobre o pipeline de replicação.

Uma solução DIY deve replicar os dados corretos no plano de controle, plano de computação e fontes de dados. Workspaces redundantes são associados a diferentes planos de controle de segurança em diferentes regiões, por isso você os mantém sincronizados com uma solução baseada em scripts, uma ferramenta de sincronização ou um fluxo de trabalho de CI/CD. Para os dados em si, a maioria das equipes usa trabalhos Azure Databricks (geralmente agendados) ou Delta Deep Clone para copiar tabelas entre regiões. Você não precisa sincronizar dados de dentro do plano de computação (como de workers do Databricks Runtime).

Se você usar o recurso de injeção de VNet (não disponível com todos os tipos de assinatura e implantação), implante redes consistentemente em ambas as regiões usando ferramentas baseadas em modelo, como o Terraform.

Replique suas fontes de dados entre regiões conforme necessário.

As soluções de DR normalmente envolvem dois (ou mais) espaços de trabalho. Escolha entre as estratégias a seguir com base na duração da interrupção que você deve tolerar, no esforço operacional e no custo para retornar à região primária.

Práticas recomendadas gerais

As práticas recomendadas gerais para um plano de dr bem-sucedido incluem:

Entenda quais processos são essenciais para a empresa e devem ser executados em DR.
Identifique claramente quais serviços estão envolvidos, quais dados estão sendo processados, qual é o fluxo de dados e onde eles são armazenados.
Isolar os serviços e os dados o máximo possível. Por exemplo, crie um contêiner de armazenamento em nuvem especial para os dados de recuperação de desastres ou mova os objetos do Azure Databricks necessários durante um desastre para um espaço de trabalho separado.
Você é responsável por manter a integridade entre implantações primárias e secundárias para objetos não armazenados no plano de controle Azure Databricks.
Para fontes de dados, use ferramentas de Azure nativas para replicar dados para suas regiões de recuperação de desastre sempre que possível.

Aviso

Não armazene dados no ADLS raiz (para workspaces criados antes de 6 de março de 2023, no Armazenamento de Blobs do Azure) usado para acesso à raiz do DBFS. O armazenamento raiz do DBFS não tem suporte para dados do cliente de produção. O Azure Databricks também não recomenda armazenar bibliotecas, arquivos de configuração ou scripts de inicialização lá.

Estratégia de solução ativa-passiva

Esta seção se concentra na estratégia ativo-passiva porque ela é a mais comum, a mais simples e a mais econômica. Uma solução ativa-passiva sincroniza dados e mudanças em objetos da implantação ativa para uma implantação passiva em uma região secundária. Durante um evento de recuperação de desastre, a implantação passiva torna-se ativa.

Duas variantes comuns:

Unificado (em toda a empresa): um conjunto de implantações ativas e passivas dá suporte a toda a organização.
Por departamento ou projeto: cada domínio mantém sua própria solução de recuperação de desastre com regiões primárias e secundárias adaptadas às suas necessidades.

Você também pode usar uma implantação passiva para cargas de trabalho somente leitura, como consultas de usuário, que não modificam dados ou objetos Azure Databricks.

Estratégia de solução ativa-ativa

Em uma solução ativa-ativa, todos os processos de dados são executados em ambas as regiões em paralelo o tempo todo. Sua equipe de operações deve marcar cada trabalho concluído somente depois de ter êxito em ambas as regiões. Os objetos não podem ser alterados na produção e devem seguir uma promoção estrita de CI/CD desde o desenvolvimento/preparo até a produção.

Ativo-ativo é a estratégia mais complexa e custa mais porque os trabalhos são executados em ambas as regiões, mas oferece o RTO e o RPO mais baixos.

Você pode implementar uma topologia ativo-ativo em toda a empresa ou por departamento. Você não precisa de um espaço de trabalho duplicado para cada carga de trabalho. Por exemplo, os workspaces de desenvolvimento ou preparo geralmente são mais fáceis de recriar a partir de um pipeline de desenvolvimento do que de mantê-los sincronizados.

Escolha suas ferramentas

Há duas abordagens principais para manter os dados sincronizados entre espaços de trabalho nas regiões primária e secundária:

Cliente de sincronização que copia da primária para a secundária: o cliente de sincronização envia os dados de produção e os ativos da região primária para a região secundária. Normalmente, isso é executado de forma programada, e a frequência do agendamento depende do RTO e RPO desejados.
Ferramentas de CI/CD para implantação paralela: para código de produção e ativos, use as ferramentas de CI/CD que enviam por push as alterações para os sistemas de produção simultaneamente para ambas as regiões. Por exemplo, ao fazer o push do código e dos ativos do ambiente de staging/desenvolvimento para a produção, um sistema de CI/CD os disponibiliza em ambas as regiões ao mesmo tempo. A ideia principal é tratar todos os artefatos em um workspace do Azure Databricks como infraestrutura como código. A maioria dos artefatos pode ser implantada em conjunto com workspaces primários e secundários, enquanto alguns artefatos podem precisar ser implantados somente após um evento de DR. Para ferramentas, consulte scripts de automação, exemplos e protótipos.

Dependendo de suas necessidades, você pode combinar as abordagens. Por exemplo, use CI/CD para o código-fonte do notebook, mas use a sincronização para configuração, como pools e controles de acesso.

A tabela a seguir descreve como lidar com cada tipo de dados com cada opção de ferramentas.

Descrição	Como lidar com ferramentas de CI/CD	Como lidar com a ferramenta de sincronização
Código-fonte: exportações de origem do notebook e código-fonte para bibliotecas empacotadas	Implante em conjunto tanto para a primária quanto para a secundária.	Sincronize o código-fonte de origem para destino.
Usuários e grupos	Gerencie metadados como configuração no Git. Como alternativa, use o mesmo provedor de identidade (IdP) para ambos os espaços de trabalho. Implante em conjunto os dados do usuário e do grupo em implantações primárias e secundárias.	Use o SCIM ou outra automação para ambas as regiões. A criação manual não é recomendada, mas, se usada, deve ser feita para ambas ao mesmo tempo. Se você usar uma configuração manual, crie um processo automatizado agendado para comparar a lista de usuários e grupos entre as duas implantações.
Configurações do pool	Podem ser modelos no Git. Implantar simultaneamente no primário e secundário. No entanto, `min_idle_instances` na secundária deve ser zero até o evento de DR.	Pools criados com qualquer `min_idle_instances` quando são sincronizados com um espaço de trabalho secundário usando a API ou a CLI.
Configurações de trabalho	Use Pacotes de Ativos do Databricks com destinos por ambiente (por exemplo, `prod` e `dr`) para implantar a mesma definição de trabalho em ambas as regiões. Para a implantação secundária, defina a simultaneidade como zero para que o trabalho seja preparado, mas não seja executado. Altere o valor das concorrências depois que a implantação secundária se tornar ativa.	Se os trabalhos forem executados em `<interactive>` clusters existentes por algum motivo, o cliente de sincronização precisará mapear para o correspondente `cluster_id` no espaço de trabalho secundário.
ACLs (listas de controle de acesso)	Podem ser modelos no Git. Implante em conjunto em implantações primárias e secundárias para notebook, pastas e clusters. No entanto, mantenha os dados dos trabalhos até o evento de DR.	A API de Permissões define os controles de acesso para clusters, trabalhos, pools, notebooks e pastas. O cliente de sincronização precisa mapear as IDs de objeto correspondentes para cada objeto no espaço de trabalho secundário. O Databricks recomenda criar um mapa de IDs de objeto do espaço de trabalho primário para o secundário ao sincronizar esses objetos antes de replicar os controles de acesso.
Bibliotecas	Inclua no código-fonte e nos modelos de cluster/trabalho.	Sincronize bibliotecas personalizadas de repositórios centralizados, DBFS ou armazenamento em nuvem (pode ser montado).
Scripts de inicialização do cluster	Você pode incluir no código-fonte, se preferir.	Para uma sincronização mais simples, armazene scripts de inicialização no espaço de trabalho primário em uma pasta comum ou em um pequeno conjunto de pastas, se possível.
Pontos de montagem	Inclua no código-fonte se for criado somente por meio de trabalhos baseados em notebook ou da API de comando.	Use trabalhos, que podem ser executados como atividades do Azure Data Factory (ADF). Observe que os pontos de extremidade de armazenamento podem mudar, dado que os espaços de trabalho podem estar em regiões diferentes. Isso também depende muito da estratégia de recuperação de dados.
Metadados da tabela	Para objetos do Unity Catalog (catálogos, esquemas, tabelas, volumes e concessões), faça a implantação em conjunto com o Provedor Terraform do Databricks ou os Pacotes de Ativos do Databricks. Para tabelas metastore herdadas do Hive, inclua instruções create-table com código-fonte se criadas por meio de trabalhos baseados em notebook ou da API de Comando.	Para objetos do Catálogo do Unity, leia os metadados de origem das tabelas do sistema ou `information_schema` e replique para o workspace secundário usando o SDK do Databricks. Para tabelas metastore herdadas do Hive, compare as definições de metadados entre metastores usando a API do Catálogo do Spark ou `SHOW CREATE TABLE` por meio de um notebook ou scripts. Os caminhos de armazenamento subjacentes podem ser baseados em região e podem diferir entre instâncias de metastore.
Segredos	Inclua no código-fonte se for criado somente por meio da API de comando. É importante observar que alguns conteúdos confidenciais podem precisar sofrer alterações entre o primário e o secundário.	Os segredos são criados em ambos os espaços de trabalho por meio da API. É importante observar que alguns conteúdos confidenciais podem precisar sofrer alterações entre o primário e o secundário.
Configurações de cluster	Podem ser modelos no Git. Realize em conjunto as implantações primária e secundária, embora as da implantação secundária devam ser encerradas até o evento de DR.	Os clusters são criados depois de serem sincronizados com o espaço de trabalho secundário usando a API ou a CLI. Eles podem ser encerrados explicitamente se você desejar, dependendo das configurações de encerramento automático.
Permissões de notebook, trabalho e pasta	Podem ser modelos no Git. Implante em conjunto tanto para a primária quanto para a secundária.	Replique usando a API de Permissões.

Escolha regiões e múltiplos espaços de trabalho secundários

Escolher regiões e vários espaços de trabalho secundários

Você controla quando a DR é acionada e para qual região secundária você realiza o failover. Você também é responsável por estabilizar o ambiente de recuperação de desastre antes de retomar as operações normais. Isso normalmente significa criar vários workspaces do Azure Databricks para produção e DR e, em seguida, escolher uma região secundária de failover.

Antes de selecionar sua região secundária, confirme se todos os recursos e serviços dos quais você depende (tipos de computação, produtos, integrações) estão disponíveis lá. Alguns serviços Azure Databricks só estão disponíveis em regiões específicas.

Verifique também a replicação de dados e a disponibilidade do tipo de VM.

Etapa 3: preparar espaços de trabalho e fazer uma cópia única

Primeiro, crie um workspace secundário do Azure Databricks (ou workspaces) e o metastore correspondente na região secundária escolhida. O espaço de trabalho secundário deve espelhar a conta, a região e a configuração de identidade do espaço de trabalho principal antes de poder replicar dados ou ativos para ele.

Se você usar a recuperação de desastre gerenciada, o Azure Databricks cuidará do bootstrap inicial dos catálogos incluídos no escopo e dos ativos do workspace quando você criar um grupo de failover. Você não precisa fazer uma cópia única para esses recursos. Prossiga com o restante desta seção para todas as fontes de dados ou ativos que o DR gerenciado não replica.

Para um workspace de produção em execução fora do escopo da DR gerenciada, execute uma cópia única para sincronizar a implantação passiva com a implantação ativa. Essa cópia processa:

Replicação de dados: use uma solução de replicação em nuvem ou o Delta Deep Clone.
Geração de token: automatizar a replicação e cargas de trabalho futuras com tokens gerados.
Replicação do espaço de trabalho: Replicar usando os métodos da Etapa 4: Preparar suas fontes de dados. Para obter diretrizes abrangentes sobre como exportar configuração de workspace, dados e ativos de IA/ML, consulte Exportar dados do workspace.
Validação do workspace: teste o workspace e o processo para confirmar se eles são executados com êxito e produzir os resultados esperados.

As sincronizações subsequentes são executadas mais rapidamente do que a cópia inicial e os logs de ferramentas registram o que foi alterado e quando.

Etapa 4: preparar as fontes de dados

O Azure Databricks pode processar uma grande variedade de fontes de dados usando processamento em lote ou fluxos de dados.

Processamento em lote de fontes de dados

Processamento em lotes de fontes de dados

Os dados do lote geralmente residem em uma fonte que você pode replicar ou entregar para outra região.

Por exemplo, os dados geralmente são carregados para o armazenamento em nuvem em intervalos programados. No modo DR, aponte esses uploads para o armazenamento da região secundária e atualize as cargas de trabalho para ler desse armazenamento e gravar nele.

Fluxos de dados

O processamento de um fluxo de dados é um desafio mais complexo. Os dados de streaming podem ser ingeridos de várias fontes, processados e enviados para uma solução de streaming:

Fila de mensagens, como Kafka
Fluxo de captura de dados de alterações de banco de dados
Processamento contínuo baseado em arquivo
Processamento agendado baseado em arquivo, também conhecido como gatilho único

Em todos esses casos, você deve configurar as fontes de dados para administrar o modo de DR e usar a implantação secundária na região secundária.

O gravador de fluxo armazena um ponto de verificação com informações sobre os dados que foram processados. Esse ponto de verificação pode conter a localização dos dados (geralmente armazenamento em nuvem) que deve ser mudado para um novo local para garantir uma reinicialização bem-sucedida do fluxo. Por exemplo, a subpasta source sob o ponto de verificação pode armazenar a pasta de nuvem baseada em arquivos.

Esse ponto de verificação deve ser replicado oportunamente. Analise a sincronização do intervalo do ponto de verificação com qualquer nova solução de replicação em nuvem.

A atualização do ponto de verificação é uma função do gravador e, portanto, se aplica à ingestão de fluxo de dados ou ao processamento e armazenamento em outra fonte de streaming.

Para cargas de trabalho de streaming, verifique se os pontos de verificação estão configurados no armazenamento gerenciado pelo cliente para que eles possam ser replicados para a região secundária, e assim retomar a carga de trabalho a partir do ponto da última falha. Você também pode optar por executar o processo de streaming secundário em paralelo com o processo primário.

Etapa 5: implementar e testar a solução

Se você usar a recuperação de desastre gerenciada, poderá disparar um failover planejado do console da conta para validar se a configuração funciona de ponta a ponta. O mesmo procedimento abrange testes de recuperação de desastre e interrupções reais. Consulte Fazer failover e failback.

Teste a configuração de recuperação de desastre regularmente. Um plano de recuperação de desastre não testado geralmente falha quando você precisa dele. Algumas equipes alternam as regiões ativas a cada poucos meses, de acordo com um cronograma, para validar pressupostos, testar os processos e manter a equipe familiarizada com o runbook.

Importante

Teste sua solução de recuperação de desastres em condições reais, em intervalos regulares.

Se um teste revelar um objeto ou modelo ausente, atualize seu plano: remova a dependência, replique-a para o workspace secundário ou disponibilize-a de outra maneira.

Teste as alterações organizacionais e de configuração também. Seu plano de DR afeta seu pipeline de implantação, portanto a equipe deve saber o que manter sincronizado. Depois de configurar os workspaces de DR, confirme se sua infraestrutura, trabalhos, notebooks, bibliotecas e outros objetos do workspace estão disponíveis na região secundária.

Expanda seus processos de trabalho padrão e pipelines de configuração para implantar alterações em todos os workspaces. Gerencie identidades de usuário em todos os espaços de trabalho e configure a automação e o monitoramento de tarefas para os novos espaços de trabalho.

Planeje e teste as alterações nas ferramentas de configuração.

Alterações de configuração para planejar e testar

Para cada um dos seguintes procedimentos, prepare um plano para failover e teste todas as suposições:

Ingestão: entenda onde estão suas fontes de dados e onde essas fontes obtêm seus dados. Sempre que possível, parametrize a origem e use um modelo de configuração separado para a implantação e a região secundárias.
Alterações de execução: se você tiver um agendador para disparar trabalhos ou outras ações, talvez seja necessário um agendador separado que funcione com a implantação secundária ou suas fontes de dados.
Conectividade interativa: considere como a configuração, a autenticação e as conexões de rede podem ser afetadas por interrupções regionais para qualquer uso de APIs REST, ferramentas da CLI ou outros serviços, como JDBC/ODBC.
Alterações de automação: para todas as ferramentas de automação.
Saídas: Para quaisquer ferramentas que geram dados de saída ou logs.
Alterações downstream: para as ferramentas de BI, painéis, agendadores e integrações de terceiros que leem ou gravam no Azure Databricks, planeje como redirecioná-los para o workspace secundário e notifique seus proprietários.

Testar o failover

Testar failover

Muitos cenários podem acionar a DR: uma interrupção inesperada na rede na nuvem, no armazenamento em nuvem ou em outro serviço essencial em que não é possível desligar normalmente; um desligamento ou uma interrupção planejada; ou até mesmo a alternância periódica entre regiões como parte do seu ciclo de testes.

Para testar o failover, conecte-se ao sistema e realize um desligamento. Confirme se todos os trabalhos sejam concluídos e os clusters sejam encerrados.

Um cliente de sincronização (ou ferramentas de CI/CD) replica objetos e recursos relevantes do Azure Databricks no espaço de trabalho secundário. Para ativar o workspace secundário, seu processo pode incluir alguns ou todos os seguintes:

Execute testes para confirmar se a plataforma está atualizada.
Desabilite pools e clusters na região primária para que, se o serviço com falha voltar a ficar online, a região primária não iniciará o processamento de novos dados.
Execute o processo de recuperação para suas fontes de dados (veja abaixo).
Inicie os pools importantes (ou aumente o min_idle_instances para um número relevante).
Inicie os clusters importantes (se não estiverem encerrados).
Altere a execução simultânea dos trabalhos e execute os trabalhos importantes. Podem ser execuções que são feitas uma única vez ou periodicamente.
Para todas as ferramentas externas que usam uma URL ou um nome de domínio no workspace do Azure Databricks, atualize as configurações para levar em conta o novo plano de controle. Por exemplo, atualize os URLs de APIs REST e conexões JDBC/ODBC. A URL voltada para o cliente do aplicativo Web do Azure Databricks muda quando o painel de controle é alterado, portanto, notifique os usuários da sua organização sobre a nova URL.

Detalhes do processo de recuperação

Verifique a data dos dados sincronizados mais recentemente. Consulte a terminologia do setor de recuperação de desastres. Os detalhes desta etapa variam dependendo de como você sincroniza os dados e suas necessidades comerciais exclusivas.
Estabilize as fontes de dados e garante que todas elas estão disponíveis. Inclua todas as fontes de dados externas, como o SQL de Nuvem do Azure, e o Delta Lake, Parquet ou outros arquivos.
Encontre o seu ponto de recuperação para streaming. Configure o processo para reiniciar a partir daí e tenha um processo pronto para identificar e eliminar possíveis duplicatas (o Delta Lake facilita isso).
Conclua o processo de fluxo de dados e informe os usuários.

Teste de restauração (failback)

Testar a restauração (failback)

O failback é mais fácil de controlar e pode ser feito em uma janela de manutenção. Planeje algumas ou todas as seguintes etapas:

Obtenha a confirmação de que a região primária foi restaurada.
Desabilite pools e clusters na região secundária para que ele não comece a processar novos dados.
Sincronize todos os ativos novos ou modificados feitos no workspace secundário de volta na implantação primária. Dependendo do design dos scripts de failover, você poderá executar os mesmos scripts para sincronizar objetos da região secundária (DR) para a região primária (produção).
Sincronize quaisquer novas atualizações de dados para a implementação primária. Você pode usar as trilhas de auditoria de logs e tabelas do Delta para garantir que não haja perda de dados.
Desative todas as cargas de trabalho na região de DR.
Altere a URL de tarefas e usuários para a região primária e redirecione as conexões dependentes (ferramentas de BI, agendadores, integrações de terceiros) novamente para ela.
Execute testes para confirmar se a plataforma está atualizada.
Inicie os pools importantes (ou aumente o min_idle_instances para um número relevante).
Inicie os clusters importantes (se não estiverem encerrados).
Altere a execução simultânea dos trabalhos e execute os trabalhos importantes. Podem ser execuções que são feitas uma única vez ou periodicamente.
Conforme necessário, configure a região secundária novamente para uma DR futura.

Scripts de automação, exemplos e protótipos

Para AWS e Azure, a recuperação de desastres gerenciada cuida da replicação de workspaces e de tabelas gerenciadas sem automação personalizada. As referências abaixo se aplicam somente se você estiver criando uma solução DIY fora do escopo da DR gerenciada.

Para pipelines de DR DIY, use o Provedor Terraform do Databricks para gerenciar ativos do workspace como código e realizar a implantação em conjunto nas regiões primária e secundária.

Se você orquestrar o Azure Databricks a partir do Azure Data Factory, replique os pipelines relevantes do ADF para que façam referência a um serviço vinculado associado ao workspace secundário.

Recursos adicionais

Comentários

Esta página foi útil?

Last updated on 2026-06-24