Windows Azure主機更新：原因、時間和方式

Windows HTTP://www.aliyun.com/zixun/aggregation/13357.html">Azure 的計算平臺（其中包括 Web Role、Worker Role 和虛擬機器）基於電腦虛擬化。 對基礎作業系統的深入訪問使 Windows Azure 的平臺即服務 (PaaS) 與許多現有軟體元件、運行時和語言唯一相容，當然，如果沒有這種深入訪問（包括使用者自己提供作業系統映射的能力），Windows Azure 的虛擬機器則不能歸類為基礎設施即服務 (IaaS)。

主機作業系統和主機代理

當然，電腦虛擬化意味著，您的代碼無論是部署在 PaaS Worker Role 還是 IaaS 虛擬機器中，均在 Windows Server
Hyper-V 虛擬機器中執行。 每台 Windows Azure 伺服器（也稱為物理節點或主機）託管一個或多個虛擬機器（稱為「實例」），這包括在物理 CPU 內核上調度這些虛擬機器、為它們分配專用 RAM，以及授權並控制對本地磁片和網路 I/O 的訪問。

下圖顯示了伺服器軟體體系結構的簡化視圖。 主機分區（也稱為根分區）將 Windows Server 的 Server Core 設定檔作為主機作業系統運行，您可以看到圖解和標準 Hyper-V 體系結構圖之間的唯一區別是，Windows Azure 結構控制器 (FC) 主機代理 ( HA) 存在於主機分區中，此外在來賓分區中還有一個來賓代理 (GA)。 FC 是 Windows Azure 計算平臺的大腦，HA 是其代理，負責將伺服器整合到平臺中，以便 FC 可以部署、監控和管理定義 Windows Azure 雲服務的虛擬機器。 只有 PaaS 角色具有 GA，它是 FC 的代理，可為角色提供運行時支援並監控角色的運行狀況。

主機更新的原因

要確保 Windows Azure 為應用程式提供可靠、高效且安全的平臺，需要提供具有安全性、可靠性和高性能的更新對主機作業系統和 HA 進行修補。 正如您會考慮 Windows Update 重啟您自己安裝的 Windows 的頻率，我們會以大約每月一次的頻率將更新部署到主機作業系統。 HA 由多個子元件組成，例如網路代理 (NA) 和虛擬機器虛擬磁片驅動程式，前者用於管理虛擬機器 VLAN，後者用於將虛擬機器磁片連接到包含其在 Windows Azure 存儲中的資料的 Blob。 因此，我們會根據修補程式或新功能準備就緒的時間，以不同的時間間隔更新 HA 及其子元件。

部署更新時可以採取的步驟取決於更新的類型。 例如，幾乎所有與 HA 相關的更新在應用時都無需重新開機伺服器。 但是Windows 作業系統更新幾乎總是至少有一個補丁，通常還可能有多個, 會導致重新開機。 因此，我們讓 FC 在每台伺服器上「暫存」我們作為 VHD 部署的新版作業系統，然後 FC 會指示 HA 重新開機伺服器以進入新的映射。

PaaS 更新流程

Windows Azure 的一個關鍵屬性是其 PaaS 的橫向擴展計算模型。 當您在雲服務中使用其中一種無狀態虛擬機器類型（無論是 Web 還是 Worker）時，您只需更新雲服務配置中的角色實例數，即可輕鬆擴展和縮小角色。 FC 將自動完成所有工作，以在您擴展時創建新虛擬機器，在縮小時關閉並刪除虛擬機器。

然而，讓 Windows Azure 的橫向擴展模型如此獨特的原因在於，它使模型的核心部分具有高可用性。 FC 定義了一個稱為更新域 (UD) 的概念，用於確保角色在要求實例重新開機的計畫更新中可用，而不管這些更新是雲服務擁有者應用的角色更新（如角色代碼更新），還是涉及伺服器重新開機的主機更新（如主機作業系統更新）。 FC 可以保證不會因為計畫中的更新導致來自不同 UD 的實例同時離線。 預設情況下, 每個角色有5個UD, 不過雲服務可以在其服務定義檔中申請多達 20 個 UD。 下圖顯示了 FC 如何跨三個 UD 傳播雲服務的兩個角色的實例。

角色實例可以調用運行時 API，以確定它們的 UD 和入口網站也顯示角色實例到 UD 的映射。 這裡是一個具有兩個角色的雲服務，每個角色有兩個實例，因此每個 UD 有每個角色的一個實例：

關於 UD，FC 針對雲服務更新和主機更新的行為有所不同。 當更新是雲服務應用的更新時，FC 將依次更新每個 UD 的所有實例。 僅當目前UD中所有實例重新開機並向 GA 報告自己正常運行時，或當雲服務擁有者要求 FC 通過服務管理 API 移動到下一個 UD 時，它才會移動到下一個 UD。

在主機更新期間，一個角色同時重新開機的實例的順序和數量可能有所不同，而不是一次處理一個 UD。 這是因為伺服器上的實例放置可以防止 FC 重新開機伺服器，在這些伺服器上，UD 的所有實例同時被託管，甚至按 UD 順序託管。 考慮下圖中伺服器的實例分配。 服務 A 的角色的實例 1 位於伺服器 1 上，實例 2 位於伺服器 2 上，而服務 B 的實例則按相反順序放置。 不管 FC 按什麼順序重新開機伺服器，服務都會以與其 UD 相反的順序重新開機實例。 所示的分配是比較少見的，因為 FC 分配演算法通過嘗試在同一伺服器上放置來自相同 UD 的實例來進行優化，而不管這些實例屬於什麼服務。 但此分配是有效分配，因為 FC 可以重新開機伺服器，而不違反它不會導致（單一服務的）相同角色的不同 UD 的實例同時離線的承諾。

主機更新和雲服務更新之間的另一個區別是，當更新為主機更新時，FC 必須確保實例不會無限期拖延整個資料中心的伺服器更新進度。 因此，FC 會在最多五分鐘內分配實例，然後將伺服器重新開機到新的主機作業系統，而角色實例會在重新開機後最多 15 分鐘內報告其正常運行。 依次重新開機主機、VM 和 GA，最後啟動角色實例代碼，此過程需要幾分鐘，因此實例通常會在 15 到 30 分鐘之間離線，具體取決於該實例和任何其他共用伺服器的實���關閉和重新開機分別需要多長時間。 有關主機作業系統更新過程中 Web role 和 Worker role 的預期狀態變化的更多詳細資訊，請按一下此處。 請注意，對於 PaaS 服務，FC 還會為來賓管理作業系統服務，因此在執行主機作業系統更新後通常會執行相應的客體作業系統更新（針對選擇更新的 PaaS 服務），後者由 UD 像其他雲服務更新一樣實施更新。

IaaS 和主機更新

前面的討論圍繞 PaaS 角色，它會在角色橫向擴展時自動獲得 UD 的益處。 另一方面，虛擬機器實質上是沒有橫向擴展能力的單實例角色。 IaaS 功能版本的一個重要目標是使虛擬機器能夠在主機更新和硬體故障時實現高可用性，可用性集功能的作用就體現在這裡。 您可以使用 PowerShell 命令或 Windows Azure 監管中心將虛擬機器添加到可用性集。 下面是具有分配到可用性集的虛擬機器的示例雲服務：

正如角色一樣，預設情況下可用性集有 5 個 UD，最多支援 20 個 UD。 FC 跨 UD 將分配的實例傳播到可用性集，如下圖中所示。 這使客戶能夠將專為高可用性設計的虛擬機器（例如為 SQL Server 鏡像配置的兩個虛擬機器）部署到可用性集，這可確保主機更新將導致只有一半的鏡像同時重新開機，如此處所述（本文將不討論這一點，但 FC 還使用一種稱為故障域的功能來跨伺服器自動傳播角色和可用性集的實例，以便資料中心的任何單個硬體故障最多影響一半實例）。

更多資訊

您可以在 Windows Azure 會議中找到有關更新域、故障域和可用性集的更多資訊，您還可以按一下此處，在 Mark 的網路直播頁面找到相關會議視頻。 Windows Azure MSDN 文檔介紹了主機作業系統更新和更新域的服務定義架構。