Partilhar via

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

  • Artigo

O runtime de integração (IR) é a infraestrutura de computação que o Microsoft Purview utiliza para ativar a análise de dados em diferentes ambientes de rede.

Um runtime de integração autoalojado (SHIR) pode ser utilizado para analisar a origem de dados numa rede no local ou numa rede virtual. A instalação de um runtime de integração autoalojado precisa de uma máquina no local ou de uma máquina virtual dentro de uma rede privada.

Este artigo aborda a configuração de um runtime de integração autoalojado e a resolução de problemas e gestão.

Importante

Transfira o runtime de integração autoalojado a partir de: Microsoft Integration Runtime.

Tópico Seção
Configurar um novo runtime de integração autoalojado Requisitos do computador
Os requisitos de máquinas específicas da origem estão listados em pré-requisitos em cada artigo de origem
Guia de configuração
Rede Requisitos de rede
Servidores proxy
Pontos de extremidade privados
Resolver problemas do proxy e da firewall
Resolver problemas de conectividade
Gerenciamento Geral

Observação

O Integration Runtime do Microsoft Purview não pode ser partilhado com um Azure Synapse Analytics ou Azure Data Factory Integration Runtime no mesmo computador. Tem de ser instalado num computador separado.

Pré-requisitos

  • As versões suportadas 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

  • A instalação do runtime de integração autoalojado num controlador de domínio não é suportada.

  • O modo FIPS não é atualmente suportado para máquinas SHIR.

Importante

A análise de algumas origens de dados requer uma configuração adicional no computador de runtime de integração autoalojado. Por exemplo, JDK, Pacote Redistribuível do Visual C++ ou controlador específico. Para obter a sua origem, consulte cada artigo de origem para obter detalhes de pré-requisitos. Todos os requisitos serão listados na secção Pré-requisitos .

  • Para adicionar e gerir um SHIR no Microsoft Purview, precisará de permissões de administrador da origem de dados no Microsoft Purview.

  • O runtime de integração autoalojado requer um Sistema Operativo de 64 bits com .NET Framework 4.7.2 ou superior. Veja .NET Framework System Requirements (Requisitos de Sistema) para obter detalhes.

  • A configuração mínima recomendada para o computador de runtime de integração autoalojado é 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 análise de algumas origens de dados pode exigir uma especificação de máquina mais elevada com base no seu cenário. Além disso, marcar os pré-requisitos no artigo do conector correspondente.

  • Se o computador anfitrião hibernar, o runtime de integração autoalojado não responde aos pedidos de dados. Configure um esquema de energia adequado no computador antes de instalar o runtime de integração autoalojado. Se o computador estiver configurado para hibernar, o instalador do runtime de integração autoalojado solicita uma mensagem.

  • Tem de ser um administrador no computador para instalar e configurar com êxito o runtime de integração autoalojado.

  • As execuções de análise ocorrem com uma frequência específica de acordo com a agenda que configurou. A utilização do processador e da RAM no computador segue o mesmo padrão com tempos de pico e inatividade. A utilização de recursos também depende bastante da quantidade de dados que são analisados. Quando várias tarefas de análise estão em curso, verá que a utilização de recursos aumenta durante as horas de pico.

Importante

Se utilizar o runtime de integração do Self-Hosted para analisar ficheiros Parquet, terá de instalar o JRE 8 de 64 bits (Ambiente de Runtime Java) ou o OpenJDK no seu computador IR. Consulte a nossa secção Ambiente de Runtime Java na parte inferior da página para obter um guia de instalação.

Considerações para utilizar um IR autoalojado

  • Pode utilizar um único runtime de integração autoalojado para analisar várias origens de dados.
  • Só pode instalar uma instância do runtime de integração autoalojado em qualquer computador. Se tiver duas contas do Microsoft Purview que precisam de analisar origens de dados no local, instale o IR autoalojado em dois computadores, um para cada conta do Microsoft Purview.
  • O runtime de integração autoalojado não precisa de estar no mesmo computador que a origem de dados, a menos que seja especialmente chamado como um pré-requisito no respetivo artigo de origem. Ter o runtime de integração autoalojado perto da origem de dados reduz o tempo para o runtime de integração autoalojado se ligar à origem de dados.

Configurar um runtime de integração autoalojado

Para criar e configurar um runtime de integração autoalojado, utilize os seguintes procedimentos.

Criar um runtime de integração autoalojado

Observação

Para adicionar ou gerir um SHIR no Microsoft Purview, precisará de permissões de administrador da origem de dados no Microsoft Purview.

  1. Na home page do portal de governação do Microsoft Purview, selecione Mapa de Dados no painel de navegação esquerdo.

  2. Em Origens e análise no painel esquerdo, selecione Runtimes de integração e, em seguida, selecione + Novo.

    Selecione ir.

  3. Na página Configuração do runtime de integração , selecione Autoalojado para criar um IR autoalojado e, em seguida, selecione Continuar.

    Crie um novo SHIR.

  4. Introduza um nome para o IR e selecione Criar.

  5. Na página de definições Integration Runtime, siga os passos na secção Configuração manual. Terá de transferir o runtime de integração do site de transferência para uma VM ou máquina onde pretende executá-lo.

    obter chave

    • Copie e cole a chave de autenticação.

    • Transfira o runtime de integração autoalojado a partir de Microsoft Integration Runtime num computador Windows local. Execute o instalador. São suportadas versões do runtime de integração autoalojado, como 5.4.7803.1 e 5.6.7795.1.

    • Na página Registar Integration Runtime (auto-hospedado), cole uma das duas chaves que guardou anteriormente e selecione Registar.

      chave de entrada.

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

  6. Depois de o Runtime de integração autoalojado ser registado com êxito, verá a seguinte janela:

    registado com êxito.

Pode registar vários nós para um runtime de integração autoalojado com a mesma chave. Saiba mais em Elevada disponibilidade e escalabilidade.

Gerir um runtime de integração autoalojado

Pode editar um runtime de integração autoalojado ao navegar para Runtimes de integração no portal de governação do Microsoft Purview, pairar o cursor sobre o IR e, em seguida, selecionar o botão Editar .

editar detalhes do IR.

Pode eliminar um runtime de integração autoalojado ao navegar para Runtimes de integração, pairar o cursor sobre o IR e, em seguida, selecionar o botão Eliminar .

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

Se mover o cursor sobre o ícone ou mensagem na área de notificação, pode ver detalhes sobre o estado do runtime de integração autoalojado.

Notificações na área de notificação

Conta de serviço do Runtime de integração autoalojado

A conta de serviço de início de sessão predefinida do runtime de integração autoalojado é NT SERVICE\DIAHostService. Pode vê-lo em Serviços –> Serviço Integration Runtime –> Propriedades –> Iniciar sessão.

Conta de serviço para o runtime de integração autoalojado

Certifique-se de que a conta tem a permissão iniciar sessão como um serviço. Caso contrário, o runtime de integração autoalojado não pode ser iniciado com êxito. Pode marcar a permissão na Política de Segurança Local –> Definições de Segurança –> Políticas Locais –> Atribuição de Direitos de Utilizador –> Iniciar sessão como um serviço

Captura de ecrã da Política de Segurança Local – Atribuição de Direitos de Utilizador

Captura de ecrã a mostrar a atribuição de direitos de utilizador iniciar sessão como um serviço

Elevada disponibilidade e escalabilidade

Pode associar um runtime de integração autoalojado a várias máquinas virtuais ou máquinas virtuais no local no Azure. Estas máquinas são denominadas nós. Pode ter até quatro nós associados a um runtime de integração autoalojado. As vantagens de ter vários nós são:

  • Maior disponibilidade do runtime de integração autoalojado para que deixe de ser o ponto único de falha da análise. Esta disponibilidade ajuda a garantir a continuidade quando utiliza até quatro nós.
  • Execute mais análises simultâneas. Cada runtime de integração autoalojado pode capacitar muitas execuções de análise ao mesmo tempo, determinadas automaticamente com base na CPU/memória do computador. Pode instalar mais nós se precisar de mais simultaneidade.
  • Ao analisar origens como o Blob do Azure, Azure Data Lake Storage Gen1, Azure Data Lake Storage Gen2 e Arquivos do Azure, cada execução de análise pode tirar partido de todos esses nós para aumentar o desempenho da análise. Para outras origens, a análise será executada num dos nós.

Pode associar vários nós ao instalar o software de runtime de integração autoalojado a partir do Centro de Transferências. Em seguida, registe-a com a mesma chave de autenticação.

Observação

Antes de adicionar outro nó para elevada disponibilidade e escalabilidade, certifique-se de que a opção Acesso remoto à intranet está ativada no primeiro nó. Para tal, selecione Microsoft Integration Runtime Configuration Manager>Definições>Acesso remoto à intranet.

Requisitos de rede

O seu computador de runtime de integração autoalojado tem de se ligar a vários recursos para funcionar corretamente:

  • Os serviços do Microsoft Purview utilizados para gerir o runtime de integração autoalojado.
  • As origens de dados que pretende analisar com o runtime de integração autoalojado.
  • Se a sua conta tiver sido criada antes de 15 de dezembro de 2023, o runtime de integração tem de conseguir ligar-se à conta de armazenamento gerida criada pelo Microsoft Purview. Se a sua conta for criada após esta data (ou implementada com a versão 2023-05-01-preview da API), é utilizada uma conta de armazenamento de ingestão. O Microsoft Purview utiliza este recurso para ingerir os resultados da análise, entre muitas outras coisas.

Existem duas firewalls a considerar:

  • A firewall empresarial que é executada no router central da organização
  • A Firewall do Windows configurada como um daemon no computador local onde o runtime de integração autoalojado está instalado

Eis os domínios e as portas de saída que tem de permitir nas firewalls empresariais e do Windows/computador.

Dica

  • Para domínios listados com "<managed_storage_account>", adicione o nome dos recursos geridos associados à sua conta do Microsoft Purview. Pode encontrá-los em portal do Azure -> a sua conta do Microsoft Purview ->Definições -> separador Recursos geridos.
  • Se a sua conta não tiver uma conta de armazenamento gerida, está a utilizar o armazenamento de ingestão. Veja os domínios com "<ingestion_storage_account>" na tabela abaixo. Pode encontrar as informações de armazenamento de portal do Azure ->Properties ->ID de armazenamento de ingestão. Para marcar os detalhes do ponto final, aceda à propriedade Descrição geral ->Vista JSON –> "primaryEndpoint".
Nomes de domínio Portas de saída Descrição
Cloud pública: *.frontend.clouddatahub.net
Azure Governamental:*.frontend.datamovement.azure.us
China: *.frontend.datamovement.azure.cn		 443 Necessário para ligar ao serviço Microsoft Purview. Atualmente, é necessário um caráter universal, uma vez que não existe nenhum recurso dedicado.
Cloud pública: *.servicebus.windows.net
Azure Governamental:*.servicebus.usgovcloudapi.net
China: *.servicebus.chinacloudapi.cn		 443 Necessário para configurar a análise no portal de governação do Microsoft Purview. Este ponto final é utilizado para a criação interativa da IU, por exemplo, ligação de teste, lista de pastas de procura e lista de tabelas para análise de âmbito. Para evitar utilizar carateres universais, veja Obter URL do Reencaminhamento do Azure.
Cloud pública: <tenantId>-api.purview-service.microsoft.com
Azure Governamental:<tenantId>-api.purview-service.microsoft.us
China: <tenantId>-api.purview-service.microsoft.cn		 443 Necessário para ligar ao serviço Microsoft Purview. Se utilizar Pontos Finais Privados do Purview, este ponto final é abrangido pelo ponto final privado da plataforma.
Cloud pública: <purview_account>.purview.azure.com
Azure Governamental:<purview-account>.purview.azure.us
China: <purview_account>.purview.azure.cn		 443 Necessário para ligar ao serviço Microsoft Purview. Se utilizar Pontos Finais Privados do Purview, este ponto final é abrangido pelo ponto final privado da conta.
Cloud pública: <managed_storage_account>.blob.core.windows.net ou <ingestion_storage_account>.*.blob.storage.azure.net
Azure Governamental: <managed_storage_account>. blob.core.usgovcloudapi.net ou<ingestion_storage_account>. blob.core.usgovcloudapi.net
China: <managed_storage_account>.blob.core.chinacloudapi.cnou <ingestion_storage_account>.blob.core.chinacloudapi.cn		 443 Necessário para ligar à conta de armazenamento de Blobs do Azure gerida pelo Microsoft Purview. Se utilizar Pontos Finais Privados do Purview, este ponto final é abrangido pelo ponto final privado de ingestão.
Cloud pública: <managed_storage_account>.queue.core.windows.net ou <ingestion_storage_account>.*.queue.storage.azure.net
Azure Governamental: <managed_storage_account>. queue.core.usgovcloudapi.net ou<ingestion_storage_account>. queue.core.usgovcloudapi.net
China: <managed_storage_account>.queue.core.chinacloudapi.cnou <ingestion_storage_account>.queue.core.chinacloudapi.cn		 443 Necessário para ligar à conta de armazenamento de Filas do Azure gerida pelo Microsoft Purview. Se utilizar Pontos Finais Privados do Purview, este ponto final é abrangido pelo ponto final privado de ingestão.
download.microsoft.com 443 Necessário para transferir as atualizações do runtime de integração autoalojado. Se tiver desativado a atualização automática, pode ignorar a configuração deste domínio.
Cloud pública: login.windows.net e login.microsoftonline.com
Azure Governamental:login.microsoftonline.us
China: login.partner.microsoftonline.cn		 443 Necessário para iniciar sessão no Microsoft Entra ID.

Observação

Uma vez que atualmente o Azure Relay não suporta a etiqueta de serviço, tem de utilizar a etiqueta de serviço AzureCloud ou Internet nas regras do NSG para a comunicação com o Reencaminhamento do Azure.

Consoante as origens que pretende analisar, também tem de permitir outros domínios e portas de saída para outras origens do Azure ou externas. São fornecidos alguns exemplos aqui:

Nomes de domínio Portas de saída Descrição
<your_storage_account>.dfs.core.windows.net 443 Ao analisar o Azure Data Lake Store Gen2.
<your_storage_account>.blob.core.windows.net 443 Ao analisar o armazenamento de Blobs do Azure.
<your_sql_server>.database.windows.net 1433 Ao analisar SQL do Azure Base de Dados.
*.powerbi.com e *.analysis.windows.net 443 Ao analisar o inquilino do Power BI.
<your_ADLS_account>.azuredatalakestore.net 443 Ao analisar o Azure Data Lake Store Gen1.
Vários domínios Dependente Domínios e portas para quaisquer outras origens que o SHIR irá analisar.

Para alguns arquivos de dados na cloud, como a Base de Dados do SQL do Azure e o Armazenamento do Azure, poderá ter de permitir o endereço IP do computador de runtime de integração autoalojado na configuração da firewall ou pode criar um ponto final privado do serviço na rede do runtime de integração autoalojado.

Importante

Na maioria dos ambientes, também terá de se certificar de que o DNS está configurado corretamente. Para confirmar, pode utilizar o nslookup do seu computador SHIR para marcar conectividade a cada um dos domínios. Cada nslookup deve devolver o IP do recurso. Se estiver a utilizar Pontos Finais Privados, o IP privado deve ser devolvido e não o IP Público. Se não for devolvido nenhum IP ou se, ao utilizar Pontos Finais Privados, o IP público for devolvido, terá de abordar a associação DNS/VNet ou o Ponto Final Privado/VNet peering.

Obter o URL do Reencaminhamento do Azure

Um domínio e porta necessários que têm de ser colocados na lista de permissões da firewall destina-se à comunicação com o Reencaminhamento do Azure. O runtime de integração autoalojado utiliza-o para criação interativa, como a ligação de teste e a lista de pastas/tabelas de procura. Se não quiser permitir o .servicebus.windows.net e quiser ter URLs mais específicos, pode ver todos os FQDNs necessários para o runtime de integração autoalojado. Siga estas etapas:

  1. Aceda ao portal de governação do Microsoft Purview –> Mapa de dados –> Runtimes de integração e edite o runtime de integração autoalojado.

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

  3. Selecione Ver URLs do Serviço para obter todos os FQDNs.

    Captura de ecrã que mostra como obter URLs do Azure Relay para um runtime de integração.

  4. Pode adicionar estes FQDNs na lista de permissões de regras de firewall.

Observação

Para obter os detalhes relacionados com o protocolo de ligações de Reencaminhamento do Azure, veja Protocolo de Connections Híbrido do Azure Relay.

Considerações sobre o servidor proxy

Se o seu ambiente de rede empresarial utilizar um servidor proxy para aceder à Internet, configure o runtime de integração autoalojado para utilizar as definições de proxy adequadas. Pode definir o proxy durante a fase de registo inicial ou depois de estar registado.

Especificar o proxy

Quando configurado, o runtime de integração autoalojado utiliza o servidor proxy para ligar aos serviços que utilizam o protocolo HTTP ou HTTPS. É por este motivo que seleciona Alterar ligação durante a configuração inicial.

Definir o proxy

Existem duas opções de configuração suportadas pelo Microsoft Purview:

  • Não utilize o proxy: o runtime de integração autoalojado não utiliza explicitamente nenhum proxy para ligar a serviços cloud.
  • Utilizar o proxy do sistema: o runtime de integração autoalojado utiliza a definição de proxy configurada nos ficheiros de configuração do executável. Se não for especificado nenhum proxy nestes ficheiros, o runtime de integração autoalojado liga-se diretamente aos serviços sem passar por um proxy.
  • Utilizar o proxy personalizado: configure a definição de proxy HTTP a utilizar para o runtime de integração autoalojado, em vez de utilizar configurações no diahost.exe.config e diawp.exe.config. Os valores de Endereço e Porta são necessários. Os valores Nome de Utilizador e Palavra-passe são opcionais, consoante a definição de autenticação do proxy. Todas as definições são encriptadas com a DPAPI do Windows no runtime de integração autoalojado e armazenadas localmente no computador.

Observação

A ligação a origens de dados através de proxy não é suportada para conectores além das origens de dados do Azure e do Power BI.

O serviço anfitrião do runtime de integração é reiniciado automaticamente depois de guardar as definições de proxy atualizadas.

Depois de registar o runtime de integração autoalojado, se quiser ver ou atualizar as definições de proxy, utilize Microsoft Integration Runtime Configuration Manager.

  1. Abra Microsoft Integration Runtime Configuration Manager.
  2. Selecione a guia Configurações.
  3. Em Proxy HTTP, selecione a ligação Alterar para abrir a caixa de diálogo Definir Proxy HTTP .
  4. Selecione Avançar. Em seguida, verá um aviso que pede a sua permissão para guardar a definição de proxy e reiniciar o serviço de anfitrião do runtime de integração.

Observação

Se configurar um servidor proxy com autenticação NTLM, o serviço de anfitrião do runtime de integração é executado na conta de domínio. Se alterar posteriormente a palavra-passe da conta de domínio, lembre-se de atualizar as definições de configuração do serviço e reiniciar o serviço. Devido a este requisito, sugerimos que aceda ao servidor proxy através de uma conta de domínio dedicada que não exija que atualize a palavra-passe com frequência.

Se estiver a utilizar o proxy do sistema, certifique-se de que o servidor proxy permite o tráfego de saída para as regras de rede.

Definir as configurações do servidor proxy

Se selecionar a opção Utilizar proxy de sistema para o proxy HTTP, o runtime de integração autoalojado utiliza as definições de proxy nos quatro ficheiros seguintes no caminho C:\Programas\Microsoft Integration Runtime\5.0\ para realizar 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 não é especificado nenhum proxy nestes ficheiros, o runtime de integração autoalojado liga-se diretamente aos serviços sem passar por um proxy.

O procedimento seguinte fornece instruções para atualizar o ficheiro diahost.exe.config .

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

  2. Abra o Bloco de notas em execução como administrador.

  3. No Bloco de Notas, abra o ficheiro de texto C:\Programas\Microsoft Integration Runtime\5.0\Shared\diahost.exe.config.

  4. Localize a etiqueta de system.net predefinida, conforme mostrado no seguinte código:

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

    Em seguida, pode adicionar detalhes do servidor proxy, conforme mostrado no exemplo seguinte:

    <system.net>
  <defaultProxy>
    <proxy bypassonlocal="true" proxyaddress="<your proxy server e.g. http://proxy.domain.org:8888/>" />
  </defaultProxy>
</system.net>

    A etiqueta proxy permite que outras propriedades especifiquem as definições necessárias, como scriptLocation. Veja <Elemento proxy> (Definições de Rede) para obter sintaxe.

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

  5. Guarde o ficheiro de configuração na localização original.

Repita o mesmo procedimento para atualizar diawp.exe.config e Microsoft.DataMap.Agent.exe.config ficheiros.

Em seguida, aceda ao caminho C:\Program Files\Microsoft Integration Runtime\5.0\Gateway\DataScan\DataTransfer, crie um ficheiro com o nome "Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config" e configure a definição de proxy da seguinte forma. Também pode expandir as definiçõ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 tem de ser excluído do proxy, por exemplo, se a sua conta do Microsoft Purview estiver protegida por pontos finais privados. Nestes casos, atualize os quatro ficheiros seguintes no caminho para incluir a lista de ignorar C:\Programas\Microsoft Integration Runtime\5.0\ com a lista de ignorar 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 para ignorar a lista para analisar uma Base de Dados do SQL do Azure e o Armazenamento do ADLS gen2:

 <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 anfitrião do runtime de integração autoalojado, que recolhe as alterações. Para reiniciar o serviço, utilize os serviços a partir de Painel de Controle. Em alternativa, em 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, é provável que tenha adicionado sintaxe de etiqueta XML incorreta no ficheiro de configuração da aplicação que editou.

Importante

Não se esqueça de atualizar os quatro ficheiros mencionados acima.

Também tem de se certificar de que o Microsoft Azure está na lista de permissões da sua empresa. Pode transferir a lista de endereços IP válidos do Azure. Os intervalos de IP para cada cloud, divididos por região e pelos serviços etiquetados nessa cloud, estão agora disponíveis no MS Download:

Se vir mensagens de erro como as seguintes, o motivo provável é uma configuração incorreta da firewall ou do servidor proxy. Esta configuração impede que o runtime de integração autoalojado se ligue aos serviços do Microsoft Purview. Para garantir que a firewall e o servidor proxy estão configurados corretamente, veja a secção anterior.

  • Quando tenta registar o runtime de integração autoalojado, recebe a seguinte mensagem de erro: "Falha ao registar este Integration Runtime nó! Confirme que a Chave de autenticação é válida e que o serviço de anfitrião do serviço de integração está em execução neste computador."

  • Quando abre Integration Runtime Configuration Manager, vê uma status de Desligado ou Ligar. Quando vê os registos de eventos do Windows, em Visualizador de Eventos>Aplicação e Registos de Serviços>Microsoft Integration Runtime, verá 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 Ambiente de Runtime java

Se analisar ficheiros Parquet com o runtime de integração autoalojado com o Microsoft Purview, terá de instalar o Ambiente de Runtime java ou o OpenJDK no seu computador de IR autoalojado.

Ao analisar ficheiros Parquet com o IR autoalojado, o serviço localiza o runtime java ao verificar primeiro o registo (HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\{Current Version}\JavaHome) de JRE, se não for encontrado, verificando em segundo lugar a variável JAVA_HOME do sistema para OpenJDK. Pode definir JAVA_HOME em Definições do Sistema, Variáveis de Ambiente no seu computador. Crie ou edite a variável JAVA_HOME para apontar para o java jre no seu computador. Por exemplo: C:\Program Files\Java\jdk1.8\jre

  • Para utilizar JRE: o IR de 64 bits requer JRE de 64 bits. Pode encontrá-lo a partir daqui.
  • Para utilizar o OpenJDK: é suportado desde a versão 3.13 do IR. Empacote o jvm.dll com todas as outras assemblagens necessárias do OpenJDK no computador DE IR autoalojado e defina a variável de ambiente do sistema JAVA_HOME em conformidade.

Como marcar a versão do runtime de integração autoalojado

Pode marcar a versão do runtime de integração autoalojado no portal de governação do Microsoft Purview –> Mapa de dados –> Runtimes de integração:

Captura de ecrã a mostrar a versão no portal de governação do Microsoft Purview.

Também pode marcar a versão no seu cliente de runtime de integração autoalojado – separador> Ajuda.

Atualização automática de Integration Runtime autoalojado

A atualização automática está ativada por predefinição quando instala um runtime de integração autoalojado. Tem duas opções para gerir a versão do runtime de integração autoalojado: atualizar automaticamente ou manter manualmente. Normalmente, o Microsoft Purview lança duas novas versões do runtime de integração autoalojado todos os meses, o que inclui o lançamento de novas funcionalidades, correção de erros ou melhoria. Por isso, recomendamos que os utilizadores atualizem para a versão mais recente para obterem a funcionalidade e o melhoramento mais recentes.

O runtime de integração autoalojado é atualizado automaticamente para uma versão mais recente. Quando a nova versão estiver disponível ainda não agendada para a sua instância, também pode acionar a atualização a partir do portal.

Captura de ecrã a mostrar a verificação da versão do runtime de integração autoalojado e a atualização do acionador.

Observação

Se tiver vários nós do runtime de integração autoalojado, não haverá tempo de inatividade durante a atualização automática. A atualização automática ocorre primeiro num nó enquanto outros estão a trabalhar em tarefas. Quando o primeiro nó concluir a atualização, assumirá as tarefas restantes quando outros nós estiverem a atualizar. Se tiver apenas um nó de runtime de integração autoalojado, terá algum tempo de inatividade durante a atualização automática.

Atualização automática da versão vs. versão mais recente

Para garantir a estabilidade do runtime de integração autoalojado, apesar de lançarmos duas versões, só emitamos uma versão todos os meses. Por isso, por vezes, descobre que a versão de atualização automática é a versão anterior da versão mais recente. Se quiser obter a versão mais recente, pode aceder ao centro de transferências e fazê-lo manualmente. Além disso, a atualização automática para uma nova versão é gerida pelo serviço e não pode alterá-la.

O separador Versão do runtime de integração autoalojado no portal de governação do Microsoft Purview mostra a versão mais recente se a versão atual for antiga. Quando o runtime de integração autoalojado está online, esta versão é a versão de atualização automática e atualiza automaticamente o runtime de integração autoalojado na hora agendada. No entanto, se o runtime de integração autoalojado estiver offline, a página só mostra a versão mais recente.

Se tiver vários nós e por alguns motivos, alguns deles não serão atualizados automaticamente com êxito. Em seguida, estes nós revertem para a versão, que era a mesma em todos os nós antes da atualização automática.

Expiração do Integration Runtime autoalojado

Cada versão do runtime de integração autoalojado expira dentro de um ano. A mensagem a expirar é apresentada no portal de governação do Microsoft Purview e no cliente de runtime de integração autoalojado 90 dias antes da expiração.

Próximas etapas