使用修補程式協調流程應用程式

  • 發行項

重要

從 2019 年 4 月 30 日開始，不再支援修補程式協調流程應用程式 1.2.* 版。 請務必升級至最新版。

修補程式協調流程應用程式 (POA) 是 Azure Service Fabric 修復管理員服務的包裝函式，可針對非 Azure 託管叢集啟用以設定為基礎的 OS 修補程式排程。 非 Azure 託管叢集不需要 POA，但需要依更新網域排程安裝修補程式，才可以在不產生停機的情況下，修補 Service Fabric 叢集主機。

POA 是一種 Service Fabric 應用程式，可在不產生停機的情況下，在 Service Fabric 叢集上自動修補作業系統。

POA 提供下列功能：

  • 自動化的作業系統更新安裝。 會自動下載並安裝作業系統更新。 視需要將叢集節點重新開機，不會產生叢集停機的情況。

  • 叢集感知的修補和健康情況整合。 POA 在套用更新的同時，會監視叢集節點的健康情況。 叢集節點一次只能更新一個節點，或一次更新一個網域。 如果因修補程序造成叢集的健康情況下降，修補就會停止，防止問題繼續惡化。

POA 的內部詳細資料

POA 由下列子元件所組成：

  • 協調器服務︰是具狀態服務，負責：

    • 協調整個叢集上的 Windows Update 作業。
    • 儲存已完成之 Windows Update 作業的結果。

  • 節點代理程式服務︰是無狀態服務，在所有 Service Fabric 叢集節點上執行。 此服務負責：

    • 啟動節點代理程式 NTService。
    • 監視節點代理程式 NTService。

  • 節點代理程式 NTService：在較高層級權限 (系統) 執行的 Windows NT 服務。 相比之下，節點代理程式服務和協調器服務則是在較低層級權限 (網路服務) 執行。 此服務會負責執行下列所有叢集節點上的 Windows Update 作業：

    • 停用節點上的 Windows 自動更新。
    • 根據使用者提供的原則下載並安裝 Windows 更新。
    • 安裝 Windows 更新後重新啟動機器。
    • 將 Windows Update 的結果上傳至協調器服務。
    • 如果耗盡所有重試之後作業還是失敗，就報告健康情況報告。

注意

POA 使用 Service Fabric 修復管理員服務，停用或啟用節點以及執行健康情況檢查。 POA 建立的修復工作會追蹤每個節點的 Windows Update 進度。

必要條件

注意

所需最低版本為 .NET Framework 4.6 版。

啟用修復管理員服務 (如果尚未執行)

POA 需要在叢集上啟用修復管理員服務。

Azure 叢集

銀級耐久性層中的 Azure 叢集依預設會啟用修復管理員服務。 金級耐久性層中的 Azure 叢集可能會或也可能不會啟用修復管理員服務，視這些叢集的建立時間而定。 銅級耐久性層中的 Azure 叢集依預設不會啟用修復管理員服務。 如果已啟用服務，您可以在 Service Fabric Explorer 的系統服務區段中看到服務正在執行。

Azure 入口網站

當您設定叢集時，可以從 Azure 入口網站啟用修復管理員。 當您設定叢集時，請選取 [附加元件功能] 下的 [包含修復管理員] 選項。

Image of enabling Repair Manager from the Azure portal

Azure Resource Manager 部署模型

或者，您可以使用 Azure Resource Manager 部署模型，在新的和現有的 Service Fabric 叢集上啟用修復管理員服務。 取得您想要部署之叢集的範本。 您可以使用範例範本，或建立自訂的 Azure Resource Manager 部署模型範本。

若要使用 Azure Resource Manager 部署模型範本啟用修復管理員服務，請執行下列動作：

  1. 檢查以確認 Microsoft.ServiceFabric/clusters 資源的 apiVersion 已設定為 2017-07-01-preview。 如果不一樣，您必須將 apiVersion 更新為 2017-07-01-preview 或更新版本：

    {
    "apiVersion": "2017-07-01-preview",
    "type": "Microsoft.ServiceFabric/clusters",
    "name": "[parameters('clusterName')]",
    "location": "[parameters('clusterLocation')]",
    ...
}

  2. 啟用修復管理員服務，方法是在 fabricSettings 區段之後新增下列 addonFeatures 區段：

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. 使用這些變更更新您的叢集範本之後，請套用變更，使更新完成。 您現在可以看到修復管理員服務在您的叢集中執行。 這在 Service Fabric Explorer 的系統服務區段中稱為 fabric:/System/RepairManagerService。

獨立的內部部署叢集

若要在新的或現有的 Service Fabric 叢集上啟用修復管理員服務，您可以使用獨立 Windows 叢集的組態設定。

若要啟用修復管理員服務：

  1. 檢查以確定一般叢集組態中的 apiVersion 已設定為 04-2017 或更新版本，如下所示：

    {
    "name": "SampleCluster",
    "clusterConfigurationVersion": "1.0.0",
    "apiVersion": "04-2017",
    ...
}

  2. 啟用修復管理員服務，方法是在 fabricSettings 區段之後新增下列 addonFeatures 區段，如下所示：

    "fabricSettings": [
    ...      
],
"addonFeatures": [
    "RepairManager"
],

  3. 使用這些變更更新您的叢集資訊清單，透過使用更新後的叢集資訊清單，您可以建立新叢集或升級叢集組態。

    使用更新後的叢集資訊清單執行叢集之後，您可以看到修復管理員服務在您的叢集中執行。 這稱為 fabric:/System/RepairManagerService，位於 Service Fabric Explorer 的系統服務區段中。

針對所有節點設定 Windows 更新

Windows 自動更新可能導致失去可用性，因為多個叢集節點會在同一時間重新啟動。 依預設，POA 會嘗試停用每個叢集節點上的 Windows 自動更新。 不過，如果設定是由管理員或群組原則所管理，則建議將 Windows Update 原則明確設定為 [下載前先通知]。

下載應用程式封裝

若要下載應用程式封裝，請移至 GitHub 的 Patch Orchestration Application (修補程式協調流程應用程式) 版本頁面。

設定 POA 行為

您可以設定 POA 行為以符合您的需求。 在您建立或更新應用程式時，傳入的應用程式參數會覆寫預設值。 您可以在 Start-ServiceFabricApplicationUpgrade 或 New-ServiceFabricApplication Cmdlet 中指定 ApplicationParameter，即可提供應用程式參數。

參數 類型​ 詳細資料
MaxResultsToCache Long 應快取的 Windows Update 結果數目上限。

預設值為 3000，假設條件為：
  - 節點數目為 20。
  - 每月節點的更新數目為 5。
  - 每個作業的結果數目可為 10。
  - 過去 3 個月的結果應加以儲存。
TaskApprovalPolicy 例舉
{ NodeWise, UpgradeDomainWise }		 TaskApprovalPolicy 會指出協調器服務在 Service Fabric 叢集節點中用來安裝 Windows 更新的原則。

允許的值有：
NodeWise：一次安裝一個節點的 Windows 更新。
UpgradeDomainWise：一次安裝一個更新網域的 Windows 更新。 (在大多數的情況下，屬於更新網域的所有節點都可以進行 Windows 更新。)

若要協助決定哪一個原則最適合您的叢集，請參閱＜常見問題＞一節。
LogsDiskQuotaInMB long
(預設值： 1024)		 修補程式協調流程應用程式可保留在節點本機上的記錄大小上限 (以 MB 為單位)。
WUQuery string
(預設值： IsInstalled=0)		 用以取得 Windows 更新的查詢。 如需詳細資訊，請參閱 WuQuery。
InstallWindowsOSOnlyUpdates 布林值
(預設值：False)		 使用此旗標可控制所應下載並安裝的更新。 允許下列值
true - 只安裝 Windows 作業系統的更新。
false - 在電腦上安裝所有可用的更新。
WUOperationTimeOutInMinutes Int
(預設值： 90)		 指定任何 Windows Update 作業的逾時 (搜尋或下載或安裝)。 如果作業未在指定的逾時內完成，它就會中止。
WURescheduleCount Int
(預設值： 5)		 如果作業持續失敗，服務重新排程 Windows 更新的次數上限。
WURescheduleTimeInMinutes Int
(預設值： 30)		 如果持續失敗，服務重新排程 Windows 更新的時間間隔。
WUFrequency 以逗號分隔的字串 (預設值： Weekly, Wednesday, 7:00:00) 安裝 Windows 更新的頻率。 格式與可能的值如下：
- Monthly, DD, HH:MM:SS (範例： Monthly, 5, 12:22:32)。 Permitted values for 欄位 DD (天) 的允許值為 1 到 28 和 last。
- Weekly, Day, HH:MM:SS (範例： Weekly, Tuesday, 12:22:32)
- Daily, HH:MM:SS (範例： Daily, 12:22:32)
- MonthlyByWeekAndDay, Week, Day, HH:MM:SS (範例： MonthlyByWeekAndDay, 2, Friday, 21:00:00 意指 UTC 時間每個月第 2 週的週五下午 9:00)
- None 意指不應進行 Windows 更新。

時間均採用 UTC 時間。
AcceptWindowsUpdateEula Boolean
(預設值： true)		 藉由設定這個旗標，應用程式會代表電腦的擁有者接受 Windows Update 的使用者授權合約 (EULA)。

提示

如果需要立即進行 Windows 更新，請將 WUFrequency 設定為相對於應用程式部署的時間。 例如，假設您的測試叢集有五個節點，計劃於大約下午 5:00 UTC 部署應用程式。 如果您假設應用程式的升級或部署最多會花費 30 分鐘的時間，則請將 WUFrequency 設定為 Daily, 17:30:00。

部署 POA

  1. 完成準備叢集的所有必要條件步驟。

  2. 部署 POA，就像任何其他 Service Fabric 應用程式一樣。 若要使用 PowerShell 進行部署，請參閱使用 Powershell 部署和移除應用程式。

  3. 若要在部署時設定應用程式，可將 ApplicationParameter 傳遞給 New-ServiceFabricApplication Cmdlet。 為了您的方便，我們提供了 Deploy.ps1 指令碼以及我們的應用程式。 若要使用指令碼：

    • 使用 Connect-ServiceFabricCluster 連線至 Service Fabric 叢集。
    • 利用適當的 ApplicationParameter 值執行 Powershell 指令碼 Deploy.ps1。

注意

將指令碼和應用程式資料夾 PatchOrchestrationApplication 保留在同一個目錄中。

升級 POA

若要使用 PowerShell 升級您的 POA 版本，請遵循使用 PowerShell 進行 Service Fabric 應用程式升級中的指示。

移除 POA

若要移除應用程式，請遵循使用 PowerShell 部署與移除應用程式中的指示。

為了您的方便，我們提供 Undeploy.ps1 指令碼以及應用程式。 若要使用指令碼：

  • 使用 Connect-ServiceFabricCluster 連線至 Service Fabric 叢集。
  • 執行 Powershell 指令碼 Undeploy.ps1。

注意

將指令碼和應用程式資料夾 PatchOrchestrationApplication 保留在同一個目錄中。

檢視 Windows Update 結果

POA 會公開 REST API 以向使用者顯示歷程記錄結果。 結果 JSON 的範例如下：

[
  {
    "NodeName": "_stg1vm_1",
    "WindowsUpdateOperationResults": [
      {
        "OperationResult": 0,
        "NodeName": "_stg1vm_1",
        "OperationTime": "2019-05-13T08:44:56.4836889Z",
        "OperationStartTime": "2019-05-13T08:44:33.5285601Z",
        "UpdateDetails": [
          {
            "UpdateId": "7392acaf-6a85-427c-8a8d-058c25beb0d6",
            "Title": "Cumulative Security Update for Internet Explorer 11 for Windows Server 2012 R2 (KB3185319)",
            "Description": "A security issue has been identified in a Microsoft software product that could affect your system. You can help protect your system by installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
            "ResultCode": 0,
            "HResult": 0
          }
        ],
        "OperationType": 1,
        "WindowsUpdateQuery": "IsInstalled=0",
        "WindowsUpdateFrequency": "Daily,10:00:00",
        "RebootRequired": false
      }
    ]
  },
  ...
]

下表說明 JSON 欄位：

欄位 值 詳細資料
OperationResult 0 - 成功
1 - 成功但發生錯誤
2 - 失敗
3 - 已中止
4 - 中止但逾時		 表示整體作業的結果，通常涉及一或多個更新的安裝。
ResultCode 與 OperationResult 相同 此欄位表示個別更新的安裝作業結果。
OperationType 1 - 安裝
0 - 搜尋和下載		 依預設，「安裝」是顯示在結果中的唯一一個 OperationType。
WindowsUpdateQuery 預設值為 "IsInstalled=0" 用來搜尋更新的 Windows Update 查詢。 如需詳細資訊，請參閱 WuQuery。
RebootRequired true - 需要重新開機
false - 不需要重新開機		 表示是否需要重新開機才能完成更新的安裝。
OperationStartTime Datetime 表示作業 (下載/安裝) 開始的時間。
OperationTime Datetime 表示作業 (下載/安裝) 完成的時間。
HResult 0 - 成功
其他 - 失敗		 表示 Windows 更新失敗 (updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6") 的原因。

如果尚未排程更新，JSON 結果會是空的。

登入叢集，查詢 Windows Update 結果。 找出協調器服務主要位址的複本 IP 位址，然後從瀏覽器開啟下列 URL： http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults。

協調器服務的 REST 端點具有動態連接埠。 若要查看確切的 URL，請查看 Service Fabric Explorer。 例如，可在 http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults 找到結果。

Image of the REST endpoint

如果在叢集上啟用反向 Proxy，您也可以從叢集外部存取 URL。

您需要點擊的端點為 http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults。

若要在叢集上啟用反向 Proxy，請遵循 Azure Service Fabric 中的反向 Proxy 中的指示。

警告

設定反向 Proxy 之後，就能從叢集外部定址叢集中公開 HTTP 端點的所有微服務。

診斷和健康情況事件

本節討論如何透過 Service Fabric 叢集上的 POA，偵錯或診斷修補程式更新的問題。

注意

若要取得許多以下列出的自我診斷增強功能，您應安裝 POA 1.4.0 版或更新版本。

節點代理程式 NTService 建立修復工作以在節點上安裝更新。 接著，協調器服務依據工作核准原則來準備每項工作。 最後，修復管理員核准已備妥的工作，如果叢集處於狀況不良的狀態，修復管理員不會核准任何工作。

為協助您了解如何在節點上進行更新，讓我們逐步執行：

  1. NodeAgentNTService 在每個節點上執行，在排定的時間尋找可用的 Windows 更新。 如果有可用的更新，在節點上下載更新。

  2. 下載更新之後，節點代理程式 NTService 針對該節點建立對應的修復工作，名稱為 POS___<unique_id>。 您可以使用 Get-ServiceFabricRepairTask Cmdlet 或在節點詳細資料區段中使用 SFX，檢視這些修復工作。 建立修復工作之後，修復工作會快速移至已宣告狀態。

  3. 協調器服務定期尋找處於已宣告狀態的修復工作，然後根據 TaskApprovalPolicy，將修復工作更新為準備中狀態。 如果 Taskapprovalpolicy 已設定為 NodeWise，則只有在目前沒有其他修復工作是處於準備中、已核准、執行中或還原中狀態的情況下，才會準備對應至節點的修復工作。

    同樣地，在 TaskApprovalPolicy 設定為 UpgradeWise 的情況下，前述狀態的工作只會針對屬於相同更新網域的節點。 修復工作移至準備中狀態之後，對應的 Service Fabric 節點會變為已停用，設定的意圖是重新啟動。

    POA 1.4.0 版和更新版本在 CoordinatorService 上張貼具 ClusterPatchingStatus 屬性的事件，顯示即將進行修補的節點。 更新已安裝於 _poanode_0，如下圖所示：

    Image of cluster patching status

  4. 停用節點之後，修復工作移至執行中狀態。

    注意

    停滯於已停用狀態的節點會封鎖新的修復工作，這會中止叢集上的修補作業。

  5. 當修復工作處於執行中狀態時，就會開始在該節點上安裝修補程式。 安裝修補程式之後，節點可能會或可能不會重新啟動，這取決於修補程式。 接下來，修復工作會移至還原中狀態，這會重新啟用節點。 接著將修復工作標示為已完成。

    在 POA 1.4.0 版本和更新版本中，您可以在 NodeAgentService 上檢視具 WUOperationStatus-<NodeName> 屬性的健康情況事件，找到更新狀態。 下列圖片中的醒目提示區域顯示節點 poanode_0 和 poanode_2 上的 Windows 更新狀態：

    Screenshot shows console window of Windows Update operation status with poanode_0 highlighted.

    Screenshot shows console window of Windows Update operation status with poanode_1 highlighted.

    您也可以使用 PowerShell 取得詳細資料。 若要這樣做，請連線到叢集，然後使用 Get-ServiceFabricRepairTask 擷取修復工作的狀態。

    在下列範例中，"POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" 工作的狀態是 DownloadComplete。 這表示已在 poanode_2 節點上下載更新，將會在工作移至執行中狀態時嘗試安裝。

     D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k = Get-ServiceFabricRepairTask -TaskId "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15"

 D:\service-fabric-poa-bin\service-fabric-poa-bin\Release> $k.ExecutorData
 {"ExecutorSubState":2,"ExecutorTimeoutInMinutes":90,"RestartRequestedTime":"0001-01-01T00:00:00"}

    如果仍發現有更多問題，請登入您的虛擬機器或 VM，利用 Windows 事件記錄檔來了解這些問題。 先前提及的修復工作只能以下列執行程式子狀態存在：

    ExecutorSubState 描述
    None=1 意指節點上沒有進行中的作業。 狀態可能在轉換中。
    DownloadCompleted=2 意指下載作業已完成，但有成功、部分失敗或失敗。
    InstallationApproved=3 意指下載作業先前已完成，修復管理員已核准安裝。
    InstallationInProgress=4 對應到修復工作的執行狀態。
    InstallationCompleted=5 意指安裝已完成，但有成功、部分成功或失敗。
    RestartRequested=6 意指修補程式安裝已完成，且節點上有擱置的重新啟動動作。
    RestartNotNeeded=7 意指修補程式安裝完成之後，不需要重新啟動。
    RestartCompleted=8 意指重新啟動已順利完成。
    OperationCompleted=9 Windows Update 作業已順利完成。
    OperationAborted=10 意指 Windows Update 作業已中止。

  6. 在 POA 1.4.0 版和更新版本中，當一次節點更新嘗試結束時，會在 NodeAgentService 上張貼具有 "WUOperationStatus-[NodeName]" 屬性的事件，通知您下次嘗試下載並安裝 Windows 更新的開始時間。 如下圖顯示：

    Screenshot shows console window of Windows Update operation status with the NodeAgentService.

診斷記錄

收集修補程式協調流程應用程式的記錄，是 Service Fabric 執行階段記錄的一部分。

您可以使用您選擇的診斷工具或管線來擷取記錄。 POA 會使用下列固定提供者識別碼，透過事件來源記錄事件：

  • e39b723c-590c-4090-abb0-11e3e6616346
  • fc0028ff-bfdc-499f-80dc-ed922c52c5e9
  • 24afa313-0d3b-4c7c-b485-1047fd964b60
  • 05dc046c-60e9-4ef7-965e-91660adffa68

健康狀態報告

POA 在下列情況下也會發佈節點代理程式服務或協調器服務的健康情況報告：

  • 節點代理程式 NTService 關閉

    如果節點上的節點代理程式 NTService 關閉，就會產生節點代理程式服務的警告等級健康情況報告。

  • 修復管理員服務未啟用

    如果在叢集上找不到修復管理員服務，就會產生協調器服務的警告等級健康情況報告。

常見問題集

問：當 POA 執行時，為什麼我看到叢集處於錯誤狀態？

答：在安裝過程中，POA 會停用或重新啟動節點，而這可能會暫時導致叢集的狀況不良。

視應用程式的原則而定，這可能是一個節點在修補作業期間關閉，「或是」整個升級網域同時關閉。

Windows 更新的安裝結束時，節點會在重新啟動後重新啟用。

在下列範例中，因為兩個節點關閉，且違反 MaxPercentageUnhealthyNodes 原則，叢集會暫時進入錯誤狀態。 錯誤是暫時性的，直到開始修補作業為止。

Image of unhealthy cluster

如果問題持續發生，請參閱〈疑難排解〉一節。

問：如果 POA 處於警告狀態，該怎麼辦？

答：檢查針對應用程式所張貼的健康情況報告，是否有指出根本原因。 警告通常包含問題的詳細資料。 如果問題是暫時性的，應用程式應該會自動復原。

問：如果我的叢集健康情況不良，我可以做什麼？我需要採取緊急的作業系統更新嗎？

答：當叢集健康情況不良時，POA 就不會安裝更新。 請嘗試使叢集回復良好的健康情況，以便將 POA 工作流程解除封鎖。

問：我是否應該針對叢集將 TaskApprovalPolicy 設為 "NodeWise" 或 "UpgradeDomainWise"？

答："UpgradeDomainWise" 設定會以平行方式修補屬於更新網域的所有節點，加快整體叢集修復的速度。 在此程序期間，整個更新網域的所屬節點會無法使用 (處於已停用狀態)。

相反地，"NodeWise" 設定一次只會修補一個節點，這意指整體叢集修補可能需要較長的時間。 不過，在修補程序期間，最多只有一個節點會無法使用 (處於已停用狀態)。

如果在修補週期期間，您的叢集可以容忍在 N-1 個更新網域上執行 (其中 N 是叢集上更新網域的總數)，則您可以將原則設為 "UpgradeDomainWise"，否則請將其設為 "NodeWise"。

問：修補節點需要耗費多久時間？

答：修補一個節點可能需要數分鐘 (例如 Windows Defender 定義更新) 到數小時 (例如 Windows 累積更新) 的時間。 修補節點所需的時間大多取決於下列因素：

  • 更新的大小。
  • 在修補期間必須套用的更新數目。
  • 安裝更新、將節點重新開機 (如有必要)，然後完成重新開機後安裝步驟所耗費的時間。
  • VM 或機器的效能，以及網路狀況。

問：修補整個叢集需要多久時間？

答：修補整個叢集所需的時間取決於：

  • 修補一個節點所需的時間。

  • 協調器服務的原則。 預設原則 "NodeWise" 會導致一次只修補一個節點，這種方法比使用 "UpgradeDomainWise" 來得慢。

    例如：如果節點需要約 1 個小時來修補，若要修補 20 個節點 (節點類型相同) 的叢集，其中有 5 個更新網域，每個網域包含 4 個節點，則需要：

    • 若是 "NodeWise"：約 20 小時。
    • 若是 "UpgradeDomainWise"：約 5 小時。

  • 叢集負載。 每個修補作業都必須將客戶工作負載重新放置到叢集中的其他可用節點。 即將修補的節點在這段期間會處於停用中狀態。 如果執行中的叢集接近尖峰負載，停用程序會需要更長的時間。 因此，在如此充滿壓力的條件下，整體修補程序可能會變慢。

  • 修補期間的叢集健康情況不佳。 叢集健康情況的任何降低情況都會中斷修補程序。 這個問題會增加修補整個叢集所需的整體時間。

問：為什麼我在 Windows Update 結果中看到某些更新已透過 REST API 取得，但未出現在機器的 Windows Update 歷程記錄下？

答：某些產品更新只會出現在自己的更新或修補歷程記錄中。 例如，Windows Defender 更新可能會也可能不會顯示在 Windows Server 2016 的 Windows Update 歷程記錄中。

問： POA 可以用來更新我的開發叢集 (單一節點叢集) 嗎？

答：否，POA 不能用來修補單一節點叢集。 這是設計好的限制，因為 Service Fabric 系統服務或其他客戶應用程式會產生停機時間。 因此，修復管理員不會核准修補的修復工作。

問：如何在 Linux 上修補叢集節點？

答：若要深入了解如何在 Linux 上協調更新，請參閱 Azure 虛擬機器擴展集的 OS 映像自動升級。

問：為什麼更新週期花了很長的時間？

答：查詢結果 JSON、使所有節點進入更新週期，然後您可以使用 OperationStartTime 和 OperationTime (OperationCompletionTime)，嘗試找出每個節點上安裝更新所花費的時間。

如果有一段很長的時間範圍未進行任何更新，則叢集可能是處於錯誤狀態，因此修復管理員無法核准任何 POA 修復工作。 如果有任何節點上的更新安裝花費很長一段時間，這表示該節點可能有一段很長的時間未進行更新。 有很多更新的安裝可能遭到擱置，因而造成延遲的情形。

也有可能是節點修補遭到封鎖，因為節點停滯於停用中狀態。 通常會發生這種情況是因為停用節點可能導致仲裁或資料遺失的情況。

問： POA 修補節點時，為什麼必須停用節點？

答： POA 停用節點的意圖是重新啟動，這會停止或重新配置節點上正在執行的所有 Service Fabric 服務。 POA 執行這項動作是為確保應用程式最後不會混用新舊 DLL，因此建議您不要在未停用節點的情況下修補節點。

問：使用 POA 可以更新的節點數目上限為何？

答： POA 使用 Service Fabric 修復管理員來建立節點的修復工作以進行更新。 然而，同時間不能存在超過 250 個修復工作。 目前，POA 會在同時間為每個節點建立修復工作，因此 POA 可在叢集中更新 250 個以內的節點。

免責聲明

  • POA 會代表使用者接受 Windows Update 的使用者授權合約。 可在應用程式的設定中選擇性地將此設定關閉。

  • POA 會收集遙測來追蹤使用情形和效能。 應用程式的遙測會遵循 Service Fabric 執行階段遙測設定 (預設為開啟) 的設定。

疑難排解

本節提供修補節點問題的可行疑難排解解決方案。

節點不會回到開啟狀態

  • 節點可能停滯於停用中狀態，因為：

    • 安全性檢查擱置。 若要補救這種情況，請確定有足夠多健康情況良好的節點。

  • 節點可能停滯於已停用狀態，因為：

    • 手動停用節點。
    • 因為 Azure 基礎結構作業正在進行中而導致節點停用。
    • POA 暫時停用節點以修補節點。

  • 節點可能會卡在關閉狀態，因為：

    • 手動將節點置於關閉狀態。
    • 正在進行重新啟動 (可能是由 POA 觸發)。
    • VM 或機器故障，或是網路連線問題。

已略過某些節點上的更新

POA 會根據重新排定原則，嘗試安裝 Windows 更新。 服務會根據應用程式原則，嘗試復原節點並略過更新。

在這種情況下，系統會針對節點代理程式服務產生警告等級的健康情況報告。 Windows Update 的結果也包含可能的失敗原因。

開始安裝更新時，叢集的健康情況出現錯誤

錯誤的 Windows Update 會損及特定節點或更新網域上應用程式或叢集的健康情況。 POA 會中止所有後續的 Windows Update 作業，直到叢集恢復良好健康情況。

管理員必須介入，判斷應用程式或叢集為何因為 Windows Update 變成健康情況不良。

POA 版本資訊

注意

您可以在 GitHub 的 Patch Orchestration Application (修補程式協調流程應用程式) 版本頁面找到 POA 1.4.0 版和更新版本的版本資訊和發行版本。

1.1.0 版

  • 公開版本

1.1.1 版

  • 修正 SetupEntryPoint of NodeAgentService 中的錯誤，該錯誤導致無法安裝 NodeAgentNTService。

版本 1.2.0

  • 關於系統重新啟動工作流程的錯誤修正。
  • 由於準備修復工作期間健康情況檢查未如預期般發生，而在 RM 工作建立時進行的錯誤修正。
  • 將 Windows 服務 POANodeSvc 的啟動模式從自動變更為延遲自動。

1.2.1 版

  • 縮小叢集範圍工作流程中的錯誤修正。 針對屬於不存在節點的 POA 修復工作，導入了記憶體回收邏輯。

1.2.2 版

  • 其他錯誤修正。
  • 現在已簽署二進位檔。
  • 已新增應用程式的 sfpkg 連結。

第 1.3.0 版

  • 現在，將 InstallWindowsOSOnlyUpdates 設定為 false 便會安裝所有可用的更新。
  • 已變更停用自動更新的邏輯。 這會修正 Server 2016 和以上版本未停用自動更新的錯誤。
  • 已針對進階使用案例將 POA 兩個微服務的放置條件約束參數化。

1.3.1 版

  • 修正 POA 1.3.0 在 Windows Server 2012 R2 或更早版本上因為停用自動更新失敗而無法運作的迴歸。
  • 修正 InstallWindowsOSOnlyUpdates 組態一律挑選為 True 的錯誤 (bug)。
  • 將 InstallWindowsOSOnlyUpdates 的預設值變更為 False。

1.3.2 版

  • 修正如果有節點的名稱是目前節點名稱的子集，而影響節點上修補週期的問題。 若是這類節點，有可能是錯過修補或重新開機遭擱置中。