Fiabilidade no Azure Data Factory

Este artigo descreve o suporte de confiabilidade no Azure Data Factory. Abrange a resiliência intrarregional através de zonas de disponibilidade e implantações multirregionais.

A fiabilidade é uma responsabilidade partilhada entre o Cliente e a Microsoft. Você pode usar este guia para determinar quais opções de confiabilidade atendem aos seus objetivos de negócios específicos e metas de tempo de atividade.

Você pode usar o Data Factory para criar pipelines de dados flexíveis e poderosos para integração e transformação de dados sem servidor. Como resultado, ao definir seu plano de continuidade de negócios para confiabilidade, você precisa considerar os requisitos de confiabilidade e a orientação para:

• Pipelines do Data Factory.

• Tempos de execução de integração (IRs), que conectam-se a armazenamentos de dados e executam atividades definidas no seu pipeline.

• Armazenamentos de dados que se conectam ao data factory. Para ajudar a garantir que os armazenamentos de dados atendam aos seus requisitos de continuidade de negócios, consulte a documentação e as orientações de confiabilidade do produto.

Visão geral da arquitetura de confiabilidade

O Data Factory consiste em vários componentes de infraestrutura. Cada componente suporta a confiabilidade da infraestrutura de várias maneiras.

Os componentes do Data Factory incluem:

• O serviço principal do Data Factory, que gerencia os gatilhos do pipeline e supervisiona a coordenação das atividades do pipeline. O serviço principal também gerencia metadados para cada componente no data factory. A Microsoft gerencia o serviço principal.

• Runtimes de integração (IRs), que executam atividades específicas num pipeline. Existem diferentes tipos de IRs.

  • IRs gerenciados pela Microsoft, que incluem o IR do Azure e o IR do Azure-SQL Server Integration Services (Azure-SSIS). A Microsoft gerencia os componentes que compõem esses tempos de execução. Em alguns cenários, você define configurações que afetam a resiliência de seus RIs.

  • Tempos de execução de integração auto-hospedados (SHIRs). A Microsoft fornece software que você pode executar em sua própria infraestrutura de computação para executar algumas partes de seus pipelines do Data Factory. Você é responsável pela implantação e gerenciamento de recursos de computação e pela resiliência desses recursos de computação.

Falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos lidem com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Ao usar o Data Factory, é importante se preparar para falhas transitórias, especialmente ao projetar pipelines e atividades.

Idempotência

Suas atividades de pipeline devem ser idempotentes, o que significa que elas podem ser repetidas várias vezes sem causar quaisquer efeitos adversos. Se ocorrer uma falha transitória, como uma falha de rede ou uma interrupção da zona de disponibilidade, o Data Factory poderá executar novamente as atividades do pipeline. Essa nova execução pode criar registros duplicados.

Para evitar a inserção de registros duplicados devido a uma falha transitória, implemente as seguintes práticas recomendadas:

• Use identificadores exclusivos para cada registro antes de gravar no banco de dados. Essa abordagem pode ajudá-lo a encontrar e eliminar registros duplicados.

• Utilize uma estratégia de upsert para conectores que suportam upsert. Antes de ocorrer a inserção de registro duplicado, use essa abordagem para verificar se um registro já existe. Se existir, atualize-o. Se não existir, insira-o. Por exemplo, comandos SQL como MERGE ou ON DUPLICATE KEY UPDATE seguem essa abordagem upsert.

• Use estratégias de ação de cópia. Para obter mais informações, consulte Verificação de consistência de dados na atividade de cópia.

Políticas de Reintentar

Você pode usar políticas de repetição para configurar partes do pipeline para tentar novamente se houver um problema, como falhas transitórias em recursos conectados. No Data Factory, você pode configurar políticas de repetição nos seguintes tipos de objeto de pipeline:

• Gatilhos de janela deslizante
• Atividades de execução

Para obter mais informações sobre como alterar ou desativar políticas de tentativa para os gatilhos e atividades do data factory, consulte Execuções e gatilhos de pipeline.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Data Factory suporta redundância de zona, o que fornece resiliência a falhas em zonas de disponibilidade. Esta seção descreve como cada parte do serviço Data Factory oferece suporte à redundância de zona.

Regiões suportadas

Os recursos do Data Factory com redundância de zona podem ser implantados em qualquer região que ofereça suporte a zonas de disponibilidade.

Considerações

Serviço principal: A Microsoft gerencia os componentes no serviço principal do Data Factory e os distribui pelas zonas de disponibilidade.

RIs: O suporte à redundância de zona depende do tipo de RI que você usa.

• Um IR do Azure dá suporte à redundância de zona e a Microsoft gerencia esse recurso.

• Um IR Azure-SSIS requer que você implante pelo menos dois nós. Esses nós são alocados em diferentes zonas de disponibilidade automaticamente.

• Um SHIR lhe dá a responsabilidade de implantar a infraestrutura de computação para hospedar o tempo de execução. Você pode implantar vários nós, como máquinas virtuais individuais (VMs), e configurá-los para alta disponibilidade. Em seguida, você pode distribuir esses nós em várias zonas de disponibilidade. Para obter mais informações, consulte Alta disponibilidade e escalabilidade.

Custo

Serviço principal: Não se aplica nenhum custo extra para redundância de zona.

RIs: O custo da redundância de zona varia dependendo do tipo de RI que você usa.

• Um IR do Azure inclui redundância de zona sem custo extra.

• Um IR Azure-SSIS requer que você implante pelo menos dois nós para obter redundância de zona. Para obter mais informações sobre como cada nó é cobrado, consulte Exemplo de preços: execução de pacotes SSIS numa Azure-SSIS IR.

• Um SHIR requer que você implante e gerencie a infraestrutura de computação. Para alcançar a resiliência de zona, você precisa distribuir seus recursos de computação por várias zonas. Dependendo do número de nós implantados e de como configurá-los, você pode incorrer em custos extras dos serviços de computação subjacentes e outros serviços de suporte. Não há nenhum custo extra para executar o SHIR em vários nós.

Configurar o suporte à zona de disponibilidade

Serviço principal: Nenhuma configuração necessária. O serviço principal do Data Factory suporta automaticamente redundância de zona.

IRs:

• Um IR do Azure: Sem necessidade de configuração. O IR do Azure habilita automaticamente a redundância de zona.

• Um RI Azure-SSIS: Não é necessária qualquer configuração. Um IR Azure-SSIS habilita automaticamente a redundância de zona quando é implantado com dois ou mais nós.

• Um SHIR requer que você configure sua própria resiliência, o que inclui distribuir seus nós por várias zonas de disponibilidade.

Planejamento e gerenciamento de capacidade

Serviço principal: O serviço principal do Data Factory é dimensionado automaticamente com base na demanda, e você não precisa planejar ou gerenciar a capacidade.

IRs:

• Um IR do Azure é dimensionado automaticamente com base na demanda e você não precisa planejar ou gerenciar a capacidade.

• Um IR Azure-SSIS requer que você configure especificamente o número de nós que você usa. Para se preparar para falhas na zona de disponibilidade, considere sobredimensionar a capacidade do seu IR. O excesso de provisionamento permite que a solução tolere algum grau de perda de capacidade e ainda continue a funcionar sem desempenho degradado. Para obter mais informações, consulte Gerenciar a capacidade por excesso de provisionamento.

• Um SHIR requer que você configure sua própria capacidade e escala. Considere o sobreprovisionamento ao implantar um SHIR.

Funcionamento normal

Roteamento de tráfego entre zonas: Durante as operações normais, o Data Factory distribui automaticamente as atividades nos pipelines, os gatilhos e outros trabalhos entre instâncias funcionais em cada zona de disponibilidade.

Experiência de redução de zona

Deteção e resposta: A plataforma Data Factory é responsável por detetar uma falha em uma zona de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona nos seus pipelines ou outros componentes.

Solicitações ativas: Todos os pipelines e ativadores em andamento continuam a ser executados, e não haverá interrupção imediata devido a uma falha de zona. No entanto, as atividades em andamento durante uma falha de zona podem falhar e ser reiniciadas. É importante projetar atividades para serem idempotentes, o que as ajuda a se recuperar de falhas de zona e outras falhas. Para obter mais informações, consulte Falhas transitórias.

Retorno após falha

Quando a zona de disponibilidade se recupera, o Data Factory retorna automaticamente à zona original. Você não precisa fazer nada para iniciar um failback de zona nas suas pipelines ou outros componentes.

No entanto, se você usar um SHIR, talvez seja necessário reiniciar seus recursos de computação se eles tiverem sido interrompidos.

Testagem para falhas de zona

Para o serviço principal e para IRs do Azure e Azure-SSIS, o Data Factory gerencia roteamento de tráfego, failover e failback para recursos redundantes de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou validar processos de falha da zona de disponibilidade.

Para SHIRs, você pode usar o Azure Chaos Studio para simular uma falha de zona de disponibilidade em uma VM do Azure.

Suporte multi-região

Os recursos do Data Factory são implantados em uma única região do Azure. Se a região ficar indisponível, a sua fábrica de dados também ficará indisponível. No entanto, há abordagens que você pode usar para ajudar a garantir resiliência a interrupções na região. Estas abordagens dependem se o *Data Factory* está numa região emparelhada ou não-emparelhada e dos seus requisitos e configuração específicos.

Failover gerenciado pela Microsoft para uma região emparelhada

O Data Factory oferece suporte a failover gerenciado pela Microsoft para fábricas de dados em regiões emparelhadas, exceto para o Brasil, Sul e Sudeste Asiático. No caso improvável de uma falha de região prolongada, a Microsoft pode iniciar um failover regional da sua instância do Data Factory.

Devido aos requisitos de residência de dados no Brasil, Sul e Sudeste Asiático, os dados do Data Factory são armazenados apenas na região local usando o armazenamento redundante de zona de Armazenamento do Azure. Para o Sudeste Asiático, todos os dados são armazenados em Singapura. Para o Sul do Brasil, todos os dados são armazenados no Brasil.

Para fábricas de dados em regiões não emparelhadas, ou no Brasil Sul ou Sudeste Asiático, a Microsoft não executa o failover regional em seu nome.

Importante

A Microsoft aciona o failover gerenciado pela Microsoft. É provável que ocorra após um atraso significativo e seja feito com o melhor esforço possível. Existem também algumas exceções a este processo. Você pode ter alguma perda dos seus metadados do Data Factory. O failover de recursos do Data Factory pode ocorrer em um momento diferente do tempo de failover de outros serviços do Azure.

Se você precisar ser resiliente a interrupções na região, considere usar uma das abordagens alternativas de várias regiões.

Alternância de Mecanismos de Redundância

Para se preparar para um failover, pode haver algumas considerações extras, dependendo do RI que você usa.

• Você pode configurar o IR do Azure para resolver automaticamente a região que ele usa. Se a região estiver definida para resolução automática e houver uma interrupção na região primária, o IR do Azure efetuará automaticamente failover para a região emparelhada. Esse failover está sujeito a limitações. Para configurar a região de IR do Azure para sua implementação ou despacho de atividade na configuração de RI, defina a região para resolução automática.

• Azure-SSIS IR failover é gerido separadamente de um failover gerido pela Microsoft da fábrica de dados. Para obter mais informações, consulte Abordagens alternativas de várias regiões.

• Um SHIR é executado na infraestrutura pela qual você é responsável, portanto, um failover gerenciado pela Microsoft não se aplica a SHIRs. Para obter mais informações, consulte Abordagens alternativas de várias regiões.

Reconfiguração pós-failover

Depois de concluído um failover gerido pela Microsoft, poderá aceder ao seu pipeline do Azure Data Factory na região emparelhada. No entanto, após concluir o failover, poderá ser necessário realizar alguma reconfiguração dos IRs ou outros componentes. Esse processo inclui o restabelecimento da configuração de rede.

Abordagens multirregionais alternativas

Se você precisar que seus pipelines sejam resilientes a interrupções regionais e precisar de controle sobre o processo de failover, considere o uso de um pipeline orientado por metadados.

• Configure o controle do código-fonte para o Data Factory para controlar e auditar quaisquer alterações em seus metadados. Você pode usar essa abordagem para acessar seus arquivos JSON de metadados para pipelines, conjuntos de dados, serviços vinculados e gatilhos. O Data Factory suporta diferentes tipos de repositório Git, como o Azure DevOps e o GitHub. Para obter mais informações, consulte Controle do código-fonte no Data Factory.

• Use um sistema de integração contínua e entrega contínua (CI/CD), como o Azure DevOps, para gerenciar seus metadados e implantações de pipeline. Você pode usar CI/CD para restaurar rapidamente operações para uma instância em outra região. Se uma região não estiver disponível, você poderá provisionar um novo data factory manualmente ou por meio de automação. Depois que a nova fábrica de dados for criada, você poderá restaurar seus pipelines, conjuntos de dados e serviços vinculados JSON a partir do repositório Git existente. Para obter mais informações, consulte Continuidade de negócios e recuperação de desastres (BCDR) para pipelines do Data Factory e do Azure Synapse Analytics.

Dependendo do RI que você usa, pode haver outras considerações.

• Um IR Azure-SSIS usa um banco de dados armazenado no Banco de Dados SQL do Azure ou na Instância Gerenciada SQL do Azure. Você pode configurar a replicação geográfica ou um grupo de failover para esse banco de dados. O banco de dados Azure-SSIS está localizado em uma região primária do Azure que tem acesso de leitura e gravação. O banco de dados é replicado continuamente para uma região secundária com acesso apenas de leitura. Se a região primária não estiver disponível, um failover será acionado, o que fará com que os bancos de dados primário e secundário troquem de função.

  Você também pode configurar um par de IR do Azure SSIS em espera dupla que funciona em sincronia com um banco de dados SQL do Azure ou um grupo de failover de instância gerenciada do SQL.

  Para obter mais informações, consulte Configurar um IR Azure-SSIS para BCDR.

• Um SHIR é executado na infraestrutura que você gerencia. Se o SHIR for implantado em uma VM do Azure, você poderá usar o Azure Site Recovery para disparar o failover de VM para outra região.

Backup e restauração

O Data Factory suporta CI/CD por meio da integração de controlo de origem, para que se possa fazer backup dos metadados de uma instância de Data Factory. Os pipelines de CI/CD implantam esses metadados perfeitamente em um novo ambiente. Para obter mais informações, consulte CI/CD no Data Factory.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) do Azure Data Factory descreve a disponibilidade esperada do serviço. Este acordo descreve igualmente as condições a preencher para concretizar esta expectativa. Para compreender estas condições, certifique-se de que revê os Contratos de Nível de Serviço (SLA) dos Serviços Online.

Conteúdo relacionado

• Fiabilidade no Azure