Resolver problemas do runtime de integração autoalojado

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

Este artigo explora métodos comuns de resolução de problemas para runtime de integração auto-hospedado (IR) nos espaços de trabalho do Azure Data Factory e Synapse.

Reunir registos de IR autogeridos

Azure Data Factory e Azure Synapse Analytics

Para atividades com falha que estão sendo executadas em um IR auto-hospedado ou um IR compartilhado, o serviço suporta a visualização e upload de logs de erros. Para obter o ID do relatório de erros, siga as instruções aqui e insira o ID do relatório para procurar problemas conhecidos relacionados.

1. Na página Monitor da interface do usuário do serviço, selecione Pipeline runs.

2. Em Execuções de atividade, na coluna Erro, selecione o botão realçado para exibir os registos de atividades, 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.

   Abre-se a janela Partilhar os registos do runtime de integração (IR) auto-hospedado com a Microsoft.

   Captura de ecrã da janela "Partilhe os registos de execução (IR) de integração auto-hospedados com a Microsoft".

4. Selecione quais logs você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar logs relacionados à atividade com falha ou todos os logs no nó IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente 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 mais assistência para resolver o problema.

   

Microsoft Purview

Para atividades de Microsoft Purview falhadas que estão a correr num IR auto-hospedado ou IR partilhado, o serviço suporta a visualização e carregamento de registos de erro do Windows Event Viewer.

Você pode procurar quaisquer erros que você vê no guia de erros abaixo. Para obter apoio e orientação para resolver problemas SHIR, pode ser necessário gerar um ID de relatório de erro e contactar o suporte Microsoft.

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

1. Antes de iniciar uma análise no portal de governação Microsoft Purview:

   1. Navegue até à máquina onde o runtime de integração auto-hospedado está instalado e abra a Windows Event Viewer.
   2. Limpe os registos Windows Event Viewer na secção Integration Runtime. Clique com o botão direito do mouse nos logs e selecione a opção limpar logs.
   3. Navegue de volta ao portal de governação Microsoft Purview e inicie a análise.

2. Assim que a análise mostrar o estado Falhado, volte para a VM SHIR ou computador e atualize o visualizador de eventos na secção Integration Runtime.

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

4. Para mais assistência da Microsoft, selecione Enviar Registos.

   A janela de Partilhar os registos de runtime de integração auto-hospedada (SHIR) com Microsoft abre-se.

   

5. Selecione quais logs você deseja enviar.

   • Para um IR auto-hospedado, você pode carregar logs relacionados à atividade com falha ou todos os logs no nó IR auto-hospedado.
   • Para um IR compartilhado, você pode carregar somente 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 mais assistência para resolver o problema.

   

Erro ou falha geral do IR autogerido

Problema de memória esgotada

• Sintomas

  Um erro OutOfMemoryException (OOM) ocorre quando tenta executar uma atividade de procura com um IR ligado ou um IR autoalojado.

• Motivo

  Uma nova atividade poderá causar um erro OOM se o computador de IR registar momentaneamente uma elevada utilização da memória. Este problema pode ser causado por um grande volume de atividade simultânea e o erro é propositado.

• Resolução

  Verifique a utilização de recursos e a execução de atividade simultânea no nó IR. Ajuste o tempo de disparo e o tempo interno das execuções de atividades para evitar uma execução excessiva num único nó de IR ao mesmo tempo.

Problema de limite de trabalhos simultâneos

• Sintomas

  Quando tentas aumentar o limite de trabalhos simultâneos através da interface do utilizador, o processo trava em estado de atualização.

  Cenário de exemplo: O valor máximo de tarefas simultâneas está atualmente definido para 24 e quer aumentar a contagem para que as tarefas possam ser executadas mais rapidamente. O valor mínimo que pode introduzir é 3 e o valor máximo é 32. Você aumenta o valor de 24 para 32 e, em seguida, selecione o botão Atualizar . O processo fica preso no status de atualização , conforme mostrado na captura de tela a seguir. Atualiza a página e o valor ainda é apresentado como 24. Não foi atualizado para 32 como esperava.

  

• Motivo

  O limite do número de tarefas simultâneas depende do núcleo lógico e da memória do computador. Tente ajustar para baixo para um valor como 24 e, em seguida, veja o resultado.

  Gorjeta

  • Para saber mais sobre a contagem de núcleos lógicos e para determinar a contagem de núcleos lógicos da sua máquina, veja Quatro formas de encontrar o número de núcleos no seu CPU em Windows 10.
  • Para saber como calcular o math.log, aceda à Calculadora de logaritmos.

Problema com o certificado SSL de Alta Disponibilidade (HA) do Integration Runtime (IR) auto-hospedado

• Sintomas

  O nó de trabalho do IR hospedado localmente apresentou o erro seguinte:

  Falhou em obter estados partilhados do nó primário net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/. ID da atividade: XXXXX O certificado X.509 CN=abc.cloud.corp. Microsoft.com, OU = teste, O = Microsoft a construção da cadeia falhou. O certificado utilizado tem uma cadeia de confiança que não pode ser verificada. Substitua o certificado ou altere o modo de validação do certificado. A função de revogação não conseguiu verificar a revogação porque o servidor de revogação estava offline.”

• Motivo

  Quando processa casos relacionados com o handshake do SSL/TLS, pode encontrar alguns problemas relacionados com a verificação da cadeia de certificados.

• Resolução

  • Veja a seguir uma forma rápida e intuitiva de resolver problemas de falha de compilação da cadeia de certificados X.509:

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

       a) No Windows, selecione Start, comece a escrever certificates e depois selecione Gerir certificados de computador.

       b) No Explorador de Ficheiros, no painel esquerdo, procure o certificado que quer verificar, clique com o botão direito do rato e, em seguida, selecione Todas as tarefas>Exportar.

       

    2. Copie o certificado exportado para o computador cliente.

    3. Do lado do cliente, numa janela da Linha de Comandos, execute o seguinte comando. Certifique-se de substituir <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 ficheiro TXT de saída. Pode encontrar o resumo dos erros no final do ficheiro TXT.

       Por exemplo:

       

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

       

  • Se uma extensão de nome de ficheiro AIA (Acesso a Informações sobre a Autoridade), CDP (Ponto de Distribuição CRL) ou OCSP (Protocolo de Estado de Certificado Online) estiver configurada no ficheiro de certificado, poderá verificar de uma forma mais intuitiva:

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

       

    2. Execute o seguinte comando. Certifique-se de substituir <o caminho> do certificado pelo caminho real do certificado.

         Certutil   -URL    <certificate path> 
       

       A ferramenta de Obtenção de URLs abre-se.

    3. Para verificar certificados com extensões de nomes de ficheiro AIA, CDP e OCSP, selecione Obter.

       

       Você construiu a cadeia de certificados com êxito se o estado do certificado da AIA for Verificado e o estado do certificado da CDP ou OCSP for Verificado.

       Se ocorrer uma falha ao tentar obter o AIA ou o CDP, trabalhe com a equipa de rede para preparar o computador cliente para se ligar ao URL de destino. Será suficiente se o caminho HTTP ou o caminho do protocolo LDAP (Lightweight Directory Access Protocol) puder ser verificado.

O IR Autoalojado não conseguiu carregar o ficheiro ou a assemblagem

• Sintomas

  Receberá mensagem de erro seguinte:

  “Não foi possível carregar o ficheiro ou a montagem “XXXXXXXXXXXXXXXX, Versão=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXXX” ou uma das dependências. O sistema não consegue encontrar o ficheiro especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

  Veja a seguir uma mensagem de erro mais específica:

  “Não foi possível carregar o ficheiro ou a montagem “System.ValueTuple, Versão=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXXX” ou uma das dependências. O sistema não consegue encontrar o ficheiro especificado. ID da Atividade: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3”

• Motivo

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

  

  Gorjeta

  No Monitor de Processos, pode definir os filtros como mostrado na captura de ecrã seguinte.

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

  Basicamente, o processo carrega a DLL primeiro da pasta GAC , depois da pasta compartilhada e, finalmente, da pasta Gateway . Portanto, pode carregar o DLL a partir de qualquer caminho que seja útil.

  Screenshot do "Filtro do Monitor de Processo", listando os filtros para a DLL.

• Resolução

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

  Pode utilizar o mesmo método para resolver outros problemas de ficheiros ou assemblagens em falta.

• Mais informações sobre esta questão

  A razão pela qual vês o System.ValueTuple.dll em %windir%\Microsoft.NET\assembly e %windir%\assembly é que este é um comportamento .NET.

  No erro a seguir, você pode ver claramente que o assembly System.ValueTuple está faltando. Este problema surge quando a aplicação 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 ficheiro ou a assembly 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' ou uma das suas dependências. O sistema não consegue encontrar 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 a GAC, veja Global Assembly Cache.

Falta a Chave de Autenticação do Runtime de integração autoalojado

• Sintomas

  O runtime de integração autoalojado fica subitamente offline sem uma Chave de Autenticação e o Registo de Eventos apresenta a seguinte mensagem de erro:

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

  

• Motivo

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

• Resolução

  Se nenhuma das causas anteriores se aplicar, pode ir à pasta %programdata%\Microsoft\Data Transfer\DataManagementGateway para ver se o ficheiro Configurations foi eliminado. Se foi apagado, siga as instruções no artigo da Netwrix Detecte quem apagou um ficheiro dos seus servidores de ficheiros Windows.

  

Não é possível utilizar o runtime autogerido para ligar dois repositórios de dados localmente.

• Sintomas

  Depois de criar os IRs auto-hospedados para os armazenamentos de dados de origem e de destino, deve conectar os IRs auto-hospedados para concluir a atividade de cópia. Se os arquivos de dados estiverem configurados em diferentes redes virtuais ou não entenderem o mecanismo do gateway, receberá um dos seguintes erros:

  • “Não é possível localizar o driver da origem no IR de destino”
  • “Não é possível aceder à origem pelo IR de destino”

• Motivo

  O IR auto-hospedado foi criado como um nó central de uma atividade de cópia, não como um agente cliente que precisa ser instalado para cada repositório de dados.

  Neste caso, deverá criar o serviço associado para cada datastore com o mesmo IR, e o IR deverá conseguir aceder a ambos os datastores através da rede. Não importa se o IR está instalado no arquivo de dados de origem ou de destino ou num terceiro computador. Se forem criados dois serviços ligados com IRs diferentes, mas utilizados na mesma atividade de cópia, o IR de destino é o que será utilizado, e é necessário instalar os drivers para ambos os repositórios de dados no computador do IR de destino.

• Resolução

  Instale os controladores para os arquivos de dados de origem e de destino no IR de destino e verifique se consegue aceder ao arquivo de dados de origem.

  Se o tráfego não puder passar pela rede entre dois datastores (por exemplo, se estiverem configurados em duas redes virtuais), pode não conseguir concluir a cópia em uma única atividade, mesmo com o IR instalado. Se não conseguir terminar a cópia numa única atividade, poderá criar duas atividades de cópia com dois IRs, cada uma num VENT:

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

  Esta solução poderá simular a condição de utilizar o IR para criar uma ponte que liga dois arquivos de dados desligados.

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

• Sintomas

  Se a credencial da origem de dados “XXXXXXXXX” for eliminada do nó de execução de integração atual com payload, receberá a seguinte mensagem de erro:

  "Quando apagares o serviço de ligação no portal Azure, ou quando a tarefa tiver a carga útil errada, por favor cria novamente um novo serviço de ligação com a tua credencial."

• Motivo

  O seu IR autoalojado está configurado no modo HA com dois nós, mas os nós não estão num estado de sincronização de credenciais. Tal significa que as credenciais armazenadas no nó do despachante não estão sincronizadas com os outros nós de trabalho. Se ocorrer algum failover do nó do despachante para o nó de trabalho e se as credenciais existirem apenas no nó do despachante anterior, a tarefa falhará quando tentar aceder às credenciais, e receberá o erro precedente.

• Resolução

  A única forma de evitar este problema é verificar se os dois nós estão no estado de sincronização de credenciais. Se não estiverem sincronizados, terá de reintroduzir as credenciais do novo despachante.

Não é possível escolher o certificado porque falta a chave privada

• Sintomas

  • Importou um ficheiro PFX para o arquivo de certificados.

  • Quando selecionou o certificado através da interface do IR Configuration Manager, recebeu a seguinte mensagem de erro:

    “Falha ao alterar o modo de encriptação da comunicação da Intranet. É provável que o certificado '<nome> do certificado' não tenha uma chave privada capaz de troca de chaves ou o processo pode não ter direitos de acesso para a chave privada. Por favor, veja a exceção interna para mais detalhes.

• Motivo

  • A conta de utilizador tem um baixo nível de privilégios e não consegue aceder à chave privada.
  • O certificado foi gerado como uma assinatura, mas não como troca de chaves.

• Resolução

  • Para operar na IU, utilize uma conta com privilégios adequados para aceder à chave privada.

  • Importe o certificado ao executar o seguinte comando:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Problema de sincronização dos nós do runtime de integração autoalojado

• Sintomas

  Os nós do runtime de integração hospedado por si próprio tentam sincronizar as credenciais entre os nós, mas ficam bloqueados no processo e encontram a mensagem de erro abaixo após algum tempo:

  O nó de Integration Runtime (Auto-hospedado) está a tentar fazer a sincronização das credenciais entre os nodos. Esta operação poderá demorar alguns minutos”.

  Nota

  Caso este erro apareça por mais de 10 minutos, verifique a conectividade com o nó do dispatcher.

• Motivo

  O motivo é que os nós de trabalho não têm acesso às chaves privadas. Pode confirmar isto nos registos do tempo de execução da 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.

  Não tem qualquer problema com o processo de sincronização quando utiliza a autenticação do principal de serviço no serviço associado. No entanto, quando trocas o tipo de autenticação para chave de conta, o problema de sincronização começou. Este problema ocorre porque o serviço de runtime de integração autoalojado é executado numa conta de serviço (SERVIÇO NT\DIAHostService) e tem de ser adicionado às permissões de chave privada.

• Resolução

  Para resolver este problema, tem de adicionar a conta de serviço do runtime de integração auto-hospedado (NT SERVICE\DIAHostService) às permissões de chave privada. Pode realizar os seguintes passos:

  1. Abra o comando Run da Microsoft Management Console (MMC).

     

  2. No painel MMC, aplique as seguintes etapas:

     

     1. Selecione Ficheiro.
     2. Escolha Adicionar/Remover Snap-in no menu pendente.
     3. Selecione Certificados no painel “Snap-ins disponíveis”.
     4. Selecione Adicionar.
     5. No painel de pop-up "Certificados snap-in", escolha Conta do computador.
     6. Selecione Seguinte.
     7. No painel “Selecionar Computador”, escolha Computador local: o computador no qual a consola está a ser executada.
     8. Selecione Concluir.
     9. Selecione OK no painel “Adicionar ou Remover Snap-ins”.

  3. No painel do MMC, continue com os seguintes passos:

     

     1. Na lista de pastas à esquerda, selecione Raiz do Console -> Certificados (Computador Local) -> Pessoal -> Certificados.
     2. Clique com o botão direito em Microsoft Intune Beta MDM.
     3. Selecione Todas as Tarefas na lista pendente.
     4. Selecione Gerir Chaves Privadas.
     5. Selecione Adicionar em “Grupos ou nomes de utilizadores”.
     6. Selecione SERVIÇO NT\DIAHostService para lhe conceder acesso com controlo total a este certificado, aplicá-lo e protegê-lo.
     7. Selecione Verificar Nomes e, em seguida, OK.
     8. No painel “Permissões”, selecione Aplicar e, em seguida, OK.

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

• Sintomas

  Quando tenta copiar conteúdo para o Microsoft Azure usando uma ferramenta ou programa baseado em Java (por exemplo, copiando ficheiros em formato ORC ou Parquet), recebe uma mensagem de erro que se assemelha ao seguinte:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment não foi encontrado. Vai a http://go.microsoft.com/fwlink/?LinkId=808605 para descarregar e instalar na tua máquina de Integration Runtime (auto-hospedada). Atenção: o Integration Runtime de 64 bits requer JRE de 64 bits e o Integration Runtime de 32 bits requer JRE de 32 bits.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': O módulo especificado não foi encontrado. (Exceção do HRESULT: 0x8007007E),Source=Microsoft. DataTransfer.Richfile.HiveOrcBridge

• Motivo

  Este problema ocorre por um dos seguintes motivos:

  • O Java Runtime Environment (JRE) não está instalado corretamente no seu servidor Integration Runtime.

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

  Por defeito, o Integration Runtime resolve o caminho do JRE usando entradas de registo. Estas entradas devem ser definidas automaticamente durante a instalação do JRE.

• Resolução

  Siga cuidadosamente os passos indicados nesta secção. Poderão ocorrer problemas graves se modificar o registo de forma incorreta. Antes de o modificar, faça uma cópia de segurança do registo para restauro caso ocorram problemas.

  Para corrigir este problema, siga estes passos para verificar o estado da instalação do JRE:

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

     • JRE de 64 bits para o Runtime de Integração ADF de 64 bits deve ser instalado na pasta: C:\Program Files\Java\

       Nota

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

     • Java Runtime (JRE) é a versão 11 ou superior, de um fornecedor JRE como Microsoft OpenJDK 11 ou Eclipse Temurin 11. Certifique-se de que a variável de ambiente do sistema JAVA_HOME esteja definida para a pasta JDK (não apenas a pasta JRE), você também pode precisar adicionar a pasta bin à variável de ambiente PATH do sistema.

  2. Verifique se o registo tem as definições corretas. Para o fazer, siga estes passos:

     1. No menu Executar, escreva Regedit e prima Enter.

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

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        No painel Detalhes, deve existir uma entrada para a Versão Atual a mostrar a versão do JRE (por exemplo, 1.8).

        

     3. No painel de navegação, localize uma subchave que seja uma correspondência exata da versão (por exemplo 1.8) na pasta JRE. No painel de detalhes, deve existir uma entrada JavaHome. O valor desta entrada é o caminho de instalação do JRE.

        

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

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

     

  4. Verifique se esta pasta tem um ficheiro jvm.dll. Se não, verifique o arquivo na pasta bin\client.

     

  Nota

  • Se alguma destas configurações não estiver conforme descrita nestes passos, utilize o Windows Installer do JRE para corrigir os problemas.
  • Se todas as configurações nestes passos estiverem corretas conforme descrito, poderá existir uma biblioteca de runtime VC++ em falta no sistema. Pode corrigir este problema ao instalar o Pacote Redistribuível VC++ 2010.

Configuração de IR auto-hospedada

Erro de registro do tempo de execução da integração

• Sintomas

  Ocasionalmente, você pode querer executar um IR auto-hospedado em uma conta diferente por um dos seguintes motivos:

  • A política da empresa não permite a conta de serviço.
  • É necessário algum tipo de autenticação.

  Depois de alterar a conta de serviço no painel de serviço, você pode achar que o tempo de execução de integração para de funcionar e você recebe a seguinte mensagem de erro:

  O nó Integration Runtime (auto-hospedado) encontrou um erro durante o registo. Não é possível ligar-se ao Integration Runtime (Self-hosted) Host Service."

  

• Motivo

  Muitos recursos são concedidos apenas para a conta de serviço. Quando muda a conta de serviço para outra conta, as permissões de todos os recursos dependentes permanecem inalteradas.

• Resolução

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

  

  • Se o erro no registo de eventos for “UnauthorizedAccessException”, faça o seguinte:

    1. Verifique a conta de serviço de início de sessão DIAHostService no painel de serviços do Windows.

       

    2. Verifica se a conta do serviço de login tem permissões de leitura/escrita para a pasta %programdata%\Microsoft\DataTransfer\DataManagementGateway.

       • Por predefinição, se a conta de serviço de início de sessão não tiver sido alterada, deverá ter permissões de leitura/escrita.

         

       • Se alterou a conta de serviço de início de sessão, mitigue o problema procedendo da seguinte forma:

         a) Realize uma desinstalação limpa do IR autogerido atual.
         b) Instale os bits do IR autoalojado.
         c. Altere a conta de serviço ao fazer o seguinte:

         i) Vai à pasta de instalação IR self-hosted e depois muda para a pasta Microsoft Integration Runtime\4.0\Shared.
         II. Abra uma janela da linha de comandos com privilégios elevados. Substitua <utilizador> e <palavra-passe> pelo seu próprio nome de utilizador e palavra-passe, e depois execute o seguinte comando:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Se quiser mudar para a conta LocalSystem, não se esqueça de utilizar o formato correto para esta conta: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         Não utilize 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. Pode utilizar um utilizador local/de domínio para a conta de logon do serviço IR.

         d. Registe o runtime de integração.

  • Se o erro for "Serviço 'Integration Runtime Service' (DIAHostService) falhou ao iniciar. Verifique se você tem privilégios suficientes para iniciar os serviços do sistema", faça o seguinte:

    1. Verifique a conta de serviço de início de sessão DIAHostService no painel de serviços do Windows.

       

    2. Verifique se a conta do serviço de login tem permissão Iniciar sessão como serviço para iniciar o serviço Windows:

       

• Mais informações

  Se nenhum dos dois padrões de resolução anteriores se aplicar no seu caso, tente recolher os seguintes registos de eventos do Windows:

  • Registos de Aplicações e Serviços > Integration Runtime
  • Windows Registos > Aplicação

Não consigo encontrar o botão Registar para registar um IR hospedado localmente

• Sintomas

  Quando registas um IR auto-hospedado, o botão Registar não aparece no painel Configuration Manager.

  

• Motivo

  Desde o lançamento da Integration Runtime 3.0, o botão Register nos nós integration runtime existentes foi removido para permitir um ambiente mais limpo e seguro. Se um nó estiver registado num runtime de integração, seja ele online ou não, deve ser registado novamente noutro runtime de integração desinstalando primeiro o nó anterior, e depois instalando e registando o nó no novo.

• Resolução

  1. No Control Panel, desinstala o runtime de integração existente.

     Importante

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

     

  2. Se não tiver o ficheiro MSI do instalador do runtime de integração, vá ao Centro de Download para descarregar o runtime de integração mais recente.

  3. Instale o ficheiro MSI e registe o runtime de integração.

Não foi possível registar o IR auto-hospedado por causa do localhost

• Sintomas

  Você não consegue registrar o IR auto-hospedado em uma nova máquina quando você usa get_LoopbackIpOrName.

  Depuração: Ocorreu um erro de tempo de execução. O inicializador de tipos para 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' lançou uma exceção. Ocorreu um erro não recuperável durante uma pesquisa na base de dados.

  Detalhe da Exceção: System.TypeInitializationException: O inicializador de tipo para 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' lançou 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).

• Motivo

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

• Resolução

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

Falha na instalaçã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.

• Motivo

  A instalação em tempo de execução da integração depende do serviço Windows Installer. Você pode ter problemas de instalação pelos seguintes motivos:

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

A conta de serviço de RI não conseguiu obter acesso ao certificado

• Sintomas

  Quando instala um IR auto-hospedado via Microsoft Integration Runtime Configuration Manager, é gerado um certificado com uma autoridade certificadora (CA) de confiança. O certificado não pôde ser aplicado para criptografar a comunicação entre dois nós e a seguinte mensagem de erro é exibida:

  "Falhou em alterar o modo de encriptação de comunicação da intranet: Falhou em conceder à Integration Runtime conta de serviço o acesso ao certificado '<nome do certificado>'. Código de erro 103"

• Motivo

  O certificado está usando o armazenamento KSP (provedor de armazenamento de chaves), que ainda não é suportado. Até o momento, o IR auto-hospedado suporta apenas armazenamento de provedor de serviços criptográficos (CSP).

• Resolução

  Recomendamos que você use certificados 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:

  

  

Tempo de execução de integração auto-hospedado versão 5.x

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

Para clientes do Azure Data Factory v2 e Azure Synapse:

• Se a atualização automática estiver ativa e já tiver atualizado o seu .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedado será automaticamente atualizado para a versão 5.x mais recente.
• Se a atualização automática estiver ativada e ainda não tiver atualizado o seu .NET Framework Runtime para 4.7.2 ou posterior, o runtime de integração auto-hospedado não será automaticamente atualizado para a versão 5.x mais recente. O ambiente de execução de integração auto-hospedado permanecerá na versão 4.x atual. Pode ver um aviso para uma atualização de runtime do .NET Framework no portal e no cliente de runtime de integração auto-hospedado.
• Se a atualização automática estiver desligada e já tiver atualizado o seu .NET Framework Runtime para a 4.7.2 ou posterior, pode descarregar manualmente a versão 5.x mais recente e instalá-la na sua máquina.
• Se a atualização automática estiver desligada e ainda não atualizaste o teu .NET Framework Runtime para a versão 4.7.2 ou posterior. Quando tentar instalar manualmente o runtime de integração auto-hospedado 5.x e registar a chave, será necessário atualizar primeiro a sua versão do .NET Framework Runtime.

Problemas de conectividade de IR auto-hospedados

O runtime de integração autoalojado não consegue ligar-se ao serviço cloud

• Sintomas

  Quando tenta registar o runtime de integração auto-hospedado, o Configuration Manager apresenta a seguinte mensagem de erro:

  "O nó Integration Runtime (Auto-hospedado) encontrou um erro durante o registo."

  

• Motivo

  O IR auto-hospedado não pode se conectar ao back-end do serviço. Este problema é normalmente causado pelas definições da rede na firewall.

• Resolução

  1. Verifique se o serviço de runtime de integração está em execução. Se estiver, avance para a etapa 2.

     

  2. Se nenhum proxy estiver configurado na integração runtime autoalojado (IR), que é a configuração padrão, execute o seguinte comando em PowerShell na máquina onde o runtime de integração autoalojado está instalado:

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

     Nota

     A URL do serviço pode variar, dependendo do local da sua fábrica de dados ou da instância do espaço de trabalho Sinapse. Para encontrar o URL do serviço, use a página Gerir da interface do utilizador (UI) na sua instância do Data Factory ou do Azure Synapse para encontrar Integration runtimes e clique no runtime de integração auto-hospedado para editar. Lá, selecione o separador Nodos e clique em Exibir URLs de Serviço.

     O seguinte é a resposta esperada:

     

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

     • Se receber uma mensagem “Não foi possível resolver o nome remoto”, significa que existe um problema no Sistema de Nomes de Domínio (DNS). Contacte a equipa de rede para corrigir o problema.
     • Se você receber uma mensagem "ssl/tls cert is not trusted", 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. Esta ação deve mitigar o problema.
     • Vai a Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, e verifica se há alguma falha causada por DNS, uma regra de firewall, ou definições de rede da empresa. Se detetar tal falha, force o encerramento da ligação. Como cada empresa tem as suas próprias definições de rede personalizadas, contacte a equipa de rede para resolver estes problemas.

  4. Se o “proxy” tiver sido configurado no runtime de integração autoalojado, verifique se o servidor proxy consegue aceder ao ponto final de serviço. Para obter um comando de amostra, veja PowerShell, pedidos 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
     

  O seguinte é a resposta esperada:

  

  Nota

  Considerações sobre procuração:

  • Verifique se o servidor proxy precisa ser colocado na lista de destinatários seguros. Se assim for, verifique se estes domínios estão na lista de Destinatários Seguros.
  • Verifique se o certificado wu2.frontend.clouddatahub.net/ SSL/TLS é confiável no servidor proxy.
  • Se estiver a usar autenticação Active Directory no proxy, altere a conta de serviço para a conta de utilizador que pode aceder ao proxy como "Integration Runtime Service."

Mensagem de erro: Nó de tempo de execução de integração auto-hospedada/IR lógico auto-hospedado está no estado Inativo/ "Em execução (limitado)"

• Motivo

  O nó de tempo de execução integrado auto-hospedado pode ter um status de Inativo, conforme mostrado na captura de ecrã a seguir:

  

  Este comportamento ocorre quando os nós não conseguem comunicar uns com os outros.

• Resolução

  1. Inicie sessão na máquina virtual (VM) alojada no nó. Em Registos de Aplicações e Serviços>Integration Runtime, abra Event Viewer e filtre os registos de erro.

  2. Verifique se um log de erros 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 vir este erro, execute o seguinte comando numa janela da Linha de Comandos:

     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" mostrado na captura de tela a seguir, entre em contato com o departamento de TI para obter ajuda para corrigir esse problema. Depois de conseguires fazer telnet com sucesso, contacta o Microsoft Support se ainda tiveres problemas com o estado do nó de integração em tempo de execução.

     Screenshot do erro de linha de comando "Não foi possível abrir a conexão com o host".

  5. Verifique se o registo de erros 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, experimente um dos métodos seguintes:

     • Coloque todos os nós no mesmo domínio.
     • Adicione o mapeamento de IP ao ficheiro de hosts de todas as VMs alojadas.

Problema de conectividade entre o IR auto-hospedado e a sua fábrica de dados ou instância do Azure Synapse, ou o IR auto-hospedado e a fonte ou sumidouro de dados

Para resolver o problema da conectividade de rede, deve saber como recolher o rastreio de rede, compreender como usá-lo e analisar o rastreio do Microsoft Network Monitor (Netmon) antes de aplicar as Ferramentas Netmon em casos reais a partir do IR auto-hospedado.

• Sintomas

  Pode ser necessário ocasionalmente resolver certas questões de conectividade entre o IR auto-hospedado e a sua fábrica de dados ou instância do Azure Synapse, como mostrado na captura de ecrã seguinte, ou entre o IR auto-hospedado e a fonte ou sumidouro de dados.

  

  Em qualquer dos casos, poderá encontrar os seguintes erros:

  • "Cópia falhou com erro:Tipo=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Mensagem=Não é possível ligar-se ao SQL Server: 'endereço IP'"

  • “Ocorreu um ou mais erros. Ocorreu um erro durante o envio do pedido. A ligação subjacente foi encerrada: ocorreu um erro inesperado numa receção. Não é possível ler os dados da ligação de transporte: uma ligação existente foi forçada a fechar por um anfitrião remoto. Uma ligação existente foi forçada a fechar pelo ID de Atividade de anfitrião remoto”.

• Resolução

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

  • Colete um rastreamento 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 do servidor é o servidor Data Factory.

       

    2. Quando você recebe o pacote de redefinição, você pode encontrar a conversa seguindo o protocolo TCP (Transmission Control Protocol).

       

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

  • Uma análise do rastreamento Netmon que você coletou mostra que o total de Tempo de Vida (TTL)) é 64. De acordo com os valores mencionados no artigo IP Time to Live (TTL) e Hop Limit Basics , extraídos na lista a seguir, você pode ver que é o sistema Linux que redefine o pacote e causa a desconexão.

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

    • Kernel Linux 2.4 (cerca de 2001): 255 para TCP, UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol)
    • Kernel Linux 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 chega ao seu 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 produzir o TTL final.

    Neste caso, você pode ver que uma redefinição pode ser enviada do sistema Linux com TTL 64.

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

    Pacote de rede do Linux System A com TTL 64 -> B TTL 64 menos 1 = 63 -> C TTL 63 menos 1 = 62 -> TTL 62 menos 1 = 61 IR auto-hospedado

  • Numa situação ideal, o número de saltos TTL seria 128, o que significa que o sistema operativo Windows está a executar a sua instância de fábrica de dados. Como mostrado no exemplo a seguir, 128 menos 107 = 21 saltos, o que significa que 21 saltos para o pacote foram enviados da instância do data factory para o IR auto-hospedado durante o handshake TCP 3.

    

    Portanto, é necessário contactar a equipa de rede para verificar qual é o quarto salto do IR autogerido. Se for o firewall, como acontece com o sistema Linux, verifique todos os logs para ver por que esse dispositivo redefine o pacote após o handshake TCP 3.

    Se não tiveres certeza de onde investigar, tenta obter o rastreamento Netmon do IR auto-hospedado e do firewall durante o período de problema. Essa abordagem ajudará você a descobrir qual dispositivo pode ter redefinido o pacote e causado a desconexão. Nesse caso, você também precisa envolver sua equipe de rede para avançar.

Analise o rastreamento Netmon

Quando você tenta telnet 8.8.8.8 888 com o rastreamento Netmon coletado, você deve ver o rastreamento nas seguintes capturas de tela:

As imagens anteriores mostram que não foi possível estabelecer uma conexão TCP com o servidor 8.8.8.8 na porta 888, então poderá ver dois pacotes SynReTransmit adicionais 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 seguintes exemplos:

• Se tu conseguires telnet 8.8.8.8 53 sem quaisquer problemas, há um handshake TCP 3 bem-sucedido e a sessão termina com um handshake TCP 4.

  

  

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

  

• O "handshake" do TCP 4 para concluir a sessão é ilustrado pelas seguintes sequências:

  

  

Determinar se esta notificação o afeta

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

Cenário 1: Comunicação de saída de um runtime de integração auto-hospedado que está a ser executado no local atrás de um firewall corporativo

Como determinar se você é 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 Configurar uma configuração de firewall e lista de permissões para endereços IP.

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

  Se você for afetado, execute a seguinte ação: até 8 de novembro de 2020, notifique sua equipe de infraestrutura de rede para atualizar sua configuração de rede para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

Cenário 2: Comunicação de saída a partir de um runtime de integração auto-hospedado que está a correr numa VM Azure dentro de uma rede virtual Azure gerida pelo cliente

Como determinar se você é afetado:

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

• Se tiver restrições nas regras de saída, verifique se está a usar etiquetas de serviço. Se estiver a utilizar etiquetas de serviço, não será afetado. Não há necessidade de alterar ou adicionar nada, porque o novo intervalo de IP está sob suas tags de serviço existentes.

  

• Você é afetado se estiver a ativar explicitamente a lista de autorização para endereços IP de saída nas configurações das regras do NSG na Azure Virtual Network.

  Se for afetado, tome a seguinte ação: até 8 de novembro de 2020, notifique a sua equipa de infraestrutura de rede para atualizar as regras NSG na configuração da sua rede virtual do Azure para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

Cenário 3: Comunicação de saída a partir do SSIS Integration Runtime numa rede virtual Azure gerida pelo cliente

Como determinar se você é afetado:

• Verifique se tem alguma regra NSG de saída numa rede privada que contenha o SQL Server Integration Services (SSIS) Integration Runtime. Se não houver restrições de saída, você não será afetado.

• Se tiver restrições nas regras de saída, verifique se está a usar etiquetas de serviço. Se estiver a utilizar etiquetas de serviço, não será afetado. Não há necessidade de alterar ou adicionar nada porque o novo intervalo de IP está sob suas tags de serviço existentes.

• Você é afetado se estiver a ativar explicitamente a lista de autorização para endereços IP de saída nas configurações das regras do NSG na Azure Virtual Network.

  Se for afetado, tome a seguinte ação: até 8 de novembro de 2020, notifique a sua equipa de infraestrutura de rede para atualizar as regras NSG na configuração da sua rede virtual do Azure para usar os endereços IP de fábrica de dados mais recentes. Para baixar os endereços IP mais recentes, vá para Descobrir tags de serviço usando arquivos JSON para download.

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

• Sintomas

  O IR auto-hospedado não conseguia ligar-se ao Azure Data Factory nem ao serviço Azure Synapse.

  Quando verifica o registo de eventos IR hospedado internamente após aceder a Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime, 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 processo de validação”.

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

  

  

• Motivo

  Existem dois motivos possíveis para este problema:

  • Motivo 1: A autoridade de certificação raiz do certificado de servidor do serviço não é confiável no computador onde o runtime de integração autoalojado está instalado.
  • Motivo 2: Está a utilizar um proxy no ambiente, o certificado de servidor do serviço é substituído pelo proxy e o certificado de servidor substituído não é considerado de confiança no computador onde o IR autoalojado está instalado.

• Resolução

  • Para o motivo 1: verifique se o certificado de servidor do serviço e a cadeia de certificados associada são de confiança no computador onde o IR autoalojado está instalado.
  • Para o motivo 2: confie na autoridade de certificação (AC) de raiz substituída no computador com o IR autoalojado ou configure o proxy para não substituir o certificado de servidor do serviço.

  Para mais informações sobre a confiança de certificados em Windows, consulte Instalação do certificado raiz confiável.

• Informações adicionais
  Implementámos um novo certificado SSL, com assinatura da DigiCert. Verifique se o DigiCert Global Root G2 está na autoridade de certificação raiz de confiança.

  

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

Conteúdos relacionados

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

• Blogue do Data Factory
• Solicitações de recursos do Data Factory

• Azure vídeos

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