Escolher a configuração certa do runtime de integração para seu cenário

O runtime de integração é uma parte muito importante da infraestrutura para a solução de integração de dados fornecida pelo Azure Data Factory. Isso exige considerar totalmente como se adaptar à estrutura de rede e à fonte de dados existentes no início da criação da solução, além de considerar o desempenho, a segurança e o custo.

Comparação dos tipos diferentes de runtimes de integração

No Azure Data Factory, temos três tipos de runtimes de integração: o runtime de integração do Azure, o runtime de integração auto-hospedada e o runtime de integração do Azure-SSIS. Para o runtime de integração do Azure, também é possível habilitar uma rede virtual gerenciada que torna a arquitetura diferente do runtime de integração global do Azure.

Esta tabela lista as diferenças em alguns aspectos de todos os runtimes de integração. Você pode escolher o mais adequado às suas necessidades reais. Com relação ao runtime de integração do Azure-SSIS, saiba mais no artigo Criar um runtime de integração do Azure-SSIS.

Recurso	Azure Integration runtime	Runtime de integração do Azure com rede virtual gerenciada	runtime de integração auto-hospedada
Computação gerenciada	S	S	N
Autoscale	Y	Y*	N
Fluxo de dados	S	S	N
Acesso a dados locais	N	S**	S
Link Privado/Ponto de extremidade privado	N	S***	S
Componente/driver personalizado	N	N	S

* Quando a TTL (vida útil) está habilitada, o tamanho da computação do runtime de integração é reservado de acordo com a configuração e não pode ser dimensionado automaticamente.

** Ambientes locais precisam estar conectados ao Azure por meio do Express Route ou de uma VPN. Não há suporte para componentes e drivers personalizados.

*** Os pontos de extremidade privados são gerenciados pelo serviço Azure Data Factory.

É muito importante escolher um tipo de runtime de integração adequado. Além de ser adequado para a arquitetura e os requisitos de integração de dados existentes, você também precisa considerar como atender às necessidades de negócios crescentes e a aumentos futuros na carga de trabalho. Mas não há uma abordagem de ajuste generalizado. A seguinte questão pode ajudar você a ponderar a decisão:

1. Quais são os locais do runtime de integração e do armazenamento de dados?
   O local do runtime de integração define o local da respectiva computação de back-end, bem como o local em que a movimentação de dados, a expedição de atividades e a transformação de dados são executadas. Para obter melhor desempenho e eficiência de transmissão, o runtime de integração deve estar mais próximo da fonte de dados ou do coletor.

   • O runtime de integração do Azure detecta automaticamente o local mais adequado com base em algumas regras (também conhecido como resolução automática). Veja os detalhes aqui: Local do Azure IR.
   • O runtime de integração do Azure com uma rede virtual gerenciada tem a mesma região que o data factory. Ele não pode ser resolvido automaticamente como o runtime de integração do Azure.
   • O runtime de integração auto-hospedada está localizado na região dos computadores locais ou das máquinas virtuais do Azure.

2. O armazenamento de dados é acessível publicamente?
   Se o armazenamento de dados for acessível publicamente, a diferença entre os tipos de runtimes de integração não será muito grande. Se o armazenamento estiver atrás de um firewall ou em uma rede privada, como uma rede local ou virtual, as melhores opções serão o runtime de integração do Azure com uma rede virtual gerenciada ou o runtime de integração auto-hospedada.

   • Alguma configuração adicional será necessária, como o serviço de Link Privado e o Load Balancer, ao usar o runtime de integração do Azure com uma rede virtual gerenciada para acessar um armazenamento de dados com base em um firewall ou em uma rede privada. Consulte este tutorial Acessar o SQL Server local da VNet gerenciada do Data Factory usando o ponto de extremidade privado para ver um exemplo. Se o armazenamento de dados estiver em um ambiente local, o local deverá estar conectado ao Azure por meio do Express Route ou de uma VPN S2S.
   • O runtime de integração auto-hospedada é mais flexível e não exige configurações adicionais, ExpressRoute ou VPN. Mas você precisa fornecer e manter o computador por conta própria.
   • Você também pode adicionar os IPs do runtime de integração do Azure à lista de permitidos do firewall e permitir que eles acessem o armazenamento de dados, mas essa não é uma solução desejável em ambientes de produção altamente seguros.

3. Qual é o nível de segurança de que você precisa durante a transmissão de dados?
   Se precisar processar dados altamente confidenciais, você precisará se defender contra, por exemplo, ataques man-in-the-middle durante a transmissão de dados. Sendo assim, você pode optar por usar um ponto de extremidade privado e o Link Privado para garantir a segurança dos dados.

   • Você pode criar pontos de extremidade privados gerenciados para seus armazenamentos de dados usando o runtime de integração do Azure com uma rede virtual gerenciada. Os pontos de extremidade privados são mantidos pelo serviço Azure Data Factory na rede virtual gerenciada.
   • Você também pode criar pontos de extremidade privados na rede virtual e o runtime de integração auto-hospedada pode aproveitá-los para acessar o armazenamentos de dados.
   • O runtime de integração do Azure não dá suporte ao ponto de extremidade privado e ao Link Privado.

4. Que nível de manutenção você pode fornecer?
   Manter a infraestrutura, os servidores e os equipamentos é uma das tarefas importantes do departamento de TI de uma empresa. Geralmente, leva muito tempo e esforço.

   • Você não precisa se preocupar com manutenção, por exemplo, com atualização, patch e versão, do runtime de integração do Azure e do runtime de integração do Azure com uma rede virtual gerenciada. O serviço Azure Data Factory se encarregará de todos os esforços de manutenção.
   • Como o runtime de integração auto-hospedada é instalado em computadores cliente, a manutenção deve ser feita pelos usuários finais. No entanto,é possível habilitar a atualização automática para obter automaticamente a versão mais recente do runtime de integração auto-hospedada sempre que houver uma atualização. Para saber mais sobre como habilitar a atualização automática e gerenciar o controle de versão do runtime de integração auto-hospedada, consulte o artigo Atualização automática e notificação de expiração do runtime de integração auto-hospedada. Também fornecemos uma ferramenta de diagnóstico para o runtime de integração auto-hospedada verificar alguns problemas comuns. Para saber mais sobre a ferramenta de diagnóstico, consulte o artigo Ferramenta de diagnóstico do runtime de integração auto-hospedada. Além disso, recomendamos usar o Azure Monitor e o Azure Log Analytics especificamente para coletar esses dados e habilitar o monitoramento em um só painel para seus runtimes de integração auto-hospedada. Saiba mais sobre como configurar isso no artigo Configurar o runtime de integração auto-hospedada para a coleta do Log Analytics.

5. Quais requisitos de simultaneidade você tem?
   Ao processar dados em grande escala, como uma migração de dados em grande escala, esperamos aprimorar a eficiência e a velocidade do processamento o máximo possível. Muitas vezes, a simultaneidade é um requisito importante para a integração de dados.

   • O runtime de integração do Azure tem o maior suporte para simultaneidade entre todos os tipos de runtime de integração. A DIU (unidade de integração de dados) é a unidade de capacidade para execução no Azure Data Factory. Você pode selecionar o número desejado de DIU, por exemplo, de atividade Copy. No escopo da DIU, você pode executar várias atividades ao mesmo tempo. Para diferentes grupos de regiões, teremos limitações superiores diferentes. Saiba mais sobre os detalhes desses limites no artigo Limites do Data Factory.
   • O runtime de integração do Azure com uma rede virtual gerenciada tem um mecanismo semelhante ao do runtime de integração do Azure, mas devido a algumas restrições de arquitetura, a simultaneidade a que ele pode dar suporte é menor que a do runtime de integração do Azure.
   • As atividades simultâneas que o runtime de integração auto-hospedada pode executar dependem do tamanho do computador e do cluster. Você poderá escolher um computador maior ou usar mais nós de integração auto-hospedada no cluster se precisar ter maior simultaneidade.

6. Você precisa de algum recurso específico?
   Há algumas diferenças funcionais entre os tipos de runtimes de integração.

   • O fluxo de dados tem suporte do runtime de integração do Azure e do runtime de integração do Azure com uma rede virtual gerenciada. No entanto, você não pode executar o fluxo de dados usando o runtime de integração auto-hospedada.
   • Se você precisar instalar componentes personalizados, como drivers ODBC, uma JVM ou um certificado do SQL Server, o runtime de integração auto-hospedada será a única opção. Componentes personalizados não têm suporte do runtime de integração do Azure nem do runtime de integração do Azure com uma rede virtual gerenciada.

Arquitetura para o runtime de integração

Com base nas características de cada runtime de integração, diferentes arquiteturas são necessárias para atender às necessidades comerciais de integração de dados. Veja a seguir algumas arquiteturas comuns que podem ser usadas como referência.

Azure Integration runtime

O runtime de integração do Azure é uma computação totalmente gerenciada e dimensionada automaticamente que você pode usar para mover dados de fontes que podem ou não ser do Azure.

1. O tráfego do runtime de integração do Azure para armazenamentos de dados ocorre por meio da rede pública.
2. Fornecemos uma variedade de IPs estáticos para o runtime de integração do Azure, e esses IPs podem ser adicionados à lista de permissões do firewall do armazenamento de dados de destino. Para saber mais sobre como obter IPs do runtime de Integração do Azure, consulte o artigo IPs do Azure Integration Runtime.
3. O runtime de integração do Azure pode ser resolvido automaticamente de acordo com a região da fonte de dados e do coletor de dados. Você também pode escolher uma região específica. Recomendamos que você escolha a região mais próxima da fonte de dados ou do coletor, o que pode fornecer um melhor desempenho de execução. Saiba mais sobre as considerações de desempenho no artigo Solucionar problemas da atividade de cópia no Azure IR.

Runtime de integração do Azure com rede virtual gerenciada

Ao usar o runtime de integração do Azure com uma rede virtual gerenciada, você deve usar pontos de extremidade privados gerenciados para conectar as fontes de dados e garantir a segurança de dados durante a transmissão. Com algumas configurações adicionais, como o serviço de Link Privado e o Load Balancer, os pontos de extremidade privados gerenciados também podem ser usados para acessar fontes de dados locais.

1. Um ponto de extremidade privado gerenciado não pode ser reutilizado em ambientes diferentes. Você precisa criar um conjunto de pontos de extremidade privados gerenciados para cada ambiente. Para todas as fontes de dados compatíveis com pontos de extremidade privados gerenciados, consulte o artigo Fontes de dados e serviços com suporte.
2. Você também pode usar pontos de extremidade privados gerenciados para conexões com recursos de computação externos que deseja orquestrar, como o Azure Databricks e o Azure Functions. Para ver a lista completa de recursos de computação externos com suporte, consulte o artigo Fontes de dados e serviços com suporte.
3. A rede virtual gerenciada é gerenciada pelo serviço Azure Data Factory. Não há suporte para o emparelhamento por VNET entre uma rede virtual gerenciada e uma rede virtual do cliente.
4. Os clientes não podem alterar diretamente as configurações, como a regra NSG, em uma rede virtual gerenciada.
5. Se alguma propriedade de um ponto de extremidade privado gerenciado for diferente entre os ambientes, você poderá substituí-la parametrizando essa propriedade e fornecendo o respectivo valor durante a implantação. Confira detalhes no artigo Melhores práticas de CI/CD.

runtime de integração auto-hospedada

Para impedir que dados de ambientes diferentes interfiram uns com os outros e garantir a segurança do ambiente de produção, precisamos criar um runtime de integração auto-hospedada correspondente para cada ambiente. Isso garante isolamento suficiente entre ambientes diferentes.

Como o runtime de integração auto-hospedada é executado em um computador gerenciado de cliente, para reduzir o custo, a manutenção e os esforços de atualização o máximo possível, podemos usar as funções compartilhadas do runtime de integração auto-hospedada para projetos diferentes no mesmo ambiente. Para obter detalhes sobre o compartilhamento do runtime de integração auto-hospedada, consulte o artigo Criar um runtime de integração auto-hospedada compartilhado no Azure Data Factory. Ao mesmo tempo, para tornar os dados mais seguros durante a transmissão, podemos optar por usar um link privado para conectar as fontes de dados e o cofre de chaves e conectar a comunicação entre o runtime de integração auto-hospedada e o serviço Azure Data Factory.

1. O ExpressRoute não é obrigatório. Sem o ExpressRoute, os dados não chegarão ao coletor por meio de redes privadas, como uma rede virtual ou um link privado, mas por meio da rede pública.
2. Se a rede local estiver conectada à rede virtual do Azure por meio do Express Route o da VPN, o runtime de integração auto-hospedada poderá ser instalado nas máquinas virtuais em uma VNET do Hub.
3. A arquitetura de rede virtual hub e spoke pode ser usada não apenas para projetos diferentes, mas também para ambientes diferentes (produção, QA e desenvolvimento).
4. O runtime de integração auto-hospedada pode ser compartilhado com vários data factories. O data factory primário faz referência a ele como um runtime de integração auto-hospedada compartilhado, e outros se referem como um runtime de integração auto-hospedada vinculado. Um runtime de integração auto-hospedada físico pode ter vários nós em um cluster. A comunicação ocorre apenas entre o runtime de integração auto-hospedada primário e o nó primário, com o trabalho sendo distribuído para nós secundários do nó primário.
5. As credenciais dos armazenamentos de dados locais podem ser armazenadas no computador local ou em um Azure Key Vault. O Azure Key Vault é altamente recomendado.
6. A comunicação entre o runtime de integração auto-hospedada e o data factory pode passar por um link privado. Atualmente, no entanto, a criação interativa por meio da Retransmissão do Azure e a atualização automática para a versão mais recente do centro de download não dão suporte ao link privado. O tráfego passa pelo firewall do ambiente local. Para obter mais informações, consulte o artigo Link Privado do Azure para Azure Data Factory.
7. O link privado é necessário apenas para o data factory primário. Todo o tráfego passa pelo data factory primário e, em seguida, para outros data factories.
8. É esperado o mesmo nome do runtime de integração auto-hospedada em todos os estágios de CI/CD. Você pode considerar o uso de um alocador ternário apenas para conter os runtimes de integração auto-hospedada compartilhados e usar o runtime de integração auto-hospedada vinculado nos diferentes estágios de produção. Para obter mais informações, consulte o artigo Integração e entrega contínuas.
9. Você pode controlar como o tráfego vai para o centro de download e para a Retransmissão do Azure usando as configurações da rede local e do Express Route, por meio de um proxy local ou de uma rede virtual do hub. Verifique se o tráfego é permitido pelas regras de proxy ou NSG.
10. Para proteger a comunicação entre os nós do runtime de integração auto-hospedada, habilite o acesso remoto da intranet com um certificado SSL/TLS. Para obter mais informações, consulte o artigo Habilitar o acesso remoto da intranet com certificado TLS/SSL (Avançado).