共用方式為


特別報導:Windows Server 2008

深入探討 Windows Server 2008 核心變更

Mark Russinovich

 

摘要:

  • 記憶體管理與 SMB 2.0
  • NTFS 自我修復、Windows Hardware Error Architecture 及驅動程式檢查器
  • I/O 完成通訊埠、執行緒集區和 NUMA 的延展性
  • Hyper-V 虛擬化

Windows Server 2008 是最新發行的 Microsoft 伺服器平台,包含橫跨作業系統中各功能區域的系統層級變更,從記憶體管理

到執行緒排程,還有從網路到安全性,不勝枚舉。

Windows Server® 2008 與 Windows Vista® SP1 共用相同的核心,因此它包含了我在前幾期《TechNet Magazine》文章中討論過的許多增強功能:<深入探索 Windows Vista 核心>第 1-3 篇 (2007 年 2 月、3 月及 4 月) 和<深入探索 Windows Vista 使用者帳戶控制>(2007 年 6 月)。在這些文章提及的功能中,只有一小部分是專門針對用戶端而設計,而且並不包含在 Windows Server 2008 中,像是 SuperFetch、ReadyBoost、ReadyDrive、ReadyBoot 及多媒體類別排程器服務 (MMCSS)。

之前討論的某些 Windows Vista 重要核心變更也出現在 Windows Server 2008 中,例如 I/O 優先順序處理、新的開機結構、BitLockerTM、程式碼完整性以及強制整合層級,因此在本文中將不再贅述,我會把重點放在前文尚未提及的關鍵變更內容,包括與可靠性、效能與延展性相關的變革,還有全新的 Microsoft Hypervisor 機器虛擬化技術 Hyper-VTM。

如同先前的文章一樣,本文的範圍僅限於作業系統核心 (Ntoskrnl.exe) 及其密切相關的系統元件。本文內容不包括有關安裝 (WIM,或 Windows® Imaging Format,以及以元件為基礎的服務)、管理 (群組原則和 Active Directory® 改進功能)、一般診斷和監控 (Windows 診斷基礎結構)、核心網路功能 (新的防火牆和 TCP/IP 實作)、Server Core 或伺服器角色等諸如此類的變更。

運用多處理器系統

其中一項低階的系統變更就是,Windows Server 2008 只包含一個專為運用多處理器系統而設計的核心版本。Windows 過去在包含單一 CPU 的電腦上是使用單一處理器的特定版本,因為這種版本會忽略只有多處理器環境才需要的同步處理程式碼,藉此稍微提升效能。隨著硬體速度越來越快,這種最佳化處理所帶來的效能優勢變得微不足道,而且今日大部分的系統都不只包含一個處理器,因此不再需要單一處理器版本。

[圖 1] 顯示 Windows Server 2008 核心的各種變體,在系統上使用的版本取決於它是否是作業系統的偵錯 (檢查) 或零售版本,安裝成 32 位元或 64 位元 (Itanium、Intel 64 或 AMD64),如果是 32 位元安裝,那麼系統是否具有 4 GB 以上的實體記憶體或支援資料執行防止 (DEP)。Windows Server 2008 也是最後一個可望提供 32 位元版本的 Windows Server 作業系統。

Figure 1 Windows Server 2008 核心變體

核心 32 位元 64 位元
多處理器
多處理器已選取
多處理器實體位址延伸 (Physical Address Extension,PAE)
多處理器 PAE 已選取

Windows Server 的每個版本都致力於提升關鍵伺服器案例的效能,例如檔案服務、網路 I/O 和記憶體管理。此外,Windows Server 2008 涵蓋多項變更與新功能,可讓 Windows 善用嶄新的硬體結構、靈活應變高延遲網路,並擺脫限制舊版 Windows 效能的瓶頸。本節將探討記憶體管理員與 I/O 系統的增強功能,並介紹全新的網路檔案系統 SMB 2.0。

記憶體管理

實驗:查看大型磁碟 I/O

您可以使用類似 TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx) 的檔案系統監控工具來尋找 Windows Server 2008 系統上的大型檔案 I/O 作業。

產生大型 I/O 的方式有好幾種。如果您有第二個執行 Windows Vista Service Pack 1 或 Windows Server 2008 的系統,就可以在伺服器上執行 Process Monitor 並監控複製到第二個系統的檔案複本。通常您也可以藉由執行需要大量記憶體的程式,讓記憶體管理員將頁面寫出到分頁檔,來產生大型分頁檔 I/O。

[圖 A] 顯示 Process Monitor 在 Windows XP 系統上執行需要大量記憶體的程式之後的情況,其 Process Monitor [選項 (Options)] 功能表中的 [啟用進階輸出 (Enable Advanced Output)] 選項已選取,而且篩選器被設為只顯示分頁檔 pagefile.sys 的寫入。[詳細資料 (Detail)] 欄顯示寫入大小為 64 KB。

[圖 A]

[圖 A]  (按影像可放大)

在 Windows Server 2008 中執行相同步驟時,您很可能會看到如 [圖 B] 所顯示的畫面,其中的寫入大小幾乎都是 1 MB 左右。

[圖 B]

[圖 B]  (按影像可放大)

Windows Server 2008 中的記憶體管理員加入了多項效能增強功能。舉例來說,它從分頁檔擷取資料或在對應檔上執行預先讀取 I/O 時,會發出次數較少但規模較大的 I/O。透過變更 I/O 系統以移除自 Windows NT® 以來一直存在的 64 KB I/O 大小限制,因而促進了大型檔案 I/O 的產生。

另外值得注意的是,在 Windows Server 2008 中,快取管理員從對應檔進行預先讀取 (推測讀取) 的資料讀取大小往往比 Windows Server 2003 的大上兩倍,而且直接進入待命清單 (系統的程式碼和資料快取)。上述這種作法使得快取管理員不再需要對應虛擬記憶體並將資料讀入系統的工作集 (由記憶體管理員指派給系統的記憶體),而第二種作法可能會造成其他使用中的程式碼或資料無緣無故從工作集中被回收。

記憶體管理員在寫入資料到分頁檔時也會執行較大的 I/O。Windows Server 2003 常會執行小於 64 KB 的寫入,但 Windows Server 2008 中的記憶體管理員一般都會發出 1 MB 的寫入。

除了減少對分頁檔的寫入次數來提高效能,較大的寫入也能降低分頁檔內部的分散程度。這也會進而減少讀回多頁所需的讀取和磁碟搜尋次數,因為這些頁面往往並不相鄰。

記憶體管理員還會試著寫出其他接近在主控處理程序的位址空間中被寫出之頁面的已修改頁面,並瞄準已經存放其他相鄰頁面的分頁檔區域。這麼做也能盡量降低分散程度並提升效能,因為最終可能會寫出到分頁檔的頁面早已寫入。此外,這樣還可減少為了提取一系列相鄰處理程序分頁所需的分頁讀取次數。請參閱資訊看板「實驗:查看大型磁碟 I/O」以取得記憶體管理員使用大型 I/O 的詳細資訊。

SMB 2.0

伺服器訊息區 (SMB) 遠端檔案系統通訊協定又稱為 Common Internet File System (CIFS),自 Windows 引入檔案服務功能以來,向來都是 Windows 檔案服務的基礎。過去幾年來,SMB 的設計限制阻礙了 Windows 檔案服務效能的成長,以及利用本機檔案系統新功能的能力。例如,在單一訊息中可以傳送的最大緩衝區大小約為 60 KB,而且 SMB 1.0 無法察覺 Windows Vista 與 Windows Server 2008 現已加入的 NTFS 用戶端符號連結。

Windows Vista 和 Windows Server 2008 引入 SMB 2.0 這個新的遠端檔案服務通訊協定,當用戶端與伺服器同時有支援時,Windows 就會使用 SMB 2.0。SMB 2.0 不僅可以正確處理用戶端符號連結和其他 NTFS 增強功能,還會使用批次處理來減少用戶端與伺服器之間交換的訊息數量。批次處理可以增進廣域網路 (WAN) 等高延遲網路的輸送量,因為它允許同時傳送更多資料。

SMB 1.0 會針對單一檔案循序發出 I/O,而 SMB 2.0 卻是透過實作 I/O 管線來為相同檔案發出多個並行 I/O。它會測量用戶端用於未處理 I/O 的伺服器記憶體量,以便決定管線深度。

多虧 Windows I/O 記憶體管理員的變更、TCP/IP 接收視窗微調,以及檔案複製引擎的功能改良,SMB 2.0 得以大幅增進輸送量,同時減少大型傳輸的檔案複製次數。部署 Windows Server 2008 檔案伺服器並搭配 Windows Vista 用戶端可以啟用 SMB 2.0 和實現這些效能優勢,因為這兩個作業系統都實作 SMB 2.0。

NTFS 自我修復提供的可靠性

可靠性是一項關鍵的伺服器特質,Windows Server 2008 提供了各種增進功能來協助系統管理員順利執行伺服器,這些功能包括線上 NTFS 一致性修復、新的硬體錯誤報告基礎結構,以及驅動程式檢查器的延伸模組。

今日的儲存裝置容量已達數兆位元組,因此讓磁碟區離線進行一致性檢查可能會導致好幾個小時的服務中斷。Windows Server 2008 發現很多磁碟損毀都是本機單一檔案或部分中繼資料的問題,因而實作新的 NTFS 自我修復功能來修復損害,同時讓磁碟區保持連線狀態。

當 NTFS 偵測到損毀時,它會禁止存取受損檔案並建立系統工作者執行緒,這個執行緒針對受損的資料結構執行類似 Chkdsk 的修正動作,動作完成後即可存取已修復的檔案。進行這項作業的期間可以照常存取其他檔案,藉此盡量避免服務中斷的情況。

WHEA 基礎結構

包含在 Windows Server 2008 中的 Windows Hardware Error Architecture (WHEA) 基礎結構保證一定會簡化硬體失敗的管理程序,並針對非嚴重錯誤主動提出回應。伺服器通常都有嚴格的執行率保證,因此在這類系統上及時識別和回應錯誤攸關重大。

經由 Online Crash Analysis (OCA) 提交給 Microsoft 的當機分析結果顯示,約有 10 % 的作業系統當機事件與硬體失敗相關,但是很難找出這些當機事件的根本原因,因為硬體在當機事件所提供的錯誤資訊不足。此外,在 Windows Server 2008 出現之前,Windows 並未提供監控裝置健康情況,也沒有實作補救措施或即將失敗通知的內建支援。原因在於硬體裝置並非使用通用的錯誤格式,而且也不支援錯誤管理軟體。

WHEA 針對平台裝置 (包括處理器、記憶體、快取和 PCI 與 PCI Express 等匯流排) 提供整合的錯誤來源探索及報告機制。方法是實作 [圖 2] 顯示的架構,其中的核心便是錯誤來源呼叫以報告錯誤的核心 API。API 會要求所有錯誤都以共通方式格式化,並使用 Windows 事件追蹤 (ETW) 事件來記錄錯誤 (嚴重錯誤會於重新開機後記錄)。

[圖 2] WHEA 錯誤報告基礎結構

[圖 2]** WHEA 錯誤報告基礎結構 **(按影像可放大)

ETW 是由 Windows 2000 引進,而 WHEA 使用 ETW 讓硬體製造商和軟體廠商更容易開發採用 WHEA 事件的裝置診斷管理應用程式。如果事件嚴重性有造成系統當機之虞,WHEA 可確保嚴重錯誤記錄會儲存在損毀傾印檔中,好讓系統管理員判斷當機的主因。

WHEA 的另一個關鍵部分是指定平台硬體錯誤驅動程式 (PSHED),位於 %Systemroot%\System32\Pshed.dll 中。核心會與 PSHED 連結,並與平台和韌體硬體交接,基本上是當做錯誤通知與 WHEA 錯誤報告 API 之間的轉譯層。每個平台架構 (x86、x64、Itanium) 都有一種 Microsoft 提供的 PSHED,而且 PSHED 會公開一個外掛程式模組,好讓硬體廠商與製造商以其平台特定的行為來覆寫預設行為。

最後,與其他錯誤來源接觸的系統元件 — 包括裝置驅動程式、硬體抽象層 (HAL) 與核心 — 可以實作最初處理錯誤情況的低階硬體錯誤處理常式 (Low-Level Hardware Error Handler,LLHEL)。LLHEL 的工作是從裝置擷取錯誤資訊,通知 PSHED 以便收集其他平台錯誤資訊,然後呼叫核心的 WHEA 錯誤報告 API。

驅動程式檢查器

打從 Windows 2000 開始,各種 Windows 產品都包含驅動程式檢查器,這項功能強大的工具可以追蹤不良的裝置驅動程式和故障硬體。系統管理員常會設定驅動程式檢查器 (%Systemroot%\System32\Verifier.exe) 來密切監控可能造成系統當機的裝置驅動程式。驅動程式檢查器會揪出不當的驅動程式作業,而損毀傾印檔便會直接指向該罪魁禍首。

之前的驅動程式檢查器實作有一項缺點,就是幾乎所有設定變更都需要重新啟動系統,這當然是生產伺服器所不樂見的。Windows Server 2008 對於驅動程式檢查器的實作能改善這項作業,方法是讓最有用的驗證不必重新啟動,讓它無須重新啟動也能疑難排解有問題的伺服器。

不僅如此,驅動程式檢查器還引入了三個新驗證,如 [圖 3] 所示。安全性檢查會確保裝置驅動程式在用來與應用程式互動的物件上有設定安全使用權限。強制擱置 I/O 要求會測試驅動程式對於立即完成而非延遲完成的非同步 I/O 作業的復原能力。而其他 (Miscellaneous) 檢查會搜尋不當釋放使用中資源的驅動程式,錯誤使用 Windows Management Instrumentation (WMI) 登錄 API 的驅動程式,以及遺漏資源控制代碼的驅動程式。

[圖 3] 驅動程式檢查器與 Windows Server 2008 已選取選項

[圖 3]** 驅動程式檢查器與 Windows Server 2008 已選取選項 **(按影像可放大)

延展性

延展性是指作業系統或應用程式有效利用多處理器和大量記憶體的能力。每一版的 Windows 都會盡量降低或避免使用鎖定來提升延展性,因為鎖定會減少多處理器的平行處理作業,Windows Server 2008 當然也不能自外於這種趨勢。

在執行計時器到期的程式碼中有一個微小卻重要的改良,它不再需要發送器鎖定,發送器鎖定是所有低階同步處理作業使用的全系統排程器鎖定。因此而減少的 CPU 同步處理量讓 Windows Server 2008 終端機伺服器系統能夠比 Windows Server 2003 額外支援 30 % 的並行使用者。

Windows Server 2008 中的其他延展性增強功能還包括完成連接埠增強、新的執行緒集區實作、效率更高的非統一記憶體存取 (NUMA) 硬體運用,以及動態系統資料分割。

改良的 I/O 完成通訊埠處理

大多數可調整的 Windows 伺服器應用程式,包括 IIS、SQL Server® 和 Exchange Server,都仰賴稱為完成通訊埠的 Windows 同步處理 API,來盡量減少在執行 I/O 作業時多個執行緒之間的切換動作。方法是首先建立新要求抵達的通知 (例如網頁伺服器用戶端連線) 與完成連接埠之間的關聯性,並使用某個執行緒集區來等待通知。當要求抵達時,Windows 會排程一個執行緒,這個執行緒接著通常會執行其他 I/O 作業,像是從磁碟讀取網頁,再傳送到用戶端以完成要求。

如此一來,同一個執行緒就可以盡快回來等候其他用戶端要求,執行緒以非同步處理的方式發出 I/O,並建立 I/O 完成與完成連接埠的關聯性。然後執行緒回來等待完成連接埠,當新要求抵達時或其中一個 I/O 完成時,該完成連接埠便會排程這個執行緒。這樣一來,相同的執行緒可以在 CPU 上保持作用中,並交替處理用戶端要求和等候完成連接埠。

舊版 Windows 的完成連接埠實作有一個缺點,就是在 I/O 完成時,I/O 系統會讓發出 I/O 的執行緒立即執行一小段完成處理程序,無論它原本是否在執行其他工作。如果有其他執行緒正在作用中,這種情況常會造成排程器提前佔用使用中執行緒並內容切換到發行者。

Windows Server 2008 透過延緩下一個執行緒的完成處理程序以等候與 I/O 相關聯的完成連接埠,藉此避免這些內容切換動作。因此,即使接下來輪到不同的執行緒等候完成連接埠,它仍會在執行其他程式碼之前執行完成處理程序,而排程器便不需要切換到發行執行緒。這種減少內容切換的方法可以顯著提升負荷過重的伺服器應用程式的延展性。

更有效的執行緒集區

撰寫運用多顆 CPU 的應用程式並不容易,為此 Windows XP 引入了工作者執行緒集區、基礎結構,以及相關的 API 來擷取在 CPU 間執行小型工作單位的詳細資料。應用程式將工作項目指定到執行緒集區 API,此執行緒集區 API 接著在它為系統中各個 CPU 建立和管理的其中一個執行緒上執行這些工作項目。

執行緒集區的目標是要透過使用相同執行緒來連續執行多個工作項目,藉此將內容切換次數減至最低。萬一其中一個執行緒正在執行其他工作而無暇這麼做時,執行緒集區便會使用其他 CPU 上的不同執行緒來執行該工作項目。

Windows Server 2008 執行緒集區實作能夠更妥善運用多顆 CPU,這是由於完成連接埠增強功能所帶來的間接好處,也是由於最佳化執行緒管理,好讓工作者執行緒在需要處理應用程式工作負載時動態往返所帶來的直接效果。再者,基礎結構的核心已移往核心模式,可有效減少使用 API 的應用程式提出系統呼叫的次數。最後,新的 API 讓應用程式更容易執行特定作業,例如在應用程式關閉期間中止佇列的工作單位。

NUMA 最佳化

Windows Server 2003 在執行緒排程器和記憶體管理員方面引入 NUMA 機器的最佳化,而 Windows Server 2008 不但在 I/O 管理員中加入 NUMA 最佳化,更擴充了記憶體管理員的 NUMA 最佳化。

NUMA 系統通常是多處理器系統,而其中的記憶體會根據存取記憶體的處理器不同而具有不同的延遲 (見 [圖 4])。記憶體被區分成節點,當中 CPU 與節點之間的延遲可能不同,而每個 CPU 都被視為它能最快存取的節點的一部份。

[圖 4] NUMA 系統範例

[圖 4]** NUMA 系統範例 **(按影像可放大)

NUMA 系統,尤其是包含 8 顆 CPU 以上的 NUMA 系統,通常比統一記憶體存取系統更具有成本和效能效益。統一記憶體存取系統必須將記憶體平均提供給所有 CPU,相對來說,NUMA 系統可以針對直接連線到 CPU 的記憶體實作高速互相連線,並針對分隔較遠的 CPU 和記憶體實作成本較低的高延遲連線。

為了在 NUMA 系統上有效調整,作業系統或應用程式必須知悉節點拓撲,以便在含有運算資料與程式碼的記憶體附近執行運算。譬如說,Windows 排程器為每個執行緒指派所謂的理想處理器,也就是排程器試圖用來一直執行執行緒的 CPU。這麼做很可能會讓執行緒放置在 CPU 快取中的資料在每次執行時都能供執行緒使用。

在 Windows Server 2003 中,排程器將此概念進一步發揚光大,它將包含理想處理器的節點視為執行緒的理想節點,當理想處理器忙於執行其他執行緒時,排程器便會嘗試將執行緒排程到理想節點上的另一個 CPU 中。Windows Server 2003 記憶體管理員也變成能夠感知 NUMA,而且在可能時將執行緒的記憶體配置導向正在執行執行緒的節點的記憶體中。

在 Windows Server 2008 中,記憶體管理員會在各個節點間分隔核心的非分頁記憶體緩衝區 (核心與裝置驅動程式用來儲存保證會存留在 RAM 中的資料的記憶體),以確定配置是來自配置來源節點上的記憶體。如果配置需要新的分頁表頁來滿足其需求,那麼系統分頁表項目 (PTE) 會從配置起源的節點進行配置,而不會向 Windows Server 2003 一樣來自任何節點。

在 Windows Server 2003 中,當執行緒進行記憶體配置時,記憶體管理員偏好使用在配置當時執行執行緒的節點。如果執行緒暫時排程到非理想節點,在這段時間內執行的任何配置都將來自非理想節點。因此當執行緒最終在自己的理想節點上執行時,就無法盡量靠近儲存在已配置記憶體中的資料或程式碼。

為了解決這種情況,Windows Server 2008 記憶體管理員偏好讓執行緒的所有配置皆使用執行緒的理想節點,即使當執行緒是在其他節點附近執行也是如此。記憶體管理員也會自動了解處理器與節點間的延遲,因此萬一理想節點沒有可用的記憶體,它會接著查看最靠近理想節點的節點。除此之外,當執行緒參考程式碼或資料時,記憶體管理員會將待命清單中的頁面移轉到執行緒的理想節點。

針對想要掌控自身配置位置的應用程式,它們可以使用新的 NUMA 記憶體 API,以便指定記憶體配置、檔案對應檢視和檔案對應物件的偏好節點。如果配置與檔案對應相關,記憶體管理員便會查看對應作業是否已指定節點,接著檢查檔案對應物件是否已指定節點,若兩者皆否,記憶體管理員最後會回頭採用執行緒的理想節點。

在 Windows Server 2008 推出之前,儲存或網路 I/O 的插斷和相關的延遲程序呼叫 (Deferred Procedure Call,DPC) 可以在任何 CPU 上執行,包括來自不同節點的 CPU,而非 I/O 被啟動的節點,這可能會導致在 I/O 作業上讀取或寫入的資料位於不同節點的記憶體中,而非存取資料所在的記憶體。

為了避免這個問題,Windows Server 2008 I/O 系統將 DPC 執行導向啟動該 I/O 的節點中的 CPU,而且如果系統的裝置支援 PCI 匯流排 MSI-X (Message Signaled Interrupt 標準的延伸模組),系統就可以進一步抑制擴大 I/O 完成,方法是使用利用 Windows Server 2008 API 的裝置驅動程式將 I/O 插斷導至啟動 I/O 的處理器。

動態資料分割

系統提高延展性的方法之一,就是支援動態新增硬體資源 (如 CPU 與記憶體)。如果無須系統重新開機就能替換這些資源,這項支援還能增進系統的可用性。

Windows Server 2003 包含熱新增記憶體,可讓具有動態記憶體支援的伺服器在系統管理員新增 RAM 時使用它。Windows Server 2008 進一步擴充此動態記憶體支援,讓您可以替換記憶體。

越來越依賴錯誤修正碼 (ECC) 修正的 RAM 會面臨全體失敗的風險,因此在具有熱替換支援的伺服器上,Windows Server 2008 可以明確地從失敗的記憶庫移轉資料到替換記憶體。這麼做的方法是先移轉由作業系統控制的資料,然後讓硬體裝置轉為低電源狀態來有效關閉這些裝置,接著重新啟動裝置電源來繼續正常操作。

Windows Server 2008 也支援處理器的熱新增和熱替換。就熱替換而言,硬體必須支援備用 CPU 的概念,當現有 CPU 產生失敗指示,備用 CPU 可以開始上線或動態加入,目前只有高階系統才做得到。Windows Server 2008 排程器減緩失敗 CPU 上的活動,並將工作移轉到替換 CPU,接下來就可以移除失敗的 CPU 並替換成新的備用 CPU。

支援處理器熱新增的 Windows Server 2008 可讓系統管理員升級伺服器的處理能力,同時避免停機時間。然而,排程器和 I/O 系統只讓要求 CPU 抵達通知透過新 API 的裝置驅動程式和應用程式使用新 CPU,因為某些應用程式內已假設開機工作階段的 CPU 數目是固定的。舉例來說,應用程式可以配置與各個 CPU 對應的工作佇列陣列,其中的執行緒將使用執行緒執行所在之 CPU 的相關佇列。如果排程器將其中一個應用程式執行緒放置到新的 CPU 上,它會嘗試參考不存在的佇列,這有可能會損壞應用程式的資料,更有可能會使應用程式損毀。

以 Microsoft 伺服器為基礎的應用程式 (如 SQL Server 和 Exchange Server) 都具有新增 CPU 功能,還有一些核心 Windows 處理程序,包括系統處理程序、工作階段管理員 (%SystemRoot%\System32\Smss.exe,) 和 Generic Service Hosting 處理程序 (%Systemroot%\System32\Svchost.exe) 也都具備此功能。其他處理程序也可能要求使用 Windows API 來提出新 CPU 抵達通知。當新的 CPU 抵達時,Windows 會通知裝置驅動程式 CPU 即將抵達,啟動 CPU,然後通知寫入的裝置驅動程式應用程式來利用新的 CPU,以便在必要時配置資料結構來追蹤新 CPU 上的活動。

機器虛擬化

在 Windows Server 2008 之前,Microsoft 虛擬化產品 (包括 Virtual Server 2005) 都是使用裝載虛擬化實作而成,如 [圖 5] 所示。在裝載虛擬化中,虛擬機器是透過 Virtual Machine Monitor (VMM) 進行實作,此 VMM 通常是以裝置驅動程式的身分在主機作業系統旁邊執行。VMM 仰賴主機作業系統的資源管理和裝置驅動程式,當主機作業系統排程 VMM 執行時,它會在使用中虛擬機器 (VM) 間建立 CPU 的時間配量。

[圖 5] 裝載機器虛擬化

[圖 5]** 裝載機器虛擬化 **(按影像可放大)

Hyper-V (原先代號為「Viridian」) 使用 Hypervisor 虛擬化技術來實作。Hypervisor 完全控制所有硬體資源,即使是啟動系統並讓您由此控制 VM 的 Windows Server 2008 作業系統本質上也是在虛擬器上執行,請參閱 [圖 6]

[圖 6] Hyper-V 架構

[圖 6]** Hyper-V 架構 **(按影像可放大)

Hypervisor 可以將系統分割成多個 VM,並將 Windows Server 2008 的開機執行個體視為主磁碟分割或根磁碟分割,以便直接存取硬體裝置,例如磁碟、網路卡和圖形處理器。Hypervisor 預期根磁碟分割會執行電源管理和回應硬體隨插即用事件。它會攔截在子磁碟分割上啟動的硬體裝置 I/O,將其路由到根磁碟分割,而根磁碟分割會使用標準 Windows Server 2008 裝置驅動程式來執行硬體存取。依照這種方式,執行 Hyper-V 的伺服器就能善用 Windows 對於硬體裝置的支援。

當您在 Windows Server 2008 中設定 Hyper-V 伺服器角色時,Windows 會將 hypervisorimagelaunchtypeboot 開機設定資料庫 (BCD) 設定設為 auto,並將 Hvboot.sys 裝置驅動程式設為在開機程序中早期啟動。若已設定選項,Hvboot.sys 便會準備好系統進行虛擬化,接著分別根據系統實作 AMD-V 或 Intel VT CPU 虛擬化延伸模組,將 %Systemroot%\System32\Hvax64.exe 或 %Systemroot%\System32\Hvix64.exe 載入到記憶體。

一旦載入之後,Hypervisor 使用虛擬化延伸模組將自己插入到 Windows Server 2008 底下。使用者模式應用程式使用 x64 處理器的核心第 3 級 (Ring 3) 權限層級,而核心模式程式碼於核心第 0 級 (Ring 0) 執行,因此 Hypervisor 是在概念權限層級 Ring 減 1 下操作,因為它能控制在核心第 0 級 (Ring 0) 中執行的程式碼執行環境。

當您使用 Hyper-V 管理主控台來建立或啟動子磁碟分割時,它會使用 %Systemroot%\System32\Drivers\Winhv.sys 驅動程式與 Hypervisor 進行通訊,這個驅動程式是利用公開記載的 Hypercall API 來引導 Hypervisor 建立特定實體記憶體大小與執行特性的新磁碟分割。根磁碟分割內的 VM 服務 (%Systemroot%\System32\Vmms.exe) 就是針對每個子磁碟分割建立 VM 工作者處理序 (%Systemroot%\System32\Vmwp.exe) 來管理子磁碟分割狀態的服務。

Windows 用來提升子 VM 作業系統效能的方法之一,就是 Windows Server 2008 與 Windows Vista 都實作 Enlightenment,這是只有當作業系統在實作 Microsoft Hypercall API 的 Hypervisor 上執行時才會啟動的程式碼順序。藉由直接要求 Hypervisor 的服務,子 VM 可避免當 Hypervisor 必須猜測子作業系統目的時可能產生的虛擬化程式碼負載。

譬如說,未針對單一執行緒存取鎖 (用來執行低階多處理器同步處理) 實作 Enlightenment 的虛擬作業系統,會直接向內微調緊密迴圈以等候其他虛擬處理器釋放單一執行緒存取鎖。微調動作可能會繫結其中一個硬體 CPU,直到 Hypervisor 排程第二個虛擬處理器。在啟蒙的作業系統中,單一執行緒存取鎖程式碼會透過 Hypercall 通知 Hypervisor 它將反向微調,好讓 Hypervisor 可以立即排程另一個虛擬處理器並減少浪費的 CPU 使用率。

Windows Server 2008 提高 VM 效能的另一種方法是加速 VM 對裝置的存取。經由安裝元件集合 (統稱為「VM 整合元件」) 到子作業系統,即可增強效能。

如果您在未安裝整合元件的情況下執行 VM,子作業系統會針對 Hypervisor 所提供的模擬裝置來設定硬體裝置驅動程式。當裝置驅動程式嘗試接觸硬體資源時,Hypervisor 必須介入以便告知根磁碟分割,而根磁碟分割會代表子 VM 的作業系統使用標準的 Windows 裝置驅動程式來執行裝置 I/O。由於單一的高階 I/O 作業,例如從磁碟讀取,可能涉及許多個別的硬體存取,因此可能會對 Hypervisor 與根磁碟分割引發很多轉換動作,稱為攔截。

Windows Server 2008 使用以下三個元件來盡量減少攔截次數:虛擬機器匯流排驅動程式 (Virtual Machine Bus Driver,%Systemroot%\System32\Drivers\Vmbus.sys)、虛擬服務用戶端 (Virtual Service Client,VSC) 和虛擬服務提供者 (Virtual Service Provider,VSP)。當您將整合元件安裝到具有支援作業系統的 VM 時,VSC 會接手裝置驅動程式的角色,並在子 VM 中使用 Vmbus.sys 驅動程式的服務,透過 Hypercall 與 Hypervisor 的記憶體共用服務,在根磁碟分割中傳送高階 I/O 要求到虛擬機器匯流排驅動程式 (Virtual Machine Bus Driver)。在根磁碟分割中,Vmbus.sys 轉送要求到對應的 VSP,VSP 接著會利用根磁碟分割的裝置驅動程式來啟動標準 Windows I/O 要求。

如您所見,Windows Server 2008 引入以 Hyper-V Hypervisor 為基礎的虛擬化技術,因而在 Microsoft 機器虛擬化策略中扮演舉足輕重的角色。如需這些功能和其他功能的詳細資訊,請參閱下一期敝作《Microsoft Windows Internals》(預定將在今年下半年發行)。

Mark Russinovich 是 Microsoft 平台服務事業群 (Platform and Services Division) 的技術人員。他是《Microsoft Windows Internals》(Microsoft Press,2004 年) 的共同執筆者,經常在 IT 和開發人員會議上發表演說,包括 Microsoft TechEd 和專業開發人員大會 (Professional Developer's Conference)。身為 Winternals Software 公司的共同創辦人,隨著 Microsoft 併購該公司,Mark 也一同加入 Microsoft。他也創立了 Sysinternals,並在該公司發行許多受歡迎的公用程式,包括 Process Explorer、Filemon 和 Regmon。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利;未經允許,嚴禁部分或全部複製.