Recuperação de desastres
Um padrão claro de recuperação de desastres é essencial para uma plataforma nativa de análise de dados em nuvem, como a Databricks. É fundamental que suas equipes de dados possam usar a plataforma Databricks mesmo no caso raro de uma interrupção regional do provedor de serviços em nuvem, seja ela causada por um desastre regional, como um furacão ou terremoto, ou por outra fonte.
Databricks é geralmente uma parte essencial de um ecossistema geral de dados que inclui muitos serviços, inclusive o serviço de ingestão de dados upstream (lotes/transmissão), armazenamento nativo em nuvem, como Amazon S3, ferramentas e serviços downstream, como aplicativos de Business Intelligence e ferramentas de orquestração. Alguns de 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 soluções bem-sucedidas de recuperação de desastres inter-regionais 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 a continuidade da infraestrutura e dos sistemas tecnológicos vitais após um desastre natural ou induzido pelo homem. Um grande serviço de nuvem como o AWS atende a muitos clientes e tem proteções integradas 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 interrompa uma região. No entanto, podem ocorrer falhas na região da nuvem, 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 que o sistema primário), projetando-a como um recurso do sistema primário. Por exemplo, serviços em nuvem como AWS têm serviços de alta disponibilidade, como Amazon S3. A alta disponibilidade não exige uma preparação explícita significativa por parte do cliente da 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, a fim de lidar com uma interrupção regional maior dos sistemas essenciais. 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 diárias típicas de análise de dados interativa e automatizada.
-
Região secundária : A região geográfica para a qual as equipes do IT transferem temporariamente as cargas de trabalho de análise de dados durante uma interrupção na região primária.
-
Armazenamento com redundância geográfica : O AWS tem armazenamento com redundância geográfica em todas as regiões para buckets persistentes usando um processo de replicação de armazenamento assíncrono.
Para processos de recuperação de desastres, a Databricks recomenda que o senhor não dependa de armazenamento com redundância geográfica para duplicação de dados entre regiões, como o seu bucket S3 raiz. Em geral, use o Deep Clone para tabelas Delta e converta os dados para o formato Delta para usar o Deep Clone, se possível, para outros formatos de dados.
Terminologia do status de implantação
Este artigo usa as seguintes definições de status de implantação:
-
Implementação ativa : Os usuários podem se conectar a uma implementação ativa de cargas de trabalho de Databricks workspace e execução. Os trabalhos são agendados periodicamente usando o programador Databricks ou outro mecanismo. A transmissão de dados também pode ser executada nessa implantação. Alguns documentos podem se referir a uma implantação ativa como uma implantação dinâmica .
-
Implantação passiva : Os processos não são executados em uma implantação passiva. IT As equipes podem definir procedimentos automatizados para implantar código, configuração e outros objetos do Databricks na implementação passiva. 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 a frio .
Opcionalmente, um projeto pode incluir várias implantações passivas em diferentes regiões para oferecer 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 ativa-passiva de recuperação de desastres. Há uma estratégia menos comum de soluções de recuperação de desastres chamada ativo-ativo, na qual há duas implantações ativas simultâneas.
Terminologia das indústrias de recuperação de desastres
Há dois termos importantes sobre indústrias que o senhor deve entender e definir para sua equipe:
-
Objetivo do ponto de recuperação : Um objetivo de ponto de recuperação (RPO) é o período máximo visado em que os dados (transações) podem ser perdidos de um serviço IT devido a um incidente grave. Sua implantação da Databricks não armazena os principais dados do cliente. Isso é armazenado em sistemas separados, como Amazon S3 ou outra fonte de dados sob seu controle. O plano de controle do Databricks armazena alguns objetos de forma parcial ou total, como Job e Notebook. Para Databricks, o RPO é definido como o período máximo visado no qual objetos como alterações de trabalhos e notebooks podem ser perdidos. Além disso, o senhor é responsável por definir o RPO para seus próprios dados do cliente em Amazon S3 ou 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 e o nível de serviço dentro dos quais um processo comercial 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 estão corrompidos nas duas regiões. Há outras maneiras de mitigar esse 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 da Databricks normalmente se desenrola da seguinte forma:
-
Ocorre uma falha em um serviço crítico que o senhor usa em sua região primária. Pode ser uma fonte de dados de serviço ou uma rede que afeta a implementação do 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 solucionado na região primária, você pode decidir que precisa fazer o failover para uma região secundária.
-
Verifique se o mesmo problema também não afeta sua região secundária.
-
Faça o failover para uma região secundária.
- Interrompa todas as atividades no site 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.
- 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 do tráfego de rede para a região secundária.
- 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 acessar log in para a implantação agora ativa. O senhor pode reativar um trabalho programado ou atrasado.
Para obter etapas detalhadas em um contexto do Databricks, consulte Testar failover.
-
Em algum momento, o problema na região primária é atenuado e você confirma esse fato.
-
Restaure (fail back) para sua região primária.
- Pare todo o trabalho na região secundária.
- começar o procedimento de recuperação na região primária. O procedimento de recuperação gerencia o roteamento e a renomeação da conexão e do tráfego de rede de volta para a região primária.
- 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 precisam ser replicados. Por exemplo, se alguns trabalhos forem somente de leitura quando executados na implementação secundária, talvez o senhor não precise replicar esses dados de volta para a implementação primária na região primária. No entanto, o senhor 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.
- Teste a implantação na região primária.
- Declare que sua região principal está operacional e que é sua implantação ativa. Retomar as cargas de trabalho de produção.
Para obter mais informações sobre a restauração para a região primária, consulte Restauração de teste (failback).
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.
Etapa 1: Entenda suas necessidades comerciais
Sua primeira etapa é definir e entender suas necessidades comerciais. Defina quais serviços de dados são essenciais e quais são os RPO e RTO esperados.
Pesquise a tolerância real de cada sistema e lembre-se de que o failover e o failback na recuperação de desastres podem ser caros e acarretar outros riscos. Outros riscos podem incluir corrupção de dados, dados duplicados se o senhor gravar no local de armazenamento errado e usuários que log in e fazem alterações nos locais errados.
Mapeie todos os pontos de integração da 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 o senhor usa? Alguns podem estar no local.
- Como os dados de entrada chegam à nuvem?
- Quem consome esses dados? Quais processos o consomem a jusante?
- Há integrações de terceiros que precisam estar cientes das mudanças na recuperação de desastres?
Determine as ferramentas ou estratégias de comunicação que podem apoiar seu plano de recuperação de desastres:
- Quais ferramentas você usará para modificar rapidamente as configurações de rede?
- O senhor 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 as alterações de failover e failback de recuperação de desastres? E como você confirmará o reconhecimento deles?
- Quais ferramentas ou suporte especial serão necessários?
- Qual serviço, se houver, será fechado até que a recuperação completa esteja em vigor?
Etapa 2: escolha um processo que atenda às necessidades da sua empresa
Suas soluções devem replicar os dados corretos no plano de controle, no plano compute e na fonte de dados. O espaço de trabalho redundante para recuperação de desastres deve ser mapeado para diferentes planos de controle em diferentes regiões. O senhor deve manter esses dados sincronizados periodicamente usando uma solução baseada em script, seja uma ferramenta de sincronização ou um CI/CD fluxo de trabalho. Não há necessidade de sincronizar os dados da própria rede do plano compute, como, por exemplo, do trabalhador Databricks Runtime.
Se o senhor usar o recurso customer-gerenciar VPC (não disponível em todos os tipos de inscrição e implantação), poderá implantar essas redes de forma consistente em ambas as regiões usando ferramentas baseadas em padrões, como Terraform.
Além disso, o senhor precisa garantir que sua fonte de dados seja replicada conforme necessário entre as regiões.
Práticas recomendadas gerais
As melhores práticas gerais para um plano de recuperação de desastres bem-sucedido incluem:
-
Entenda quais processos são essenciais para os negócios e precisam ser executados na recuperação de desastres.
-
Identifique claramente quais serviços estão envolvidos, quais dados estão sendo processados, qual é o fluxo de dados e onde eles são armazenados
-
Isole o serviço e os dados o máximo 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 Databricks que são necessários durante um desastre para um workspace separado.
-
É de sua responsabilidade manter a integridade entre as implantações primária e secundária de outros objetos que não estejam armazenados no plano de controle do Databricks.
É uma prática recomendada não armazenar dados no bucket raiz Amazon S3 que é usado para acesso DBFS root para o workspace. Esse armazenamento DBFS root não é compatível com a produção de dados do cliente. Databricks também recomenda não armazenar biblioteca, arquivos de configuração ou script de inicialização nesse local.
- Para a fonte de dados, sempre que possível, é recomendável que o senhor use as ferramentas nativas do AWS 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 as alterações de dados e objetos da implementação ativa para a implementação passiva. Se preferir, o senhor 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 desastres, a implantação passiva na região secundária se torna sua implantação ativa.
Existem duas variantes principais dessa estratégia:
- Soluções unificadas (para toda a empresa): 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 uma solução de recuperação de desastres separada. Algumas organizações querem dissociar os detalhes da recuperação de desastres entre os departamentos e usar diferentes regiões primárias e secundárias para cada equipe com base nas necessidades específicas de cada equipe.
Há outras variantes, como o uso de uma implantação passiva para casos de uso somente para leitura. Se o senhor tiver cargas de trabalho que sejam somente de leitura, por exemplo, consultas de usuários, elas poderão ser executadas em uma solução passiva 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 ativa-ativa, o senhor 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 Job, seja marcado como concluído somente quando terminar 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 do desenvolvimento/preparação para a produção.
Uma solução ativa-ativa é a estratégia mais complexa e, como o trabalho é executado em ambas as regiões, há um custo financeiro adicional.
Assim como na estratégia ativa-passiva, o senhor pode implementá-la como uma organização unificada ou por departamento.
Talvez o senhor não precise de um workspace equivalente no sistema secundário para todo o espaço de trabalho, dependendo do seu fluxo de trabalho. Por exemplo, talvez um site de desenvolvimento ou de preparação workspace não precise de uma duplicata. Com um desenvolvimento bem projetado pipeline, o senhor poderá reconstruir facilmente esse espaço de trabalho, se necessário.
Escolha suas ferramentas
Há duas abordagens principais para que as ferramentas mantenham os dados tão semelhantes quanto possível entre o espaço 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 de produção e ativos da região primária para a região secundária. Normalmente, essa execução é feita de forma programada.
- CI/CD para implantação paralela : Para o código de produção e o ativo, use a ferramentaCI/CD que envia as alterações para os sistemas de produção simultaneamente para ambas as regiões. Por exemplo, ao enviar o código e o ativo da fase de preparação/desenvolvimento para a produção, um sistema CI/CD o torna disponível em ambas as regiões ao mesmo tempo. A ideia central é tratar todos os artefatos em um Databricks workspace como Infrastructure-as-Code. A maioria dos artefatos pode ser implantada conjuntamente no espaço de trabalho primário e secundário, enquanto alguns artefatos podem precisar ser implantados somente após um evento de recuperação de desastres. Para ferramentas, consulte Scripts, amostras e protótipos de automação.
O diagrama a seguir contrasta essas duas abordagens.
Dependendo de 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 a configuração, como pool 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 as ferramentas de CI/CD | Como lidar com a ferramenta de sincronização |
|---|---|---|
Código-fonte: Exportações do código-fonte do notebook e código-fonte do pacote biblioteca | Co-implantado tanto no primário quanto no secundário. | Sincronize o código-fonte do primário para o secundário. |
Usuários e grupos | Gerenciar metadados como configuração em Git. Como alternativa, use o mesmo provedor de identidade (IdP) para ambos os espaços de trabalho. Co-implantado dados de usuários e grupos para 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 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 do pool | Pode ser padrão em Git. Co-implantado no primário e no secundário. No entanto, | pool criado com qualquer |
Job configurações | Pode ser padrão em Git. Para a implementação primária, implante a definição do trabalho como está. Para a implementação secundária, implante o Job e defina as simultaneidades como zero. Isso desativa o trabalho nessa 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 do trabalho no clustering |
Listas de controle de acesso (ACLs) | Pode ser padrão em Git. Co-implantado em implantações primárias e secundárias para Notebook, pastas e clustering. No entanto, mantenha os dados para o trabalho até o evento de recuperação de desastres. | O site Permissions API pode definir controles de acesso para clustering, Job, pool, Notebook e pastas. Um cliente de sincronização precisa mapear os IDs de objeto correspondentes para cada objeto no site secundário workspace. Databricks recomenda a criação de um mapa de IDs de objetos do site primário para o secundário workspace e a sincronização desses objetos antes de replicar os controles de acesso. |
bibliotecas | Incluir no código-fonte e no padrão de clustering/Job. | Sincronize a biblioteca personalizada a partir de repositórios centralizados, DBFS ou armazenamento em nuvem (pode ser montado). |
Inclua no código-fonte, se preferir. | Para simplificar a sincronização, armazene o script de inicialização no site principal workspace 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 do trabalho baseado em Notebook ou do comando API. | Use Job. Observe que o endpoint de armazenamento pode mudar, já que o espaço de trabalho estaria em regiões diferentes. Isso também depende muito da sua estratégia de recuperação de desastres de dados. |
Metadados da tabela | Inclua com o código-fonte se for criado somente por meio do trabalho baseado em Notebook ou do comando API. Isso se aplica tanto ao metastore interno do Databricks quanto ao metastore externo configurado. | 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 for criado somente por meio do comando API. Observe que o conteúdo de alguns segredos pode precisar ser alterado entre o primário e o secundário. | Os segredos são criados em ambos os espaços de trabalho por meio do site API. Observe que o conteúdo de alguns segredos pode precisar ser alterado entre o primário e o secundário. |
configurações de agrupamento | Pode ser padrão em Git. Co-implantado em implantações primárias e secundárias, embora aquelas em implantação secundária devam ser encerradas até o evento de recuperação de desastres. | Os clusters são criados depois de serem sincronizados com o site secundário workspace usando API ou CLI. Eles podem ser encerrados explicitamente se você quiser, dependendo das configurações de encerramento automático. |
NotebookPermissões de trabalho, trabalho e pasta | Pode ser padrão em Git. Co-implantado em implantações primárias e secundárias. | Replicar usando a API de permissões. |
Escolha regiões e múltiplos espaços de trabalho secundários
Você precisa ter controle total do gatilho de recuperação de desastres. Você pode decidir acionar isso a qualquer momento ou por qualquer motivo. O senhor deve assumir a responsabilidade pela estabilização da recuperação de desastres antes de poder reiniciar suas operações no modo failback (produção normal). Normalmente, isso significa que o senhor precisa criar vários espaços de trabalho Databricks para atender às suas necessidades de produção e recuperação de desastres e escolher a região de failover secundária.
No AWS, o senhor pode ter controle total da região secundária escolhida. Certifique-se de que todos os seus recursos e produtos estejam disponíveis lá, como, por exemplo, EC2. Alguns Databricks serviços estão disponíveis apenas em algumas regiões.
Etapa 3: Preparar o espaço de trabalho e fazer uma cópia única
Se o site workspace já estiver em produção, é comum executar uma única operação de cópia para sincronizar a implantação passiva com a implantação ativa. Essa cópia única trata do seguinte:
- Replicação de dados : Replique usando uma solução de replicação em nuvem ou Delta Deep Clone operações.
- geração de tokens : Use a geração de tokens para automatizar a replicação e as cargas de trabalho futuras.
- replicação do espaço de trabalho : Use a replicação workspace usando os métodos descritos na Etapa 4: Preparar sua fonte de dados.
- Validação do espaço de trabalho : - teste para garantir que o workspace e o processo possam ser executados com êxito e fornecer os resultados esperados.
Após as operações de cópia únicas iniciais, as ações subsequentes de cópia e sincronização são mais rápidas e qualquer registro de suas ferramentas também é um log do que mudou e quando mudou.
Etapa 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.
processamento de lotes a partir 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 carregados regularmente em um local de armazenamento em nuvem. No modo de recuperação de desastres da região secundária, o senhor deve garantir que os arquivos sejam 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.
Transmissão de dados
O processamento de uma transmissão de dados é um desafio maior. Os dados de transmissão podem ser ingeridos de várias fontes, processados e enviados para uma solução de transmissão:
- Fila de mensagens, como o Kafka
- Banco de dados de captura de dados de alterações (CDC) transmissão
- Processamento contínuo baseado em arquivos
- Processamento agendado baseado em arquivos, também conhecido como acionar uma vez
Em todos esses casos, o senhor deve configurar a fonte de dados para lidar com o modo de recuperação de desastres e usar a implementação secundária na região secundária.
Um gravador de transmissão 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 o reinício bem-sucedido da transmissão. Por exemplo, a subpasta source abaixo do ponto de verificação pode armazenar a pasta na nuvem baseada em arquivos.
Esse 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 em nuvem.
A atualização do ponto de verificação é uma função do gravador e, portanto, aplica-se à ingestão ou ao processamento da transmissão de dados e ao armazenamento em outra fonte de transmissão.
Para cargas de trabalho de transmissão, certifique-se de que os pontos de verificação estejam configurados no armazenamento gerenciado pelo cliente para que possam ser replicados na região secundária para a retomada da carga de trabalho a partir do ponto da última falha. O senhor também pode optar por executar o processo de transmissão secundário em paralelo ao processo primário.
Etapa 5: Implemente e teste suas soluções
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 o senhor não puder usá-la quando precisar. Algumas empresas trocam de região 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.
Teste regularmente suas soluções de recuperação de desastres em condições reais.
Se o senhor descobrir que está faltando um objeto ou padrão e ainda precisar contar com as informações armazenadas no seu sistema primário workspace, 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 mudanças organizacionais necessárias em seus processos e na configuração em geral. Seu plano de recuperação de desastres afeta o pipeline de implementação, e é importante que sua equipe saiba o que precisa ser mantido em sincronia. Depois de configurar o espaço de trabalho de recuperação de desastres, o senhor deve garantir que a infraestrutura (manual ou código), o Job, o Notebook, a biblioteca e outros objetos do workspace estejam disponíveis na região secundária.
Converse com sua equipe sobre como expandir os processos de trabalho padrão e o pipeline de configuração para implantar alterações em todo o espaço de trabalho. gerenciar identidades de usuários em todos os espaços de trabalho. Lembre-se de configurar ferramentas como automação de trabalho e monitoramento para o novo espaço de trabalho.
Planeje e teste as 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 garanta que o senhor tenha um padrão de configuração separado para trabalhar com suas implantações secundárias e regiões secundárias. Prepare um plano para o failover e teste todas as suposições.
- Alterações na execução: Se o senhor tiver um programador para acionar o Job ou outras ações, talvez seja necessário configurar um programador separado que funcione com a implementação secundária ou com sua fonte de dados. Prepare um plano para o 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 pela interrupção regional para qualquer uso de REST APIs, ferramentas CLI ou outro serviço, como JDBC/ODBC. Prepare um plano para o failover e teste todas as suposições.
- Mudanças na automação: para todas as ferramentas de automação, prepare um plano de failover e teste todas as suposições.
- Saídas: Para todas as ferramentas que geram dados de saída ou logs, prepare um plano de failover e teste todas as suposições.
Failover de teste
A recuperação de desastres pode ser acionada por vários cenários diferentes. Ele pode ser acionado por uma pausa inesperada. Algumas funcionalidades essenciais podem estar inativas, inclusive a rede em nuvem, o armazenamento em nuvem ou outro serviço essencial. Você não tem acesso para desligar o sistema normalmente e deve tentar se recuperar. 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.
Quando o senhor testar o failover, conecte-se ao sistema e execute um processo de desligamento. Verifique se todos os trabalhos foram concluídos e se o clustering foi encerrado.
Um cliente de sincronização (ou a ferramenta CI/CD ) pode replicar objetos e recursos relevantes do Databricks para o workspace secundário. Para ativar seu workspace secundário, seu processo pode incluir alguns ou todos os itens a seguir:
-
execução de testes para confirmar que a plataforma está atualizada.
-
Desative o pool e o clustering na região primária para que, se o serviço com falha voltar a ficar on-line, a região primária não comece a processar novos dados.
-
Processo de recuperação:
- Verifique a data dos dados sincronizados mais recentes. Consulte a terminologia das indústrias de recuperação de desastres. Os detalhes dessa etapa variam de acordo com a forma como você sincroniza os dados e suas necessidades comerciais exclusivas.
- Estabilize sua fonte de dados e garanta que todos eles estejam disponíveis. Inclua todas as fontes de dados externas, como AWS RDS, bem como seus arquivos Delta Lake, Parquet, ou outros.
- Encontre o ponto de recuperação da 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 facilita isso).
- Conclua o processo de fluxo de dados e informe os usuários.
-
começar o pool relevante (ou aumentar o
min_idle_instancespara o número relevante). -
começar o agrupamento relevante (se não for encerrado).
-
Altere a execução concorrente do Job e a execução relevante do Job. Essas execuções podem ser únicas ou periódicas.
-
Para qualquer ferramenta externa que use um URL ou nome de domínio para o seu Databricks workspace, atualize as configurações para account para o novo plano de controle. Por exemplo, atualizar URLs para APIs REST e conexões JDBC/ODBC. O URL voltado para o cliente do aplicativo da Web Databricks muda quando o plano de controle é alterado, portanto, notifique os usuários da sua 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. Esse plano pode incluir alguns ou todos os itens a seguir:
- Obtenha a confirmação de que a região primária foi restaurada.
- Desative o pool e o clustering na região secundária para que ela não comece a processar novos dados.
- Sincronize qualquer ativo novo ou modificado no workspace secundário de volta à implementação primária. Dependendo do design de seus scripts de failover, o senhor poderá executar os mesmos scripts para sincronizar os objetos da região secundária (recuperação de desastres) com a região primária (produção).
- Sincronize todas as novas atualizações de dados com a implantação primária. O senhor 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 o URL do trabalho e dos usuários para a região primária.
- execução de testes para confirmar que a plataforma está atualizada.
- começar o pool relevante (ou aumentar o
min_idle_instancespara um número relevante) . - começar o agrupamento relevante (se não for encerrado).
- Altere a execução concorrente do Job e a execução relevante do Job. Essas execuções podem ser únicas ou periódicas.
- Conforme necessário, configure sua região secundária novamente para uma futura recuperação de desastres.
Scripts de automação, amostras e protótipos
Scripts de automação a serem considerados em seus projetos de recuperação de desastres:
- A Databricks recomenda que o senhor use o Databricks Terraform Provider para ajudar a desenvolver seu próprio processo de sincronização.
- Consulte também Databricks Workspace Migration Tools para obter exemplos de automação e scripts de protótipo.
- O projeto Databricks Sync (DBSync) é uma ferramenta de sincronização de objetos que faz backup, restaura e sincroniza o espaço de trabalho do Databricks.