Устранение неполадок автономной среды выполнения интеграции

ПРИМЕНИМО К: Azure Data Factory Azure Synapse Analytics Microsoft Purview

В этой статье рассматриваются распространенные методы устранения неполадок для локальной среды выполнения интеграции (IR) в Azure Data Factory и рабочих областях Synapse.

Сбор журналов самостоятельно размещённого IR

Azure Data Factory и Azure Synapse Analytics

В службе предусмотрена возможность просмотра и отправки журналов ошибок в случае сбоя при выполнении действий в локальной или общей среде IR. Следуйте приведенным здесь инструкциям, чтобы получить идентификатор отчета об ошибках, а затем введите идентификатор отчета для поиска связанных известных проблем.

1. На странице "Мониторинг" пользовательского интерфейса службы выберите Выполнения конвейеров.

2. В разделе Выполнения действий в столбце Ошибка выберите выделенную кнопку для отображения журналов действий, как показано на следующем снимке экрана.

   • Фабрика данных Azure
   • Azure Synapse

   

   Журналы действий отображаются в случае сбоя при выполнении действия.

   

3. Для получения дополнительной помощи выберите Отправка журналов.

   Откроется Общий доступ к журналам локальной среды выполнения интеграции с Microsoft.

   

4. Выберите журналы, которые требуется отправить.

   • Для локально размещённого IR можно передать журналы, связанные с действиями, завершившимися сбоем, или все журналы на узле локально размещённого IR.
   • Для общей среды IR можно загрузить только журналы, которые относятся к неудавшемуся действию.

5. После отправки журналов следует сохранить запись идентификатора отчета для последующего использования в случае, если требуется дополнительная помощь по устранению проблемы.

   

Microsoft Purview

Для неудачных действий Microsoft Purview, выполняемых на самостоятельно размещенном IR или общем IR, служба поддерживает просмотр и отправку журналов ошибок из Windows Event Viewer.

Вы можете просмотреть любые ошибки, которые вы видите в приведенном ниже руководстве по ошибкам. Чтобы получить рекомендации по поддержке и устранению неполадок с SHIR, может потребоваться создать идентификатор отчета об ошибке и обратиться в поддержку Microsoft.

Чтобы создать идентификатор отчета об ошибке для Microsoft Support, выполните следующие инструкции:

1. Перед началом сканирования на портале управления Microsoft Purview выполните следующие действия.

   1. Перейдите на компьютер, на котором установлена локальная среда выполнения интеграции и откройте Windows Event Viewer.
   2. Снимите журналы Windows Event Viewer в разделе Integration Runtime. Щелкните правой кнопкой мыши журналы и выберите параметр очистки журналов.
   3. Вернитесь на портал управления Microsoft Purview и запустите проверку.

2. После сканирования отобразится состояние Failed, вернитесь к виртуальной машине SHIR или компьютеру и обновите средство просмотра событий в разделе Integration Runtime.

3. Журналы действий отображаются для неудачного сеанса сканирования.

4. Для получения дополнительной помощи от Microsoft выберите Send Logs.

   Откроется окно для передачи журналов локальной среды выполнения интеграции (SHIR) в компанию Microsoft.

   

5. Выберите журналы, которые требуется отправить.

   • Для локально размещённого IR можно передать журналы, связанные с действиями, завершившимися сбоем, или все журналы на узле локально размещённого IR.
   • Для общей среды IR можно загрузить только журналы, которые относятся к неудавшемуся действию.

6. После отправки журналов следует сохранить запись идентификатора отчета для последующего использования в случае, если требуется дополнительная помощь по устранению проблемы.

   

Общая неисправность или ошибка в локальной среде IR

Проблема нехватки памяти

• Симптомы

  Ошибка OutOfMemoryException (OOM) происходит при попытке выполнить операцию выборки с использованием связанной или локальной инфраструктуры IR.

• Причина

  Новое действие может вызвать ошибку "Out Of Memory" (OOM), если на машине IR наблюдается мгновенное усиленное использование памяти. Такая неполадка может быть вызвана параллельным выполнением большого числа действий, а сама эта ошибка предусмотрена конструктивно.

• Решение

  Проверьте использование ресурсов и параллельное выполнение действий на узле IR. Чтобы избежать одновременного выполнения слишком большого количества действий на одном узле IR, настройте внутреннее время и время активации выполнения действий.

Проблема с ограничением количества параллельных заданий

• Симптомы

  При попытке увеличить ограничение количества одновременных заданий из пользовательского интерфейса процесс зависает в состоянии Обновляется.

  Пример сценария. Максимальное количество одновременных заданий в настоящее время равно 24. Требуется увеличить это значение, чтобы задания могли выполняться быстрее. Минимальное значение, которое можно ввести, равно 3, а максимальное — 32. Вы увеличиваете значение с 24 до 32, а затем нажимаете кнопку Обновить. Процесс зависает в состоянии Обновление, как показано на снимке экрана ниже. Вы обновляете страницу, но на ней по-прежнему отображается значение 24. Оно не было обновлено до 32, как вы ожидали.

  

• Причина

  Ограничение на количество параллельных заданий зависит от логического ядра и памяти компьютера. Попробуйте уменьшить значение, например до 24, а затем просмотрите результат.

  Совет

  • Дополнительные сведения о количестве ядер логики и определении количества ядер логики компьютера см. в статье Four способы поиска количества ядер в ЦП на Windows 10.
  • Чтобы узнать, как вычислить math.log, перейдите к калькулятору логарифма.

Проблема с SSL-сертификатом в локальной среде IR с высоким уровнем доступности (HA)

• Симптомы

  От рабочего узла локальной среды IR поступило следующее сообщение об ошибке:

  "Не удалось извлечь общие состояния из первичного узла net.tcp://abc.cloud.corp.Microsoft.com:8060/ExternalService.svc/." Идентификатор действия: XXXXX Не удалось построить цепочку для сертификата X.509 CN=abc.cloud.corp.Microsoft.com, OU=test, O=Microsoft. Используемый сертификат имеет цепочку доверия, которую невозможно проверить. Замените сертификат или измените certificateValidationMode. Функции отзыва не удалось проверить отзыв, так как сервер отзыва был не в сети".

• Причина

  При обработке случаев, связанных с рукопожатием SSL/TLS, могут возникнуть проблемы при проверке цепочки сертификатов.

• Решение

  • Вот быстрый и понятный способ устранения неполадок со сборкой цепочки сертификатов X.509:

    1. Экспортируйте сертификат, который необходимо проверить. Для этого выполните следующее.

       а. В Windows выберите Пуск, начните вводить сертификаты, а затем выберите Управление сертификатами компьютера.

       б. В проводнике в области слева найдите сертификат, который требуется проверить, щелкните его правой кнопкой мыши и выберите Все задачи>Экспорт.

       

    2. Скопируйте экспортированный сертификат на клиентский компьютер.

    3. На стороне клиента в окне командной строки запустите выполнение следующей команды. Не забудьте заменить <путь к сертификату> и <путь к выходному TXT-файлу> фактическими путями.

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

       Например:

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

    4. Проверьте наличие ошибок в выходном TXT-файле. Сводку ошибок можно найти в конце TXT-файла.

       Например:

       

       Если в конце файла журнала отсутствует ошибка, как показано на следующем снимке экрана, можно считать, что цепочка сертификатов на клиентском компьютере построена успешно.

       

  • Если в файле сертификата настроено расширение имени файла AIA (доступ к информации о центре сертификации), CDP (точка распространения списка отзыва сертификатов) или OCSP (Online Certificate Status Protocol), его можно проверить с помощью более интуитивно понятного способа.

    1. Для получения этих сведений проверьте данные сертификата, как показано на следующем снимке экрана.

       

    2. Выполните следующую команду. Не забудьте заменить <путь к сертификату> фактическим путем к сертификату.

         Certutil   -URL    <certificate path> 
       

       Откроется средство извлечения URL-адресов.

    3. Чтобы проверить сертификаты с расширениями имени файла AIA, CDP и OCSP, выберите Получить.

       

       Цепочка сертификатов успешно создана, если статус сертификата из AIA — Проверено, а также если статус сертификатов из CDP или OCSP — Проверено.

       Если при попытке получения данных AIA и CDP отображается сообщение об ошибке, обратитесь в команду по работе с сетями, чтобы подготовить клиентский компьютер к подключению к целевому URL-адресу. Достаточно будет проверить либо путь HTTP, либо путь LDAP.

Локальной среде IR не удалось загрузить файл или сборку

• Симптомы

  Возникает следующее сообщение об ошибке:

  "Не удалось загрузить файл или сборку "XXXXXXXXXXXXXXXX, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" либо одну из их зависимостей. Системе не удается найти указанный файл. Идентификатор действия: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

  Вот более конкретное сообщение об ошибке:

  "Не удалось загрузить файл или сборку "System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX" либо одну из их зависимостей. Системе не удается найти указанный файл. Идентификатор действия: 92693b45-b4bf-4fc8-89da-2d3dc56f27c3"

• Причина

  В мониторе процессов можно просмотреть следующий результат:

  

  Совет

  В мониторе процессов можно задать фильтры, как показано на следующем снимке экрана.

  Предыдущее сообщение об ошибке говорит, что библиотека DLL System.ValueTuple не находится в связанной папке Global Assembly Cache (GAC), в папке C:\Program Files\Microsoft Integration Runtime\4.0\Gateway или в папке C:\Program Files\Microsoft Integration RuntimeПапка \4.0\Shared.

  По сути, процесс загружает библиотеку DLL сначала из папки GAC, затем из папки Shared и, наконец, из папки Gateway. Таким образом, библиотека DLL может загружаться из любого удобного пути.

  

• Решение

  Вы найдете файл System.ValueTuple.dll в папке C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan. Чтобы устранить проблему, скопируйте файл System.ValueTuple.dll в папку C:\Program Files\Microsoft Integration Runtime\4.0\Gateway.

  Можно использовать тот же метод для устранения других проблем, связанных с отсутствием файлов или сборок.

• Дополнительные сведения об этой проблеме

  Причина, по которой отображается System.ValueTuple.dll в разделе %windir%\Microsoft.NET\assembly и %windir%\assembly это .NET поведение.

  В следующем сообщении об ошибке видно, что сборка System.ValueTuple отсутствует. Эта проблема возникает, когда приложение пытается проверить сборку System.ValueTuple.dll.

  "<LogProperties><ErrorInfo>[{"Code":0,"Message":"Инициализатор типа для 'Npgsql.PoolManager' породил исключение.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.TypeInitializationException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[{"Code":0,"Message":"Не удалось загрузить файл или сборку 'System.ValueTuple, Version=4.0.2.0, Culture=neutral, PublicKeyToken=XXXXXXXXX' либо одну из соответствующих зависимостей. Системе не удается найти указанный файл.","EventType":0,"Category":5,"Data":{},"MsgId":null,"ExceptionType":"System.IO.FileNotFoundException","Source":"Npgsql","StackTrace":"","InnerEventInfos":[]}]}]</ErrorInfo></LogProperties>"

  Подробнее о GAC см. в статье Глобальный кэш сборок.

Отсутствует ключ проверки подлинности локальной среды выполнения интеграции

• Симптомы

  Локальная среда выполнения интеграции внезапно переходит в автономный режим без ключа проверки подлинности, а в журнале событий отображается следующее сообщение об ошибке:

  "Ключ проверки подлинности еще не назначен".

  

• Причина

  • Самостоятельно размещённый узел IR или логический самостоятельно размещённый узел IR на портале Azure удалены.
  • Выполнено чистое удаление.

• Решение

  Если ни из предыдущих причин не применяется, можно перейти в папку %programdata%\Microsoft\Data Transfer\DataManagementGateway, чтобы узнать, был ли удален файл Configurations. Если файл был удалён, следуйте инструкциям в статье Netwrix Как определить, кто удалил файл на файловых серверах Windows.

  

Невозможно использовать самостоятельно развернутое IR для объединения двух локальных хранилищ данных

• Симптомы

  После создания локальных сред IR для исходного и целевого хранилищ данных необходимо соединить эти две среды IR для завершения операции копирования. Если хранилища данных настроены в разных виртуальных сетях или не поддерживают механизм шлюза, отображается одно из следующих сообщений об ошибке:

  • The driver of source cannot be found in destination IR (Не удается найти драйвер источника в целевой среде IR)
  • The source cannot be accessed by the destination IR (Источник недоступен для целевой среды IR)

• Причина

  Самостоятельно размещаемая среда выполнения (IR) разработана как центральный узел операции копирования, а не клиентский агент, который необходимо устанавливать для каждого хранилища данных.

  В этом случае необходимо создать связанную службу для каждого хранилища данных с использованием одной и той же среды выполнения IR, которая должна иметь сетевой доступ к обоим хранилищам данных. Не имеет значения, установлено ли IR в исходном или целевом хранилище данных или на отдельном от них компьютере. Если две связанные службы создаются с разными IR, но используются в одном и том же действии копирования, используется целевой IR, и драйверы для обоих хранилищ данных должны быть установлены на машину целевого IR.

• Решение

  Установите драйверы для исходного и целевого хранилищ данных в целевой среде IR и убедитесь, что у нее есть доступ к исходному хранилищу данных.

  Если трафик не может пройти через сеть между двумя хранилищами данных (например, они настроены в двух виртуальных сетях), вы не сможете завершить копирование в рамках одного действия, даже при наличии установленной среды IR. Если не удается завершить копирование в рамках одного действия, можно создать две операции копирования с двумя интеграционными средами, каждая из которых находится в одной виртуальной сети:

  • Скопируйте один IR из хранилища данных 1 в Azure Blob Storage.
  • Скопируйте другой IR из Azure Blob Storage в дата-хранилище 2.

  Это решение позволяет сымитировать соответствие требованию использовать IR для создания моста, соединяющего два неподключенных хранилища данных.

Ошибка синхронизации учетных данных приводит к потере учетных данных в режиме HA

• Симптомы

  Если учетные данные источника данных "XXXXXXXXXX" удалены из текущего узла среды выполнения интеграции с полезной нагрузкой, отображается следующее сообщение об ошибке:

  При удалении службы связей на портале Azure или если у задачи неправильная нагрузка, создайте новую службу связей повторно с вашими учетными данными.

• Причина

  Локальная среда IR создана в режиме высокой доступности с двумя узлами, но узлы не находятся в состоянии синхронизации учетных данных. Это означает, что учетные данные, хранящиеся в узле диспетчера, не синхронизируются с другими рабочими узлами. Если произойдет переключение на резервный узел с узла диспетчера на рабочий узел, но учетные данные существуют только в предыдущем узле диспетчера, то при попытке доступа к учетным данным задание завершится сбоем, и вы получите приведенное выше сообщение об ошибке.

• Решение

  Единственный способ избежать этой проблемы — проследить за тем, чтобы учетные данные в обоих узлах находились в состоянии синхронизации. Если они не синхронизированы, необходимо повторно ввести учетные данные для нового диспетчера.

Не удается выбрать сертификат, поскольку отсутствует закрытый ключ

• Симптомы

  • Вы импортировали PFX-файл в хранилище сертификатов.

  • При выборе сертификата через пользовательский интерфейс IR Configuration Manager вы получили следующее сообщение об ошибке:

    "Не удалось изменить режим шифрования коммуникации интрасети. Возможно, у сертификата <имя сертификата> нет закрытого ключа, обеспечивающего обмен ключами, или у процесса нет прав доступа к закрытому ключу. Дополнительные сведения см. в внутреннем исключении.

• Причина

  • Учетная запись пользователя имеет низкий уровень привилегий и не может получить доступ к закрытому ключу.
  • Сертификат создан как сигнатура и не предназначен для обмена ключами.

• Решение

  • Для работы с пользовательским интерфейсом используйте учетную запись с соответствующими привилегиями для доступа к закрытому ключу.

  • Импортируйте сертификат с помощью следующей команды:

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

Проблема с синхронизацией узлов локальной среды выполнения интеграции

• Симптомы

  Узлы локальной среды выполнения интеграции пытаются синхронизировать учетные данные на узлах, но процесс зависает и через некоторое время отображается приведенное ниже сообщение об ошибке:

  Узел Integration Runtime (самостоятельный) пытается синхронизировать учетные данные между другими узлами. Узел Integration Runtime (Self-hosted) пытается синхронизировать учетные данные между узлами. Это может занять несколько минут.

  Примечание.

  Если эта ошибка происходит в течение более 10 минут, проверьте подключение к узлу диспетчера.

• Причина

  Причина заключается в том, что рабочие узлы не имеют доступа к закрытым ключам. В этом можно убедиться в журналах локальной среды выполнения интеграции, как показано ниже.

  [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.

  При использовании аутентификации service principal в привязанной службе проблем с процессом синхронизации не возникает. Однако при смене типа проверки подлинности на проверку с помощью ключа учетной записи возникает проблема синхронизации. Это связано с тем, что служба локальной среды выполнения интеграции работает в учетной записи службы (NT SERVICE\DIAHostService) и ее необходимо добавить к разрешениям закрытого ключа.

• Решение

  Чтобы решить эту проблему, необходимо добавить учетную запись службы локальной среды выполнения интеграции (NT SERVICE\DIAHostService) в разрешения закрытого ключа. В этом случае можно выполнить указанные ниже действия.

  1. Откройте команду запуска Microsoft Management Console (MMC).

     

  2. В области MMC выполните следующие действия.

     

     1. Выберите Файл.
     2. В раскрывающемся меню выберите Добавить или удалить оснастку.
     3. В области "Доступные оснастки" выберите Сертификаты.
     4. Выберите Добавить.
     5. Во всплывающем окне "Оснастка сертификатов" выберите Учетная запись компьютера.
     6. Выберите Далее.
     7. На странице "Выбор компьютера" выберите Локальный компьютер (на котором запущена эта консоль) .
     8. Выберите Готово.
     9. Нажмите кнопку ОК в области "Добавление и удаление оснасток".

  3. В области консоли MMC перейдите к следующим шагам.

     

     1. В списке папок слева выберите Корень консоли > Сертификаты (локальный компьютер) > Личные > Сертификаты.
     2. Щелкните правой кнопкой мыши на Microsoft Intune Beta MDM.
     3. В раскрывающемся списке выберите Все задачи.
     4. Выберите Управление закрытыми ключами.
     5. В разделе "Имена пользователей или групп" выберите Добавить.
     6. Выберите NT SERVICE\DIAHostService, чтобы предоставить ему полный контроль доступа к этому сертификату, примените изменения и сохраните их.
     7. Выберите Проверить имена и нажмите кнопку ОК.
     8. В области "Разрешения" выберите Применить, а затем нажмите кнопку ОК.

Сообщение об ошибке UserErrorJreNotFound при выполнении действия копирования в Azure

• Симптомы

  При попытке скопировать содержимое в Microsoft Azure с помощью средства или программы на основе Java (например, копирования файлов ORC или Parquet) появится сообщение об ошибке, похожее на следующее:

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft. DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Среда выполнения не найдена. Перейдите к http://go.microsoft.com/fwlink/?LinkId=808605, чтобы скачать и установить на вашем компьютере узла самостоятельного размещения Integration Runtime. Примечание: 64-разрядная Integration Runtime требует 64-разрядного JRE; 32-разрядная Integration Runtime требует 32-разрядного JRE.,Source=Microsoft.DataTransfer.Common,'Type=System.DllNotFoundException,Message=Не удалось загрузить библиотеку DLL 'jvm.dll': не удалось найти указанный модуль. (Исключение из HRESULT: 0x8007007E),Source=Microsoft. DataTransfer.Richfile.HiveOrcBridge

• Причина

  Эта проблема возникает по одной из следующих причин:

  • Java среда выполнения (JRE) не установлена правильно на сервере Integration Runtime.

  • Сервер Integration Runtime не имеет требуемой зависимости для JRE.

  По умолчанию Integration Runtime определяет путь JRE с помощью записей реестра. Эти записи должны быть автоматически заданы во время установки JRE.

• Решение

  Внимательно выполните действия, описанные в этом разделе. Неправильное изменение реестра может привести к серьезным проблемам. Перед внесением изменений создайте резервную копию реестра для его восстановления в случае возникновения проблем.

  Чтобы устранить эту проблему и проверить состояние установки JRE, выполните следующие действия:

  1. Убедитесь, что на одной платформе установлены Integration Runtime (Diahost.exe) и JRE. Проверьте следующие условия:

     • 64-разрядный JRE для 64-разрядной среды выполнения интеграции ADF должен быть установлен в папке: C:\Program Files\Java\

       Примечание.

       Папка не C:\Program Files (x86)\Java\

     • Java Runtime (JRE) — это версия 11 или более поздней версии, от поставщика JRE, например Microsoft OpenJDK 11 или Eclipse Temurin 11. Убедитесь, что переменная системной среды JAVA_HOME задана в папку JDK (а не только в папке JRE), возможно, также потребуется добавить папку bin в переменную среды PATH системы.

  2. Проверьте реестр на наличие нужных параметров. Для этого выполните следующие действия:

     1. В меню Выполнить введите regedit и нажмите клавишу ВВОД.

     2. В области навигации выберите следующий подраздел:

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        В области сведений должна быть запись текущей версии, которая показывает версию JRE (например, 1.8).

        

     3. В области навигации выберите подключ, точно соответствующий версии (например, 1.8) в папке JRE. В области сведений должна быть запись JavaHome. Значение этой записи — путь установки JRE.

        

  3. Откройте папку bin\server по следующему пути:

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

     

  4. Проверьте, содержит ли эта папка файл jvm.dll. Если это не так, проверьте наличие файла в папке bin\client.

     

  Примечание.

  • Если какая либо из этих конфигураций не описана в этих шагах, используйте установщик Windows JRE для устранения неполадок.
  • Если все конфигурации в этих шагах правильные, как описано, в системе может отсутствовать библиотека среды выполнения VC++. Эту проблему можно решить, установив распространяемый пакет VC++ 2010.

Установка локальной среды IR

Ошибка регистрации среды выполнения интеграции

• Симптомы

  Локальную среду IR иногда требуется запустить с другой учетной записью по одной из следующих причин:

  • политика компании запрещает использование учетной записи службы;
  • требуется проверка подлинности.

  После изменения учетной записи службы на панели службы вы можете обнаружить, что среда выполнения интеграции не работает, и появится следующее сообщение об ошибке:

  Узел Integration Runtime (самостоятельный хостинг) столкнулся с ошибкой при регистрации. Не удается подключиться к службе узла Integration Runtime (собственное размещение).

  

• Причина

  Многие ресурсы предоставляются только сервисной учетной записи. При изменении учетной записи службы на другую учетную запись разрешения всех зависимых ресурсов остаются неизменными.

• Решение

  Чтобы проверить наличие ошибки, перейдите в журнал событий среды выполнения интеграции.

  

  • Если в журнале событий содержится ошибка UnauthorizedAccessException, выполните следующие действия.

    1. Проверьте учетную запись службы DIAHostService входа в систему на панели служб Windows.

       

    2. Проверьте, имеет ли учетная запись службы входа разрешения на чтение и запись для папки %programdata%\Microsoft\DataTransfer\DataManagementGateway.

       • По умолчанию, если учетная запись для входа в службу не изменена, она должна иметь разрешения на чтение и запись.

         

       • Если вы изменили учетную запись входа в службу, выполните следующие действия, чтобы устранить проблему.

         а. Выполните чистое удаление установки текущей локальной среды IR.
         б. Установите компоненты IR для локального размещения.
         с. Измените учетную запись службы, выполнив следующие действия.

         и. Перейдите в папку установки локальной среды IR, а затем перейдите в папку Microsoft Integration Runtime\4.0\Shared.
         ii. Откройте окно командной строки с более высоким уровнем привилегий. Замените <имя пользователя> и <пароль> своим именем пользователя и паролем, а затем выполните следующую команду:
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. Если вы хотите перейти на учетную запись LocalSystem, убедитесь, что для нее используется правильный формат: dmgcmd.exe -SwitchServiceAccount "NT Authority\System" "".
         Не используйте этот формат: dmgcmd.exe -SwitchServiceAccount "LocalSystem" "".
         iv. Поскольку локальная система имеет более высокий уровень привилегий, чем администратор, вы можете при необходимости изменить ее напрямую в разделе "Службы".
         в. Для учетной записи входа в службу IR можно использовать локального пользователя или пользователя домена.

         д. Зарегистрируйте среду выполнения интеграции.

  • Если ошибка "Служба 'Integration Runtime Service' (DIAHostService) не удалось запустить. Убедитесь в том, что у вас имеются достаточные привилегии для запуска системных служб", выполните следующие действия:

    1. Проверьте учетную запись службы DIAHostService входа в систему на панели служб Windows.

       

    2. Проверьте, имеет ли учетная запись службы для входа разрешение Вход в систему как служба для запуска службы Windows.

       

• Дополнительные сведения

  Если ни один из двух предыдущих шаблонов разрешения не применяется в вашем случае, попробуйте собрать следующие журналы событий Windows.

  • Журналы приложений и служб > Integration Runtime
  • Журналы Windows > Приложение

Не удается найти кнопку «Регистрация», чтобы зарегистрировать автономный IR

• Симптомы

  При регистрации локальной среды интеграции (IR) кнопка Register не отображается на панели диспетчера конфигураций.

  

• Причина

  По состоянию на выпуск Integration Runtime 3.0 кнопка Register на существующих узлах integration runtime была удалена, чтобы обеспечить более чистую и безопасную среду. Если узел был зарегистрирован в среде выполнения интеграции (в сети или в автономном режиме), для его повторной регистрации в другой среде выполнения интеграции необходимо удалить предыдущий узел, а затем установить и зарегистрировать узел.

• Решение

  1. В Control Panel удалите существующую среду выполнения интеграции.

     Внимание

     В следующем процессе выберите Да. Не оставляйте данные во время процесса удаления.

     

  2. Если у вас нет MSI-файла установщика среды выполнения интеграции, перейдите в центр загрузки, чтобы скачать последнюю версию этой среды.

  3. Установите MSI-файл и зарегистрируйте среду выполнения интеграции.

Не удалось зарегистрировать самостоятельно размещённый IR из-за использования localhost.

• Симптомы

  Вы не можете зарегистрировать self-hosted IR на новом компьютере при использовании get_LoopbackIpOrName.

  Отладка. Произошла ошибка среды выполнения. Инициализатор типов для 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' выбросил исключение. При просмотре базы данных произошла неисправимая ошибка.

  Exception detail: System.TypeInitializationException: Инициализатор типа для 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' вызвал исключение. ---> System.Net.Sockets.SocketException. При просмотре базы данных произошла неисправимая ошибка в System.Net.Dns.GetAddrInfo(строковое имя).

• Причина

  Эта проблема обычно возникает при разрешении имени хоста localhost.

• Решение

  Чтобы разместить файл и устранить проблему, используйте IP-адрес localhost 127.0.0.1.

Сбой самостоятельной установки

• Симптомы

  Невозможно удалить существующую среду выполнения интеграции (IR), установить новую среду выполнения интеграции (IR) или обновить существующую до новой версии.

• Причина

  Установка среды выполнения интеграции зависит от службы установщика Windows. Проблемы установки могут возникать по следующим причинам:

  • недостаточно свободного места на диске;
  • отсутствие необходимых разрешений;
  • Служба NT Windows заблокирована.
  • слишком высокий уровень использования ЦП;
  • MSI-файл размещен в сетевом расположении с медленной скоростью.
  • непреднамеренное изменение некоторых системных файлов или реестров.

Учетной записи службы IR не удалось получить доступ к сертификату

• Симптомы

  При установке автономного IR через Microsoft Integration Runtime Configuration Manager создается сертификат с доверенным центром сертификации (ЦС). Сертификат не удалось применить для шифрования данных, передаваемых между двумя узлами, и отображается следующее сообщение об ошибке:

  "Не удалось изменить режим шифрования связи интрасети: не удалось предоставить учетной записи службы Integration Runtime доступ к сертификату "<certificate name>". Код ошибки: 103".

• Причина

  Сертификат использует хранилище поставщика хранилища ключей (KSP), которое пока не поддерживается. На сегодняшний день локальная среда IR поддерживает только хранилище поставщика служб шифрования (CSP).

• Решение

  В этом случае рекомендуется использовать сертификаты CSP.

  Решение 1

  Чтобы импортировать сертификат, воспользуйтесь следующей командой:

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

  

  Решение 2

  Чтобы преобразовать сертификат, воспользуйтесь следующими командами:

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

  До и после преобразования:

  

  

Локальная среда выполнения интеграции версии 5.x

Для обновления до версии 5.x локальной среды выполнения интеграции требуется .NET Framework Runtime 4.7.2 или более поздней версии. На странице загрузки приведена ссылка для скачивания последней версии 4.x и последних двух версий 5.x.

Для клиентов Azure Data Factory версии 2 и Azure Synapse:

• Если автоматическое обновление установлено и вы уже обновили среду выполнения .NET Framework до версии 4.7.2 или более поздней, локальная среда выполнения интеграции будет автоматически обновлена до последней версии 5.x.
• Если автоматическое обновление включено и вы не обновили среду выполнения .NET Framework до версии 4.7.2 или более поздней, локальная среда выполнения интеграции не будет автоматически обновлена до последней версии 5.x. Сохранится текущая версия 4.x локальной среды выполнения интеграции. Вы можете увидеть предупреждение об обновлении среды выполнения .NET Framework на портале и локальном клиенте среды выполнения интеграции.
• Если автоматическое обновление отключено, и вы уже обновили среду выполнения .NET Framework до 4.7.2 или более поздней версии, вы можете скачать последнюю версию 5.x и установить ее на компьютере.
• Если автоматическое обновление отключено, и вы не обновили среду выполнения .NET Framework до версии 4.7.2 или более поздней версии. При попытке вручную установить локальную среду выполнения интеграции 5.x и зарегистрировать ключ, сначала потребуется обновить версию среды выполнения .NET Framework.

Проблемы с подключением локальной среды IR

Локальной среде выполнения интеграции не удается подключиться к облачной службе

• Симптомы

  При попытке зарегистрировать локальную среду выполнения интеграции Configuration Manager отображается следующее сообщение об ошибке:

  Узел Integration Runtime (самостоятельный хостинг) встретил ошибку при регистрации.

  Скриншот сообщения "Узел Integration Runtime (локальное размещение) столкнулся с ошибкой во время регистрации."

• Причина

  Самостоятельно размещенному IR не удается подключиться к бэкенду службы. Обычно такая проблема возникает из-за настроек брандмауэра.

• Решение

  1. Проверьте, запущена ли среда выполнения интеграции. Если да, перейдите к шагу 2.

     

  2. Если для локальной среды IR не используется прокси-сервер (вариант по умолчанию), выполните следующую команду PowerShell на том компьютере, где установлена локальная среда выполнения интеграции.

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

     Примечание.

     URL-адрес службы может различаться в зависимости от местоположения вашей инстанции фабрики данных или рабочей области Synapse. Чтобы найти URL-адрес службы, используйте страницу "Управление" в пользовательском интерфейсе вашей фабрики данных или объекта Azure Synapse, найдите среды выполнения интеграции и щелкните вашу локальную среду выполнения IR, чтобы редактировать ее. Откройте вкладку Узлы и щелкните Просмотреть URL-адреса службы.

     Ожидается примерно такой ответ:

     

  3. Если получен не тот ответ, который ожидался, воспользуйтесь одним из описанных ниже методов в зависимости от ситуации.

     • Если вы получаете сообщение Remote name could not be resolved (Не удалось разрешить удаленное имя), это указывает на проблему в службе доменных имен (DNS). Для устранения этой проблемы свяжитесь с командой по работе с сетями.
     • Если вы получаете сообщение ssl/tls cert не является доверенным, проверьте сертификат (https://wu2.frontend.clouddatahub.net/), чтобы узнать, является ли сертификат доверенным на компьютере, а затем установите общедоступный сертификат с помощью диспетчера сертификатов. Это действие должно устранить проблему.
     • Перейдите в раздел Windows>Event viewer (logs)>Applications and Services Logs>Integration Runtime и проверьте наличие любого сбоя, вызванного DNS, правилом брандмауэра. или параметры сети компании. Если вы обнаружите такую неисправность, принудительно закройте подключение. В каждой компании настройки собственной сети будут отличаться, поэтому устранение неполадок следует поручить команде по работе с сетями.

  4. Если для локальной среды выполнения интеграции настроен прокси-сервер, убедитесь, что этот прокси-сервер имеет доступ к конечной точке службы. Посмотрите пример команды в PowerShell, web requests, and 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
     

  Ожидается примерно такой ответ:

  

  Примечание.

  Рекомендации по использованию прокси-сервера:

  • Проверьте, не нужно ли добавить прокси-сервер в список надежных получателей. Если это так, включите в список надежных получателей эти домены.
  • Проверьте, является ли ssl/TLS-сертификат wu2.frontend.clouddatahub.net/ доверенным на прокси-сервере.
  • Если вы используете проверку подлинности Active Directory на прокси-сервере, измените учетную запись службы на учетную запись пользователя, которая может получить доступ к прокси-серверу как "служба Integration Runtime".

Сообщение об ошибке: Узел локальной среды выполнения интеграции или логическая локальная среда выполнения интеграции находятся в неактивном или "Ограниченном режиме работы" состоянии.

• Причина

  Узел локальной среды выполнения интеграции может находиться в состоянии Неактивно, как показано на следующем снимке экрана.

  

  Такое может происходить, если узлы не могут нормально взаимодействовать.

• Решение

  1. Войдите на виртуальную машину, размещенную на узле. В разделе Applications and Services Logs>Integration Runtime откройте Event Viewer и отфильтруйте журналы ошибок.

  2. Проверьте, содержит ли журнал ошибок следующую ошибку.

     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. В случае этой ошибки в окне командной строки выполните следующую команду:

     telnet 10.2.4.10 8060
     

  4. Если в командной строке отобразится сообщение об ошибке "Не удалось открыть подключение к этому узлу", которое показано на следующем снимке экрана, обратитесь в ИТ-отдел за помощью в устранении этой проблемы. После успешного выполнения telnet обратитесь к Microsoft Support, если у вас по-прежнему возникли проблемы с состоянием узла среды выполнения интеграции.

     

  5. Проверьте, содержит ли журнал ошибок следующую запись:

     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. Для устранения этой проблемы воспользуйтесь одним из указанных ниже способов или обоими сразу.

     • Разместите все узлы в одном домене.
     • Добавьте сопоставление IP-адресов и узлов во все файлы узлов размещенной виртуальной машины.

Проблема с подключением между самостоятельно управляемым IR и вашей фабрикой данных, экземпляром Azure Synapse, источником данных или приемником.

Чтобы устранить проблему с сетевым подключением, необходимо знать, как собирать трассировку сети, понять, как использовать ее, и проанализировать трассировку Microsoft Network Monitor (Netmon) перед применением средств Netmon в реальных случаях из автономной среды интеграции.

• Симптомы

  Иногда может потребоваться устранить определенные проблемы с подключением между самостоятельно размещенным IR и вашей фабрикой данных или экземпляром Azure Synapse, как показано на следующем снимке экрана, или между самостоятельно размещенным IR и источником данных или приемником данных.

  

  В обоих случаях могут возникать следующие ошибки:

  • "Сбой копирования с ошибкой:Type=Microsoft. DataTransfer.Common.Shared.HybridDeliveryException,Message=Не удается подключиться к SQL Server: "IP-адрес"

  • "Произошла одна или более ошибок. Произошла ошибка при отправке запроса. Базовое соединение закрыто. Непредвиденная ошибка при приеме. Не удается прочитать данные из транспортного соединения. Удаленный хост принудительно разорвал существующее подключение. Удаленный хост принудительно разорвал существующее подключение (идентификатор действия)".

• Решение

  В случае возникновения предыдущих ошибок следуйте инструкциям из этого раздела для их устранения.

  • Получите трассировку Netmon для анализа:

    1. Вы можете настроить фильтр для просмотра сброса с сервера на стороне клиента. На следующем снимке экрана показан пример, где стороной сервера является сервер Фабрики данных.

       

    2. При получении пакета сброса можно найти беседу, следуя протоколу управления передачей (TCP).

       

    3. Получите диалог между клиентом и сервером Data Factory, убрав фильтр.

  • Анализ трассировки с помощью Netmon, которую вы собрали, показывает, что общее время жизни (TTL) составляет 64. В соответствии со значениями, указанными в статье Основные сведения о предельных значениях срока жизни и числа прыжков для протокола IP, выдержка из которой приведена в следующем списке, можно установить, что это система Linux, которая сбрасывает пакет и вызывает отключение.

    Значения TTL и предельное число прыжков по умолчанию варьируются в разных операционных системах, как указано здесь.

    • Ядро Linux 2.4 (около 2001 года): 255 для TCP, UDP и ICMP
    • Ядро Linux 4.10 (2015): 64 для TCP, UDP и ICMP
    • Windows XP (2001): 128 для TCP, UDP и ICMP
    • Windows 10 (2015): 128 для TCP, UDP и ICMP
    • Windows Server 2008: 128 для TCP, UDP и ICMP
    • Windows Server 2019 (2018): 128 для TCP, UDP и ICMP
    • macOS (2001): 64 для TCP, UDP и ICMP

    

    В предыдущем примере время жизни (TTL) отображается как 61 вместо 64, потому что, когда сетевой пакет достигает места назначения, ему нужно проходить через различные узлы, такие как маршрутизаторы или сетевые устройства. Для получения окончательного значения TTL из него вычитается число маршрутизаторов или сетевых устройств.

    В этом случае вы можете увидеть, что сброс может быть отправлен из системы Linux с TTL 64.

  • Чтобы определить, какое устройство инициирует сброс, проверьте четвертый прыжок из локальной среды IR.

    Сетевой пакет из системы Linux A с TTL 64 -> из системы B TTL 64 минус 1 = 63 -> из системы C TTL 63 минус 1 = 62 -> TTL 62 минус 1 = 61 для автономной конфигурации IR

  • В идеальной ситуации число прыжков TTL будет равно 128, что означает, что операционная система Windows выполняет экземпляр вашей фабрики данных. Как показано в следующем примере, 128 минус 107 = 21 переход. Это означает, что во время трёхэтапного рукопожатия TCP пакет прошёл через 21 переход из инстанса фабрики данных на локальный сервер IR.

    

    Поэтому необходимо обратиться к сетевой команде, чтобы выяснить, каким был четвертый переход с собственным размещением IR. Если это брандмауэр, как в системе Linux, проверьте все журналы, чтобы узнать, почему устройство сбрасывает пакет после подтверждения TCP 3.

    Если вы не знаете, где искать причину, попытайтесь получить трассировку Netmon из локальной среды IR и брандмауэра во время возникновения проблемы. Этот подход поможет вам определить, какое устройство могло сбросить пакет и которое привело к отсоединению. В этом случае для выполнения дальнейших действий также необходимо привлечь команду по работе с сетями.

Анализ трассировки Netmon

При попытке подключения через Telnet к 8.8.8.8 888 с собранной трассировкой Netmon, вы должны увидеть ее на следующих снимках экрана.

На приведенных выше изображениях показано, что установить TCP-подключение на стороне сервера 8.8.8.8 через порт 888 не удалось, поэтому здесь отображается два дополнительных пакета SynReTransmit. Поскольку источнику SELF-HOST2 не удалось подключиться к серверу 8.8.8.8 с помощью первого пакета, он продолжит попытки установить соединение.

В следующих примерах показаны успешные сценарии.

• Если вы можете установить подключение Telnet 8.8.8.8 53 без каких-либо проблем, то подтверждение TCP 3 будет успешным, а сеанс завершится с подтверждением TCP 4.

  

  

• Предыдущий трёхэтапный обмен TCP создает следующую последовательность действий:

  

• TCP 4-х шаговое рукопожатие для завершения сеанса иллюстрируется следующими последовательностями:

  

  

Определите, влияет ли на вас это уведомление

Это уведомление касается следующих сценариев:

Сценарий 1. Исходящий трафик из локальной среды выполнения интеграции, которая работает локально за корпоративным брандмауэром

Как определить, затронуло ли это вас:

• Если вы определяете правила брандмауэра на основе полных доменных имен (FQDN), которые используют подход, описанный в разделе Настройка конфигурации брандмауэра и списка разрешений для IP-адресов, это вас не касается.

• Если вы явно включили список разрешенных для исходящих IP-адресов в корпоративном брандмауэре, это вас касается.

  Если оно вас касается, выполните следующее. До 8 ноября 2020 года сообщите представителям команды по работе с сетевой инфраструктурой, что они должны обновить конфигурацию сети и использовать в ней новейшие IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Сценарий 2. Исходящее взаимодействие из локальной среды выполнения интеграции, работающей на виртуальной машине Azure в управляемой клиентом виртуальной сети Azure

Как определить, затронуло ли это вас:

• Проверьте, есть ли у вас правила группы безопасности сети (NSG) для исходящего трафика в частной сети, содержащей локальную среду выполнения интеграции. Если ограничения для исходящего трафика отсутствуют, это на вас не влияет.

• Если у вас есть ограничения на правила для исходящего трафика, проверьте, используются ли теги службы. Если вы используете теги сервиса, это вас не затрагивает. Нет необходимости что-либо изменять или добавлять, так как новый диапазон IP-адресов охватывает имеющиеся теги службы.

  

• Вы подвержены влиянию, если вы явно включаете разрешающий список для исходящих IP-адресов в настройках правил NSG в виртуальной сети Azure.

  Если вы затронуты, выполните следующие действия: к 8 ноября 2020 г. сообщите группе сетевой инфраструктуры, чтобы обновить правила NSG в конфигурации виртуальной сети Azure, чтобы использовать последние IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Сценарий 3. Исходящая коммуникация из SSIS Integration Runtime в управляемой клиентом виртуальной сети Azure.

Как определить, затронуло ли это вас:

• Проверьте наличие правил NSG для исходящего трафика в частной сети, содержащей SQL Server Integration Services (SSIS) Integration Runtime. Если ограничения для исходящего трафика отсутствуют, это на вас не влияет.

• Если у вас есть ограничения на правила для исходящего трафика, проверьте, используются ли теги службы. Если вы используете теги сервиса, это вас не затрагивает. Нет необходимости что-либо изменять или добавлять, так как новый диапазон IP-адресов входит в существующие теги службы.

• Вы подвержены влиянию, если вы явно включаете разрешающий список для исходящих IP-адресов в настройках правил NSG в виртуальной сети Azure.

  Если вы затронуты, выполните следующие действия: к 8 ноября 2020 г. сообщите группе сетевой инфраструктуры, чтобы обновить правила NSG в конфигурации виртуальной сети Azure, чтобы использовать последние IP-адреса фабрики данных. Чтобы скачать новейшие IP-адреса, перейдите к разделу Обнаружение тегов службы с помощью скачиваемых файлов JSON.

Не удалось установить доверительные отношения для защищенного канала SSL/TLS

• Симптомы

  Локальная среда IR не могла подключиться к службе Azure Data Factory или Azure Synapse.

  При проверке локального журнала событий IR после перехода в Windows>Просмотр событий (журналы)>Журналы приложений и служб>Среда выполнения интеграции, вы найдете следующее сообщение об ошибке.

  "Базовое соединение закрыто. Не удалось установить доверительные отношения для защищенного канала SSL/TLS. Удаленный сертификат недопустим согласно процедуре проверки".

  Самый простой способ проверить сертификат сервера службы — открыть ее URL-адрес в браузере. Например, откройте ссылку на сертификат сервера проверки (https://eu.frontend.clouddatahub.net/) на компьютере, где установлена локальная среда IR, а затем просмотрите сведения о сертификате сервера.

  

  

• Причина

  Эта ошибка может произойти по двум причинам:

  • Причина 1. Корневой центр сертификации сертификата сервера службы не является доверенным на компьютере, где установлена локальная среда IR.
  • Причина 2. Вы используете прокси-сервер в своей среде, сертификат сервера службы заменяется прокси-сервером, а замененный сертификат сервера не является доверенным для компьютера, на котором установлена локальная среда IR.

• Решение

  • По причине 1: Убедитесь, что сертификат сервера службы и его цепочка сертификатов являются доверенными для компьютера, на котором установлена локальная среда IR.
  • В случае причины 2. Обозначьте замененный корневой центр сертификации на компьютере локальной среды IR как доверенный либо настройте прокси-сервер так, чтобы он не заменил сертификат сервера службы.

  Дополнительные сведения о доверии сертификатам в Windows см. в разделе Установка доверенного корневого сертификата.

• Дополнительные сведения
  Мы развернули новый SSL-сертификат, подписанный компанией DigiCert. Проверьте, находится ли Digicert Global Root G2 в доверенном корневом центре сертификации.

  

  Если он не находится в доверенном корневом центре сертификации, скачайте его здесь.

Связанный контент

Дополнительные сведения об устранении неполадок см. в статьях, указанных ниже.

• Блог о Фабрике данных
• Запросы на добавление функции в Фабрику данных

• Azure видео

• Страница вопросов и ответов Microsoft
• Форум Stack Overflow по Фабрике данных
• Сведения о Data Factory X
• Руководство по производительности сопоставления потоков данных