Recuperação após desastre

Artigo
05/04/2024

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

O Azure Databricks geralmente é uma parte central de um ecossistema de dados geral que inclui muitos serviços, incluindo serviços de ingestão de dados upstream (lote/streaming), armazenamento nativo da nuvem, como ADLS gen2 (para espaços de trabalho 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 sensíveis a uma interrupção regional em todo o serviço.

Este artigo descreve conceitos e práticas recomendadas para uma solução de recuperação de desastres inter-regional 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 desastres 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 cobrem os seguintes componentes:

Disponibilidade do plano de controle do Azure Databricks

A maioria dos serviços do plano de controle está sendo executada em clusters Kubernetes e lidará com a perda de VMs no AZ específico automaticamente.
Os dados do espaço de trabalho 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 exibindo uma nova instância do backup.
As contas de armazenamento usadas para fornecer imagens DBR também são redundantes dentro da região, e todas as regiões têm contas de armazenamento secundário que são usadas quando o primário está inativo. Consulte Regiões do Azure Databricks.
Em geral, a funcionalidade do plano de controle deve ser restaurada dentro de ~15 minutos após a recuperação da zona de disponibilidade.

Disponibilidade do plano de computação

A disponibilidade do espaço de trabalho depende da disponibilidade do plano 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 para clusters são extraídos das diferentes zonas de disponibilidade solicitando nós do provedor de computação do Azure (assumindo 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 trabalho ou o gerenciador de cluster os reinicia.

Visão geral da recuperação de desastres

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

Antes de implementar um plano de recuperação de desastres, é importante entender a diferença entre recuperação de desastres (DR) e 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 porcentagem de tempo de atividade. A alta disponibilidade é implementada no local (na mesma região do sistema principal) 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 ADLS gen2 (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure). A alta disponibilidade não requer uma preparação explícita significativa do cliente do Azure Databricks.

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

Terminologia

Terminologia da região

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

Região primária: a região geográfica na qual os usuários executam cargas de trabalho diárias típicas de análise de dados interativa e automatizada.
Região secundária: a região geográfica na qual as equipes de TI movem temporariamente cargas de trabalho de análise de dados durante uma interrupçã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 de replicação de armazenamento assíncrono.

Importante

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

Terminologia do status da 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 espaço de trabalho 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 ativa.
Implantação passiva: os processos não são executados em uma implantação passiva. As equipes de TI podem configurar procedimentos automatizados para implantar código, configuração e outros objetos do Azure Databricks na implantação passiva. Uma implantação torna-se ativa somente se uma implantação ativa atual estiver inativa. Alguns documentos podem se referir a uma implantação passiva como uma implantação fria.

Importante

Um projeto pode, opcionalmente, incluir várias implantações passivas em diferentes regiões para fornecer opções adicionais para resolver interrupções regionais.

De um modo geral, uma equipe tem apenas uma implantação ativa de cada vez, no que é chamado de estratégia de recuperação de desastres ativo-passivo . Há uma estratégia de solução de recuperação de desastres menos comum chamada ativo-ativo, na qual há duas implantações ativas simultâneas.

Terminologia do setor de recuperação de desastres

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

Objetivo de ponto de recuperação: um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) é o período máximo no qual os dados (transações) podem ser perdidos de um serviço de TI devido a um incidente grave. Sua implantação do Azure Databricks não armazena os dados principais do cliente. Isso é armazenado em sistemas separados, como ADLS gen2 (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou outras fontes de dados sob seu controle. O plano de controle do Azure Databricks armazena alguns objetos em parte ou na totalidade, como trabalhos e blocos de anotações. Para o Azure Databricks, o RPO é definido como o período máximo de destino no qual objetos como alterações de trabalho e bloco de anotações podem ser perdidos. Além disso, você é responsável por definir o RPO para seus próprios dados de cliente no ADLS gen2 (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) ou outras fontes de dados sob seu controle.
Objetivo de tempo de recuperação: o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) é a duração de tempo e um nível de serviço no qual um processo de negócios deve ser restaurado após um desastre.

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

Uma solução de recuperação de desastres não reduz a corrupção de dados. Os dados corrompidos na região primária são replicados da região primária para uma região secundária e corrompidos em ambas as regiões. Existem outras formas de mitigar este tipo de falhas, por exemplo a viagem no tempo Delta.

Fluxo de trabalho de recuperação típico

Um cenário de recuperação de desastres do Azure Databricks normalmente funciona da seguinte maneira:

Ocorre uma falha em um serviço crítico que você usa na região principal. Isso 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 sua empresa não pode esperar que o problema seja corrigido na região primária, você pode decidir que precisa de failover para uma região secundária.
Verifique se o mesmo problema também não afeta sua região secundária.
Failover para uma região secundária.
1. Pare todas as atividades no espaço de trabalho. Os usuários interrompem 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 são encerrados se ainda não tiverem falhado devido à interrupção.
2. Inicie 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 de rede para a região secundária.
3. Após o teste, declare a região secundária operacional. As cargas de trabalho de produção agora podem ser retomadas. Os usuários podem fazer login na implantação agora ativa. Você pode reativar trabalhos agendados ou atrasados.
Para obter etapas detalhadas em um contexto do Azure Databricks, consulte Failover de teste.
Em algum momento, o problema na região primária é mitigado e você confirma esse fato.
Restaure (failback) para a região principal.
1. Pare todo o trabalho na região secundária.
2. Inicie o procedimento de recuperação na região primária. O procedimento de recuperação lida com o roteamento e a renomeação da conexão e do tráfego de rede de volta para a região primária.
3. Replique os dados de volta para a região primária conforme necessário. Para reduzir a complexidade, talvez minimize a quantidade de dados que precisa ser replicada. Por exemplo, se alguns trabalhos forem somente leitura quando executados na implantação secundária, talvez não seja necessário replicar esses dados de volta para a implantação principal na região primária. No entanto, você pode ter um trabalho de produção que precisa ser executado e pode precisar de replicação de dados de volta para a região primária.
4. Teste a implantação na região primária.
5. Declare sua região principal operacional e que é sua implantação ativa. Retome as cargas de trabalho de produção.
Para obter mais informações sobre como restaurar para sua região primária, consulte Restaurar teste (failback).

Importante

Durante essas etapas, alguma perda de dados pode acontecer. Sua organização deve definir quanta perda de dados é aceitável e o que você pode fazer para mitigar essa perda.

Passo 1: Compreender as necessidades do seu negócio

O seu primeiro passo é definir e compreender as necessidades do seu negócio. Defina quais serviços de dados são críticos e qual é seu RPO e RTO esperados.

Pesquise a tolerância no mundo real de cada sistema e lembre-se de que o failover e o failback de recuperação de desastres podem ser caros e acarretar outros riscos. Outros riscos podem incluir corrupção de dados, dados duplicados se você gravar no local de armazenamento errado e usuários que fazem login e fazem alterações nos locais errados.

Mapeie todos os pontos de integração do Azure Databricks que afetam sua empresa:

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

Determine as ferramentas ou estratégias de comunicação que podem dar suporte ao seu plano de recuperação de desastres:

Quais ferramentas você usará para modificar as configurações de rede rapidamente?
Você pode predefinir sua configuração e torná-la modular para acomodar soluções de recuperação de desastres de forma natural e sustentável?
Quais ferramentas e canais de comunicação notificarão as equipes internas e terceiros (integrações, consumidores downstream) sobre alterações de failover e failback de recuperação de desastres? E como confirmará o seu reconhecimento?
Que ferramentas ou apoio especial serão necessários?
Que serviços, se houver, serão encerrados até que a recuperação completa esteja em vigor?

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

Sua solução deve replicar os dados corretos no plano de controle, no plano de computação e nas fontes de dados. Os espaços de trabalho redundantes para recuperação de desastres 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 de dentro da própria rede do plano de computação, como de trabalhadores do Databricks Runtime.

Se você usar o recurso de injeção de VNet (não disponível com todos os tipos de assinatura e implantação), 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 suas fontes de dados sejam replicadas conforme necessário entre regiões.

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

Melhores práticas gerais

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

Entenda quais processos são críticos para os negócios e precisam ser executados na recuperação de desastres.
Identificar 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, crie um contêiner de armazenamento em nuvem especial para os dados para recuperação de desastres ou mova os objetos do Azure Databricks necessários durante um desastre para um espaço de trabalho separado.
É sua responsabilidade manter a integridade entre 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 no ADLS gen2 raiz (para espaços de trabalho criados antes de 6 de março de 2023, Armazenamento de Blobs do Azure) que é usado para acesso raiz DBFS para o espaço de trabalho. Esse armazenamento raiz DBFS não é suportado para dados de clientes de produção. O 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, é recomendável usar ferramentas nativas do Azure para replicação e redundância para replicar dados para as regiões de recuperação de desastres.

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

As soluções típicas de recuperação de desastres envolvem dois (ou possivelmente mais) espaços de trabalho. Existem várias estratégias que você pode escolher. Considere a duração potencial da 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 para restaurar (failback) para a região primária.

Estratégia de solução ativo-passivo

Uma solução ativo-passiva é a solução mais comum e a mais fácil, e este tipo de solução é o foco deste artigo. Uma solução ativo-passivo sincroniza dados e alterações de objetos da implantação ativa para 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 implantação passiva única. Durante um evento de recuperação de desastre, a implantação passiva na região secundária torna-se sua implantação ativa.

Existem duas variantes principais desta estratégia:

Solução unificada (em termos corporativos): exatamente um conjunto de implantações ativas e passivas que dão suporte a 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 querem separar os detalhes de recuperação de desastres entre departamentos e usar diferentes regiões primárias e secundárias para cada equipe com base nas necessidades exclusivas de cada equipe.

Existem outras variantes, como o uso de uma implantação passiva para casos de uso somente leitura. Se você tiver cargas de trabalho que são somente leitura, por exemplo, consultas de usuário, elas podem ser executadas em uma solução passiva a qualquer momento se não modificarem dados ou objetos do Azure Databricks, como blocos de anotações 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 sempre em paralelo. Sua equipe de operações deve garantir que um processo de dados, como um trabalho, seja marcado como concluído somente quando for concluído com êxito em ambas as regiões. Os objetos não podem ser alterados na produção e devem seguir uma promoção rigorosa de CI/CD desde o desenvolvimento/preparação 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 na estratégia ativo-passivo, você pode implementá-la como uma solução de organização unificada 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 seu fluxo de trabalho. Por exemplo, talvez um espaço de trabalho de desenvolvimento ou preparo não precise de uma duplicata. Com um pipeline de desenvolvimento bem projetado, você poderá reconstruir esses espaços de trabalho facilmente, se necessário.

Escolha as suas ferramentas

Há duas abordagens principais para ferramentas para manter os dados o mais semelhantes possível entre espaços de trabalho em suas regiões primária e secundária:

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, isso é executado de forma programada.
Ferramentas de CI/CD para implantação paralela: para código e ativos de produção, use ferramentas de CI/CD que enviam alterações para sistemas de produção simultaneamente para 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 artefatos pode ser coimplantada em 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 ferramentas, consulte Scripts, exemplos e protótipos de automação.

O diagrama a seguir contrasta essas duas abordagens.

Opções de recuperação de desastres

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

A tabela a seguir descreve como lidar com diferentes tipos de dados com cada opção de ferramenta.

Description	Como lidar com ferramentas de CI/CD	Como lidar com a ferramenta de sincronização
Código-fonte: exportações fonte do bloco de notas e código-fonte para bibliotecas empacotadas	Co-implantação tanto para o primário quanto para o 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. Coimplantar dados de usuários e grupos em implantações primárias e secundárias.	Use SCIM ou outra automação para ambas as regiões. A criação manual não é recomendada, mas se usada 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 conjuntos	Podem ser modelos no Git. Co-implantação para primário e secundário. No entanto, `min_idle_instances` em secundário deve ser zero até o evento de recuperação de desastre.	Pools criados com qualquer um `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 implantação primária, implante a definição de tarefa como está. Para implantação secundária, implante o trabalho e defina as simultaneidades como zero. Isso desabilita o trabalho nessa implantação e impede execuções extras. Altere o valor das simultaneidades 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 ser modelos no Git. Coimplantação em implantações primárias e secundárias para blocos de anotações, pastas e clusters. No entanto, mantenha os dados para trabalhos até o evento de recuperação de desastre.	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, 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 criado somente por meio de trabalhos baseados em bloco de anotações 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 estariam em regiões diferentes. Isso também depende muito da sua estratégia de recuperação de desastres de dados.
Metadados de tabelas	Inclua com código-fonte se criado somente por meio de trabalhos baseados em bloco de anotações ou API de comando. Isso se aplica ao metastore interno do Azure Databricks ou ao metastore configurado externo.	Compare as definições de metadados entre os metastores usando a API do Catálogo do Spark ou Mostrar criar tabela por meio de um bloco de anotações ou scripts. Observe que as tabelas para armazenamento subjacente podem ser baseadas em região e serão diferentes entre instâncias de metastore.
Segredos	Inclua no código-fonte se criado somente por meio da API de comando. 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 ser modelos no Git. Coimplantação em implantações primárias e secundárias, embora as implantações secundárias devam ser encerradas até o evento de recuperação de desastre.	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 bloco de anotações, trabalhos e pastas	Podem ser modelos no Git. Coimplantação em implantações primárias e secundárias.	Replicar 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 de recuperação de desastres. Você pode decidir acionar isso a qualquer momento ou por qualquer motivo. Você deve assumir a responsabilidade pela estabilização da recuperação de desastres antes de poder 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 suas necessidades de produção e recuperação de desastres e escolher sua região de failover secundária.

No Azure, verifique a replicação de dados, bem como a disponibilidade de produtos e tipos de 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 sua implantação passiva com sua implantação ativa. Esta cópia única lida com o seguinte:

Replicação de dados: replique usando uma solução de replicação em nuvem ou uma operação Delta Deep Clone.
Geração de tokens: use a geração de tokens para automatizar a replicação e cargas de trabalho futuras.
Replicação de espaço de trabalho: use a replicação de espaço de trabalho usando os métodos descritos em Etapa 4: preparar suas 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 fornecer os resultados esperados.

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

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

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 para um local de armazenamento em nuvem. No modo de recuperação de desastres para sua região secundária, você deve garantir que os arquivos serão carregados para o 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 maior. 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 Kafka
Fluxo de captura de dados de alteração de banco de dados
Processamento contínuo baseado em arquivo
Processamento agendado baseado em arquivo, também conhecido como trigger once

Em todos esses casos, você deve configurar suas fontes de dados para lidar com o modo de recuperação de desastres e usar sua implantação secundária em 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

Teste periodicamente sua configuração de recuperação de desastres para garantir que ela funcione corretamente. Não há valor em manter uma solução de recuperação de desastres se você não puder usá-la quando precisar. Algumas empresas mudam de região a cada poucos meses. Alternar regiões em um cronograma regular testa suas suposições e processos e garante que eles atendam às suas necessidades de recuperação. Isso também garante que sua organização esteja familiarizada com as políticas e procedimentos para emergências.

Importante

Teste regularmente sua solução de recuperação de desastres em condições reais.

Se você descobrir que está faltando um objeto ou modelo e ainda precisar confiar nas informações armazenadas em seu espaço de trabalho principal, modifique seu 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 em seus processos e na configuração em geral. Seu plano de recuperação de desastres afeta seu pipeline de implantação, e é importante que sua equipe saiba o que precisa ser mantido em sincronia. Depois de configurar seus espaços de trabalho de recuperação de desastres, você deve garantir que sua infraestrutura (manual ou código), trabalhos, bloco de anotações, bibliotecas e outros objetos de espaço de trabalho estejam disponíveis em sua região secundária.

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

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

Ingestão: entenda onde estão suas fontes de dados e onde essas fontes obtêm seus dados. Sempre que possível, parametrize a origem e certifique-se de ter um modelo de configuração separado para trabalhar com suas implantações secundárias e regiões secundárias. Prepare um plano para failover e teste todas as suposições.
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 suas fontes de dados. Prepare um plano para failover e teste todas as suposições.
Conectividade interativa: considere como a configuração, a autenticação e as conexões de rede podem ser afetadas por interrupções regionais para qualquer uso de APIs REST, ferramentas CLI ou outros serviços, como JDBC/ODBC. Prepare um plano para failover e teste todas as suposições.
Alterações de automação: para todas as ferramentas de automação, prepare um plano de failover e teste todas as suposições.
Saídas: Para quaisquer ferramentas que gerem dados ou logs de saída, prepare um plano para failover e teste todas as suposições.

Failover de teste

A recuperação de desastres pode ser acionada por muitos cenários diferentes. Pode ser desencadeada por uma quebra inesperada. Algumas funcionalidades principais podem estar inativas, incluindo a rede na nuvem, o armazenamento na nuvem ou outro serviço principal. Você não tem acesso para desligar o sistema graciosamente e deve tentar recuperar. No entanto, o processo pode ser acionado por um desligamento ou interrupção planejada, ou até mesmo pela alternância periódica de suas implantações ativas entre duas regiões.

Ao testar o failover, conecte-se ao sistema e execute um processo de desligamento. Certifique-se de que todos os trabalhos estejam concluídos e que os clusters sejam encerrados.

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

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.
Processo de recuperação:
1. Verifique a data dos últimos dados sincronizados. Consulte Terminologia do setor de recuperação de desastres. Os detalhes desta etapa variam de acordo com a forma como você sincroniza os dados e suas necessidades comerciais exclusivas.
2. Estabilize suas fontes de dados e garanta que todas estejam disponíveis. Inclua todas as fontes de dados externas, como o Azure Cloud SQL, bem como seus arquivos Delta Lake, Parquet ou outros.
3. 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 (Delta Lake Lake torna isso mais fácil).
4. Conclua o processo de fluxo de dados e informe os usuários.
Inicie pools relevantes (ou aumente o min_idle_instances número para 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.
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.

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 os seguintes:

Obtenha a confirmação de que a região primária foi restaurada.
Desative pools e clusters na região secundária para que ela não comece 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 scripts de failover, talvez seja possível executar os mesmos scripts para sincronizar os objetos da região secundária (recuperação de desastres) para a região primária (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.
Desligue todas as cargas de trabalho na região de recuperação de desastres.
Altere a URL de trabalhos e usuários para a região principal.
Execute testes para confirmar se a plataforma está atualizada.
Inicie pools relevantes (ou aumente o min_idle_instances número 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, configure sua região secundária novamente para recuperação de desastres futuros.

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

Scripts de automação a serem considerados para seus projetos de recuperação de desastres:

A Databricks recomenda que você use o Databricks Terraform Provider para ajudar a desenvolver seu próprio processo de sincronização.
Consulte também Ferramentas de migração do espaço de trabalho Databricks para obter scripts de exemplo e protótipo. Além dos objetos do Azure Databricks, replique todos os pipelines relevantes do Azure Data Factory para que eles se refiram a um serviço vinculado mapeado para o espaço de trabalho secundário.
O projeto Databricks Sync (DBSync) é uma ferramenta de sincronização de objetos que faz backup, restaura e sincroniza espaços de trabalho Databricks.