Create and configure a self-hosted integration runtime (Criar e configurar um runtime de integração autoalojado)
APLICA-SE A: Azure Data Factory Azure Synapse Analytics
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
O tempo de execução de integração (IR) é a infraestrutura de computação que o Azure Data Factory e os pipelines Synapse usam para fornecer recursos de integração de dados em diferentes ambientes de rede. Para obter detalhes sobre RI, consulte Visão geral do tempo de execução da integração.
Um runtime de integração autoalojado pode executar atividades de cópia entre um arquivo de dados da cloud e um arquivo de dados numa rede privada. Também pode distribuir atividades de transformação em relação aos recursos de computação numa rede no local ou numa rede virtual do Azure. A instalação de um runtime de integração autoalojado tem de ser num computador no local ou numa máquina virtual que esteja numa rede privada.
Este artigo descreve como você pode criar e configurar um IR auto-hospedado.
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Considerações sobre o uso de um RI auto-hospedado
- Você pode usar um único tempo de execução de integração auto-hospedado para várias fontes de dados locais. Você também pode compartilhá-lo com outro data factory dentro do mesmo locatário do Microsoft Entra. Para obter mais informações, consulte Compartilhando um tempo de execução de integração auto-hospedado.
- Só pode instalar uma instância de um runtime de integração autoalojado num computador. Se você tiver duas fábricas de dados 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 espaço de trabalho Synapse. O espaço de trabalho Synapse não suporta o Integration Runtime Sharing.
- O tempo de execução de integração auto-hospedado não precisa estar na mesma máquina que a fonte de dados. No entanto, ter o tempo de execução de integração auto-hospedado perto da fonte de dados reduz o tempo de tempo para o tempo de execução de integração auto-hospedado se conectar à fonte de dados. Recomendamos que você instale o tempo de execução de integração auto-hospedado em uma máquina diferente daquela que hospeda a fonte de dados local. Quando o tempo de execução de integração auto-hospedado e a fonte de dados estão em máquinas diferentes, o tempo de execução de integração auto-hospedado não compete com a fonte de dados por recursos.
- Você pode ter vários tempos de execução de integração auto-hospedados em máquinas diferentes que se conectam à mesma fonte de dados local. Por exemplo, se você tiver dois tempos de execução de integração auto-hospedados que servem duas fábricas de dados, a mesma fonte de dados local pode ser registrada com ambas as fábricas de dados.
- Use um tempo de execução de integração auto-hospedado para dar suporte à integração de dados em uma rede virtual do Azure.
- Trate sua fonte de dados como uma fonte de dados local que está atrás de um firewall, mesmo quando você usa a Rota Expressa do Azure. Use o tempo de execução de integração auto-hospedado para conectar o serviço à fonte de dados.
- Use o tempo de execução de integração auto-hospedado mesmo que o armazenamento de dados esteja na nuvem em uma máquina virtual IaaS (Infraestrutura como Serviço) do Azure.
- As tarefas podem falhar em um tempo de execução de integração auto-hospedado que você instalou em um servidor Windows para o qual a criptografia compatível com FIPS está habilitada. Para contornar esse problema, você tem duas opções: armazenar credenciais/valores secretos em um Cofre de Chaves do Azure ou desabilitar a criptografia compatível com FIPS no servidor. Para desativar a criptografia compatível com FIPS, altere o valor da seguinte subchave do Registro de 1 (habilitado) para 0 (desabilitado):
HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled
. Se você usar o tempo de execução de integração auto-hospedado como um proxy para o tempo de execução de integração do SSIS, a criptografia compatível com FIPS poderá ser habilitada e será usada ao mover dados do local para o Armazenamento de Blobs do Azure como uma área de preparação. - Os detalhes completos do licenciamento são fornecidos na primeira página da configuração do tempo de execução de integração auto-hospedada.
Nota
Atualmente, o tempo de execução de integração auto-hospedado só pode ser compartilhado com várias fábricas de dados, não pode ser compartilhado entre espaços de trabalho Synapse ou entre data factory e espaço de trabalho Synapse.
Fluxo de comandos e fluxo de dados
Quando você move dados entre o local e a nuvem, a atividade usa um tempo de execução de integração auto-hospedado para transferir os dados entre uma fonte de dados local e a nuvem.
Aqui está um resumo de alto nível das etapas de fluxo de dados para copiar com um IR auto-hospedado:
Um desenvolvedor de dados primeiro cria um tempo de execução de integração auto-hospedado em uma fábrica de dados do Azure ou espaço de trabalho Synapse usando o portal do Azure ou o cmdlet do PowerShell. Em seguida, o desenvolvedor de dados cria um serviço vinculado para um armazenamento de dados local, especificando a instância de tempo de execução de integração auto-hospedada que o serviço deve usar para se conectar a armazenamentos de dados.
O nó de tempo de execução de integração auto-hospedado criptografa as credenciais usando a DPAPI (Interface de Programação de Aplicativos 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 ainda mais sincronizadas entre outros nós. Cada nó criptografa as credenciais usando DPAPI e as armazena localmente. A sincronização de credenciais é transparente para o desenvolvedor de dados e é tratada pelo IR auto-hospedado.
Os pipelines do Azure Data Factory e Synapse se comunicam com o tempo de execução de integração auto-hospedado para agendar e gerenciar trabalhos. A comunicação é feita por meio de um canal de controle que usa uma conexão compartilhada do Azure Relay . Quando um trabalho de atividade precisa ser executado, o serviço enfileira a solicitação junto com qualquer informação de credencial. Ele faz isso caso as credenciais ainda não estejam armazenadas no tempo de execução de integração auto-hospedado. O tempo de execução de integração auto-hospedado inicia o trabalho depois de sondar a fila.
O tempo de execução de integração auto-hospedado copia dados entre um armazenamento local e o armazenamento em nuvem. A direção da cópia depende de como a atividade de cópia é configurada no pipeline de dados. Nesta etapa, o tempo de execução de integração auto-hospedado se comunica diretamente com serviços de armazenamento baseados em nuvem, como o armazenamento de Blob do Azure, em um canal HTTPS seguro.
Pré-requisitos
- As versões suportadas do Windows são:
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
Não há suporte para a instalação do tempo de execução de integração auto-hospedado em um controlador de domínio.
- O tempo de execução de integração auto-hospedado requer um sistema operacional de 64 bits com .NET Framework 4.7.2 ou superior. Consulte Requisitos de sistema do .NET Framework para obter detalhes.
- A configuração mínima recomendada para a máquina de tempo de execução 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 os detalhes dos requisitos do sistema, consulte Download.
- Se a máquina host hibernar, o tempo de execução de integração auto-hospedado não responderá às solicitações de dados. Configure um plano de energia apropriado no computador antes de instalar o tempo de execução de integração auto-hospedado. Se a máquina estiver configurada para hibernar, o instalador do tempo de execução de integração auto-hospedado solicitará uma mensagem.
- Você deve ser um administrador na máquina para instalar e configurar com êxito o tempo de execução de integração auto-hospedado.
- As execuções de atividade de cópia acontecem com uma frequência específica. O uso do processador e da RAM na máquina segue o mesmo padrão com os tempos de pico e ocioso. O uso de recursos também depende muito da quantidade de dados que são movidos. Quando vários trabalhos de cópia estão em andamento, você vê o uso de recursos aumentar durante os horários de pico.
- As tarefas podem falhar durante a extração de dados nos formatos Parquet, ORC ou Avro. Para obter mais informações sobre Parquet, consulte Formato Parquet no Azure Data Factory. A criação de arquivos é executada na máquina de integração auto-hospedada. Para funcionar conforme o esperado, a criação de arquivos requer 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 (não apenas a pasta JRE), você também pode precisar adicionar a pasta bin à variável de ambiente PATH do seu sistema.
Nota
Pode ser necessário ajustar as configurações do Java se ocorrerem erros de memória, conforme descrito na documentação do formato Parquet.
Nota
Se você estiver executando na nuvem do governo, consulte Conectar-se à nuvem do governo.
Configurando um tempo de execução de integração auto-hospedado
Para criar e configurar um tempo de execução de integração auto-hospedado, use os procedimentos a seguir.
Criar um IR auto-hospedado por meio do Azure PowerShell
Você pode usar o Azure PowerShell para essa tarefa. Segue-se um exemplo:
Set-AzDataFactoryV2IntegrationRuntime -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName -Type SelfHosted -Description "selfhosted IR description"
Baixe e instale o tempo de execução de integração auto-hospedado em uma máquina local.
Recupere a chave de autenticação e registre o tempo de execução de integração auto-hospedado com a chave. Aqui está um exemplo do PowerShell:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
Nota
Execute o comando PowerShell no governo do Azure, consulte Conectar-se ao Azure Government com o PowerShell.
Criar um IR auto-hospedado via UI
Use as etapas a seguir para criar um IR auto-hospedado usando o Azure Data Factory ou a interface do usuário do Azure Synapse.
Na home page da interface do usuário do Azure Data Factory, selecione a guia Gerenciar no painel mais à esquerda.
Selecione Tempos de execução de integração no painel esquerdo e, em seguida, selecione +Novo.
Na página Configuração do tempo de execução da integração, selecione Azure, Auto-Hospedado e selecione Continuar.
Na página seguinte, selecione Auto-Hospedado para criar um IR Auto-Hospedado e, em seguida, selecione Continuar.
Configurar um IR auto-hospedado via interface do usuário
Insira um nome para seu RI e selecione Criar.
Na página Configuração do tempo de execução da integração, selecione o link em Opção 1 para abrir a configuração expressa no seu computador. Ou siga as etapas na Opção 2 para configurar manualmente. As instruções a seguir são baseadas na configuração manual:
Copie e cole a chave de autenticação. Selecione Baixar e instalar o tempo de execução da integração.
Transfira o integration runtime autoalojado num computador windows local. Execute o instalador.
Na página Register Integration Runtime (Self-hosted), cole a chave salva anteriormente e selecione Registrar.
Na página Novo Nó de Tempo de Execução de Integração (Auto-hospedado), selecione Concluir.
Depois que o tempo de execução de integração auto-hospedado for registrado com êxito, você verá a seguinte janela:
Configurar um IR auto-hospedado em uma VM do Azure por meio de um modelo do Azure Resource Manager
Você pode automatizar a configuração de IR auto-hospedada em uma máquina virtual do Azure usando o modelo Criar IR de host próprio. O modelo fornece uma maneira fácil de ter um IR auto-hospedado totalmente funcional dentro de uma rede virtual do Azure. O IR tem recursos de alta disponibilidade e escalabilidade, desde que você defina a contagem de nós como 2 ou superior.
Configurar um RI auto-hospedado existente por meio do 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 IR auto-hospedados.
Dmgcmd.exe está incluído no instalador auto-hospedado. Normalmente está localizado na pasta C:\Program Files\Microsoft Integration Runtime\5.0\Shared\. Esta aplicação suporta vários parâmetros e pode ser invocada através de uma linha de comando usando scripts em lote para automação.
Use o aplicativo da seguinte maneira:
dmgcmd ACTION args...
Aqui estão os detalhes das ações e argumentos do aplicativo:
AÇÃO | args | Description |
---|---|---|
-rn ,-RegisterNewNode |
"<AuthenticationKey> " ["<NodeName> "] |
Registre um nó de tempo de execução de integração auto-hospedado 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 a configuração de credenciais diretamente no IR auto-hospedado sem passar por um espaço de trabalho do Azure Data Factory ou do Azure Synapse. Você faz isso usando o cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential de uma máquina remota na mesma rede. |
-erac ,-EnableRemoteAccessInContainer |
"<port> " ["<thumbprint> "] |
Habilite o acesso remoto ao nó atual quando o nó for executado em um contêiner. |
-dra ,-DisableRemoteAccess |
Desative o acesso remoto ao nó atual. O acesso remoto é necessário para a configuração de vários nós. O cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential PowerShell ainda funciona mesmo quando o acesso remoto está desabilitado. Esse comportamento é verdadeiro desde que o cmdlet seja executado na mesma máquina que o nó IR auto-hospedado. | |
-k ,-Key |
"<AuthenticationKey> " |
Substitua ou atualize a chave de autenticação anterior. Tenha cuidado com esta ação. Seu nó IR auto-hospedado anterior pode ficar offline se a chave for de um novo tempo de execução de integração. |
-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 armazenamento de dados. |
-ibf ,-ImportBackupFile |
"<filePath> " "<password> " |
Restaure o nó a partir de um arquivo de backup. |
-r ,-Restart |
Reinicie o serviço de host de tempo de execução de integração auto-hospedado. | |
-s ,-Start |
Inicie o serviço de host de tempo de execução de integração auto-hospedado. | |
-t ,-Stop |
Pare o serviço de host de tempo de execução de integração auto-hospedado. | |
-sus ,-StartUpgradeService |
Inicie o serviço de atualização de tempo de execução de integração auto-hospedado. | |
-tus ,-StopUpgradeService |
Pare o serviço de atualização de tempo de execução de integração auto-hospedado. | |
-tonau ,-TurnOnAutoUpdate |
Ative a atualização automática do tempo de execução da integração auto-hospedada. Este comando é apenas para o Azure Data Factory V1. | |
-toffau ,-TurnOffAutoUpdate |
Desative a atualização automática do tempo de execução da integração auto-hospedada. Este comando é apenas para o Azure Data Factory V1. | |
-ssa ,-SwitchServiceAccount |
"<domain\user> " ["<password> "] |
Defina DIAHostService para ser executado como uma nova conta. Use a senha vazia "" para contas do sistema e contas virtuais. |
-elma ,-EnableLocalMachineAccess |
Habilite o acesso à máquina local (localhost, IP privado) no nó IR auto-hospedado atual. No cenário de Alta Disponibilidade de IR auto-hospedado, a ação precisa ser invocada em cada nó de IR auto-hospedado. | |
-dlma ,-DisableLocalMachineAccess |
Desative o acesso à máquina local (localhost, IP privado) no nó IR auto-hospedado atual. No cenário de Alta Disponibilidade de IR auto-hospedado, a ação precisa ser invocada em cada nó de IR auto-hospedado. | |
-DisableLocalFolderPathValidation |
Desative a validação de segurança para habilitar o acesso ao sistema de arquivos da máquina local. | |
-EnableLocalFolderPathValidation |
Habilite a validação de segurança para desabilitar o acesso ao sistema de arquivos da máquina local. | |
-eesp ,-EnableExecuteSsisPackage |
Habilite a execução do pacote SSIS no nó IR auto-hospedado. | |
-desp ,-DisableExecuteSsisPackage |
Desative 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 será habilitado; Se o valor retornado for false ou null, ExecuteSSISPackage será desabilitado. |
Instalar e registrar um RI auto-hospedado do Centro de Download da Microsoft
Vá para a página de download do tempo de execução de integração da Microsoft.
Selecione Download, selecione a versão de 64 bits e selecione Avançar. A versão de 32 bits não é suportada.
Execute o arquivo MSI diretamente ou salve-o em seu disco rígido e execute-o.
Na janela Bem-vindo, selecione um idioma e selecione Avançar.
Aceite os Termos de Licença para Software Microsoft e selecione Avançar.
Selecione a pasta para instalar o tempo de execução de integração auto-hospedado e selecione Avançar.
Na página Pronto para instalar, selecione Instalar.
Selecione Concluir para concluir a instalação.
Obtenha a chave de autenticação usando o PowerShell. Aqui está um exemplo do PowerShell para recuperar a chave de autenticação:
Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntimeName
Na janela Register Integration Runtime (Self-hosted) do Microsoft Integration Runtime Configuration Manager em execução no seu computador, execute as seguintes etapas:
Cole a chave de autenticação na área de texto.
Opcionalmente, selecione Mostrar chave de autenticação para ver o texto da chave.
Selecione Registar.
Nota
As Notas de Versão estão disponíveis na mesma página de download do tempo de execução de integração da Microsoft.
Conta de serviço para tempo de execução de integração auto-hospedado
A conta de serviço de logon padrão do tempo de execução de integração auto-hospedado é NT SERVICE\DIAHostService. Você pode vê-lo em Serviços -> Integration Runtime Service -> Properties -> Log on.
Verifique se a conta tem a permissão de Fazer logon como um serviço. Caso contrário, o tempo de execução de integração auto-hospedado não poderá ser iniciado com êxito. Você pode verificar a permissão em Política de Segurança Local -> Configurações de Segurança -> Políticas Locais -> Atribuição de Direitos de Usuário -> Fazer logon como um serviço
Ícones e notificações da área de notificação
Se você mover o cursor sobre o ícone ou a mensagem na área de notificação, poderá ver detalhes sobre o estado do tempo de execução de integração auto-hospedado.
Alta disponibilidade e escalabilidade
Você pode associar um tempo de execução de integração auto-hospedado a várias máquinas locais ou máquinas virtuais no Azure. Essas máquinas são chamadas de nós. Você pode ter até quatro nós associados a um tempo de execução de integração auto-hospedado. Os benefícios de ter vários nós em máquinas locais que têm um gateway instalado para um gateway lógico são:
- Maior disponibilidade do tempo de execução de integração auto-hospedado para que ele não seja mais o único ponto de falha em sua solução de big data ou integração de dados em nuvem. Essa disponibilidade ajuda a garantir a continuidade quando você usa até quatro nós.
- Melhor desempenho e taxa de transferência durante a movimentação de dados entre armazenamentos de dados locais e na nuvem. Obtenha mais informações sobre comparações de desempenho.
Você pode associar vários nós instalando o software de tempo de execução de integração auto-hospedado do Centro de Download. Em seguida, registre-o usando uma das chaves de autenticação obtidas do cmdlet New-AzDataFactoryV2IntegrationRuntimeKey , conforme descrito no tutorial.
Nota
Você não precisa criar um novo tempo de execução de integração auto-hospedado para associar cada nó. Você pode instalar o tempo de execução de integração auto-hospedado em outra máquina e registrá-lo usando a mesma chave de autenticação.
Nota
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>Settings>Acesso remoto à intranet.
Considerações de escala
Aumentar horizontalmente
Quando o uso do processador for alto e a memória disponível estiver baixa no IR auto-hospedado, adicione um novo nó para ajudar a dimensionar a carga entre as máquinas. Se as atividades falharem porque atingem o tempo limite ou o nó IR auto-hospedado estiver offline, isso ajudará se você adicionar um nó ao gateway. Para adicionar um nó, conclua as seguintes etapas:
- Baixe a configuração do SHIR no portal do Azure Data Factory.
- Execute o instalador no nó que você deseja adicionar ao cluster.
- Durante a instalação, selecione a opção para ingressar em um tempo de execução de integração existente e forneça a chave de autenticação do SHIR existente para vincular o novo nó ao cluster SHIR existente.
Aumentar 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ó, aumente a escala aumentando o número de trabalhos simultâneos que um nó pode executar. Você também pode querer aumentar a escala quando as atividades expirarem porque o IR auto-hospedado está sobrecarregado. Conforme mostrado na imagem a seguir, você pode aumentar a capacidade máxima de um nó:
Requisitos do certificado TLS/SSL
Se desejar habilitar o acesso remoto da intranet com certificado TLS/SSL (Avançado) para proteger a comunicação entre nós de tempo de execução de integração, siga as etapas em Habilitar acesso remoto da intranet com certificado TLS/SSL.
Nota
Este certificado é utilizado:
- Para criptografar portas em um nó de IR auto-hospedado.
- Para comunicação nó-a-nó para sincronização de estado, que inclui a sincronização de credenciais de serviços vinculados entre nós.
- Quando um cmdlet do PowerShell é usado para configurações de credenciais de serviço vinculado de dentro de uma rede local.
Sugerimos que utilize este certificado se o seu ambiente de rede privada não for seguro ou se pretender proteger a comunicação entre nós na sua rede privada.
A movimentação de dados em trânsito de um IR auto-hospedado para outros armazenamentos de dados sempre acontece dentro de um canal criptografado, independentemente de esse certificado estar definido ou não.
Sincronização de credenciais
Se você não armazenar credenciais ou valores secretos em um Cofre de Chaves do Azure, as credenciais ou valores secretos serão armazenados nas máquinas onde seu tempo de execução de integração auto-hospedado localiza. Cada nó terá uma cópia da credencial com determinada versão. Para fazer com que todos os nós trabalhem juntos, o número da versão deve ser o mesmo para todos os nós.
Considerações do servidor proxy
Se seu ambiente de rede corporativa usa um servidor proxy para acessar a Internet, configure o tempo de execução de integração auto-hospedado para usar as configurações de proxy apropriadas. Você pode definir o proxy durante a fase inicial de registro.
Quando configurado, o tempo de execução de integração auto-hospedado usa o servidor proxy para se conectar à origem e ao destino do serviço de nuvem (que usam o protocolo HTTP ou HTTPS). É por isso que você seleciona Alterar link durante a configuração inicial.
Existem três opções de configuração:
- Não use proxy: o tempo de execução de integração auto-hospedado não usa explicitamente nenhum proxy para se conectar a serviços de nuvem.
- Usar proxy do sistema: o tempo de execução de integração auto-hospedado usa a configuração de proxy definida em diahost.exe.config e diawp.exe.config. Se esses arquivos não especificarem nenhuma configuração de proxy, o tempo de execução de integração auto-hospedado se conectará ao serviço de nuvem diretamente sem passar por um proxy.
- Usar proxy personalizado: configure a configuração de proxy HTTP para usar no tempo de execução de integração auto-hospedado, em vez de usar configurações em diahost.exe.config e diawp.exe.config. Os valores Endereço e Porta são obrigatórios. Os valores de 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 DPAPI do Windows no tempo de execução de integração auto-hospedado e armazenadas localmente na máquina.
O serviço de host de tempo de execução de integração é reiniciado automaticamente depois que você salva as configurações de proxy atualizadas.
Depois de registrar o tempo de execução de integração auto-hospedado, se você quiser exibir ou atualizar as configurações de proxy, use o Microsoft Integration Runtime Configuration Manager.
- Abra o Microsoft Integration Runtime Configuration Manager.
- Selecione o separador Definições.
- Em Proxy HTTP, selecione o link Alterar para abrir a caixa de diálogo Definir Proxy HTTP .
- Selecione Seguinte. Em seguida, você verá um aviso que solicita sua permissão para salvar a configuração de proxy e reiniciar o serviço de host de tempo de execução de integração.
Você pode usar a ferramenta do gerenciador de configurações para exibir e atualizar o proxy HTTP.
Nota
Se você configurar um servidor proxy com autenticação NTLM, o serviço de host de tempo de execução de integração será executado na conta de domínio. Se, posteriormente, alterar a palavra-passe da conta de domínio, lembre-se de atualizar as definições de configuração para o serviço e reiniciar o serviço. Devido a esse requisito, sugerimos que você acesse o servidor proxy usando uma conta de domínio dedicada que não exija que você atualize a senha com frequência.
Definir configurações do servidor proxy
Se você selecionar a opção Usar proxy do sistema para o proxy HTTP, o tempo de execução de integração auto-hospedado usará as configurações de proxy em diahost.exe.config e diawp.exe.config. Quando esses arquivos não especificam nenhum proxy, o tempo de execução de integração auto-hospedado se conecta 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:
No Explorador de Ficheiros, faça uma cópia segura de C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como cópia de segurança do ficheiro original.
Abra o Bloco de Notas em execução como administrador.
No bloco de notas, abra o arquivo de texto C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Encontre a tag system.net padrão, conforme mostrado no código a seguir:
<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 tag proxy permite que propriedades adicionais especifiquem as configurações necessárias, como
scriptLocation
. Consulte <Elemento proxy> (Configurações de Rede) para obter a sintaxe.<proxy autoDetect="true|false|unspecified" bypassonlocal="true|false|unspecified" proxyaddress="uriString" scriptLocation="uriString" usesystemdefault="true|false|unspecified "/>
Salve o arquivo de configuração em seu local original. Em seguida, reinicie o serviço de host de tempo de execução de integração auto-hospedado, que seleciona as alterações.
Para reiniciar o serviço, use o miniaplicativo de serviços no Painel de Controle. Ou no Integration Runtime Configuration Manager, selecione o botão Parar Serviço e, em seguida, selecione Iniciar Serviço.
Se o serviço não iniciar, você provavelmente adicionou sintaxe de marca XML incorreta no arquivo de configuração do aplicativo que editou.
Importante
Não se esqueça de atualizar diahost.exe.config e diawp.exe.config.
Você também precisa se certificar de que o Microsoft Azure está na lista de permissões da sua empresa. Você pode 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 MS Download:
- Público: https://www.microsoft.com/download/details.aspx?id=56519
- Gov dos EUA: 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 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, e a política da sua empresa não permitir uma conexão direta com a Internet da VM que hospeda o Self Hosted Integration Runtime para a URL de serviço do 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.
No Explorador de Ficheiros, faça uma cópia segura de C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config como cópia de segurança do ficheiro original.
Abra o Bloco de Notas em execução como administrador.
No Bloco de Notas, abra C:\Program Files\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.
Encontre a tag system.net padrão, conforme mostrado aqui:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>
Em seguida, você pode adicionar detalhes da lista de desvios, 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 para problemas relacionados ao firewall e ao servidor proxy
Se você vir mensagens de erro como as seguintes, o motivo provável é a configuração incorreta do firewall ou servidor proxy. Essa configuração impede que o tempo de execução de integração auto-hospedado se conecte aos pipelines do Data Factory ou Synapse para se autenticar. Para garantir que o firewall e o servidor proxy estejam configurados corretamente, consulte a seção anterior.
Quando você tenta registrar o tempo de execução de integração auto-hospedado, você receber a seguinte mensagem de erro: "Falha ao registrar este nó de tempo de execução de integração! Confirme se a chave de autenticação é válida e se o serviço de host do serviço de integração está em execução nesta máquina."
Ao abrir o Integration Runtime Configuration Manager, você verá um status de Desconectado ou Conectando. Quando visualiza os registos de eventos do Windows, em Registos de Aplicações e Serviços do Visualizador>de Eventos>Microsoft Integration Runtime, 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 o acesso remoto a partir de uma intranet
Se você usar o PowerShell para criptografar credenciais de uma máquina em rede diferente de onde instalou o tempo de execução de integração auto-hospedado, poderá habilitar a opção Acesso Remoto da Intranet . Se você executar o PowerShell para criptografar credenciais na máquina onde instalou o tempo de execução de integração auto-hospedado, não poderá habilitar o Acesso Remoto da Intranet.
Habilite o Acesso Remoto da Intranet antes de adicionar outro nó para alta disponibilidade e escalabilidade.
Quando você executa a instalação do tempo de execução de integração auto-hospedada versão 3.3 ou posterior, por padrão, o instalador do tempo de execução de integração auto-hospedado desabilita o Acesso Remoto da Intranet na máquina de tempo de execução de integração auto-hospedada.
Quando você usa um firewall de um parceiro ou outros, você pode abrir manualmente a porta 8060 ou a porta configurada pelo usuário. Se você tiver um problema de firewall ao configurar o tempo de execução de integração auto-hospedado, use o seguinte comando para instalar o tempo de execução de integração auto-hospedado sem configurar o firewall:
msiexec /q /i IntegrationRuntime.msi NOFIREWALL=1
Se você optar por não abrir a porta 8060 na máquina de tempo de execução de integração auto-hospedada, use mecanismos diferentes do aplicativo Definindo Credenciais para configurar credenciais de armazenamento de dados. Por exemplo, você pode usar o cmdlet New-AzDataFactoryV2LinkedServiceEncryptCredential PowerShell.
Portas e firewalls
Há dois firewalls a considerar:
- O firewall corporativo que é executado no roteador central da organização
- O firewall do Windows configurado como um daemon na máquina local onde o tempo de execução de integração auto-hospedado está instalado
No nível de firewall corporativo, você precisa configurar os seguintes domínios e portas de saída:
Nomes de domínio | Portas de saída | Description |
---|---|---|
Cloud Pública: *.servicebus.windows.net Azure Government: *.servicebus.usgovcloudapi.net China: *.servicebus.chinacloudapi.cn |
443 | Exigido pelo tempo de execução de integração auto-hospedado para criação interativa. Não é necessário se a criação interativa independente estiver habilitada. |
Cloud Pública: {datafactory}.{region}.datafactory.azure.net ou *.frontend.clouddatahub.net Azure Government: {datafactory}.{region}.datafactory.azure.us China: {datafactory}.{region}.datafactory.azure.cn |
443 | Exigido pelo tempo de execução de integração auto-hospedado para se conectar ao serviço Data Factory. Para o novo Data Factory criado na nuvem pública, localize o nome de domínio totalmente qualificado (FQDN) da sua chave Self-hosted Integration Runtime, que está no formato {data factory}. {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 em sua chave de integração auto-hospedada, use *.frontend.clouddatahub.net em vez disso. |
download.microsoft.com |
443 | Exigido pelo tempo de execução de integração auto-hospedado para baixar as atualizações. Se desativou a atualização automática, pode ignorar a configuração deste domínio. |
URL do Cofre de Chaves | 443 | Exigido pelo Cofre da Chave do Azure se você armazenar a credencial no Cofre da Chave. |
No nível de firewall do Windows ou no nível da máquina, essas portas de saída normalmente são habilitadas. Se não estiverem, você pode configurar os domínios e portas em uma máquina de tempo de execução de integração auto-hospedada.
Nota
Como atualmente o Azure Relay não oferece suporte à tag de serviço, você precisa usar a marca de serviço AzureCloud ou Internet nas regras NSG para a comunicação com o Azure Relay. Para a comunicação com os espaços de trabalho do Azure Data Factory e Synapse, você pode usar a marca de serviço DataFactoryManagement na configuração da regra NSG.
Com base na origem e nos coletores, talvez seja necessário permitir domínios adicionais e portas de saída no firewall corporativo ou no firewall do Windows.
Nomes de domínio | Portas de saída | Description |
---|---|---|
*.core.windows.net |
443 | Usado pelo tempo de execução de integração auto-hospedado para se conectar à conta de armazenamento do Azure quando você usa o recurso de cópia em estágios. |
*.database.windows.net |
1433 | Necessário somente quando você copia de ou para o Banco de Dados SQL do Azure ou o Azure Synapse Analytics e opcional caso contrário. Use o recurso de cópia em estágios para copiar dados para o Banco de Dados SQL ou o Azure Synapse Analytics sem abrir a porta 1433. |
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token |
443 | Necessário somente quando você copia de ou para o Repositório Azure Data Lake e opcional caso contrário. |
Para alguns bancos de dados em nuvem, como o Banco de Dados SQL do Azure e o Azure Data Lake, talvez seja necessário permitir endereços IP de máquinas de tempo de execução de integração auto-hospedadas em suas configurações de firewall.
Nota
Não é correto instalar o Integration Runtime e o gateway do Power BI na mesma máquina, porque principalmente o Integration Runtime usa o número de porta 443, que é uma das principais portas que estão sendo usadas pelo gateway do Power BI também.
Criação interativa independente (visualização)
Para executar ações de criação interativas, como visualização de dados e teste de conexão, o tempo de execução de integração auto-hospedado requer uma conexão com o Azure Relay. Se a conexão não for estabelecida, há duas soluções possíveis para garantir a funcionalidade ininterrupta. A primeira opção é adicionar os pontos de extremidade do Azure Relay à lista de permissões Get URL of Azure Relay do firewall. Como alternativa, você pode habilitar a criação interativa independente.
Nota
Se o tempo de execução de integração auto-hospedado não conseguir estabelecer uma conexão com o Azure Relay, seu status será marcado como "limitado".
Nota
Embora a criação interativa independente esteja habilitada, todo o tráfego de criação interativa será roteado exclusivamente por meio dessa funcionalidade, ignorando o Azure Relay. O tráfego só será redirecionado de volta para o Azure Relay quando você optar por desabilitar esse recurso.
Nota
Não há suporte para "Obter IP" e "Enviar log" quando a criação interativa independente está ativada.
Obter URL do Azure Relay
Um domínio e uma porta necessários que precisam ser colocados na lista de permissões do seu firewall é para a comunicação com o Azure Relay. O tempo de execução de integração auto-hospedado o usa para criação interativa, como conexão de teste, lista de pastas e lista de tabelas, obter esquema e visualizar dados. Se você não quiser permitir .servicebus.windows.net e quiser ter URLs mais específicas, poderá ver todos os FQDNs exigidos pelo seu tempo de execução de integração auto-hospedado no portal de serviços.
Obtenha a URL do Azure Relay via interface do usuário:
Siga estes passos:
Vá para o portal de serviços e selecione seu tempo de execução de integração auto-hospedado.
Na página Editar, selecione Nós.
Selecione Exibir URLs de serviço para obter todos os FQDNs.
Você pode adicionar esses FQDNs na lista de permissões de regras de firewall.
Nota
Para obter os detalhes relacionados ao protocolo de conexões de retransmissão do Azure, consulte Protocolo de conexões híbridas de retransmissão do Azure.
Obtenha a URL do Azure Relay via script:
# The documentation of Synapse self hosted integration runtime (SHIR) mentions that the SHIR requires access to the Azure Service Bus IP addresses
# https://learn.microsoft.com/en-us/azure/data-factory/create-self-hosted-integration-runtime
# It is a requirement to use a wildcard (*.servicebus.windows.net) in your firewalls.
# While this is the easiest way to clear the firewall, it also opens the firewall to all Azure Service Bus IP addresses, including malicious_actor.servicebus.windows.net.
# This might be restricted by your security policies.
# This script resolves the Azure Service Bus IP addresses used by an integration runtime and adds them to the network security group (NSG) rule for the Synapse self-hosted integration runtime (SHIR).
# As the mapping of IP addresses to Domain Names might change, we recommend to run at least once a day to keep the NSG up to date.
# An alternative to running this script is to use the "Self-contained interactive authoring" feature of the self hosted integration runtime.
# Prerequisites:
# - PowerShell installed
# - Azure CLI (az) installed and logged in (https://learn.microsoft.com/en-us/cli/azure/)
# - signed in user needs rights to modify NSG (e.g. Network contributor) and to read status of the SHIR (e.g. reader), plus reader on the subscription
param (
[string]$synapseRresourceGroupName = "synapse_test",
[string]$nsgResourceGroupName = "adf_shir_rg",
[string]$synapseWorkspaceName = "synapse-test-jugi2",
[string]$integrationRuntimeName = "IntegrationRuntime2",
[string]$networkSecurityGroupName = "jugis-shir-nsg",
[string]$securityRuleName = "AllowSynapseServiceBusIPs",
[int]$priority = 100
)
# Check if the user is already logged in
$azAccount = az account show 2>$null
if (-not $azAccount) {
# Run az login with managed identity if not logged in
az login --identity
}
# Retrieve the URLs of the connections from the Synapse self-hosted integration runtime
$urls = az synapse integration-runtime get-status `
--resource-group $synapseResourceGroupName `
--workspace-name $synapseWorkspaceName `
--name $integrationRuntimeName `
--query "properties.serviceUrls" -o tsv
# Initialize an empty array to hold the IP addresses
$ipAddresses = @()
# Iterate over the URLs to resolve and collect the IP addresses
# The proper DNS resolution might only work within Azure, not locally
foreach ($url in $urls) {
Write-Output "Processing URL: $url"
$ip = [System.Net.Dns]::GetHostAddresses($url) | Where-Object { $_.AddressFamily -eq 'InterNetwork' } | Select-Object -ExpandProperty IPAddressToString
if ($ip) {
$ipAddresses += $ip
}
}
# Remove duplicate IP addresses from the array
$ipAddresses = $ipAddresses | Sort-Object -Unique
# Convert the array of IP addresses to a space-separated string
$ipAddressesString = $ipAddresses -join ' '
# Create or update the network security group rule to allow outbound traffic for the collected IP addresses
# Using Invoke-Expression to handle the command string
$az_cmd = "az network nsg rule create --resource-group $nsgResourceGroupName --nsg-name $networkSecurityGroupName --name $securityRuleName --priority $priority --destination-address-prefixes $ipAddressesString --destination-port-ranges '443' --direction Outbound --access Allow --protocol '*' --description 'Allow outbound access to Synapse servicebus IPs'"
Invoke-Expression $az_cmd
Copiar dados de uma fonte para um coletor
Certifique-se de habilitar corretamente as regras de firewall no firewall corporativo, no firewall do Windows da máquina de tempo de execução de integração auto-hospedada e no próprio armazenamento de dados. A habilitação dessas regras permite que o tempo de execução de integração auto-hospedado se conecte com êxito à origem e ao coletor. Habilite regras para cada armazenamento de dados envolvido na operação de cópia.
Por exemplo, para copiar de um armazenamento de dados local para um coletor do Banco de dados SQL ou um coletor do Azure Synapse Analytics, execute as seguintes etapas:
- Permita a comunicação TCP de saída na porta 1433 para o firewall do Windows e o firewall corporativo.
- Configure as configurações de firewall do Banco de dados SQL para adicionar o endereço IP da máquina de tempo de execução de integração auto-hospedada à lista de endereços IP permitidos.
Nota
Se o firewall não permitir a porta de saída 1433, o tempo de execução de integração auto-hospedado não poderá acessar o banco de dados SQL diretamente. Nesse caso, você pode usar uma cópia em estágios para o Banco de Dados SQL e o Azure Synapse Analytics. Nesse cenário, você precisa apenas de HTTPS (porta 443) para a movimentação de dados.
Se toda a fonte de dados e o tempo de execução de integração auto-hospedado estiverem em ambiente local, os dados copiados não irão para a nuvem, mas permanecerão estritamente no local.
Armazenamento de credenciais
Há duas maneiras de armazenar as credenciais ao usar o tempo de execução de integração auto-hospedado:
- Use Azure Key Vault.
Essa é a maneira recomendada de armazenar suas credenciais no Azure. O tempo de execução de integração auto-hospedado pode obter diretamente as credenciais do Cofre de Chaves do Azure, o que pode evitar alguns possíveis problemas de segurança ou quaisquer problemas de sincronização de credenciais entre nós de tempo de execução de integração auto-hospedados. 2. Armazene as credenciais localmente.
As credenciais serão enviadas por push para a máquina do seu tempo de execução de integração auto-hospedado e serão criptografadas. Quando o tempo de execução de integração auto-hospedado é recuperado de falha, você pode recuperar a credencial do que você fez backup antes ou editar o serviço vinculado e permitir que a credencial seja enviada por push para o tempo de execução de integração auto-hospedado novamente. Caso contrário, o pipeline não funcionará devido à falta de credencial ao ser executado por meio do tempo de execução de integração auto-hospedado.
Nota
Se preferir armazenar a credencial localmente, será necessário colocar o domínio para criação interativa na lista de permissões do firewall e abrir a porta. Esse canal também é para o tempo de execução de integração auto-hospedado para obter as credenciais. Para obter o domínio e a porta necessários para a criação interativa, consulte Portas e firewalls
Melhores práticas de instalação
Você pode instalar o tempo de execução de integração auto-hospedado baixando um pacote de instalação do Managed Identity do Centro de Download da Microsoft. Consulte o artigo Mover dados entre o local e a nuvem para obter instruções passo a passo.
- Configure um plano de energia na máquina host para o tempo de execução de integração auto-hospedado para que a máquina não hiberne. Se a máquina host hibernar, o tempo de execução de integração auto-hospedado ficará offline.
- Faça backup regularmente das credenciais associadas ao tempo de execução de integração auto-hospedado.
- Para automatizar as operações de configuração de IR auto-hospedadas, consulte Configurar um IR auto-hospedado existente via PowerShell.
Considerações importantes
Ao instalar um tempo de execução de integração auto-hospedado, considere o seguinte:
- Mantenha-o perto da sua fonte de dados, mas não necessariamente na mesma máquina
- Não o instale na mesma máquina que o gateway do Power BI
- Somente Windows Server (servidores de criptografia compatíveis com FIPS podem fazer com que os trabalhos falhem)
- Compartilhar entre várias fontes de dados
- Compartilhar em várias fábricas de dados
Conteúdos relacionados
Para obter instruções passo a passo, consulte Tutorial: Copiar dados locais para a nuvem.