Criar e configurar um runtime de integração auto-hospedada

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Dica

Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!

O IR (runtime de integração) é a infraestrutura de computação que os pipelines do Azure Data Factory e do Synapse usam para fornecer funcionalidades de integração de dados entre diferentes ambientes de rede. Para obter detalhes sobre o IR, confira Visão geral do Integration Runtime.

Um runtime de integração auto-hospedada pode executar atividades de cópia entre um armazenamento de dados de nuvem e um armazenamento de dados em uma rede privada. Ele também pode distribuir atividades de transformação em relação aos recursos de computação em uma rede local ou em uma rede virtual do Azure. A instalação de um runtime de integração auto-hospedada precisa de um computador local ou uma máquina virtual em uma rede privada.

Este artigo descreve como você pode criar e configurar o IR auto-hospedado.

Observação

Recomendamos que você use o módulo Az PowerShell do Azure para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o Az.

Considerações para o uso de um IR auto-hospedado

• Você pode usar um único runtime de integração auto-hospedada para várias fontes de dados locais. Também poderá compartilhá-lo com outro data factory no mesmo locatário do Microsoft Entra. Para obter mais informações, confira Compartilhando um runtime de integração auto-hospedada.
• Você pode instalar apenas uma instância do runtime de integração auto-hospedada em um único computador. Se você tiver dois data factories que precisam acessar fontes de dados locais, use o recurso de compartilhamento de IR auto-hospedado para compartilhar o IR auto-hospedado ou instale o IR auto-hospedado em dois computadores locais, um para cada data factory ou workspace do Synapse. O workspace do Synapse não dá suporte ao compartilhamento do Integration Runtime.
• O runtime de integração auto-hospedada não precisa estar no mesmo computador que a fonte de dados. No entanto, ter o runtime de integração auto-hospedada mais perto da fonte de dados reduz o tempo para o runtime de integração auto-hospedada se conectar à fonte de dados. É recomendável instalar o runtime de integração auto-hospedada em um computador que seja diferente daquele que hospeda a fonte de dados local. Quando a fonte de dados e o runtime de integração auto-hospedada estão em computadores diferentes, o runtime de integração auto-hospedada não compete por recursos com a fonte de dados.
• Você pode ter vários runtimes da integração auto-hospedada em diferentes computadores conectados à mesma fonte de dados local. Por exemplo, se você tiver dois runtimes de integração auto-hospedada servindo dois data factories, a mesma fonte de dados local pode ser registrada com ambos os data factories.
• Use um runtime de integração auto-hospedada para dar suporte à integração de dados na rede virtual do Azure.
• Trate a fonte de dados como uma fonte de dados local protegida por um firewall mesmo quando você usar o Microsoft Azure ExpressRoute. Use o runtime de integração auto-hospedada para conectar o serviço ao data factory.
• Use o runtime de integração auto-hospedada mesmo se o repositório de dados estiver na nuvem em uma máquina virtual de IaaS (infraestrutura como serviço) do Azure.
• As tarefas podem falhar em um runtime de integração auto-hospedada instalado em um Windows Server para o qual a criptografia em conformidade com FIPS está habilitada. Para contornar esse problema, você tem duas opções: armazenar credenciais/valores de segredo em um Azure Key Vault ou desabilitar a criptografia compatível com FIPS no servidor. Para desabilitar a criptografia compatível com FIPS, altere o valor da subchave de registro a seguir de 1 (habilitado) para 0 (desabilitado): HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled. Se você usar o runtime de integração auto-hospedada como proxy para o runtime de integração do SSIS, a criptografia compatível com FIPS poderá ser habilitada e será usada ao migrar dados do local para o Armazenamento de Blobs do Azure como área de preparo.
• Detalhes completos de licenciamento são fornecidos na primeira página da configuração do runtime de integração auto-hospedada.

Observação

Atualmente, o runtime de integração auto-hospedada só pode ser compartilhado com vários data factories; ele não pode ser compartilhado entre workspaces do Synapse ou entre o data factory e o workspace do Synapse.

Fluxo de comando e fluxo de dados

Quando você move os dados entre a nuvem e o local, a atividade usa um runtime de integração auto-hospedada para transferir os dados entre uma fonte de dados local e a nuvem.

Veja a seguir um resumo de alto nível das etapas do fluxo de dados para a cópia com um IR auto-hospedado:

1. Um desenvolvedor de dados cria um runtime de integração auto-hospedado em um workspace do Azure Data Factory ou do Synapse usando o portal do Azure ou o cmdlet do PowerShell. Em seguida, ele cria um serviço vinculado para um armazenamento de dados local especificando a instância de runtime de integração auto-hospedado que o serviço deve usar para se conectar aos armazenamentos de dados.

2. O nó do runtime de integração auto-hospedada criptografa a credencial usando a DPAPI (Interface de Programação do Aplicativo de Proteção de Dados) do Windows e salva as credenciais localmente. Se vários nós forem definidos para alta disponibilidade, as credenciais serão mais sincronizadas em outros nós. Cada nó criptografa as credenciais usando a DPAPI e as armazena localmente. A sincronização de credenciais é transparente para o desenvolvedor de dados e é tratada pelo IR auto-hospedado.

3. Os pipelines do Azure Data Factory e do Synapse se comunica com o runtime de integração auto-hospedada para agendar e gerenciar trabalhos. A comunicação ocorre por meio de um canal de controle que usa uma conexão de Retransmissão do Azure compartilhada. Quando o trabalho de atividade precisa ser executado, o serviço enfileira a solicitação juntamente com as informações de credencial. Ele faz isso, caso as credenciais ainda não estejam armazenadas no runtime de integração auto-hospedada. O runtime de integração auto-hospedada inicia o trabalho depois de sondar a fila.

4. O runtime de integração auto-hospedada copia dados entre um armazenamento local e um armazenamento em nuvem. A direção da cópia depende de como a atividade Copy foi configurada no pipeline de dados. Para esta etapa, o runtime de integração auto-hospedada se comunica diretamente com os serviços de armazenamento baseado em nuvem, como Armazenamento de Blobs do Azure por um canal HTTPS seguro.

Pré-requisitos

• As versões com suporte do Windows são:
  • Windows 10
  • Windows 11
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022

A instalação do runtime de integração auto-hospedada em um controlador de domínio não tem suporte.

• O runtime de integração auto-hospedada exige um Sistema Operacional de 64 bits com o .NET Framework 4.7.2 ou posterior. Confira Requisitos de sistema do .NET Framework para obter detalhes.
• A configuração mínima recomendada para o computador de runtime de integração auto-hospedada é um processador de 2 GHz com 4 núcleos, 8 GB de RAM e 80 GB de espaço disponível no disco rígido. Para obter detalhes sobre os requisitos do sistema, confira Baixar.
• Se o computador de host hibernar, o runtime de integração auto-hospedada não responderá às solicitações de dados. Configure um plano de energia adequado no computador antes de instalar o runtime de integração auto-hospedada. Se o computador estiver configurado para hibernar, o instalador do runtime de integração auto-hospedada avisará com uma mensagem.
• Você deve ser um administrador no computador para instalar e configurar com sucesso o runtime de integração auto-hospedada.
• As execuções de atividade Copy ocorrem em uma frequência específica. A utilização de processador e RAM no computador segue o mesmo padrão em horários ociosos e de pico. A utilização de recursos também depende muito do volume de dados movido. Quando vários trabalhos de cópia estiverem em andamento, você verá o uso do recurso aumentar durante horários de pico.
• As tarefas podem falhar durante a extração de dados nos formatos Parquet, ORC ou Avro. Para saber mais sobre Parquet, confira Formato Parquet no Azure data Factory. A criação de arquivo é executada no computador de integração auto-hospedada. Para funcionar conforme o esperado, a criação de arquivo tem os seguintes pré-requisitos:
  • Java Runtime (JRE) versão 11 de um provedor JRE, como Microsoft OpenJDK 11 ou Eclipse Temurin 11. Certifique-se de que a variável de ambiente do sistema JAVA_HOME esteja definida para a pasta JDK (e não apenas para a pasta JRE); talvez seja necessário adicionar a pasta bin à variável de ambiente PATH do sistema.

  Observação

  Talvez seja necessário ajustar as configurações do Java caso ocorram erros de memória, conforme descrito na documentação do Formato Parquet.

Observação

Se você estiver executando na nuvem do governo, examine Conexão na nuvem do governo.

Configuração de um runtime de integração auto-hospedada

Para criar e configurar um runtime de integração auto-hospedada, siga os procedimentos abaixo.

Criar um IR auto-hospedado usando o Azure PowerShell

1. Você pode usar o Azure PowerShell para essa tarefa. Veja um exemplo:

   Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"
   

2. Faça o download e instale o runtime de integração auto-hospedada em um computador local.

3. Recupere a chave de autenticação e registre o runtime de integração auto-hospedada com ela. Aqui está um exemplo do PowerShell:

   
   Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName  
   
   

Observação

Executar o comando do PowerShell no Azure Governamental, confira Conexão para o Azure Governamental com o PowerShell.

Criar um IR auto-hospedado na interface do usuário

Use as etapas a seguir para criar um IR auto-hospedado usando a interface do usuário do Azure Data Factory ou do Azure Synapse.

Azure Data Factory

1. Na página inicial da interface do usuário do Azure Data Factory, selecione a guia Gerenciar no painel mais à esquerda.

   

2. Selecione Runtimes de integração no painel esquerdo e, em seguida, selecione + Novo.

   

3. Na página Configuração do runtime de integração, selecione Azure, Auto-Hospedado e Continuar.

4. Na página a seguir, selecione Auto-Hospedado para criar um IR auto-hospedado e, em seguida, selecione Continuar.

Azure Synapse

1. Na página inicial da interface do usuário do Azure Synapse, selecione a guia Gerenciar no painel mais à esquerda.

   

2. Selecione Runtimes de integração no painel esquerdo e, em seguida, selecione + Novo.

   

3. Na página a seguir, selecione Auto-Hospedado para criar um IR auto-hospedado e, em seguida, selecione Continuar.

Configurar um IR auto-hospedado na interface do usuário

1. Insira um nome para o IR e selecione Criar.

2. Na página Configuração do runtime de integração, selecione o link em Opção 1 para abrir a configuração expressa no computador. Ou siga as etapas em Opção 2 para configurar manualmente. As instruções a seguir são baseadas na configuração manual:

   

   1. Copie e cole a chave de autenticação. Selecione Baixar e instalar o runtime de integração.

   2. Baixe o runtime de integração auto-hospedada em uma máquina local do Windows. Execute o instalador.

   3. Na página Registrar Integration Runtime (auto-hospedado) , cole a chave salva anteriormente e selecione Registrar.

      

   4. Na página Novo nó do Integration Runtime (auto-hospedado) , selecione Concluir.

3. Depois que o runtime de integração auto-hospedada estiver registrado com sucesso, você verá a seguinte janela:

   

Configurar um IR auto-hospedado em uma VM do Azure usando modelo do ARM

É possível automatizar a configuração do IR auto-hospedado em uma máquina virtual do Azure usando Criar modelo de IR auto-hospedado. O modelo fornece uma maneira fácil de ter um IR auto-hospedado totalmente funcional em uma rede virtual do Azure. O IR tem recursos de alta disponibilidade e escalabilidade, contanto que você defina a contagem de nós como 2 ou mais.

Configurar um IR auto-hospedado existente usando o PowerShell local

Você pode usar uma linha de comando para configurar ou gerenciar um IR auto-hospedado existente. Esse uso pode ajudar especialmente a automatizar a instalação e o registro de nós de IR auto-hospedado.

O Dmgcmd.exe está incluído no instalador auto-hospedado. Normalmente, ele está localizado na pasta C:\Arquivos de Programas\Microsoft Integration Runtime\5.0\Shared\. Esse aplicativo dá suporte a vários parâmetros e pode ser invocado por meio de uma linha de comando usando scripts em lotes para automação.

Use o aplicativo da maneira a seguir:

dmgcmd ACTION args...

Estes são os detalhes das ações e dos argumentos do aplicativo:

ACTION	args	Descrição
-rn, -RegisterNewNode	"<AuthenticationKey>" ["<NodeName>"]	Registre um nó de runtime de integração auto-hospedada com a chave de autenticação especificada e o nome do nó.
-era, -EnableRemoteAccess	"<port>" ["<thumbprint>"]	Habilite o acesso remoto no nó atual para configurar um cluster de alta disponibilidade. Ou habilite as credenciais de configuração diretamente no IR auto-hospedado, sem passar por um workspace do Azure Data Factory ou do Azure Synapse. Você faz a última opção usando o cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential de um computador remoto na mesma rede.
-erac, -EnableRemoteAccessInContainer	"<port>" ["<thumbprint>"]	Habilite o acesso remoto para o nó atual, quando o nó for executado em um contêiner.
-dra, -DisableRemoteAccess		Desabilite o acesso remoto para o nó atual. O acesso remoto é necessário para a configuração de vários nós. O cmdlet do PowerShell New-AzDataFactoryV2LinkedServiceEncryptedCredential ainda funciona, mesmo quando o acesso remoto está desabilitado. Esse comportamento é verdadeiro, contanto que o cmdlet seja executado no mesmo computador que o nó de IR auto-hospedado.
-k, -Key	"<AuthenticationKey>"	Substitua ou atualize a chave de autenticação anterior. Tenha cuidado com essa ação. O nó de IR auto-hospedado anterior pode ficar offline, se a chave for de um runtime de integração novo.
-gbf, -GenerateBackupFile	"<filePath>" "<password>"	Gere um arquivo de backup para o nó atual. O arquivo de backup inclui a chave do nó e as credenciais do repositório de dados.
-ibf, -ImportBackupFile	"<filePath>" "<password>"	Restaure o nó em um arquivo de backup.
-r, -Restart		Reinicie o serviço de host de runtime de integração auto-hospedada.
-s, -Start		Inicie o serviço de host de runtime de integração auto-hospedada.
-t, -Stop		Pare o serviço de host de runtime de integração auto-hospedada.
-sus, -StartUpgradeService		Inicie o serviço de atualização de runtime de integração auto-hospedada.
-tus, -StopUpgradeService		Pare o serviço de atualização de runtime de integração auto-hospedada.
-tonau, -TurnOnAutoUpdate		Ative a atualização automática do runtime de integração auto-hospedada. Esse comando serve apenas para o Azure Data Factory V1.
-toffau, -TurnOffAutoUpdate		Desative a atualização automática do runtime de integração auto-hospedada. Esse comando serve apenas para o Azure Data Factory V1.
-ssa, -SwitchServiceAccount	"<domain\user>" ["<password>"]	Defina DIAHostService para executar como uma nova conta. Use a senha vazia "" para contas de sistema e contas virtuais.
-elma, -EnableLocalMachineAccess		Habilitar acesso ao computador local (localhost, IP privado) no nó do IR auto-hospedado atual. No cenário de Alta Disponibilidade do IR auto-hospedado, a ação precisa ser invocada em cada nó do IR auto-hospedado.
-dlma, -DisableLocalMachineAccess		Desabilitar o acesso ao computador local (localhost, IP privado) no nó do IR auto-hospedado atual. No cenário de Alta Disponibilidade do IR auto-hospedado, a ação precisa ser invocada em cada nó do IR auto-hospedado.
-DisableLocalFolderPathValidation		Desabilite a validação de segurança para habilitar o acesso ao sistema de arquivos do computador local.
-EnableLocalFolderPathValidation		Habilite a validação de segurança para desabilitar o acesso ao sistema de arquivos do computador local.
-eesp, -EnableExecuteSsisPackage		Habilitar a execução do pacote SSIS no nó IR auto-hospedado.
-desp, -DisableExecuteSsisPackage		Desabilitar a execução do pacote SSIS no nó IR auto-hospedado.
-gesp, -GetExecuteSsisPackage		Obtenha o valor se a opção ExecuteSsisPackage estiver habilitada no nó IR auto-hospedado. Se o valor retornado for true, ExecuteSSISPackage estará habilitado; Se o valor retornado for false ou null, ExecuteSSISPackage estará desabilitado.

Instalar e registrar um IR auto-hospedado no Centro de Download da Microsoft

1. Acesse a página de downloads do Microsoft Integration Runtime.

2. Selecione Baixar, escolha a versão de 64 bits e selecione Avançar. Não há suporte para a versão de 32 bits.

3. Execute o arquivo MSI diretamente ou salve-o em seu disco rígido e execute-o.

4. Na janela Boas-vindas, escolha um idioma e selecione Avançar.

5. Aceite os Termos de Licença para Software Microsoft e selecione Avançar.

6. Selecione pasta para instalar o runtime de integração auto-hospedada e selecione Avançar.

7. Na página Pronto para instalar, selecione Instalar.

8. Selecione Concluir para finalizar a instalação.

9. Obtenha a chave de autenticação usando o PowerShell. Aqui há um exemplo do PowerShell para recuperar a chave de autenticação:

   Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
   

10. Na janela Registrar Integration Runtime (auto-hospedado) do Microsoft Integration Runtime Configuration Manager no computador, realize as seguintes etapas:

    1. Cole a chave de autenticação na área de texto.

    2. Opcionalmente, selecione Mostrar chave de autenticação para ver o texto da chave.

    3. Selecione Registrar.

Observação

As notas sobre a versão estão disponíveis na mesma página de download do Microsoft Integration Runtime.

Conta de serviço do runtime de integração auto-hospedada

A conta de serviço de logon padrão do runtime de integração auto-hospedada é NT SERVICE\DIAHostService. Você pode vê-la em Serviços -> Serviço do Integration Runtime -> Propriedades -> Logon.

Verifique se a conta tem a permissão de fazer logon como serviço. Caso contrário, o runtime de integração auto-hospedada não pode ser iniciado com sucesso. Você pode verificar a permissão em Política de segurança local -> Configurações de segurança -> Políticas locais -> Atribuição dos direitos do usuário -> Logon como serviço

Ícones e notificações da área de notificação

Se você mover o cursor sobre o ícone ou mensagem na área de notificação, poderá ver detalhes sobre o estado do runtime de integração auto-hospedada.

Alta disponibilidade e escalabilidade

Você pode associar um runtime de integração auto-hospedada a vários computadores locais ou máquinas virtuais no Azure. Esses computadores são chamados de nós. Você pode ter até quatro nós associados a um runtime de integração auto-hospedada. Os benefícios de ter vários nós nos computadores locais com um gateway instalado para um gateway lógico são:

• Disponibilidade superior do runtime de integração auto-hospedada para que ele não seja o único ponto de falha na sua solução de Big Data ou integração de dados de nuvem. Essa disponibilidade ajuda a garantir a continuidade quando você usa até quatro nós.
• Desempenho e taxa de transferência aprimorados durante a movimentação de dados entre os armazenamentos de dados de nuvem e locais. Obtenha mais informações sobre comparações de desempenho.

Para associar vários nós, instale o software do runtime de integração auto-hospedada no Centro de Download. A seguir, registre-o usando uma das chaves de autenticação obtidas do cmdlet New-AzDataFactoryV2IntegrationRuntimeKey, conforme descrito no tutorial.

Observação

Você não precisa criar um novo runtime de integração auto-hospedada para associar cada nó. Você pode instalar o runtime de integração auto-hospedada em outro computador e registrá-lo usando a mesma chave de autenticação.

Observação

Antes de adicionar outro nó para alta disponibilidade e escalabilidade, verifique se a opção Acesso remoto à intranet está habilitada no primeiro nó. Para fazer isso, selecione Microsoft Integration Runtime Configuration Manager>Configurações>Acesso remoto à intranet.

Considerações de escala

Escalar horizontalmente

Quando a utilização do processador for alta e houver pouca memória disponível no IR auto-hospedado, adicione um novo nó para ajudar a escalar horizontalmente a carga entre os computadores. Se as atividades falharem porque atingiram o tempo limite ou se o nó IR auto-hospedado estiver offline, é útil adicionar um nó ao gateway. Para adicionar um nó, conclua as seguintes etapas:

1. Baixe a configuração do SHIR no portal do Azure Data Factory.
2. Execute o Instalador no nó que você deseja adicionar ao cluster.
3. Durante a instalação, selecione a opção de ingressar em um runtime de integração existente e forneça a chave de autenticação do SHIR existente para vincular o novo nó ao cluster SHIR existente.

Escalar verticalmente

Quando o processador e a RAM disponível não são bem utilizados, mas a execução de trabalhos simultâneos atinge os limites de um nó, escale verticalmente aumentando o número de trabalhos simultâneos que um nó pode executar. Convém também escalar verticalmente quando as atividades atingirem o tempo limite porque o IR auto-hospedado está sobrecarregado. Conforme mostrado na imagem a seguir, você pode aumentar a capacidade máxima de um nó:

Requisitos de certificado TLS/SSL

Se você quiser habilitar o acesso remoto da intranet com o certificado TLS/SSL (Avançado) para proteger a comunicação entre nós de runtime de integração, siga as etapas em Habilitar o acesso remoto da intranet com o certificado TLS/SSL.

Observação

Esse certificado é usado:

• Para criptografar portas em um nó de IR auto-hospedado.
• Para a comunicação de um nó para outro para sincronização de estado, que inclui a sincronização de credenciais dos serviços vinculados entre os nós.
• Quando um cmdlet do PowerShell é usado para configurações de credencial de serviço vinculado de dentro de uma rede local.

Sugerimos usar esse certificado se o ambiente de rede privada não for seguro ou se você gostaria de proteger a comunicação entre os nós na rede privada também.

A movimentação de dados em trânsito do IR auto-hospedado para outros repositórios de dados sempre ocorre por meio de um canal criptografado, independentemente desse certificado estar definido ou não.

Sincronização de credenciais

Se você não armazenar as credenciais ou os valores secretos em um Azure Key Vault, eles serão armazenados nas máquinas em que se localiza o runtime de integração auto-hospedada. Cada nó terá uma cópia da credencial com determinada versão. Para fazer com que todos os nós funcionem juntos, o número de versão deve ser o mesmo para todos os nós.

Considerações do servidor proxy

Se o ambiente de rede corporativo usar um servidor proxy para acessar a Internet, configure o runtime de integração auto-hospedada para usar as definições de proxy apropriadas. Você pode definir o proxy durante a fase de registro inicial.

Quando configurado, o runtime de integração auto-hospedada usa o servidor proxy para se conectar à origem e ao destino do serviço de nuvem (que usam o protocolo HTTP ou HTTPS). Isso ocorre porque você seleciona Alterar link durante a configuração inicial.

Há três opções de configuração:

• Não usar proxy: o runtime de integração auto-hospedada não usa explicitamente qualquer proxy para se conectar aos serviços de nuvem.
• Usar proxy de sistema: o runtime de integração auto-hospedada usa a configuração de proxy definida em diahost.exe.config e diawp.exe.config. Se esses arquivos não especificarem uma configuração de proxy, o runtime de integração auto-hospedada se conectará ao serviço de nuvem diretamente, sem passar por um proxy.
• Usar proxy personalizado: configure a definição do proxy HTTP a ser usado pelo runtime de integração auto-hospedada, em vez de usar as configurações em diahost.exe.config e diawp.exe.config. Os valores de Endereço e Porta são necessários. Os valores Nome de Usuário e Senha são opcionais, dependendo da configuração de autenticação do proxy. Todas as configurações são criptografadas com a DPAPI do Windows no Integration Runtime auto-hospedado e armazenados localmente no computador.

O serviço de host do runtime de integração é reiniciado automaticamente depois que você salva as configurações de proxy atualizadas.

Após registrar o runtime de integração auto-hospedada, se você quiser exibir ou atualizar as configurações de proxy, use o Microsoft Integration Runtime Configuration Manager.

1. Abra o Configuration Manager do Microsoft Integration Runtime.
2. Selecione a guia Settings (Configurações).
3. Em Proxy HTTP, selecione o link Alterar para abrir a caixa de diálogo Definir proxy HTTP.
4. Selecione Avançar. Você verá um aviso solicitando sua permissão para salvar a configuração de proxy e reiniciar o serviço de host do runtime de integração.

É possível usar a ferramenta Configuration Manager para exibir e atualizar o proxy HTTP.

Observação

Se você configurar um servidor proxy com autenticação NTLM, o serviço de host do runtime de integração será executado sob a conta de domínio. Se você alterar a senha da conta de domínio posteriormente, lembre-se de atualizar as definições de configuração do serviço e de reiniciá-lo. Em virtude desse requisito, sugerimos que você acesse o servidor proxy usando uma conta de domínio dedicada que não exija a atualização frequente da senha.

Definir configurações do servidor proxy

Se você selecionar a opção Usar proxy de sistema para o proxy HTTP, o runtime de integração auto-hospedada usará as configurações de proxy em diahost.exe.config e diawp.exe.config. Quando esses arquivos não especificarem um proxy, o runtime de integração auto-hospedada se conectará ao serviço de nuvem diretamente, sem passar por um proxy. O procedimento a seguir fornece instruções para atualizar o arquivo diahost.exe.config:

1. No Explorador de Arquivos, faça uma cópia de segurança de C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como backup do arquivo original.

2. Abra o Notepad em execução como administrador.

3. No Notepad, abra o arquivo de texto C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Localize a marca padrão de system.net, conforme mostrado no código abaixo:

   <system.net>
       <defaultProxy useDefaultCredentials="true" />
   </system.net>
   

   Em seguida, você pode adicionar detalhes do servidor proxy, conforme mostrado no exemplo a seguir:

   <system.net>
       <defaultProxy enabled="true">
             <proxy bypassonlocal="true" proxyaddress="http://proxy.domain.org:8888/" />
       </defaultProxy>
   </system.net>
   

   A marca proxy permite que propriedades adicionais especifiquem as configurações necessárias, como scriptLocation. Confira <Elemento proxy> (Configurações de Rede) para encontrar a sintaxe.

   <proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>
   

5. Salve o arquivo de configuração no local original. Depois, reinicie o serviço de host de runtime da integração auto-hospedada, que assimila as alterações.

   Para reiniciar o serviço, use o applet de serviços no painel de controle. Ou, no Configuration Manager do Integration Runtime, selecione o botão Interromper serviço e, depois, selecione Iniciar serviço.

   Se o serviço não for iniciado, provavelmente você adicionou a sintaxe de marca XML incorreta no arquivo de configuração do aplicativo editado.

Importante

Não se esqueça de atualizar diahost.exe.config e diawp.exe.config.

Você também precisa verificar se o Microsoft Azure está na lista de permitidos de sua empresa. É possível baixar a lista de endereços IP válidos do Azure. Os intervalos de IP para cada nuvem, divididos por região e pelos serviços marcados nessa nuvem agora estão disponíveis no Download da MS:

• Público: https://www.microsoft.com/download/details.aspx?id=56519
• Gov (US): https://www.microsoft.com/download/details.aspx?id=57063
• Alemanha: https://www.microsoft.com/download/details.aspx?id=57064
• China: https://www.microsoft.com/download/details.aspx?id=57062

Definir as configurações do servidor proxy ao usar um ponto de extremidade privado

Se a arquitetura de rede da sua empresa envolver o uso de pontos de extremidade privados e, por motivos de segurança, a política da sua empresa não permitir uma conexão direta com a Internet da VM que hospeda o runtime de integração auto-hospedo para a URL do serviço Azure Data Factory, você precisará permitir ignorar a URL do Serviço ADF para conectividade total. O procedimento a seguir fornece instruções para atualizar o arquivo diahost.exe.config. Você também deve repetir essas etapas para o arquivo diawp.exe.config.

1. No Explorador de Arquivos, faça uma cópia segura de C:\Arquivos de Programas\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como um backup do arquivo original.

2. Abra o Notepad em execução como administrador.

3. No Bloco de notas, abra C:\Arquivos de Programas\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

4. Localize a marca padrão system.net, conforme mostrado aqui:

   <system.net>
       <defaultProxy useDefaultCredentials="true" />
   </system.net>
   

   Você pode então adicionar detalhes de bypasslist conforme mostrado no exemplo a seguir:

   <system.net>
     <defaultProxy>
         <bypasslist>
             <add address = "[adfresourcename].[adfresourcelocation].datafactory.azure.net" />
         </bypasslist>
         <proxy 
         usesystemdefault="True"
         proxyaddress="http://proxy.domain.org:8888/"
         bypassonlocal="True"
         />
     </defaultProxy>
   </system.net>
   

Possíveis sintomas de problemas relacionados ao firewall e ao servidor proxy

Se você observar mensagens de erro como as seguintes, a razão provável é a configuração incorreta do firewall ou do servidor proxy. Essa configuração impede que o runtime de integração auto-hospedada se conecte aos pipelines do Data Factory ou do Synapse para se autenticar. Para garantir que seu firewall e servidor proxy estejam configurados corretamente, confira a seção anterior.

• Quando você tenta registrar o runtime de integração auto-hospedada, recebe a seguinte mensagem de erro: "Falha ao registrar esse nó do runtime de integração. Confirme se a chave de autenticação é válida e o serviço de host de serviço de integração está em execução neste computador".

• Ao abrir o Configuration Manager do Integration Runtime, você vê o status Desconectado ou Conectando. Ao exibir os logs de eventos do Windows, em Visualizador de Eventos>Logs de aplicativos e serviços>Microsoft Integration Runtime, você vê mensagens de erro como esta:

  Unable to connect to the remote server
  A component of Integration Runtime has become unresponsive and restarts automatically. Component name: Integration Runtime (self-hosted).
  

Habilitar acesso remoto pela intranet

Se você usar o PowerShell para criptografar as credenciais de um computador na rede, diferente daquele em que você instalou o runtime de integração auto-hospedada, poderá habilitar a opção Acesso remoto pela intranet. Se você executar o PowerShell para criptografar as credenciais no computador em que você instalou o runtime de integração auto-hospedada, não poderá habilitar o Acesso remoto pela intranet.

Habilite a opção Acesso remoto pela intranet antes de adicionar outro nó para alta disponibilidade e escalabilidade.

Quando você executa a configuração do runtime de integração auto-hospedada versão 3.3 ou posterior, por padrão, o instalador do runtime de integração auto-hospedada desabilita o Acesso remoto pela intranet no computador do runtime de integração auto-hospedada.

Ao usar um firewall de um parceiro ou de terceiros, você pode abrir manualmente a porta 8060 ou a porta configurada pelo usuário. Se tiver um problema de firewall durante a configuração do runtime de integração auto-hospedada, use o comando a seguir para instalar o runtime de integração auto-hospedada sem configurar o firewall:

msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1

Se optar por não abrir a porta 8060 no computador do runtime de integração auto-hospedada, use mecanismos diferentes do aplicativo Definindo Credenciais para configurar as credenciais do armazenamento de dados. Por exemplo, você pode usar o cmdlet do PowerShell New-AzDataFactoryV2LinkedServiceEncryptCredential.

Portas e Firewalls

Existem dois firewalls a serem levados em consideração:

• O firewall corporativo executado no roteador central da organização
• O firewall do Windows que é configurado como daemon no computador local em que o runtime de integração auto-hospedada foi instalado

No nível do firewall corporativo, é necessário configurar os seguintes domínios e portas de saída:

Nomes de domínios	Portas de saída	Descrição
Nuvem pública: *.servicebus.windows.net Azure Governamental: *.servicebus.usgovcloudapi.net China: *.servicebus.chinacloudapi.cn	443	Exigido pelo runtime de integração auto-hospedada para criação interativa. Não será necessário se a criação interativa autocontida estiver habilitada.
Nuvem pública: {datafactory}.{region}.datafactory.azure.net ou *.frontend.clouddatahub.net Azure Governamental: {datafactory}.{region}.datafactory.azure.us China: {datafactory}.{region}.datafactory.azure.cn	443	Necessárias para que o runtime de integração auto-hospedada se conecte ao serviço do Data Factory. Para um Data Factory recém-criado em nuvem pública, localize o FQDN (nome de domínio totalmente qualificado) na sua chave do runtime de integração auto-hospedada, que está no formato {datafactory}.{região}.datafactory.azure.net. Para o Data Factory antigo e qualquer versão do Azure Synapse Analytics, se você não vir o FQDN na chave de integração auto-hospedada, use *.frontend.clouddatahub.net.
download.microsoft.com	443	Exigido pelo runtime de integração auto-hospedada para fazer o download das atualizações. Se você desabilitar a atualização automática, poderá ignorar a configuração desse domínio.
URL do cofre da chave	443	Exigido pelo Azure Key Vault se você armazena a credencial no Key Vault.

No nível do Firewall do Windows ou no nível do computador, essas portas de saída normalmente estão habilitadas. Caso contrário, você poderá configurar as portas e os domínios em um computador com runtime de integração auto-hospedada.

Observação

Como a Retransmissão do Azure não dá suporte à marca de serviço no momento, você precisa usar a marca de serviço AzureCloud ou Internet nas regras de NSG para a comunicação com a Retransmissão do Azure. Para a comunicação com os workspaces do Azure Data Factory ou do Synapse, você pode usar a marca de serviço DataFactoryManagement na configuração da regra de NSG.

Com base na origem e nos coletores, pode ser conveniente permitir domínios adicionais e portas de saída no firewall corporativo ou no Firewall do Windows.

Nomes de domínios	Portas de saída	Descrição
*.core.windows.net	443	Usada pelo runtime de integração auto-hospedada para se conectar à conta de armazenamento do Azure ao usar o recurso cópia em etapas.
*.database.windows.net	1433	Obrigatório somente quando você copia do Banco de Dados SQL do Azure ou do Azure Synapse Analytics ou para ambos; caso contrário, opcional. Use o recurso de cópia em etapas para copiar dados para o Banco de Dados SQL ou para o Azure Synapse Analytics sem abrir a porta 1433.
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token	443	Obrigatório somente quando você copia do Azure Data Lake Storage ou para ele; caso contrário, opcional.

Para alguns bancos de dados na nuvem, como Banco de Dados SQL do Azure e Azure Data Lake, talvez seja necessário incluir os endereços IP do computador do runtime de integração auto-hospedada na lista de permissões na configuração do firewall deles.

Observação

Não é correto instalar o Integration Runtime e o gateway do Power BI no mesmo computador, pois principalmente o Integration Runtime usa a porta número 443, que também é uma das portas principais que estão sendo usadas pelo gateway do Power BI.

Criação interativa autocontida (versão prévia)

Para executar ações interativas de criação, como visualização de dados e teste de conexão, o runtime de integração auto-hospedada requer uma conexão com a Retransmissão do Azure. Se a conexão não for estabelecida, haverá duas soluções possíveis para garantir a funcionalidade ininterrupta. A primeira opção é adicionar os pontos de extremidade da Retransmissão do Azure à lista de permissões do firewall Obter URL da Retransmissão do Azure. Como alternativa, você pode habilitar a criação interativa autocontida.

Observação

Se o runtime de integração auto-hospedada não estabelecer uma conexão com a Retransmissão do Azure, seu status será marcado como "limitado".

Observação

Embora a criação interativa autocontida esteja habilitada, todo o tráfego de criação interativa será roteado exclusivamente por meio dessa funcionalidade, ignorando a Retransmissão do Azure. O tráfego só será redirecionado de volta para a Retransmissão do Azure depois que você optar por desabilitar esse recurso.

Observação

Não há suporte para "Obter IP" e "Enviar log" quando a criação interativa autossuficiente está habilitada.

Obter URL da Retransmissão do Azure

É necessário colocar um domínio e uma porta na lista de permitidos do firewall para a comunicação com a Retransmissão do Azure. O runtime de integração auto-hospedada o utiliza para criação interativa, como conexão de teste, pesquisa de lista de pastas e lista de tabelas, obtenção de esquema e visualização de dados. Se você não quiser permitir .servicebus.windows.net e gostaria de ter URLs mais específicas, pode ver todos os FQDNs exigidos pelo runtime de integração auto-hospedada no portal do serviço. Siga estas etapas:

1. Acesse o portal do serviço e selecione o runtime de integração auto-hospedada.

2. Na página Editar, selecione Nós.

3. Selecione Exibir URLs de serviço para obter todos os FQDNs.

   

4. Você pode adicionar esses FQDNs na lista de permitidos das regras de firewall.

Observação

Para obter os detalhes relacionados ao protocolo de conexões de retransmissão do Azure, confira o protocolo de Conexões Híbridas de Retransmissão do Azure.

Copiar dados de uma origem para um coletor

Verifique se você habilitou corretamente as regras de firewall no firewall corporativo, no Firewall do Windows no computador do runtime de integração auto-hospedada e no próprio repositório de dados. Habilitar essas regras permite que o runtime de integração auto-hospedada seja conectado com sucesso à origem e ao coletor. Habilite as regras para cada repositório de dados que esteja envolvido na operação de cópia.

Por exemplo, para copiar de um repositório de dados local para um coletor do Banco de Dados SQL ou um coletor do Azure Synapse Analytics, siga as etapas abaixo:

1. Permita a comunicação TCP de saída na porta 1433 para o Firewall do Windows e o firewall corporativo.
2. Configurar as definições de firewall do Banco de Dados SQL para adicionar o endereço IP do computador do runtime de integração auto-hospedada à lista de endereços IP permitidos.

Observação

Se o firewall não permitir a porta de saída 1433, o runtime de integração auto-hospedada não poderá acessar diretamente o Banco de Dados SQL. Nesse caso, você pode usar uma cópia de preparo para o Banco de Dados SQL e o Azure Synapse Analytics. Neste cenário, você precisa apenas de HTTPS (porta 443) para a movimentação de dados.

Se toda a fonte de dados, o coletor e o runtime de integração auto-hospedada estiverem no ambiente local, os dados copiados não irão para a nuvem, mas permanecerão estritamente dentro do local.

Armazenamento de credenciais

Há duas maneiras de armazenar as credenciais ao usar o tempo de execução de integração auto-hospedado:

1. Usar o Azure Key Vault.

Essa é a maneira recomendada para armazenar suas credenciais no Azure. O runtime de integração auto-hospedada pode obter diretamente as credenciais de Azure Key Vault, o que pode evitar problemas de segurança em potencial ou quaisquer problemas sincronização de credenciais entre os nós de runtime de integração auto-hospedada. 2. Armazene credenciais localmente.

As credenciais serão efetuadas por push para o computador do runtime de integração auto-hospedada e ser criptografadas. Quando o runtime de integração auto-hospedada é recuperado da falha, você pode recuperar a credencial de uma que você faz backup antes ou editar o serviço vinculado e permitir que a credencial seja enviada por push para o runtime de integração auto-hospedada novamente. Caso contrário, o pipeline não funcionará devido à falta de credencial ao ser executado por meio do runtime de integração auto-hospedada.

Observação

Se você preferir armazenar a credencial localmente, precisará colocar o domínio para criação interativa na lista de permitidos do firewall e abrir a porta. Esse canal também é para o runtime de integração auto-hospedada para obter as credenciais. Para o domínio e a porta necessários para a criação interativa, consulte Portas e firewalls

Melhores práticas de instalação

É possível instalar o runtime de integração auto-hospedada baixando um pacote de instalação de Identidade Gerenciada no Centro de Download da Microsoft. Confira o artigo Migrar dados entre o local e a nuvem para obter as instruções passo a passo.

• Configure um plano de energia no computador host para o runtime de integração auto-hospedada para que o computador não hiberne. Se o computador host hibernar, o runtime de integração auto-hospedada ficará offline.
• Faça backup regulares das credenciais associadas ao runtime de integração auto-hospedada.
• Para automatizar as operações de configuração do IR auto-hospedado, confira Configurar um IR auto-hospedado existente por meio do PowerShell.

Considerações importantes

Ao instalar um runtime de integração auto-hospedada, considere o seguinte

• Mantenha-o próximo à fonte de dados, mas não necessariamente no mesmo computador
• Não instale-o no mesmo computador que o gateway do Power BI
• Somente Windows Server (servidores de criptografia compatíveis com FIPS podem causar falha nos trabalhos)
• Compartilhe entre várias fontes de dados
• Compartilhe entre vários data factories

Conteúdo relacionado

Para obter as instruções passo a passo, confira Tutorial: copiar dados locais para a nuvem.