了解 Azure VM 的系统重启

项目
03/27/2024

) (VM 的 Azure 虚拟机有时可能无明显原因重新启动，但无法证明你已启动重新启动操作。本文列出了可能导致 VM 重新启动的操作和事件，并提供有关如何避免意外重启问题或减少此类问题影响的信息。

配置 VM 以实现高可用性

保护 Azure 上运行的应用程序免受 VM 重启和停机影响的最佳方法是配置 VM 以实现高可用性。

若要为应用程序提供此级别的冗余，建议将两个或更多 VM 分组到一个可用性集中。此配置可确保在计划内或计划外维护事件期间，至少有一个 VM 可用，并且符合 99.95% 的 Azure SLA。

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

资源运行状况信息

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

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

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

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

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

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

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

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

计划的维护

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

但是，某些更新确实需要重新启动。在这种情况下，我们会在修补基础结构时关闭 VM，然后重启 VM。

若要了解什么是 Azure 计划内维护，以及它如何影响 Linux VM 的可用性，请参阅此处列出的文章。这些文章提供了有关 Azure 计划内维护过程的背景，以及如何计划计划内维护以进一步降低影响。

内存保留更新

对于 Microsoft Azure 中的此类更新，用户对其正在运行的 VM 没有任何影响。其中许多更新适用于组件或服务，可以在不干扰正在运行的实例的情况下进行更新。有些是主机操作系统上的平台基础结构更新，无需重启 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 地址。

适用于云和Windows 更新的Microsoft Defender

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

与本地服务器一样，Azure 不会将更新从Windows 更新推送到 Windows VM，因为这些计算机由其用户管理。但是，建议将自动Windows 更新设置保持启用状态。从Windows 更新自动安装更新也可能导致在应用更新后重新启动。有关详细信息，请参阅Windows 更新常见问题解答。

影响 VM 可用性的其他情况

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

主机服务器故障

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

服务器故障通常是由硬件故障引起的，例如硬盘或固态硬盘故障。 Azure 持续监视这些事件，识别基础 bug，并在实施和测试缓解措施后推出更新。

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

自动恢复

如果主机服务器出于任何原因无法重新启动，Azure 平台会启动自动恢复操作，使发生故障的主机服务器退出轮换，以便进一步调查。

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

计划外维护

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

计划外维护包括：

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

VM 崩溃

VM 可能会因为 VM 本身中的问题而重启。 VM 上运行的工作负荷或角色可能会在来宾操作系统中触发 bug 检查。有关确定崩溃原因的帮助，请查看 Windows VM 的系统和应用程序日志，以及 Linux VM 的串行日志。

Azure 中的 VM 依赖于托管在 Azure 存储基础结构上的操作系统和数据存储的虚拟磁盘。每当 VM 与关联的虚拟磁盘之间的可用性或连接受到影响超过 120 秒时，Azure 平台都会强制关闭 VM 以避免数据损坏。还原存储连接后，VM 会自动重新开机。关闭持续时间可以短到五分钟，但可以明显更长。

其他事件

在极少数情况下，普遍存在的问题可能会影响 Azure 数据中心中的多台服务器。如果发生此问题，Azure 团队会将电子邮件通知发送到受影响的订阅。可以检查 Azure 服务运行状况仪表板以及持续中断和过去事件的状态Azure 门户。

诊断 VM 重启

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

联系我们寻求帮助

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