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 os pipelines do Azure Data Factory e do Azure Synapse Analytics.
As estratégias 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 e entrega contínua (CI/CD).
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
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 dentro de um perímetro definido pela latência.
- As zonas de disponibilidade do Azure são locais fisicamente separados dentro de cada região do Azure que são tolerantes a falhas locais.
- Todas as regiões e zonas de disponibilidade do Azure estã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 zona de disponibilidade têm pelo menos três zonas de disponibilidade separadas para garantir resiliência.
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 resilientes de zona do Data Factory 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
- Conjuntos de Dados
- Serviços ligados
- Integration runtime (Runtime de integração)
- Acionadores
Dados de monitorização
- Pipeline
- Acionadores
- 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, o 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, o Backup do Azure e a recuperação de desastres, 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 precisar validar seus pipelines recuperados, você poderá fazer backup dos modelos do Azure Resource Manager para seus pipelines de produção em armazenamento secreto e comparar os pipelines recuperados com os backups.
A equipe Global do Azure realiza exercícios BCDR regulares, e o Azure Data Factory e o Azure Synapse Analytics participam desses exercícios. O drill BCDR simula uma falha de região e realiza failover de 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 uma fábrica de dados ou um espaço de trabalho do Azure Synapse na região secundária. Em caso de exclusão acidental do pipeline do Data Factory ou do Azure Synapse, interrupçõ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 DR secundária 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.
Potenciais casos de utilização
A redundância gerenciada pelo usuário é útil em cenários como:
- Exclusão acidental de artefatos de tubulação 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
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte 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 suportam zonas de disponibilidade e foram concebidos 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, interrupções ou erros humanos na região principal. Usando CI/CD, a fábrica de dados e os pipelines 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 custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
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. Este cenário pode implicar custos acrescidos. Para estimar custos, use a calculadora de preços do Azure.
Para obter exemplos de preços do Data Factory e do Azure Synapse Analytics, consulte:
- Noções básicas sobre os preços do Azure Data Factory por meio de exemplos
- Preços do Azure Synapse Analytics
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.
Usando a abordagem de recuperação de CI/CD gerenciada pelo usuário, você pode integrar ao Azure Repos ou ao GitHub. Para obter mais informações sobre as práticas recomendadas de CI/CD, consulte Práticas recomendadas para CI/CD.
Implementar este cenário
Execute as seguintes ações para configurar o DR automatizado ou gerenciado 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 tempo de execução de integração (IR) do Azure para sua execução ou despacho de atividade na configuração do tempo de execução da integração. Para habilitar o failover automático no caso de uma interrupção regional completa, defina a Região como Auto Resolve.
No contexto dos tempos de execução de integração, o IR realiza failover automaticamente para a região emparelhada quando você seleciona Auto Resolve como a região IR. Para outras regiões de locais específicos, você pode criar uma fábrica de dados secundária em outra região e usar CI/CD para provisionar sua fábrica de dados a partir do repositório Git.
Para redes virtuais gerenciadas, o Data Factory também alterna automaticamente para o IR gerenciado.
O failover automático gerenciado do Azure não se aplica ao tempo de execução de integração auto-hospedado (SHIR), porque a infraestrutura é gerenciada pelo cliente. Para obter orientação sobre como configurar vários nós para maior disponibilidade com SHIR, consulte Criar e configurar um tempo de execução de integração auto-hospedado.
Para configurar o BCDR para IR do Azure-SSIS, consulte Configurar o tempo de execução da integração Azure-SSIS para continuidade de negócios e recuperação de desastres (BCDR).
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 pontos finais privados usando a API de aprovaçã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 do pipeline do Data Factory ou do Azure Synapse.
Para usar o CI/CD do pipeline do Data Factory, consulte Integração e entrega contínuas no Azure Data Factory e Controle do código-fonte no Azure Data Factory.
Para usar o CI/CD do pipeline do Azure Synapse, consulte Integração e entrega contínuas para um espaço de trabalho do Azure Synapse Analytics. Certifique-se de inicializar o espaço de trabalho do Azure Synapse primeiro. Para obter mais informações, consulte Controle do código-fonte no Synapse Studio.
Ao implantar 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 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 da 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 melhorias de CI/CD relacionadas à implantação de gatilhos de pipeline.
Lidar com gravações duplicadas
A maioria dos pipelines de extração, transformação e carga (ETL) são projetados para lidar com gravações duplicadas, porque o preenchimento e a reafirmação os exigem. Os coletores de dados que suportam 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 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 do ponto de interesse.
Adicione um parâmetro global em seu data factory para indicar a região, por exemplo
region='EastUS', no data factory primário eregion='CentralUS'no secundário.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.Quando ocorrer um desastre, atualize manualmente a testemunha para retornar a nova região primária, por exemplo
'CentralUS'.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 está sendo executado na região primária. Prossiga com o trabalho real.
- Se os parâmetros não corresponderem, esse pipeline será executado na região secundária. Basta devolver o resultado.
Nota
Essa abordagem introduz uma dependência da pesquisa de testemunhas em seu pipeline. A falta de leitura da testemunha interrompe todas as execuções do gasoduto.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
Krishnakumar Rukmangathan - Brasil | Gestor de Programa Sénior - Equipa do Azure Data Factory
Sunil Sabat - Brasil | Gerente de Programa Principal - Equipe do Azure Data Factory
Outros contribuidores:
Mario Zimmermann - Brasil | Gerente Principal de Engenharia de Software - Equipe do Azure Data Factory
Wee Hyong Tok - Brasil | Diretor Principal do PM - Azure Data Factory team
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Gerenciamento de continuidade de negócios no Azure
- Resiliência no Azure
- Terminologia de resiliência do Azure
- Regiões e zonas de disponibilidade
- Replicação entre regiões no Azure
- Guia de decisão de regiões do Azure
- Serviços do Azure que dão suporte a zonas de disponibilidade
- Responsabilidade partilhada na cloud
- Redundância de dados do Azure Data Factory
- Integration runtime in Azure Data Factory (Runtime de integração no Azure Data Factory)
- Pipelines e atividades no Azure Data Factory e no Azure Synapse Analytics
- Integração de dados no Azure Synapse Analytics versus Azure Data Factory
Recursos relacionados
- Recuperação de desastres em escala empresarial
- Recuperação de desastres SMB com o Azure Site Recovery
- Crie alta disponibilidade em sua estratégia BCDR
- Escolher uma tecnologia de orquestração de pipeline de dados no Azure
- Continuidade de negócios e recuperação de desastres para Aplicativos Lógicos do Azure