Recuperação após desastre

A recuperação de desastres (DR) para Azure Databricks replica espaços de trabalho, dados e configurações entre regiões cloud, para que as suas equipas continuem a trabalhar quando uma falha regional coloca a sua implementação principal offline. Um plano completo de DR abrange não só o Azure Databricks, mas também as fontes de dados, ferramentas de ingestão, ferramentas de BI e agendadores a que se liga.

Esta página cobre os conceitos, estratégias, ferramentas e procedimentos de teste de que precisa para desenhar e executar uma solução de DR entre regiões.

É novo no planeamento de DR? Comece com a terminologia da indústria de recuperação de desastres para definições de RPO e RTO.

Importante

Use recuperação gerida em caso de desastres. O Azure Databricks recomenda recuperação de desastres gerida para DR entre regiões na AWS e Azure. Replica metadados do Unity Catalog, dados de tabelas geridas e ativos do espaço de trabalho num calendário contínuo, fornece uma URL estável que sobrevive ao failover e permite ativar o failover a partir da consola da conta. Não há scripts de replicação para escrever ou manter. Utilize as instruções de configuração manual nesta página apenas para recursos que a DR gerida não replica, ou se necessitar de topologias ativo-ativo, replicação entre nuvens ou controlo granular sobre o pipeline de replicação.

Garantias de alta disponibilidade intra-regionais

O resto desta página cobre a DR entre regiões, mas o Azure Databricks também oferece alta disponibilidade (HA) dentro de uma única região. Compreenda primeiro estas garantias. Eles determinam se precisa de uma estratégia de DR separada.

HA e DR resolvem diferentes problemas:

O HA utiliza redundância por zona de disponibilidade (AZ) dentro de uma região. Se uma zona falhar, os serviços continuam a funcionar nas outras.
O DR utiliza replicação entre regiões. Executa espaços de trabalho secundários do Azure Databricks noutra região e replica dados e configurações para eles, depois faz failover durante uma falha regional.

Se não precisares de DR multi-região, o Azure Databricks HA pode ser suficiente. O HA evita a complexidade entre regiões, mas não protege contra uma falha total na região. Se depender exclusivamente de HA para DR, verifique a separação e a redundância da sua região na cloud.

As garantias de alta disponibilidade intra-região abrangem o plano de controlo e o plano de computação.

Disponibilidade do Azure Databricks control plane

O plano de controlo do Azure Databricks é resistente a falhas de zona e recupera automaticamente em aproximadamente 15 minutos após uma falha de zona. Os testes regulares de falha de zona confirmam-no.

Todos os serviços de plano de controlo sem estado podem perder VMs individuais, ou todas as VMs de uma zona inteira, sem derrubar o serviço. Os dados do espaço de trabalho são armazenados em bancos de dados replicados entre zonas da região. As contas de armazenamento que disponibilizam imagens do Databricks Runtime também são redundantes na própria região, e todas as regiões têm contas de armazenamento secundárias que assumem a operação quando a principal fica indisponível.

Note

As garantias do plano de controlo acima aplicam-se à infraestrutura gerida pelo Azure Databricks. És responsável pela redundância entre zonas do plano de computação, por exemplo, escolhendo armazenamento com redundância entre zonas para o bucket raiz da área de trabalho e usando conjuntos de instâncias que se estendem por várias zonas de disponibilidade.

Algumas regiões do Azure utilizam um plano de controlo implantado numa região emparelhada. Consulte as regiões do Azure Databricks.

A resiliência a falhas de zona suporta, no máximo, uma zona em inatividade, e só está disponível em regiões do Azure que suportam múltiplas zonas.

Disponibilidade do plano de computação

A disponibilidade do espaço de trabalho depende da disponibilidade do plano de controlo.

Os dados raiz do DBFS não são afetados se a conta de armazenamento estiver configurada com armazenamento redundante por zona (ZRS) ou armazenamento redundante por zona geográfica (GZRS). O padrão é armazenamento geo-redundante (GRS).

Os nós do cluster são obtidos de diferentes zonas de disponibilidade ao solicitar nós ao serviço de computação do Azure, pressupondo que existe capacidade suficiente nas restantes zonas. Se um nó for perdido, o gestor de cluster solicitará novos nós ao provedor de computação da Azure, que os obtém das AZs disponíveis. A exceção é quando o nó do driver é perdido. Nesse caso, o gestor do cluster reinicia o trabalho e o cluster.

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

Terminologia

Use estas definições de forma consistente ao discutir DR com a sua equipa.

Terminologia regional

Terminologia da região

Esta página utiliza as seguintes definições de regiões:

Região principal: A região onde os utilizadores executam diariamente cargas de trabalho interativas e automatizadas de análise de dados.
Região secundária: A região onde as equipas de TI transferem temporariamente as cargas de trabalho durante uma falha na região principal.
Armazenamento geo-redundante: Replicação assíncrona entre regiões do armazenamento persistente. Consulte a documentação da sua nuvem:

Armazenamento geo-redundante entre regiões (Azure).

Importante

Não confie no armazenamento geo-redundante para duplicar o armazenamento raiz do Azure Databricks (como o ADLS (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) criado pelo Azure Databricks para cada espaço de trabalho) entre regiões. Para replicar dados de tabelas geridas, use o Delta Deep Clone e, para dados não-Delta, converta primeiro para Delta sempre que possível.

Terminologia do estado de implantação

Terminologia do status da implantação

Esta página utiliza as seguintes definições de estado de implantação:

Implementação ativa (por vezes chamada de implementação quente): Os utilizadores ligam-se a ela e executam cargas de trabalho. Os trabalhos e fluxos de dados funcionam aqui dentro do prazo.
Desdobramento passivo (por vezes chamado de desdobramento frio): Nenhum processo é executado aqui. As equipas de TI mantêm-no pronto automatizando a implementação de código, configuração e outros objetos do Azure Databricks. Uma implantação passiva só se torna ativa quando a implantação ativa fica indisponível.

Importante

Um projeto pode incluir múltiplas implementações passivas em diferentes regiões para maior resiliência.

A maioria das equipas executa apenas uma implantação ativa de cada vez, a estratégia ativo-passiva. A estratégia ativa-ativa, menos comum, utiliza duas implementações ativas simultâneas.

Terminologia da indústria de recuperação de desastres

Terminologia do setor de recuperação de desastres

Defina estes dois termos do setor com a sua equipa:

Objetivo do ponto de recuperação (RPO): O período máximo de perda de dados que o seu serviço pode tolerar durante um incidente grave. Veja RPO.

O Azure Databricks não armazena os seus dados principais de clientes. Está armazenado no ADLS (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou noutros sistemas sob o seu controlo. O plano de controlo do Azure Databricks armazena alguns objetos (como trabalhos e cadernos), pelo que o RPO do Azure Databricks é o período máximo em que as alterações a esses objetos podem ser perdidas. És responsável por definir o RPO para os dados dos teus clientes no ADLS (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) e noutras fontes de dados que controlas.
Objetivo de tempo de recuperação (RTO): O tempo máximo dentro do qual um processo de negócio deve ser restaurado após um desastre. Ver RTO.

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

Uma solução de DR não mitiga a corrupção de dados. Dados corrompidos na região primária são replicados para a região secundária e são corrompidos em ambas as regiões. Para mitigar este tipo de falha, utilize a viagem temporal da Delta, ferramentas semelhantes ou ferramentas de backup de dados.

Fluxo de trabalho de recuperação típico

Um cenário do Azure Databricks DR desenrola-se normalmente da seguinte forma:

Uma falha atinge um serviço crítico na sua região principal: uma fonte de dados, uma rede ou outra dependência da implementação do Azure Databricks.
Investigue junto do seu fornecedor de serviços de nuvem.
Se o tempo de espera for inaceitável, decide comutar para a região secundária.
Confirma que o mesmo problema não afeta a tua região secundária.
Ativação pós-falha (para ver os passos detalhados, consulte testar a ativação pós-falha):
1. Pare toda a atividade no espaço de trabalho. Os utilizadores param as cargas de trabalho e fazem backup das alterações recentes sempre que possível. As tarefas foram interrompidas (caso a indisponibilidade ainda não as tenha feito falhar).
2. Execute o procedimento de recuperação da região secundária para atualizar o encaminhamento e redirecionar ligações e tráfego de rede.
3. Redirecione os sistemas subsequentes (ferramentas de BI, agendadores, integrações de terceiros) para o espaço de trabalho secundário e restabeleça as respetivas ligações.
4. Após o teste, declare a região secundária operacional. Os utilizadores iniciam sessão na implementação agora ativa e reativam os trabalhos agendados ou atrasados.
Depois de mitigar o problema na região primária, confirme a correção.
Fail back (para detalhes, ver Teste de restauro (failback)):
1. Pare todo o trabalho na região secundária.
2. Execute o procedimento de recuperação da região principal para redirecionar novamente o encaminhamento.
3. Replique quaisquer novos dados de volta para a região primária. Minimize o que precisa de ser replicado. Por exemplo, tarefas só de leitura que foram executadas no ambiente secundário podem não exigir regravação.
4. Teste a implantação na região primária.
5. Marque a região principal como ativa e retome as cargas de produção.

Importante

Pode ocorrer alguma perda de dados durante estas etapas. Defina quanta perda é aceitável para a sua organização e como a mitiga.

Passo 1: Compreender as necessidades do seu negócio

Identificar quais os serviços de dados críticos e definir os respetivos RPO e RTO alvo. Investigue a tolerância de cada sistema em condições reais.

DR, failover e failback acarretam custos e riscos reais, incluindo corrupção de dados, duplicação de dados (escrita no local de armazenamento errado) e utilizadores que fazem alterações na região errada.

Mapeie todos os pontos de integração do Azure Databricks que afetem o seu negócio e escolha as ferramentas e canais de comunicação que o seu plano utiliza.

Pontos de integração para mapear

A sua solução de DR precisa de acomodar processos interativos, processos automatizados ou ambos?
Que serviços de dados utilizam? Alguns podem estar nas instalações.
Como os dados de entrada chegam à nuvem?
Quem consome esses dados? Que processos o consomem a jusante?
Existem integrações de terceiros que precisam de estar cientes das alterações de DR?

Ferramentas e comunicação para planear

Pode pré-definir a sua configuração e torná-la modular para acomodar soluções de DR de forma natural e sustentável?
Que ferramentas e canais de comunicação informam as equipas internas e entidades terceiras (integrações, consumidores subsequentes) sobre alterações de failover e failback de DR? Como confirmas o reconhecimento deles?
Que serviços, caso existam, desativa até que a recuperação completa esteja implementada?

Etapa 2: escolha um processo que atenda às necessidades do seu negócio

Predefinir recuperação após desastre gerida. Gere a replicação de espaços de trabalho, os metadados do Unity Catalog, os dados de tabelas geridas e a orquestração de failover sem scripts personalizados. Utilize as orientações abaixo para fazer você mesmo apenas se o seu caso de utilização estiver fora do respetivo âmbito, por exemplo, recursos que a DR gerida não replica, topologias ativo-ativo, replicação entre nuvens ou controlo detalhado sobre o pipeline de replicação.

Uma solução DIY deve replicar os dados corretos através do plano de controlo, plano de computação e fontes de dados. Espaços de trabalho redundantes correspondem a diferentes planos de controlo em diferentes regiões, pelo que os mantém sincronizados com uma solução assente em scripts, seja uma ferramenta de sincronização ou um fluxo de trabalho de CI/CD. Relativamente aos próprios dados, a maioria das equipas usa tarefas do Azure Databricks (muitas vezes agendadas) ou Delta Deep Clone para copiar tabelas entre regiões. Não é necessário sincronizar dados a partir do plano de computação (por exemplo, a partir dos nós de trabalho do Databricks Runtime).

Se usares a funcionalidade de injeção de VNet (não disponível para todos os tipos de subscrição e implementação), implementa redes de forma consistente em ambas as regiões usando ferramentas baseadas em templates como o Terraform.

Replique as 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 seguintes estratégias com base na duração da interrupção que pode tolerar, no esforço operacional e no custo de retorno à região primária.

Melhores práticas gerais

As melhores práticas gerais para um plano de DR bem-sucedido incluem:

Compreenda quais os processos críticos para o negócio e que 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 estão armazenados.
Isole os serviços e os dados tanto quanto possível. Por exemplo, criar um contentor especial de armazenamento na nuvem para os dados de DR ou mover os objetos Azure Databricks necessários durante um desastre para um espaço de trabalho separado.
És responsável por manter a integridade entre as implementações primárias e secundárias para objetos que não estão armazenados no plano de controlo do Azure Databricks.
Para fontes de dados, use ferramentas nativas do Azure para replicar dados para as suas regiões de DR sempre que possível.

Aviso

Não armazene dados no ADLS raiz (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) usado para acesso root ao DBFS. O armazenamento raiz DBFS não é suportado para dados de clientes de produção. O Azure Databricks também recomenda não armazenar lá bibliotecas, ficheiros de configuração ou scripts de init.

Estratégia de solução ativo-passiva

Estratégia de solução ativo-passivo

Esta secção foca-se na estratégia ativo-passiva porque é a mais comum, a mais simples e a mais económica. Uma solução ativo-passiva sincroniza as alterações de dados e objetos da sua implementação ativa para uma implementação passiva numa região secundária. Durante um evento de DR, a implantação passiva torna-se ativa.

Duas variantes comuns:

Unificado (a nível empresarial): Um conjunto de implementações ativas e passivas suporta toda a organização.
Por departamento ou projeto: Cada domínio mantém a sua própria solução de DR com regiões primárias e secundárias adaptadas às suas necessidades.

Também pode usar uma implementação passiva para cargas de trabalho apenas de leitura, como consultas de utilizador, que não modificam dados nem objetos do Azure Databricks.

Estratégia de solução ativa-ativa

Numa solução ativo-ativo, todos os processos de dados são executados em ambas as regiões em paralelo, permanentemente. A sua equipa de operações deve marcar cada tarefa como concluída apenas depois de ser bem-sucedida em ambas as regiões. Os objetos não podem ser alterados em produção e devem seguir um processo rigoroso de promoção em CI/CD de desenvolvimento/homologação até à produção.

A estratégia ativo-ativo é a mais complexa e é mais dispendiosa, porque as tarefas são executadas em ambas as regiões, mas oferece os valores de RTO e RPO mais baixos.

Pode implementar ativo-ativo em toda a empresa ou por departamento. Não precisas de um espaço de trabalho duplicado para cada carga de trabalho. Por exemplo, muitas vezes, é mais fácil reconstruir espaços de trabalho de desenvolvimento ou de pré-produção a partir de um pipeline de desenvolvimento do que mantê-los sincronizados.

Escolha as suas ferramentas

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

Cliente de sincronização que copia do primário para o secundário: um cliente de sincronização envia dados e ativos de produção da região primária para a região secundária. Normalmente, isto decorre de forma programada, e a frequência de agendamento depende do seu RTO e RPO alvo.
Ferramentas de CI/CD para implantação paralela: para código e ativos de produção, use ferramentas de CI/CD que efetuam alterações nos sistemas de produção simultaneamente em ambas as regiões. Por exemplo, ao enviar código e ativos da preparação/desenvolvimento para a produção, um sistema de CI/CD o disponibiliza em ambas as regiões ao mesmo tempo. A ideia principal é tratar todos os artefatos em um espaço de trabalho do Azure Databricks como infraestrutura como código. A maioria dos artefactos podia ser implementada em simultâneo tanto em espaços de trabalho primários como secundários, enquanto alguns artefactos poderiam ter de ser implementados apenas após um evento de DR. Para ferramentas, consulte Scripts, exemplos e protótipos de automação.

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

A tabela seguinte descreve como lidar com cada tipo de dados com cada opção de ferramenta.

Descrição	Como lidar com ferramentas de CI/CD	Como lidar com a ferramenta de sincronização
Código-fonte: exportações de origem dos notebooks e código-fonte para bibliotecas empacotadas	Implementar ambos simultaneamente no primário e secundário.	Sincronize o código-fonte do primário para o secundário.
Utilizadores 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. Implantar em conjunto os dados de usuários e grupos nas implantações primárias e secundárias.	Use SCIM ou outra automação para ambas as regiões. A criação manual absolutamente não é recomendada, mas se utilizada deve ser feita para ambos 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 de pool	Podem existir como modelos no Git. Co-implementação para primário e secundário. No entanto, `min_idle_instances` no secundário deve ser zero até ao evento DR.	Pools criados usando qualquer `min_idle_instances` quando são sincronizados com um espaço de trabalho secundário através da API ou da CLI.
Configurações de trabalho	Use Databricks Asset Bundles com metas por ambiente (por exemplo, `prod` e `dr`) para implementar a mesma definição de trabalho em ambas as regiões. Para a implementação secundária, defina a concorrência como zero para que o trabalho fique preparado, mas não seja executado. Altere o valor da simultaneidade depois que a implantação secundária se tornar ativa.	Se os trabalhos forem executados em clusters existentes `<interactive>` por algum motivo, o cliente de sincronização precisará mapear para o correspondente `cluster_id` no espaço de trabalho secundário.
Listas de controlo de acesso (ACL)	Podem existir como modelos no Git. Implantação conjunta em implantações primárias e secundárias para notebooks, pastas e clusters. No entanto, guarda os dados dos empregos até ao evento de recuperação de dados.	A API de permissões pode definir controles de acesso para clusters, trabalhos, pools, blocos de anotações e pastas. Um cliente de sincronização precisa mapear para IDs de objeto correspondentes para cada objeto no espaço de trabalho secundário. O Databricks recomenda a criação de um mapa de IDs de objetos do espaço de trabalho primário para o secundário durante a sincronização desses objetos antes de replicar os controles de acesso.
Bibliotecas	Inclua no código-fonte e modelos de cluster/trabalho.	Sincronize bibliotecas personalizadas de repositórios centralizados, DBFS ou armazenamento em nuvem (pode ser montado).
Scripts de inicialização de cluster	Inclua no código fonte, caso prefira.	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 criado somente por meio de trabalhos baseados em notebook ou API de Comando.	Use trabalhos, que podem ser executados como atividades do Azure Data Factory (ADF). Tenha em mente que os endpoints de armazenamento podem mudar, dado que os espaços de trabalho estariam em regiões diferentes. Isto depende muito também da tua estratégia de DR de dados.
Metadados de tabelas	Para objetos do Catálogo Unity (catálogos, esquemas, tabelas, volumes e concessões), co-implemente com o fornecedor Databricks Terraform ou com os Databricks Asset Bundles. Para tabelas herdadas do metastore Hive, inclua instruções CREATE TABLE juntamente com o código-fonte, se tiverem sido criadas através de jobs baseados em notebooks ou da Command API.	Para objetos do Unity Catalog, ler metadados de origem das tabelas do sistema ou `information_schema` e replicá-los para o espaço de trabalho secundário utilizando o SDK da Databricks. Para tabelas de metastore Hive legadas, compare definições de metadados entre metastores usando a API do Catálogo Spark ou `SHOW CREATE TABLE` através de um caderno ou scripts. Os caminhos de armazenamento subjacentes podem ser baseados em regiões e podem diferir entre instâncias do metastore.
Segredos	Inclua no código-fonte se criado somente por meio da Command API. Observe que alguns conteúdos secretos podem precisar ser alterados entre o primário e o secundário.	Os segredos são criados em ambos os espaços de trabalho através da API. Observe que alguns conteúdos secretos podem precisar ser alterados entre o primário e o secundário.
Configurações de clusters	Podem existir como modelos no Git. Implementar em simultâneo nas implementações primária e secundária, embora as da implementação secundária devam ser desativadas até à ocorrência de um evento de DR.	Os clusters são criados depois de sincronizados com o espaço de trabalho secundário usando a API ou a CLI. Eles podem ser explicitamente encerrados se você quiser, dependendo das configurações de terminação automática.
Permissões de notebooks, tarefas e pastas	Podem existir como modelos no Git. Coimplantação em implantações primárias e secundárias.	Replicar 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

Tu controlas quando o DR é ativado e para que região secundária fazes failover. Também és responsável por estabilizar o ambiente de DR antes de retomar as operações normais. Isto normalmente significa criar múltiplos espaços de trabalho Azure Databricks para produção e DR, e depois escolher uma região de failover secundária.

Antes de selecionar a sua região secundária, confirme que todos os recursos e serviços de que depende (tipos de computação, produtos, integrações) estão disponíveis lá. Alguns serviços do Azure Databricks estão disponíveis apenas em regiões específicas.

Verifique também a replicação de dados e a disponibilidade dos tipos de VM.

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

Primeiro, implemente um espaço de trabalho secundário do Azure Databricks (ou espaços de trabalho) e a respetiva metastore associada na região secundária que escolheu. O espaço de trabalho secundário deve espelhar a conta, região e configuração de identidade do primário antes de poder replicar dados ou ativos para ele.

Se utilizar recuperação de desastres gerida, o Azure Databricks assegura a configuração inicial dos catálogos abrangidos e dos recursos da área de trabalho ao criar um grupo de ativação pós-falha. Não precisa de executar uma cópia única desses recursos. Continue com o resto desta secção para quaisquer fontes de dados ou ativos que o DR gerido não reproduza.

Para um espaço de trabalho de produção em execução fora do âmbito da DR gerida, execute uma cópia pontual para sincronizar a implementação passiva com a implementação ativa. Este texto abrange:

Replicação de dados: Utilize uma solução de replicação na nuvem ou o Delta Deep Clone.
Geração de tokens: Automatizar a replicação e futuras cargas de trabalho com tokens gerados.
Replicação no espaço de trabalho: Replice usando os métodos do Passo 4: Prepare as suas fontes de dados. Para orientações abrangentes sobre a exportação da configuração do espaço de trabalho, dados e ativos de IA/ML, consulte Exportar dados do espaço de trabalho.
Validação do espaço de trabalho: Teste o espaço de trabalho e o processo para confirmar que executam com sucesso e produzem os resultados esperados.

As sincronizações subsequentes correm mais rápido do que a cópia inicial, e os teus registos de ferramentas registam o que mudou e quando.

Etapa 4: Preparar suas 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 a partir de fontes de dados

Os dados por lote normalmente residem numa fonte que pode replicar ou entregar para outra região.

Por exemplo, os dados são frequentemente carregados para armazenamento na cloud de forma programada. No modo DR, aponta esses carregamentos para o armazenamento da tua região secundária e atualiza as cargas de trabalho para ler e escrever nesse armazenamento.

Fluxos de dados

O processamento de um fluxo de dados é um desafio maior. 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 alteração de dados do banco de dados
Processamento contínuo baseado em arquivo
Processamento agendado baseado em ficheiros, também conhecido como "disparo único"

Em todos estes casos, deve configurar as suas fontes de dados para lidar com o modo DR e para usar a sua implementação secundária na sua região secundária.

Um 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 um local de dados (geralmente armazenamento em nuvem) que precisa ser modificado para um novo local para garantir uma reinicialização bem-sucedida do fluxo. Por exemplo, a source subpasta sob o ponto de verificação pode armazenar a pasta de nuvem baseada em arquivo.

Esse ponto de verificação deve ser replicado em tempo hábil. Considere a sincronização do intervalo de pontos de verificação com qualquer nova solução de replicação na nuvem.

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

Para cargas de trabalho de streaming, certifique-se de que os pontos de verificação estejam configurados no armazenamento gerenciado pelo cliente para que possam ser replicados para a região secundária para retomada da 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 ao processo principal.

Etapa 5: Implementar e testar sua solução

Se usares recuperação de desastres gerida, podes ativar um failover planeado a partir da consola da conta para validar que a tua configuração funciona de ponta a ponta. O mesmo procedimento abrange tanto os testes de DR como as falhas reais. Consulte ativação pós-falha e recuperação após failover.

Testa regularmente a tua configuração de DR. Um plano de DR não testado muitas vezes falha quando é necessário. Algumas equipas mudam de região ativa a cada poucos meses num calendário para validar pressupostos, exercitar processos e manter a equipa familiarizada com o runbook.

Importante

Teste a sua solução de DR em condições reais, com um horário regular.

Se um teste revelar um objeto ou modelo em falta, atualize o seu plano: remova a dependência, replique-a para o espaço de trabalho secundário ou torne-a disponível de outra forma.

Testa também as mudanças organizacionais e de configuração. O seu plano de DR afeta o seu pipeline de implementação, pelo que a equipa tem de saber o que deve manter sincronizado. Depois de configurar as áreas de trabalho de DR, confirme que a sua infraestrutura, tarefas, notebooks, bibliotecas e outros objetos da área de trabalho estão disponíveis na região secundária.

Expanda os seus processos de trabalho padrão e os pipelines de configuração para implementar alterações para todos os espaços de trabalho. Gerir as identidades dos utilizadores entre os espaços de trabalho e configurar a automação e monitorização dos trabalhos para os novos espaços de trabalho.

Planeie e teste alterações às suas ferramentas de configuração.

Alterações de configuração no planeamento e teste

Para cada uma das seguintes situações, prepare um plano para failover e teste todas as suposições:

Ingestão: Compreenda onde estão as suas fontes de dados e de onde essas fontes obtêm os seus dados. Sempre que possível, parametrize a fonte e utilize um modelo de configuração separado para a implementação secundária e região.
Alterações na execução: Se tiver um agendador para ativar trabalhos ou outras ações, poderá precisar de um agendador separado que trabalhe com a implementação secundária ou com as suas fontes de dados.
Conectividade interativa: Considere como a configuração, autenticação e ligações de rede podem ser afetadas por perturbações regionais para qualquer utilização de APIs REST, ferramentas CLI ou outros serviços como JDBC/ODBC.
Alterações na automação: Para todas as ferramentas de automação.
Saídas: Para quaisquer ferramentas que gerem dados de saída ou logs.
Alterações subsequentes: Para ferramentas de BI, dashboards, agendadores de tarefas e integrações de terceiros que leem dados do Azure Databricks ou nele escrevem, planeie como reconfigurá-los para apontarem para a área de trabalho secundária e notifique os respetivos proprietários.

Falha de teste

Teste de failover

Muitos cenários podem desencadear a DR: uma interrupção inesperada na rede na nuvem, no armazenamento na nuvem ou noutro serviço central em que não seja possível encerrar de forma controlada; uma paragem programada ou uma interrupção; ou até a alternância periódica entre regiões como parte do ciclo de testes.

Para testar o failover, ligue-se ao sistema e execute um desligamento. Confirme que todas as tarefas são concluídas e que os clusters são terminados.

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

Execute testes para confirmar se a plataforma está atualizada.
Desative pools e clusters na região primária para que, se o serviço com falha retornar online, a região primária não comece a processar novos dados.
Execute o processo de recuperação das suas fontes de dados (ver abaixo).
Inicie pools relevantes (ou aumente o min_idle_instances para um número relevante).
Inicie clusters relevantes (se não forem encerrados).
Altere a execução simultânea de tarefas e execute as tarefas relevantes. Podem ser execuções únicas ou periódicas.
Para qualquer ferramenta externa que use uma URL ou nome de domínio para seu espaço de trabalho do Azure Databricks, atualize as configurações para levar em conta o novo plano de controle. Por exemplo, atualize URLs para APIs REST e conexões JDBC/ODBC. A URL voltada para o cliente do aplicativo Web Azure Databricks muda quando o plano 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 últimos dados sincronizados. Ver Terminologia da indústria de recuperação de desastres. Os detalhes desta etapa variam dependendo de como você sincroniza os dados e suas necessidades exclusivas de negócios.
Estabilize suas fontes de dados e garanta que todas estejam disponíveis. Inclua todas as fontes de dados externas, como o Azure Cloud SQL, e seus arquivos Delta Lake, Parquet ou outros.
Encontre o seu ponto de recuperação de 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.

Restauro de testes (failback)

Restauração de teste (failback)

O failback é mais fácil de controlar e pode ser feito numa janela de manutenção. Planeie alguns ou todos os seguintes passos:

Obtenha a confirmação de que a região primária foi restaurada.
Desative pools e clusters na região secundária para que não comecem a processar novos dados.
Sincronize quaisquer ativos novos ou modificados no espaço de trabalho secundário de volta à implantação principal. Dependendo do design dos teus scripts de failover, podes conseguir executar os mesmos scripts para sincronizar objetos da região secundária (DR) para a região primária (de produção).
Sincronize todas as novas atualizações de dados com a implantação principal. Você pode usar as trilhas de auditoria de logs e tabelas Delta para garantir que não haja perda de dados.
Desliga todas as cargas de trabalho na região de DR.
Muda o URL dos trabalhos e dos utilizadores para a região principal, e redireciona as ligações a jusante (ferramentas BI, agendadores, integrações de terceiros) de volta para ela.
Execute testes para confirmar se a plataforma está atualizada.
Inicie pools relevantes (ou aumente o min_idle_instances para um número relevante).
Inicie clusters relevantes (se não forem encerrados).
Altere a execução simultânea de trabalhos e execute trabalhos relevantes. Podem ser execuções únicas ou periódicas.
Conforme necessário, configura novamente a tua região secundária para futura DR.

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

Para AWS e Azure, a recuperação gerida de desastres gere a replicação de espaços de trabalho e tabelas geridas sem automação personalizada. As referências abaixo aplicam-se apenas se estiveres a construir uma solução DIY fora do âmbito do DR gerido.

Para pipelines de DR personalizadas, utilize o provider do Terraform para Databricks para gerir os recursos do workspace como código e implementar em simultâneo nas regiões primária e secundária.

Se estiver a 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 ligado associado à área de trabalho secundária.

Recursos adicionais

Comentários

Esta página foi útil?

Last updated on 2026-06-23