Recuperação de desastre gerenciada

A recuperação de desastre gerenciada (DR) replica sua implantação de Azure Databricks em uma região secundária para que você possa se recuperar de uma interrupção regional em minutos. Azure Databricks gerencia o pipeline de replicação, o estado dos catálogos replicados no secundário e o processo de failover. Você não escreve nem mantém scripts de replicação.

Para obter a abordagem manual de recuperação de desastres, incluindo conceitos gerais de DR e práticas recomendadas, consulte Recuperação de desastre.

O que é a recuperação de desastre gerenciada?

A DR gerenciada fica acima dos workspaces e metastores já operados por você. Você abre dois workspaces do Azure Databricks, um na região primária e outro na região secundária, e um metastore em cada região. Então, a DR gerenciada:

• Replica as categorias aceitas por você da primária para a secundária em um agendamento contínuo. Ambas as categorias são opcionalmente independentes: metadados do Unity Catalog e dados de tabelas gerenciadas; e ativos do workspace, como notebooks, jobs, SQL warehouses, clusters e ACLs.
• Fornece uma URL estável opcional, uma única cadeia de conexão que sempre aponta para a primária atual, de maneira que os clientes continuem funcionando após o failover sem reconfiguração.
• Permite acionar o failover quando quiser, para um teste de DR ou uma falha real.

As IDs de ativo do workspace são preservadas entre regiões, logo, as URLs que referenciam um ativo do workspace por ID continuarão sendo resolvidas depois do failover.

O que é replicado

A DR gerenciada pode replicar o seguinte em cada ciclo de replicação. Ambas as categorias são opcionais, portanto, você pode habilitar um ou ambos:

• Metadados e dados do Unity Catalog: tabelas gerenciadas do Unity Catalog no Delta Lake com dados, tabelas externas e volumes (somente metadados), exibições, funções e todas as concessões de permissões. O modo de isolamento do catálogo é replicado. Se o catálogo de origem estiver aberto, a réplica estará aberta. Se a origem estiver isolada e associada ao workspace primário, a réplica será isolada e associada ao workspace secundário.
• Ativos de workspace: notebooks, trabalhos, warehouses SQL, clusters, painéis de IA/BI de rascunho, arquivos e pastas, além das ACLs. Os SQL warehouses são replicados no estado STOPPED, e os clusters, no estado TERMINATED. Os agendamentos de trabalho no secundário são pausados.

Propriedade de objetos replicados

Quando a DR gerenciada cria um objeto protegível replicado (catálogo, esquema, tabela, exibição, função ou volume) no ambiente secundário, o proprietário inicial é a entidade de serviço do Azure Databricks que executa a replicação, porque o Unity Catalog atribui a propriedade à identidade que cria o objeto. A DR gerenciada acaba transferindo a propriedade da réplica de acordo com o proprietário do protegível correspondente no primário.

Se o proprietário de um protegível no primário for um usuário que tiver sido excluído da conta, a DR gerenciada não conseguirá transferir a propriedade para uma entidade que não existe mais. Nesse caso, a réplica protegível mantém a entidade de serviço do Azure Databricks como o proprietário. Para resolver isso, atribua um proprietário válido ao objeto protegível no primário e deixe a DR replicá-lo.

Requirements

• Um workspace no plano Premium nas regiões primária e secundária.

• O complemento Mission Critical está habilitado em ambos os espaços de trabalho. Consulte Habilitar missão crítica em ambos os espaços de trabalho.
• Computação sem servidor habilitada em ambos os workspaces. A computação sem servidor está disponível por padrão na maioria dos espaços de trabalho com o Unity Catalog habilitado. Consulte Conectar-se ao computador sem servidor.
• Função de administrador da conta com TODOS OS PRIVILÉGIOS em cada local externo usado pelos catálogos que você pretende replicar.
• SSO no nível da conta com todos os espaços de trabalho ativados e identidades sincronizadas com a conta por meio do SCIM, de modo que usuários, grupos e principais de serviço existam em ambas as regiões.
• Para URLs estáveis: uma URL personalizada provisionada para seu domínio Azure Databricks (contate sua equipe de conta) e o OAuth no nível da conta.
• Um workspace secundário e um metastore do Unity Catalog na região secundária, na mesma conta do Azure Databricks e na mesma nuvem da primária. O espaço de trabalho secundário deve corresponder à rede do principal, ao Link Privado e à configuração de chave gerenciada pelo cliente. O metastore secundário não deve conter catálogos que compartilhem nomes com catálogos replicados. Para a replicação de ativos do workspace, Azure Databricks exclui todos os ativos existentes no escopo no workspace secundário quando a replicação inicial é concluída. Os ativos fora do escopo não são afetados, portanto, o workspace secundário não precisa estar vazio.
• Uma localização externa correspondente e uma credencial de armazenamento correspondente na região secundária para cada uma das referenciadas nos catálogos primários. A DR gerenciada não replica automaticamente locais externos ou credenciais de armazenamento; você deve criá-los no secundário.

Como a computação sem servidor do workspace secundário lê do armazenamento de origem durante a replicação entre regiões, tanto o armazenamento de origem quanto o armazenamento secundário devem permitir o acesso de rede sem servidor do Azure Databricks em ambas as direções.

Se você restringir o acesso de rede ao armazenamento de origem ou à raiz do DBFS, também permita os endereços IP do plano de controle da região secundária no firewall do armazenamento de origem e os endereços IP do plano de controle da região primária no firewall do DBFS secundário. Para ver os endereços IP do plano de controle que devem ser permitidos em cada região, consulte Tráfego de entrada para o plano de controle do Azure Databricks.

• Um Conector de Acesso do Azure Databricks na região secundária com a função Colaborador de Dados do Blob de Armazenamento nas contas de armazenamento secundárias, adicionado como uma credencial de armazenamento no workspace secundário.
• Uma Configuração de Conectividade de Rede (NCC) na região secundária, atribuída ao workspace secundário, para que a computação sem servidor possa acessar o armazenamento por pontos de extremidade privados. Consulte Configuração de conectividade privada para recursos do Azure.
• Pontos de extremidade privados para todas as contas de armazenamento de origem e secundária referenciadas pelos catálogos replicados. Para o armazenamento ADLS Gen2, crie um endpoint privado para os sub-recursos dfs e blob em cada conta. Aprove-os no portal do Azure.

Habilitar a Missão Crítica em ambos os workspaces

Habilite o complemento Crítico nos workspaces primário e secundário antes de criar um grupo de failover. O uso de recursos computacionais em cada espaço de trabalho no qual você habilitar o complemento será cobrado pela tarifa Mission Critical. Entre em contato com sua equipe de conta Azure Databricks para obter a taxa atual.

1. No console da conta, clique em Workspaces e, em seguida, clique no workspace.
2. Clique na guia Complementos.
3. No cartão Missão Crítica, ative o botão e confirme.

Repita para o espaço de trabalho secundário.

Opcional: URL estável

Azure Databricks recomenda usar a URL estável. A URL estável sempre aponta para o espaço de trabalho primário atual, portanto os clientes que se conectam por meio dela não precisam ser reconfigurados após um failover. O URL original do workspace permanece válido para acesso direto a esse workspace, mas, após um failover, ele continua apontando para o primário anterior, agora o secundário. Aponte os seguintes clientes downstream na URL estável em vez da URL do workspace original:

• A interface do usuário da Web do Azure Databricks.
• Conexões JDBC e ODBC para data warehouses SQL.
• Solicitações diretas da API REST.

Há suporte a URLs estáveis com o Link Privado de front-end de entrada. Com o Link Privado de entrada, o URL estável usa seu URL personalizado com um ID de conexão estável, em vez do formato padrão de URL do workspace.

Configurar a replicação

Um novo grupo de failover faz a transição por meio de CREATING → INITIAL_REPLICATION → ACTIVE. O primeiro ciclo de replicação copia todos os dados no escopo para o secundário. Para espaços de trabalho grandes, o provisionamento inicial dos recursos do espaço de trabalho pode levar até duas semanas. Esta espera ocorre apenas uma vez. Após a conclusão da inicialização inicial, a replicação é executada continuamente.

Durante a replicação, os catálogos em escopo secundários são somente leitura, e a computação permanece indisponível no workspace secundário. Para executar consultas de validação sem gravação na instância secundária, o Azure Databricks recomenda um workspace de monitoramento somente leitura à parte na região secundária.

Para criar um grupo de failover:

1. No console da conta, clique em Resiliência.
2. Se você planeja usar uma URL estável, clique na guia URLs Estáveis e crie uma URL estável. Insira um nome, selecione o workspace primário atual e crie a URL estável. Aponte os clientes downstream (JDBC, ODBC, a interface web do Azure Databricks, solicitações diretas de API) para a URL estável em vez da URL original do workspace.
3. Clique na guia Grupos de failover e, em seguida, em Criar grupo de failover.
4. Preencha o formulário:
   • Nome do grupo de failover: Um nome que você escolhe para o grupo de failover.
   • Espaço de trabalho principal: O espaço de trabalho principal.
   • Espaço de trabalho secundário: O espaço de trabalho na região secundária.
   • Replicar ativos do workspace (opcional): desativado por padrão. Ative para replicar notebooks, trabalhos, warehouses SQL, clusters, painéis, arquivos e pastas (e as ACLs) do primário para o secundário. Requer que ambos os workspaces tenham o complemento Mission Critical habilitado. Se você ativar a replicação de ativos do workspace, o Azure Databricks excluirá todos os ativos existentes abrangidos pelo escopo no workspace secundário quando a replicação inicial estiver concluída. Ativos fora do escopo não são afetados.
   • URL estável (opcional): a URL estável que você criou na etapa 2.
   • Escopo de replicação: os catálogos a serem replicados. Você deve selecionar um workspace primário antes que esse campo esteja disponível.
   • Mapeamentos de armazenamento: para cada local externo que os catálogos replicados usam na região primária, adicione uma entrada que mapeia seu caminho de armazenamento para o local externo correspondente que você criou na região secundária (consulte Requisitos). Você pode usar * como um curinga para correspondência de prefixo.
5. Clique em Criar grupo de failover.

Por exemplo, um mapeamento de armazenamento do Azure pode mapear abfss://data@primary.dfs.core.windows.net/* para abfss://data@secondary.dfs.core.windows.net/*.

Recursos criados pela DR gerenciada

Quando você cria um grupo de failover, a DR gerenciada provisiona recursos do Unity Catalog auxiliares usados pelo pipeline de replicação para copiar dados entre regiões. Nos metastores primários e secundários, a DR gerenciada cria:

• Uma conexão que aponta para o espaço de trabalho na outra região.
• Um catálogo estrangeiro para cada catálogo replicado. O catálogo estrangeiro faz referência ao catálogo correspondente na outra região.

Esses recursos aparecem junto com seus próprios catálogos no Catalog Explorer. Você pode identificá-los pelo comentário, o que indica que a recuperação de desastre do Azure Databricks os cria e gerencia.

ID estável do espaço de trabalho

Algumas ferramentas identificam um workspace por seu ID de workspace em vez de seu URL, incluindo o provedor Terraform do Databricks e os Pacotes de Ativos do Databricks. Cada URL estável tem um ID estável do workspace que aponta para o primário atual, portanto essas ferramentas continuam apontando para o workspace ativo após um failover. Use o ID estável do workspace sempre que uma ferramenta solicitar um ID do workspace, da mesma forma que usaria um ID comum do workspace.

Para encontrar o ID estável do workspace, liste as URLs estáveis da sua conta com o Databricks CLI e leia o campo stable_workspace_id da URL estável correspondente:

databricks api get /api/disaster-recovery/v1/accounts/<account-id>/stable-urls

Implantar com Pacotes de Ativos do Databricks e Terraform

Os DABs (Pacotes de Ativos do Databricks) e o provedor Terraform do Databricks têm como alvo um workspace pelo URL do host do workspace ou por uma combinação do URL personalizado da conta do Azure Databricks e do ID do workspace. Para continuar implantando no primário atual após um failover, configure o host para usar seu URL personalizado — a parte de host do URL estável, não o URL original de cada workspace — e especifique o ID do workspace estável no campo workspace_id. Juntos, eles resolvem para o primário atual, para que os pipelines de CI/CD continuem sendo implantados no workspace ativo após um failover, sem nenhuma alteração de configuração.

• Novas implantações: use a URL personalizada e o ID estável do espaço de trabalho da primeira implantação.
• Implantações existentes: importe o estado do seu projeto anterior do Terraform para um novo projeto configurado com a URL personalizada e o ID estável do workspace e, em seguida, remova o projeto anterior. Não reaponte diretamente um projeto existente — a implantação não reconhece mais os recursos que criou usando o URL original de cada workspace, portanto, uma nova implantação os destrói e recria.
• DABs: habilite a replicação de ativos do workspace no grupo de failover. Um pacote armazena seu estado de implantação no workspace e esse estado atinge o novo primário apenas como parte da replicação de ativos do workspace.

Monitorar a replicação

A guia Grupos de failover mostra o estado atual, o ponto de replicação e eventuais erros ativos de cada grupo de failover. Possíveis estados:

Selecione o nome de um grupo de failover para abrir sua página de detalhes. A replicação é executada continuamente, mas o ponto de replicação mostra a última vez que todos os recursos no escopo foram copiados juntos. Os recursos individuais podem ser mais atuais, mas nem todos os dados após o ponto de replicação podem existir no secundário e podem ser perdidos durante o failover.

Quando um ponto de replicação é mostrado, tudo o que não está coberto por um erro foi replicado até esse ponto. Durante a replicação inicial, antes que exista o primeiro ponto de replicação, o grupo de failover ainda pode mostrar erros de bloqueio, mas ainda não mede a completude. Tipos de ativos que o DR gerenciado não suporta não aparecem na tabela do sistema system.replication.states. Confira Limitações. Para verificar um ativo específico, inspecione-o no secundário (veja Configurar replicação).

Para monitorar tendências históricas do RPO e ver os erros que estão bloqueando a replicação, consulte a tabela do system.replication.states sistema. Consulte a referência da tabela do sistema de replicação. Para obter as classes de erro mais comuns e como resolvê-las, consulte Referência.

Failover e failback

O mesmo procedimento abrange failovers planejados (testes de DR, manutenção programada) e failovers não planejados (uma interrupção regional). Para fazer failback, repita o procedimento com as regiões invertidas.

Quando você dispara um failover, o Azure Databricks:

• Aponta a URL estável, se anexada, para a nova região primária.
• Inverte a direção da replicação.
• Pausa agendamentos de trabalho no primário anterior.
• Faz a transição do grupo de failover de FAILING_OVER para INITIAL_REPLICATION.

Para fazer failover:

1. Notifique sua equipe de que um failover está sendo iniciado.

2. Somente para um failover planejado:

   1. No espaço de trabalho principal, encerre todos os clusters em execução e interrompa todos os depósitos SQL.
   2. Confirme se as gravações no primário foram interrompidas e aguarde até que a replicação seja atualizada. Para verificar, abra a página de detalhes do grupo de failover e confirme se o ponto de replicação está a poucos segundos do momento em que você interrompeu as gravações.

3. No console da conta, clique em Resiliência → Grupos de Failover e clique no nome do grupo de failover.

4. Clique em Fazer failover.

5. Selecione a nova região primária e confirme. O failover é concluído em minutos.

6. No novo primário, inicie a computação que estava em execução antes do failover. Os clusters replicados e os warehouses SQL chegam ao novo primário nos estados TERMINATED e STOPPED, respectivamente.

7. Retome manualmente os agendamentos de trabalho necessários no novo primário. Os agendamentos do primário anterior já estão pausados.

Os clientes conectados por meio da URL estável continuam funcionando após o failover. Redirecione os clientes que ainda usam a URL original do espaço de trabalho para a URL estável ou para a URL do espaço de trabalho da nova instância primária.

Desativar DR gerenciada

1. No console da conta, clique em Resiliência → Grupos de Failover e, em seguida, clique no nome do grupo de failover e exclua-o. Não é possível desativar o Mission Critical enquanto um grupo de failover estiver ativo no espaço de trabalho.
2. Para interromper a cobrança na taxa Crítica, desative Crítico em cada workspace na guia Complementos.

Limitações

A DR gerenciada tem as seguintes limitações:

• Não replicados: exibições materializadas, tabelas de streaming, pipelines do Lakeflow, dados de volume gerenciado (replicações de metadados), segredos do Unity Catalog e workspaces, modelos de ML, pontos de extremidade do serviço de modelo, índices de busca em vetores, compartilhamentos Delta, painéis de IA/BI publicados (rascunhos replicados) e Streaming Estruturado do Spark fora dos pipelines do Lakeflow. Tabelas com filtros de linha ou máscaras de coluna, e recursos marcados ABAC, são sinalizados como Falha na replicação na tabela do sistema, e essas falhas impedem o avanço do RPO até você remover o recurso do escopo do grupo de failover.
• As escritas em tabelas gerenciadas feitas por motores externos têm detectabilidade limitada. O DR gerenciado detecta alterações nas tabelas gerenciadas do Unity Catalog a partir de operações de gravação feitas pelos recursos de computação do Azure Databricks. Gravações feitas em uma tabela gerenciada replicada por um mecanismo externo (não Azure Databricks), por meio de APIs abertas, como o Catálogo REST do Iceberg, podem não ser detectadas; portanto, essas gravações podem não ser replicadas para a réplica secundária e podem ser perdidas durante o failover. Para tabelas replicadas com DR gerenciada, grave usando a computação do Azure Databricks.
• Catálogos secundários abrangidos pelo escopo são somente para leitura. Somente leitura só se aplica a entidades replicadas. Você ainda pode configurar a própria replicação de protegíveis fora do escopo da DR gerenciada. No entanto, você não pode executar a computação no workspace secundário, e a DR gerenciada está habilitada, o que limita a operação do pipeline de replicação por conta própria ali.
• Renomear um protegível do Unity Catalog dispara uma exclusão e uma recriação no secundário. Para tabelas gerenciadas, a renomeação replica novamente os dados da tabela no próximo ciclo. Evite renomear durante a replicação de estado estável.
• UNDROP não é propagado para o secundário.
• O bootstrap de ativo do workspace inicial pode demorar até 2 semanas para workspaces grandes.

• Usar o firewall de armazenamento do workspace nas contas de armazenamento do workspace usadas com a DR gerenciada requer configuração manual. Você deve permitir os endereços IP do plano de controle relevantes no firewall de armazenamento para que Azure Databricks possa replicar dados. Confira os Requisitos

Reference

Quando um recurso não pode ser replicado, o grupo de failover exibe uma classe de erro na tabela do system.replication.states sistema, juntamente com uma mensagem identificando o recurso afetado. As seções a seguir abrangem as classes de erro mais comuns e como resolvê-las. A replicação é recuperada automaticamente depois que você corrige o problema subjacente.

Para obter conceitos de dr e práticas recomendadas, consulte Recuperação de desastre.