顯示具有 Windows 標籤的文章。 顯示所有文章
顯示具有 Windows 標籤的文章。 顯示所有文章

前言

簡單來說,每次微軟發佈安全性更新後,過不久便會有惡意人士產生攻擊工具來嘗試侵入未進行安全性更新的主機。這次,便是針對上個月 Microsoft 發佈 (Microsoft Security Bulletin MS17-010 - Ctitical) 針對 SMB (Server Message Block) 通訊協定的漏洞攻擊。



台灣受害主機數量已達第 2 名

根據網路安全公司 Below0Day,所發佈的部落格文章 DoublePulsar Global Implants: On the rise? 統計結果可以看到,在 4 月 18 日的掃描結果中在網際網路上共有 5,502,460 台主機開啟 Port 445,並且在其中檢查到共有 30,626 台主機已經偵測到遭受 DoublePulsar 攻擊。可以看到台灣名列遭受 DoublePulsar 攻擊數量第 3 名,共有 2,323 台主機遭受 DoublePulsar 攻擊成功。

圖、4 月 18 日全球遭受 DoublePulsar 攻擊分佈圖

圖、全球遭受 DoublePulsar 攻擊分佈圖 (台灣名列第 3 名)

接著,他們再次於 4 月 21 日的掃描,發現在網際網路上共有 5,190,506 台主機開啟 Port 445,並且在其中檢查到共有 56,586 台主機已經偵測到遭受 DoublePulsar 攻擊 (短短 3 天受感染主機數量已提升 25,960 台主機)。可以看到台灣名列遭受 DoublePulsar 攻擊數量升高至第 2 名,共有 5,217 台主機遭受 DoublePulsar 攻擊成功 (短短 3 天受感染主機數量已提升 2,894 台主機)。

圖、4 月 21 日全球遭受 DoublePulsar 攻擊分佈圖

圖、全球遭受 DoublePulsar 攻擊分佈圖 (台灣名列第 2 名)



安裝 KB 3150513

簡單來說,請先盡速透過 Windows Update 安裝 Microsoft KB 3150513 安全性更新,或至 Microsoft Update Catalog 下載及安裝 Microsoft KB 3150513 安全性更新。

圖、至 Microsoft Update Catalog 下載 KB 3150513 安全性更新

圖、確認主機已安裝 KB 3150513 安全性更新

當然,並非安裝 KB 3150513 安全性更新便可以高枕無憂。還是老話一句,安全與便利永遠是天秤的二個拉址點,一旦主機連線至網際網路就沒有絕對的安全 (即便未連線至網際網路也沒有絕對的安全性),這場攻防之間的戰爭只要有利益可圖就沒有停止的一天。👿



參考資源


前言

簡單來說,在新一代 Windows Server 2016 雲端作業系統中,倘若 IT 管理人員需要透過 S2D (Storage Spaces Direct) 技術建構 SDS 軟體定義儲存環境。在相關教學文章及影片中,你應該會不斷看到強調支援「RDMA (Remote Direct Memory Access)」技術,主要原因在於 RDMA 技術能夠有效「降低 S2D 叢集節點 CPU 工作負載」同時「降低延遲時間」

然而,大家對於 RDMA 運作環境相對陌生,因此許多 IT 管理人員一開始的困惑便是,那麼「不支援」RDMA 的環境能否運作 Windows Server 2016 的 S2D 技術? 答案是,S2D 即便在不支援 RDMA (走一般的 TCP/IP 乙太網路) 的環境下仍能正常運作。



測試環境及測試工具

微軟官方採用同一批軟硬體環境,並且進行「RDMA Enabled」以及「RDMA Disabled」的測試,同時整理出 2 種運作環境的儲存效能,以便 IT 管理人員能夠了解這 2 種運作環境之間的效能差異。

測試環境 (4 Nodes S2D Cluster)

下列為 4 Nodes S2D Cluster 測試環境中,每台 S2D 叢集節點主機的硬體配置:
  • Host: Intel S2600WT Platform
  • CPU: E5-2699 v4 2.2 GHz *2 (每顆 22 Cores / 44 執行緒)。
  • Memory: 128 GB DDR4
  • SSD: Intel P3700 NVMe *4
  • NIC: Mellanox CX3 Pro 40Gb (Dual Port, RoCE v2)
  • BIOS: Power Performance Plan、C States Disabled、Turbo Enabled、HT Enabled。
  • OS: Windows Server 2016、S2D (Storage Spaces Direct)、High Performance Power Plan。
  • S2D Volume: 3-Way Mirror。

測試工具

  • DISKSPD
  • 4K 100% Random I/O (70% Read / 30% Write)。
  • 10 Threads (Queue Depth 4 per Thread,Total is 40)。
  • 10 GB file per Thread (Total is 100 GB)。

測試結果

下列圖表便是分享整理「RDMA Enabled」「RDMA Disabled」的測試結果,歸納重點如下:
  • 倘若,你希望 S2D 有良好的儲存效能表現。那麼,你應該要讓 S2D 運作在 RDMA Enabled 環境。
  • 此次的實作環境中 RDMA Enabled,能夠提升 28% IOPS、27% CPU 效能、36% Write Latency、28% Read Latency
  • 即便是 RDMA Disabled 環境 (TCP/IP 乙太網路),仍能夠提供 145,500 IOPS 的儲存效能。



此外,也可以參考去年 Microsoft Ignite 2016 大會中 BRK3088 - Discover Storage Spaces Direct, the ultimate software-defined storage for Hyper-V 議程。


在該議程中的測試環境,也有分別測試「RDMA Enabled」「RDMA Disabled」的效能測試結果 (節省 1/3 的 CPU 工作負載、達到提升 2 倍的 IOPS 效能表現):





參考資源



網管人雜誌

本文刊載於 網管人雜誌第 135 期 - 2017 年 4 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。



文章目錄

前言
何謂 PtH 與 PtT 攻擊?
什麼是 Credential Guard?
          Credential Guard 環境需求
實戰 Credential Guard
          未啟用 Credential Guard
          啟用 Credential Guard
          確認 Credential Guard 安全性機制執行中
          測試 Credential Guard 防護機制
結語





前言

過去,雖然企業及組織在整個 IT 基礎架構中,已經部署許多增強安全性的相關運作機制或硬體設備,除了確保線上營運服務不停止之外也保護企業機敏資料不外洩,然而隨著時間的推移駭客攻擊企業及組織的方法也不斷演變及翻新,惡意攻擊的方式也從過往正面對決改採潛伏並轉而朝向最弱環節下手。簡單來說,相較於企業及組織內強調高安全性高效能的線上營運伺服器來說,惡意攻擊方式則改為朝向安全防護相對薄弱的使用者端電腦下手。

在現代化 IT 基礎架構中,為了達到統一且集中式管理的使用者身分驗證機制,在企業及組織當中便會建置目錄服務以達成「單一登入」(Single Sign On,SSO)的目的,一般來說較廣為採用的目錄服務有 Active Directory、OpenLDAP……等,以便使用者只要登入並通過使用者身分驗證機制之後(也就是通過所謂的 3A 程序),那麼就能順利存取企業及組織內部中各式各樣的服務了。
所謂 3A 程序便是指驗證(Authentication)、授權(Authorization)、稽核(Accounting)。簡單來說,「驗證」是指系統能夠正確識別登入的使用者帳號是代表誰,而「授權」則是負責確認使用者登入後能否啟用或執行某項工作任務,至於「稽核」則是追踪使用者在登入後的各項操作及使用情況並進行記錄。

圖 1、現代化 IT 運作架構中,使用者必須存取各式各樣的應用服務才能滿足需求





何謂 PtH 與 PtT 攻擊?

雖然,企業及組織透過目錄服務達到 SSO 單一登入,讓使用者只要通過使用者身分驗證程序後便能使用區網內的各項服務。然而,在資訊攻防上面「操作便利性」與「安全性」永遠處於天秤之間不同的兩端,因此針對 SSO 單一登入的惡意攻擊方式便應運而生,也就是大家耳熟能詳的「傳遞雜湊」(Pass-the-Hash,PtH)「傳遞票證」(Pass-the-Ticket,PtT)攻擊。

在本文一開始,我們曾經提到現代化的惡意攻擊方式,已經改為朝向安全防護相對薄弱的使用者端電腦下手,舉例來說,典型的 PtH / PtT 惡意攻擊方式,便是由惡意攻擊者先透過惡意電子郵件、惡意網站、使用者端已經發佈或尚未修補的漏洞……等方式,進而取得使用者端主機的管理者權限。

接著,惡意攻擊者便會利用取得的管理者權限,從使用者電腦主機硬碟內的 Windows 作業系統中,讀取 SAM Database 內容以便取得使用者密碼的雜湊值,或者透過取得的管理者權限直接讀取儲存於記憶體中的「認證」(Credentials)資訊。

圖 2、典型的傳遞雜湊及傳遞票證攻擊方式(第一階段)

可能會有讀者感到困惑,即便惡意攻擊者取得使用者端主機的管理者權限,一般來說使用者在企業及組織的 Active Directory 網域環境中,通常僅具備一般網域使用者權限而已理論上危害範圍不致過大才對。是的,取得一般使用者端電腦主機的管理者權限,通常只是惡意攻擊方式的第一階段,接下來我們將要討論惡意攻擊的第二階段。

在上述的範例情境中,惡意攻擊者已經取得企業及組織中某台使用者端主機的管理者權限,接著便會透過攻擊成功所偷來的認證資訊,嘗試假冒這位使用者的身分再去攻擊區域網路中其它使用者端主機。倘若,使用者端主機的管理者帳號(例如,本機 Administrator),在區域網路中其它使用者端主機也採用「相同」的密碼時,因為 NT 密碼雜湊是採用未加密的 MD4 雜湊演算法,所以惡意攻擊者便可以橫向的輕易侵入其它台使用者端主機。

接著,惡意攻擊者將採用上述相同的入侵手法不斷攻擊區網中其它台使用者端主機,同時嘗試取得 Active Directory 網域環境中,權限等級更高的特權帳號或服務帳號。倘若,剛好使用者端主機發生其它問題請 MIS 人員協助處理,然而 MIS 人員為求方便而使用 Active Directory 網域特權帳號登入時,那麼惡意攻擊者便能進而取得儲存於使用者端記憶體內的網域特權帳號密碼。

一旦被惡意攻擊者取得 Active Directory 網域特權帳號(例如,Domain Administrator),或其它具有相同權限等級的使用者帳號時,那麼惡意攻擊者便具有 Active Directory 網域的管理權限,並且還能更進一步危害與此網域信任的其它網域。

即便惡意攻擊者無法取得 Active Directory 網域特權帳號,仍然可以透過由一般使用者端主機所偷到的使用者權限,針對企業及組織 IT 基礎架構中相關服務進行存取,舉例來說,假冒該使用者帳號存取檔案伺服器內的檔案,導致企業及組織的機敏資料外洩等資安事件。

圖 3、典型的傳遞雜湊及傳遞票證攻擊方式(第二階段)





什麼是 Credential Guard?

為了能夠有效阻擋使用者密碼遭受未經授權的認證竊取攻擊,從 Windows 10 及 Windows Server 2016 版本開始,導入新的安全性機制稱之為「Credential Guard」,它會使用虛擬式安全性的方式來隔離使用者帳號的密碼,因此只有具備特殊權限的系統軟體才能夠存取它們,同時透過保護 NTLM 密碼雜湊以阻擋傳遞雜湊攻擊,或保護 Kerberos 票證以阻擋傳遞票證這種未經使用者授權存取的認證竊取攻擊。
請注意,在 Windows 10 版本的部分,必須採用 Windows 10「企業版、教育版」才支援 Credential Guard 安全性功能。

在過去舊版的 Windows 作業系統中,會將登入的使用者帳號密碼儲存於「本機安全性授權」(Local Security Authority,LSA),而 LSA 會將作業系統所要使用的密碼儲存於處理程序記憶體當中。因此,惡意攻擊者只要透過偷到的管理者權限,便能查看處理程序記憶體當中所儲存,所有曾經登入過此台主機的使用者帳號及密碼。

現在,Credential Guard 安全性機制透過「虛擬式安全性」(Virtualization-Based Security,VBS)方式,將 LSA 中的密碼進行隔離並使用遠端程序呼叫的方式與新的運作元件溝通,隔離的 LSA 執行程序所儲存的資料由虛擬式安全性機制所保護,無法由作業系統其它的部分進行存取。簡單來說,VBS 提供安全核心與一般作業系統隔離的功能,所以不會暴露一般作業系統中的弱點及零時差漏洞。

因此,基於安全性考量隔離的 LSA 執行程序不會載入任何裝置驅動程式,只會載入安全性所需的作業系統「二進位檔案」(Binary File)而已,並且這些二進位檔案都使用虛擬化安全性信任的憑證所簽署的,這些簽章會先經過驗證程序並通過驗證後才會保護運作環境中的檔案。

圖 4、透過 VBS 虛擬式安全性運作機制隔離 LSA 的運作示意圖



Credential Guard 環境需求

在開始部署 Credential Guard 安全性機制之前,我們先了解部署 Credential Guard 機制所需要的軟體、硬體及韌體等環境需求。舉例來說,在硬體的部分建議採用具備「信賴平台模組」(Trusted Platform Module,TPM)的安全性晶片,但事實上若主機未配置或未支援 TPM 2.0 安全性晶片的話,仍然能夠啟用 Credential Guard 安全性機制,只是 Credential Guard 用來加密的安全性金鑰無法受到 TPM 安全性晶片保護,因此安全性防護力較弱仍有被攻擊成功的可能性。

基礎安全性保護環境需求
  • 硬體: 首先,必須採用具備「64 位元」的 CPU 處理器,並支援 Intel VT-x/EPT 或 AMD-V/NPT 等硬體輔助虛擬化功能,那麼 Windows Hypervisor 才能提供 VBS 虛擬化安全性機制。同時,建議配置「TPM 2.0」安全性晶片,以便為 VBS 加密金鑰提供保護及防範惡意存取 BIOS 等攻擊行為。
  • 韌體: 具備 UEFI 安全開機及韌體更新功能的「UEFI 2.3.1.c 或後續版本」,透過 UEFI 安全開機以確保裝置只會使用已授權的程式碼開機,並配合韌體更新機制修補安全性弱點,以便充分防止主機遭受 Bootkit 及 Rootkit 攻擊行為。
  • 軟體: Windows 10 僅「企業版、教育版」支援、Windows Server 2016 及 Windows Enterprise IoT。

請注意,倘若 Windows Server 2016 運作 DC 網域控制站的話,那麼便不支援 Credential Guard 安全性機制,僅支援另一項安全性機制 Device Guard 而已。

事實上,上述僅列出 Credential Guard 安全性機制的基礎環境需求而已,倘若企業及組織需要更高等級的安全性機制時,那麼建議可以採用上述基礎環境需求搭配下列進階安全性保護環境需求,即可大幅增強 Credential Guard 可提供的安全性等級。

進階安全性保護環境需求
  • 硬體: 採用支援「Intel VT-D 或 AMD Vi IOMMU」硬體輔助虛擬化功能,以便增強系統對於記憶體攻擊的抵擋及復原能力。
  • 韌體: 採用支援「Secure Boot」、「Secure MOR」、「HSTI」、「WSMT」……等,確保只有經過驗證的平台 BIOS 系統管理員可以變更 BIOS 設定,並且防止進階記憶體攻擊、抵擋惡意程式碼、從系統韌體減少 VBS 的受攻擊面、封鎖其它針對 SMM 的安全性攻擊 ……等。





實戰 Credential Guard

了解 Credential Guard 安全性機制的運作原理及環境需求後,接下來首先為讀者展示倘若主機未啟用 Credential Guard 安全性機制,但是遭受傳遞雜湊及傳遞票證攻擊時將會發生什麼情況,接著將實際演練如何啟用 Credential Guard 安全性機制,以及啟用後該如何確認 Credential Guard 安全性機制已經正確運作。在啟用 Credential Guard 安全性機制的部分,可以採用 GPO 群組原則、修改登錄檔、Device Guard 及 Credential 硬體準備工具……等方式來進行啟用作業。



未啟用 Credential Guard

那麼,我們來嘗試模擬在未啟用 Credential Guard 安全性機制之前,當 Windows 10 及 Windows Server 2016 作業系統,遭受本文所描述的傳遞雜湊及傳遞票證攻擊時會發生什麼情況。在本文測試環境中,我們採用由法國知名駭客 Benjamin Delpy 透過 C 語言所撰寫的 Mimikatz 工具 ,模擬傳遞雜湊及傳遞票證身分竊取攻擊行為。

值得注意的是,在 Windows 10 及 Windows Server 2016 作業系統運作環境中,請在下載及執行 Mimikatz 工具之前,將預設內建的「Windows Defender」防毒防駭工具關閉,否則一旦下載 Mimikatz 工具後便會立即被 Windows Defender 移除。

圖 5、關閉 Windows 預設內建的 Windows Defender 防毒防駭工具

順利關閉內建的 Windows Defender 防毒防駭工具後,請透過「以系統管理員身分執行」的方式開啟命令提示字元,接著執行 Mimikatz 工具後首先鍵入「Privilege::Debug」指令,以便確認 Mimikatz 工具已正常啟動並能順利運作,接著鍵入「sekurlsa::msv」「sekurlsa::logonpasswords」便會列出,在這台主機中 LSA 儲存於記憶體內所有登入過的使用者帳號或服務帳號的密碼資訊。

如圖 6 所示在順利執行 Mimikatz 工具後,可以看到目前的主機名稱為 HV01,登入的管理者帳號 Administrator 以及管理者帳號的 SID,在下方便直接看到管理者帳號的 NTLM 雜湊值,也就是本文一開始提到 NT 密碼雜湊採用未加密的 MD4 雜湊演算法。
倘若採用的是 Windows 10 或 Windows Server 2016 之前的版本,那麼透過 Mimikatz 工具甚至「直接」看到密碼為「明文」而非 NTLM 雜湊值。
圖 6、透過 Mimikatz 工具查看主機記憶體內容中所有使用者帳號密碼資訊

或許有些讀者會感到困惑,透過 Mimikatz 工具看到管理者帳號的 NTLM 雜湊值會有什麼影響 ?事實上,隨著惡意攻擊種類及方式不斷增加的情況下,只要取得使用者帳號的 NTLM 雜湊值之後,惡意攻擊者只要透過「NTLM 雜湊值解密程式」(NTLM Hash Decrypter),便可以在幾小時甚至幾分鐘之內解密出使用者密碼。
原則上密碼字元在 8 字元以下普通強度的使用者密碼,只要幾分鐘之內便可以順利解密。即便密碼字元在 14 字元並採用高強度的使用者密碼,也只要幾小時之內便可以順利解密。



啟用 Credential Guard

了解惡意攻擊所造成的安全性風險後,接著我們來看看啟用 Credential Guard 安全性機制後,是否能夠有效防護傳遞雜湊及傳遞票證攻擊。在此次實作的 x86 伺服器中,硬體的部分採用 64 位元的 CPU 處理器並支援相關硬體輔助虛擬化功能,同時也配置 TPM 2.0 信賴平台模組安全性晶片。在韌體的部分,採用具備 UEFI 安全開機及韌體更新功能的 UEFI 2.4.0。在軟體的部分,則是採用 Windows Server 2016 DataCenter 版本。

圖 7、順利在裝置管理員中看到信賴平台模組 2.0

符合 Credential Guard 安全性機制的運作環境準備完畢後,在本文實作環境中我們採用 GPO 群組原則的方式啟用 Credential Guard。請依序點選「開始 > 執行 > 鍵入 gpedit.msc > 確定」,系統將會開啟本機群組原則編輯器視窗,接著請依序點選「電腦設定 > 系統管理範本 > 系統 > Device Guard」項目,然後開啟右方「開啟虛擬化型安全性」項目。

圖 8、準備透過 GPO 群組原則啟用 Credential Guard 安全性機制

在開啟虛擬化型安全性視窗中,預設值為尚未設定請點選至「已啟用」項目,接著在下方選取平台安全性層級下拉式選單中,可以看到安全開機或安全開機及 DMA 保護項目,在本文實作環境中選擇至「安全開機」項目。最後,在 Credential Guard 設定下拉式選單中,預設值為已停用另外 2 個選項為在不含鎖定情況下啟用、在包含 UEFI 鎖定的情況下啟用,在本文實作環境中選擇至「在不含鎖定情況下啟用」項目。
在選取平台安全性層級選項中,倘若選擇至「安全開機及 DMA 保護」項目的話,那麼請確保主機必須支援「Intel VT-D 或 AMD Vi IOMMU」硬體輔助虛擬化功能才行。
圖 9、透過 GPO 群組原則啟用 Credential Guard 安全性機制

組態設定完畢回到本機群組原則編輯器視窗中,將會發現開啟虛擬化型安全性項目的狀態,由先前的「尚未設定」轉換成為「已啟用」。接著,為了能夠快速讓組態設定套用生效,請開啟以系統管理員身份開啟命令提示字元後,鍵入「gpupdate /force」指令然後重新啟動主機。



確認 Credential Guard 安全性機制執行中

順利啟用 Credential Guard 安全性機制並重新啟動主機後,首先請確認 Credential Guard 安全性機制已經順利運作並執行中,請依序點選「開始 > 執行 > 鍵入 msinfo32.exe > 確定」,系統將會開啟系統資訊視窗,點選「系統摘要」項目後在右方窗格中下拉至底即可看到啟用資訊,依據本文實作環境的組態設定後,在啟用 Credential Guard 安全性機制的部分將會看到下列組態設定值:

  • Device Guard 虛擬化型安全性: 執行中
  • Device Guard 必要的安全性屬性: 基底虛擬化支援,安全開機
  • Device Guard 可用的安全性屬性: 基底虛擬化支援,安全開機,DMA 保護
  • Device Guard 安全性服務已設定: Credential Guard
  • Device Guard 安全性服務執行中: Credential Guard

圖 10、確認 Credential Guard 安全性機制是否順利啟用並執行中

倘若最後一項「Device Guard 安全性服務執行中」空白的話,可以稍等 2 ~ 3 分鐘後重新整理視窗內容,倘若仍為空白的話建議再次重新啟動主機,以確保 Credential Guard 安全性機制啟用並執行中。



測試 Credential Guard 防護機制

確認 Credential Guard 安全性機制順利運作後,在執行 Mimikatz 工具再次模擬惡意攻擊行為之前請再次確認,是否已經關閉內建的 Windows Defender 防毒防駭工具。
因為預設情況下,重新啟動 Windows 主機之後,將會自動帶起 Windows Defender 防毒防駭工具。

一切準備就緒後,請透過「以系統管理員身分執行」的方式開啟命令提示字元,接著執行 Mimikatz 工具以便再次模擬惡意攻擊行為。同樣的,請先鍵入「Privilege::Debug」指令,以便確認 Mimikatz 工具已正常啟動並能順利運作,接著鍵入「sekurlsa::msv」「sekurlsa::logonpasswords」指令,便會列出此台主機中 LSA 儲存於記憶體內的使用者帳號或服務帳號的密碼資訊。

但是,這台主機已經受到 Credential Guard 安全性機制的保護,所以可以看到 Mimikatz 工具執行後,仍然可以看到目前的主機名稱為 HV01,登入的管理者帳號 Administrator 以及管理者帳號的 SID,但是這次在下方便可以看到有一行關鍵字「LSA Isolated Data:NtlmHash」,然後原本應該顯示 NTLM 雜湊值的部份,變成「Unk-Key」「Encrypted」2 行經過加密金鑰保護的亂數,順利阻擋傳遞雜湊及傳遞票證惡意攻擊行為。

圖 11、Credential Guard 安全性機制順利運作及阻擋惡意攻擊

值得注意的是,惡意攻擊的方式及手法隨著時間的推移不斷翻新,因此管理人員並非只要啟用 Credential Guard 安全性機制就能高枕無憂,舉例來說,企業及組織的 IT 管理人員,已經為區網中的伺服器及使用者端主機啟用 Credential Guard 安全性機制,然而使用者端主機卻因為遭受社交攻擊而被植入鍵盤記錄木馬程式時,那麼即便啟用 Credential Guard 安全性機制也是無法防護的,因為惡意攻擊者將可以透過植入的鍵盤記錄木馬程式,輕鬆且直接獲得使用者所鍵入的密碼。





結語

透過本文的說明及實作演練,相信讀者已經完全了解在 Windows 10 及 Windows Server 2016 環境中,新增的 Credential Guard 安全性機制,確實能夠阻擋傳遞雜湊及傳遞票證惡意攻擊,有效提升儲存於主機記憶體內的使用者密碼防護力。

前言

在去年 Microsoft Ignite 2016 大會上,在 Meet Windows Server 2016 and System Center 2016 議程中展示 S2D (Storage Spaces Direct) 的儲存效能表現。在當時展示的運作環境中,每台 S2D 叢集節點配置的是 Chelsio T580CR 40GbE (iWARP) 網路介面卡,整個 S2D 叢集共有 16 台節點主機,最後打出高達「600 萬 IOPS」的儲存效能表現。




S2D 支援 10 / 25 / 40 / 100 GbE 網路環境

現在,Microsoft S2D 軟體定義儲存技術已經支援 10 / 25 / 40 / 100 GbE 網路環境。同時,Chelsio 也已經發行 T6 系列 100GbE 的網路介面卡。




S2D 使用 100GbE iWARP 的儲存效能輸送量

因此,Microsoft 官方也為 S2D 叢集節點主機配置 Chelsio T6 100GbE 網路介面卡,來測試在這樣的網路環境中 S2D 的儲存效能輸送量為多少。下列便是此次的 S2D 測試環境說明:

4 台 S2D 叢集節點主機 (Dell R730xd),每台硬體配置如下:

  • CPU: E5-2660 v3 2.60 GHz *2 (每顆 10 Cores / 20 執行緒)。
  • Memory: 256 GB DDR4 2133 MHz (16 GB * 16 DIMM)。
  • Storage: 3.2TB NVME Samsung PM1725 *4 (PCIe 3.0 x8)。
  • NIC: Chelsio T6 100GbE (Dual Port PCIe 3.0 x16)。
  • Cabling: QSFP28 Passive Copper Cabling。
  • BIOS Power: Performance Power Plan
  • OS: Windows Server 2016、S2D (Storage Spaces Direct)、High Performance Power Plan。
  • DCB 組態設定: 因為採用的 Chelsio T6 100GbE 為 RDMA 中的 iWARP,所以無須組態設定 DCB (PFC)。

工作負載

  • DISKSPD
  • VM Fleet
  • 80 VMs (16 GB VHDX),每台 S2D 叢集節點運作 20 Azure A1 Sized VMs (1 vCPU、1.75 GB RAM)。
  • 512 KB 100% Random Read (每台 VM 的 Queue Depth 為 3)。


IOPS 輸送量效能測試結果

下列便是採用 VMFleet 進行 IOPS 輸送量效能測試結果,從結果數據中可以看到總頻寬輸送量高達「83 GB/s」,也就是說每台 VM 虛擬主機使用超過 1GB/s 的輸送量,同時整個 Read Latency 也「< 1.5 ms」




參考資源


[2017/3/14 Update] 上傳活動照片及簡報

活動簡介

根據知名市調機構 Gartner 的統計調查結果,從 2016 年開始有「2/3 以上」的企業及組織,將開始建構及整合「Mode 2」的敏捷式 IT 基礎架構,所謂「基礎架構敏捷化」(Infrastructure Agility),便是著重於 IT 基礎架構中「Mode 2」的部分以便因應商業數位化的需求。

此外,根據 Gartner 的預測,在 2017 年時全球大型企業中將有高達「75 %」的比例,會建立 Mode 1 及 Mode 2 的雙重 IT 基礎架構稱之為「Bimodal IT」。在傳統 Mode 1 當中的工作負載、技術、流程、部署模式已經行之有年無須再驗證,但 Mode 2 是新興的方式並在根本上與 Mode 1 不同,它強調的是「敏捷性」(Agility)「可擴充性」(Scalability)以提高開發人員的生產力,達到快速推出新服務的一種方式,舉例來說,「容器」(Container)技術可以幫助開發人員達到更好的敏捷性。簡單來說,傳統的 Mode 1 運作架構專注於「基礎架構管理」,而新興的 Mode 2 則是專注於「工作負載為中心」。

在本次聚會中將快速與大家討論及實作,如何透過 Microsoft Azure 公有雲環境,快速建立 ubuntu、CentOS、FreeBSD 虛擬主機,並且安裝及建立 Docker 容器測試環境。同時,也將實作及展示 Windows Server 2016 Container 容器環境。



活動資訊



活動照片及簡報

對於今天無法到場參與 Live Hands-On 及討論的朋友,可以參考看看今天議程的簡報。😎





課程簡介

  • 熟悉雲端運算定義 五種服務特徵、四種部署模型、三種服務類型。
  • 針對建置企業私有雲網路環境時,該如何規劃 VM 虛擬主機的各種傳輸流量,如 VM 網路服務流量、高可用性遷移流量、容錯移轉流量…等以避免造成傳輸瓶頸。
  • 從針對不同儲存設備類型特性的認識,到私有雲運作環境該如何規劃及計算儲存設備 IOPS 效能,以避免資料傳輸瓶頸產生 VM 虛擬主機運作效能不佳的情況。



課程資訊

日期: 2017/4/29 ~ 2017/6/17
時間: 每週六 09:00 ~ 12:00、13:30 ~ 16:30
地點: 國立臺北商業大學 (臺北市中正區濟南路一段321號)
網址: Hyper-V 私有雲規劃與建置實務班



網管人雜誌

本文刊載於 網管人雜誌第 133 期 - 2017 年 2 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。





文章目錄

前言
實戰 Hyper-V 巢狀式虛擬化
          Guest Hypervisor 安裝 Hyper-V 角色
          Guest Hypervisor 啟用 MAC 位址變更機制
          Guest Hypervisor 啟用 NAT 機制
          Nested VM 再生 Nested VM?
結語





前言

在伺服器虛擬化運作環境中,談到「巢狀式虛擬化」(Nested Virtualization)的運作環境時,大家通常都會想到 VMware vSphere 虛擬化解決方案。沒錯,在過去的 Hyper-V 虛擬化平台當中,要建構出「巢狀式虛擬化」的運作環境,確實非常困難並且難以達成的。現在,透過最新發行的 Windows Server 2016 雲端作業系統,所建構的 Hyper-V 虛擬化平台便能原生內建支援「巢狀式虛擬化」運作機制。
事實上,從 Windows Server 2016技術預覽版本 4 的「10565」組建號碼開始,便原生內建支援巢狀式虛擬化機制。

簡單來說,在過去舊版 Hyper-V 虛擬化平台運作架構中,最底層 Hyper-V Hypervisor 虛擬化管理程序,將會完全管控「虛擬化擴充功能」(Virtualization Extensions)的部分,也就是如圖 1 所示中「橘色箭頭」的部分。同時,Hyper-V Hypervisor 並不會將底層硬體輔助虛擬化功能,傳遞給運作於上層的客體作業系統,所以在舊版的 Hyper-V 虛擬化平台上很難實作出巢狀式虛擬化的運作環境。

圖 1、舊版 Hyper-V 虛擬化平台運作架構(不支援巢狀式虛擬化)


現在,透過最新 Windows Server 2016 雲端作業系統所建置的 Hyper-V 虛擬化平台當中,Hyper-V Hypervisor 虛擬化管理程序,已經可以順利將「虛擬化擴充功能」也就是底層硬體輔助虛擬化技術,傳遞給 Hyper-V 虛擬化平台上運作的客體作業系統了。

因此,當 Hyper-V 虛擬化平台上運作的客體作業系統為 Windows Server 2016 時,因為能夠順利接收到由底層所傳遞過來的硬體輔助虛擬化技術,所以便能啟用 Hyper-V 虛擬化功能並建立 VM 虛擬主機,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
事實上,當客體作業系統運作 Windows 10 時,也能順利接收底層所傳遞過來的硬體輔助虛擬化技術,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
圖 2、新版 Hyper-V 虛擬化平台運作架構(支援巢狀式虛擬化)

此外,一般對於巢狀式虛擬化技術的認知,僅止於建立測試研發環境上具備方便度而已,通常在線上營運的運作環境中並不會使用到巢狀式虛擬化技術。然而,在新版 Windows Server 2016 中 Hyper-V 虛擬化平台支援巢狀式虛擬化技術,並非只是為了達到 Nested VM 這種 VM 虛擬主機再生出 VM 虛擬主機,方便建立測試研發環境的目的而已。

在新一代 Windows Server 2016 雲端作業系統運作環境中,同時支援 Windows Containers 及 Hyper-V Container 這 2 種容器技術運作環境,其中「Hyper-V Container」容器技術運作環境的部分,便是在 VM 虛擬主機中再運作 Container 容器環境,達到更進一步的容器技術隔離運作環境。事實上,Hyper-V Container 的容器技術運作環境,便是透過 Hyper-V 巢狀式虛擬化技術所達成的。

圖 3、Windows Containers 與 Hyper-V Containers 運作架構示意圖





實戰 Hyper-V 巢狀式虛擬化

在開始實作 Hyper-V 巢狀式虛擬化機制之前,我們先了解建立 Hyper-V 巢狀式虛擬化的運作環境需求以及相關限制:

Hyper-V 主機(Hyper-V Hypervisor)
  • 運作 Hyper-V 巢狀式虛擬化技術的實體伺服器,在 CPU 處理器硬體輔助虛擬化技術的部分,必須採用支援「Intel VT-x 及 EPT」虛擬化擴充功能的 CPU 處理器才行。
  • 作業系統的部分,必須採用 Windows 10 年度更新版(Enterprise、Professional、Education)或 Windows Server 2016(Standard、Datacenter)等版本。

VM 虛擬主機(Guest Hypervisor)
  • 必須採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式。
  • 作業系統的部分,必須採用 Windows 10年度更新版(Enterprise、Professional、Education)或 Windows Server 2016(Standard、Datacenter)等版本。
  • 必須「啟用」vCPU 虛擬處理器的虛擬化擴充功能,才能夠順利接收由底層 Hyper-V 虛擬化平台所傳遞的硬體輔助虛擬化技術。
  • 建議「停用」動態記憶體功能。雖然,啟用動態記憶體功能仍然不影響 VM 虛擬主機的運作,但倘若嘗試調整記憶體空間大小時(也就是執行 Runtime Memory Resize 的動作),將會發生失敗的情況。
  • 必須「啟用」MAC Address Spoofing 機制,或建立具備 NAT 功能的 vSwitch 虛擬網路交換器,否則屆時建立的 Nested VM 虛擬主機,將會發生無法與實體網路環境連通或連線至網際網路的情況。

上述 Hyper-V 巢狀式虛擬化的運作環境需求僅為大方向的重點規劃要項,下列將針對 Hyper-V 實體伺服器在 CPU 處理器及記憶體方面的選擇及規劃給予建議。

CPU 處理器的選擇
事實上,從 Windows Server 2008 R2 作業系統版本開始,Windows Server 便僅提供 64 位元的作業系統版本,當然 Windows Server 2012 和 2012 R2 以及新世代的雲端作業系統 Windows Server 2016 也不例外。因此,在選擇原生 64 位元的 CPU 處理器時,請選擇具備更多「定址空間」及具備大容量「L2 / L3 快取」空間的 CPU 處理器,甚至較新世代的處理器如 Intel Haswell、Broadwell 更支援 L4 快取,當擔任 Hyper-V 角色的硬體伺服器配置這樣的 CPU 處理器時,將能夠讓 Hyper-V 伺服器擁有更強大的運算資源。
請注意,雖然從 Windows Server 2008 R2 作業系統版本開始,Windows Server 便不再發行 32 位元版本,但是在原生 64 位元的 Windows Server 環境中運作 32 位元的應用程式,並不會有任何問題產生。

至於,在選擇 CPU 處理器時,應該選擇追求「高時脈」以得到高效能的運算速度,或者是著重在選擇「多核心」以達到平行運算,則應該視屆時運作於 Hyper-V 虛擬化平台上 VM 虛擬主機當中的工作負載類型而定,舉例來說,倘若 VM 虛擬主機當中的應用程式是屬於「單線程」(Single-Thread)類型的話,那麼便應該選擇採用「高時脈」類型的 CPU 處理器,倘若 VM 虛擬主機當中的應用程式是屬於「多線程」(Multi-Thread)類型的話,那麼便應該選擇採用「多核心」類型的 CPU 處理器,如此一來才能夠讓 VM 虛擬主機當中的工作負載得到最佳化的運算效能。

此外,在選擇 CPU 處理器硬體輔助虛擬化技術的部分,目前主流的 CPU 處理器皆已經支援第一代硬體輔助虛擬化技術(例如,Intel VT-x 或 AMD-V),以及第二代硬體輔助虛擬化技術或稱第二層位址轉譯 SLAT(例如,Intel EPT 或 AMD NPT),以便降低因為虛擬化技術所造成的硬體資源耗損。
請注意,在 Windows Server 2016 所建構的 Hyper-V 虛擬化平台中,倘若要建立 Hyper-V 巢狀式虛擬化運作環境的話,目前僅支援 Intel 處理器的硬體輔助虛擬化技術「Intel VT-x 及 EPT」,尚未支援採用 AMD 處理器「AMD-V 及 NPT」虛擬化擴充功能建立 Hyper-V 巢狀式虛擬化運作環境。

Memory 記憶體的選擇
在建構 Hyper-V 虛擬化平台的硬體伺服器上,針對實體記憶體的部分當然是越多越好。因為,當實體伺服器記憶體空間不足時,便會迫使 Windows Server 透過硬碟空間產生「分頁檔案」,以便嘗試渡過記憶體空間不敷使用的情況,此時將會直接影響並降低實體伺服器的運作效能。

倘若,因為 IT 預算的關係在短期之內真的無法購足實體記憶體時,則會建議應該依照如下準則來優化分頁檔案的運作效率:

  • 請將分頁檔案產生在實體隔離的硬碟環境,也就是不要跟作業系統或應用程式共用同一個硬碟空間。
  • 雖然將分頁檔案建立在具備容錯機制的硬碟空間中(例如,RAID 1),可能會導致更慢的儲存 I/O 效能,但是倘若將分頁檔案存放於「未」具備容錯機制的硬碟空間時,雖然會獲得較快的儲存 I/O 效能,然而一旦該硬碟發生災難事件時可能會導致「系統崩潰」的情況發生。
  • 請保持分頁檔案隔離原則,不要將「多個」分頁檔案同時建立在同一個硬碟內。

此外,應該要選擇支援 NUMA 架構的實體伺服器,以避免 CPU 處理器與記憶體之間的資料存取行為,因為匯流排頻寬不足的問題而產生存取瓶頸。值得注意的是,當採用支援 NUMA 架構的實體伺服器時,必須要注意實體記憶體空間必須平均分配到不同的 NUMA 節點,以避免 CPU 處理器仍需跨越 NUMA 節點進行記憶體空間的存取。

了解,上述 Hyper-V 伺服器在 CPU 處理器及記憶體的選擇規劃,以及實作 Hyper-V 巢狀式虛擬化的運作環境需求及限制等準則之後,接著便可以開始實作 Nested VM 巢狀式虛擬化運作環境。



Guest Hypervisor 安裝 Hyper-V 角色

首先,我們在實體伺服器所建構的 Hyper-V 虛擬化平台中,建立擔任 Guest Hypervisor 角色名稱為「WS2016-Outer」的 VM 虛擬主機,同時採用「第 2 世代」以及新版「8.0」的 VM 虛擬主機格式,在客體作業系統的部分則是採用 Windows Server 2016 DataCenter 版本。

圖 4、建立擔任 Guest Hypervisor 角色的 VM 虛擬主機

登入 WS2016-Outer 虛擬主機之後,我們可以直接開啟伺服器管理員並嘗試安裝 Hyper-V 伺服器角色,然而你會發現當你勾選「Hyper-V」伺服器角色項目後,在系統執行檢查程序完畢時將會出現「無法安裝 Hyper-V:處理器沒有必要的虛擬化功能」的錯誤訊息。

圖 5、擔任 Guest Hypervisor 角色的 VM 虛擬主機,無法順利安裝 Hyper-V 伺服器角色

此時,我們可以透過 Coreinfo 虛擬化擴充功能檢查工具,下載後解壓縮無須安裝直接在開啟的命令提示字元視窗中鍵入「coreinfo.exe -v」指令,便可以檢查目前在 WS2016-Outer 虛擬主機中,是否擁有 Intel VT-x 及 EPT 硬體輔助虛擬化功能。如圖 6 所示,可以看到在檢查的顯示結果中,目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何的硬體輔助虛擬化功能,所以才會導致無法順利安裝 Hyper-V 伺服器角色。

圖 6、目前擔任 Guest Hypervisor 角色的虛擬主機並沒有任何硬體輔助虛擬化功能

因此,我們必須為擔任「Guest Hypervisor」角色的 VM 虛擬主機,執行「啟用」vCPU 虛擬處理器虛擬化擴充功能的動作,如此一來 VM 虛擬主機才能順利接收,由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。

值得注意的是,擔任 Guest Hypervisor 角色的 VM 虛擬主機必須為「關機(Power Off)」狀態,才能透過 PowerShell 順利執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作,倘若 VM 虛擬主機為「運作中(Power On)」狀態的話,那麼當你執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作時,將會得到 PowerShell 指令執行失敗的情況。

圖 7、VM 虛擬主機必須關機,否則啟用 vCPU 虛擬處理器虛擬化擴充功能的動作會失敗

順利將 WS2016-Outer 虛擬主機關機後,便可以執行啟用 vCPU 虛擬處理器虛擬化擴充功能的動作,並且於指令執行完畢後再次確認 VM 虛擬主機屬性中,「ExposeVirtualizationExtensions」的欄位值是否為「True」以便確認變更作業已經套用生效。

圖 8、確認 VM 虛擬主機是否啟用 vCPU 虛擬處理器虛擬化擴充功能

請將擔任 Guest Hypervisor 角色的 VM 虛擬主機重新開機並登入後,再次執行 Coreinfo 虛擬化擴充功能檢查作業。如圖 9 所示,可以看到在檢查的顯示結果中,擔任 Guest Hypervisor 角色的虛擬主機,已經順利接收到由底層 Hyper-V 虛擬化平台所傳遞而來的 Intel VT-x 及 EPT 硬體輔助虛擬化技術。

圖 9、VM 虛擬主機,順利接收底層 Hyper-V 虛擬化平台傳遞的 Intel VT-x 及 EPT 硬體輔助虛擬化技術

此時,請開啟伺服器管理員並再次嘗試為 WS2016-Outer 虛擬主機,安裝 Hyper-V 伺服器角色時便可以發現能夠順利新增並安裝完成。

圖 10、順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色



Guest Hypervisor 啟用 MAC 位址變更機制

當你順利為 WS2016-Outer 虛擬主機安裝 Hyper-V 伺服器角色,並且在 WS2016-Outer 虛擬主機中建立名稱為「WS2016-Inner」的虛擬主機後,此時你將會發現 WS2016-Inner 虛擬主機的網路組態設定雖然正確無誤,但是它卻無法順利與實體網路環境溝通或連接到網際網路?

主要原因在於,在 Hyper-V 巢狀式虛擬化運作架構中的 VM 虛擬主機(又稱為 Nested VM 虛擬主機),必須在上層 Guest Hypervisor 虛擬主機中,啟用「MAC 位址變更」(MAC Address Spoofing)功能,以便 Nested VM 虛擬主機的網路封包,能夠順利在 2 層(Hyper-V Hypervisor 及 Guest Hypervisor)虛擬網路交換器之間順利路由,才能夠與實體網路環境溝通或碰觸到網際網路。

因此,Hyper-V 主機的管理人員可以透過 PowerShell 指令,或者是 Hyper-V 管理員操作介面進行啟用 MAC 位址變更的動作。倘若,透過 PowerShell 指令進行組態設定的話,請在 Hyper-V 主機指定為「WS2016-Outer」虛擬主機開啟 MAC 位址變更功能,並於執行後再次確認 VM 虛擬主機屬性中「MacAddressSpoofing」欄位值為「On」,以便確認變更作業已經套用生效。

圖 11、透過 PowerShell 指令,為 Guest Hypervisor 啟用 MAC 位址變更功能

或者,管理人員也可以開啟 Hyper-V 管理員操作介面,選擇 WS2016-Outer 虛擬主機後依序點選「設定 > 網路介面卡 > 進階功能」項目,然後勾選「啟用 MAC 位址變更」選項即可。

圖 12、透過 Hyper-V 管理員,為 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能

完成 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能的組態設定後,便可以發現「WS2016-Inner」Nested VM 虛擬主機,已經可以順利通過 WS2016-Outer 這台 Guest Hypervisor 的 vSwitch 虛擬網路交換器,以及 HV01 這台 Hyper-V 實體伺服器的 vSwitch 虛擬網路交換器進行路由,進而與實體網路環境溝通或碰觸到網際網路。

圖 13、Nested VM 虛擬主機,順利在 2 層 vSwitch 虛擬網路交換器之間順利路由



Guest Hypervisor 啟用 NAT 機制

當 Guest Hypervisor 虛擬主機,運作在你能掌控的 Hyper-V 虛擬化平台時,便可以透過上述 PowerShell 指令或 Hyper-V 管理員,幫 Guest Hypervisor 虛擬主機啟用 MAC 位址變更功能,進而讓 Nested VM 虛擬主機能夠與實體網路環境溝通或碰觸到網際網路。

倘若,Guest Hypervisor 虛擬主機運作在你「無法」掌控的 Hyper-V 虛擬化平台時,例如,Microsoft Azure 公有雲服務。或者,其它並非採用 Hyper-V 虛擬化解決方案的虛擬化平台,例如,Amazon AWS 公有雲服務 、VMware vSphere 虛擬化解決方案……等。

此時,便需要在 Guest Hypervisor 虛擬主機端,建立具備 NAT 功能的 vSwitch 虛擬網路交換器,以便屆時在 Guest Hypervisor 中所產生的 Nested VM 虛擬主機,能夠順利與實體網路環境溝通或碰觸到網際網路。

請在 Guest Hypervisor 虛擬主機端,執行 PowerShell 指令或透過 Hyper-V 管理員操作介面,建立類型為「內部」(Internal)的 vSwitch 虛擬網路交換器。如圖 14 所示,我們透過「New-VMSwitch」的 PowerShell 指令建立名稱為「VM-NAT」,並且類型為內部的 vSwitch 虛擬網路交換器,然後透過 Hyper-V 管理員操作介面驗證是否建立完成。

圖 14、建立屆時 Nested VM 虛擬主機對外溝通連線的 vSwitch 虛擬網路交換器

接著,再次執行「New-NetNat」的 PowerShell 指令,建立屆時用於 NAT 運作機制中的 IP 網段,在本文實作環境中建立名稱為「LocalNAT」,並且採用「192.168.100.0/24」IP 網段的 NAT 網路環境。

圖 15、建立屆時用於 NAT 運作機制中的 IP 網段網路環境

最後,再為剛才所建立名稱為 VM-NAT 的虛擬網路交換器指定所要採用的 IP 位址即可。在本文實作環境中,我們指派 VM-NAT 虛擬網路交換器採用「192.168.100.254」的 IP 位址,屆時 Nested VM 虛擬主機在設定網路組態時,便需要將預設閘道的 IP 位址設定為 192.168.100.254 後,才能順利與實體網路環境溝通或碰觸到網際網路。

圖 16、為 VM-NAT 虛擬網路交換器指派使用 192.168.100.254 的 IP 位址

在 Guest Hypervisor 虛擬主機端進行 NAT 組態設定的動作執行完畢後,首先請為 Nested VM 虛擬主機調整該網路介面卡所連接的 vSwitch 虛擬網路交換器,在本文實作環境中便是將 WS2016-Inner 虛擬主機的網路介面卡,改為連接至剛才我們所建立的 VM-NAT 虛擬網路交換器,然後在設定網路組態的部分則是指派為 192.168.100.10,當然最重要的是預設閘道必須指向至 192.168.100.254 的 IP 位址。此時,Nested VM 虛擬主機便可以順利透過 WS2016-Outer 虛擬主機,也就是 Guest Hypervisor 的 VM-NAT 虛擬網路交換器進行 NAT 進而能夠碰觸到網際網路。

圖 17、Nested VM 虛擬主機,透過具備 NAT 功能的 vSwitch 虛擬網路交換器碰觸到網際網路



Nested VM 再生 Nested VM?

至此,我們已經順利透過新一代 Windows Server 2016 雲端作業系統,原生內建的 Hyper-V 巢狀式虛擬化技術建立 Nested VM 運作環境,讓管理人員只要透過 1 台硬體伺服器,便能建立出「Hyper-V Host > Guest Hypervisor > Nested VM」的 Hyper-V 巢狀式虛擬化運作環境。

那麼,有沒有可能更進一步在 Nested VM 虛擬主機中再生出 Nested VM 虛擬主機?答案是可行的,只要遵循前述所條列的 Hyper-V 巢狀式虛擬化技術運作環境需求及限制,便可以讓 Nested VM 再生出 Nested VM 虛擬主機。

因為實作方式與前述的操作步驟相同所以便不再贅述,如圖 18 所示我們總共建立出 4 層的 Hyper-V 巢狀式虛擬化技術運作環境:

第 1 層(HV01):Hyper-V Hypervisor 實體伺服器。
     第 2 層(WS2016-Outer):VM 虛擬主機並擔任 Guest Hypervisor。
          第 3 層(WS2016-Inner):Nested VM 虛擬主機並再擔任 Guest Hypervisor。
               第 4 層(WS2016-Innermost):由 Nested VM 再生出的 Nested VM 虛擬主機。

圖 18、由 Nested VM 再生出的 Nested VM 虛擬主機





結語

透過本文的說明及實作演練,相信讀者已經完全了解新一代 Windows Server 2016 雲端作業系統中,原生內建的 Hyper-V 巢狀式虛擬化的強大功能,善用此機制相信能夠有效幫助管理人員只要利用少量的實體伺服器,就能夠建構出複雜的測試研發環境有效減少過往建立測試研發環境時的困擾。