Recuperação de desastres

Um padrão claro de recuperação de desastres é crítico para uma plataforma analítica de dados cloud nativa, como o Databricks. É fundamental que suas equipes de dados possam usar a plataforma Databricks mesmo no caso raro de uma interrupção do provedor de serviços cloudem todo o serviço regional, causada por um desastre regional como um furacão ou terremoto ou outra fonte.

Databricks costuma ser uma parte central de um ecossistema geral de dados que inclui muitos serviços, incluindo serviço de ingestão de dados upstream (lotes/transmissão), armazenamento nativo em nuvem, como Google Cloud Storage, ferramentas e serviços downstream, como aplicativos 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 melhores práticas para soluções de recuperação de desastres inter-regionais bem-sucedidas para a plataforma Databricks.

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 continuação de infraestruturas e sistemas tecnológicos vitais após um desastre natural ou induzido pelo homem. Um grande serviço clouds como clouds do Google atende muitos clientes e possui proteções integradas contra uma única falha. Por exemplo, uma região é um grupo de edifícios ligados a diferentes fontes de energia para garantir que uma única perda de energia não irá encerrar uma região. No entanto, podem ocorrer falhas na região clouds , 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 primário) ao ser projetada como um recurso do sistema primário. Por exemplo, serviços clouds como as clouds do Google têm serviços de alta disponibilidade, como o Google clouds Storage. A alta disponibilidade não requer uma preparação explícita significativa por parte do cliente 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 a terminologia comum de recuperação de desastres, soluções comuns e algumas práticas recomendadas para planos de recuperação de desastres com 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 analíticas diárias interativas e automatizadas típicas.

  • Região secundária: a região geográfica na qual as equipes IT movem cargas de trabalho analíticas de dados temporariamente durante uma interrupção na região primária.

  • Armazenamento com redundância geográfica: clouds do Google têm armazenamento com redundância geográfica em regiões para buckets persistentes do GCS 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 os dois buckets do GCS em sua do Google clouds account que o Databricks cria para cada workspace. Em geral, use Deep Clone para tabelas Delta e converta os dados para o formato Delta para usar Deep Clone, se possível, 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 Databricks e cargas de trabalho de execução. Os trabalhos são agendados periodicamente usando o programador do Databricks ou outro mecanismo. A transmissão de dados também pode ser executada nesta implantação. Alguns documentos podem referir-se 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 IT podem configurar procedimentos automatizados para aprimorar código, configuração e outros objetos Databricks para o aprimoramento passivo. Uma implantação se torna 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 por vez, no que é chamado de estratégia de recuperação de desastre ativa-passiva . Existe uma estratégia menos comum de soluções de recuperação de desastre chamada ativo-ativo, em que há duas implantações ativas simultâneas.

Terminologia de recuperação de desastres

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

  • Objetivo de ponto de recuperação: Um objetivo de ponto de recuperação (RPO) é o período máximo em que os dados (transações) podem ser perdidos de um serviço IT devido a um incidente grave. A implantação do Databricks não armazena os principais dados do cliente. Isso é armazenado em sistemas separados, como o Google Cloud Storage ou outra fonte de dados sob seu controle. O plano de controle do Databricks armazena alguns objetos parcial ou totalmente, como Job e Notebook. Para Databricks, o RPO é definido como o período máximo direcionado em que objetos como alterações Job e Notebook podem ser perdidos. Além disso, você é responsável por definir o RPO para seus próprios dados do cliente no Google Cloud Storage ou em outra fonte de dados sob seu controle.

  • Objetivo de tempo de recuperação: O objetivo de tempo de recuperação (RTO) é a duração de tempo pretendida e um nível de serviço dentro do qual um processo de negócios deve ser restaurado após um desastre.

    RPO e RTO de recuperação de desastres

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

A Disaster Recovery Soluções não mitiga a corrupção de dados. 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 falha, por exemplo Delta viagem do tempo.

Fluxo de trabalho típico de recuperação

Um cenário de recuperação de desastres do Databricks geralmente ocorre da seguinte maneira:

  1. Ocorre uma falha em um serviço crítico que você usa em sua região principal. Isso pode ser um serviço de fonte de dados ou uma rede que afeta a implantação do Databricks.

  2. Você investiga a situação com o provedor cloud .

  3. 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.

  4. Verifique se o mesmo problema também não afeta sua região secundária.

  5. Failover para uma região secundária.

    1. Pare todas as atividades no workspace. Os usuários interrompem 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 são encerrados se ainda não tiverem falhado devido à interrupção.

    2. começar 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 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 logs in na implantação agora ativa. Você pode reativar Job agendado ou atrasado.

    Para obter os passos detalhados em um contexto Databricks, consulte Failover de teste.

  6. Em algum momento, o problema na região primária é mitigado e você confirma esse fato.

  7. Restaure (fail back) para sua região primária.

    1. Pare todo o trabalho na região secundária.

    2. começar o procedimento de recuperação na região primária. O procedimento de recuperação trata do roteamento e renomeação da conexão e do tráfego de rede de volta à 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 algum Job for somente leitura durante a execução na implantação secundária, talvez não seja necessário replicar esses dados de volta para sua implantação primária na região primária. No entanto, você pode ter um Job 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 primária 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 principal, consulte Testar restauração (failback).

Importante

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

Passo 1: Entenda as necessidades do seu negócio

Seu primeiro passo é definir e entender suas 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 real de cada sistema e lembre-se de que o failover e o failback da recuperação de desastres podem ser caros e acarretam outros riscos. Outros riscos podem incluir corrupção de dados, dados duplicados se você gravar no local de armazenamento errado e usuários que logs in e fazem alterações nos lugares errados.

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

  • Suas soluções de recuperação de desastres precisam acomodar processos interativos, processos automatizados ou ambos?

  • Quais serviços de dados você usa? Alguns podem estar no local.

  • Como os dados de entrada chegam à cloud?

  • Quem consome esses dados? Quais processos o consomem a jusante?

  • Existem integrações de terceiros que precisam estar cientes das alterações na recuperação de desastres?

Determine as ferramentas ou estratégias de comunicação que podem oferecer 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 maneira natural e sustentável?

  • Quais ferramentas e canais de comunicação notificarão equipes internas e terceiros (integrações, consumidores downstream) sobre failover de recuperação de desastres e alterações de failback? E como você confirmará o reconhecimento deles?

  • Quais ferramentas ou suporte especial serão necessários?

  • Quais serviços, se houver, serão encerrados até que a recuperação completa esteja em vigor?

Passo 2: Escolha um processo que atenda às suas necessidades de negócios

Suas soluções devem replicar os dados corretos no plano de controle, no plano compute e na fonte de dados. workspace redundante para recuperação de desastres deve ser mapeado para diferentes planos de controle em diferentes regiões. Você deve manter esses dados sincronizados periodicamente usando soluções baseadas em script, seja 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 compute , como do Databricks Runtime worker.

Além disso, você precisa garantir que sua fonte de dados seja replicada conforme necessário nas regiões.

Recuperação de desastres - 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:

  1. Entenda quais processos são críticos para o negócio e devem ser executados na recuperação de desastres.

  2. Identifique claramente quais serviços estão envolvidos, quais dados estão sendo processados, qual é o fluxo de dados e onde estão armazenados

  3. Isole os serviços e dados o máximo possível. Por exemplo, crie um contêiner de armazenamento cloud especial para os dados para recuperação de desastres ou mova objetos Databricks necessários durante um desastre para um workspace separado.

  4. É sua responsabilidade manter a integridade entre implantações primárias e secundárias para outros objetos que não são armazenados no plano de controle Databricks.

    Aviso

    É uma prática recomendada não armazenar nenhum elemento de dados no bucket raiz do GCS usado para acesso raiz do DBFS ao workspace. Esse armazenamento DBFS raiz não é compatível com dados de produção do cliente. No entanto, você pode armazenar outros objetos, como biblioteca, arquivos de configuração, init script e dados semelhantes. Desenvolva um processo automatizado para replicar esses objetos ou lembre-se de ter processos em vigor para atualizar a implantação secundária para implantação manual.

  5. Para fonte de dados, sempre que possível, é recomendado que você use ferramentas nativas clouds do Google para replicação e redundância para replicar dados para as regiões de recuperação de desastres.

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

As soluções típicas de recuperação de desastres envolvem dois (ou possivelmente mais) workspace. 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 workspace esteja totalmente operacional e o esforço para restaurar (fazer fail back) para a região primária.

Estratégia de soluções ativo-passivo

Uma solução ativa-passiva é a mais comum e a mais fácil, e esse tipo de solução é o foco deste artigo. Uma solução ativa-passiva sincroniza alterações de dados e objetos de sua implantação ativa para sua implantação passiva. Se preferir, você pode ter várias implantações passivas em diferentes regiões, 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ções unificadas (corporativas): Exatamente um conjunto de implementações ativas e passivas que dão suporte a toda a organização.

  • soluções por departamento ou projeto: Cada departamento ou domínio de projeto mantém um Disaster Recovery Soluções separado. Algumas organizações desejam desacoplar os detalhes de recuperação de desastres entre os 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 usar uma implantação passiva para casos de uso somente leitura. Se você tiver cargas de trabalho somente leitura, por exemplo, user query, elas podem executar soluções passivas a qualquer momento se não modificarem dados ou objetos Databricks, como Notebook ou Job.

Estratégia de soluções ativo-ativo

Em uma solução ativo-ativo, você executa todos os processos de dados em ambas as regiões em todos os momentos em paralelo. Sua equipe de operações deve garantir que um processo de dados, como um Job 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/encenação até a produção.

Uma solução ativo-ativo é a estratégia mais complexa e, devido à execução Job em ambas as regiões, há um custo financeiro adicional.

Tal como acontece com a estratégia ativo-passivo, pode implementá-la como uma organização unificada soluções ou por departamento.

Você pode não precisar de um workspace equivalente no sistema secundário para todos workspace, dependendo do seu fluxo de trabalho. Por exemplo, talvez um workspace de desenvolvimento ou preparação não precise de uma duplicata. Com um pipeline de desenvolvimento bem projetado, você poderá reconstruir esses workspace facilmente, se necessário.

Escolha seu ferramental

Existem duas abordagens principais para ferramentas para manter os dados o mais semelhantes possível entre workspace 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 de produção e ativos da região primária para a região secundária. Normalmente esta execução é 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 os disponibiliza em ambas as regiões ao mesmo tempo. A ideia principal é tratar todos os artefatos em um workspace do Databricks como infraestrutura como código. A maioria dos artefatos pode ser implantada conjuntamente no workspace primário e secundário, enquanto alguns artefatos podem precisar ser implantados somente após um evento de recuperação de desastre. Para ferramentas, consulte Scripts, amostras e protótipos de automação.

O diagrama a seguir contrasta essas duas abordagens.

Opções de recuperação de desastres

Dependendo de suas necessidades, você pode combinar as abordagens. Por exemplo, use CI/CD para o código-fonte 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.

Descrição

Como lidar com ferramentas de CI/CD

Como lidar com a ferramenta de sincronização

Código-fonte: Exportações de fonte Notebook e código-fonte para bibliotecas do pacote

Co-implantado tanto para primário como para secundário.

Sincronize o código-fonte do primário para o secundário.

Usuários e grupos

gerencia metadados como config no Git. Como alternativa, use o mesmo provedor de identidade (IdP) para ambos workspace. Dados de usuário e grupo co-implantados para aprimoramentos primários e secundários.

Use SCIM ou outra automação para ambas as regiões. A criação manual não é recomendada, mas se for utilizada deve ser feita para os dois 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 pool

Pode ser padrão no Git. Co-implantado para primário e secundário. No entanto, min_idle_instances no secundário deve ser zero até o evento de recuperação de desastre.

pool criado com qualquer min_idle_instances quando eles são sincronizados com o workspace secundário usando a API ou CLI.

Configurações Job

Pode ser padrão no Git. Para aprimoramento primário, aprimore a definição do Job como está. Para aprimoramento secundário, aprimore o Job e defina as simultaneidades como zero. Isso desativa o Job nesta implantação e impede a execução extra. Altere o valor das simultaneidades depois que a implantação secundária se tornar ativa.

Se a execução Job em <interactive> existente agrupar por algum motivo, o cliente de sincronização precisará mapear para o cluster_id correspondente no workspace secundário.

Listas de controle de acesso (ACLs)

Pode ser padrão no Git. Co-implantado para melhorias primárias e secundárias para Notebook, pastas e clusters. No entanto, mantenha os dados do Job até o evento de recuperação de desastre.

A API Permissions pode definir controles de acesso para clusters, Job, pool, Notebook e pastas. Um cliente de sincronização precisa mapear os IDs de objeto correspondentes para cada objeto no workspace secundário. A Databricks recomenda a criação de um mapa de IDs de objetos do workspace primário para o secundário ao sincronizar esses objetos antes de replicar os controles de acesso.

Bibliotecas

Incluir no código fonte e clusters/Job padrão.

Sincronize bibliotecas personalizadas de repositórios centralizados, DBFS ou armazenamento cloud (podem ser montados).

init script clusters

Inclua no código-fonte, se preferir.

Para uma sincronização mais simples, armazene init script no workspace principal em uma pasta comum ou em um pequeno conjunto de pastas, se possível.

Pontos de montagem

Incluir no código-fonte se for criado apenas por meio Notebookde Job ou Command API baseado em .

Usar Job. Observe que os endpoints de armazenamento podem mudar, já que workspace estaria em diferentes regiões. Isso também depende muito da sua estratégia de recuperação de desastres de dados.

Metadados da tabela

Incluir no código-fonte se for criado apenas por Notebookmeio Job de ou Command API baseado em . Isto aplica-se tanto à metastore interna do Databricks como à metastore configurada externamente.

Compare as definições de metadados entre os metastore usando a API de catálogo do Spark ou SHOW CREATE TABLE por meio de um Notebook 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

Incluir no código-fonte se criado apenas por meio de comando API. Observe que pode ser necessário alterar o conteúdo de alguns segredos entre o primário e o secundário.

Os segredos são criados em ambos workspace por meio da API. Observe que o conteúdo de alguns segredos pode precisar ser alterado entre o primário e o secundário.

configurações clusters

Pode ser padrão no Git. Co-implantado para aprimoramentos primários e secundários, embora os de aprimoramento secundário devam ser encerrados até o evento de recuperação de desastre.

Os clusters são criados após serem sincronizados com o workspace secundário usando a API ou CLI. Eles podem ser encerrados explicitamente, se você quiser, dependendo das configurações de encerramento automático.

Permissões Notebook, Job e pasta

Pode ser padrão no Git. Co-implantado para reforços primários e secundários.

Replique usando a API de permissões.

Escolha 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 acioná-lo 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 de operações (produção normal). Normalmente, isso significa que você precisa criar vários workspace do Databricks para atender às suas necessidades de produção e recuperação de desastres e escolher sua região de failover secundária.

Nas clouds do Google, você pode ter controle total da região secundária escolhida. Certifique-se de que todos os seus recursos e produtos estejam disponíveis naquela região. Alguns serviços do Databricks estão disponíveis apenas em algumas regiões clouds do Google.

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

Se um workspace já estiver em produção, é comum executar operações 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: Replicar usando soluções de replicação cloud ou operações de Delta Deep Clone.

  • geraçãotokenss : Use a geração tokens para automatizar a replicação e futuras cargas de trabalho.

  • replicaçãoworkspace : Use a replicação workspace usando os métodos descritos na passo 4: Prepare sua fonte de dados.

  • validaçãoworkspace : - teste para garantir que o workspace e o processo possam ser executados com êxito e fornecer os resultados esperados.

Após as operações iniciais de cópia única, as ações subsequentes de cópia e sincronização são mais rápidas e todos os logsgerados por suas ferramentas também são logs do que foi alterado e quando foi alterado.

Passo 4: Prepare sua fonte de dados

Databricks pode processar uma grande variedade de fontes de dados usando processamento de lotes ou transmissão de dados.

Antes de implementar um sistema para sua fonte de dados, é importante entender a diferença de replicação entre GCS e BigQuery:

  • Para o BigQuery, os dados são replicados. Os dados corrompidos podem ser recuperados por até sete dias (supondo que não haja backups).

  • Para o GCS que usa Delta Lake, a replicação depende do tipo de bucket, como único, duplo ou múltiplo. Dados corrompidos podem ser recuperados dependendo da retenção do Vacuum .

processamento de lotes da fonte de dados

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

Por exemplo, os dados podem ser upload regularmente para um local de armazenamento cloud . No modo de recuperação de desastre para sua região secundária, você deve garantir que os arquivos sejam upload no armazenamento de sua 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.

dados transmitidos

Processar um dado transmitido é um desafio maior. os dados de transmissão podem ser ingeridos de várias fontes e processados e enviados para a transmissão soluções:

  • Fila de mensagens, como Kafka ou Pub/Sub Lite

  • Captura de banco de dados de alterações (CDC) transmitida

  • Processamento contínuo baseado em arquivo

  • Processamento agendado baseado em arquivo, também conhecido como gatilho uma vez

Em todos esses casos, você deve configurar sua fonte 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 transmissão armazena um ponto de verificação com informações sobre os dados que foram processados. Este ponto de verificação pode conter um local de dados (geralmente armazenamento cloud ) que deve ser modificado para um novo local para garantir o reinício bem-sucedido da transmissão. Por exemplo, a subpasta source sob o ponto de verificação pode armazenar a pasta cloud baseada em arquivo.

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

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

Para cargas de trabalho de transmissão, certifique-se de que os pontos de verificação sejam configurados no armazenamento gerador do 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 transmissão secundário em paralelo ao processo primário.

Passo 5: Implemente e teste suas soluções

Teste periodicamente sua configuração de recuperação de desastres para garantir que ela funcione corretamente. De nada adianta manter uma Disaster Recovery Soluções se você não puder utilizá-la quando precisar. Algumas empresas alternam entre regiões a cada poucos meses. A troca de regiões em um programa 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 suas soluções de recuperação de desastres em condições do mundo real.

Se você descobrir que está faltando um objeto ou padrão e ainda precisa confiar na informação armazenada em seu workspace primário, modifique seu plano para remover esses obstáculos, replique esta informação no sistema secundário ou disponibilize-a de alguma outra forma.

Teste quaisquer mudanças 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 seu workspace de recuperação de desastres, você deve garantir que sua infraestrutura (manual ou código), Job, Notebook, bibliotecas e outros objetos workspace 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 aprimorar as mudanças em todos os workspace. gerencia as identidades dos usuários em todo workspace. Lembre-se de configurar ferramentas como automação Job e monitoramento para o novo workspace.

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

  • Ingestão: entenda onde está sua fonte de dados e onde essas fontes obtêm seus dados. Sempre que possível, parametrize a origem e certifique-se de ter uma configuração padrão separada para trabalhar com suas implantações secundárias e regiões secundárias. Prepare um plano para failover e teste todas as suposições.

  • Mudanças de execução: Se você tiver um programador para acionar Job ou outras ações, pode ser necessário configurar um programador separado que funcione com a implantação secundária ou sua fonte de dados. Prepare um plano para failover e teste todas as suposições.

  • Conectividade interativa: considere como a configuração, autenticação e conexões de rede podem ser afetadas pela interrupção regional 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.

  • Mudanças de automação: para todas as ferramentas de automação, prepare um plano para failover e teste todas as suposições.

  • Saídas: para qualquer ferramenta que gere 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 desencadeado por uma quebra inesperada. Algumas funcionalidades principais podem estar inativas, incluindo a rede cloud , armazenamento cloud ou outro serviço principal. Você não tem acesso para desligar o sistema normalmente e deve tentar recuperá-lo. No entanto, o processo pode ser acionado por um desligamento ou interrupção planejada ou até mesmo pela troca 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. Assegure-se de que todos Job estejam concluídos e os clusters encerrados.

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

  1. testes de execução para confirmar se a plataforma está atualizada.

  2. Desabilite 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.

  3. Processo de recuperação:

    1. Verifique a data dos últimos dados sincronizados. Consulte a terminologia de recuperação de desastres. Os detalhes deste passo variam com base em como você sincroniza os dados e suas necessidades comerciais exclusivas.

    2. Estabilize sua fonte de dados e garanta que todos estejam disponíveis. Inclua todas as fontes de dados externas, como Google Cloud SQL, BigQuery ou Pub/Sub, bem como Delta Lake, Parquet ou outros arquivos.

    3. Encontre o seu ponto de recuperação de transmissão. Configure o processo para reiniciar a partir daí e tenha um processo pronto para identificar e eliminar possíveis duplicatas (o Delta Lake Lake torna isso mais fácil).

    4. Conclua o processo de fluxo de dados e informe os usuários.

  4. iniciar pools relevantes (ou aumentar o min_idle_instances para o número relevante).

  5. começar clusters relevantes (se não forem encerrados).

  6. Altere a execução concorrente para Job e execute Job relevante. Estas podem ser uma execução única ou uma execução periódica.

  7. Para qualquer ferramenta externa que use uma URL ou nome de domínio para seu workspace do Databricks, atualize as configurações para account 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 Databricks muda quando o plano de controle muda, então 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 itens a seguir:

  1. Obtenha a confirmação de que a região primária foi restaurada.

  2. Desative pools e clusters na região secundária para que ela não comece a processar novos dados.

  3. Sincronize todos os ativos novos ou modificados no workspace secundário de volta à implantação primária. Dependendo do design de seus scripts de failover, você poderá 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).

  4. Sincronize quaisquer novas atualizações de dados com a implantação primária. Você pode usar trilhas de auditoria de logs e tabelas Delta para garantir que não haja perda de dados. Observe que alguns gerenciamentos de fontes de dados têm janelas de tempo limitadas para recuperação usando Snapshot automatizado. Por exemplo, o Google BigQuery tem um limite de sete dias para restauração de dados.

  5. Desligue todas as cargas de trabalho na região de recuperação de desastres.

  6. Altere a URL Job e dos usuários para a região primária.

  7. testes de execução para confirmar se a plataforma está atualizada.

  8. começar pools relevantes (ou aumentar o min_idle_instances para um número relevante) .

  9. começar clusters relevantes (se não forem encerrados).

  10. Altere a execução concorrente para Job e execute Job relevante. Estas podem ser uma execução única ou uma execução periódica.

  11. Conforme necessário, configure sua região secundária novamente para futura recuperação de desastres.

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

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