共用方式為

瞭解 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，然後重新啟動 VM。

若要了解什麼是 Azure 計劃性維護，以及其如何影響 Linux VM 的可用性，請參閱此處所列的文章。 這些文章提供有關 Azure 背景計劃性維護程序的背景，以及如何排定計劃性維護以進一步降低影響。

記憶體保留更新

針對 azure Microsoft中的這一類更新，使用者不會對其執行中的 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 和 Windows Update

適用於雲端的 Microsoft Defender 監視每日 Windows 和 Linux VM，以取得遺失的作業系統更新。 適用於雲端的 Defender 會根據 Windows VM 上設定的服務，從 Windows Update 或 Windows Server Update Services （WSUS） 擷取可用安全性和重大更新的清單。 適用於雲端的 Defender 也會檢查 Linux 系統的最新更新。 如果您的 VM 遺失系統更新，適用於雲端的 Defender 建議您套用系統更新。 這些系統更新的應用程式是透過 Azure 入口網站 中的 適用於雲端的 Defender 來控制。 套用一些更新之後，可能需要 VM 重新啟動。 如需詳細資訊，請參閱在 適用於雲端的 Microsoft Defender 中套用系統更新。

就像內部部署伺服器一樣，Azure 不會將更新從 Windows Update 推送至 Windows VM，因為這些機器是由其使用者所管理。 不過，建議您讓自動 Windows Update 設定保持啟用。 從 Windows Update 自動安裝更新也可能導致套用更新之後重新啟動。 如需詳細資訊，請參閱 Windows Update 常見問題。

影響 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 上執行的工作負載或角色可能會觸發客體作業系統內的錯誤檢查。 如需判斷損毀原因的協助，請檢視 Windows VM 的系統和應用程式記錄以及 Linux VM 的序列記錄。

Azure 中的 VM 依賴裝載於 Azure 儲存體 基礎結構上的作業系統和數據記憶體的虛擬磁碟。 每當 VM 與相關聯虛擬磁碟之間的可用性或連線能力超過 120 秒時，Azure 平臺就會執行強制關閉 VM，以避免數據損毀。 還原記憶體連線之後，VM 會自動重新開啟電源。 關機的持續時間可能縮短為五分鐘，但可能更長。

其他事件

在罕見的情況下，廣泛的問題可能會影響 Azure 數據中心內的多部伺服器。 如果發生此問題，Azure 小組會將電子郵件通知傳送給受影響的訂用帳戶。 您可以檢查 Azure 服務健康狀態儀錶板和 Azure 入口網站，以取得持續中斷和過去的事件狀態。

診斷 VM 重新啟動

您可以使用 VM 刀鋒視窗上的 [診斷和解決] 刀鋒視窗來執行其他診斷。 這可能會發現最近 VM 重新啟動的更具體原因。 如果有任何客體 OS 問題，請收集記憶體轉儲並連絡支持人員。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。