Azure 中虛擬機器進行的維修

適用於：✔️ Linux 虛擬機器 ✔️ Windows 虛擬機器 ✔️ 彈性調整集 ✔️ 統一調整集

為提升虛擬機器之主機基礎結構的可靠性、效能和安全性，Azure 會定期更新其平台。 這些更新的目的涵蓋修補主控環境中的軟體元件，以至升級網路元件或將硬體解除委任。

更新很少會影響託管的 VM。 當更新確實會影響時，Azure 會選擇影響最小的更新方法：

  • 若更新不需重新啟動，VM 在主機更新期間暫停，或 VM 會即時遷移至已更新的主機。
  • 若維護需重新啟動，會通知計畫性維護。 Azure 也提供一個時間範圍，可讓您在適合自己的時間自行開始維護。 除非維護很緊急，否則自行維護的時間範圍通常為 35 天 (針對主機電腦)。 Azure 正在投資技術，以減少計劃性平台維護需要 VM 重新開機的情況。 有關管理計畫性維護的指示，請參考使用 Azure CLI、PowerShell 或入口網站處理計畫性維護通知。

本文說明 Azure 如何執行兩種類型的維護。 有關非計畫事件 (中斷) 的更多資訊，請參見管理 Windows VM 可用性或對應的 Linux 文章。

在 VM 內，您可透過 Windows Scheduled Events 或 Linux Scheduled Events 獲取即將維護的通知。

不需重新啟動的維護

大多數平台更新不會影響客戶 VM。 當無影響更新不可行時，Azure 會選擇對客戶 VM 影響最小的更新機制。

當需要對 VM 產生影響的維護時，幾乎總是透過暫停 VM 少於 10 秒完成。 在罕見情況下，一般用途 VM 尺寸每 18 個月最多一次，Azure 會使用暫停 VM 約 30 秒的機制。 任何暫停操作後，VM 時鐘在恢復時會自動同步。

保留記憶體的維護適用於超過 90% 的 Azure VM。 它不適用於 G、L、N 和 H 系列。 如需詳細資訊，請參閱 哪些 VM 大小支援記憶體保留維護。 Azure 逐漸使用即時遷移技術，並改進保留記憶體的維護機制，以縮短暫停時間。

這些不需重新啟動的維護操作會一次應用於一個故障域。 若平台監控工具發出任何健康警告，這些操作會停止。 不需重新啟動的維護操作可能同時在配對區域或可用性區域發生。 對於特定變更，部署大多按可用性區域及區域配對依序進行，但尾端可能有重疊。

這類更新可能會影響某些應用程式。 當 VM 即時遷移到不同主機時，一些敏感工作負載可能在 VM 暫停前幾分鐘出現輕微效能下降。 為了準備 VM 維護並減少 Azure 維護期間的影響，請嘗試使用 Windows Scheduled Events 或 Linux Scheduled Events 進行此類應用程式的管理。

為對所有維護活動 (包括零影響及無需重新啟動的更新) 進行更大控制，您可以建立維護設定功能。 建立維護設定可讓您選擇跳過所有平台更新，並在自己選擇的時間套用更新。 更多資訊請參閱使用維護設定管理平台更新。

即時移轉

即時移轉作業不需要重新開機，而且會保留 VM 的記憶體。 這會造成暫停或凍結，通常不超過 5 秒。 除 G、L、N 和 H 系列外，所有基礎結構即服務 (IaaS) VM 均可進行即時遷移。 大部分的 M 系列 SKU 都可以使用即時移轉。 符合條件的 VM 佔 Azure 車隊部署的 IaaS VM 超過 90%。

附註

您不會在 Azure 入口網站中收到已嘗試或不需要重新啟動的即時移轉作業通知。 要查看不需重新啟動的即時遷移清單，請查詢已排定事件。

即時遷移以盡力而為的方式執行。 在某些罕見情況下，即時遷移可能失敗，若需要，VM 將在通知前排程進行服務修復。 即時移轉不是保證的作業。

Azure 平臺會在下列案例中觸發即時移轉：

  • 預定的維修
  • 硬體故障
  • 配置最佳化

某些計畫性維護情境使用即時遷移，您可使用 Scheduled Events 提前得知即時遷移操作開始時間。

當 Azure 機器學習演算法預測即將到來的硬體故障或虛擬機配置優化時，也能使用即時遷移來移動虛擬機。 有關更多偵測硬體降級執行個體的預測模型資訊，請參閱使用預測機器學習與即時遷移改善 Azure VM 韌性。 即時遷移通知會出現在 Azure 入口網站的「監視器」和「服務健康狀態」記錄檔中，如果您使用這些服務，也會出現在 Scheduled Events 中。

即時遷移期間的 TCP 連線韌性

維持長期 TCP 連線的應用程式，如資料庫伺服器、訊息代理及快取層，在即時遷移期間可能會遇到連線中斷。 雖然虛擬機暫停通常不到 5 秒，但若未處理，暫停期間及之後的 TCP 堆疊行為可能會延長應用程式層級的復原時間。

即時遷移如何影響 TCP 連線：

  • 暫停期間，正在遷移的虛擬機不會確認在執行中的 TCP 區段。
  • 傳送端 (用戶端或負載平衡器健全狀態探查) 開始以指數輪詢方式進行 TCP 重傳。
  • Azure Standard Load Balancer 會對超過所設定閒置逾時值的閒置連線傳送 TCP RST。 然而，對於仍有傳輸中資料的作用中連線，負載平衡器在移轉暫停期間不會發送 TCP RST 封包。 連線保持開啟但無反應，客戶端也沒有立即出現故障的訊號。
  • 若不進行應用程式層級調校，Linux 預設的 TCP 重傳行為tcp_retries2 = 15 可能會延遲連線失敗偵測約 15 分鐘。

Important

影響會因作業系統預設而有很大差異。 在 Linux 上，tcp_retries2 的預設值為 15，因此大約會在 15 分鐘後偵測到失效的連線。 在 Windows 上，TcpMaxDataRetransmissions預設為 5，這限制偵測時間約 25-50 秒，且不需調整。 本文所述的緩解措施對於基於 Linux 的工作負載來說最為關鍵。

附註

對於 HTTP/1.1 工作負載，影響通常有限：只有遷移時仍在執行中的請求會受影響，且由於 HTTP/1.1 用戶端不會透過 keep-alive 連線進行流水線，因此會透過開啟新連線來快速恢復下一個請求。 對於 HTTP/2，爆炸範圍較寬，因為多個並行串流共用單一 TCP 連線。

當負載平衡器以 L4 TLS 直通模式運作時，無法檢查、重試或向加密串流注入錯誤回應。 在此配置下，用戶端需獨自負責偵測並恢復中斷連線。

透過多實例部署減少爆炸半徑：

在應用 TCP 層級的緩解措施前，請先考慮架構基線。 即時移轉一次會影響可用性設定組或虛擬機器擴展集內的一台 VM。 將連線分散到多個後端實例，可以限制任何單一遷移事件的影響：

  • 包含三個執行個體的級別意指每個移轉事件最多影響三分之一的活躍連線。
  • 跨可用區域部署可確保不同可用區域的遷移不會重疊。
  • 分布於多個後端的連線池用戶端恢復速度更快，因為未受影響的連線會立即持續提供請求。

在虛擬機器暫停期間，Azure Standard Load Balancer 對已暫停的後端執行個體所做的健康情況探查也會失敗。 負載平衡器會在約 10 秒內（預設 5 秒間隔連續兩次探針失敗）標記後端為不健康，並停止將新連線路由至該後端。 這種狀況意味著新連接會自然受到保護。 本文所述的 TCP 緩解措施是針對遷移開始前已建立的現有連線進行處理。

建議的緩解措施：

以下的緩解措施是互補的。 當兩者同時實施時，能將即時遷移事件的影響從幾分鐘的停機縮短為幾秒鐘的自動恢復。

Priority 緩和措施 努力 影響
1 在通訊端層級設定 TCP_USER_TIMEOUT 低 將失效連線偵測時間從 ~15 分鐘縮短至 30 秒
2 訂閱預定活動 中等 能在凍結發生前主動耗盡連線
3 調整 TCP keep-alive 參數 低 偵測在遷移後會失效的閒置連線
4 實作客戶端重試邏輯 中等 無論根源為何，都能提供韌性

緩解措施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 或 socket 層級，而非系統範圍。 30秒是個不錯的起點。 低於 10 秒的數值在正常網路抖動時可能會產生誤報。

Windows 相關考量：

這個 TCP_USER_TIMEOUT socket選項是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 並未提供以每個 socket 為單位、相當於 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）內被偵測到。 Keepalive 探測也會被視為 Standard Load Balancer 閒置逾時的活動，避免負載平衡器獨立使閒置連線逾時。

緩解措施 4：用戶端重試邏輯

應用程式層級的重連與重試邏輯可確保無論故障偵測方式為何，都能恢復：

  1. 偵測連線錯誤（逾時、RST 或連線拒絕）。
  2. 關閉失效的連線，並將其從連線池中移除。
  3. 開啟一條新的連線到相同或不同的節點。
  4. 用指數退縮重試操作。

對於資料庫 SDK 和連線池，啟用定期健康檢查（例如每 10-15 秒輕量級 ping 一次），以主動驗證連線。

連線池配置：

維持長時間連線的連線池可受益於最大存留時間設定。 此環境強制定期連線回收，確保不會有單一連線累積未來遷移事件的無限風險：

泳池技術 Setting 建議值
HikariCP（Java） maxLifetime 1800000（30分鐘）
PgBouncer server_lifetime 1800（30分鐘）
前往 database/sql SetConnMaxLifetime 30 * time.Minute
Node.js (pg Pool) idleTimeoutMillis 30000（閒置 30 秒後清除；最大生命週期需自訂邏輯）
.NET SqlConnection 連接字串：Connection Lifetime 1800（30分鐘）

將最大存留時間設為 30 分鐘，表示即使沒有執行主動健康狀態檢查，連線會在累積過久而未被察覺的過期狀態之前，自然進行汰換。

監控與可觀察性：

要偵測並衡量即時遷移事件對 TCP 連線的影響，請採用以下方法：

  • Azure 監視器 VM Availability Metric （Preview）：VM 暫停期間降至 0。 建立一個警示規則 VmAvailabilityMetric ，閾值低於 1 以偵測遷移事件。
  • 預定活動活動記錄：即時遷移事件會以操作名稱Microsoft.Compute出現在服務提供者的活動日誌Microsoft.Compute/virtualMachines/liveMigration/action中，或透過中繼資料服務查詢時以事件形式Freeze出現。
  • 應用層級連線錯誤率： 監控 TCP 連線重設、逾時及重新連線次數，反映在應用程式指標中。 連線錯誤激增與虛擬機可用性下降相關，證實了遷移的影響。
  • 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，您會提前收到通知。 計畫性維護包含兩個階段：自助服務階段與排程維護階段。

在自助服務階段 (通常持續四週)，您會開始對虛擬機器進行維護。 作為自助服務的一部分，您可以查詢每個虛擬機器的狀態以及您上一次維護請求的結果。

附註

對於不支援即時移轉的虛擬機器系列，維護期間本機 (暫時性) 磁碟資料可能會丟失。 請參閱每個虛擬機器系列，以了解是否支援即時移轉。

當您開始自助服務維護時，您的虛擬機器將重新部署到已更新的節點。 由於虛擬機器會重新部署，暫存磁碟將會遺失，且與虛擬網路介面相關聯的公用動態 IP 位址會更新。

如果在自助服務維護期間發生錯誤，操作將停止，虛擬機器不會更新，您將可以選擇重新執行自助服務維護。

當自助服務階段結束時，就會進入排程維護階段。 在此階段，您仍然可以查詢維護階段，但無法自行啟動維護。

有關管理需要重新啟動的維護的更多資訊，請參閱使用 Azure CLI、PowerShell 或入口網站處理計畫維護通知。

排程維護期間的可用性考量

如果您決定等到排程維護階段，應考慮一些事項以維持虛擬機器的最高可用性。

配對的區域

每個 Azure 區域都與同一地理區域內的另一個區域配對。 它們一起構成區域配對。 在排程的維護階段期間，Azure 只會更新區域配對中單一區域的 VM。 例如，在更新美國中北部的虛擬機器時，Azure 不會同時更新美國中南部的任何虛擬機器。 然而，其他區域如北歐可能會與美國東部同時進行維護。 了解區域配對的運作方式可以幫助您更好地將虛擬機器分布在不同區域。 更多資訊，請參閱 Azure 區域配對。

可用性區域

可用性區域是 Azure 地區內獨特的實體位置。 每個區域都是由一或多個資料中心所組成，配備了獨立的電力、冷卻系統及網路系統。 若要確保復原能力，在所有已啟用的區域中都至少要有三個個別的區域。

可用性區域是故障網域和更新網域的組合。 如果您在 Azure 區域中的三個區域建立三個或以上的虛擬機器，您的虛擬機器將有效地分布在三個故障網域和三個更新網域。 Azure 平台會識別這種跨更新網域的分布，以確保不同區域的虛擬機器不會同時更新。

每次基礎結構更新會按區域逐步推出。 但是，您可以在區域 1 有部署進行的同時，在區域 2 有不同的部署進行。 部署並非全部序列化進行。 但需要重新啟動的單一部署，每次僅在一個區域推出，以降低風險。 一般而言，會盡量避免需要重新啟動的更新，且 Azure 會嘗試使用即時移轉或提供客戶控制。

虛擬機器擴展集

彈性協調流程模式下的虛擬機器擴展集是 Azure 計算資源，可讓您結合「統一」協調流程模式下虛擬機器擴展集的可擴充性，與可用性設定組的區域可用性保證。

使用「彈性」協調流程，您可以選擇執行個體是分布在多個區域，還是分布在單一區域內的多個故障網域。

可用性設定組與「統一」擴展集

在 Azure 虛擬機器上部署工作負載時，您可以將虛擬機器建立在可用性設定組中，以為應用程式提供高可用性。 使用可用性設定組，您可以確定在需要重新開機的中斷或維護事件期間，至少有一個 VM 可供使用。

在可用性設定組中，單個虛擬機器會分布在最多 20 個更新網域內。 在排定的維護期間，同一時間只會更新一個更新網域。 更新網域不一定會依序更新。

虛擬機器擴展集在統一協調流程模式中是一種 Azure 計算資源，您可以使用它將一組相同的虛擬機器作為單一資源進行部署與管理。 擴展集會自動分佈到更新網域，就像可用性設定組中的虛擬機器一樣。 與可用性設定組相同，當您使用「統一」擴展集時，在排定的維護期間，同一時間只會更新一個更新網域。

如需設定虛擬機器以達成高可用性的詳細資訊，請參閱管理適用於 Windows 的虛擬機器可用性或 Linux 的相應文章。

後續步驟

要管理計劃維護，請使用 Azure CLI、Azure PowerShell 或 portal。

  • Last updated on