共用方式為

Azure VM 作業系統升級所造成的角色實例重新啟動

  • 發行項

本文討論Microsoft Azure 虛擬機 （VM） 操作系統 （OS） 升級對重新啟動角色實例的影響。 其中包含OS和客體代理程序升級排程、服務影響和需求、通知、偵測，以及如何解決常見問題的詳細數據。

升級排程

大約每月Microsoft發行 Azure 平臺即服務 （PaaS） VM 的新客體 OS 版本。 確切的排程會有所不同，在 Azure 客體 OS 版本和 SDK 相容性矩陣中可以看到歷史趨勢。 在此推出期間， Azure Fabric 控制器 會透過所有資料中心執行兩次傳遞（主機 OS 傳遞和客體 OS 傳遞）。 Azure 客體代理程式的定期更新也會在您的 VM 內執行。

下列各節提供有關兩個升級階段和客體代理程序升級的更多詳細數據。

傳遞 1：主機 OS

第一次傳遞會升級主機OS。 主機OS會重新啟動角色實例，網狀架構控制器可確保一次只重新啟動一個升級網域中的實例。 在此重新啟動期間，您的角色實例會經歷標準關機程式。 然後，系統會 RoleEnvironment.OnStop 執行 事件，讓您有機會正常關閉 實例。

主機 OS 更新可能需要數天的時間，網狀架構才能協調數據中心內所有不同託管服務和升級網域的升級。 一般而言，部署的不同實例會相隔數小時更新。

如需主機 OS 升級程式的詳細資訊，請參閱 Azure 主機更新：為何、何時及如何 進行 Azure 部落格文章。

傳遞 2：客體 OS

主機 OS 在數據中心完成升級之後，客體 OS 會針對設定為使用自動客體 OS 版本的服務升級。 此升級會繼續使用您服務的標準升級網域規則。 您的 VM 會重新啟動，並使用升級的 OS 重新映像 Windows 磁碟分區（D 磁碟驅動器）。

客體OS更新程式比主機OS更新快得多。 這是因為網狀架構必須只協調裝載服務和升級網域內的更新。 您服務的客體 OS 更新程式持續時間主要取決於下列因素：

  • 角色實例的數目
  • 升級網域數目
  • 您的服務關閉所花費的時間（Stopping 和 OnStop 事件）
  • 您的服務啟動所花費的時間（啟動工作和 OnStart 事件）

客體代理程式

Azure 客體代理程式會每月更新約一次。 更新客體代理程式時，會發生下列動作：

  • 執行您角色的主機進程（通常是 WaWorkerHost 或 WaWebHost）會正常關閉。
  • 客體代理程式會自行更新。
  • 主機進程會再次啟動。

如需客體代理程序進程及其如何與您的服務互動的詳細資訊，請參閱 Windows Azure 傳統 VM 架構的工作流程。

服務影響和需求

下列清單描述雲端服務的影響和需求：

  • 如果您的任一角色只有一個實例，您的服務可能會遇到停機時間。 您應該至少有兩個角色的實例，因為服務等級協定 （SLA） 需要 99.95% 的運行時間。

  • 預期您的角色實例會在每個月大約一次重新啟動主機 OS 更新。 如果您有自動客體 OS 更新，請預期您的實例會再次重新啟動。 一般而言，重新啟動相隔數小時。 不過，此時間範圍可能會根據數據中心記憶體在不同服務組成而變更。

  • 您的角色必須遵守控管主機 OS 更新的規則。 特別是，角色實例應該會在啟動工作 30 分鐘內達到 Ready 狀態。 如需這項限制的詳細資訊，請參閱 升級如何繼續。

  • 主機 OS 升級會導致重新啟動您的角色實例，而客體 OS 升級會導致相當於您實例的重新映像。 由於這些事件，您的角色實例必須能夠處理下列程式：

    • 重新啟動
    • 重新安裝映像
    • 回收

通知

目前，當操作系統升級發生時，Azure 平臺不會提供主動式通知。 您的角色實例會在關閉之前收到 RoleEnvironment.Stopping 事件。 您可以使用該事件，正常結束角色實例正在執行的任何工作，或通知系統管理員實例正在關閉。

您可以訂閱 Azure OS 更新 RSS 摘要。 此摘要應該會在操作系統更新開始推出至資料中心的同一天更新。 摘要通常不會提供進階主動式通知，但可協助您識別何時發生更新。 更新程式可能需要數天的時間才能完成。 因此，您可能必須等候更新 RSS 摘要和託管服務開始更新之間的一或多個天。

Azure 客體 OS 版本清單，以及可供在 Azure 入口網站 中選取的作業系統版本清單，通常會在客體 OS 推出完成後更新。 您不應該在這些清單中使用最新的專案，以指出操作系統更新何時進行中。

偵測

目前沒有直接方法來偵測主機 OS 升級。 不過，您可以在 VM 上的記錄檔內查看重新啟動的證據。 要執行這項操作，請執行下列任一動作：

  • 在 事件檢視器 應用程式中，搜尋事件來源 USER32、事件標識碼 1074 的系統事件記錄檔。 此事件包含下列訊息：

    程式 D：\Packages\GuestAgent\WaAppAgent.exe （RD00155D50206D ） 已代表使用者 NT AUTHORITY\SYSTEM 起始計算機關閉RD00155D50206D，原因如下：舊版 API 關機

    此訊息指出 Azure 網狀架構客體代理程式 （WaAppAgent.exe） 起始 VM 關機。

  • 在文本編輯器中，搜尋舊應用程式代理程式運行時間記錄檔 （AppAgentRuntime.log.old） 以尋找 _Context_Start 等於 的訊息ContextStopContainer()。 如需如何檢查應用程式代理程式運行時間記錄中內容專案的詳細資訊，請參閱 針對在 Azure 部落格封存中執行一段時間 後的角色回收進行疑難解答案例 6 – 角色回收。

常見問題與解決方案

下列各節將討論一些涉及角色實例重新啟動的常見問題，以及如何解決這些問題。 如需執行中進程以及可用於疑難解答之記錄檔位置的詳細資訊，請參閱 Windows Azure 傳統 VM 架構的工作流程。

問題 1：啟動工作或程式代碼無法在主機 OS 重新啟動後第二次執行

啟動工作或 或 Run 函式中的OnStart程式代碼可能會在主機 OS 重新啟動後第二次失敗。 重新啟動應該叫用啟動工作再次執行。 此失敗可防止角色實例達到 Ready 狀態。

如果您在啟動工作中執行某些動作，然後執行第二次執行錯誤後傳回錯誤的命令，該怎麼做？ 在此情況下，您的啟動工作將會失敗，並導致您的角色實例開始回收。 例如，如果您使用APPCMD set config 命令在 網際網路資訊服務 （IIS） 中新增組態區段，命令在第二次執行時會失敗。 此命令會產生錯誤訊息：「新增新增物件缺少必要的屬性。 無法新增類型的重複集合專案...然後，角色實例會開始回收。

解決方案 1：連線至 VM，並從遠端偵錯啟動或程式代碼失敗

若要針對這類失敗進行疑難解答，請使用遠端桌面通訊協定 （RDP） 從遠端連線到 VM。 檢查事件記錄檔中是否有錯誤，並簽入WaHostBootstrapper.log檔案中是否有啟動工作失敗。 在一般開發和測試程序期間，您應該從 Azure 入口網站 主動起始角色實例的重新啟動。 此步驟可協助您測試服務，以確保它在此案例中正常運作。

啟動工作失敗的常見修正是將命令新增 exit /b 0 至啟動工作腳本的結尾。 這個 結束 命令會使用表示成功的結束代碼結束腳本。 如需為何需要此命令的詳細資訊，請參閱 如何設定及執行 Azure 雲端服務（傳統版）的啟動工作。

問題 2：重新映像 Windows 磁碟分區之後，啟動工作或程式代碼不會執行

Windows 磁碟分區 （D 磁碟驅動器） 通常是儲存程式安裝和登錄變更的位置。 在更新的客體 OS 部分期間，會重新映像 Windows 磁碟分區。 這可能會導致這些安裝與變更遺失。 如果啟動程式代碼錯誤地假設 Windows 磁碟分區重新映射之後，某些登錄變更仍然存在，則角色實例可能無法正常運作。 此失敗可防止角色實例達到 Ready 狀態。

例如，啟動工作可能會進行登錄變更。 然後，它會將該變更的記錄儲存在 C 或 E 磁碟驅動器上，以確保登錄變更不會第二次執行。 不過，D 磁碟驅動器上的登錄變更將會因為重新映像而遺失，而且啟動工作不會還原該登錄變更，因為工作認為沒有必要。 遺失的登錄變更最終可能會導致啟動工作的其餘部分失敗。

解決方案 2：測試從 Azure 入口網站 重新映射角色實例

在一般開發和測試程序期間，您應該從 Azure 入口網站 主動起始角色實例的重新映像。 此步驟可協助您測試服務，並確定它在此案例中正常運作。

問題3：啟動程式代碼需要超過30分鐘才能完成

如果您的啟動程式代碼需要超過 30 分鐘才能完成，您可能同時有多個角色實例超出服務。 當啟動工作採取下列其中一個動作時，最常發生此案例：

  • 安裝程式或功能
  • 下載快取數據
  • 下載網站資訊

解決方案3：檢閱服務影響和需求

請檢閱 服務影響和需求 一節，以瞭解預期的情況，以及如何防止或減輕任何啟動延遲。

問題 4：Azure 不會在更新後重新啟動主機或客體 OS

在極少數情況下，Azure 在更新之後可能不會重新啟動主機或客體 OS。 在此案例中，您可能會在入口網站中看到「等候主機」訊息，該訊息在 30 分鐘或之後不會變更。

解決方案 4a：修正啟動程式代碼

如果您能夠使用遠端桌面通訊協定 （RDP） 連線到角色實例，則啟動程式代碼中可能會發生失敗，您可以修正。 如需如何修正啟動程式碼的詳細資訊，請參閱 解決方案 1：連線到 VM 並遠端偵錯啟動或程式代碼失敗。

解決方案 4b：刪除部署

如果您無法使用 RDP 連線到角色實例，則復原實例的唯一方式可能是刪除部署。

問題 5：操作系統升級期間無法使用一或多個角色實例

如果在OS升級期間無法使用任何角色實例，這可能會導致服務容量減少。 例如，假設您有兩個 Web 角色實例，而且這兩個實例通常會以 75% 的 CPU 使用量執行。 如果在升級期間重新啟動一個實例，流量會重新導向至其餘實例。 該實例無法處理額外的負載。 這會導致服務可用性降低。

解決方案5：在您的服務中保留足夠的容量

請確定您的服務有足夠的容量過剩，以吸收特定百分比的角色實例無法使用。 若要計算您必須提供的過剩容量量，請將第一個數位除以升級網域數目。 例如，如果您有兩個升級網域，則需要 1/2 = 50% 的容量，才能處理升級網域變得無法使用。 如果您有五個升級網域，則需要 1/5 = 20% 的容量，以處理五個升級網域中的其中一個可用性遺失。

問題 6：用戶端遇到中斷或逾時，因為您的網站需要太長的時間才能熱身

您的網站需要幾分鐘的時間才能熱身嗎？ （例如，網站熱身可能由標準 IIS 或 ASP.NET 先行編譯和模組載入所組成，或者可能會讓快取或其他應用程式特定的工作變暖。在此情況下，您的用戶端可能會遇到中斷或隨機逾時的情況。

角色實例重新啟動后，您的程式 OnStart 代碼會完成其執行，您的角色實例會還原至負載平衡器輪替。 角色實例接著會開始接收傳入要求。 如果您的網站仍在熱身，所有傳入的要求都會排入佇列並逾時。假設您只有兩個 Web 角色實例。 在此情況下， IN_0 實例會在客體 OS 更新重新啟動實例時 IN_1 收到 100% 的傳入要求。 不過， IN_0 實例仍在升溫。 此案例可能會導致服務完全中斷，直到您的網站在這兩個實例上完成熱身。

解決方案 6：停止角色實例接收傳入要求，直到熱身完成

建議您保留 OnStart 角色實例的事件處理程序代碼，直到網站完成其熱身為止。 若要實作此事件進程，您可以使用下列範例程式代碼：

public class WebRole : RoleEntryPoint {
    public override bool OnStart () {
        // For information about handling configuration changes, see the article
        // "Customize the Lifecycle of a Web or Worker role in .NET" at
        // https://learn.microsoft.com/azure/cloud-services/cloud-services-role-lifecycle-dotnet.
        IPHostEntry ipEntry = Dns.GetHostEntry (Dns.GetHostName ());
        string ip = null;
        foreach (IPAddress ipaddress in ipEntry.AddressList) {
            if (ipaddress.AddressFamily.ToString () == "InterNetwork") {
                ip = ipaddress.ToString ();
            }
        }
        string urlToPing = "https://" + ip;
        HttpWebRequest req = HttpWebRequest.Create (urlToPing) as HttpWebRequest;
        WebResponse resp = req.GetResponse ();
        return base.OnStart ();
    }
}

其他相關資訊

與我們連絡，以取得說明

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