在 Service Fabric 群集中修补 Windows 操作系统Patch the Windows operating system in your Service Fabric cluster

重要

从 2019 年 4 月 30 日起,修补业务流程应用程序版本 1.2.* 不再受支持。As of April 30, 2019, Patch Orchestration Application version 1.2.* is no longer supported. 请务必升级到最新版本。Be sure to upgrade to the latest version.

修补业务流程应用程序 (POA) 是围绕 Azure Service Fabric 修复管理器服务的包装器,可为非 Azure 托管群集启用基于配置的 OS 修补计划。Patch Orchestration Application (POA) is a wrapper around the Azure Service Fabric Repair Manager service, which enables configuration-based OS patch scheduling for non-Azure hosted clusters. 非 Azure 托管群集不需要 POA,但需要按更新域计划修补程序安装,以便在不停机的情况下修补 Service Fabric 群集主机。POA isn't required for non-Azure hosted clusters, but scheduling patch installation by update domain is required to patch Service Fabric cluster hosts without incurring downtime.

POA 是一个 Service Fabric 应用程序,可在 Service Fabric 群集中自动修补操作系统,而无需停机。POA is a Service Fabric application that automates operating system patching on a Service Fabric cluster without incurring downtime.

POA 提供以下功能:POA provides the following features:

  • 自动完成操作系统更新安装。Automatic operating system update installation. 自动下载并安装操作系统更新。Operating system updates are automatically downloaded and installed. 可根据需要重启群集节点,且无需让群集停机。Cluster nodes are rebooted as needed without incurring cluster downtime.

  • 群集感知修补和运行状况集成。Cluster-aware patching and health integration. POA 在应用更新时,会监视群集节点的运行状况。While POA is applying updates, it monitors the health of the cluster nodes. 群集节点的更新方式为一次一个节点,或一次一个更新域。Cluster nodes are updated one node at a time or one update domain at a time. 如果群集的运行状况由于修补进程而恶化,则会停止修补以防止问题加重。If the health of the cluster goes down because of the patching process, patching is stopped to prevent aggravating the problem.

POA 的内部详细信息Internal details of POA

POA 由以下子组件构成:POA is composed of the following subcomponents:

  • 协调器服务:此有状态服务负责:Coordinator Service: This stateful service is responsible for:

    • 协调整个群集上的 Windows 更新作业。Coordinating the Windows Update job on the entire cluster.
    • 存储已完成的 Windows 更新操作的结果。Storing the result of completed Windows Update operations.
  • 节点代理服务:此无状态服务在所有 Service Fabric 群集节点上运行。Node Agent Service: This stateless service runs on all Service Fabric cluster nodes. 此服务负责:The service is responsible for:

    • 启动节点代理 NTService。Bootstrapping the Node Agent NTService.
    • 监视节点代理 NTService。Monitoring the Node Agent NTService.
  • 节点代理 NTService:此 Windows NT 服务以更高级别的特权 (SYSTEM) 运行。Node Agent NTService: This Windows NT service runs at a higher-level privilege (SYSTEM). 相比之下,节点代理服务和协调器服务以较低级别的特权 (NETWORK SERVICE) 运行。In contrast, the Node Agent Service and the Coordinator Service run at a lower-level privilege (NETWORK SERVICE). 该服务负责在所有群集节点上执行以下 Windows 更新作业:The service is responsible for performing the following Windows Update jobs on all the cluster nodes:

    • 在节点上禁用自动 Windows 更新。Disabling automatic Windows updates on the node.
    • 根据用户提供的策略下载并安装 Windows 更新。Downloading and installing Windows updates according to the policy the user has provided.
    • 安装 Windows 更新后重启计算机。Restarting the machine post-Windows updates installation.
    • 将 Windows 更新的结果上传到协调器服务。Uploading the results of Windows updates to the Coordinator Service.
    • 在某个操作用完所有重试次数仍失败后报告运行状况。Reporting health reports if an operation has failed after it exhausts all retries.

备注

POA 使用 Service Fabric 的修复管理器服务来禁用/启用节点和执行运行状况检查。POA uses the Service Fabric Repair Manager service to disable or enable the node and perform health checks. POA 创建的修复任务跟踪每个节点的 Windows 更新进度。The repair task created by POA tracks the Windows Update progress for each node.

先决条件Prerequisites

备注

所需的最低 .NET Framework 版本为 4.6。The required minimum .NET Framework version is 4.6.

启用修复管理器服务(如果尚未运行)Enable the Repair Manager service (if it's not running already)

POA 要求在群集上启用修复管理器服务。POA requires the Repair Manager service to be enabled on the cluster.

Azure 群集Azure clusters

银级持久层中的 Azure 群集默认启用修复管理器服务。Azure clusters in the silver durability tier have the Repair Manager service enabled by default. 金级持久层中的 Azure 群集可能启用或不启用修复管理器服务,具体取决于这些群集的创建时间。Azure clusters in the gold durability tier might or might not have the Repair Manager service enabled, depending on when those clusters were created. 铜级持久层中的 Azure 群集默认不启用修复管理器服务。Azure clusters in the bronze durability tier, by default, do not have the Repair Manager service enabled. 如果已启用该服务,可以看到它在 Service Fabric Explorer 的系统服务部分运行。If the service is already enabled, you can see it running in the system services section in Service Fabric Explorer.

Azure 门户The Azure portal

在设置群集时,可以从 Azure 门户启用修复管理器。You can enable Repair Manager from the Azure portal when you set up the cluster. 配置群集时,选择“附加功能”下的“包括修复管理器”选项。 When you're configuring the cluster, select the Include Repair Manager option under Add-on features.

从 Azure 门户启用修复管理器的插图

Azure 资源管理器部署模型The Azure Resource Manager deployment model

另外,也可以使用 Azure 资源管理器部署模型在新的或现有 Service Fabric 群集上启用修复管理器服务。Alternatively, you can use the Azure Resource Manager deployment model to enable the Repair Manager service on new and existing Service Fabric clusters. 获取要部署的群集的模板。Get the template for the cluster that you want to deploy. 可以使用示例模板,或者创建自定义 Azure 资源管理器部署模型模板。You can either use the sample templates or create a custom Azure Resource Manager deployment model template.

若要使用 Azure 资源管理器部署模型模板启用修复管理器服务,请执行以下操作:To enable the Repair Manager service by using the Azure Resource Manager deployment model template, do the following:

  1. 检查并确保 Microsoft.ServiceFabric/clusters 资源的 apiVersion 设置为 2017-07-01-previewCheck to ensure that apiVersion is set to 2017-07-01-preview for the Microsoft.ServiceFabric/clusters resource. 否则,需要将 apiVersion 更新为 2017-07-01-preview 或更高的值:If it's different, you need to update apiVersion to 2017-07-01-preview or later:

    {
        "apiVersion": "2017-07-01-preview",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        ...
    }
    
  2. 通过在 fabricSettings 节后面添加以下 addonFeatures 节来启用修复管理器服务:Enable the Repair Manager service by adding the following addonFeatures section after the fabricSettings section:

    "fabricSettings": [
        ...      
    ],
    "addonFeatures": [
        "RepairManager"
    ],
    
  3. 通过这些更改更新群集模板后,应用更改并等待更新完成。After you've updated your cluster template with these changes, apply them and let the update finish. 现在可以看到修复管理器服务在群集中运行。You can now see the Repair Manager service running in your cluster. 它在 Service Fabric Explorer 中的系统服务部分中名为 fabric:/System/RepairManagerServiceIt's called fabric:/System/RepairManagerService in the system services section in Service Fabric Explorer.

独立的本地群集Standalone on-premises clusters

若要在新的或现有的 Service Fabric 群集上启用修复管理器服务,可以使用独立 Windows 群集的配置设置To enable the Repair Manager service on a new or existing Service Fabric cluster, you can use the Configuration settings for standalone Windows cluster.

启用修复管理器服务:To enable the Repair Manager service:

  1. 检查并确保 常规群集配置中的 apiVersion 设置为 04-2017 或更高的值,如下所示:Check to ensure that apiVersion in General cluster configurations is set to 04-2017 or later, as shown here:

    {
        "name": "SampleCluster",
        "clusterConfigurationVersion": "1.0.0",
        "apiVersion": "04-2017",
        ...
    }
    
  2. 通过在 fabricSettings 节后面添加以下 addonFeatures 节来启用修复管理器服务,如下所示:Enable the Repair Manager service by adding the following addonFeatures section after the fabricSettings section, as shown here:

    "fabricSettings": [
        ...      
    ],
    "addonFeatures": [
        "RepairManager"
    ],
    
  3. 通过这些更改更新群集清单后,使用已更新的群集清单创建新群集升级群集配置Update your cluster manifest with these changes by using the updated cluster manifest create a new cluster or upgrade the cluster configuration.

    群集使用已更新的群集清单运行后,就可以看到修复管理器服务在群集中运行。After the cluster is running with an updated cluster manifest, you can see the Repair Manager service running in your cluster. 其名为 fabric:/System/RepairManagerService,位于 Service Fabric Explorer 中的系统服务部分中。It's called fabric:/System/RepairManagerService, and it's in the system services section in Service Fabric Explorer.

为所有节点配置 Windows 更新Configure Windows updates for all nodes

自动 Windows 更新可能导致失去可用性,因为多个群集节点可能同时重启。Automatic Windows updates might lead to availability loss, because multiple cluster nodes can restart at the same time. POA 默认会尝试在每个群集节点上禁用自动 Windows 更新。POA, by default, tries to disable the automatic Windows updates on each cluster node. 但是,如果设置由管理员或组策略管理,建议将 Windows 更新策略显式设置为“下载之前发出通知”。However, if the settings are managed by an administrator or a Group Policy, we recommend setting the Windows Update policy to "Notify before Download" explicitly.

下载应用程序包Download the application package

若要下载应用程序包,请转到 GitHub 上的修补业务流程应用程序版本页To download the application package, go to the Patch Orchestration Application release page on GitHub.

配置 POA 的行为Configure POA behavior

可根据需求配置 POA 的行为。You can configure POA behavior to meet your needs. 在创建或更新应用程序时,通过传入应用程序参数来替代默认值。Override the default values by passing in the application parameter while you're creating or updating the application. 可以通过在 cmdlet Start-ServiceFabricApplicationUpgradeNew-ServiceFabricApplication 中指定 ApplicationParameter 来提供应用程序参数。You can provide application parameters by specifying ApplicationParameter to the Start-ServiceFabricApplicationUpgrade or New-ServiceFabricApplication cmdlets.

参数Parameter 类型Type 详细信息Details
MaxResultsToCacheMaxResultsToCache LongLong 应缓存的 Windows 更新结果的最大数目。The maximum number of Windows Update results that should be cached.

在假定以下情况时,默认值为 3000:The default value is 3000, assuming that:
  - 节点数为 20。  - The number of nodes is 20.
  - 节点上每月发生的更新次数为 5。  - The number of updates to a node per month is 5.
  - 每个操作的结果数可为 10。  - The number of results per operation can be 10.
  - 应存储过去三个月的结果。  - The results for the past three months should be stored.
TaskApprovalPolicyTaskApprovalPolicy 枚举Enum
{ NodeWise, UpgradeDomainWise }{ NodeWise, UpgradeDomainWise }
TaskApprovalPolicy 所指示的策略将由协调器服务用于跨 Service Fabric 群集节点安装 Windows 更新。TaskApprovalPolicy indicates the policy that is to be used by the Coordinator Service to install Windows updates across the Service Fabric cluster nodes.

允许的值为:The allowed values are:
NodeWise:每次在一个节点上安装 Windows 更新。NodeWise: Windows updates are installed one node at a time.
UpgradeDomainWise:每次在一个更新域上安装 Windows 更新。UpgradeDomainWise: Windows updates are installed one update domain at a time. (在最大程度情况下,属于更新域的所有节点都可进行 Windows 更新。)(At the most, all the nodes belonging to an update domain can go for a Windows update.)

若要帮助确定哪种策略最适合你的群集,请参阅常见问题解答部分。To help decide which policy is best suited for your cluster, see the FAQ section.
LogsDiskQuotaInMBLogsDiskQuotaInMB LongLong
(默认值:1024(Default: 1024)
可在节点本地持久保存的修补业务流程应用日志的最大大小,以 MB 为单位。The maximum size of patch orchestration app logs in MB, which can be persisted locally on nodes.
WUQueryWUQuery stringstring
(默认值:IsInstalled=0(Default: IsInstalled=0)
用于获取 Windows 更新的查询。Query to get Windows updates. 有关详细信息,请参阅 WuQueryFor more information, see WuQuery.
InstallWindowsOSOnlyUpdatesInstallWindowsOSOnlyUpdates 布尔值Boolean
(默认值:false)(default: false)
使用此标志来控制应当下载并安装哪些更新。Use this flag to control which updates should be downloaded and installed. 允许以下值Following values are allowed
true - 仅安装 Windows 操作系统更新。true - Installs only Windows operating system updates.
false - 在计算机上安装所有可用的更新。false - Installs all the available updates on the machine.
WUOperationTimeOutInMinutesWUOperationTimeOutInMinutes intInt
(默认值:90(Default: 90)
指示任何 Windows 更新操作(搜索、下载或安装)的超时。Specifies the timeout for any Windows Update operation (search or download or install). 在指定的超时内未完成的操作将被中止。If the operation is not completed within the specified timeout, it is aborted.
WURescheduleCountWURescheduleCount intInt
(默认值:5(Default: 5)
在操作持续失败的情况下,服务重新计划 Windows 更新的最大次数。The maximum number of times the service reschedules the Windows update if an operation fails persistently.
WURescheduleTimeInMinutesWURescheduleTimeInMinutes intInt
(默认值:30(Default: 30)
在持续失败的情况下,服务重新计划 Windows 更新的间隔。The interval at which the service reschedules the Windows updates if failure persists.
WUFrequencyWUFrequency 逗号分隔的字符串(默认值:Weekly, Wednesday, 7:00:00Comma-separated string (Default: Weekly, Wednesday, 7:00:00) 安装 Windows 更新的频率。The frequency for installing Windows updates. 其格式和可能的值包括:The format and possible values are:
- Monthly, DD, HH:MM:SS(示例:“Monthly, 5, 12:22:32”)。- Monthly, DD, HH:MM:SS (example: Monthly, 5, 12:22:32). 字段 DD(日)允许的值为 1 到 28 中的数字和“last”。Permitted values for field DD (day) are numbers from 1 through 28 and last.
- Weekly, Day, HH:MM:SS(示例:“Weekly, Tuesday, 12:22:32”)- Weekly, Day, HH:MM:SS (example: Weekly, Tuesday, 12:22:32)
- Daily, HH:MM:SS(示例:“Daily, 12:22:32”)- Daily, HH:MM:SS (example: Daily, 12:22:32)
- Week, Day, HH:MM:SS(示例:“2, Friday, 21:00:00”表示每月第二周周五晚上 9:00 UTC)- Week, Day, HH:MM:SS (example: 2, Friday, 21:00:00 indicates 9:00 PM UTC on Friday of the 2nd week of every month)
- “None”表示不应执行 Windows 更新。- None indicates that Windows updates shouldn't be done.

时间为 UTC 时间。Times are in UTC.
AcceptWindowsUpdateEulaAcceptWindowsUpdateEula 布尔Boolean
(默认值:true(Default: true)
设置此标志即表示该应用程序将代表计算机所有者接受 Windows 更新的最终用户许可协议。By setting this flag, the application accepts the End-User License Agreement for Windows Update on behalf of the owner of the machine.

提示

若要立即进行 Windows 更新,请依据应用程序部署时间设置 WUFrequencyIf you want Windows updates to happen immediately, set WUFrequency relative to the application deployment time. 例如,假设你有一个 5 节点测试群集,并计划在大约 UTC 下午 5:00 部署应用。For example, suppose that you have a five-node test cluster and plan to deploy the app at around 5:00 PM UTC. 如果假定应用程序升级或部署最多需要 30 分钟,请将 WUFrequency 设置为 Daily, 17:30:00If you assume that the application upgrade or deployment takes 30 minutes at most, set the WUFrequency as Daily, 17:30:00.

部署 POADeploy POA

  1. 若要准备群集,请完成所有先决条件步骤。Finish all the prerequisite steps to prepare the cluster.

  2. 像部署任何其他 Service Fabric 应用一样部署 POA。Deploy POA like any other Service Fabric app. 若要使用 PowerShell 进行部署,请参阅使用 PowerShell 部署和删除应用程序To deploy it by using PowerShell, see Deploy and remove applications using PowerShell.

  3. 若要在部署时配置应用程序,请将 ApplicationParameter 传递至 New-ServiceFabricApplication cmdlet。To configure the application at the time of deployment, pass the ApplicationParameter to the New-ServiceFabricApplication cmdlet. 为方便起见,我们随应用程序一同提供了脚本 Deploy.ps1。For your convenience, we've provided the script Deploy.ps1 along with the application. 使用脚本:To use the script:

    • 使用 Connect-ServiceFabricCluster 连接到 Service Fabric 群集。Connect to a Service Fabric cluster by using Connect-ServiceFabricCluster.
    • 结合相应的 ApplicationParameter 值执行 PowerShell 脚本 Deploy.ps1。Execute the PowerShell script Deploy.ps1 with the appropriate ApplicationParameter value.

备注

让脚本和应用程序文件夹 PatchOrchestrationApplication 始终位于同一目录中。Keep the script and the application folder PatchOrchestrationApplication in the same directory.

升级 POAUpgrade POA

若要使用 PowerShell 升级 POA 版本,请按照使用 PowerShell 进行 Service Fabric 应用程序升级中的说明操作。To upgrade your POA version by using PowerShell, follow the instructions in Service Fabric application upgrade using PowerShell.

删除 POARemove POA

若要删除应用程序,请按照使用 PowerShell 部署和删除应用程序中的说明操作。To remove the application, follow the instructions in Deploy and remove applications using PowerShell.

为方便起见,我们随应用程序一同提供了 Undeploy.ps1 脚本。For your convenience, we've provided the Undeploy.ps1 script along with the application. 使用脚本:To use the script:

  • 使用 Connect-ServiceFabricCluster 连接到 Service Fabric 群集。Connect to a Service Fabric cluster by using Connect-ServiceFabricCluster.
  • 执行 PowerShell 脚本 Undeploy.ps1。Execute the PowerShell script Undeploy.ps1.

备注

让脚本和应用程序文件夹 PatchOrchestrationApplication 始终位于同一目录中。Keep the script and the application folder PatchOrchestrationApplication in the same directory.

查看 Windows 更新结果View the Windows Update results

POA 公开 REST API 以向用户显示历史结果。POA exposes REST APIs to display the historical results to users. 下面是 JSON 结果的示例:Here's an example of the result 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 Azure software product that could affect your system. You can help protect your system by installing this update from Azure. 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 字段:The JSON fields are described in the following table:

字段Field Values 详细信息Details
OperationResultOperationResult 0 - 已成功0 - Succeeded
1 - 已成功但有错误1 - Succeeded With Errors
2 - 已失败2 - Failed
3 - 已中止3 - Aborted
4 - 已中止,超时4 - Aborted With Timeout
指示整个操作(通常涉及安装一个或多个更新)的结果。Indicates the result of the overall operation, which ordinarily involves the installation of one or more updates.
ResultCodeResultCode 与 OperationResult 相同Same as OperationResult 此字段指示单个更新的安装操作的结果。This field indicates the result of the installation operation for an individual update.
OperationTypeOperationType 1 - 安装1 - Installation
0 - 搜索并下载0 - Search and Download
默认情况下,“安装”是结果中显示的唯一 OperationType。By default, Installation is the only OperationType that's shown in the results.
WindowsUpdateQueryWindowsUpdateQuery 默认值为 "IsInstalled=0"Default is "IsInstalled=0" 用来搜索更新的 Windows 更新查询。The Windows Update query that was used to search for updates. 有关详细信息,请参阅 WuQueryFor more information, see WuQuery.
RebootRequiredRebootRequired true - 需要重新启动true - reboot was required
true - 不需要重新启动false - reboot was not required
指示是否需要重新启动才能完成安装更新。Indicates whether a reboot was required to complete the installation of updates.
OperationStartTimeOperationStartTime DateTimeDateTime 指示启动操作(下载/安装)的时间。Indicates the time at which operation(Download/Installation) started.
OperationTimeOperationTime DateTimeDateTime 指示完成操作(下载/安装)的时间。Indicates the time at which operation(Download/Installation) was completed.
HResultHResult 0 - 成功0 - Successful
其他 - 失败other - failure
指示 Windows 更新失败并出现 updateID“7392acaf-6a85-427c-8a8d-058c25beb0d6”的原因。Indicates the reason for the failure of the Windows update with updateID "7392acaf-6a85-427c-8a8d-058c25beb0d6".

如果尚未计划更新,则生成的 JSON 为空。If no update is scheduled yet, the result JSON is empty.

请登录到群集以查询 Windows 更新结果。Sign in to the cluster to query Windows Update results. 找出协调器服务的主要地址的副本 IP 地址,并在浏览器中打开以下 URL: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults。Find out the replica IP address for the primary address of the Coordinator Service, and open the following URL from the browser: http://<REPLICA-IP>:<ApplicationPort>/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

协调器服务的 REST 终结点有一个动态端口。The REST endpoint for the Coordinator Service has a dynamic port. 若要查看确切的 URL,请参考 Service Fabric Explorer。To check the exact URL, refer to Service Fabric Explorer. 例如,可在 http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults 处获取结果。For example, the results are available at http://10.0.0.7:20000/PatchOrchestrationApplication/v1/GetWindowsUpdateResults.

REST 终结点的插图

如果在群集上启用了反向代理,则也可从群集外部访问该 URL。If the reverse proxy is enabled on the cluster, you can access the URL from outside the cluster as well.

需要访问的终结点是 http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResultsThe endpoint that you need to hit is http://<SERVERURL>:<REVERSEPROXYPORT>/PatchOrchestrationApplication/CoordinatorService/v1/GetWindowsUpdateResults.

若要在群集上启用反向代理,请按照 Azure Service Fabric 中的反向代理中的说明操作。To enable the reverse proxy on the cluster, follow the instructions in Reverse proxy in Azure Service Fabric.

警告

配置反向代理后,公开 HTTP 终结点的群集中的所有微服务都可从群集外部进行访问。After the reverse proxy is configured, all microservices in the cluster that expose an HTTP endpoint are addressable from outside the cluster.

诊断和运行状况事件Diagnostics and health events

本部分介绍如何通过 Service Fabric 群集上的 POA 调试或诊断修补更新问题。This section discusses how to debug or diagnose issues with patch updates through POA on Service Fabric clusters.

备注

若要获取下面列出的多项自我诊断改进功能,请安装 POA 1.4.0 或更高版本。To get many of the following called-out, self-diagnostic improvements, you should have POA version 1.4.0 or later installed.

节点代理 NTService 创建修复任务用于在节点上安装更新。The Node Agent NTService creates repair tasks for installing updates on the nodes. 然后,协调器服务根据任务审批策略准备每个任务。Each task is then prepared by the Coordinator Service according to the task approval policy. 准备好的任务最终由修复管理器审批,如果群集处于不正常状态,修复管理器不会批准任何任务。Finally, the prepared tasks are approved by Repair Manager, which doesn't approve any task if the cluster is in an unhealthy state.

让我们逐步了解如何在节点上继续更新:To help you understand how updates proceed on a node, let's go step by step:

  1. 在每个节点上运行的 NodeAgentNTService 按计划的时间查找可用的 Windows 更新。NodeAgentNTService, running on every node, looks for available Windows updates at the scheduled time. 如果有可用的更新,它会将更新下载到节点上。If updates are available, it downloads them on the node.

  2. 下载更新后,节点代理 NTService 将为节点创建名为“POS___<unique_id>”的相应修复任务。After the updates are downloaded, the Node Agent NTService creates a corresponding repair task for the node with the name POS___<unique_id>. 可以使用 Get-ServiceFabricRepairTask cmdlet 或节点详细信息部分所述的 SFX 查看这些修复任务。You can view these repair tasks by using the Get-ServiceFabricRepairTask cmdlet or using SFX in the node details section. 创建修复任务后,它会立即转到 Claimed 状态After the repair task is created, it quickly moves to Claimed state.

  3. 协调器服务定期查找处于 Claimed 状态的修复任务,然后根据 TaskApprovalPolicy 将这些任务更新到 Preparing 状态。The Coordinator Service periodically looks for repair tasks in Claimed state and then updates them to Preparing state based on TaskApprovalPolicy. 如果 TaskApprovalPolicy 配置为 NodeWise,仅当没有任何其他修复任务当前处于 PreparingApprovedExecutingRestoring 状态时,才会准备对应于节点的修复任务。If TaskApprovalPolicy is configured to be NodeWise, a repair task that corresponds to a node is prepared only if no other repair task is currently in Preparing, Approved, Executing, or Restoring state.

    同理,如果 TaskApprovalPolicy 配置为 UpgradeWise,只有属于同一个更新域的节点才具有处于上述状态的任务。Similarly, in the case of UpgradeWise TaskApprovalPolicy, there are tasks in the preceding states only for nodes that belong to the same update domain. 在修复任务转到 Preparing 状态后,相应的 Service Fabric 节点将会 禁用,其意图设置为 RestartAfter a repair task is moved to Preparing state, the corresponding Service Fabric node is disabled with the intent set to Restart.

    POA 1.4.0 和更高版本使用 CoordinatorService 上的 ClusterPatchingStatus 属性发布事件,以显示正在修补的节点。POA versions 1.4.0 and later post events with the ClusterPatchingStatus property on CoordinatorService to display the nodes that are being patched. 更新将在 _poanode_0 上安装,如下图所示:The updates are installed on _poanode_0, as shown in the following image:

    群集修补状态的插图 Image of cluster patching status

  4. 禁用该节点后,修复任务将转到 Executing 状态。After the node is disabled, the repair task is moved to Executing state.

    备注

    停滞在 Disabled 状态的节点可能会导致阻止新的修复任务,因此会停止群集上的修补操作。A node that's stuck in Disabled state can block a new repair task, which halts the patching operation on the cluster.

  5. 修复任务进入 Executing 状态时,将开始在该节点上安装修补程序。When the repair task is in Executing state, the patch installation on that node begins. 安装修补程序后,节点不一定重启,具体取决于安装的修补程序。After the patch is installed, the node might or might not be restarted, depending on the patch. 接下来,修复任务将转到 Restoring 状态,这会重新启用节点。Next, the repair task is moved to Restoring state, which reenables the node. 然后,修复任务将标记为 completed。The repair task is then marked as completed.

    在 POA 1.4.0 和更高版本中,可以使用“WUOperationStatus-<NodeName>”属性查看 NodeAgentService 上的运行状况事件,以便查找更新的状态。In POA versions 1.4.0 and later, you can find the status of the update by viewing the health events on NodeAgentService with the WUOperationStatus-<NodeName> property. 下图中的突出显示部分显示了节点 poanode_0poanode_2 上的 Windows 更新状态:The highlighted sections in the following images show the status of Windows updates on nodes poanode_0 and poanode_2:

    屏幕截图显示了包含 Windows 更新操作状态的控制台窗口,其中突出显示了 poanode_0。 Screenshot shows console window of Windows Update operation status with poanode_0 highlighted.

    屏幕截图显示了包含 Windows 更新操作状态的控制台窗口,其中突出显示了 poanode_1。 Screenshot shows console window of Windows Update operation status with poanode_1 highlighted.

    也可以使用 PowerShell 获取详细信息。You can also get the details by using PowerShell. 为此,请连接到群集并使用 Get-ServiceFabricRepairTask 提取修复任务的状态。To do so, you connect to the cluster and fetch the state of the repair task by using Get-ServiceFabricRepairTask.

    在以下示例中,“POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15”任务处于 DownloadComplete 状态。In the following example, the "POS__poanode_2_125f2969-933c-4774-85d1-ebdf85e79f15" task is in DownloadComplete state. 这表示更新已下载到 poanode_2 节点,任务转为 Executing 状态后,将尝试安装这些更新。It means that updates have been downloaded on the poanode_2 node, and the installation will be attempted when the task moves to Executing state.

    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 事件日志来了解相关信息。If more issues remain to be found, sign in to your virtual machine (VM) or VMs and learn about them by using Windows event logs. 上述修复任务只能在以下执行程序子状态下存在:The previously mentioned repair task can exist in only the following executor substates:

    ExecutorSubStateExecutorSubState 说明Description
    None=1None=1 表示节点上没有正在进行的操作。Implies that there wasn't an ongoing operation on the node. 状态可能正在过渡。The state might be in transition.
    DownloadCompleted=2DownloadCompleted=2 表示下载操作已完成,状态为成功、部分失败或失败。Implies that the download operation was completed with success, partial failure, or failure.
    InstallationApproved=3InstallationApproved=3 表示下载操作已提前完成,修复管理器已批准安装。Implies that the download operation was completed earlier and Repair Manager has approved the installation.
    InstallationInProgress=4InstallationInProgress=4 对应于修复任务的执行状态。Corresponds to the state of execution of the repair task.
    InstallationCompleted=5InstallationCompleted=5 表示安装已完成,状态为成功、部分成功或失败。Implies that the installation was completed with success, partial success, or failure.
    RestartRequested=6RestartRequested=6 表示修补程序安装已完成,节点上有一个挂起的重启操作。Implies that the patch installation was completed and there's a pending restart action on the node.
    RestartNotNeeded=7RestartNotNeeded=7 表示完成修补程序安装后不需要重启。Implies that the restart wasn't needed after the patch installation was completed.
    RestartCompleted=8RestartCompleted=8 表示重启已成功完成。Implies that the restart was completed successfully.
    OperationCompleted=9OperationCompleted=9 Windows 更新操作已成功完成。The Windows Update operation was completed successfully.
    OperationAborted=10OperationAborted=10 表示 Windows 更新操作已中止。Implies that the Windows Update operation was aborted.
  6. 在 POA 1.4.0 和更高版本中,当节点更新尝试完成后,将在 NodeAgentService 上发布一个包含属性“WUOperationStatus-[NodeName]”的事件,以通知下一次要在何时开始尝试下载并安装 Windows 更新。In POA versions 1.4.0 and later, when a node update attempt finishes, an event with the "WUOperationStatus-[NodeName]" property is posted on NodeAgentService to notify you when the next attempt to download and install the Windows updates will begin. 下图显示了此信息:This is displayed in the following image:

    屏幕截图显示了带有 NodeAgentService 的 Windows 更新操作状态的控制台窗口。 Screenshot shows console window of Windows Update operation status with the NodeAgentService.

诊断日志Diagnostics logs

修补业务流程应用程序日志是作为 Service Fabric 运行时日志的一部分进行收集的。Patch orchestration application logs are collected as part of the Service Fabric runtime logs.

可以使用所选的诊断工具或管道来捕获日志。You can capture logs by using the diagnostic tool or pipeline of your choice. POA 使用以下固定的提供程序 ID 通过事件源记录事件:POA uses the following fixed provider IDs to log events via event source:

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

运行状况报告Health reports

对于以下情况,POA 还会针对节点代理服务或协调器服务发布运行状况报告:POA also publishes health reports against the Node Agent Service or the Coordinator Service in the following scenarios:

  • 节点代理 NTService 关闭The Node Agent NTService is down

    如果某个节点上的节点代理 NTService 关闭,将会针对节点代理服务生成警告级别的运行状况报告。If the Node Agent NTService is down on a node, a warning-level health report is generated against the Node Agent Service.

  • 未启用修复管理器服务The Repair Manager service is not enabled

    如果在群集上找不到修复管理器服务,将会针对协调器服务生成警告级别的运行状况报告。If the Repair Manager service is not found on the cluster, a warning-level health report is generated for the Coordinator Service.

常见问题Frequently asked questions

问:当 POA 正在运行时,群集为何处于错误状态?Q: Why do I see my cluster in an error state when POA is running?

答:在安装过程中,POA 将会禁用或重启节点,这可能会暂时导致群集处于不正常状态。A: During the installation process, POA disables or restarts nodes, which can temporarily result in an unhealthy cluster.

根据应用程序的策略,执行修补操作期间可以让一个节点关闭,或者可以让整个更新域完全关闭。Depending on the application's policy, either one node can go down during a patching operation or an entire update domain can go down all at once.

在 Windows 更新安装结束时,节点会在重启后重新启用。By the end of the Windows updates installation, the nodes are reenabled post-restart.

在以下示例中,由于两个节点关闭且违反了 MaxPercentageUnhealthyNodes 策略,群集暂时进入了错误状态。In the following example, the cluster went to an error state temporarily because two nodes were down and the MaxPercentageUnhealthyNodes policy was violated. 这是暂时性错误,在修补操作开始后即可恢复。The error is temporary until the patching operation can begin.

不正常群集的图像

如果问题持续出现,请参阅“故障排除”部分。If the issue persists, refer to the Troubleshooting section.

问:如果 POA 处于警告状态,该怎么办?Q: What can I do if POA is in a warning state?

答:检查针对应用程序发布的运行状况报告是否指示了根本原因。A: Check to see whether a health report posted against the application indicates the root cause. 通常,警告中会包含问题的详细信息。Usually, the warning contains details of the problem. 如果该问题是暂时性的,则应用程序预期会自动恢复。If the issue is transient, the application is expected to recover automatically.

问:如果群集运行不正常,而我需要进行紧急的操作系统更新,该怎么办?Q: What can I do if my cluster is unhealthy and I need to do an urgent operating system update?

答:如果群集不正常,POA 不会安装更新。A: POA does not install updates while the cluster is unhealthy. 请尝试将群集恢复正常状态,以取消阻止 POA 工作流。Try to bring your cluster to a healthy state to unblock the POA workflow.

问:对于我的群集,应将 TaskApprovalPolicy 设置为“NodeWise”还是“UpgradeDomainWise”?Q: Should I set TaskApprovalPolicy as "NodeWise" or "UpgradeDomainWise" for my cluster?

答:“UpgradeDomainWise”设置通过同时修补属于某个更新域的所有节点,来加快总体群集修复速度。A: The "UpgradeDomainWise" setting speeds up overall cluster repair by patching in parallel all the nodes that belong to an update domain. 在此过程中,属于整个更新域的节点将不可用(处于 Disabled 状态)。During the process, nodes that belong to an entire update domain are unavailable (in Disabled state).

相比之下,“NodeWise”设置每次只修补一个节点,这意味着,总体群集修补可能需要更长时间。In contrast, the "NodeWise" setting patches only one node at a time, which would imply that overall cluster patching might take longer. 但是,在修补过程中最多只有一个节点不可用(处于 Disabled 状态)。However, only one node at most would be unavailable (in Disabled state) during the patching process.

如果群集在修补周期内可以容忍在 N-1 个更新域上运行(其中 N 是群集上更新域的总数),则你可以将策略设置为“UpgradeDomainWise”。If your cluster can tolerate running on an N-1 number of update domains during patching cycle (where N is the total number of update domains on your cluster) you can set the policy as "UpgradeDomainWise." 否则,请将其设置为“NodeWise”。Otherwise, set it to "NodeWise."

问:修补一个节点需要多长时间?Q: How much time does it take to patch a node?

答:修补一个节点可能需要几分钟(例如 Windows Defender 定义更新)到几小时(例如 Windows 累积更新)。A: Patching a node can take from minutes (for example, Windows Defender definition updates) to hours (for example, Windows Cumulative updates). 修补一个节点所需的时间主要取决于:The time that's required to patch a node depends mostly on:

  • 更新的大小。The size of the updates.
  • 必须在修补窗口中应用的更新数。The number of updates, which have to be applied in a patching window.
  • 安装更新、重新启动节点(如果需要)以及完成重新启动后安装步骤所需的时间。The time it takes to install the updates, reboot the node (if required), and finish the post-reboot installation steps.
  • VM 或计算机的性能以及网络状况。The performance of the VM or machine, and network conditions.

问:修补整个群集需要多长时间?Q: How long does it take to patch an entire cluster?

答:修补整个群集所需的时间取决于:A: The time that's required to patch an entire cluster depends on:

  • 修补一个节点所需的时间。The time needed to patch a node.

  • 协调器服务的策略。The policy of the Coordinator Service. 如果使用默认策略“NodeWise”,则每次只会修补一个节点,这种方法比使用“UpgradeDomainWise”要慢。The default policy, "NodeWise," results in patching only one node at a time, an approach that's slower than using "UpgradeDomainWise."

    例如:如果修补一个节点需要大约 1 小时,那么,修补包含 5 个更新域(每个更新域包含 4 个节点)的 20 节点(节点类型相同)群集需要:For example: If a node takes ~1 hour to be patched, patching a 20-node (same type of nodes) cluster with 5 update domains, each containing 4 nodes, requires:

    • 使用“NodeWise”时:大约 20 小时。For "NodeWise": ~20 hours.
    • 使用“UpgradeDomainWise”时:大约 5 小时。For "UpgradeDomainWise": ~5 hours.
  • 群集负载。The cluster load. 每个修补操作都需要将客户工作负荷重新分配到群集中的其他可用节点。Each patching operation requires relocating the customer workload to other available nodes in the cluster. 正在进行修补的节点在此期间将处于 Disabling 状态A node that's being patched would be in Disabling state during this time. 如果群集正在运行接近峰值负载,则禁用过程将需要更长时间。If the cluster is running near peak load, the disabling process would take longer. 因此,在这种重压条件下,整个修补过程可能会看起来很慢。Therefore, the overall patching process might appear to be slow in such stressed conditions.

  • 修补期间的群集运行状况错误。Cluster health failures during patching. 群集运行状况出现任何降级都会中断修补过程。Any degradation in the health of the cluster would interrupt the patching process. 此问题会增加修补整个群集所需的总时间。This issue would add to the overall time required to patch the entire cluster.

问:为什么某些更新会出现在通过 REST API 获得的 Windows 更新结果中,而不是在计算机的 Windows 更新历史记录下?Q: Why do I see some updates in the Windows Update results that are obtained via REST API, but not under the Windows Update history on the machine?

答:某些产品更新仅在其自身的更新或修补程序历史记录中出现。A: Some product updates appear only in their own update or patch history. 例如,Windows Defender 更新不一定会显示在 Windows Server 2016 上的 Windows 更新历史记录中。For example, Windows Defender updates might or might not be displayed in Windows Update history on Windows Server 2016.

问:是否可以使用 POA 修补开发群集(单节点群集)?Q: Can POA be used to patch my dev cluster (one-node cluster)?

答:POA 不可用于修补单节点群集。A: No, POA can't be used to patch a one-node cluster. 此限制是设计使然,因为 Service Fabric 系统服务或其他客户应用会造成停机。This limitation is by design, because Service Fabric system services or other customer apps would incur downtime. 因此,修复管理器永远不会批准修补修复作业。Therefore, patching repair jobs would never get approved by Repair Manager.

问:如何在 Linux 上修补群集节点?Q: How do I patch cluster nodes on Linux?

答:若要了解 Linux 上的协调更新,请参阅 Azure 虚拟机规模集自动 OS 映像升级A: To learn about orchestrating updates on Linux, see Azure virtual machine scale set automatic OS image upgrades.

问:为何更新周期需要花费这么长时间?Q: Why is the update cycle taking so long?

答:查询结果 JSON,进入所有节点的更新周期,然后可以尝试使用 OperationStartTime 和 OperationTime (OperationCompletionTime) 来了解在每个节点上安装更新所花费的时间。A: Query for the result JSON, enter the update cycle for all nodes, and then you can try to find out the time taken by update installation on every node by using OperationStartTime and OperationTime (OperationCompletionTime).

如果在某个较长时间段内未进行更新,原因可能是群集处于错误状态,因此,修复管理器无法批准任何 POA 修复任务。If there's a large time window in which no update is taking place, the cluster might be in an error state and, consequently, Repair Manager can't approve any POA repair tasks. 如果任一节点上的更新安装花费了较长时间,原因可能是该节点有一段时间未曾更新过。If the update installation is taking a long time on any node, that node might not have been updated in a while. 可能有大量的更新正在等待安装,因此导致了延迟。A lot of updates might be pending installation, which can result in delays.

此外,可能该节点停滞在 Disabling 状态,因此其修补被阻止。It might also be possible that node patching is blocked because it's stuck in Disabling state. 这种情况往往是禁用节点导致仲裁或数据丢失造成的。This usually happens because disabling the node might lead to quorum or data loss situations.

问:POA 修补节点时为何必须禁用该节点?Q: Why must the node be disabled when POA is patching it?

答:POA 使用 Restart 意图禁用节点,这会停止或重新分配该节点上运行的所有 Service Fabric 服务。A: POA disables the node with a Restart intent, which stops or reallocates all the Service Fabric services that are running on the node. POA 这样做的目的是确保应用程序最终不会混用新的和旧的 DLL,因此,我们不建议在未禁用节点的情况下对其进行修补。POA does this to ensure that applications don't end up using a mix of new and old DLLs, so we recommend not patching a node without disabling it.

问:可以使用 POA 更新的最大节点数是多少?Q: What is the maximum number of nodes that can be updated by using POA?

答:POA 使用 Service Fabric 修复管理器为要更新的节点创建修复任务。A: POA uses Service Fabric Repair Manager to create repair tasks for nodes for updates. 但是,同时存在的修复任务不能超过 250 个。However, no more than 250 repair tasks can be present at the same time. 目前,POA 会同时为每个节点创建修复任务,因此 POA 在一个群集中最多只能更新 250 个节点。Currently, POA creates repair tasks for each node at the same time, so POA can update no more than 250 nodes in a cluster.

免责声明Disclaimers

  • POA 代表用户接受 Windows 更新的最终用户许可协议。POA accepts the End-User License Agreement for Windows Update on behalf of the user. 可以选择在应用程序的配置中关闭该设置。Optionally, the setting can be turned off in the configuration of the application.

  • POA 收集遥测数据以跟踪使用情况和性能。POA collects telemetry to track usage and performance. 应用程序的遥测遵循 Service Fabric 运行时的遥测设置(默认为启用)。The application's telemetry follows the setting of the Service Fabric runtime's telemetry setting (which is on by default).

故障排除Troubleshooting

本部分提供修补节点时出现的问题的可能故障排除解决方法。This section provides possible troubleshooting solutions to problems with patching nodes.

节点无法恢复启动状态A node is not coming back to up state

  • 节点可能会出于以下原因停滞在 Disabling 状态:The node might be stuck in Disabling state because:

    • 安全检查已挂起。A safety check is pending. 若要纠正此情况,请确保有足够多的节点处于正常状态。To remedy this situation, ensure that enough nodes are available in a healthy state.
  • 节点可能会出于以下原因停滞在 Disabled 状态:The node might be stuck in Disabled state because:

    • 已手动禁用节点。It was disabled manually.
    • 某个正在进行的 Azure 基础结构作业导致禁用了节点。It was disabled because of an ongoing Azure infrastructure job.
    • POA 已暂时禁用节点以对其进行修补。It was disabled temporarily by POA to patch the node.
  • 节点可能会出于以下原因停滞在关闭状态:The node might be stuck in a down state because:

    • 手动将节点置于关闭状态。It was placed in a down state manually.
    • 节点正在重启(可能由 POA 触发)。It is undergoing a restart (which might be triggered by POA).
    • VM 或计算机出现故障,或出现网络连接问题。It has a faulty VM or machine, or it's having network connectivity issues.

在某些节点上跳过了更新Updates were skipped on some nodes

POA 根据重新计划策略尝试安装 Windows 更新。POA tries to install a Windows update according to the rescheduling policy. 服务根据应用程序策略尝试恢复节点并跳过更新。The service tries to recover the node and skip the update according to the application policy.

在这种情况下,将针对节点代理服务生成警告级别的运行状况报告。In such a case, a warning-level health report is generated against the Node Agent Service. Windows 更新结果也包含可能的失败原因。The Windows Update result also contains the possible reason for the failure.

安装更新时群集运行状况转为错误状态The health of the cluster goes to error while the update is being installed

Windows 更新发生故障时,会使特定节点或更新域上的应用程序或群集的运行状况恶化。A faulty Windows update can bring down the health of an application or cluster on a particular node or update domain. POA 会终止任何后续的 Windows 更新操作,直到群集再次正常运行。POA discontinues any subsequent Windows Update operation until the cluster is healthy again.

管理员必须介入,并判断为何 Windows 更新会导致应用程序或群集运行不正常。An administrator must intervene and determine why the application or cluster became unhealthy because of Windows Update.

POA 发行说明POA release notes

备注

对于 POA 版本 1.4.0 及更高版本,可以在 GitHub 的修补业务流程应用程序版本页上找到发行说明和版本。For POA versions 1.4.0 and later, you can find release notes and releases on the Patch Orchestration Application release page on GitHub.

版本 1.1.0Version 1.1.0

  • 公开发布的版本Public release

版本 1.1.1Version 1.1.1

  • 修复了 NodeAgentService 的 SetupEntryPoint 中的 bug,可阻止安装 NodeAgentNTService。Fixed a bug in SetupEntryPoint of NodeAgentService that prevented installation of NodeAgentNTService.

版本 1.2.0Version 1.2.0

  • 系统重启工作流中的 Bug 修复。Bug fixes around system restart workflow.
  • 由于修复任务准备过程中的运行状况检查,RM 任务创建过程中的 Bug 修复未能按预期方式进行。Bug fix in creation of RM tasks due to which health check during preparing repair tasks wasn't happening as expected.
  • 将 Windows 服务 POANodeSvc 的启动模式从自动更改为延时自动。Changed the startup mode for Windows service POANodeSvc from auto to delayed-auto.

版本 1.2.1Version 1.2.1

  • 群集缩减工作流中的 Bug 修复。Bug fix in cluster scale-down workflow. 引入了针对不存在节点中 POA 修复任务的垃圾回收逻辑。Introduced garbage collection logic for POA repair tasks belonging to non-existent nodes.

版本 1.2.2Version 1.2.2

  • 其他 Bug 修复。Miscellaneous bug fixes.
  • 二进制文件现已签名。Binaries are now signed.
  • 为应用程序添加了 sfpkg 链接。Added sfpkg link for the application.

版本 1.3.0Version 1.3.0

  • 将 InstallWindowsOSOnlyUpdates 设置为 false 现在会安装所有可用的更新。Setting InstallWindowsOSOnlyUpdates to false now installs all the available updates.
  • 更改了禁用自动更新的逻辑。Changed the logic of disabling automatic updates. 这修复了在 Server 2016 及更高版本上不会禁用自动更新的 bug。This fixes a bug where Automatic updates were not getting disabled on Server 2016 and above.
  • 针对高级用例,对 POA 的微服务的放置约束进行了参数化。Parameterized placement constraint for both the microservices of POA for advanced use cases.

版本 1.3.1Version 1.3.1

  • 修复了因为禁用自动更新失败而导致 POA 1.3.0 无法在 Windows Server 2012 R2 或更早版本上运行的回归。Fixing regression where POA 1.3.0 won't work on Windows Server 2012 R2 or earlier because of a failure in disabling automatic updates.
  • 修复了 InstallWindowsOSOnlyUpdates 配置总是被选为 True 的 bug。Fixing bug where InstallWindowsOSOnlyUpdates configuration is always picked as True.
  • 将 InstallWindowsOSOnlyUpdates 的默认值更改为 False。Changing default value of InstallWindowsOSOnlyUpdates to False.

版本 1.3.2Version 1.3.2

  • 修复了一个问题,如果存在其名称属于当前节点名称子集的节点,此问题会影响节点上的修补生命周期。Fixing an issue that affects the patching lifecycle on a node, if there are nodes with a name that's a subset of the current node name. 对于此类节点,可能出现修补缺失或重启操作挂起的情况。For such nodes, it's possible that patching was missed or a reboot is pending.