通过

了解 Azure VM 的系统重启

  • 项目

适用于：✔️ Linux VM ✔️ Windows VM

Azure 虚拟机 (VM) 有时可能会在没有明显原因（没有证据表明你已启动重启操作）的情况下重启。 本文列出了可导致 VM 重启的操作和事件，并针对如何避免意外重启问题或减少此类问题影响提供见解。

配置 VM 以实现高可用性

若要防止 Azure 上运行的应用程序出现 VM 重启和停机问题，最佳方式是配置 VM 以实现高可用性。

若要为应用程序提供此级别的冗余，建议两个或更多 VM 组合到一个可用性集中。 这种配置可确保发生计划内或计划外维护事件时，至少有一个 VM 可用，并满足 99.95% 的 Azure SLA 要求。

有关可用性集的详细信息，请参阅 管理 VM 的可用性

资源运行状况信息

Azure 资源运行状况是一项服务，用于公开各个 Azure 资源的运行状况，并为排查问题提供可行的指南。 在无法直接访问服务器或基础结构元素的云环境中，资源运行状况的目标是减少在故障排除上花费的时间。 具体说来，目的是减少确定问题根源在于应用程序还是在于 Azure 平台内事件所花的时间。 有关详细信息，请参阅了解和使用资源运行状况。

如果 Azure 提供了有关平台启动的虚拟机不可用的根本原因的详细信息，该信息可能会在初始不可用后最多 72 小时发布在资源运行状况中。

活动日志中缺少 VM 停机时间

资源运行状况警报基于活动日志信息发送。 在某些情况下，VM 停机时间可能不会显示在活动日志中。 如果活动日志中未显示停机时间，则不会在停机期间发送警报资源运行状况。 停机时间在资源运行状况中仍可见。

下面是活动日志中未显示 VM 停机时间的情况：

  • 创建或迁移到新主机时，Azure 平台不会正确显示 VM 状态，并且状态更改为“未知”。 只有在建立所有网络连接和节点进程后，VM 状态才会更改为“可用”。 “未知”状态的长时间被筛选出活动日志。
  • 当 VM 可用性状态从“可用”更改为“不可用”，然后在 35 秒内返回“可用”时，活动日志中不会显示停机时间。 如果在发生第一次转换前 15 分钟内发送相关停机时间，则不会发生此情况。
  • 如果 VM 运行状况从状态更改为“未知”，然后返回到原始状态，则会从活动日志中筛选出间歇性未知状态和相关转换。

活动日志中未显示的 VM 停机时间在 Azure 平台端进行筛选，以防止暂时性错误向客户显示不正确的停机时间。 随着 VM 运行状况质量的持续投资，筛选器可能不再需要，并可能导致 VM 运行状况的快速更改保持未报告。 Microsoft正在制定逐步淘汰计划，以提供最佳的客户体验。

可能导致 VM 重启的操作和事件

计划内维护

Microsoft Azure 在全球范围内定期执行更新，提高 VM 所基于主机基础结构的可靠性、性能及安全性。 许多更新（包括内存保留更新）在执行时不会对 VM 或云服务产生任何影响。

但是，有些更新确实需要重启。 在这种情况下，VM 会在修补基础结构期间关闭，随后再重启。

若要了解什么是 Azure 计划内维护，及其如何影响 Linux VM 的可用性，请参阅下面列出的文章。 这些文章介绍了 Azure 计划内维护过程的背景，以及如何安排计划内维护以进一步减少影响。

内存保留更新

对于 Microsoft Azure 中的这类更新，用户体验不到其对运行中的 VM 的任何影响。 其中一些更新主要面向组件或服务，更新时不会干扰正在运行的实例。 还有一些是主机操作系统上的平台基础结构更新，应用时无需重启 VM。

这些内存保留更新通过启用就地实时迁移技术实现。 进行更新时，VM 处于“暂停”状态。 该状态可保留 RAM 中的内存，基础主机操作系统则接收必要的更新和补丁。 VM 通常在暂停后的 30 秒内恢复。 VM 恢复后，其时钟将自动同步。

由于暂停时间短，因此通过这种机制部署更新可以大大减少对 VM 的影响。 但是，并非所有更新都可通过这种方式部署。

多实例更新（针对可用性集中的 VM）一次应用一个更新域。

注意

具有旧内核版本的 Linux 计算机在此更新方法期间受内核错误影响。 若要避免此问题，请更新到内核版本 3.10.0-327.10.1 或更高版本。 有关详细信息，请参阅主机节点升级后基于 3.10 内核的 Azure Linux VM 出现错误。

用户发起的重启或关机操作

如果从 Azure 门户、Azure PowerShell、命令行接口或 REST API 执行重新启动，可以在 Azure 活动日志中找到该事件。

如果在 VM 的操作系统中执行该操作，则可在系统日志中找到该事件。

通常导致 VM 重启的其他方案包括多个配置更改操作。 通常会看到一条指示执行特定操作将导致 VM 重启的警告消息。 示例包括任意 VM 大小调整操作、更改管理帐户密码和设置静态 IP 地址。

Microsoft Defender for Cloud 和 Windows 更新

Microsoft Defender for Cloud 每天监视 Windows 和 Linux VM，以获取缺少操作系统更新。 Defender for Cloud 根据 Windows VM 上配置的服务，从 Windows 更新 或 Windows Server Update Services （WSUS）检索可用安全和关键更新的列表。 Defender for Cloud 还会检查 Linux 系统的最新更新。 如果 VM 缺少系统更新，Defender for Cloud 建议应用系统更新。 这些系统更新的应用程序通过 Azure 门户 中的 Defender for Cloud 进行控制。 应用某些更新后，可能需要重启 VM。 有关详细信息，请参阅 Microsoft Defender for Cloud 中的应用系统更新。

与本地服务器一样，Azure 不会向 Windows VM 推送 Windows 更新提供的更新，因为这些虚拟机应由用户进行管理。 但是，我们依然建议启用 Windows 自动更新设置。 自动安装 Windows 更新提供的更新也会导致应用更新后发生重启。 有关详细信息，请参阅 Windows 更新常见问题解答。

影响 VM 可用性的其他情况

在其他情况下，Azure 可能主动暂停使用 VM。 你会在执行此操作前收到电子邮件通知，因此有机会解决该基础问题。 举例来说，影响 VM 可用性的问题包括：违反安全规范、付款方式过期。

主机服务器错误

在 Azure 数据中心内运行的物理服务器上托管 VM。 除了其他几个 Azure 组件外，物理服务器也运行名为“主机代理”的代理。 如果物理服务器上的这些 Azure 软件组件无响应，则监视系统会触发主机服务器重启，尝试恢复。 在许多情况下，VM 将在 10-15 分钟内再次可用，并继续与之前相同的主机上运行。

服务器错误通常由硬盘或固态硬盘等硬件故障引起。 Azure 持续监视这些事件，确定基础 bug，并在实现和测试缓解举措后推出更新。

由于某些主机服务器错误可能特定于该服务器，因此可通过手动将 VM 重新部署到其他主机服务器来改善 VM 重复重启的情况。 在 VM 详细信息页上使用“重新部署”选项，或在 Azure 门户中停止并重启 VM，可触发此操作。

自动恢复

如果出于某种原因，主机服务器不能重启，Azure 平台会启动自动恢复操作，使发生故障的主机服务器脱离轮换，以便展开进一步调查。

该主机上的所有 VM 均自动重新定位到其他运行正常的主机服务器。 尽管此过程通常在 15 分钟内完成，但恢复所需的时间可能因多种因素而异，包括主机内存的大小和采用的恢复方法。 若要详细了解自动恢复过程，请参阅 VM 自动恢复。

非计划维护

在少数情况下，Azure 运营团队可能需要执行维护活动，确保 Azure 平台总体上正常运行。 此行为可能会影响 VM 可用性，并且通常会导致相同的自动恢复操作，如前所述。

计划外维护包括：

  • 紧急节点碎片整理
  • 紧急网络交换机更新

VM 故障

VM 可能因自身问题重启。 在 VM 上运行的工作负荷或角色可能触发来宾操作系统内的 Bug 检查。 为帮助确定故障原因，请查看系统和应用程序日志（适用于 Windows VM）和串行日志（适用于 Linux VM）。

对于在 Azure 存储基础结构上托管的操作系统和数据存储，Azure 中的 VM 依赖于虚拟磁盘。 只要可用性或者 VM 和关联的虚拟磁盘之间的连接受影响的时间超过 120 秒，Azure 平台就会强制关闭 VM，以免数据损坏。 存储连接还原后，VM 自动重启。 关机持续时间可短至 5 分钟，也可能非常久。

其他事件

在极少数情况下，普遍的问题可能影响 Azure 数据中心内的多台服务器。 如果出现这种问题，Azure 团队会向受影响订阅者发送电子邮件通知。 可查看 Azure 服务运行状况仪表板和 Azure 门户，了解正在进行的服务中断和过去事件的状态。

诊断 VM 重启

可以使用 VM 边栏选项卡上的“诊断和解决”边栏选项卡运行其他诊断。 这可能会发现最近 VM 重启的更具体原因。 如果存在任何来宾 OS 问题，请收集内存转储并联系支持人员。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。