通过

处理计划内维护通知

  • 项目

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

Azure 定期执行更新，以提高虚拟机的主机基础结构的可靠性、性能及安全性。 更新包括如下更改：修补托管环境或升级以及解除硬件授权。 大多数此类更新在完成时不会影响托管的虚拟机。 但是，也会存在更新产生影响的情况：

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

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

需要重启的计划内维护是按批进行计划的。 每个批具有不同的作用域（区域）。

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

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

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

你是否应在自助时段启动维护？

可以先阅读以下指南，然后再决定是否使用此功能按自己的时间来启动维护。

注意

自助维护不一定适用于所有 VM。 若要确定是否可以对 VM 进行主动重新部署，请在维护状态中查找“立即启动”。 自助维护目前不适用于云服务（Web/辅助角色）和 Service Fabric。

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

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

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

  • 如果频繁关闭 VM，不管是使用手动方式、使用开发测试实验室、使用自动关闭还是按计划来完成，都可能会还原维护状态，从而导致停机时间延长。
  • VM 的生存期短，已确定在维护结束之前就会被删除。
  • 工作负荷的状态为“大”，存储在本地（临时）磁盘中，需要在更新后进行维护。
  • 经常需要重设 VM 大小的情况，可能还原维护状态。
  • 在采用的计划事件允许对工作负荷进行主动故障转移或正常关闭的情况下，在启动维护性关闭之前的 15 分钟

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

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

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

常见问题

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

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

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

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

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

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

答: 一次计划内维护是通过将计划设置到一个或多个 Azure 区域启动的。 Azure 门户中的服务运行状况下提供了与虚拟机相关的维护通知。 对于某些特定的虚拟机计划内维护场景，Azure 还可能会向订阅经典管理员、共同管理员和订阅所有者组发送其他电子邮件来传达计划（在添加了所有收件人的情况下，对于每个订阅发送一封电子邮件）。

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

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

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

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

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

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

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

答: 根据 VM 的大小，在自助维护时段内，重启最多可能需要几分钟时间。 当 Azure 在计划性维护时段内启动重启时，重启通常需要 25 分钟左右。 请注意，如果使用云服务（Web/辅助角色）、虚拟机规模集或可用性集，则在计划性维护时段内每组 VM (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 已计划进行第二次维护， 为什么？

答: 多种用例都会看到在完成维护性重新部署后，VM 仍进行计划性维护：

  1. 我们已取消这次维护，并使用不同的有效负载重新启动它。 可能是我们已检测到出错的有效负载，只需部署其他有效负载。
  2. 由于硬件故障，已在另一个节点上对 VM 进行服务修复。
  3. 选择了停止（解除分配）VM 并将其重启。
  4. 已经为 VM 启用了自动关闭。

后续步骤

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