Azure 中虚拟机的维护

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

Azure 定期更新平台，以提高虚拟机的主机基础结构的可靠性、性能及安全性。 此类更新的目的范围涵盖修补托管环境中的软件组件、升级网络组件以及将硬件退役。

更新极少会影响到托管的 VM。 如果更新确实会造成影响，Azure 将选择影响最小的方法进行更新：

  • 如果更新不需要重启，则会在主机更新时暂停 VM，或者将 VM 实时迁移到已更新的主机。
  • 如果维护需要重启，则将收到计划内维护通知。 Azure 还会提供一个时间范围，方便你在适合自己的时间自行启动维护。 除非需要紧急维护，否则自行维护时段通常为 35 天（对于主机）。 Azure 当前正在投资技术，以减少因计划内平台维护而需要重启 VM 的情况。 有关管理计划内维护的说明，请参阅“使用 Azure CLI、PowerShell 或门户处理计划内维护通知”。

本页介绍 Azure 如何执行上述两种类型的维护。 有关非计划内事件（中断）的详细信息，请参阅管理 Windows VM 的可用性或适用于 Linux 的相应文章。

可以通过使用 Windows 或 Linux 的计划事件，在 VM 中获取有关即将进行的维护的通知。

不需要重新启动的维护

大多数平台更新不会影响客户 VM。 如果无法避免更新产生影响，Azure 会选择对客户 VM 影响最小的更新机制。

当需要进行会影响 VM 的维护时，几乎总是通过一次少于 10 秒的 VM 暂停来完成。 在极少数情况下，对于通用型 VM 大小，这种情况每 18 个月最多发生一次；Azure 会采用一种机制，将 VM 暂停大约 30 秒。 执行任何暂停操作后，VM 时钟将在恢复时自动同步。

内存保留维护适用于 90% 以上的 Azure VM。 它不适用于 N 和 H 系列。 Azure 逐渐趋向于使用实时迁移技术并改进内存保留维护机制，目的是缩短暂停时间。

这些无需重启的维护操作将每次针对一个容错域依次应用。 如果他们从平台监控工具收到任何健康警告信号，就会停止。 不需要重新启动的维护操作可能会在配对区域或可用性区域同时进行。 对于某项给定的更改，部署通常会按顺序跨可用区和区域对进行，但在最后阶段可能会有重叠。

这些类型的更新可能会影响某些应用程序。 当 VM 实时迁移到另一台主机时，某些对性能敏感的工作负载在 VM 暂停前的几分钟内可能会出现轻微的性能下降。 若要针对 VM 维护做好准备并降低 Azure 维护期间的影响，可尝试为此类应用程序使用适用于 Windows 或 Linux 的计划事件。

若要更好地控制包括零影响和无需重启的更新在内的所有维护活动，可以创建“维护配置”功能。 如果创建维护配置，可以选择跳过所有平台更新并选择适当的时间来应用更新。 有关详细信息，请参阅通过维护配置管理平台更新。

实时迁移

实时迁移是一个无需重新启动的操作，可为 VM 预留内存。 它会导致暂停或冻结，但持续时间通常不超过 5 秒。 除 N 和 H 系列之外，所有基础结构即服务（IaaS）VM 都有资格进行实时迁移。 大多数 M 系列 SKU 上都提供实时迁移。 符合条件的 VM 代表了可部署到 Azure 机群的 90% 以上的 IaaS VM。

注意

您不会在 Azure 门户中收到关于已尝试但不需要重新启动的实时迁移操作的通知。 若要查看无需重新启动的实时迁移列表，请查询计划事件。

实时迁移是按尽力而为的原则执行的。 在极少数情况下，实时迁移可能不会成功，如果需要，将在发出通知之前为 VM 计划服务修复。 实时迁移不是有保证的操作。

Azure 平台在以下方案中触发实时迁移：

  • 计划内维护
  • 硬件故障
  • 分配优化

某些计划内维护方案使用实时迁移，你可以使用计划事件来提前了解实时迁移操作何时开始。

当 Azure 机器学习算法预测即将发生的硬件故障或 VM 分配优化时，还可以使用实时迁移来移动 VM。 有关用于检测降级硬件实例的预测建模的详细信息，请参阅使用预测性机器学习和实时迁移提高 Azure VM 的复原能力。 实时迁移通知将显示在 Azure 门户上的“监视”和“服务运行状况”日志中以及“计划事件”中（如果使用这些服务）。

实时迁移期间的 TCP 连接复原能力

维护长期 TCP 连接的应用程序（例如数据库服务器、消息代理和缓存层）在实时迁移期间可能会遇到连接中断。 虽然 VM 暂停通常不到 5 秒，但暂停期间和之后的 TCP 堆栈行为可能会延长应用程序级恢复时间（如果未解决）。

实时迁移如何影响 TCP 连接：

  • 在暂停期间，传输中的 TCP 报文段不会得到迁移中的虚拟机的确认。
  • 发送端（客户端或负载均衡器健康探测）开始以指数退避方式进行 TCP 重传。
  • Azure 标准负载均衡器 会向超过所配置空闲超时时间的空闲连接发送 TCP RST。 但是，对于仍有传输中数据的活跃连接，负载均衡器不会在迁移暂停期间发送 TCP RST。 连接保持打开状态，但无响应，客户端没有立即失败信号。
  • 如果没有应用程序级优化，默认 TCP 重新传输行为（tcp_retries2 = 15 在 Linux 上）可能会延迟连接故障检测大约 15 分钟。

Important

影响因操作系统默认值而异。 在 Linux 上，tcp_retries2 的默认值为 15，因此大约在 15 分钟后才会检测到断开的连接。 在Windows，TcpMaxDataRetransmissions默认值为 5，这会在不进行任何优化的情况下将检测时间限制为大约 25-50 秒。 本文中所述的缓解措施对于基于 Linux 的工作负荷最为重要。

注意

对于 HTTP/1.1 负载，其影响通常有限：只有在迁移发生时正在传输中的请求会受到影响，而且由于 HTTP/1.1 客户端不会在持久连接上进行管线化，因此只需为下一个请求重新建立连接，便能快速恢复。 对于 HTTP/2，爆炸半径更宽，因为多个并发流共享单个 TCP 连接。

当负载均衡器以 L4 TLS 直通模式运行时，它无法检查、重试或将错误响应注入加密流。 在此配置中，客户端仅负责检测和恢复已停止的连接。

使用多实例部署减少爆炸半径：

在应用 TCP 级别缓解之前，请考虑体系结构基线。 实时迁移在可用性集或虚拟机规模集中每次仅影响一台虚拟机。 跨多个后端实例分布连接会限制任何单个迁移事件的影响：

  • 具有三个实例的规模集，这意味着每次迁移事件最多只会影响三分之一的活跃连接。
  • 跨可用区部署可确保不同可用区中的迁移不会相互重叠。
  • 跨多个后端分布的连接池的客户端会更快地恢复，因为不受影响的连接会立即继续处理请求。

在 VM 暂停期间，Azure 标准负载均衡器针对已暂停后端的运行状况探测也会失败。 负载均衡器在大约 10 秒内将后端标记为不正常（默认 5 秒间隔连续两次探测失败），并停止路由到该后端的新连接。 此条件意味着新连接自然受到保护。 本文中所述的 TCP 缓解措施解决了在迁移开始之前已建立的现有连接。

建议的缓解措施：

以下缓解措施是互补的。 当它们结合实施时，可将实时迁移带来的影响从原本可能导致数分钟停机，降低到仅需几秒钟即可自动恢复。

Priority 缓解措施 努力 影响
1 在套接字级别设置 TCP_USER_TIMEOUT Low 将死连接检测从大约 15 分钟减少到 30 秒
2 订阅预定事件 Medium 在冻结发生之前启用主动连接清空
3 调整 TCP 保活参数 Low 检测迁移后失效的空闲连接
4 实现客户端重试逻辑 Medium 无论根本原因如何，都提供复原能力

缓解措施 1：TCP_USER_TIMEOUT（最快的检测方式）

TCP_USER_TIMEOUT 控制内核在声明连接已死亡之前等待确认传输的数据的时间。 将每个套接字设置为 30 秒（30000 毫秒），可显著缩短检测时间。

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

或者，减少整个系统的重传次数：

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Tip

将 TCP_USER_TIMEOUT 设置在 SDK 或套接字级别，而不是在整个系统范围内。 值为 30 秒是一个很好的起点。 低于 10 秒的值可能会在正常的网络抖动情况下导致误报。

Windows注意事项：

TCP_USER_TIMEOUT 套接字选项是 Linux 特有的。 在Windows，TCP 重新传输行为以不同的方式控制：

  • Windows默认为 5 次重新传输（TcpMaxDataRetransmissions这已经提供大约 25-50 秒的检测时间，无需进行任何优化）。
  • 若要进一步缩短Windows的检测时间，请调整注册表：
# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

如果 TcpMaxDataRetransmissions 设置为 3，检测时间将减少到大约 10-20 秒，具体取决于初始重新传输超时。

注意

与 Linux 不同，Windows 不提供对应于每个套接字的 TCP_USER_TIMEOUT 等效项。 注册表设置适用于系统上的所有 TCP 连接。 若要在 Windows 上实现细粒度控制，应依靠应用程序级超时和健康检查（缓解措施 4）。

缓解 2：计划事件（主动排出）

计划事件服务在实时迁移开始之前提供提前通知。 应用程序可以在暂停发生之前侦听 Freeze 事件并主动清空连接。

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

实时迁移事件如下所示：

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

检测到 Freeze 事件时：

  1. 停止接受受影响节点上的新连接。
  2. 清空现有连接（指示客户端重新连接到其他节点）。
  3. 等待正在进行中的操作在限定的超时时间内完成。
  4. （可选）通过回发 EventId 来确认事件。

注意

提前通知期通常为 15 分钟，但在极少数情况下可以短到 30 秒。 建议对生产工作负荷使用每秒一次的轮询频率。

缓解措施 3：TCP keepalive 调优

TCP keepalive 探测可检测到在迁移事件后变为空闲状态的连接：

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

使用这些设置，可在 60 秒内检测到空闲的陈旧连接（30 + 10 x 3）。 保活探测也会被视为标准负载均衡器空闲超时的活动，从而防止负载均衡器自行使空闲连接超时。

缓解措施 4：客户端重试逻辑

无论故障检测方法如何，应用程序级重新连接和重试逻辑都可确保恢复：

  1. 检测连接错误（超时、RST 或连接被拒绝）。
  2. 关闭死连接，将其从连接池中删除。
  3. 打开与相同或不同节点的新连接。
  4. 使用指数退避重试操作。

对于数据库 SDK 和连接池，启用定期运行状况检查（例如，每 10-15 秒轻量 ping 一次），以主动验证连接。

连接池配置：

对于维护长期连接的连接池，设置最大生命周期会带来好处。 此设置会强制定期重建连接，以确保任何单个连接都不会因未来的迁移事件而累积无上限的风险：

池技术 设置 推荐值
HikariCP （Java） maxLifetime 1800000 （30 分钟）
PgBouncer server_lifetime 1800 （30 分钟）
去 database/sql SetConnMaxLifetime 30 * 时间。分钟
Node.js （pg 池） idleTimeoutMillis 30000 （30 秒空闲逐出;最大生存期需要自定义逻辑）
.NET SqlConnection 连接字符串：Connection Lifetime 1800 （30 分钟）

将最大生存期设置为 30 分钟，意味着即使没有主动健康检查，连接也会在累积长时间未被发现的陈旧状态之前自然被替换。

监视和可观测性：

若要检测和测量实时迁移事件对 TCP 连接的影响，请使用以下方法：

  • Azure Monitor VM 可用性指标（预览）：在 VM 暂停期间下降到 0。 创建阈值小于 1 的警报规则 VmAvailabilityMetric 来检测迁移事件。
  • 计划事件活动日志： 实时迁移事件会显示在活动日志中，提供程序为 Microsoft.Compute，操作名称为 Microsoft.Compute/virtualMachines/liveMigration/action；或者在通过元数据服务查询时，显示为 Freeze 事件。
  • 应用程序级连接错误率： 监视应用程序指标中的 TCP 连接重置、超时和重新连接计数。 与 VM 可用性下降相关的连接错误的峰值证实了迁移影响。
  • TCP 重传计数器： 在 Linux 上，监视 /proc/net/netstat 字段 TCPTimeouts，或使用 ss -ti 来观察各个套接字的重传次数。 在已知维护窗口期间，重传次数增加表明连接受到了影响。
# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

在正常操作期间为这些指标建立基线，可以直接量化迁移事件的影响，并验证缓解措施是否按预期工作。

无法容忍在线迁移中断的工作负载

对于无法容忍实时迁移中断的工作负荷，请考虑使用具有维护配置的专用主机Azure。 专用主机可让你控制主机级维护何时发生，从而消除意外的实时迁移事件。

需要重新启动的维护

在极少数情况下，VM 需重新启动以进行计划内维护，这种情况下系统会提前通知。 计划内维护有两个阶段：自助服务阶段和计划内维护阶段。

自助服务阶段通常持续四周，你将在 VM 上启动维护。 在自助服务期间，可以查询每个 VM 来了解其状态，以及上次维护请求的结果。

注意

对于不支持实时迁移的 VM 系列，本地（临时）磁盘数据可能会在维护事件期间丢失。 有关是否支持实时迁移的信息，请查看每个单独的 VM 系列。

启动自助维护时，VM 会重新部署到已更新的某个节点。 由于重新部署了 VM，临时磁盘会丢失，并且与虚拟网络接口关联的公共动态 IP 地址会更新。

如果在自助维护期间出错，操作将会停止，VM 不会更新，而你可以使用相应的选项来重试自助维护。

自助维护阶段结束时，计划内维护阶段随即开始。 在此阶段，仍可以查询维护阶段，但不能自行启动维护。

有关管理需要重新启动的维护的详细信息，请参阅“使用 Azure CLI、PowerShell 或门户处理计划内维护通知”。

计划内维护期间的可用性注意事项

如果你决定等到计划内维护阶段开始，为了保持 VM 的最高可用性，应考虑到一些要素。

配对区域

每个 Azure 区域将与同一邻近地理范围内的另一区域配对。 它们共同构成一个区域对。 在计划内维护阶段，Azure 只会更新一个区域对中单个区域内的 VM。 例如，在更新中国北部 2 中的 VM 时，Azure不会同时更新中国东部 2 中的任何 VM。 了解区域对的工作原理有助于更好地跨区域分配 VM。 有关详细信息，请参阅 Azure 区域对。

可用性区域

可用性区域是 Azure 区域中独特的物理位置。 每个区域由一个或多个数据中心组成，这些数据中心配置了独立电源、冷却和网络。 为确保能够进行复原，所有已启用的地区中都必须至少有三个单独的区域。

可用性区域是容错域和更新域的组合。 如果在 Azure 区域的三个区域中创建三个或更多 VM，则 VM 将有效分布在三个容错域和三个更新域中。 Azure 平台会识别更新域上的此分布，以确保不同区域中的 VM 不会同时更新。

每个基础结构更新在单个地区中按区域依次推出。 但是，您可以让区域 1 中正在进行一种部署，同时在区域 2 中进行另一种不同的部署。 并非所有部署都会按顺序执行。 但对于需要重启的单次部署，为了降低风险，每次只会在一个区域逐步部署。 通常情况下，会尽量避免需要重启的更新，而 Azure 会尝试采用实时迁移，或让客户拥有控制权。

虚拟机规模集

处于灵活业务流程模式的虚拟机规模集是 Azure 计算资源，使你可将处于统一业务流程模式的虚拟机规模集的可伸缩性与可用性集的区域可用性保证相结合。

使用灵活编排时，你可以选择让实例分布在多个可用区中，或者分布在单个区域内的多个故障域中。

可用性集和统一规模集

在 Azure VM 上部署工作负荷时，可以在可用性集中创建 VM，向应用程序提供高可用性。 使用可用性集，可以确保在需要重启的中断或维护事件期间，至少有一个 VM 可用。

在可用性集中，个别 VM 可分布在最多 20 个更新域中。 在计划内维护期间，同一时间只会更新一个更新域。 更新域不一定要按顺序更新。

处于统一业务流程模式的虚拟机规模集是一种 Azure 计算资源，支持将一组相同的 VM 作为单个资源进行部署和管理。 规模集自动跨 UD 进行部署，此类更新域就像可用性集中的 VM 一样。 与可用性集一样，使用统一虚拟机规模集时，在计划内维护期间的任一时刻，只会更新一个更新域 (UD)。

有关设置 VM 以实现高可用性的详细信息，请参阅管理 Windows VM 的可用性或适用于 Linux 的相应文章。

后续步骤

若要管理计划内维护，请使用Azure CLI、Azure PowerShell或门户。

  • Last updated on