Solução de problemas do runtime de integração auto-hospedada
APLICA-SE A: 
Azure Data Factory Azure Synapse Analytics Microsoft Purview
Dica
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange desde movimentação de dados até ciência de dados, análise em tempo real, business intelligence e relatórios. Saiba como iniciar uma avaliação gratuita!
Este artigo explora métodos comuns de solução de problemas para o IR (runtime de integração) auto-hospedado nos workpaces 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.
Na página Monitor da interface do usuário do serviço, selecione Execução de pipeline.
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:
Os logs de atividade são exibidos para a execução da atividade com falha.
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.
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.
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.
Observação
As solicitações de exibição e carregamento de log são executadas em todas as instâncias de IR auto-hospedado online. Se houver logs ausentes, verifique se todas as instâncias de IR auto-hospedado estão online.
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 vir no guia de erro abaixo. Para obter diretrizes de suporte e solução de problemas para problemas do SHIR, talvez seja necessário gerar uma ID de relatório de erro e entrar em contato com o suporte da Microsoft.
Para gerar a ID do relatório de erros para Suporte da Microsoft, siga essas instruções:
Antes de iniciar uma verificação no portal de governança do Microsoft Purview:
- Navegue até o computador em que o runtime de integração auto-hospedada está instalado e abra o Visualizador de Eventos do Windows.
- Limpe os logs do Visualizador de Eventos do Windows na seção Runtime de Integração. Clique com o botão direito do mouse nos logs e selecione a opção limpar logs.
- Navegue de volta para o portal de governança do Microsoft Purview e inicie a verificação.
Depois que a verificação mostrar status Falha, navegue de volta para a VM SHIR ou o computador e atualize o visualizador de eventos na seção Runtime de Integração.
Os logs de atividade são exibidos para a execução da atividade com falha.
Para obter mais assistência da Microsoft, selecione Enviar Logs.
A janela Compartilhar os logs do runtime de integração (IR) auto-hospedado com a Microsoft é aberta.
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.
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.
Observação
As solicitações de exibição e carregamento de log são executadas em todas as instâncias de IR auto-hospedado online. Se houver logs ausentes, verifique se todas as instâncias de IR auto-hospedado estão online.
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 trabalhos concorrentes
Sintomas
Quando você tenta aumentar o limite de trabalhos simultâneos na interface do usuário, o processo trava 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, confira Quatro maneiras de encontrar o número de núcleos na CPU no 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:
Exporte o certificado que precisa ser verificado. Para fazer isso, faça o seguinte:
a. No Windows, selecione Iniciar, comece a digitar os certificados e, em seguida, selecione Gerenciar certificados de computador.
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.
Copie o certificado exportado para o computador cliente.
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.txtVerifique 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 OCSP) foi configurada no arquivo de certificado, você poderá verificá-la de maneira mais intuitiva:
Obtenha essas informações verificando os detalhes do certificado, conforme mostrado na captura de tela a seguir:
Execute o comando a seguir. Substitua o <caminho do certificado> pelo caminho real do certificado.
Certutil -URL <certificate path>A ferramenta Recuperação de URL será aberta.
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 afirma que o DLL System.ValueTuple não está localizado na pasta GAC (Cache de Assembly Global) relacionada, na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Gateway ou na pasta C:\Program Files\Microsoft Integration Runtime\4.0\Shared.
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 na 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 do .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":"The type initializer for 'Npgsql.PoolManager' threw an exception.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Could not load file or assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' or one of its dependencies. The system cannot find the file specified.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"
Para obter mais informações sobre GAC, confira 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ê pode acessar a pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o arquivo de Configurações foi excluído. Se ele foi excluído, siga as instruções no artigo do NetWrix Detectar quem excluiu um arquivo dos servidores de arquivos do 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, é conveniente conectar os dois IRs para concluir uma atividade Copy. 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 auto-hospedado é projetado como um nó central de uma atividade de cópia, não um agente cliente que precisa ser instalado para cada armazenamento 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 Copy, o IR de destino será usado e você precisará instalar os drivers para os dois armazenamentos de dados no computador de 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 Armazenamento de Blobs do Azure
- Copie outro IR do Armazenamento de Blobs do Azure para o armazenamento de dados 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" foi excluída do nó de runtime de integração atual com o conteúdo, você receberá a seguinte mensagem de erro:
"Quando você excluir o serviço de link no portal do Azure ou a tarefa tiver o conteúdo incorreto, crie um serviço de link com a 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 Configuration Manager do IR, 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.
Import 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 de integração auto-hospedada 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:
Abra Executar Comando do MMC (Console de Gerenciamento da Microsoft).
No painel do MMC, aplique as seguintes etapas:
- Selecionar Arquivo.
- Escolha Adicionar/Remover Snap-in na lista suspensa.
- Selecione Certificados no painel "Snap-ins disponíveis".
- Selecione Adicionar.
- No painel pop-up "Snap-in de certificados", escolha Conta de computador.
- Selecione Avançar.
- No painel “Selecionar Computador”, escolha Computador local: o computador no qual este console está sendo executado.
- Selecione Concluir.
- Selecione OK no painel "Adicionar ou Remover Snap-ins".
No painel do MMC, avance com as seguintes etapas:
- Na lista de pastas à esquerda, selecione Raiz do Console –> Certificados (Computador Local) –> Pessoal –> Certificados.
- Clique com o botão direito em MDM Beta do Microsoft Intune.
- Selecione Todas as Tarefas na lista suspensa.
- Selecione Gerenciar Chaves Privadas.
- Selecione Adicionar em “Nomes de grupo ou de usuário”.
- Selecione NT SERVICE\DIAHostService para conceder acesso de controle total a esse certificado, aplicar e proteger.
- Selecione Verificar Nomes e, em seguida, OK.
- 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 em formato ORC ou Parquet), você recebe uma mensagem de erro semelhante à 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=808605para baixar e instalar em seu computador de nó de Integration Runtime (auto-hospedado). Observe que o Integration Runtime de 64 bits exige o JRE de 64 bits e o Integration Runtime de 32 bits exige o JRE de 32 bits.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': o módulo especificado não pôde ser encontrado. (Exceção de HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridgeCausa
Esse problema ocorre por um dos dois motivos:
O JRE (Java Runtime Environment) não está instalado corretamente no servidor do Integration Runtime.
Seu servidor do Integration Runtime não tem a dependência necessária para o JRE.
Por padrão, o Integration Runtime resolve o caminho do 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:
Verifique se o Integration Runtime (Diahost.exe) e o 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 está
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.
Verifique o registro para obter as configurações apropriadas. Para fazer isso, execute estas etapas:
No menu Executar, digite Regedit e pressione ENTER.
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).
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.
Localize a pasta bin\server no seguinte caminho:
C:\Program Files\Java\jre1.8.0_74
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:
Verifique a conta de serviço de logon DIAHostService no painel de serviço do Windows.
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:
a. 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. Acesse a pasta de instalação do IR auto-hospedado e, em seguida, alterne 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:
Verifique a conta de serviço de logon DIAHostService no painel de serviço do Windows.
Verifique se a conta de serviço de logon tem a permissão Fazer logon como serviço para iniciar o serviço do 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 do Windows:
- Logs de Aplicativos e Serviços > Integration Runtime
- Logs do Windows > 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 Registrar não é exibido no painel Configuration Manager.
Causa
A partir do lançamento do Integration Runtime 3.0, o botão Registrar nos nós de runtime de integração existentes foram removidos para fornecer 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
No painel de controle, 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.
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.
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: A non-recoverable error occurred during a database lookup at System.Net.Dns.GetAddrInfo(String name).
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 runtime de integração 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 Windows NT 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
Ao instalar um IR auto-hospedado por meio do Configuration Manager do Microsoft Integration Runtime, um certificado com uma 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 do Integration Runtime o acesso ao certificado '<nome do certificado>'. 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.pfxAntes e depois da conversão:
Runtime de integração auto-hospedada versão 5.x
Para atualizar para a versão 5.x do runtime de integração auto-hospedada, exigimos o .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 os clientes do Azure Data Factory v2 e do Azure Synapse:
- Se a atualização automática estiver ativada e você já tiver atualizado o .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedada será atualizado automaticamente para a versão 5.x mais recente.
- Se a atualização automática estiver ativada e você ainda não tiver atualizado o .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 5.x mais recente. 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 o .NET Framework Runtime para 4.7.2 ou posterior, você poderá baixar manualmente o 5.x mais recente e instalá-lo no computador.
- Se a atualização automática estiver desativada e você não tiver atualizado o .NET Framework Runtime para 4.7.2 ou posterior. Quando você tentar instalar manualmente o runtime de integração auto-hospedada 5.x e registrar a chave, será necessário atualizar a 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ê tentar registrar o runtime de integração auto-hospedada, o Configuration Manager exibirá a seguinte mensagem de erro:
"O nó do Integration Runtime (auto-hospedado) encontrou um erro durante o registro."
Causa
O IR auto-hospedado não pode se conectar ao back-end de serviço. Esse problema normalmente é causado pelas configurações de rede no firewall.
Resolução
Verifique se o serviço de runtime de integração está em execução. Nesse caso, vá para a etapa 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 Nós e clique em Exibir URLs do Serviço.
A resposta esperada é a seguinte:
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. - Acesse Windows>Visualizador de Eventos (logs)>Logs de Aplicativos e Serviços>Integration Runtime e verifique se há falhas causadas pelo DNS, por uma regra de firewall ou pelas configurações de rede da empresa. Se encontrar uma 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.
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 para 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 estiver usando a 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 do Runtime de Integração”.
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
Faça logon na VM (máquina virtual) hospedada no nó. Em Logs de Aplicativos e Serviços>Integration Runtime, abra o Visualizador de Eventos e filtre os logs de erros.
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)Se você observar esse erro, execute o seguinte comando em uma janela do prompt de comando:
telnet 10.2.4.10 8060Se 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 que você puder executar o Telnet com êxito, entre em contato com Suporte da Microsoft se ainda tiver problemas com o status do nó de runtime de integração.
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)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 a instância do data factory, ou do Azure Synapse, ou entre o IR auto-hospedado e a fonte de dados ou o coletor
Para solucionar o problema de conectividade de rede, você deve saber coletar o rastreamento de rede, entender como usá-lo e analisar o rastreamento do Monitor de Rede da Microsoft (Netmon), antes de aplicar as ferramentas do Netmon em casos reais no IR auto-hospedado.
Sintomas
Ocasionalmente, talvez você precise solucionar alguns problemas de conectividade entre o IR auto-hospedado e a instância de data factory ou do Azure Synapse, conforme mostrado na captura de tela a seguir, ou entre o IR auto-hospedado e a fonte de dados ou o coletor.
Em qualquer um dos casos, você pode encontrar os seguintes erros:
"Falha na cópia com erro:Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Não é possível se conectar 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:
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 do servidor é o servidor do Data Factory.
Ao receber o pacote de redefinição, você pode encontrar a conversa seguindo o protocolo TCP.
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:
- Linux kernel 2.4 (circa 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 uma redefinição pode ser enviada do Sistema Linux com o 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 redefinido o pacote e causado 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
Observação
As instruções a seguir se aplicam ao rastreamento do Netmon. Como o rastreamento do Netmon está sem suporte no momento, você pode usar o Wireshark para essa finalidade.
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 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.
Dica
Para fazer essa conexão, tente a seguinte solução:
- Selecione Carregar filtro>Filtro padrão>Endereços>Endereços IPv4.
- Para aplicar o filtro, insira IPv4.Address == 8.8.8.8 e depois selecione Aplicar. Em seguida, você deve ver a comunicação do computador local com o destino 8.8.8.8.
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 do Azure dentro de uma rede virtual do 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 as marcas 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ê será afetado se estiver habilitando explicitamente a lista de permissões para endereços IP de saída na configuração de regras de NSG na rede virtual do Azure.
Se você for afetado, realize a seguinte ação: até 8 de novembro de 2020, notifique a equipe de infraestrutura de rede para atualizar as regras de 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 do 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 contenha o SSIS (SQL Server Integration Services) 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 as marcas 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ê será afetado se estiver habilitando explicitamente a lista de permissões para endereços IP de saída na configuração de regras de NSG na rede virtual do Azure.
Se você for afetado, realize a seguinte ação: até 8 de novembro de 2020, notifique a equipe de infraestrutura de rede para atualizar as regras de 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 pode se conectar ao serviço do Azure Data Factory ou do 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 verificar certificado do servidor (
https://eu.frontend.clouddatahub.net/) na máquina em que o IR auto-hospedado está instalado e 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 a confiança em certificados no Windows, confira Instalação do 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: