Solução de problemas do runtime de integração auto-hospedada

APLICA-SE A: Azure Data Factory Azure Synapse Analytics Microsoft Purview

Este artigo explora métodos comuns de solução de problemas para IR (runtime de integração auto-hospedada) em workspaces do Azure Data Factory e do Synapse.

Reunir logs do IR auto-hospedado

Azure Data Factory e Azure Synapse Analytics

Para atividades com falha executadas em um IR auto-hospedado ou IR compartilhado, o serviço dá suporte à exibição e ao carregamento de logs de erro. Para obter a ID do relatório de erros, siga estas instruções e, em seguida, insira a ID do relatório para pesquisar os problemas conhecidos relacionados.

1. Na página Monitor da interface do usuário do serviço, selecione Execução de pipeline.

2. Em Execuções de atividade, na coluna Erro, selecione o botão realçado para exibir os logs de atividade, conforme mostrado na captura de tela a seguir:

   • Fábrica de dados do Azure
   • Azure Synapse

   

   Os logs de atividade são exibidos para a execução da atividade com falha.

   

3. Para obter mais assistência, selecione Enviar logs.

   A janela Compartilhar os logs do IR (runtime de integração) auto-hospedado com a Microsoft é aberta.

   Screenshot da "janela Compartilhar os logs de IR (integration runtime) auto-hospedados com a Microsoft".

4. Selecione os logs que você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar os logs relacionados à atividade com falha ou todos os logs no nó de IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente os logs relacionados à atividade com falha.

5. Quando os logs forem carregados, mantenha um registro da ID do relatório para uso posterior, se precisar de assistência adicional para resolver o problema.

   

Microsoft Purview

Para atividades do Microsoft Purview com falha executadas em um IR auto-hospedado ou IR compartilhado, o serviço dá suporte à exibição e ao carregamento de logs de erro a partir do Visualizador de Eventos do Windows.

Você pode pesquisar todos os erros que ver no guia de erros abaixo. Para obter diretrizes de suporte e solução de problemas para problemas de SHIR, talvez seja necessário gerar uma ID de relatório de erro e entrar em Microsoft suporte.

Para gerar a ID do relatório de erros para Microsoft Support, siga estas instruções:

1. Antes de iniciar uma verificação no portal de governança do Microsoft Purview:

   1. Navegue até o computador em que o runtime de integração auto-hospedada está instalado e abra o Windows Event Viewer.
   2. Limpe os logs do Windows Event Viewer na seção Integration Runtime. Clique com o botão direito do mouse nos logs e selecione a opção limpar logs.
   3. Navegue de volta para o portal de governança do Microsoft Purview e inicie a verificação.

2. Depois que a verificação mostrar o status Failed, retorne à VM SHIR ou ao computador e atualize o visualizador de eventos na seção Integration Runtime.

3. Os logs de atividade são exibidos para a execução da atividade com falha.

4. Para obter mais assistência de Microsoft, selecione Send Logs.

   A janela Compartilhar os logs do SHIR (self-hosted integration runtime) com a Microsoft é aberta.

   

5. Selecione os logs que você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar os logs relacionados à atividade com falha ou todos os logs no nó de IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente os logs relacionados à atividade com falha.

6. Quando os logs forem carregados, mantenha um registro da ID do relatório para uso posterior, se precisar de assistência adicional para resolver o problema.

   

Erro ou falha geral de IR auto-hospedado

Problema de memória insuficiente

• Sintomas

  Um erro OOM (OutOfMemoryexception) ocorre quando você tenta executar uma atividade de pesquisa com um IR vinculado ou um IR auto-hospedado.

• Causa

  Uma nova atividade pode gerar um erro OOM, se o computador de IR apresentar alta utilização da memória momentânea. O problema pode ser causado por um grande volume de atividades simultâneas e o erro ocorre por design.

• Resolução

  Verifique a utilização de recursos e a execução de atividades simultâneas no nó de IR. Ajuste o tempo interno e de gatilho das execuções de atividade para evitar o excesso de execução em um único nó de IR ao mesmo tempo.

Problema de limite de tarefas concorrentes

• Sintomas

  Quando você tenta aumentar o limite de trabalhos simultâneos na interface do usuário, o processo fica preso no status Atualizando.

  Cenário de exemplo: no momento, o valor máximo de trabalhos simultâneos está definido como 24 e você deseja aumentar a contagem para que os trabalhos possam ser executados com mais rapidez. O valor mínimo que você pode inserir é 3, e o valor máximo é 32. Você aumenta o valor de 24 para 32 e, em seguida, seleciona o botão Atualizar. O processo fica paralisado no status Atualização, conforme mostrado na captura de tela a seguir. Você atualiza a página e o valor ainda é exibido como 24. Não foi atualizado para 32, como esperado.

  

• Causa

  O limite do número de trabalhos simultâneos depende do núcleo de lógica do computador e da memória. Tente diminuir o valor para 24, por exemplo, e depois exiba o resultado.

  Dica

  • Para saber mais sobre a contagem de núcleos lógicos e determinar a contagem de núcleos lógicos do computador, consulte 4 maneiras de localizar o número de núcleos em sua CPU em Windows 10.
  • Para saber como calcular o math.log, acesse a Calculadora do logaritmo.

Problema de certificado SSL de HA (alta disponibilidade) do IR auto-hospedado

• Sintomas

  O nó de trabalho de IR auto-hospedado relatou o erro a seguir:

  "Falha ao efetuar pull de estados compartilhados no nó primário net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID da atividade: XXXXX A compilação da cadeia do certificado X.509 CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft falhou. O certificado usado tem uma cadeia de confiança que não pode ser verificada. Substitua o certificado ou altere o certificateValidationMode. A função de revogação não pôde verificar a revogação porque o servidor de revogação estava offline."

• Causa

  Quando você lida com casos relacionados ao handshake SSL/TLS, pode encontrar alguns problemas relacionados à verificação da cadeia de certificados.

• Resolução

  • Esta é uma maneira rápida e intuitiva de solucionar problemas de falha de compilação da cadeia de certificados X.509:

    1. Exporte o certificado que precisa ser verificado. Para fazer isso, faça o seguinte:

       um. Em Windows, selecione Start, comece a digitar certificates e, em seguida, selecione Manage computer certificates.

       b. No Explorador de Arquivos, no painel esquerdo, pesquise o certificado que você deseja verificar, clique nele com o botão direito do mouse e selecione Todas as tarefas>Exportar.

       

    2. Copie o certificado exportado para o computador cliente.

    3. No lado do cliente, em uma janela do prompt de comando, execute o comando a seguir. Substitua o <caminho do certificado> e o <caminho do arquivo txt de saída> pelos caminhos reais.

       Certutil -verify -urlfetch    <certificate path>   >     <output txt file path> 
       

       Por exemplo:

       Certutil -verify -urlfetch c:\users\test\desktop\servercert02.cer > c:\users\test\desktop\Certinfo.txt
       

    4. Verifique se há erros no arquivo txt de saída. Você pode encontrar o resumo de erros no final do arquivo txt.

       Por exemplo:

       

       Se você não observar um erro no final do arquivo de log, conforme mostrado na captura de tela a seguir, pode considerar que a cadeia de certificados foi criada com êxito no computador cliente.

       

  • Se uma extensão de nome de arquivo AIA (Acesso a Informações de Autoridade), CDP (Ponto de Distribuição de CRL) ou OCSP (Protocolo de Status de Certificado Online) foi configurada no arquivo de certificado, você pode verificá-la de maneira mais intuitiva:

    1. Obtenha essas informações verificando os detalhes do certificado, conforme mostrado na captura de tela a seguir:

       

    2. Execute o comando a seguir. Certifique-se de substituir o <caminho do certificado> pelo caminho correto do certificado.

         Certutil   -URL    <certificate path> 
       

       A ferramenta Recuperação de URL será aberta.

    3. Para verificar os certificados com as extensões de nome de arquivo AIA, CDP e OCSP, selecione Recuperar.

       

       Você compilou a cadeia de certificados com êxito, se o status do certificado em AIA for Verificado e o status do certificado em CDP ou OCSP for Verificado.

       Se você falhar ao tentar recuperar AIA ou CDP, trabalhe com a equipe de rede para preparar o computador cliente para se conectar à URL de destino. Será suficiente se for possível verificar o caminho HTTP ou LDAP (Lightweight Directory Access Protocol).

O IR auto-hospedado não conseguiu carregar o arquivo ou assembly

• Sintomas

  Você recebe a seguinte mensagem de erro:

  "Não foi possível carregar o arquivo ou assembly 'XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. ID da atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

  Veja abaixo uma mensagem de erro mais específica:

  "Não foi possível carregar o arquivo ou assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. ID da atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

• Causa

  No Process Monitor, você pode exibir o seguinte resultado:

  

  Dica

  No Process Monitor, você pode definir filtros, conforme mostrado na captura de tela a seguir.

  A mensagem de erro anterior diz que o DLL System.ValueTuple não está localizado na pasta Global Assembly Cache (GAC) relacionada, na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway ou na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Shared pasta.

  Basicamente, o processo carrega a DLL primeiro na pasta GAC, depois na pasta Compartilhada e, por fim, na pasta Gateway. Portanto, você pode carregar a DLL em qualquer caminho útil.

  

• Resolução

  Você encontrará o arquivo System.ValueTuple.dll na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Para resolver o problema, copie o arquivo System.ValueTuple.dll para a pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

  Você pode usar o mesmo método para resolver outros problemas de arquivo ou assembly ausente.

• Mais informações sobre este problema

  O motivo pelo qual você vê o System.ValueTuple.dll em %windir%\Microsoft.NET\assembly e %windir%\assembly é que esse é um comportamento .NET.

  No erro a seguir, você pode ver claramente que o assembly System.ValueTuple está ausente. Esse problema ocorre quando o aplicativo tenta verificar o assembly System.ValueTuple.dll.

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"O inicializador de tipo para 'Npgsql.PoolManager' lançou uma exceção.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Não foi possível carregar o arquivo ou o assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma de suas dependências." O sistema não consegue localizar o ficheiro especificado.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

  Para obter mais informações sobre o Cache de Assembly Global (GAC), consulte Cache de Assembly Global.

A chave de autenticação do runtime de integração auto-hospedada está ausente

• Sintomas

  De repente, o runtime de integração auto-hospedada fica offline, sem uma Chave de Autenticação, e o Log de Eventos exibe a seguinte mensagem de erro:

  "A Chave de Autenticação ainda não foi atribuída"

  

• Causa

  • O nó de IR auto-hospedado ou o IR auto-hospedado lógico no portal do Azure foi excluído.
  • Foi realizada uma desinstalação limpa.

• Resolução

  Se nenhuma das causas anteriores se aplicar, você poderá acessar a pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o arquivo Configurations foi excluído. Se ele tiver sido excluído, siga as instruções no artigo do Netwrix Detecte quem excluiu um arquivo nos seus servidores de arquivos Windows.

  

Não é possível usar o IR auto-hospedado para unir dois armazenamentos de dados locais

• Sintomas

  Depois de criar IRs auto-hospedados para os armazenamentos de dados de origem e de destino, é necessário conectar os dois IRs para concluir uma atividade de cópia. Se os armazenamentos de dados foram configurados em redes virtuais diferentes ou se os armazenamentos de dados não conseguirem entender o mecanismo de gateway, você receberá um dos seguintes erros:

  • O driver de origem não pode ser encontrado no IR de destino.
  • "A origem não pode ser acessada pelo IR de destino"

• Causa

  O IR autogerenciado é projetado como um nó central de uma atividade de cópia de dados, não como um agente cliente que precisa ser instalado para cada repositório de dados.

  Nesse caso, você deve criar o serviço vinculado para cada armazenamento de dados com o mesmo IR, e o IR deve ser capaz de acessar ambos os armazenamentos de dados através da rede. Não importa se o IR foi instalado no armazenamento de dados de origem, no armazenamento de dados de destino ou em um terceiro computador. Se dois serviços vinculados forem criados com IRs diferentes, mas forem usados na mesma atividade de Cópia, o IR de destino será utilizado, e será necessário instalar os drivers para ambos os datastores na máquina do IR de destino.

• Resolução

  Instale os drivers para os armazenamentos de dados de origem e de destino no IR de destino e verifique se ele pode acessar o armazenamento de dados de origem.

  Se o tráfego não puder passar pela rede entre dois armazenamentos de dados (por exemplo, se eles estiverem configurados em duas redes virtuais), você pode não concluir a cópia em uma atividade, mesmo com o IR instalado. Se não for possível concluir a cópia em uma única atividade, você pode criar duas atividades Copy com dois IRs, cada uma em uma VNET:

  • Copiar um IR do armazenamento de dados 1 para o Azure Blob Storage
  • Copiar outro IR do Azure Blob Storage para o datastore 2.

  Essa solução poderia simular a necessidade de usar o IR para criar uma ponte que conecta dois armazenamentos de dados desconectados.

O problema de sincronização de credenciais causa a perda de credenciais na HA

• Sintomas

  Se a credencial da fonte de dados "XXXXXXXXXX" for excluída do nó atual de runtime de integração com carga útil, você receberá a seguinte mensagem de erro:

  "Quando você excluir o serviço de link no portal Azure ou a tarefa tiver o conteúdo errado, crie um novo serviço de link com sua credencial novamente."

• Causa

  O IR auto-hospedado é criado no modo de HA com dois nós, mas os nós não estão no estado de sincronização de credenciais. Isso significa que as credenciais armazenadas no nó de dispatcher não são sincronizadas com outros nós de trabalho. Se ocorrer um failover do nó de dispatcher para o nó de trabalho e as credenciais existirem apenas no nó de dispatcher anterior, a tarefa falhará quando você tentar acessar as credenciais e você receberá o erro anterior.

• Resolução

  A única maneira de evitar esse problema é verificar se dois nós estão no estado de sincronização de credenciais. Se eles não estiverem sincronizados, você precisará reinserir as credenciais para o novo dispatcher.

Não é possível escolher o certificado porque a chave privada está ausente

• Sintomas

  • Você importou um arquivo PFX para o repositório de certificados.

  • Ao selecionar o certificado por meio da interface do usuário do IR Configuration Manager, você recebeu a seguinte mensagem de erro:

    "Falha ao alterar o modo de criptografia de comunicação da intranet. Provavelmente, o certificado '<nome do certificado>' não tem uma chave privada que possa trocar de chave ou o processo pode não ter direitos de acesso para a chave privada. Confira a exceção interna para obter detalhes.""

• Causa

  • A conta de usuário tem um nível de baixo privilégio e não pode acessar a chave privada.
  • O certificado foi gerado como assinatura, mas não como troca de chaves.

• Resolução

  • Para operar a interface do usuário, use uma conta com privilégios apropriados para acessar a chave privada.

  • Importe o certificado executando o seguinte comando:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Problema de falta de sincronização dos nós do runtime de integração auto-hospedada

• Sintomas

  Os nós de runtime de integração auto-hospedada tentam sincronizar as credenciais entre os nós, mas ficam presos no processo e encontram a mensagem de erro abaixo após alguns instantes:

  "O nó do Integration Runtime (auto-hospedado) está tentando sincronizar as credenciais entre os nós. Isso pode levar alguns minutos.”

  Observação

  Se esse erro aparecer por mais de 10 minutos, verifique a conectividade com o nó dispatcher.

• Causa

  O motivo é que os nós de trabalho não têm acesso às chaves privadas. Isso pode ser confirmado a partir dos logs de runtime da integração auto-hospedada mostrados abaixo:

  [14]0460.3404::05/07/21-00:23:32.2107988 [System] A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

  Você não tem nenhum problema com o processo de sincronização ao usar a autenticação de entidade de serviço no serviço vinculado. No entanto, quando você alterna o tipo de autenticação para chave de conta, o problema de sincronização é iniciado. Isso ocorre porque o serviço de runtime de integração auto-hospedada é executado em uma conta de serviço (NT SERVICE\DIAHostService) e precisa ser adicionado às permissões de chave privada.

• Resolução

  Para resolver esse problema, você precisa adicionar a conta de runtime de integração auto-hospedada (NT SERVICE\DIAHostService) às permissões de chave privada. Você pode aplicar as seguintes etapas:

  1. Abra o comando Executar do Microsoft Management Console (MMC).

     

  2. No painel do MMC, aplique as seguintes etapas:

     

     1. Selecione Arquivo.
     2. Escolha Adicionar/Remover Snap-in na lista suspensa.
     3. Selecione Certificados no painel “Snap-ins disponíveis”.
     4. Selecione Adicionar.
     5. No painel pop-up "Snap-in de certificados", escolha Conta de computador.
     6. Selecione Avançar.
     7. No painel “Selecionar Computador”, escolha Computador local: o computador no qual este console está sendo executado.
     8. Selecione Concluir.
     9. Selecione OK no painel "Adicionar ou Remover Snap-ins".

  3. No painel do MMC, siga as etapas a seguir:

     

     1. Na lista de pastas à esquerda, selecione Raiz do Console –> Certificados (Computador Local) –> Pessoal –> Certificados.
     2. Clique com o botão direito do mouse no Microsoft Intune Beta MDM.
     3. Selecione Todas as Tarefas na lista suspensa.
     4. Selecione Gerenciar Chaves Privadas.
     5. Selecione Adicionar em “Nomes de grupo ou de usuário”.
     6. Selecione NT SERVICE\DIAHostService para conceder acesso de controle total a esse certificado, aplicar e proteger.
     7. Selecione Verificar Nomes e, em seguida, OK.
     8. No painel "Permissões", selecione Aplicar e, em seguida, selecione OK.

Mensagem de erro UserErrorJreNotFound ao executar uma atividade de cópia para o Azure

• Sintomas

  Ao tentar copiar conteúdo para Microsoft Azure usando uma ferramenta ou programa baseado em Java (por exemplo, copiando arquivos de formato ORC ou Parquet), você recebe uma mensagem de erro semelhante ao seguinte:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment não foi encontrado. Vá até http://go.microsoft.com/fwlink/?LinkId=808605 para baixar e instalar em seu computador de nó de Integration Runtime (auto-hospedado). Observe que Integration Runtime de 64 bits requer JRE de 64 bits e Integration Runtime de 32 bits requer JRE de 32 bits,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Não foi possível carregar a DLL 'jvm.dll': O módulo especificado não pôde ser encontrado. (Exceção de HRESULT: 0x8007007E), Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

• Causa

  Esse problema ocorre por um dos dois motivos:

  • Java JRE (Ambiente de Runtime) não está instalado corretamente no servidor Integration Runtime.

  • O servidor Integration Runtime não tem a dependência necessária para JRE.

  Por padrão, Integration Runtime resolve o caminho JRE usando entradas do Registro. Essas entradas devem ser definidas automaticamente durante a instalação do JRE.

• Resolução

  Siga as etapas nesta seção com cuidado. Problemas sérios podem ocorrer se você modificar o Registro incorretamente. Antes de modificá-lo, faça backup do Registro para a restauração em caso de problemas.

  Para corrigir esse problema, siga estas etapas para verificar o status da instalação do JRE:

  1. Verifique se Integration Runtime (Diahost.exe) e JRE estão instalados na mesma plataforma. Verifique as seguintes condições:

     • O JRE de 64 bits para o Integration Runtime do ADF de 64 bits deve ser instalado na pasta: C:\Program Files\Java\

       Observação

       A pasta não é C:\Program Files (x86)\Java\

     • Java RUNTIME (JRE) é a versão 11 ou superior, de um provedor JRE como Microsoft OpenJDK 11 ou Eclipse Temurin 11. Certifique-se de que a variável de ambiente do sistema JAVA_HOME esteja definida para a pasta JDK (e não apenas para a pasta JRE); talvez seja necessário adicionar a pasta bin à variável de ambiente PATH do sistema.

  2. Verifique o registro para obter as configurações apropriadas. Para fazer isso, execute estas etapas:

     1. No menu Executar, digite Regedit e pressione ENTER.

     2. No painel de navegação, localize a seguinte subchave:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        No painel Detalhes, deve haver uma entrada de Versão Atual que mostra a versão do JRE (por exemplo, 1.8).

        

     3. No painel de navegação, localize uma subchave que corresponda exatamente à versão (por exemplo, 1.8) na pasta do JRE. No painel de detalhes, deve haver uma entrada JavaHome. O valor dessa entrada é o caminho de instalação do JRE.

        

  3. Localize a pasta bin\server no seguinte caminho:

     C:\Program Files\Java\jre1.8.0_74

     

  4. Verifique se essa pasta contém um arquivo de jvm.dll. Caso contrário, verifique o arquivo na pasta bin\client.

     

  Observação

  • Se essas configurações não forem conforme descrito nestas etapas, use o instalador do JRE do Windows para corrigir os problemas.
  • Se todas as configurações nessas etapas estiverem corretas conforme descrito, pode haver uma biblioteca de runtime VC++ ausente no sistema. Você pode corrigir esse problema instalando o Pacote Redistribuível 2010 do VC++.

Configuração do IR auto-hospedado

Erro de registro do runtime de integração

• Sintomas

  Ocasionalmente, pode ser conveniente executar um IR auto-hospedado em uma conta diferente por qualquer um dos seguintes motivos:

  • A política da empresa proíbe a conta de serviço.
  • Alguma autenticação é necessária.

  Depois de alterar a conta de serviço no painel de serviço, você pode descobrir que o runtime de integração parou de funcionar e irá receber a seguinte mensagem de erro:

  "O nó do Integration Runtime (auto-hospedado) encontrou um erro durante o registro. Não é possível se conectar ao Serviço de Host do Integration Runtime (auto-hospedado)."

  

• Causa

  Muitos recursos são concedidos somente à conta de serviço. Quando você altera a conta de serviço para outra conta, as permissões de todos os recursos dependentes permanecem inalteradas.

• Resolução

  Acesse o log de eventos do runtime de integração para verificar o erro.

  

  • Se o erro no log de eventos for "UnauthorizedAccessException", faça o seguinte:

    1. Verifique a conta de logon do serviço DIAHostService no painel de serviços do Windows.

       

    2. Verifique se a conta de serviço de logon tem permissões de leitura/gravação para a pasta %programdata%\Microsoft\DataTransfer\DataManagementGateway.

       • Por padrão, se a conta de logon do serviço não foi alterada, ela deve ter permissões de leitura/gravação.

         

       • Se você alterou a conta de logon do serviço, atenue o problema fazendo o seguinte:

         um. Realize uma desinstalação limpa do IR auto-hospedado atual.
         b. Instale os bits de IR auto-hospedado.
         c. Altere a conta de serviço fazendo o seguinte:

         i. Vá até a pasta de instalação do IR auto-hospedada e mude para a pasta Microsoft Integration Runtime\4.0\Shared.
         ii. Abra uma janela do prompt de comando usando privilégios elevados. Substitua <user> e <password> por seu próprio nome de usuário e senha e depois execute o seguinte comando:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         III. Se você quiser alterar para a conta LocalSystem, use o formato correto para essa conta: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Não use este formato: dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. Opcionalmente, como o sistema local tem privilégios mais altos do que o administrador, você também pode alterá-lo diretamente em "Serviços".
         .v Você pode usar um usuário de domínio/local para a conta de logon do serviço do IR.

         d. Registrar o runtime de integração.

  • Se o erro for "O serviço 'Serviço de Integration Runtime' (DIAHostService) não foi iniciado. Verifique se você tem privilégios suficientes para iniciar os serviços do sistema" e faça o seguinte:

    1. Verifique a conta de logon do serviço DIAHostService no painel de serviços do Windows.

       

    2. Verifique se a conta de serviço de logon tem permissão Log on as a service para iniciar o serviço Windows:

       

• Mais informações

  Se nenhum dos dois padrões de resolução anteriores se aplicar em seu caso, tente coletar os seguintes logs de eventos Windows:

  • Logs de Aplicativos e Serviços > Integration Runtime
  • Windows Logs > Aplicativo

Não é possível localizar o botão Registrar para registrar um IR auto-hospedado

• Sintomas

  Quando você registra um IR auto-hospedado, o botão Register não é exibido no painel Configuration Manager.

  

• Causa

  A partir da versão do Integration Runtime 3.0, o botão Register em nós integration runtime existentes foi removido para habilitar um ambiente mais limpo e seguro. Se um nó foi registrado em um runtime de integração, seja online ou não, registre-o novamente em outro runtime de integração, desinstalando o nó anterior e, em seguida, instale e registre o nó.

• Resolução

  1. Em Control Panel, desinstale o runtime de integração existente.

     Importante

     No processo a seguir, selecione Sim. Não mantenha os dados durante o processo de desinstalação.

     

  2. Se você não tiver o arquivo MSI do instalador do runtime de integração, acesse o centro de download para baixar o runtime de integração mais recente.

  3. Instale o arquivo MSI e registre o runtime de integração.

Não é possível registrar o IR auto-hospedado devido ao localhost

• Sintomas

  Não é possível registrar o IR auto-hospedado em um novo computador ao usar o get_LoopbackIpOrName.

  Depurar: ocorreu um erro de runtime. O inicializador de tipo para 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' exibiu uma exceção. Ocorreu um erro irrecuperável durante uma pesquisa no banco de dados.

  Detalhe da exceção: System.TypeInitializationException: o inicializador de tipo para 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' gerou uma exceção. >--- System.Net.Sockets.SocketException: ocorreu um erro não recuperável durante uma pesquisa de banco de dados em System.Net.Dns.GetAddrInfo(Nome da cadeia de caracteres).

• Causa

  O problema geralmente ocorre quando o localhost está sendo resolvido.

• Resolução

  Use o endereço IP do localhost 127.0.0.1 para hospedar o arquivo e resolver o problema.

Falha na configuração auto-hospedada

• Sintomas

  Não é possível desinstalar um IR existente, instalar um novo IR ou atualizar um IR existente para um novo IR.

• Causa

  A instalação do integration runtime depende do serviço Windows Installer. Você pode enfrentar problemas de instalação pelos seguintes motivos:

  • Espaço em disco disponível insuficiente.
  • Falta de permissões.
  • O serviço NT Windows está bloqueado.
  • A utilização de CPU está muito alta.
  • O arquivo MSI está hospedado em um local de rede lento.
  • Alguns arquivos do sistema ou registros foram tocados sem querer.

A conta de serviço do IR não buscou acesso ao certificado

• Sintomas

  Quando você instala um IR auto-hospedado por meio de Microsoft Integration Runtime Configuration Manager, um certificado com uma AC (autoridade de certificação) confiável é gerado. Não foi possível aplicar o certificado para criptografar a comunicação entre dois nós e a seguinte mensagem de erro é exibida:

  "Falha ao alterar o modo de criptografia de comunicação da Intranet: falha ao conceder à conta de serviço Integration Runtime o acesso ao certificado '<certificate name>'. Código de erro 103"

• Causa

  O certificado está usando o armazenamento de KSP (provedor de armazenamento de chaves), que ainda não tem suporte. Até o momento, o IR auto-hospedado dá suporte apenas ao armazenamento de CSP (provedor de serviços de criptografia).

• Resolução

  É recomendável que você use certificados de CSP nesse caso.

  Solução 1

  Para importar o certificado, execute o seguinte comando:

  Certutil.exe -CSP "CSP or KSP" -ImportPFX FILENAME.pfx

  

  Solução 2

  Para converter o certificado, execute os seguintes comandos:

  openssl pkcs12 -in .\xxxx.pfx -out .\xxxx_new.pem -password pass: <EnterPassword> openssl pkcs12 -export -in .\xxxx_new.pem -out xxxx_new.pfx

  Antes e depois da conversão:

  

  

Runtime de integração autogerida versão 5.x

Para a atualização para a versão 5.x do runtime de integração auto-hospedada, precisamos de .NET Framework Runtime 4.7.2 ou posterior. Na página de download, você encontrará links de download para a versão 4.x mais recente e as duas versões 5.x mais recentes.

Para clientes Azure Data Factory v2 e Azure Synapse:

• Se a atualização automática estiver ativada e você já tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedada será atualizado automaticamente para a versão mais recente do 5.x.
• Se a atualização automática estiver ativada e você não tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedada não será atualizado automaticamente para a versão mais recente do 5.x. O runtime de integração auto-hospedada permanecerá na versão 4.x atual. Você pode ver um aviso para uma atualização do .NET Framework Runtime no portal e no cliente do runtime de integração auto-hospedada.
• Se a atualização automática estiver desativada e você já tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior, você poderá baixar manualmente o 5.x mais recente e instalá-lo em seu computador.
• Se a atualização automática estiver desativada e você não tiver atualizado seu .NET Framework Runtime para 4.7.2 ou posterior. Ao tentar instalar manualmente o runtime de integração auto-hospedada 5.x e registrar a chave, você precisará atualizar sua versão do .NET Framework Runtime primeiro.

Problemas de conectividade do IR auto-hospedado

O runtime de integração auto-hospedada não pode se conectar ao serviço de nuvem

• Sintomas

  Quando você tenta registrar o runtime de integração auto-hospedada, Configuration Manager exibe a seguinte mensagem de erro:

  "O nó do Integration Runtime (auto-hospedado) encontrou um erro durante o registro."

  

• Causa

  O IR autogerido não pode se conectar ao backend do serviço. Esse problema normalmente é causado pelas configurações de rede no firewall.

• Resolução

  1. Verifique se o serviço de runtime de integração está em execução. Nesse caso, vá para a etapa 2.

     

  2. Se o proxy não foi configurado no IR auto-hospedado, que é a configuração padrão, execute o seguinte comando do PowerShell no computador em que o runtime de integração auto-hospedada foi instalado:

     (New-Object System.Net.WebClient).DownloadString("https://wu2.frontend.clouddatahub.net/")
     

     Observação

     A URL do serviço pode variar, dependendo do local da instância do wokspace do data factory ou do Synapse. Para encontrar a URL do serviço, use a página Gerenciar da interface do usuário em sua instância do data factory ou do Azure Synapse para encontrar Runtimes de integração, e clique em seu IR auto-hospedado para editá-lo. Então, selecione a guia Nodos e clique em Visualizar URLs de Serviço.

     A resposta esperada é a seguinte:

     

  3. Se não receber a resposta esperada, use um dos seguintes métodos conforme apropriado:

     • Se receber uma mensagem “Não foi possível resolver o nome remoto”, há um problema no Sistema de Nomes de Domínio (DNS). Entre em contato com a equipe de rede para corrigir o problema.
     • Se você receber a mensagem "o certificado ssl/tls não é confiável", verifique o certificado (https://wu2.frontend.clouddatahub.net/) para ver se ele é confiável na máquina e instale o certificado público usando o Gerenciador de Certificados. Essa ação deve ajudar a resolver o problema.
     • Vá para Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, e verifique se há qualquer falha causada pelo DNS, uma regra de firewall, ou configurações de rede da empresa. Caso encontre tal falha, force o fechamento da conexão. Como cada empresa tem suas próprias configurações de rede personalizadas, entre em contato com a equipe de rede para solucionar esses problemas.

  4. Se “proxy” tiver sido configurado no runtime de integração auto-hospedada, verifique se o servidor proxy pode acessar o ponto de extremidade de serviço. Para obter um comando de exemplo, veja PowerShell, solicitações da Web e proxies.

     $user = $env:username
     $webproxy = (get-itemproperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet
     Settings').ProxyServer
     $pwd = Read-Host "Password?" -assecurestring
     $proxy = new-object System.Net.WebProxy
     $proxy.Address = $webproxy
     $account = new-object System.Net.NetworkCredential($user,[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($pwd)), "")
     $proxy.credentials = $account
     $url = "https://wu2.frontend.clouddatahub.net/"
     $wc = new-object system.net.WebClient
     $wc.proxy = $proxy
     $webpage = $wc.DownloadData($url)
     $string = [System.Text.Encoding]::ASCII.GetString($webpage)
     $string
     

  A resposta esperada é a seguinte:

  

  Observação

  Considerações sobre proxy:

  • Verifique se o servidor proxy precisa ser colocado na lista de Destinatários Seguros. Nesse caso, verifique se esses domínios estão na lista de Destinatários seguros.
  • Verifique se o certificado TLS/SSL wu2.frontend.clouddatahub.net/ é confiável no servidor proxy.
  • Se você estiver usando autenticação do Active Directory no proxy, altere a conta de serviço para a conta de usuário que pode acessar o proxy como "Serviço Integration Runtime".

Mensagem de erro: o nó de runtime de integração auto-hospedada/IR auto-hospedado lógico está no estado Inativo/”Em execução (Limitado)”

• Causa

  O nó de runtime de integração auto-hospedada pode ter um status Inativo, conforme mostrado na captura de tela a seguir:

  

  Esse comportamento ocorre quando os nós não conseguem se comunicar entre si.

• Resolução

  1. Faça logon na VM (máquina virtual) hospedada no nó. Em Applications and Services Logs>Integration Runtime, abra Event Viewer e filtre os logs de erros.

  2. Verifique se um log de erro contém o seguinte erro:

     System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://xxxxxxx.bwld.com:8060/ExternalService.svc/WorkerManager. The connection attempt lasted for a time span of 00:00:00.9940994. TCP error code 10061: No connection could be made because the target machine actively refused it 10.2.4.10:8060. 
     System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it. 
     10.2.4.10:8060
     at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
     at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
     at System.ServiceModel.Channels.SocketConnectionInitiator.Connect(Uri uri, TimeSpan timeout)
     

  3. Se você observar esse erro, execute o seguinte comando em uma janela do prompt de comando:

     telnet 10.2.4.10 8060
     

  4. Se você receber o erro de linha de comando "Não foi possível abrir a conexão com o host", que é mostrado na captura de tela a seguir, entre em contato com o departamento de TI para obter ajuda para corrigir esse problema. Depois de conseguir usar o telnet com sucesso, entre em contato com o Suporte da Microsoft se ainda tiver problemas com o status do nó do runtime de integração.

     

  5. Verifique se o log de erro contém a seguinte entrada:

     Error log: Cannot connect to worker manager: net.tcp://xxxxxx:8060/ExternalService.svc/ No DNS entries exist for host azranlcir01r1. No such host is known Exception detail: System.ServiceModel.EndpointNotFoundException: No DNS entries exist for host xxxxx. ---> System.Net.Sockets.SocketException: No such host is known at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostEntry(String hostNameOrAddress) at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri) --- End of inner exception stack trace --- Server stack trace: at System.ServiceModel.Channels.DnsCache.Resolve(Uri uri)
     

  6. Para resolver o problema, tente usar um ou ambos os seguintes métodos:

     • Coloque todos os nós no mesmo domínio.
     • Adicione o IP ao mapeamento de host em todos os arquivos de host da VM hospedada.

Problema de conectividade entre o IR auto-hospedado e sua instância do Data Factory ou Azure Synapse, ou entre o IR auto-hospedado e a fonte ou destino de dados.

Para solucionar o problema de conectividade de rede, você deve saber como coletar o rastreamento de rede, entender como usá-lo e analisar o rastreamento do Microsoft Network Monitor (Netmon) antes de aplicar as Netmon Tools em casos reais do IR auto-hospedado.

• Sintomas

  Ocasionalmente, talvez seja necessário solucionar determinados problemas de conectividade entre o IR auto-hospedado e seu Data Factory ou instância do Azure Synapse, como mostrado na captura de tela a seguir, ou entre o IR auto-hospedado e a fonte de dados ou o destino de dados.

  

  Em qualquer um dos casos, você pode encontrar os seguintes erros:

  • A cópia falhou com o erro: Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException, Message=Não é possível conectar-se ao SQL Server: 'Endereço IP'

  • "Ocorreram um ou mais erros. ocorreu um erro ao enviar a solicitação. A conexão subjacente estava fechada: ocorreu um erro inesperado em um recebimento. Não é possível ler os dados na conexão de transporte: uma conexão existente foi fechada à força pelo host remoto. Uma conexão existente foi fechada forçadamente pela ID da atividade do host remoto."

• Resolução

  Quando encontrar os erros anteriores, solucione-os seguindo as instruções nesta seção.

  • Colete um rastreamento do Netmon para análise:

    1. Você pode definir o filtro para ver uma redefinição do servidor para o lado do cliente. Na captura de tela de exemplo a seguir, você pode ver que o lado servidor é o Data Factory.

       

    2. Ao receber o pacote de redefinição, você pode encontrar a conversa seguindo o Protocolo de Controle de Transmissão (TCP).

       

    3. Obtenha a conversa entre o cliente e o servidor do Data Factory removendo o filtro.

  • Uma análise do rastreamento do Netmon que você coletou mostra que o TTL (Vida Útil) é 64. De acordo com os valores mencionados no artigo Noções Básicas sobre TTL (Vida Útil) e Limite de Salto, extraído na lista a seguir, você pode ver que o sistema Linux redefine o pacote e causa a desconexão.

    Os valores padrão de TTL e Limite de Salto variam entre sistemas operacionais diferentes, conforme listado aqui:

    • Kernel Linux 2.4 (cerca de 2001): 255 para TCP, UDP e ICMP
    • Linux kernel 4.10 (2015): 64 para TCP, UDP e ICMP
    • Windows XP (2001): 128 para TCP, UDP e ICMP
    • Windows 10 (2015): 128 para TCP, UDP e ICMP
    • Windows Server 2008: 128 para TCP, UDP e ICMP
    • Windows Server 2019 (2018): 128 para TCP, UDP e ICMP
    • macOS (2001): 64 para TCP, UDP e ICMP

    

    No exemplo anterior, o TTL é mostrado como 61 em vez de 64, porque quando o pacote de rede atinge o destino, ele precisa passar por vários saltos, como roteadores ou dispositivos de rede. O número de roteadores ou dispositivos de rede é deduzido para resultar no TTL final.

    Nesse caso, você pode ver que um reset pode ser enviado do Sistema Linux com TTL 64.

  • Para confirmar de onde o dispositivo de redefinição pode vir, verifique o quarto salto no IR auto-hospedado.

    O pacote de rede do Sistema Linux A com TTL 64 –> B TTL 64 menos 1 = 63 –> C TTL 63 menos 1 = 62 –> TTL 62 menos 1 = 61 IR auto-hospedado

  • Em uma situação ideal, o número de saltos de TTL seria 128, o que significa que o sistema operacional Windows está executando a instância de data factory. Conforme mostrado no exemplo a seguir, 128 menos 107 = 21 saltos, o que significa que 21 saltos para o pacote foram enviados da instância de data factory para o IR auto-hospedado durante o handshake TCP 3.

    

    Portanto, você precisa entrar em contato com a equipe de rede para verificar qual é o quarto salto no IR auto-hospedado. Se for o firewall, como no Sistema Linux, verifique todos os logs para descobrir por que esse dispositivo redefine o pacote após o handshake TCP 3.

    Se você não tiver certeza de onde investigar, tente obter o rastreamento do Netmon do IR auto-hospedado e do firewall durante o tempo com problemas. Essa abordagem ajudará você a descobrir qual dispositivo pode ter reiniciado o pacote e que causou a desconexão. Nesse caso, você também precisa entrar em contato com a equipe de rede para seguir em frente.

Analisar o rastreamento do Netmon

Ao tentar executar o Telnet 8.8.8.8 888 com o rastreamento do Netmon coletado, você deverá ver o rastreamento nas capturas de tela a seguir:

As imagens anteriores mostram que não foi possível fazer uma conexão TCP com o lado do servidor 8.8.8.8 na porta 888, portanto, você verá dois pacotes adicionais do SynReTransmit lá. Como o SELF-HOST2 de origem não pôde se conectar ao 8.8.8.8 com o primeiro pacote, ele continuará tentando fazer a conexão.

Os cenários bem-sucedidos são mostrados nos exemplos a seguir:

• Se você puder executar o Telnet 8.8.8.8 53 sem problemas, haverá um handshake TCP 3 bem-sucedido e a sessão terminará com um handshake TCP 4.

  

  

• O handshake TCP 3 anterior gera o seguinte fluxo de trabalho:

  

• Para concluir a sessão, o handshake TCP 4 é ilustrado pelos seguintes fluxos de trabalho:

  

  

Determine se essa notificação afeta você

Essa notificação se aplica aos seguintes cenários:

Cenário 1: comunicação de saída de um runtime de integração auto-hospedada que está em execução no local protegido por um firewall corporativo

Como determinar se você será afetado:

• Você não será afetado se estiver definindo regras de firewall com base em FQDNs (nomes de domínio totalmente qualificados), que usam a abordagem descrita em Definir uma configuração de firewall e uma lista de permissões para endereços IP.

• Você será afetado se estiver habilitando explicitamente a lista de permissões para IPs de saída no firewall corporativo.

  Se você for afetado, realize a seguinte ação: até 8 de novembro de 2020, notifique a equipe de infraestrutura de rede para atualizar a configuração de rede, para usar os endereços IP mais recentes do data factory. Para baixar os endereços IP mais recentes, acesse Descobrir marcas de serviço usando os arquivos JSON para download.

Cenário 2: Comunicação de saída de um runtime de integração auto-hospedada em execução em uma VM Azure dentro de uma rede virtual Azure gerenciada pelo cliente

Como determinar se você será afetado:

• Verifique se você tem regras de NSG (grupo de segurança de rede) de saída em uma rede privada que contenha o runtime de integração auto-hospedada. Se não houver restrições de saída, você não será afetado.

• Se você tiver restrições de regra de saída, verifique se está usando as marcas de serviço. Se você estiver usando tags de serviço, não será afetado. Não é necessário alterar nem adicionar nada, pois o novo intervalo de IP está nas marcas de serviço existentes.

  

• Você está afetado se estiver habilitando explicitamente a lista de permissão para endereços IP de saída na configuração de regras NSG na rede virtual do Azure.

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar as regras do NSG na configuração de rede virtual do Azure para usar os endereços IP mais recentes do Data Factory. Para baixar os endereços IP mais recentes, acesse Descobrir marcas de serviço usando os arquivos JSON para download.

Cenário 3: Comunicação de saída do SSIS Integration Runtime em uma rede virtual Azure gerenciada pelo cliente

Como determinar se você será afetado:

• Verifique se você tem regras de NSG de saída em uma rede privada que contém SQL Server Integration Services (SSIS) Integration Runtime. Se não houver restrições de saída, você não será afetado.

• Se você tiver restrições de regra de saída, verifique se está usando as marcas de serviço. Se você estiver usando tags de serviço, não será afetado. Não é necessário alterar nem adicionar nada, pois o novo intervalo de IP está nas marcas de serviço existentes.

• Você está afetado se estiver habilitando explicitamente a lista de permissão para endereços IP de saída na configuração de regras NSG na rede virtual do Azure.

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar as regras do NSG na configuração de rede virtual do Azure para usar os endereços IP mais recentes do Data Factory. Para baixar os endereços IP mais recentes, acesse Descobrir marcas de serviço usando os arquivos JSON para download.

Não foi possível estabelecer uma relação de confiança para o canal seguro SSL/TLS

• Sintomas

  O IR auto-hospedado não pôde se conectar ao serviço Azure Data Factory ou Azure Synapse.

  Ao verificar o registro de eventos de IR auto-hospedado depois de acessar Windows>Visualizador de eventos (log)>Logs de aplicativos e serviços>Integration Runtime, você encontrará a seguinte mensagem de erro.

  "A conexão subjacente foi fechada: não foi possível estabelecer uma relação de confiança para o canal seguro SSL/TLS. O certificado remoto é inválido de acordo com o procedimento de validação."

  A maneira mais simples de verificar o certificado do servidor do serviço é abrir a URL do serviço no navegador. Por exemplo, abra o link "verificação de certificado do servidor" (https://eu.frontend.clouddatahub.net/) na máquina onde o IR auto-hospedado está instalado e, em seguida, visualize as informações do certificado do servidor.

  

  

• Causa

  Há dois motivos possíveis para esse problema:

  • Motivo 1: a autoridade de certificação raiz do certificado do servidor do serviço não é confiável para o computador em que o IR auto-hospedado foi instalado.
  • Motivo 2: você está usando um proxy no ambiente, o certificado do servidor do serviço foi substituído pelo proxy e o certificado de servidor substituído não é confiável para o computador em que o IR auto-hospedado foi instalado.

• Resolução

  • Para o motivo 1: verifique se o certificado do servidor do serviço e a cadeia de certificados são confiáveis para o computador em que o IR auto-hospedado foi instalado.
  • Para o motivo 2: confie na autoridade de certificação raiz substituída no computador do IR auto-hospedado ou configure o proxy para não substituir o certificado do servidor do serviço.

  Para obter mais informações sobre como confiar em certificados em Windows, consulte Instalando o certificado raiz confiável.

• Informações adicionais
  Distribuímos um novo certificado SSL, que é assinado pela DigiCert. Verifique se o DigiCert Global Root G2 está na autoridade de certificação raiz confiável.

  

  Se não estiver na autoridade de certificação raiz confiável, baixe-o aqui.

Conteúdo relacionado

Para obter mais ajuda com a solução de problemas, experimente os seguintes recursos:

• Blog de Data Factory
• Solicitações de recurso do Data Factory

• vídeos Azure

• Página de Perguntas e Respostas da Microsoft
• Fórum do Stack Overflow para Data Factory
• X informações sobre o Data Factory
• Guia de desempenho de fluxos de dados de mapeamento