Recuperação gerida de desastres

A recuperação de desastres gerida (DR) replica a sua implementação do Azure Databricks para uma região secundária para que possa recuperar de uma falha regional em minutos. O Azure Databricks gere o pipeline de replicação, o estado dos catálogos replicados no secundário e o processo de failover. Não escreve nem mantém scripts de replicação.

Para a abordagem manual da recuperação de desastres, incluindo conceitos gerais de DR e melhores práticas, consulte Recuperação em desastres.

O que é a recuperação gerida em caso de desastres?

A DR gerida está por cima dos espaços de trabalho e metastores que já operas. Trazes dois espaços de trabalho do Azure Databricks, um na tua região principal e outro na tua região secundária, e uma metastore em cada região. DR gerido anteriormente:

• Replica as categorias em que optas desde a primária até à secundária, num calendário contínuo. Ambas as categorias são opcionais de forma independente: metadados do Catálogo Unity e dados de tabelas geridas, e ativos de espaço de trabalho como cadernos, jobs, armazéns SQL, clusters e ACLs.
• Fornece um URL estável opcional, uma única cadeia de ligação que aponta sempre para o primário atual, para que os clientes continuem a funcionar após o failover sem reconfiguração.
• Permite-te ativar o failover quando quiseres, para um teste de DR ou uma falha real.

Os IDs dos recursos do espaço de trabalho são preservados entre regiões, pelo que os URLs que fazem referência a um recurso do espaço de trabalho pelo ID continuam a ser resolvidos após a comutação pós-falha.

O que é replicado

A DR gerida pode replicar o seguinte em cada ciclo de replicação. Ambas as categorias são opcionais, por isso pode ativar uma ou ambas:

• Metadados e dados do Unity Catalog: Tabelas geridas pelo Unity Catalog em Delta Lake com datas, tabelas externas e volumes (apenas metadados), vistas, 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 está aberta. Se a fonte estiver isolada e ligada ao workspace primário, a réplica é isolada e ligada ao workspace secundário.
• Recursos do espaço de trabalho: Blocos de notas, tarefas, armazéns de dados SQL, clusters, painéis de controlo IA/BI em rascunho, ficheiros e pastas, juntamente com as respetivas ACLs. Os armazéns SQL são replicados no estado STOPPED, e os clusters são replicados no estado TERMINATED. Os agendamentos de tarefas no sistema secundário estão suspensos.

Propriedade de objetos replicados

Quando a DR gerida cria um objeto protegível replicado (catálogo, esquema, tabela, vista, função ou volume) no ambiente secundário, o proprietário inicial é o principal de serviço do Azure Databricks que executa a replicação, porque o Unity Catalog atribui a propriedade à identidade que cria o objeto. O DR Gerido transfere então a propriedade da réplica para que corresponda à do securável correspondente na base de dados primária.

Se o titular de um seguro garantido no principal for um utilizador que foi eliminado da conta, a DR gerida não pode transferir a propriedade para um principal que já não existe. Neste caso, a réplica securável mantém o principal de serviço do Azure Databricks como seu proprietário. Para resolver isto, atribua um proprietário válido ao objeto protegível na instância primária e deixe que a DR o replique.

Requirements

• Um espaço de trabalho no plano Premium tanto nas regiões primária como secundária.

• A extensão Mission Critical ativada em ambos os espaços de trabalho. Veja Ativar Missão Crítica em ambos os espaços de trabalho.
• Computação serverless ativada em ambos os espaços de trabalho. O processamento sem servidor está disponível por predefinição na maioria dos espaços de trabalho com o Unity Catalog ativado. Consulte como se conectar à computação sem servidor.
• Função de administrador da conta com TODOS OS PRIVILÉGIOS sobre cada localização externa utilizada pelos catálogos que planeia replicar.
• SSO ao nível da conta com todos os espaços de trabalho ativados e identidades sincronizadas com a conta através do SCIM para que utilizadores, grupos e principais de serviço existam em ambas as regiões.
• Para URLs estáveis: um URL personalizado provisionado para o seu domínio Azure Databricks (contacte a sua equipa de conta) e um OAuth ao nível da conta.
• Um espaço de trabalho secundário e uma metastore do Unity Catalog na região secundária, na mesma conta do Azure Databricks e na mesma nuvem que o principal. O espaço de trabalho secundário deve corresponder à rede principal, ao Private Link e à configuração de chaves geridas pelo cliente. O metastore secundário não deve conter catálogos que tenham nomes em comum com catálogos replicados. Para a replicação de ativos de espaço de trabalho, o Azure Databricks elimina quaisquer ativos existentes dentro do âmbito no espaço secundário quando a replicação inicial termina. Os ativos fora do âmbito não são afetados, pelo que o espaço de trabalho secundário não precisa de estar vazio.
• Uma localização externa correspondente e uma credencial de armazenamento na região secundária por cada um dos elementos referenciados pelos seus catálogos primários. O DR gerido não replica automaticamente localizações externas ou credenciais de armazenamento; Tens de os criar no secundário.

Como a computação sem servidor do espaço de trabalho secundário lê do armazenamento de origem durante a replicação entre regiões, tanto o armazenamento de origem como o armazenamento secundário têm de permitir o acesso de rede sem servidor do Azure Databricks em ambos os sentidos.

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

• Um Azure Databricks Access Connector na região secundária com a função Storage Blob Data Contributor nas contas de armazenamento secundárias, adicionado como credencial de armazenamento no espaço de trabalho secundário.
• Uma Configuração de Conectividade de Rede (NCC) na região secundária, atribuída ao espaço de trabalho secundário, para que a computação sem servidor possa aceder ao armazenamento através de pontos de extremidade privados. Consulte Configurar conectividade privada para recursos do Azure.
• Endpoints privados para cada conta de origem e armazenamento secundário referenciados pelos teus catálogos replicados. Para o armazenamento ADLS Gen2, crie um ponto final privado para ambos os sub-recursos dfs e blob em cada conta. Aprove-os no portal do Azure.

Ativar o Mission Critical em ambos os espaços de trabalho

Ative o add-on Mission Critical tanto nos seus espaços de trabalho primários como secundários antes de criar um grupo de failover. A utilização de computação em cada espaço de trabalho onde ativar o suplemento é faturada à tarifa Mission Critical. Contacte a sua equipa de conta Azure Databricks para saber a taxa atual.

1. No console da conta, clique em Espaços de Trabalho e depois clique no espaço de trabalho.
2. Clique no separador de Complementos.
3. Na carta de Missão Crítica , ativa a opção de alternar e confirma.

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

Opcional: URL estável

O Azure Databricks recomenda usar a URL estável. O URL estável aponta sempre para o espaço de trabalho primário atual, pelo que os clientes que se ligam através desta não precisam de ser reconfigurados após um failover. O URL original do espaço de trabalho mantém-se válido para acesso direto a esse espaço de trabalho, mas após uma comutação por falha continua a apontar para o antigo primário, agora secundário. Aponte os seguintes clientes dependentes para o URL estável em vez do URL original da área de trabalho:

• A interface web do Azure Databricks.
• Ligações JDBC e ODBC a armazéns de dados SQL.
• Pedidos diretos à API REST.

URLs estáveis são suportados com o front-end (inbound) Private Link. Com o Private Link de entrada, o URL estável utiliza o seu URL personalizado com um identificador de ligação estável, em vez do formato de URL padrão da área de trabalho.

Configurar replicação

Um novo grupo de failover transita por CREATING → INITIAL_REPLICATION → ACTIVE. O primeiro ciclo de replicação copia todos os dados abrangidos para o sistema secundário. Para espaços de trabalho de grande dimensão, a configuração inicial do recurso do espaço de trabalho pode demorar até duas semanas. Esta espera ocorre apenas uma vez. Após a conclusão do bootstrap inicial, a replicação corre de forma contínua.

Durante a replicação, os catálogos secundários dentro do âmbito são apenas de leitura e a computação não está disponível no espaço de trabalho secundário. Para executar consultas de validação sem escrever na instância secundária, o Azure Databricks recomenda um espaço de trabalho de monitorização só de leitura separado na região secundária.

Para criar um grupo de failover:

1. Na consola da conta, clique em Resiliência.
2. Se tenciona usar um URL estável, clique no separador URLs estáveis e, em seguida, em Criar URL estável. Insira um nome, selecione o espaço de trabalho principal atual e crie a URL estável. Aponte os clientes downstream (JDBC, ODBC, a interface web do Azure Databricks, pedidos diretos à API) para o URL estável em vez do URL original do espaço de trabalho.
3. Clique no separador Grupos de failover , depois Criar grupo de failover.
4. Preencha o formulário:
   • Nome do grupo de failover: O nome que escolhe para o grupo de failover.
   • Espaço de trabalho primário: O espaço de trabalho que é o seu espaço principal.
   • Espaço de trabalho secundário: O espaço de trabalho na região secundária.
   • Duplicar recursos do espaço de trabalho (opcional): Desativado por predefinição. Ative esta opção para replicar blocos de notas, tarefas, armazéns de SQL, clusters, painéis, ficheiros e pastas (e as respetivas ACLs) da principal para a secundária. Requer que ambos os espaços de trabalho tenham o add-on Mission Critical ativado. Se ativares a replicação de ativos de workspace, o Azure Databricks elimina quaisquer ativos existentes dentro do âmbito secundário quando a replicação inicial termina. Os ativos fora do âmbito não são afetados.
   • URL estável (opcional): O URL estável que criaste no passo 2.
   • Âmbito de replicação: Os catálogos a replicar. Deve selecionar um espaço de trabalho principal antes de este campo estar disponível.
   • Mapeamentos de armazenamento: Para cada localização externa que os seus catálogos replicados usam na região primária, adicione uma entrada que mapeie o seu caminho de armazenamento para a localização externa correspondente que criou na região secundária (ver Requisitos). Podes usar * como coringa para emparelhar prefixos.
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 gerida

Ao criar um grupo de failover, a DR gerida aprovisiona recursos auxiliares do Unity Catalog que o processo de replicação utiliza para copiar dados entre regiões. Quer nas metastores primárias quer nas secundárias, a DR gerida 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.

Estes recursos aparecem juntamente com os seus próprios catálogos no Explorador de Catálogos. Pode identificá-los pelo comentário, que refere que o Azure Databricks de recuperação de desastres os criou e gere.

ID de espaço de trabalho estável

Algumas ferramentas identificam um espaço de trabalho pelo seu ID de espaço de trabalho em vez do seu URL, incluindo o fornecedor Databricks Terraform e os Databricks Asset Bundles. Cada URL estável tem um ID estável do espaço de trabalho que aponta para o principal atual, pelo que estas ferramentas continuam a apontar para o espaço de trabalho ativo após um failover. Use o ID de espaço de trabalho estável sempre que uma ferramenta peça um ID de espaço de trabalho, da mesma forma que usaria um ID de espaço de trabalho normal.

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

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

Implementar com Databricks Asset Bundles e Terraform

Os Databricks Asset Bundles (DABs) e o fornecedor Databricks Terraform direcionam um espaço de trabalho quer pela URL do seu anfitrião do espaço de trabalho, quer por uma combinação do URL personalizado da conta Azure Databricks e do ID do espaço de trabalho. Para continuar a fazer implementações no primário atual após um failover, defina o host como o seu URL personalizado — a parte do 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, resolvem para o principal atual, por isso os teus pipelines CI/CD continuam a ser implementados para o workspace ativo após um failover, sem qualquer alteração de configuração.

• Novas implementações: use o URL personalizado e o ID estável do espaço de trabalho da primeira implementação.
• Implementações existentes: importa o estado do teu projeto anterior do Terraform para um novo projeto configurado com o URL personalizado e o ID do espaço de trabalho estável, depois remove o projeto anterior. Não redirecione diretamente um projeto existente — a implantação já não reconhece os recursos que criou com base no URL original por espaço de trabalho, pelo que uma nova implantação os destrói e recria.
• DABs: ative a replicação de ativos do espaço de trabalho no grupo de ativação pós-falha. Um pacote armazena o estado da sua implementação no espaço de trabalho, e esse estado só chega ao novo nó primário como parte da replicação dos recursos do espaço de trabalho.

Monitorizar a replicação

O separador Grupos de ativação pós-falha mostra o estado atual de cada grupo de ativação pós-falha, o ponto de replicação e quaisquer erros ativos. Estados possíveis:

Selecione o nome de um grupo de failover para abrir a página de detalhes. A replicação é executada continuamente, mas o ponto de replicação indica a última vez em que todos os recursos abrangidos pelo âmbito foram copiados em conjunto. Os recursos individuais podem estar mais atualizados, 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 de existir o primeiro ponto de replicação, o grupo de failover ainda pode mostrar erros de bloqueio, mas ainda não mede a completude. Os tipos de ativos que a DR gerida não suporta de todo não aparecem na system.replication.states tabela do sistema. Consulte Limitações. Para verificar um ativo específico, inspecione-o no secundário (ver Configurar replicação).

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

Comutação por falha e retorno por falha

O mesmo procedimento abrange comutações planeadas (testes de recuperação após desastre, manutenção programada) e comutações não planeadas (uma falha regional). Para reverter, repita o procedimento com as regiões invertidas.

Quando desencadeias um failover, Azure Databricks:

• Aponta a URL estável, se anexada, para a nova região primária.
• Inverte a direção da replicação.
• Pausa os horários de trabalho na antiga primária.
• Transita o grupo de failover de FAILING_OVER para INITIAL_REPLICATION.

Para fazer fail-over:

1. Avise a sua equipa de que está a iniciar um failover.

2. Apenas para um failover planeado:

   1. Na área de trabalho principal, termine todos os clusters em execução e pare todos os armazéns de dados SQL.
   2. Confirme que as operações de escrita no primário foram interrompidas e, em seguida, aguarde que a replicação fique sincronizada. Para verificar, abra a página de detalhes do grupo de failover e confirme que o ponto de replicação está a poucos segundos da hora a que interrompeu as operações de escrita.

3. Na consola da conta, clique em Resiliência → Grupos de failover e, em seguida, clique no nome do grupo de failover.

4. Clique em Fail over.

5. Selecione a nova região principal e confirme. O failover termina em minutos.

6. No novo primário, inicia o cálculo que estava a correr antes do failover. Os clusters replicados e os armazéns de dados SQL chegam ao novo primário nos estados TERMINATED e STOPPED, respetivamente.

7. Retoma manualmente os horários de trabalho de que precisas no novo primário. Os calendários das antigas primárias já estão suspensos.

Os clientes ligados através do URL estável continuam a funcionar após o failover. Redirecione os clientes que ainda utilizam o URL original da área de trabalho para o URL estável ou para o URL da nova área de trabalho principal.

Desmontar DR gerida

1. Na consola da conta, clique em Resiliência → Grupos de ativação pós-falha e, em seguida, clique no nome do grupo de ativação pós-falha e elimine-o. Não pode desligar o Mission Critical enquanto um grupo de failover estiver ativo no workspace.
2. Para parar a faturação à tarifa Mission Critical, desative o Mission Critical em cada espaço de trabalho no separador Add-ons.

Limitations

A DR gerida tem as seguintes limitações:

• Não são replicados: vistas materializadas, tabelas de streaming, pipelines do Lakeflow, dados de volumes geridos (os metadados são replicados), segredos do Unity Catalog e do espaço de trabalho, modelos de ML, pontos finais de disponibilização de modelos, índices de pesquisa vetorial, partilhas Delta, painéis de IA/BI publicados (os rascunhos são replicados) e Spark Structured Streaming fora dos pipelines do Lakeflow. Tabelas com filtros de linha ou máscaras de colunas e recursos etiquetados com ABAC são assinaladas como Falha na replicação na tabela de sistema, e estas falhas impedem o cumprimento do RPO até remover o recurso do âmbito do grupo de failover.
• As operações de escrita em tabelas geridas realizadas por motores externos têm capacidade de deteção limitada. O DR gerido deteta alterações nas tabelas geridas do Unity Catalog a partir de escritas feitas pelo Azure Databricks compute. As escritas efetuadas numa tabela gerida replicada por um motor externo (que não seja o Azure Databricks), através de APIs abertas, como o Iceberg REST Catalog, podem não ser detetadas, pelo que essas escritas podem não ser replicadas para o sistema secundário e podem perder-se durante o failover. Para tabelas que replicas com DR gerido, escreve através do Azure Databricks compute.
• Os catálogos secundários dentro do âmbito são apenas de leitura. Apenas leitura aplica-se apenas a entidades replicadas. Ainda podes configurar a tua própria replicação para seguráveis fora do âmbito da DR gerida. No entanto, não é possível executar cargas de trabalho de computação no espaço de trabalho secundário enquanto a recuperação após desastre (DR) gerida estiver ativada, o que limita a possibilidade de operar nesse local um pipeline de replicação autogerido.
• Mudar o nome de um objeto protegível do Unity Catalog aciona uma eliminação e uma recriação no secundário. Para tabelas geridas, a renomeação re-replica os dados da tabela no ciclo seguinte. Evite mudar de nome durante a replicação em regime estacionário.
• UNDROP não é propagado para o secundário.
• A inicialização inicial dos recursos do espaço de trabalho pode demorar até 2 semanas em espaços de trabalho de grande dimensão.

• A utilização do firewall de armazenamento do espaço de trabalho nas contas de armazenamento do espaço de trabalho utilizadas com recuperação após desastre gerida requer configuração manual. Deve permitir que os endereços IP relevantes do plano de controlo estejam no firewall de armazenamento para que o Azure Databricks possa replicar os dados. Consulte Requisitos.

Reference

Quando um recurso não pode ser replicado, o grupo de failover apresenta uma classe de erro na system.replication.states tabela do sistema, juntamente com uma mensagem que identifica o recurso afetado. As secções seguintes abordam as classes de erro mais comuns e como resolvê-las. A replicação recupera automaticamente depois de corrigir o problema subjacente.

Para conceitos e melhores práticas de DR, veja Recuperação de Desastres.