Editar

Compartilhar via

BCDR em pipelines do Azure Data Factory e do Azure Synapse Analytics

Fábrica de dados do Azure
Azure Repos
Azure Synapse Analytics
GitHub

Os desastres podem ser falhas de hardware, desastres naturais ou falhas de software. O processo de preparação e recuperação de um desastre é chamado de recuperação de desastres (DR). Este artigo discute as práticas recomendadas para obter continuidade de negócios e recuperação de desastres (BCDR) para pipelines do Azure Data Factory e do Azure Synapse Analytics.

As estratégias de BCDR incluem redundância de zona de disponibilidade, recuperação automatizada fornecida pela recuperação de desastres do Azure e recuperação gerenciada pelo usuário usando integração contínua/entrega contínua (CI/CD).

Arquitetura

Diagrama que mostra zonas de disponibilidade e regiões para o BCDR de pipelines do Azure Synapse Analytics e do Data Factory.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

  1. Os pipelines do Data Factory e do Azure Synapse alcançam resiliência usando regiões do Azure e zonas de disponibilidade do Azure.

    • Cada região do Azure tem um conjunto de datacenters que são implantados em um perímetro definido por latência.
    • As zonas de disponibilidade do Azure são locais fisicamente separados em cada região do Azure que são tolerantes a falhas locais.
    • Todas as regiões e zonas de disponibilidade do Azure são conectadas por meio de uma rede regional dedicada de baixa latência e por uma rede de alto desempenho.
    • Todas as regiões habilitadas para zonas de disponibilidade têm pelo menos três zonas de disponibilidade separadas para garantir a resiliência.

  2. Quando um datacenter, parte de um datacenter ou uma zona de disponibilidade em uma região fica inativo, o failover acontece com tempo de inatividade zero para pipelines do Data Factory resiliente à zona e do Azure Synapse.

Componentes

Detalhes do cenário

Os pipelines do Data Factory e do Azure Synapse armazenam artefatos que incluem os seguintes dados:

Metadados

  • Pipeline
  • Conjunto de dados
  • Serviços vinculados
  • runtime de integração
  • Gatilhos

Dados de monitoramento

  • Pipeline
  • Gatilhos
  • Execuções de atividade

Os desastres podem ocorrer de diferentes maneiras, como falhas de hardware, desastres naturais ou falhas de software resultantes de erro humano ou ataque cibernético. Dependendo dos tipos de falhas, seu impacto geográfico pode ser regional ou global. Ao planejar uma estratégia de recuperação de desastres, considere a natureza do desastre e seu impacto geográfico.

O BCDR no Azure funciona em um modelo de responsabilidade compartilhada. Muitos serviços do Azure exigem que os clientes configurem explicitamente sua estratégia de DR, enquanto o Azure fornece a infraestrutura de linha de base e os serviços de plataforma conforme necessário.

Você pode usar as seguintes práticas recomendadas para obter o BCDR para pipelines do Data Factory e do Azure Synapse em vários cenários de falha. Para implementação, consulte Implantar este cenário.

Recuperação automatizada com recuperação de desastres do Azure

Com a recuperação automatizada fornecida pelo backup e recuperação de desastres do Azure, quando há uma interrupção regional completa para uma região do Azure que tem uma região emparelhada, os pipelines do Data Factory ou do Azure Synapse fazem failover automaticamente para a região emparelhada quando você configura a recuperação automatizada. As exceções são as regiões do Sudeste Asiático e do Brasil, onde os requisitos de residência de dados exigem que os dados permaneçam nessas regiões.

No failover de DR, o Data Factory recupera os pipelines de produção. Se você precisar validar os seus pipelines recuperados, poderá fazer backup dos modelos do Azure Resource Manager para os seus pipelines de produção no armazenamento secreto e comparar os pipelines recuperados com os backups.

A equipe Global do Azure realiza simulações regulares de BCDR, e o Azure Data Factory e o Azure Synapse Analytics participam dessas simulações. O exercício BCDR simula uma falha de região e faz failover dos serviços do Azure para uma região emparelhada sem qualquer envolvimento do cliente. Para obter mais informações sobre os exercícios BCDR, consulte Teste de serviços.

Redundância gerenciada pelo usuário com CI/CD

Para obter o BCDR no caso de uma falha de região inteira, você precisa de um data factory ou um workspace do Azure Synapse na região secundária. Em caso de exclusão acidental do pipeline do Data Factory ou do Azure Synapse, paralisações ou eventos de manutenção interna, você pode usar o Git e o CI/CD para recuperar os pipelines manualmente.

Opcionalmente, você pode usar uma implementação ativa/passiva. A região primária lida com operações normais e permanece ativa, enquanto a região secundária DR requer etapas pré-planejadas, dependendo da implementação específica, para ser promovida a primária. Nesse caso, todas as configurações necessárias para a infraestrutura estão disponíveis na região secundária, mas não são provisionadas.

Possíveis casos de uso

A redundância gerenciada pelo usuário é útil em cenários como:

  • Exclusão acidental de artefatos de pipeline por erro humano.
  • Interrupções prolongadas ou eventos de manutenção que não acionam o BCDR porque não há nenhum desastre relatado.

Você pode mover rapidamente suas cargas de trabalho de produção para outras regiões e não ser afetado.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Os pipelines do Data Factory e do Azure Synapse são os principais serviços do Azure que dão suporte a zonas de disponibilidade e foram projetados para fornecer o nível certo de resiliência e flexibilidade, juntamente com latência ultrabaixa.

A abordagem de recuperação gerenciada pelo usuário permite que você continue operando se houver eventos de manutenção, paralisações ou erros humanos na região principal. Usando CI/CD, os pipelines do Data Factory e do Azure Synapse podem se integrar a um repositório Git e implantar em uma região secundária para recuperação imediata.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

A recuperação gerenciada pelo usuário integra o Data Factory ao Git usando CI/CD e, opcionalmente, usa uma região de DR secundária que tem todas as configurações de infraestrutura necessárias como backup. Esse cenário pode incorrer em custos adicionais. Para estimar os custos, use a Calculadora de Preços do Azure.

Para obter exemplos de preços do Data Factory e do Azure Synapse Analytics, consulte:

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

Usando a abordagem de recuperação de CI/CD gerenciada pelo usuário, você pode se integrar ao Azure Repos ou ao GitHub. Para obter mais informações sobre as melhores práticas de CI/CD, consulte Práticas recomendadas para CI/CD.

Implantar este cenário

Execute as seguintes ações para configurar a DR automatizada ou gerenciada pelo usuário para pipelines do Data Factory e do Azure Synapse.

Configurar a recuperação automatizada

No Data Factory, você pode definir a região do Azure Integration Runtime (IR) para execução ou envio de sua atividade na confiiguração do Integration Runtime. Para habilitar o failover automático no caso de uma interrupção regional completa, defina a Região como Auto Resolve.

Captura de tela que mostra a seleção de Resolução Automática para habilitar o failover automático na configuração do tempo de execução de integração.

No contexto dos Integration Runtimes, IR faz failover automaticamente para a região emparelhada quando você seleciona Auto Resolve como a região IR. Para outras regiões de local específicas, você pode criar um data factory secundário em outra região e usar CI/CD para provisionar seu data factory a partir do repositório Git.

Os serviços vinculados não são totalmente habilitados após o failover, devido a pontos de extremidade privados pendentes na rede mais recente da região. Você precisa configurar pontos de extremidade privados na região recuperada. Você pode automatizar a criação de ponto de extremidade privado usando a API deaprovação.

Configurar a recuperação gerenciada pelo usuário por meio de CI/CD

Você pode usar o Git e o CI/CD para recuperar pipelines manualmente em caso de exclusão ou interrupção de pipeline do Data Factory ou do Azure Synapse.

Ao implantar a redundância gerenciada pelo usuário usando CI/CD, execute as seguintes ações:

Desativar gatilhos

Desative os gatilhos no data factory primário original assim que ele voltar a ficar online. Você pode desativar os gatilhos manualmente ou implementar a automação para verificar periodicamente a disponibilidade do primário original. Desative todos os gatilhos no data factory primário original imediatamente após a recuperação de fábrica.

Para usar o Azure PowerShell para desativar ou ativar gatilhos do Data Factory, consulte Exemplo de script pré e pós-implantação e aprimoramentos de CI/CD relacionados à implantação de gatilhos de pipeline.

Manipular gravações duplicadas

A maioria dos pipelines de extração, transformação e carregamento (ETL) é projetada para lidar com gravações duplicadas, porque o preenchimento e a reformulação exigem isso. Os coletores de dados que oferecem suporte a failover transparente podem lidar com gravações duplicadas com mesclagem de registros ou excluindo e inserindo todos os registros no intervalo de tempo específico.

Para coletores de dados que alteram pontos de extremidade após o failover, o armazenamento primário e secundário pode ter dados duplicados ou parciais. Você precisa mesclar os dados manualmente.

Verifique a testemunha e controle o fluxo da tubulação (opcional)

Em geral, você precisa projetar seus pipelines para incluir atividades, como atividades de falha e pesquisa, para reiniciar pipelines com falha a partir do ponto de interesse.

  1. Adicione um parâmetro global em seu data factory para indicar a região, por exemplo region='EastUS' no data factory primário e region='CentralUS' no secundário.

  2. Crie uma testemunha em uma terceira região. A testemunha pode ser uma chamada REST ou qualquer tipo de armazenamento. A testemunha retorna a região primária atual, por exemplo 'EastUS', por padrão.

  3. Quando ocorrer um desastre, atualize manualmente a testemunha para retornar a nova região primária, por exemplo 'CentralUS'.

  4. Adicione uma atividade em seu pipeline para procurar a testemunha e comparar o valor primário atual com o parâmetro global.

    • Se os parâmetros corresponderem, esse pipeline estará sendo executado na região primária. Prossiga com o trabalho real.
    • Se os parâmetros não corresponderem, esse pipeline estará sendo executado na região secundária. Apenas retornam o resultado.

Observação

Essa abordagem introduz uma dependência da pesquisa de testemunhas em seu pipeline. A falha na leitura da testemunha interrompe todas as execuções do pipeline.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

  • Mario Zimmermann | Gerente Principal de Engenharia de Software - Equipe do Azure Data Factory

  • Wee Hyong Tok | Diretor Principal da PM - Equipe do Azure Data Factory

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas