Azure 中虛擬機器進行的維修

適用於: ✔️ Linux VM ✔️ Windows VM ✔️ 彈性擴展集 ✔️ 統一擴展集

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

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

  • 如果更新不需要重新開機,則在更新主機時 VM 會暫停,或 VM 會即時移轉至已更新的主機。
  • 如果維護需要重新開機,您會收到計劃性維護的通知。 Azure 也提供一個時間範圍,可讓您在適合自己的時間自行開始維護。 除非維護很緊急,否則自行維護的時間範圍通常為 35 天 (針對主機電腦)。 Azure 正在投資技術,以減少計劃性平台維護需要 VM 重新開機的情況。 如需如何管理計劃性維護的指示,請參閱使用 Azure CLIPowerShell入口網站來處理計劃性維護通知。

本頁說明 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、M、N 和 H 系列。 Azure 越來越常使用即時移轉技術,並改進了記憶體保留維護機制以縮短暫停時間。

這些不需要重新開機的維護作業一次會套用到一個容錯網域。 作業在收到平台監視工具所傳來的任何警告健康情況訊號時便會停止。 不需要重新開機的維護作業可能會在配對的區域或可用性區域中同時發生。 針對指定的變更,部署大多會跨可用性區域和跨區域配對進行排序,但尾端可能會重疊。

這些類型的更新可能會影響某些應用程式。 將 VM 即時移轉至不同主機時,有些敏感性工作負載可能會在該幾分鐘內出現些微的效能降低,而導致 VM 暫停。 若要準備 VM 維護並降低 Azure 維護期間的影響,請嘗試為這類應用程式使用適用於 Windows 的 Scheduled Events使用適用於 Linux 的 Scheduled Events

若要對所有維護活動 (包括無影響和不必重新開機的更新) 進行更好的控制,您可以建立 [維護設定] 功能。 建立 [維護設定] 可讓您選擇略過所有平台更新,並在您所選的時間套用更新。 如需詳細資訊,請參閱使用維護設定管理平台更新

即時移轉

即時移轉作業不需要重新開機,而且會保留 VM 的記憶體。 其會造成暫停或凍結,通常不會持續超過 5 秒。 除了 G、L、N 和 H 系列以外,所有基礎結構即服務 (IaaS) VM 都有資格進行即時移轉。 大部分的 M 系列 SKU 都可以使用即時移轉。 合格的 VM 代表 90% 以上已部署至 Azure Fleet 的 IaaS VM。

注意

針對不需要重新開機的即時移轉作業,您將不會在 Azure 入口網站中收到通知。 若要查看不需要重新開機的即時移轉清單,請查詢已排定事件

Azure 平台會在下列案例中開始進行即時移轉:

  • 預定的維修
  • 硬體失敗
  • 配置最佳化

某些計劃性維護案例會使用即時移轉,而您可以使用 Scheduled Events 來事先了解即時移轉作業將要開始。

當 Azure Machine Learning 演算法預測到即將發生硬體故障或您想要將 VM 配置最佳化時,也可以使用即時移轉來移動 VM。 如需可偵測到硬體降級情況的預測性模型詳細資訊,請參閱使用預測性機器學習和即時移轉來改善 Azure VM 復原能力。 如果您使用這些服務,即時移轉通知就會出現在 Azure 入口網站的「監視器」和「服務健康狀態」記錄以及 Scheduled Events 中。

需要重新開機的維護

如果遇到計劃性維護需要將 VM 重新開機的罕見情況,您會事先收到通知。 計劃性維護有兩個階段:自助階段和排程維護階段。

自助階段期間 (一般會持續四週),您可以在 VM 上啟動維護作業。 在自助期間,您可以查詢每個 VM,以查看其狀態和上一次維護要求的結果。

注意

對於不支援即時移轉的 VM 系列,本機 (暫時) 磁碟資料在維護事件期間可能會遺失。 如需是否支援即時移轉的詳細資訊,請參閱每個個別 VM 系列。

當您開始進行自助維護時,您的 VM 會重新部署至已經更新的節點。 因為 VM 會重新部署,所以暫存磁碟會遺失,而系統會更新與虛擬網路介面關聯的公用動態 IP 位址。

如果在自助維護期間發生錯誤,作業將會停止、VM 不會更新,而且您可以選擇重試自助維護。

當自助階段結束時,排程維護階段就會開始。 在這個階段,您仍然可以查詢維護階段,但無法自行啟動維護作業。

若要深入了解如何管理需要重新開機的維護,請參閱使用 Azure CLIPowerShell入口網站處理計劃性維護通知

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

如果您決定等到排程維護階段,為了維持 VM 的最高可用性,請考慮下列事項。

配對的區域

每個 Azure 區域都會與相同鄰近地理位置內的另一個區域配對。 它們一起構成區域配對。 在排程的維護階段期間,Azure 只會更新區域配對中單一區域的 VM。 舉例來說,在更新美國中北部的 VM 時,Azure 並不會同時更新任何美國中南部的 VM。 不過,像是北歐等其他區域可以和美國東部一同進行維護。 了解區域配對的運作方式可協助您將 VM 更妥善地分散於各區域。 如需詳細資訊,請參閱 Azure 區域配對

可用性區域

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

可用性區域結合了容錯網域和更新網域。 如果您在 Azure 區域中建立橫跨三個區域的三個 (或更多) VM,您的 VM 會有效地分散到三個容錯網域和三個更新網域。 Azure 平台會從更新網域中辨識此分佈,以確定不會同時更新不同區域中的 VM。

每個基礎結構更新都會在單一區域內逐區推出。 但是,您可以在 Zone 1 進行部署,並同時在 Zone 2 進行不同的部署。 部署並未完全序列化。 但是,需要重新啟動的單一部署一次只會推出到一區,以降低風險。 一般而言,系統會儘量避免需要重新開機的更新,而 Azure 會嘗試使用即時移轉或提供客戶控制項。

虛擬機器擴展集

處於彈性協調流程模式的虛擬機器擴展集是可讓您合併處於統一協調流程模式之虛擬機器擴展集的可擴縮性,以及可用性設定組的區域可用性保證的 Azure 計算資源。

透過彈性協調流程,您可以選擇要將執行個體分散到多個區域,還是分散到單一區域內的容錯網域。

可用性設定組和統一擴展集

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

在可用性設定組內,個別 VM 會散佈在多達 20 個更新網域。 在排程維護期間,在任何指定時間都只會更新一個更新網域。 更新網域不一定會依序更新。

處於統一協調流程模式的虛擬機器擴展集是可讓您使用來以單一資源的形式部署及管理一組相同 VM 的 Azure 計算資源。 擴展集會自動部署於更新網域,如可用性設定組中的 VM。 和可用性設定組一樣,當您使用統一擴展集時,在排程維護期間的任何時候,都只會更新一個 UD。

如需如何設定 VM 以獲得高可用性的詳細資訊,請參閱管理 Windows VM 的可用性或適用於 Linux 的對應文章。

下一步

您可以使用 Azure CLIAzure PowerShell,或入口網站來管理計劃性維護。