Recuperação de desastre

Artigo
10/02/2024

Um padrão claro de recuperação de desastre é essencial para uma plataforma de análise de dados nativa de nuvem, como o Azure Databricks. É essencial que suas equipes de dados possam usar a plataforma Azure Databricks mesmo no caso raro de uma paralisação do provedor de serviços de nuvem em todo o serviço regional, causada seja por um desastre regional, como um furacão ou terremoto, ou outra problema.

O Azure Databricks costuma ser uma parte essencial de um ecossistema de dados geral que inclui muitos serviços, incluindo serviços de ingestão de dados upstream (lote/streaming), armazenamento nativo em nuvem, como ADLS gen2 (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure), ferramentas e serviços downstream, como aplicativos de business intelligence e ferramentas de orquestração. Alguns dos seus casos de uso podem ser particularmente suscetíveis a uma paralisação regional em todo o serviço.

Este artigo descreve conceitos e melhores práticas para uma solução de recuperação de desastre inter-regionais bem-sucedida para a plataforma Databricks.

Garantias de alta disponibilidade dentro da região

Embora o restante deste tópico se concentre na implementação da recuperação de desastre entre regiões, é importante entender as garantias de alta disponibilidade que o Azure Databricks fornece dentro de uma única região. As garantias de alta disponibilidade dentro da região abrangem os seguintes componentes:

Disponibilidade do painel de controle do Azure Databricks

A maioria dos serviços do painel de controle está em execução em clusters do Kubernetes e lidará com a perda de VMs em AZ específica automaticamente.
Os dados do workspace são armazenados em bancos de dados com armazenamento premium, replicados em toda a região. O armazenamento do banco de dados (servidor único) não é replicado em diferentes AZs ou regiões. Se a interrupção da zona afetar o armazenamento do banco de dados, o banco de dados será recuperado trazendo uma nova instância do backup.
As contas de armazenamento usadas para atender imagens DBR também são redundantes dentro da região e todas as regiões têm contas de armazenamento secundárias que são usadas quando a primária está inativa. Confira Regiões do Azure Databricks.
Em geral, a funcionalidade do painel de controle deve ser restaurada dentro de aproximadamente 15 minutos após a recuperação da zona de disponibilidade.

Disponibilidade do plano de computação

A disponibilidade do workspace depende da disponibilidade do painel de controle (conforme descrito acima).
Os dados na raiz DBFS não serão afetados se a conta de armazenamento da Raiz DBFS estiver configurada com ZRS ou GZRS (o padrão é GRS).
Os nós dos clusters são extraídos das diferentes zonas de disponibilidade solicitando nós do provedor de computação do Azure (exigindo capacidade suficiente nas zonas restantes para atender à solicitação). 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 única exceção é quando o nó do driver é perdido. Nesse caso, o gerenciador de cluster ou trabalho os reiniciará.

Visão geral da recuperação de desastres

A recuperação de desastre envolve um conjunto de políticas, ferramentas e procedimentos que permitem a recuperação ou a continuação de sistemas e infraestrutura de tecnologia vitais após um desastre natural ou induzido por humanos. Um grande serviço de nuvem, como o Azure, atende muitos clientes e tem proteção integrada contra uma falha individual. Por exemplo, uma região é um grupo de edifícios conectados a diferentes fontes de energia para garantir que a perda individual de energia não desligue uma região. No entanto, podem ocorrer falhas na região da nuvem e o grau de interrupção e seu impacto na organização podem variar.

Antes de implementar um plano de recuperação de desastre, é importante entender a diferença entre a recuperação de desastre (DR) e a alta disponibilidade (HA).

A alta disponibilidade é uma característica de resiliência de um sistema. A alta disponibilidade garante um nível mínimo de desempenho operacional que geralmente é definido em termos de tempo de atividade consistente ou percentual de tempo de atividade. A alta disponibilidade é implementada (na mesma região que o sistema primário) projetando-a como um recurso do sistema primário. Por exemplo, serviços de nuvem como o Azure têm serviços de alta disponibilidade, como o ADLS gen2 (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure). A alta disponibilidade não exige uma preparação explícita significativa por parte do cliente do Azure Databricks.

Por outro lado, um plano de recuperação de desastre requer decisões e soluções que funcionem para uma organização específica para que ela consiga administrar uma paralisação regional maior de sistemas críticos. Este artigo discute a terminologia comum de recuperação de desastre, soluções comuns e algumas práticas recomendadas para planos de recuperação de desastres com o Azure Databricks.

Terminologia

Terminologia de região

Este artigo usa as seguintes definições para regiões:

Região primária: região geográfica na qual os usuários executam cargas de trabalho típicas e diárias de análise de dados interativas e automatizadas.
Região secundária: região geográfica na qual as equipes de IT movem cargas de trabalho de análise de dados temporariamente durante uma paralisação na região primária.
Armazenamento com redundância geográfica: o Azure tem armazenamento com redundância geográfica entre regiões para armazenamento persistente usando um processo assíncrono de replicação de armazenamento.

Importante

Para processos de recuperação de desastre, o Databricks recomenda que você não dependa do armazenamento com redundância geográfica para duplicação de dados entre regiões, como ADLS gen2 (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) que o Azure Databricks cria para cada workspace em sua assinatura do Azure. Em geral, use o Deep Clone para tabelas do Delta e converta os dados no formato Delta para usar o Deep Clone. Se possível, converta para outros formatos de dados.

Terminologia de status de implantação

Este artigo usa as seguintes definições de status de implantação:

Implantação ativa: os usuários podem se conectar a uma implantação ativa de um workspace do Azure Databricks e executar cargas de trabalho. Os trabalhos são agendados periodicamente usando o agendador do Azure Databricks ou outro mecanismo. Os fluxos de dados também podem ser executados nessa implantação. Alguns documentos podem se referir a uma implantação ativa como uma implantação quente.
Implantação passiva: os processos não executam em uma implantação passiva. As equipes de IT podem configurar procedimentos automatizados para implantar um código, configuração e outros objetos do Azure Databricks em uma implantação passiva. Uma implantação se tornará ativa somente se a implantação ativa atual não estiver executando. Alguns documentos podem se referir a uma implantação ativa como uma implantação fria.

Importante

Opcionalmente, um projeto pode incluir várias implantações passivas em regiões diferentes para fornecer opções adicionais para resolver as paralisações regionais.

Em termos gerais, uma equipe tem apenas uma implantação ativa por vez, no que é chamado de estratégia ativa-passiva de recuperação de desastre. Há uma estratégia de solução de recuperação de desastre menos comum chamada ativa-ativa, na qual há duas implantações ativas simultâneas.

Terminologia do setor de recuperação de desastre

Há dois termos importantes do setor que você deve entender e definir para sua equipe:

Objetivo do ponto de recuperação: um objetivo do ponto de recuperação (RPO) é o período máximo no qual os dados (transações) podem ser perdidos de um serviço de IT devido a um incidente grave. A implantação do Azure Databricks não armazena os dados principais do cliente. Isso é armazenado em sistemas separados, como ADLS gen2 (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou outras fontes de dados sob seu controle. O painel de controle do Azure Databricks armazena partes ou os objetos inteiros, como trabalhos e notebooks. No Azure Databricks, o RPO é definido como o período máximo no qual objetos como alterações de trabalho e notebook podem ser perdidos. Além disso, você é responsável por definir o RPO dos dados de seus próprios cliente no ADLS gen2 (para workspaces criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou outras fontes de dados sob seu controle.
Objetivo do tempo de recuperação: o objetivo do tempo de recuperação (RTO) é a duração prevista do tempo e um nível de serviço no qual um processo empresarial deve ser restaurado após um desastre.

Recuperação de desastre e dados corrompidos

Uma solução de recuperação de desastre não reduz os dados corrompidos. Os dados corrompidos na região primária são replicados da região primária para uma região secundária e ficam corrompidos em ambas as regiões. Há outras maneiras de reduzir esse tipo de falha, por exemplo, viagem no tempo do Delta.

Fluxo de trabalho típico de recuperação

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

Ocorre uma falha em um serviço crítico que você usa na região primária. Pode ser um serviço de fonte de dados ou uma rede que afeta a implantação do Azure Databricks.
Você investiga a situação com o provedor de nuvem.
Se você concluir que a sua empresa não pode aguardar a correção do problema na região primária, poderá decidir que precisa de failover em uma região secundária.
Verifica se o mesmo problema também não afeta a região secundária.
Faz o failover na região secundária.
1. Para todas as atividades no workspace. Os usuários param as cargas de trabalho. Os usuários ou administradores são instruídos a fazer um backup das alterações recentes, se possível. Os trabalhos serão parados, se ainda não tiverem falhado devido ao problema.
2. Inicia o procedimento de recuperação na região secundária. O procedimento de recuperação atualiza o roteamento e a renomeação das conexões e do tráfego para a região secundária.
3. Após o teste, declara que a região secundária está operacional. As cargas de trabalho de produção agora podem ser retomadas. Agora, os usuários podem fazer logon na implantação ativa. Você pode recuperar trabalhos agendados ou atrasados.
Para ver as etapas detalhadas em um contexto do Azure Databricks, confira Testar failover.
Em algum momento, o problema na região primária é mitigado e você confirma esse fato.
Restaura (failback) a região primária.
1. Para todo o trabalho na região secundária.
2. Inicia o procedimento de recuperação na região primária. O procedimento de recuperação gerencia o roteamento e a renomeação do tráfego e da conexão de volta para a região primária.
3. Replica os dados de volta para a região primária conforme necessário. Para reduzir a complexidade, talvez minimiza a quantidade de dados que precisam ser replicados. Por exemplo, se alguns trabalhos são somente leitura quando executados na implantação secundária, talvez você não precise replicar esses dados de volta na implantação primária da região primária. No entanto, você pode ter um trabalho de produção que precise ser executado e necessita que os dados sejam replicados de volta na região primária.
4. Teste a implantação na região primária.
5. Declare que a região primária está operacional e que ela é a implantação ativa. Retome as cargas de trabalho de produção.
Para obter mais informações sobre como restaurar a região primária, consulte Restauração de teste (failback).

Importante

Durante essas etapas, podem ocorrer perdas de dados. Sua organização deve definir quanta perda de dados é aceitável e o que se pode fazer para mitigar essa perda.

Etapa 1: entender as necessidades de negócios

A primeira etapa é definir e entender as necessidades de negócios. Defina quais serviços de dados são críticos e qual é o RPO e RTO esperados.

Pesquise a tolerância do mundo real de cada sistema e lembre-se de que o failover e o failback da recuperação de desastre podem ser custosos e trazem outros riscos. Os outros riscos podem incluir dados corrompidos, dados duplicados (se você gravar no local de armazenamento errado) e usuários que fazem logon e executam alterações nos locais errados.

Mapeie todos os pontos de integração do Azure Databricks que afetam os negócios:

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

Determine as ferramentas ou as estratégias de comunicação que podem apoiar o plano de recuperação de desastre:

Quais ferramentas serão usadas para modificar as configurações de rede rapidamente?
Você pode predefinir a configuração e torná-la modular para acomodar as soluções de recuperação de desastres de maneira natural e passível de manutenção?
Quais ferramentas e canais de comunicação notificarão as equipes internas e terceiras (integrações, consumidores de downstream) sobre o failover de recuperação de desastre e as alterações do failback? E como você confirmará que eles entenderam tudo?
Quais ferramentas ou suporte especial serão necessários?
Quais serviços estão em funcionamento (se alguns serão desligados até a completa recuperação)?

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

A solução precisa replicar os dados corretos no painel de controle, no plano de computação e nas fontes de dados. Os espaços de trabalho redundantes para a recuperação de desastre devem ser mapeados para diferentes planos de controle em diferentes regiões. Você deve manter esses dados sincronizados periodicamente usando uma solução baseada em script, uma ferramenta de sincronização ou um fluxo de trabalho de CI/CD. Não há necessidade de sincronizar dados na própria rede do plano de computação, como nas funções de trabalho do Databricks Runtime.

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

Além disso, você precisa garantir que as fontes de dados sejam replicadas conforme necessário nas regiões.

Recuperação de desastre - O que precisa ser replicado?

Práticas recomendadas gerais

As melhores práticas gerais para um plano de recuperação de desastres bem-sucedido incluem:

Entender quais processos são essenciais para os negócios e precisam ser executados na recuperação de desastre.
Identificar claramente quais serviços estão envolvidos, quais dados estão sendo processados, qual é o fluxo de dados e onde ele está armazenado
Isolar os serviços e os dados o máximo possível. Por exemplo, crie um contêiner especial de armazenamento em nuvem para os dados da recuperação de desastre ou mova os objetos do Azure Databricks que são necessários durante o desastre para um espaço de trabalho separado.
É sua responsabilidade manter a integridade entre as implantações primárias e secundárias para outros objetos que não estão armazenados no plano de controle do Databricks.

Aviso

É uma prática recomendada não armazenar dados na raiz ADLS gen2 (para espaços de trabalho criados antes de 6 de março de 2023, Azure Blob Storage) que é usado para acesso raiz DBFS para o espaço de trabalho. Esse armazenamento raiz DBFS não é compatível com dados de produção do cliente. A Databricks também recomenda não armazenar bibliotecas, arquivos de configuração ou scripts de inicialização nesse local.
Para fontes de dados, sempre que possível, recomenda-se usar ferramentas nativas do Azure na replicação e redundância para replicar dados para as regiões de recuperação de desastre.

Escolher uma estratégia de solução de recuperação

Soluções típicas de recuperação de desastre envolvem dois (ou possivelmente mais) espaços de trabalho. Há várias estratégias que você pode escolher. Considere o possível período de interrupção (horas ou talvez até um dia), o esforço para garantir que o espaço de trabalho esteja totalmente operacional e o esforço de restauração (failback) para a região primária.

Estratégia de solução ativa-passiva

Uma solução ativa-passiva é a solução mais comum e a mais fácil, sendo que esse tipo de solução é o foco deste artigo. Uma solução ativa-passiva sincroniza os dados e as alterações de objetos da implantação ativa com a implantação passiva. Se preferir, você pode ter várias implantações passivas em regiões diferentes, mas este artigo se concentra na abordagem de uma só implantação passiva. Durante um evento de recuperação de desastre, a implantação passiva na região secundária se torna a implantação ativa.

Há duas variantes principais dessa estratégia:

Solução unificada (corporativa): exatamente um conjunto de implantações ativas e passivas que apoiam toda a organização.
Solução por departamento ou projeto: cada departamento ou domínio de projeto mantém uma solução de recuperação de desastres separada. Algumas organizações desejam desassociar detalhes de recuperação de desastre entre departamentos e usar regiões primárias e secundárias diferentes para cada equipe com base nas necessidades exclusivas de cada equipe.

Há outras variantes, como usar uma implantação passiva para casos de uso de somente leitura. Se você tiver cargas de trabalho que são somente leitura (por exemplo, consultas de usuário), elas poderão ser executadas em uma solução passiva a qualquer momento, caso não modifiquem dados ou objetos do Azure Databricks, como notebooks ou trabalhos.

Estratégia de solução ativa-ativa

Em uma solução ativa-ativa, você executa todos os processos de dados em ambas as regiões em todos os momentos simultaneamente. Sua equipe de operações deve garantir que um processo de dados, como um trabalho, seja marcado como concluído somente quando termina com ê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.

Uma solução ativa-ativa é a estratégia mais complexa e, como os trabalhos são executados em ambas as regiões, há um custo financeiro adicional.

Assim como acontece com a estratégia ativa-passiva, você pode implementá-la como uma solução unificada da organização ou por departamento.

Talvez você não precise de um espaço de trabalho equivalente no sistema secundário para todos os espaços de trabalho, dependendo do fluxo de trabalho. Por exemplo, talvez um espaço de trabalho de desenvolvimento ou de preparo não precise ser duplicado. Com um pipeline de desenvolvimento bem projetado, você poderá reconstruir esses espaços de trabalho facilmente, se necessário.

Escolha suas ferramentas

Há duas abordagens principais para que as ferramentas mantenham os dados o mais semelhante possível entre os espaços de trabalho nas regiões primárias e secundárias:

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 em uma base agendada.
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 enviar por push o código e os ativos do preparo/desenvolvimento para a produção, um sistema de CI/CD o disponibilizará 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 implementada em conjunto com espaços de trabalho primários e secundários, enquanto alguns artefatos podem precisar ser implantados somente após um evento de recuperação de desastre. Para obter as ferramentas, consulte scripts de automação, exemplos e protótipos.

O diagrama a seguir compara essas duas abordagens.

Opções de recuperação de desastre

Dependendo das 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 administrar diferentes tipos de dados com cada opção de ferramentas.

Descrição	Como administrar ferramentas CI/CD	Como administrar ferramentas 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 da primária para a secundária.
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. Implante em conjunto tanto para a primária quanto para a secundária. No entanto, `min_idle_instances` na secundária deve ser zero até o evento de recuperação de desastre.	Pools criados com qualquer `min_idle_instances` quando são sincronizados com o espaço de trabalho secundário usando a API ou a CLI.
Configurações de trabalho	Podem ser modelos no Git. Para a implantação primária, implante a definição de trabalho assim como ela está. Para a implantação secundária, implante o trabalho e defina as concorrências como zero. Isso desabilita o trabalho nessa implantação e impede execuções extras. 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 recuperação de desastre.	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	Inclua 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 desastre de dados.
Metadados da tabela	Inclua no código-fonte se for criado somente por meio de trabalhos baseados em notebook ou da API de comando. Isso se aplica ao metastore interno do Azure Databricks ou ao metastore externo configurado.	Compare as definições de metadados entre os metastores usando a API de catálogo do Spark ou o Show Create Table por meio de notebook ou scripts. Observe que as tabelas do armazenamento subjacente podem ser baseadas em região e serão diferentes entre as instâncias do metastore.
Segredos	Inclua no código-fonte se for criado somente por meio da API de comando. Observe que alguns conteúdos de segredos podem precisar ser mudados entre o primário e o secundário.	Os segredos são criados em ambos os espaços de trabalho por meio da API. Observe que alguns conteúdos de segredos podem precisar ser mudados entre o primário e o secundário.
Configurações de cluster	Podem ser modelos no Git. Implante em conjunto as implantações primárias e secundárias, embora aquelas na implantação secundária devam ser encerradas até o evento da recuperação de desastre.	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.

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

Você precisa de controle total do gatilho da recuperação de desastre. Você pode disparar isso a qualquer momento ou por qualquer motivo. Você deve assumir a responsabilidade pela estabilização da recuperação de desastre antes de reiniciar o modo de failback da operação (produção normal). Normalmente, isso significa que você precisa criar vários espaços de trabalho do Azure Databricks para atender às necessidades da recuperação de desastre e da produção e escolher a região secundária do failover.

No Azure, verifique a replicação de dados, bem como a disponibilidade dos tipos de produto e VM.

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

Se um espaço de trabalho já estiver em produção, é comum executar uma operação de cópia única para sincronizar a implantação passiva com a implantação ativa. Esta cópia que é feita uma única vez trata o seguinte:

Replicação de dados: replique usando uma solução de replicação em nuvem ou uma operação de clonagem Delta Deep.
Geração de token: use a geração de token para automatizar a replicação e as cargas de trabalho futuras.
Replicação de espaço de trabalho: use a replicação de espaços de trabalho usando os métodos descritos na Etapa 4: preparar as fontes de dados.
Validação do espaço de trabalho: teste para certificar-se de que o espaço de trabalho e o processo podem ser executados com êxito e forneçam os resultados esperados.

Após a operação inicial de cópia única, as ações de cópia e sincronização subsequentes são mais rápidas, e qualquer registro em log das ferramentas também é um log do que mudou e quando mudou.

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 lotes de fontes de dados

Quando os dados são processados em lote, geralmente residem em uma fonte de dados que pode ser replicada facilmente ou entregue em outra região.

Por exemplo, os dados podem ser carregados regularmente em um local de armazenamento em nuvem. No modo de recuperação de desastre para a região secundária, você deve garantir que os arquivos serão carregados no armazenamento da região secundária. As cargas de trabalho devem ler o armazenamento da região secundária e gravar no armazenamento da região secundária.

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 e processados e enviados para uma solução de streaming:

Fila de mensagens, como o 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 recuperação de desastre 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 da nuvem com base no arquivo.

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

Teste periodicamente a configuração de recuperação de desastre para garantir que ela está funcionando corretamente. Não há razão em manter uma solução de recuperação de desastre se você não puder usá-la quando precisar. Algumas empresas alternam entre regiões a cada alguns meses. Alternar regiões em uma programação regular testa as premissas e os processos e garante que eles atendam às necessidades de recuperação. Também assegura que a organização conheça as políticas e os procedimentos de emergências.

Importante

Teste regularmente a solução de recuperação de desastres sob as condições do mundo real.

Se você descobrir que está faltando um objeto ou modelo e ainda precisa das informações armazenadas no espaço de trabalho primário, modifique o plano para remover esses obstáculos, replique essas informações no sistema secundário ou disponibilize-as de alguma outra forma.

Teste todas as alterações organizacionais necessárias nos processos e na configuração em geral. O plano de recuperação de desastres afeta o pipeline de implantação e é importante que a equipe saiba o que precisa ser mantido em sincronia. Depois de configurar os espaços de trabalho de recuperação de desastre, você deve garantir que a infraestrutura (manual ou por código), trabalhos, notebooks, bibliotecas e outros objetos do espaço de trabalho estejam disponíveis na região secundária.

Converse com a equipe sobre como expandir os processos de trabalho padrão e pipelines de configuração para implantar as alterações em todos os espaços de trabalho. Gerencie as identidades de usuário em todos os espaços de trabalho. Lembre-se de configurar as ferramentas como a automação de trabalho e o monitoramento de novos espaços de trabalho.

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

Ingestão: entenda onde estão as fontes de dados e onde essas fontes obtêm os dados. Sempre que possível, parametrize a origem e garanta que você tenha um modelo de configuração separado para trabalhar com as implantações secundárias e regiões secundárias. Prepare um plano de failover e teste todas as premissas.
Alterações de execução: se você tiver um agendador para disparar trabalhos ou outras ações, talvez seja necessário configurar um agendador separado que funcione com a implantação secundária ou as fontes de dados dela. Prepare um plano de failover e teste todas as premissas.
Conectividade interativa: analise 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. Prepare um plano de failover e teste todas as premissas.
Alterações de automação: para todas as ferramentas de automação, prepare um plano de failover e teste todas as premissas.
Saídas: para todas as ferramentas que geram logs ou dados de saída, prepare um plano de failover e teste todas as premissas.

Testar failover

A recuperação de desastre pode ser disparada por vários cenários diferentes. Ele pode ser disparado por uma interrupção inesperada. Algumas funcionalidades essenciais podem estar inativas, incluindo a rede em nuvem, o armazenamento em nuvem ou outro serviço crítico. Você não tem acesso para desligar o sistema normalmente e deve tentar recuperá-lo. No entanto, o processo poderia ser disparado por um desligamento ou uma interrupção planejada, ou até mesmo pela alternância periódica das implantações ativas entre duas regiões.

Para testar o failover, conecte-se ao sistema e execute um processo de desligamento. Verifique se todos os trabalhos foram concluídos e se os clusters foram encerrados.

Um cliente de sincronização (ou ferramentas de CI/CD) pode replicar os objetos e recursos relevantes do Azure Databricks para o workspace secundário. Para ativar o workspace secundário, o processo pode incluir alguns ou todos a seguir:

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.
Processo de recuperação:
1. Verifique a data dos dados sincronizados mais recentemente. Confira a Terminologia do setor de recuperação de desastre. Os detalhes dessa etapa variam de acordo com a maneira como se sincroniza os dados e as necessidades exclusivas de negócios.
2. Estabilize as fontes de dados e garante que todas elas estão disponíveis. Inclua todas as fontes de dados externas, como o SQL do Azure Cloud, bem como o Delta Lake, Parquet ou outros arquivos.
3. Encontre o 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 duplicações (o Delta Lake facilita isso).
4. Conclua o processo de fluxo de dados e informe os usuários.
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. O URL voltado para o cliente do aplicativo Web do Azure Databricks muda quando o plano de controle muda, portanto, notifique os usuários da organização sobre o novo URL.

Restauração de teste (failback)

O failback é mais fácil de controlar e pode ser feito em uma janela de manutenção. Este plano pode incluir alguns ou todos a seguir:

Obtenha a confirmação de que a região primária foi restaurada.
Desabilite pools e clusters na região secundária para que novos dados não comecem a ser processados.
Sincronize todos os ativos novos ou modificados feitos no workspace secundário de volta na implantação primária. Dependendo do projeto dos scripts de failover, você poderá executar os mesmos scripts para sincronizar os objetos da região secundária (recuperação de desastre) na região primária (produção).
Sincronize todas as novas atualizações de dados de volta na implantaçã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.
Desligue todas as cargas de trabalho na região da recuperação de desastre.
Altere o URL dos trabalhos e usuários na região primária.
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, configurar a região secundária novamente para uma recuperação de desastre futura.

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

Scripts de automação a analisar para os projetos de recuperação de desastre:

O Databricks recomenda que você use o Provedor Terraform do Databricks para ajudá-lo a desenvolver seu próprio processo de sincronização.
Consulte também Ferramentas de migração de workspace do Databricks para scripts de exemplo e protótipo. Além de objetos do Azure Databricks, replique qualquer pipeline importante do Azure Data Factory para que ele se refira a um serviço vinculado que é mapeado para o workspace secundário.
O projeto Databricks Sync (DBSync) é uma ferramenta de sincronização de objetos que faz backup, restauração e sincronização de workspaces do Databricks.

Compartilhar via