Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O IR (runtime de integração) é a infraestrutura de computação que o Microsoft Purview usa para alimentar a verificação de dados em diferentes ambientes de rede.
Um SHIR (runtime de integração auto-hospedada) pode ser usado para verificar a fonte de dados em uma rede local ou em uma rede virtual. A instalação de um runtime de integração auto-hospedada precisa de um computador local ou de uma máquina virtual dentro de uma rede privada.
Este artigo aborda a configuração de um runtime de integração auto-hospedada e a solução de problemas e gerenciamento.
Importante
Baixe o runtime de integração auto-hospedada em: Microsoft Integration Runtime.
| Para saber mais sobre | Consulte |
|---|---|
| Configurando um novo runtime de integração auto-hospedada | Requisitos da máquina |
| Os requisitos de computador específicos da fonte são listados em Pré-requisitos em cada artigo de origem | |
| Guia de configuração | |
| Rede | Requisitos de rede |
| Servidores proxy | |
| Pontos de extremidade privados | |
| Solucionar problemas de proxy e firewall | |
| Solucionar problemas de conectividade | |
| Gerenciamento | Geral |
Observação
O Integration Runtime do Microsoft Purview não pode ser compartilhado com um Azure Synapse Analytics ou Azure Data Factory Integration Runtime no mesmo computador. Ele precisa ser instalado em uma máquina separada.
Pré-requisitos
As versões com suporte do Windows são:
- Windows 8.1
- Windows 10
- Windows 11
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Windows Server 2025
Não há suporte para a instalação do runtime de integração auto-hospedada em um controlador de domínio.
No momento, não há suporte para o modo FIPS para computadores SHIR.
Importante
A verificação de algumas fontes de dados requer configuração extra no computador de runtime de integração auto-hospedada. Por exemplo, JDK, Pacote Redistribuível do Visual C++ ou driver específico. Para obter a fonte, consulte cada artigo de origem para obter detalhes de pré-requisito. Todos os requisitos serão listados na seção Pré-requisitos .
Para adicionar e gerenciar um SHIR no Microsoft Purview, você precisará de permissões de administrador da fonte de dados no Microsoft Purview.
O runtime de integração auto-hospedada requer um sistema operacional de 64 bits com o .NET Framework 4.7.2 ou superior. Consulte os Requisitos do 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 8 núcleos, 28 GB de RAM e 80 GB de espaço disponível no disco rígido. A verificação de algumas fontes de dados pode exigir especificações de computador mais altas com base no cenário. Além disso, marque os pré-requisitos no artigo do conector correspondente.
Se o computador host hibernar, o runtime de integração auto-hospedada não responderá às solicitações de dados. Configure um plano de energia apropriado 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 enviará uma mensagem.
Você deve ser um administrador no computador para instalar e configurar com êxito o runtime de integração auto-hospedada.
As execuções de verificação acontecem com uma frequência específica de acordo com o agendamento que você configurou. O uso do processador e da RAM no computador segue o mesmo padrão com tempos de pico e ociosos. O uso de recursos também depende muito da quantidade de dados verificados. Quando vários trabalhos de verificação estão em andamento, você vê que o uso de recursos aumenta durante os horários de pico.
Habilite o caminho longo do Windows por padrão seguindo estas etapas.
Importante
Se você usar o runtime Self-Hosted Integration para verificar arquivos Parquet, precisará instalar o JRE 8 (Java Runtime Environment) de 64 bits ou o OpenJDK em sua máquina de IR. Verifique nossa seção Java Runtime Environment na parte inferior da página para obter um guia de instalação.
Considerações sobre o uso de um IR auto-hospedado
- Você pode usar um único runtime de integração auto-hospedada para verificar várias fontes de dados.
- Você pode instalar apenas uma instância do runtime de integração auto-hospedada em qualquer computador único. Se você tiver duas contas do Microsoft Purview que precisam verificar fontes de dados locais, instale o IR auto-hospedado em dois computadores, um para cada conta do Microsoft Purview.
- O runtime de integração auto-hospedada não precisa estar no mesmo computador que a fonte de dados, a menos que seja especialmente mencionado como pré-requisito no respectivo artigo de origem. Ter o runtime de integração auto-hospedada próximo à fonte de dados reduz o tempo para o runtime de integração auto-hospedada se conectar à fonte de dados.
- Para otimizar o espaço em disco, é recomendável limpar periodicamente as pastas numéricas, juntamente com as pastas numéricas na pasta Data Scan e MITIlib com mais de sete dias, na pasta Temp gerada em sua máquina.
Configurando um runtime de integração auto-hospedada
Para criar e configurar um runtime de integração auto-hospedada, use os procedimentos a seguir.
Criar um runtime de integração auto-hospedada
Observação
Para adicionar ou gerenciar um SHIR no Microsoft Purview, você precisará de permissões de administrador da fonte de dados no Microsoft Purview.
Na página inicial do portal de governança do Microsoft Purview clássico, selecione Mapa de Dados no painel de navegação esquerdo.
Em Fontes e verificação no painel esquerdo, selecione Runtimes de integração e, em seguida, selecione + Novo.
Na página Configuração do runtime de integração , selecione Auto-hospedado para criar um IR auto-hospedado e selecione Continuar.
Insira um nome para o IR e selecione Criar.
Na página de configurações do Integration Runtime, siga as etapas na seção Configuração manual. Você terá que baixar o runtime de integração do site de download em uma VM ou computador em que pretende executá-lo.
Copie e cole a chave de autenticação.
Baixe o runtime de integração auto-hospedada do Microsoft Integration Runtime em um computador Windows local. Execute o instalador. Versões de tempo de execução de integração auto-hospedada, como 5.4.7803.1 e 5.6.7795.1, têm suporte.
Na página Registrar o Integration Runtime (auto-hospedado), cole uma das duas chaves salvas anteriormente e selecione Registrar.
Na página Novo Nó do Integration Runtime (auto-hospedado), selecione Concluir.
Depois que o runtime de integração auto-hospedada for registrado com êxito, você verá a seguinte janela:
Você pode registrar vários nós para um runtime de integração auto-hospedada usando a mesma chave. Saiba mais com Alta disponibilidade e escalabilidade.
Gerenciar um runtime de integração auto-hospedada
Você pode editar um runtime de integração auto-hospedada navegando até Runtimes de integração no portal de governança do Microsoft Purview clássico, passando o mouse sobre o IR e, em seguida, selecionando Editar.
- Na guia Configurações , você pode atualizar a descrição, copiar a chave ou regenerar novas chaves.
- Na guia Nodes, você pode ver uma lista dos nós registrados, juntamente com o status, endereço IP e a opção de exclusão do nó. Saiba mais com Alta disponibilidade e escalabilidade.
- Na guia Versão, você pode ver o status da versão de IR. Saiba mais em Runtime de integração auto-hospedada, atualização automática e notificação de expiração.
Você pode excluir um runtime de integração auto-hospedada navegando até Runtimes de integração, passe o mouse sobre o IR e selecione o botão Excluir .
Í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 runtime de integração auto-hospedada.
Conta de serviço para tempo de execução de integração auto-hospedada
A conta de serviço de entrada padrão do runtime de integração auto-hospedada é NT SERVICE\DIAHostService. Você pode vê-lo em Serviços -> Serviço Integration Runtime -> Propriedades -> Log on.
Certifique-se de que a conta tenha a permissão de Log-on como serviço. Caso contrário, o runtime de integração auto-hospedada não poderá ser iniciado com êxito. Você pode marcar 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
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. Essas máquinas são chamadas 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 são:
- Maior disponibilidade do runtime de integração auto-hospedada para que ele não seja mais o único ponto de falha para verificação. Essa disponibilidade ajuda a garantir a continuidade quando você usa até quatro nós.
- Execute mais verificações simultâneas. Cada runtime de integração auto-hospedada pode capacitar muitas execuções de verificação ao mesmo tempo, determinadas automaticamente com base na CPU/memória do computador. Você poderá instalar mais nós se tiver mais necessidade de simultaneidade.
- Ao verificar fontes como o Blob do Azure, o Azure Data Lake Storage Gen1, o Azure Data Lake Storage Gen2 e os Arquivos do Azure, cada execução de verificação pode usar todos esses nós para aumentar o desempenho da verificação. Para outras fontes, a varredura será executada em um dos nós.
Você pode associar vários nós instalando o software de tempo de execução de integração auto-hospedada no Centro de Download. Em seguida, registre-o 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 Gerenciador de Configurações>Configurações>Acesso remoto à intranet.
Requisitos de rede
Seu computador de runtime de integração auto-hospedada precisa se conectar a vários recursos para funcionar corretamente:
- Os serviços do Microsoft Purview usados para gerenciar o runtime de integração auto-hospedada.
- As fontes de dados que você deseja examinar usando o runtime de integração auto-hospedada.
- Se sua conta foi criada antes de 15 de dezembro de 2023, seu runtime de integração precisará ser capaz de se conectar à conta de armazenamento gerenciada criada pelo Microsoft Purview. Se sua conta for criada após essa data (ou implantada usando a API versão 2023-05-01-preview em diante), uma conta de armazenamento de ingestão será usada. O Microsoft Purview usa esse recurso para incluir os resultados da verificação, entre muitas outras coisas.
Há dois firewalls a serem considerados:
- O firewall corporativo que é executado no roteador central da organização
- O Firewall do Windows que está configurado como um daemon no computador local em que o runtime de integração auto-hospedada está instalado
Aqui estão os domínios e as portas de saída que você precisa permitir nos firewalls corporativos e do Windows/computador.
Dica
- Para domínios listados com "<managed_storage_account>", adicione o nome dos recursos gerenciados associados à sua conta do Microsoft Purview. Você pode encontrá-los no portal do Azure –> sua conta do Microsoft Purview –>Guia Configurações –>Recursos gerenciados.
- Se sua conta não tem uma conta de armazenamento gerenciada, ela está usando o armazenamento de ingestão. Consulte os domínios com "<ingestion_storage_account>" na tabela abaixo. Você pode encontrar as informações de armazenamento no portal do Azure ->Propriedades ->ID de armazenamento de ingestão. Para marcar os detalhes do ponto de extremidade, acesse Visão geral -Exibição JSON> -> propriedade "primaryEndpoint".
| Nomes de domínio | Portas de saída | Descrição |
|---|---|---|
Nuvem pública: *.frontend.clouddatahub.netAzure Governamental: *.frontend.datamovement.azure.usChina: *.frontend.datamovement.azure.cn |
443 | Necessário para se conectar ao serviço Microsoft Purview. Atualmente, o curinga é necessário, pois não há recurso dedicado. |
Nuvem pública: *.servicebus.windows.netAzure Governamental: *.servicebus.usgovcloudapi.netChina: *.servicebus.chinacloudapi.cn |
443 | Necessário para configurar a verificação no portal de governança do Microsoft Purview clássico. Esse ponto de extremidade é usado para criação interativa da interface do usuário, por exemplo, teste de conexão, lista de pastas de navegação e lista de tabelas para verificação de escopo. Para evitar o uso de curinga, consulte Obter URL da Retransmissão do Azure. |
Nuvem pública: <tenantId>-api.purview-service.microsoft.comAzure Governamental: <tenantId>-api.purview-service.microsoft.usChina: <tenantId>-api.purview-service.microsoft.cn |
443 | Necessário para se conectar ao serviço Microsoft Purview. Se você usar Pontos de Extremidade Privados do Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado da plataforma. |
Nuvem pública: <purview_account>.purview.azure.comAzure Governamental: <purview-account>.purview.azure.usChina: <purview_account>.purview.azure.cn |
443 | Necessário para se conectar ao serviço Microsoft Purview. Se você usar Pontos de Extremidade Privados do Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado da conta. |
Nuvem pública: <managed_storage_account>.blob.core.windows.net ou <ingestion_storage_account>.*.blob.storage.azure.netAzure Governamental: <managed_storage_account>. blob.core.usgovcloudapi.net ou<ingestion_storage_account>. blob.core.usgovcloudapi.netChina: <managed_storage_account>.blob.core.chinacloudapi.cnou <ingestion_storage_account>.blob.core.chinacloudapi.cn |
443 | Necessário para se conectar à conta de Armazenamento de Blobs do Azure gerenciada pelo Microsoft Purview. Se você usar Pontos de Extremidade Privados do Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado de ingestão. |
Nuvem pública: <managed_storage_account>.queue.core.windows.net ou <ingestion_storage_account>.*.queue.storage.azure.netAzure Governamental: <managed_storage_account>. queue.core.usgovcloudapi.net ou<ingestion_storage_account>. queue.core.usgovcloudapi.netChina: <managed_storage_account>.queue.core.chinacloudapi.cnou <ingestion_storage_account>.queue.core.chinacloudapi.cn |
443 | Necessário para se conectar à conta de armazenamento de Fila do Azure gerenciada pelo Microsoft Purview. Se você usar Pontos de Extremidade Privados do Purview, esse ponto de extremidade será coberto pelo ponto de extremidade privado de ingestão. |
download.microsoft.com |
443 | Necessário para baixar as atualizações do runtime de integração auto-hospedada. Se você tiver desabilitado a atualização automática, poderá ignorar a configuração desse domínio. |
Nuvem pública: login.windows.net e login.microsoftonline.comAzure Governamental: login.microsoftonline.usChina: login.partner.microsoftonline.cn |
443 | É necessário entrar no Microsoft Entra ID. |
Observação
Como atualmente a Retransmissão do Azure não dá suporte à marca de serviço, você precisa usar a marca de serviço AzureCloud ou Internet nas regras do NSG para a comunicação com a Retransmissão do Azure.
Dependendo das fontes que você deseja verificar, você também precisa permitir outros domínios e portas de saída para outras fontes externas ou do Azure. Alguns exemplos são fornecidos aqui:
| Nomes de domínio | Portas de saída | Descrição |
|---|---|---|
<your_storage_account>.dfs.core.windows.net |
443 | Ao verificar o Azure Data Lake Store Gen 2. |
<your_storage_account>.blob.core.windows.net |
443 | Ao verificar o armazenamento de Blobs do Azure. |
<your_sql_server>.database.windows.net |
1433 | Ao digitalizar SQL do Azure Banco de dados. |
*.powerbi.com e *.analysis.windows.net |
443 | Ao verificar locatário do Power BI. |
<your_ADLS_account>.azuredatalakestore.net |
443 | Ao verificar o Azure Data Lake Store Gen 1. |
| Vários domínios | Dependente | Domínios e portas para quaisquer outras fontes que o SHIR examinará. |
Para alguns armazenamentos de dados em nuvem, como o Banco de Dados SQL do Azure e o Armazenamento do Azure, talvez seja necessário permitir o endereço IP da máquina de runtime de integração auto-hospedada em sua configuração de firewall ou você pode criar um ponto de extremidade privado do serviço na rede do runtime de integração auto-hospedada.
Importante
Na maioria dos ambientes, você também precisará verificar se o DNS está configurado corretamente. Para confirmar, você pode usar nslookup em seu computador SHIR para marcar a conectividade com cada um dos domínios. Cada nslookup deve retornar o IP do recurso. Se você estiver usando Pontos de Extremidade Privados, o IP privado deverá ser retornado e não o IP Público. Se nenhum IP for retornado ou se, ao usar Pontos de Extremidade Privados, o IP público for retornado, você precisará resolver sua associação DNS/VNet ou seu Ponto de Extremidade Privado/emparelhamento VNet.
Obter URL da Retransmissão do Azure
Um domínio e uma porta necessários que precisam ser colocados na lista de permissões do seu firewall é a comunicação com a Retransmissão do Azure. O runtime de integração auto-hospedada o usa para criação interativa, como testar a conexão e procurar na lista de pastas/tabelas. Se você não quiser permitir .servicebus.windows.net e quiser ter URLs mais específicas, poderá ver todos os FQDNs exigidos pelo seu runtime de integração auto-hospedada. Siga estas etapas:
Acesse o portal de governança clássico do Microsoft Purview -> Mapa de Dados -> Runtimes de integração e edite seu runtime de integração auto-hospedada.
Na página Editar, selecione a guia Nós .
Selecione Exibir URLs de Serviço para obter todos os FQDNs.
Você pode adicionar esses FQDNs à lista de regras de firewall.
Observação
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.
Considerações sobre o servidor proxy
Se o ambiente de rede corporativa usa um servidor proxy para acessar a Internet, configure o runtime de integração auto-hospedada para usar as configurações de proxy apropriadas. Você pode definir o proxy durante a fase de registro inicial ou após o registro.
Quando configurado, o runtime de integração auto-hospedada usa o servidor proxy para se conectar aos serviços que usam o protocolo HTTP ou HTTPS. É por isso que você seleciona Alterar link durante a configuração inicial.
Há duas opções de configuração com suporte pelo Microsoft Purview:
- Não use proxy: o runtime de integração auto-hospedada não usa explicitamente nenhum proxy para se conectar aos serviços de nuvem.
- Usar proxy do sistema: o runtime de integração auto-hospedada usa a configuração de proxy definida nos arquivos de configuração do executável. Se nenhum proxy for especificado nesses arquivos, o runtime de integração auto-hospedada se conectará aos serviços diretamente sem passar por um proxy.
- Usar proxy personalizado: defina a configuração de proxy HTTP a ser usada para o runtime de integração auto-hospedada, em vez de usar configurações no diahost.exe.config e no diawp.exe.config. Os valores de endereço e porta são necessá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 Windows DPAPI no runtime de integração auto-hospedada e armazenadas localmente no computador.
Observação
A conexão a fontes de dados por proxy não tem suporte para conectores que não sejam as fontes de dados do Azure e o Power BI.
O serviço de host de runtime de integração reinicia automaticamente depois que você salva as configurações de proxy atualizadas.
Depois de registrar o runtime de integração auto-hospedada, se você quiser exibir ou atualizar as configurações de proxy, use Microsoft Integration Runtime Gerenciador de Configurações.
- Abra Microsoft Integration Runtime Gerenciador de Configurações.
- Selecione a guia Configurações.
- Em Proxy HTTP, selecione o link Alterar para abrir a caixa de diálogo Definir Proxy HTTP .
- Selecione Avançar. Em seguida, você verá um aviso solicitando sua permissão para salvar a configuração de proxy e reiniciar o serviço host de runtime de integração.
Observação
Se você configurar um servidor proxy com autenticação NTLM, o serviço de host do runtime de integração será executado na conta de domínio. Se, posteriormente, você alterar a senha da conta de domínio, lembre-se de atualizar as definições de configuração do serviço e reiniciá-lo. 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.
Se estiver usando o proxy do sistema, certifique-se de que seu servidor proxy permita tráfego de saída para as regras de rede.
Definir as configurações do servidor proxy
Se você selecionar a opção Usar proxy do sistema para o proxy HTTP, o runtime de integração auto-hospedada usará as configurações de proxy nos quatro arquivos a seguir no caminho C:\Program Files\Microsoft Integration Runtime\5.0\ para executar operações diferentes:
- .\Shared\diahost.exe.config
- .\Shared\diawp.exe.config
- .\Gateway\DataScan\Microsoft.DataMap.Agent.exe.config
- .\Gateway\DataScan\DataTransfer\Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config
Quando nenhum proxy é especificado nesses arquivos, o runtime de integração auto-hospedada se conecta aos serviços diretamente sem passar por um proxy.
O procedimento a seguir fornece instruções para atualizar o arquivo diahost.exe.config .
No Explorador de Arquivos, faça uma cópia segura do Runtime\5.0\Shared\diahost.exe.config C:\Program Files\Microsoft Integration como um backup do arquivo 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 marca system.net padrão, conforme mostrado no seguinte código:
<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> <proxy bypassonlocal="true" proxyaddress="<your proxy server e.g. http://proxy.domain.org:8888/>" /> </defaultProxy> </system.net>A tag de proxy permite que outras propriedades 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.
Repita o mesmo procedimento para atualizar arquivosdiawp.exe.config e Microsoft.DataMap.Agent.exe.config .
Em seguida, vá para o caminho C:\Program Files\Microsoft Integration Runtime\5.0\Gateway\DataScan\DataTransfer, crie um arquivo chamado "Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config", e defina a configuração de proxy da seguinte maneira. Você também pode estender as configurações conforme descrito acima.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.net>
<defaultProxy>
<proxy bypassonlocal="true" proxyaddress="<your proxy server e.g. http://proxy.domain.org:8888/>" />
</defaultProxy>
</system.net>
</configuration>
O tráfego local deve ser excluído do proxy, por exemplo, se sua conta do Microsoft Purview estiver atrás de pontos de extremidade privados. Nesses casos, atualize os quatro arquivos a seguir no caminho para incluir a lista de bypass C:\Program Files\Microsoft Integration Runtime\5.0\ com a lista de bypass necessária:
- .\Shared\diahost.exe.config
- .\Shared\diawp.exe.config
- .\Gateway\DataScan\Microsoft.DataMap.Agent.exe.config
- .\Gateway\DataScan\DataTransfer\Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config
Um exemplo de lista de bypass para verificar um Banco de Dados SQL do Azure e armazenamento ADLS gen 2:
<system.net>
<defaultProxy>
<bypasslist>
<add address="scaneastus4123.blob.core.windows.net" />
<add address="scaneastus4123.queue.core.windows.net" />
<add address="Atlas-abc12345-1234-abcd-a73c-394243a566fa.servicebus.windows.net" />
<add address="contosopurview123.purview.azure.com" />
<add address="contososqlsrv123.database.windows.net" />
<add address="contosoadls123.dfs.core.windows.net" />
<add address="contosoakv123.vault.azure.net" />
</bypasslist>
<proxy proxyaddress=http://proxy.domain.org:8888 bypassonlocal="True" />
</defaultProxy>
</system.net>
Reinicie o serviço de host de runtime de integração auto-hospedada, que seleciona as alterações. Para reiniciar o serviço, use o miniaplicativo de serviços no Painel de Controle. Ou, no Integration Runtime Gerenciador de Configurações, 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 incorreta da marca XML no arquivo de configuração do aplicativo que você editou.
Importante
Não se esqueça de atualizar todos os quatro arquivos mencionados acima.
Você também precisa verificar se o Microsoft Azure está na lista de permissões da sua empresa. Você pode baixar a lista de endereços IP do Azure válidos. 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:
Possíveis sintomas de problemas relacionados ao firewall e ao servidor proxy
Se você vir mensagens de erro como as seguintes, o motivo provável é a configuração inadequada do firewall ou do servidor proxy. Essa configuração impede que o runtime de integração auto-hospedada se conecte aos serviços do Microsoft Purview. Para garantir que o firewall e o servidor proxy estejam configurados corretamente, consulte a seção anterior.
Ao tentar registrar o runtime de integração auto-hospedada, você recebe a seguinte mensagem de erro: "Falha ao registrar este nó do Integration Runtime! Confirme se a chave de autenticação é válida e se o serviço host do serviço de integração está em execução nesta máquina."
Ao abrir Integration Runtime Gerenciador de Configurações, você vê uma status de Desconectado ou Conectando. Ao exibir logs de eventos do Windows, em Visualizador de EventosLogs> 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)
Instalação do Java Runtime Environment
Se você digitalizar arquivos Parquet usando o runtime de integração auto-hospedada com o Microsoft Purview, precisará instalar o Java Runtime Environment ou o OpenJDK em seu computador de IR auto-hospedado.
Ao verificar arquivos Parquet usando o IR auto-hospedado, o serviço localiza o tempo de execução Java verificando primeiro o registro (HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Current Version}\JavaHome) para JRE, se não for encontrado, em segundo lugar, verificando a variável JAVA_HOME do sistema para OpenJDK. Você pode definir JAVA_HOME em Configurações do Sistema, Variáveis de Ambiente em seu computador. Crie ou edite a variável JAVA_HOME para apontar para o jre Java em sua máquina. Por exemplo: C:\Program Files\Java\jdk1.8\jre
- Para usar o JRE: o IR de 64 bits requer o JRE de 64 bits. Você pode encontrá-lo aqui.
- Para usar o OpenJDK: é suportado desde a versão 3.13 do IR. Empacote o jvm.dll com todos os outros assemblies necessários do OpenJDK na máquina IR auto-hospedada e defina a variável de ambiente do sistema JAVA_HOME de acordo.
Como marcar sua versão do runtime de integração auto-hospedada
Você pode marcar a versão do seu runtime de integração auto-hospedada no portal de governança clássico do Microsoft Purview –> Mapa de Dados –> Runtimes de integração:
Você também pode marcar a versão em seu cliente de runtime de integração auto-hospedada -> guia Ajuda.
Auto-hospedado Integration Runtime autoupdate
A atualização automática é habilitada por padrão quando você instala um runtime de integração auto-hospedada. Você tem duas opções para gerenciar a versão do runtime de integração auto-hospedada: atualização automática ou manutenção manual. Normalmente, o Microsoft Purview lança duas novas versões do runtime de integração auto-hospedada todos os meses, o que inclui o lançamento de novos recursos, correção de bugs ou aprimoramentos. Portanto, recomendamos que os usuários atualizem para a versão mais recente para obter os recursos e aprimoramentos mais recentes.
O runtime de integração auto-hospedada é atualizado automaticamente para uma versão mais recente. Quando a nova versão estiver disponível e ainda não estiver agendada para sua instância, você também poderá disparar a atualização no portal.
Observação
Se você tiver vários nós de runtime de integração auto-hospedada, não haverá tempo de inatividade durante a atualização automática. A atualização automática ocorre primeiro em um nó enquanto outros estão trabalhando em tarefas. Quando o primeiro nó termina a atualização, ele assume as tarefas restantes quando outros nós estão sendo atualizados. Se você tiver apenas um nó de runtime de integração auto-hospedada, ele terá algum tempo de inatividade durante a atualização automática.
Versão do Autoupdate versus versão mais recente
Para garantir a estabilidade do runtime de integração auto-hospedada, embora lancemos duas versões, enviamos apenas uma versão por mês. Portanto, às vezes você descobre que a versão do autoupdate é a versão anterior da versão mais recente real. Se você deseja obter a versão mais recente, pode acessar o Centro de Download e fazer isso manualmente. Além disso, a atualização automática para uma nova versão é gerenciada pelo serviço e você não pode alterá-la.
A guia Versão do runtime de integração auto-hospedada no portal de governança do Microsoft Purview clássico mostra a versão mais recente se a versão atual for antiga. Quando o seu runtime de integração auto-hospedada está online, esta versão é a versão do autoupdate e atualiza automaticamente o seu runtime de integração auto-hospedada no horário agendado. Mas se o runtime de integração auto-hospedada estiver offline, a página mostrará apenas a versão mais recente.
Se você tiver vários nós e, por alguns motivos, alguns deles não foram atualizados automaticamente com êxito. Em seguida, esses nós são revertidos para a versão, que era a mesma em todos os nós antes da atualização automática.
Expiração do Integration Runtime auto-hospedado
Cada versão do runtime de integração auto-hospedada expira em um ano. A mensagem de expiração é mostrada no portal de governança clássico do Microsoft Purview e no cliente de runtime de integração auto-hospedada 90 dias antes da expiração.