处理计划内维护通知

适用于：✔️ Linux VM ✔️ Windows VM ✔️ 灵活规模集 ✔️ 统一规模集

Azure 定期执行更新，以提高虚拟机的主机基础结构的可靠性、性能及安全性。 更新是指诸如对托管环境打补丁，或对硬件进行升级和停用之类的更改。 大多数此类更新在完成时不会影响托管的虚拟机。 但是，也会存在更新产生影响的情况：

• 如果维护不需要重启，Azure 会在主机更新时暂停 VM 几秒钟。 这些维护操作按容错域逐一应用。 如果接收到任何警告健康状况信号，则进程将停止。

• 如果维护需重新启动，系统会告知计划维护的时间。 系统会提供一个大约 35 天的时间窗口，方便我们在适当的时间自行启动维护。

需要重启的计划内维护将分批进行。 每个波次的覆盖范围（地区）都不同。

• 一个批从向客户发送通知开始。 Azure 门户中的服务运行状况下提供了与虚拟机相关的维护通知。 对于一小部分特定于虚拟机计划内维护的场景，Azure 还可通过向订阅所有者组的成员发送附加电子邮件来传达计划。 Azure 服务运行状况使用户能够针对“计划内维护”类别配置自己的自定义警报。 借助 Azure 服务运行状况警报，可使用活动日志警报添加更多收件人和消息传送选项，例如电子邮件、短信和 Webhook。
• 除部分事件类型外，服务运行状况计划内维护通知现在还有一个附加选项卡“受影响的资源”，其中列出了事件范围内的 VM 名称。 详细了解受影响的资源预览功能。
• 通知发出后，将开放一个自助服务窗口。 在此时间窗口内，你可以查询哪些虚拟机受影响，并根据你自己的计划需求来启动维护。 自助服务时间窗口通常为大约 35 天。
• 在自助服务时段之后，计划维护窗口开始。 在此时段的某个时刻，Azure 会计划所需的维护，并将其应用于虚拟机。

设置这两个时段的目的是，在了解 Azure 何时将自动启动维护时，提供足够的时间来启动维护和重新启动虚拟机。

可以使用 Azure 门户、PowerShell、REST API 和 CLI 查询 VM 的维护时段并启动自助式维护。

你是否应在自助服务窗口期内开始维护？

以下指南应能帮助您决定是否使用此功能，并在您方便的时候开始维护。

对于使用可用性集的部署，不推荐使用自助维护。 可用性集一次只能更新一个更新域。

• 让 Azure 触发维护。 对于需要重启的维护操作，将按更新域逐一进行。 各个更新域不一定会按顺序接受维护，并且每个更新域之间会有 30 分钟的暂停。
• 如果某些容量（1 个更新域）的临时损失是个需要顾虑的问题，在维护期间可以增加实例。
• 对于无需重启的维护，将在容错域级别应用更新。

以下情况请勿使用自助维护：

• 如果您频繁关闭虚拟机，无论是手动关闭、使用 DevTest Labs、使用自动关闭功能，还是按计划关闭，都可能导致维护状态恢复，从而造成额外的停机时间。
• VM 的生存期短，已确定在维护结束之前就会被删除。
• 对于那些在本地（临时）磁盘中存储了大量状态数据，且希望在更新后仍予以保留的工作负载。
• 对于经常调整 VM 大小的情况，请注意，这可能会使维护状态恢复原状。
• 如果您已采用可实现工作负载主动故障转移或正常关机的计划事件，则会在维护关机开始前 15 分钟

如果打算在计划性维护阶段不间断地运行 VM，而且上述禁忌均不适用，则可使用自助维护。

以下情况最好使用自助维护：

• 需要向管理层或最终客户告知确切的维护时段。
• 需要在给定的日期之前完成维护。
• 需要控制维护顺序，例如，应用程序为多层应用程序，需要确保安全地进行恢复。
• 在两个更新域 (UD) 之间，需要的 VM 恢复时间超过 30 分钟。 要控制更新域之间的时间间隔，必须一次按一个更新域 (UD) 对 VM 触发维护。

FAQ

问：为什么需要立即重新启动虚拟机？

答：虽然对 Azure 平台的大多数更新和升级不会影响虚拟机的可用性，但在某些情况下无法避免重启 Azure 中托管的虚拟机。 我们累积了多个需要重启服务器的更改，这会导致虚拟机重启。

问：如果我按建议使用可用性集实现高可用性，我是否安全？

答: 部署在可用性集或虚拟机规模集中的虚拟机具有更新域 (UD) 这一概念。 执行维护时，Azure 遵循 UD 约束，不会从不同 UD（在同一可用性集中）重启虚拟机。 Azure 还会至少等待 30 分钟，然后才移到下一组虚拟机。

有关高可用性的详细信息，请参阅 Azure 中虚拟机的可用性。

问：如何收到有关计划内维护的通知？

答: 计划内维护波次首先通过为一个或多个 Azure 区域设置计划来开始。 Azure 门户中的服务运行状况下提供了与虚拟机相关的维护通知。 对于一小部分特定于虚拟机计划内维护的场景，Azure 还可通过向订阅所有者组的成员发送附加电子邮件来传达计划。

除部分事件类型外，服务运行状况计划内维护通知现在还有一个附加选项卡“受影响的资源”，其中列出了事件范围内的 VM 名称。 详细了解受影响的资源预览功能。

Azure 服务运行状况使用户能够针对“计划内维护”类别配置自己的自定义警报。 借助 Azure 服务运行状况警报，可使用活动日志警报添加更多收件人和消息传送选项，例如电子邮件、短信和 Webhook。

如果将虚拟机部署到已安排计划内维护的区域，将不会收到通知，而是需要检查 VM 的维护状态。

问：我在门户、PowerShell 或 CLI 中看不到计划内维护的任何指示。 出了什么问题？

答: 只有在计划内维护波次期间，才可查看与计划内维护相关的信息，且仅针对将受此次计划内维护影响的 VM。 换而言之，如果你看不到数据，则可能是这次维护已完成（或未启动）或虚拟机已在更新的服务器中托管。

问：有什么方法可以知道虚拟机受影响的确切时间？

答: 设置计划时，我们定义了长达几天的时间窗口。 但是，服务器（和 VM）在此时间窗口内的确切排序是未知的。 想要知道其 VM 确切时间的客户可以使用计划事件并从虚拟机中进行查询，这样就会在 VM 重启前 15 分钟收到通知。

问：重新启动虚拟机需要多长时间？

答: 根据 VM 的大小，在自助维护时段内，重启最多可能需要几分钟时间。 当 Azure 在计划性维护时段内启动重启时，重启通常需要 25 分钟左右。 请注意，如果您使用云服务（Web/辅助角色）、虚拟机规模集或可用性集，则在计划内维护时段内，每组虚拟机 (UD) 之间将有 30 分钟的间隔时间。

问：使用虚拟机规模集时的体验如何？

答: 计划内维护现在适用于虚拟机规模集。 有关如何发起自助维护的说明，请参阅虚拟机规模集的计划维护文档。

问：使用云服务（Web/辅助角色）和 Service Fabric 时的体验如何？

答: 虽然这些平台会受到计划内维护的影响，但使用这些平台的客户可以安全地进行操作，因为在任何给定的时间，只有单个升级域 (UD) 中的 VM 受影响。 目前，云服务（Web 角色/辅助角色）和 Service Fabric 不支持自助维护。

问：我在 VM 上看不到任何维护信息， 哪里出错了？

答： 有很多原因会导致在 VM 上看不到任何维护信息：

1. 你正在使用标记为“Azure 内部”的订阅。
2. 您的 VM 未安排维护。 可能是这次维护已结束、已取消或已改变计划，因此你的 VM 不再受其影响。
3. 你已解除分配 VM，然后将其启动。 这可能会导致 VM 被迁移到未安排计划内维护波次的位置。 因此，VM 不再显示维护信息。
4. 你的 VM 列表视图中尚未添加维护列。 虽然我们已向默认视图添加此列，但配置为查看非默认列的客户必须手动将“维护”列添加到其 VM 列表视图。

问：我的虚拟机被安排进行第二次维护。 为什么？

答：在以下几种情况下，即使您已经完成维护重新部署，您仍可能会看到您的 VM 被安排进行维护：

1. 我们已取消这轮维护，并以不同的负载重新启动了该轮维护。 可能是我们检测到了发生故障的负载，只需再部署一个额外的负载。
2. 由于硬件故障，您的 VM 已服务性恢复到另一个节点。
3. 您已选择停止（解除分配）并重新启动该虚拟机。
4. 已经为 VM 启用了自动关闭。

问：在计划内维护时段内，是否可以确切地了解 VM 何时重新启动？

一个： Azure 提供常规维护时段，但不会在该时段内共享 VM 重新启动的确切时间。 重新启动可能在该时间的任何时间点发生。 可以利用自我维护时段从你方来控制维护。

后续步骤

还可以使用 Azure CLI、Azure PowerShell 或门户处理计划内维护。