針對自我裝載整合執行階段進行疑難排解

適用於：Azure Data Factory Azure Synapse Analytics Microsoft Purview

提示

試用 Microsoft Fabric 中的 Data Factory，這是適用於企業的全方位分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告的所有項目。 了解如何免費開始新的試用！

本文探討 Azure Data Factory 和 Synapse 工作區中的自我裝載整合執行階段 (IR) 常見的疑難排解方法。

收集自我裝載 IR 記錄

Azure Data Factory 和 Azure Synapse Analytics

對於在自我裝載 IR 或共用 IR 上執行的失敗活動，此服務支援檢視和上傳錯誤記錄檔。 若要取得錯誤報表識別碼，請遵循這裡的指示，然後輸入報告識別碼來搜尋相關的已知問題。

1. 在服務 UI 的 [監視] 頁面上，選取 [管線執行]。

2. 在 [活動執行] 下的 [錯誤] 資料行中，選取醒目提示的按鈕以顯示活動記錄，如下列螢幕擷取畫面所示：

   Azure Data Factory

   

   Azure Synapse

   

   失敗活動執行的活動記錄隨即出現。

   

3. 如需進一步的協助，請選取 [傳送記錄]。

   [與 Microsoft 分享自我裝載整合執行階段 (IR) 記錄] 視窗隨即開啟。

   

4. 選取您要傳送的記錄。

   • 針對 [自我裝載 IR]，您可以上傳與失敗活動相關的記錄，或自我裝載 IR 節點上的所有記錄。
   • 針對 [共用 IR]，您只能上傳與失敗活動相關的記錄。

5. 上傳記錄時，請將報表識別碼記下來，以供稍後需要進一步協助來解決問題時使用。

   

注意

記錄檢視和上傳要求是在所有線上自我裝載 IR 執行個體上執行。 如果遺漏任何記錄，請確定所有自我裝載 IR 執行個體都已上線。

Microsoft Purview

針對在自我裝載 IR 或共用 IR 上執行的失敗 Microsoft Purview 活動，此服務支援從 Windows 事件檢視器檢視和上傳錯誤記錄檔。

您可以在下列錯誤指南中查閱所看到的任何錯誤。 若要取得 SHIR 問題的支援和疑難排解指導，您可能需要產生錯誤報告識別碼，並連絡 Microsoft 支援服務。

若要產生 Microsoft 支援服務的錯誤報告識別碼，請遵循下列指示：

1. 在 Microsoft Purview 治理入口網站中開始掃描之前：

   1. 瀏覽至自我裝載整合執行階段安裝所在的機器，然後開啟 Windows 事件檢視器。
   2. 清除 [整合執行階段] 區段中的 Windows 事件檢視器記錄。 以滑鼠右鍵按一下記錄，然後選取 [清除記錄] 選項。
   3. 往回瀏覽 Microsoft Purview 治理入口網站，然後開始掃描。

2. 掃描顯示失敗狀態後，請往回瀏覽 SHIR VM 或機器，然後在 [整合執行階段] 區段中重新整理事件檢視器。

3. 失敗掃描執行的活動記錄隨即出現。

4. 如需 Microsoft 的進一步協助，請選取 [傳送記錄]。

   [與 Microsoft 共用自我裝載整合執行階段 (SHIR) 記錄] 視窗隨即開啟。

   

5. 選取您要傳送的記錄。

   • 針對 [自我裝載 IR]，您可以上傳與失敗活動相關的記錄，或自我裝載 IR 節點上的所有記錄。
   • 針對 [共用 IR]，您只能上傳與失敗活動相關的記錄。

6. 上傳記錄時，請將報表識別碼記下來，以供稍後需要進一步協助來解決問題時使用。

   

注意

記錄檢視和上傳要求是在所有線上自我裝載 IR 執行個體上執行。 如果遺漏任何記錄，請確定所有自我裝載 IR 執行個體都已上線。

自我裝載 IR 常見失敗或錯誤

記憶體不足問題

• 徵兆

  當您嘗試使用連結 IR 或自我裝載 IR 來執行查閱活動時，發生 OutOfMemoryException (OOM) 錯誤。

• 原因

  如果 IR 機器遇到瞬間的高記憶體使用量，新的活動可能擲回 OOM 錯誤。 問題可能起因於大量並行活動，而錯誤是刻意設計。

• 解決方法

  檢查 IR 節點上的資源使用狀況和並行活動執行。 調整活動執行的內部和觸發時間，以避免單一 IR 節點上同時執行太多活動。

並行作業數限制問題

• 徵兆

  從 UI 嘗試提高並行作業限制時，程序停留在「更新中」狀態。

  範例情節：並行作業最大值目前設定為 24，您想要提高計數讓作業執行更快。 您可以輸入的最小值為 3，最大值為 32。 您將值從 24 增加到 32，然後選取 [更新] 按鈕。 流程陷入「更新中」狀態，如下列螢幕擷取畫面所示。 您重新整理頁面，但值仍顯示為 24。 並未如預期更新為 32。

  

• 原因

  並行作業數目的限制取決於電腦的邏輯核心和記憶體。 嘗試將值向下調整到例如 24，然後檢視結果。

  提示

  • 若要深入了解邏輯核心計數，並判斷機器的邏輯核心計數，請參閱在 Windows 10 上找出 CPU 核心數目的四種方式。
  • 若要了解如何計算 math.log，請前往對數計算機。

自我裝載 IR 高可用性 (HA) SSL 憑證問題

• 徵兆

  自我裝載 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. 匯出需要驗證的憑證。 若要這樣做，請執行下列動作：

       a. 在 Windows 中，選取 [開始]，開始輸入憑證，然後選取 [管理電腦憑證]。

       b. 在檔案總管的左窗格中，搜尋您要檢查的憑證、以滑鼠右鍵按一下該憑證，然後選取 [所有工作] > [匯出]。

       

    2. 將匯出的憑證複製到用戶端機器。

    3. 在用戶端的命令提示字元視窗中，執行下列命令。 請務必將 <certificate path> 和 <output txt file path> 換成實際路徑。

       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 (CRL 發佈點) 或 OCSP (線上憑證狀態通訊協定) 副檔名是在憑證檔案中設定，您可以用更直覺的方式來檢查：

    1. 檢查憑證詳細資料以取得這項資訊，如下列螢幕擷取畫面所示：

       

    2. 執行下列命令。 請務必將 <certificate path> 換成憑證的實際路徑。

         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 不在相關的「全域組件快取」(GAC) 資料夾、C:\Program Files\Microsoft Integration Runtime\4.0\Gateway 資料夾或 C:\Program Files\Microsoft Integration Runtime\4.0\Shared 資料夾中。

  基本上，此程序依序從 GAC 資料夾、Shared 資料和 Gateway 資料夾載入 DLL。 因此，您可以從任何可用的路徑載入 DLL。

  

• 解決方法

  您會在 C:\Program Files\Microsoft Integration Runtime\4.0\Gateway\DataScan 資料夾中找到 System.ValueTuple.dll 檔案。 若要解決此問題，請將 System.ValueTuple.dll 檔案複製到 C:\Program Files\Microsoft Integration Runtime\4.0\Gateway 資料夾。

  您可以使用相同的方法來解決其他遺失的檔案或元件問題。

• 有關此問題的詳細資訊

  您在 %windir%\Microsoft.NET\assembly 和 %windir%\assembly 下看到 System.ValueTuple.dll 是因為這是 .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 節點或在 Azure 入口網站中的邏輯自我裝載 IR。
  • 執行了完整的解除安裝。

• 解決方法

  如果都不是上述原因，您可以移至 %programdata%\Microsoft\Data Transfer\DataManagementGateway 資料夾，查看是否已刪除 Configurations 檔案。 如果已刪除，請依照偵測哪些人從 Windows 檔案伺服器刪除檔案 Netwrix 文章的指示。

  

無法使用自我裝載 IR 來橋接兩個內部部署資料存放區

• 徵兆

  建立來源和目的地資料存放區的自我裝載 IR 之後，您想將兩個 IR 連線在一起，以完成複製活動。 如果資料存放區是在不同的虛擬網路中設定，或資料存放區無法了解閘道機制，您會收到下列其中一個錯誤：

  • 「在目的地 IR 中找不到來源的驅動程式」
  • 「目的地 IR 無法存取來源」

• 原因

  自我裝載 IR 設計為複製活動的中央節點，而不是每個資料存放區都需要安裝的用戶端代理程式。

  在此情況下，您應該為具有相同 IR 的每個資料存放區建立連結的服務，而 IR 應該能夠透過網路存取這兩個資料存放區。 無論 IR 是安裝在來源資料存放區或目的地資料存放區，還是在第三台電腦上。 如果有兩個連結的服務是使用不同 IR 所建立，但是在相同的複製活動中使用，則會使用目的地 IR，而您必須在目的地 IR 電腦上安裝這兩個資料存放區的驅動程式。

• 解決方法

  將來源和目的地資料存放區驅動程式安裝在目的地 IR 上，並確定其可以存取來源資料存放區。

  如果流量無法在兩個資料存放區之間通過網路 (例如，是在兩個虛擬網路中設定的)，您可能無法在一個活動中完成複製，即使已安裝 IR 也是一樣。 如果您無法在單一活動中完成複製作業，您可以建立具有兩個 IR 的兩個複製活動，VENT 中各一個：

  • 從資料存放區 1 將一個 IR 複製到 Azure Blob 儲存體
  • 將另一個 IR 從 Azure Blob 儲存體複製到資料存放區 2。

  這個解決方案可能會模擬使用 IR 來建立連線兩個已中斷連線資料存放區之橋接器的需求。

認證同步問題導致高可用性遺失認證

• 徵兆

  如果從帶有承載的目前整合執行階段節點中刪除資料來源認證 "XXXXXXXXXX"，您會收到下列錯誤訊息：

  「當您在 Azure 入口網站上刪除連結服務，或工作具有錯誤的承載時，請以您的認證再次建立新的連結服務。」

• 原因

  在具有兩個節點的高可用性模式下建立自我裝載 IR，但節點未處於認證同步狀態。 這表示儲存在發送器節點中的認證不會同步至其他背景工作節點。 如果從發送器節點到背景工作節點發生任何容錯移轉，而且認證只存在於前一個發送器節點中，則當您嘗試存取認證時，工作會失敗，您也會收到上述錯誤。

• 解決方法

  避免此問題的唯一方法是確保兩個節點都處於認證同步狀態。 如果不同步，則您必須為新的發送器重新輸入認證。

因為遺失私密金鑰而無法選擇憑證

• 徵兆

  • 您將 PFX 檔案匯入至憑證存放區。

  • 透過 IR Configuration Manager UI 選取憑證時，您會收到下列錯誤訊息：

    「無法變更內部網路通訊加密模式」。 可能是憑證 '<certificate name>' 的私密金鑰沒有金鑰交換的能力，或是處理序對該私密金鑰不具有存取權限。 如需詳細資訊，請參閱內部例外狀況。」

• 原因

  • 使用者帳戶具有低權限層級，而且無法存取私密金鑰。
  • 所產生的憑證會用於簽章，而非用於金鑰交換。

• 解決方法

  • 若要操作 UI，請使用具有適當權限的帳戶來存取私密金鑰。

  • 透過執行下列命令匯入憑證：

    certutil -importpfx FILENAME.pfx AT_KEYEXCHANGE
    

自我裝載整合執行時間節點未同步問題

• 徵兆

  自我裝載整合執行時間節點會嘗試在節點之間同步認證，但會在過程中停滯，並在一段時間之後遇到下列錯誤訊息：

  「Integration Runtime (自我裝載) 節點正嘗試在節點之間同步認證。 可能需要幾分鐘的時間。」

  注意

  如果此錯誤出現超過 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.

  當您在連結服務中使用服務主體驗證時，同步程序沒有任何問題。 但是，當您將驗證類型切換到帳戶金鑰時，就會開始出現同步問題。 這是因為自我裝載整合執行階段服務是在服務帳戶 (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. 在 [權限] 窗格中，選取 [套用]，然後選取 [確定]。

對 Azure 執行複製活動時出現 UserErrorJreNotFound 錯誤訊息

• 徵兆

  當您嘗試使用以 JAVA 為基礎的工具或程式將內容複寫到 Microsoft Azure 時 (例如，複製 ORC 或 Parquet 格式檔案)，您收到類似下列的錯誤訊息：

  ErrorCode=UserErrorJreNotFound,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Java Runtime Environment is not found. Go to http://go.microsoft.com/fwlink/?LinkId=808605 to download and install on your Integration Runtime (Self-hosted) node machine. Note 64-bit Integration Runtime requires 64-bit JRE and 32-bit Integration Runtime requires 32-bit JRE.,Source=Microsoft.DataTransfer.Common,''Type=System.DllNotFoundException,Message=Unable to load DLL 'jvm.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E),Source=Microsoft.DataTransfer.Richfile.HiveOrcBridge

• 原因

  發生此問題有下列其中一個原因：

  • Integration Runtime 伺服器上未正確安裝 Java Runtime Environment (JRE)。

  • Integration Runtime 伺服器缺少 JRE 所需的相依性。

  Integration Runtime 預設使用登錄項目來解析 JRE 路徑。 JRE 安裝期間應該會自動設定這些項目。

• 解決方法

  請仔細依循本節中的步驟。 如果您未正確修改登錄，可能會發生嚴重問題。 在修改之前，備份登錄以供還原，以免發生問題。

  若要修正此問題，請遵循下列步驟來確認 JRE 安裝的狀態：

  1. 請確定 Integration Runtime (Diahost.exe) 和 JRE 都安裝在相同的平台上。 檢查下列情況：

     • 64 位元 ADF Integration Runtime 的 64 位元 JRE 應該安裝在下列資料夾中：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，然後按 Enter 鍵。

     2. 在瀏覽窗格中，找出下列子機碼：

        HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment.

        在 [詳細資料] 窗格中，應該有 Current Version 項目顯示 JRE 版本 (例如 1.8)。

        

     3. 在瀏覽窗格中，在 JRE 資料夾下找出與版本完全相符的子機碼 (例如 1.8)。 在詳細資料窗格中，應該有 JavaHome 項目。 此項目的值為 JRE 安裝路徑。

        

  3. 在下列路徑中找出 bin\server 資料夾：

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

     

  4. 檢查此資料夾是否包含 jvm.dll 檔案。 如果沒有，請檢查 bin\client 資料夾中有無此檔案。

     

  注意

  • 如果其中有任何設定與這些步驟所述不符，請使用 JRE Windows Installer 來修正問題。
  • 如果上述步驟中的所有設定都符合所述，則表示系統中可能遺漏 VC++ 執行階段程式庫。 您可以安裝 VC++ 2010 可轉散發套件來修正此問題。

自我裝載 IR 設定

整合執行階段註冊錯誤

• 徵兆

  基於下列其中一個原因，您有時可能想要在不同的帳戶中執行自我裝載 IR：

  • 公司原則不允許服務帳戶。
  • 需進行某項驗證。

  在服務窗格上變更服務帳戶之後，您可能會發現整合執行階段停止運作，且收到下列錯誤訊息：

  「Integration Runtime (自我裝載) 節點在註冊期間發生錯誤。 無法連線至 Integration Runtime (自我裝載) 主機服務。」

  

• 原因

  許多資源僅授與服務帳戶。 當您將服務帳戶變更為另一個帳戶時，所有相依資源的權限都會保持不變。

• 解決方法

  移至整合執行階段事件記錄檔來檢查錯誤。

  

  • 如果事件記錄檔中的錯誤是 "UnauthorizedAccessException"，請執行下列動作：

    1. 在 Windows 服務面板中查看 DIAHostService 登入服務帳戶。

       

    2. 檢查登入服務帳戶是否具有 %programdata%\Microsoft\DataTransfer\DataManagementGateway 資料夾的讀取/寫入權限。

       • 根據預設，如果服務登入帳戶未變更，則應有讀取/寫入權限。

         

       • 如果您已變更服務登入帳戶，請執行下列動作以減輕問題：

         a. 執行目前自我裝載 IR 的全新解除安裝。
         b. 安裝自我裝載 IR 位元。
         c. 執行下列動作以變更服務帳戶：

         i. 移至自我裝載 IR 安裝資料夾，然後切換至 Microsoft Integration Runtime\4.0\Shared 資料夾。
         ii. 使用提高的權限開啟 [命令提示字元] 視窗。 將 <user> 和 <password> 換成您自己的使用者名稱和密碼，然後執行下列命令：
         dmgcmd.exe -SwitchServiceAccount "<user>" "<password>"
         iii. 如果您想要變更為 LocalSystem 帳戶，請務必對此帳戶使用正確的格式：dmgcmd.exe -SwitchServiceAccount "NT Authority\System" ""
         請勿使用此格式：dmgcmd.exe -SwitchServiceAccount "LocalSystem" ""
         iv. (選擇性) 由於 Local System 的權限高於 Administrator，您也可以直接在「服務」中變更。
         v. 您可以使用本機/網域使用者作為 IR 服務登入帳戶。

         d. 註冊整合執行階段。

  • 如果錯誤為「服務 'Integration Runtime Service' (DIAHostService) 無法啟動。 請確認您有足夠權限可以啟動系統服務」，請執行下列動作：

    1. 在 Windows 服務面板中查看 DIAHostService 登入服務帳戶。

       

    2. 檢查登入服務帳戶是否具有以服務方式登入權限可啟動 Windows 服務：

       

• 詳細資訊

  如果上述兩種解決模式都未能解決您的情況，請嘗試收集下列 Windows 事件記錄檔：

  • 應用程式及服務記錄檔 > Integration Runtime
  • Windows 記錄 > 應用程式

找不到 [註冊] 按鈕以註冊自我裝載 IR

• 徵兆

  當您註冊自我裝載 IR 時，Configuration Manager 窗格中不會出現 [註冊] 按鈕。

  

• 原因

  自 Integration Runtime 3.0 版起，現有整合執行階段節點上的 [註冊] 按鈕已移除，為您提供更簡潔、更安全的環境。 若某個節點已註冊到某個整合執行階段 (無論是否為線上)，若要將該節點重新註冊至另一個整合執行階段，必須先解除安裝舊有的節點，再安裝並註冊該節點。

• 解決方法

  1. 在主控台，解除安裝現有的整合執行階段。

     重要

     在下列程序中，選取 [是]。 請勿在解除安裝的過程中保留資料。

     

  2. 如果您沒有整合執行階段安裝程式 MSI 檔案，請前往下載中心下載最新的整合執行階段。

  3. 安裝 MSI 檔案，並註冊整合執行階段。

因 localhost 而無法註冊自我裝載 IR

• 徵兆

  使用 get_LoopbackIpOrName 時，無法在新機器上註冊自我裝載 IR。

  偵錯：發生執行階段錯誤。 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' 的類型初始設定式擲回例外狀況。 資料庫查閱期間發生無法復原的錯誤。

  例外狀況詳細資料： System.TypeInitializationException: 'Microsoft.DataTransfer.DIAgentHost.DataSourceCache' 的型別初始設定式擲回例外狀況。 ---> System.Net.Sockets.SocketException: System.Net.Dns.GetAddrInfo(String name) 在資料庫查閱期間發生無法復原的錯誤。

• 原因

  此問題通常在解析 localhost 時發生。

• 解決方法

  使用 localhost IP 位址 127.0.0.1 來裝載檔案並解決問題。

自我裝載安裝失敗

• 徵兆

  您無法解除安裝現有的 IR、安裝新的 IR，或將現有的 IR 升級至新的 IR。

• 原因

  整合執行階段安裝依賴 Windows Installer 服務。 您可能因為下列原因而遇到安裝問題：

  • 可用的磁碟空間不足。
  • 缺少權限。
  • Windows NT 服務已鎖定。
  • CPU 使用率太高。
  • MSI 檔案裝載於緩慢的網路位置。
  • 意外修改某些系統檔案或登錄。

IR 服務帳戶無法擷取憑證存取權

• 徵兆

  當您透過 Microsoft Integration Runtime Configuration Manager 安裝自我裝載 IR 時，產生一個具有受信任憑證授權單位 (CA) 的憑證。 無法套用此憑證來加密兩個節點之間的通訊，且出現下列錯誤訊息：

  「無法變更內部網路通訊加密模式：無法將憑證 '<certificate name>' 的存取權授與 Integration Runtime 服務帳戶。 錯誤碼 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 v2 和 Azure Synapse Analytics 客戶：

• 如果自動更新已啟用，且您已將 .NET Framework Runtime 升級至 4.7.2 或更新版本，自我裝載整合執行階段會自動升級至最新的 5.x 版。
• 如果自動更新已啟用，但您尚未將 .NET Framework Runtime 升級至 4.7.2 或更新版本，自我裝載整合執行階段不會自動升級至最新的 5.x 版。 自我裝載整合執行階段會停留在目前的 4.x 版。 在入口網站和自我裝載整合執行階段用戶端，您會看到有關 .NET Framework Runtime 升級的警告。
• 如果自動更新已停用，且您已將 .NET Framework Runtime 升級至 4.7.2 或更新版本，則您可以手動下載最新的 5.x 並安裝在您的機器上。
• 如果自動更新已停用，但您尚未將 .NET Framework Runtime 升級至 4.7.2 或更新版本。 當您嘗試手動安裝自我裝載整合執行階段 5.x 並註冊金鑰時，必須先升級您的 .NET Framework Runtime 版本。

自我裝載 IR 連線問題

自我裝載整合執行階段無法連線至雲端服務

• 徵兆

  當您嘗試註冊自我裝載整合執行階段時，設定管理員顯示了下列錯誤訊息：

  「Integration Runtime (自我裝載) 節點在註冊期間發生錯誤。」

  

• 原因

  自我裝載 IR 無法連線至服務後端。 此問題通常是因為防火牆中的網路設定所造成。

• 解決方法

  1. 檢查整合執行階段服務是否正在執行。 如果是，請移至步驟 2。

     

  2. 如果未在自我裝載 IR 上設定 Proxy (預設設定)，請在安裝自我裝載整合執行階段的機器上執行下列 PowerShell 命令：

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

     注意

     根據資料處理站或 Synapse 工作區執行個體所在的位置而定，服務 URL 可能有所不同。 若要尋找服務 URL，請在資料處理站或 Azure Synapse Analytics 執行個體中使用 UI 的 [管理] 頁面來尋找整合執行階段，然後按一下您的自我裝載 IR 來編輯。 接著，選取 [節點] 索引標籤，並按一下 [檢視服務 URL]。

     預期的回應如下：

     

  3. 若您未收到預期的回應，請視情況使用下列其中一種方法：

     • 如果您收到「無法解析遠端名稱」訊息，即表示有網域名稱系統 (DNS) 問題。 請連絡您的網路小組以修正問題。
     • 如果您收到「ssl/tls 憑證不受信任」訊息，請檢查憑證 (https://wu2.frontend.clouddatahub.net/)，以了解在機器上是否受信任，然後使用憑證管理員安裝公開憑證。 這個動作應可減輕此問題。
     • 移至 [Windows]>[事件檢視器 (記錄)]>[應用程式和服務記錄]>[整合執行階段]，然後查看是否有任何由 DNS、防火牆規則或公司網路設定所造成的失敗。 如果您發現此類錯誤，請強制關閉連線。 由於每間公司都有其本身的自訂網路設定，請連絡您的網路小組以針對這些問題進行疑難排解。

  4. 如果您已在自我裝載整合執行階段上設定「Proxy」，請確認您的 Proxy 伺服器可以存取服務端點。 如需範例命令，請參閱 PowerShell、Web 要求和 Proxy。

     $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
     

  預期的回應如下：

  

  注意

  Proxy 考量：

  • 檢查是否需要將 Proxy 伺服器放在安全的收件者清單中。 若是如此，請確定這些網域 列於安全收件者的清單上。
  • 檢查以確認 SSL/TLS 憑證 wu2.frontend.clouddatahub.net/ 在 Proxy 伺服器上是否受信任。
  • 如果您在 Proxy 上使用 Active Directory 驗證，請將服務帳戶變更為可將 Proxy 作為「整合執行階段服務」存取的使用者帳戶。

錯誤訊息：自我裝載整合執行階段節點/邏輯自我裝載 IR 處於非使用中 /「執行中 (有限制)」狀態

• 原因

  自我裝載整合執行階段節點可能為非使用中狀態，如下列螢幕擷取畫面所示：

  

  當節點無法彼此通訊時，即會發生這種行為。

• 解決方法

  1. 登入節點裝載的虛擬機器 (VM)。 在 [應用程式和服務記錄檔]>[整合執行階段]下，開啟 [事件檢視器]，然後篩選錯誤記錄檔。

  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. 如果您收到下列螢幕擷取畫面中顯示的「無法開啟到主機的連線」命令列錯誤，請向 IT 部門尋求協助解決此問題。 順利完成 telnet 之後，如果仍有整合執行階段節點狀態的問題，請連絡 Microsoft 支援服務。

     

  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. 若要解決此問題，請嘗試下列一或兩個方法：

     • 將所有節點放在相同的網域中。
     • 在所有託管 VM 的主機檔案中，將 IP 新增至主機對應。

在自我裝載 IR 與資料處理站或 Azure Synapse Analytics 執行個體之間，或自我裝載 IR 與資料來源或接收器之間，發生連線問題

若要針對網路連線問題進行疑難排解，您應該先了解如何收集網路追蹤、了解如何使用，並分析 Microsoft 網路監視器 (Netmon) 追蹤，然後才在實際案例中從自我裝載 IR 套用 Netmon 工具。

• 徵兆

  在自我裝載 IR 與資料處理站或 Azure Synapse Analytics 執行個體之間，如下列螢幕擷取畫面所示，或自我裝載 IR 與資料來源或接收器之間，您有時可能需要針對特定連線問題進行疑難排解。

  

  在任一情況下，您可能會遇到下列錯誤：

  • 「複製失敗，並出現錯誤：Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=無法連線至 SQL Server：'IP 位址'」

  • 「發生一或多個錯誤。 傳送要求時發生錯誤。 基礎連線已關閉：接收時發生非預期的錯誤。 無法從傳輸連線讀取資料：遠端主機已強制關閉現有的連線。 遠端主機活動識別碼已強制關閉現有的連線。」

• 解決方法

  當您遇到上述錯誤時，請依照本節中的指示進行疑難排解。

  • 收集 Netmon 追蹤來分析：

    1. 您可以設定篩選條件，以查看從伺服器到用戶端的重設。 在下列範例螢幕擷取畫面中，您可以看到伺服器端是 Data Factory 伺服器。

       

    2. 當您取得重設套件時，您可以遵循傳輸控制通訊協定 (TCP) 來尋找交談。

       

    3. 拿掉篩選，以取得用戶端與 Data Factory 伺服器之間的交談。

  • 分析您已收集的 Netmon 追蹤指出存留時間 (TTL) 總計為 64。 根據 IP 存留時間 (TTL) 和躍點限制基礎一文所述的值，摘錄於下列清單中，您可以看到是 Linux 系統重設套件並造成連線中斷。

    不同作業系統之間的預設 TTL 和躍點限制值有所不同，如下所示：

    • Linux kernel 2.4 (circa 2001)：TCP、使用者資料包通訊協定 (UDP) 及網際網路控制訊息通訊協定 (ICMP) 為 255
    • Linux kernel 4.10 (2015)：TCP、UDP 和 ICMP 為 64
    • Windows XP (2001)：TCP、UDP 和 ICMP 為 128
    • Windows 10 (2015)：TCP、UDP 和 ICMP 為 128
    • Windows Server 2008：TCP、UDP 和 ICMP 的 128
    • Windows Server 2019 (2018)：TCP、UDP 和 ICMP 為 128
    • macOS (2001)：TCP、UDP 和 ICMP 為 64

    

    在上述範例中，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 個躍點」，這表示套件的 21 個躍點在 TCP 3 交握期間從資料處理站執行個體傳送到自我裝載 IR。

    

    因此，您必須與網路小組合作，檢查源於自我裝載 IR 的第四個躍點是什麼。 如果是防火牆，如同 Linux 系統一樣，請檢查任何記錄，以了解該裝置在 TCP 3 交握之後重設套件的原因。

    如果您不確定該調查何處，請在有問題時嘗試從自我裝載 IR 和防火牆取得 Netmon 追蹤。 此方法協助您查明哪個裝置可能已重設套件並導致連線中斷。 在此情況下，您也需要與網路小組合作，以繼續進行。

分析 Netmon 追蹤

注意

下列指示適用於 Netmon 追蹤。 由於目前已不支援 Netmon 追蹤，您可以為此使用 Wireshark。

當您嘗試使用收集的 Netmon 追蹤來 telnet 8.8.8.8 888 時，應該會看到下列螢幕擷取畫面中的追蹤：

上述影像顯示您無法對 8.8.8.8 伺服器端的連接埠 888 建立 TCP 連線，因此您在那裡看到額外兩個 SynReTransmit 套件。 因為來源 SELF-HOST2 無法以第一個套件連線到 8.8.8.8，所以繼續嘗試建立連線。

提示

若要建立此連線，請嘗試下列解決方案：

1. 選取 [載入篩選條件]>[標準篩選條件]>[位址]>[IPv4 位址]。
2. 若要套用篩選條件，請輸入 IPv4.Address == 8.8.8.8，然後選取 [套用]。 接著，您應該會看到從本機電腦到目的地 8.8.8.8 的通訊。

下列範例顯示成功案例：

• 如果您可以毫無問題 telnet 8.8.8.8 53，則會有成功的 TCP 3 交握，而工作階段會以 TCP 4 交握完成。

  

  

• 上述 TCP 3 交握產生下列工作流程：

  

• 下列工作流程說明以 TCP 4 交握完成工作階段：

  

  

判斷此通知是否影響您

此通知適用於下列案例：

案例 1：從公司防火牆後方內部執行的自我裝載整合執行階段輸出的通訊

如何判斷您是否受影響：

• 如果您使用設定防火牆組態和 IP 位址的允許清單中所述的方法，根據完整網域名稱 (FQDN) 來定義防火牆規則，則「不會」受影響。

• 如果您在公司防火牆上明確啟用輸出 IP 的允許清單，則「會」受影響。

  如果您受影響，請採取下列動作：在 2020 年 11 月 8 日之前，通知網路基礎結構小組更新您的網路設定，以使用最新的資料處理站 IP 位址。 若要下載最新的 IP 位址，請參閱使用可下載的 JSON 檔案探索服務標籤。

案例 2：從客戶自控 Azure 虛擬網路內的 Azure VM 上執行的自我裝載整合執行階段輸出的通訊

如何判斷您是否受影響：

• 在包含自我裝載整合執行階段的私人網路中，檢查是否有任何輸出網路安全性群組 (NSG) 規則。 如果沒有輸出限制，則您不受影響。

• 如果您有輸出規則限制，請檢查您是否使用服務標籤。 如果您使用服務標籤，則不受影響。 因為新的 IP 範圍在現有的服務標籤下，完全不需要變更或新增。

  

• 如果您在 Azure 虛擬網路上的 NSG 規則設定上明確啟用輸出 IP 位址的允許清單，則「會」受影響。

  如果您受到影響，請採取下列動作：在 2020 年 11 月 8 日之前，請通知網路基礎結構小組更新 Azure 虛擬網路設定上的 NSG 規則，以使用最新的資料處理站 IP 位址。 若要下載最新的 IP 位址，請參閱使用可下載的 JSON 檔案探索服務標籤。

案例 3：從客戶自控 Azure 虛擬網路中的 SSIS Integration Runtime 輸出的通訊

如何判斷您是否受影響：

• 在包含 SQL Server Integration Services (SSIS) Integration Runtime 的私人網路中，檢查是否有任何輸出 NSG 規則。 如果沒有輸出限制，則您不受影響。

• 如果您有輸出規則限制，請檢查您是否使用服務標籤。 如果您使用服務標籤，則不受影響。 因為新的 IP 範圍在現有的服務標籤下，完全不需要變更或新增。

• 如果您在 Azure 虛擬網路上的 NSG 規則設定上明確啟用輸出 IP 位址的允許清單，則「會」受影響。

  如果您受到影響，請採取下列動作：在 2020 年 11 月 8 日之前，請通知網路基礎結構小組更新 Azure 虛擬網路設定上的 NSG 規則，以使用最新的資料處理站 IP 位址。 若要下載最新的 IP 位址，請參閱使用可下載的 JSON 檔案探索服務標籤。

無法為 SSL/TLS 安全通道建立信任關係

• 徵兆

  自我裝載 IR 無法連線到 Azure Data Factory 或 Azure Synapse Analytics 服務。

  當移至 [Windows] > [事件檢視器 (記錄)] > [應用程式和服務記錄] > [整合執行階段] 後檢查自我裝載 IR 事件記錄檔時，您會發現下列錯誤訊息。

  「基礎連線已關閉：無法為 SSL/TLS 安全通道建立信任關係。 根據驗證程序，遠端憑證無效。」

  若要檢查服務的伺服器憑證，最簡單的方式就是在瀏覽器中開啟服務 URL。 例如，在已安裝自我裝載 IR 的機器上開啟檢查伺服器憑證連結 (https://eu.frontend.clouddatahub.net/)，然後檢視伺服器憑證資訊。

  

  

• 原因

  此問題的可能原因有兩個：

  • 原因 1：在安裝自我裝載 IR 的機器上，不信任服務之伺服器憑證的根 CA。
  • 原因 2：您在環境中使用了 Proxy，服務的伺服器憑證會由 Proxy 取代，而被取代的伺服器憑證不受安裝自我裝載 IR 的機器所信任。

• 解決方法

  • 針對原因 1：確定已安裝自我裝載 IR 的機器會信任服務的伺服器憑證及其憑證鏈結。
  • 針對原因 2：在自我裝載 IR 機器上信任被取代的根 CA，或將 Proxy 設定為不要取代服務的伺服器憑證。

  如需關於在 Windows 上信任憑證的詳細資訊，請參閱安裝受信任的根憑證。

• 其他資訊
  我們已推出從 DigiCert 簽署的新 SSL 憑證。 查看 DigiCert 全域根 G2 是否位於受信任的根 CA 中。

  

  如果不在受信任的根 CA 中，請在此下載。

相關內容

如需疑難排解方面的更多協助，請嘗試下列資源：

• Data Factory 部落格
• Data Factory 功能要求
• Azure 影片
• Microsoft Q&A 頁面
• Data Factory 的堆疊溢位論壇
• 關於 Data Factory 的 X 資訊
• 對應資料流效能指南