虛擬化 巢狀式虛擬化 Nested Virtualization 容器 Container

活用Azure VM虛擬主機 靈活建構多層虛機運作

實戰巢狀式虛擬化 打造容器高規隔離保護

2021-06-07
微軟Hyper-V虛擬化平台中內建的巢狀式虛擬化技術,不僅提供容器更高的隔離安全性,還能夠在企業內部資料中心硬體資源不足時,藉由Auzre公有雲環境來輕鬆建構研發和測試環境,本文將透過實戰演練的方式來做示範解說。

 

在過去的微軟Hyper-V虛擬化平台中,一直遲遲未支援深受管理人員喜愛的巢狀式虛擬化技術。在過去的Windows Server版本中,非常難以實作出巢狀式虛擬化環境,即便實作成功後,微軟官方也不支援該運作環境。直到Windows Server 2016版本時,微軟的Hyper-V虛擬化平台開始內建支援「巢狀式虛擬化」運作環境,除了方便管理人員建構研發和測試環境之外,更重要的是將巢狀式虛擬化和Windows「容器」技術進行整合。

在典型的Linux容器運作環境中,於Linux主機上層運作的容器透過命名空間、資源控制和執行程序隔離的方式,讓多種不同服務的容器同時運作在同一台Linux主機中,並且上層運作的容器和底層的Linux主機共用相同的系統核心。

而在Windows容器技術中,採用隔離模式為「執行程序」(Process)的時候,便是與典型的Linux容器環境大致相同,如圖1所示。

圖1  採用執行程序隔離模式的Windows Server Container運作架構示意圖。 (圖片來源:Microsoft Docs – Windows Container Essentials – Isolation Modes)

雖然採取執行程序隔離模式時具有一定強度的安全性,然而對於強度高度安全性和完全隔離需求的企業組織來說可能不足。因此,微軟透過巢狀式虛擬化搭配Windows容器技術,發展出相容性更佳且高度安全性的「Windows Hyper-V Container」技術,如圖2所示。

圖2  Windows Hyper-V Container運作架構示意圖。 (圖片來源:Microsoft Docs – Windows Container Essentials – Isolation Modes)

簡單來說,若是採用隔離模式為「Hyper-V」的容器,將會運作在微軟高度客製化和組態最佳化的特殊VM虛擬主機中,每個容器皆可以安全且完整地使用VM虛擬主機核心,充分為不同的容器之間提供硬體層級的隔離機制。

巢狀式虛擬化環境需求

在開始實作巢狀式虛擬化技術之前,管理人員必須先確保運作環境滿足相關條件,後續才能在Hyper-V虛擬化平台中,順利地為運作的VM虛擬主機啟用巢狀式虛擬化技術。

首先,在Hyper-V虛擬化平台的硬體伺服器方面,必須採用支援Intel VT-x和EPT硬體輔助虛擬化技術的CPU處理器,並且Hyper-V虛擬化平台的伺服器版本,至少要採用Windows Server 2016或後續版本,建立的VM虛擬主機組態設定版本必須為8.0或後續版本。

值得注意的是,啟用巢狀式虛擬化技術後的第二層VM虛擬主機,在vNetwork虛擬網路組態設定上,與一般正常的第一層VM虛擬主機有所不同。目前,Hyper-V虛擬化平台支援兩種不同的作法,分別是「MAC位址欺騙」(MAC Address Spoofing)和「網路位址轉譯」(Network Address Translation,NAT)。

當管理人員能夠碰觸和管理Hyper-V虛擬化平台時,例如在企業內部資料中心內建立的Hyper-V虛擬化平台,便建議採用MAC位址欺騙方式,如圖3所示,讓第二層VM虛擬主機的網路封包能夠在vSwitch虛擬交換器進行路由。當管理人員無法碰觸Hyper-V虛擬化平台時,例如公有雲環境,建議採用NAT網路位址轉譯的方式,在第一層VM虛擬主機中建立NAT vSwitch虛擬交換器,幫助第二層VM虛擬主機的網路封包進行路由。

圖3  啟用MAC位址欺騙機制,以便啟用巢狀式虛擬化的VM虛擬主機網路封包能夠進行路由。

此外,建議第二層VM虛擬主機應「停用」動態記憶體功能。因為,第二層VM虛擬主機即便啟用動態記憶體功能,除了記憶體空間不會動態調整和變動之外,管理人員在第二層VM虛擬主機運作時,如果嘗試調整記憶體空間大小將會遭遇失敗,必須將第二層VM虛擬主機關機後才能調整記憶體空間大小。

了解巢狀式虛擬化運作架構

在過去Hyper-V虛擬化平台尚未支援巢狀式虛擬化技術時,一旦硬體伺服器安裝並啟用Hyper-V虛擬化功能,Hyper-V虛擬化平台中的Hypervisor虛擬化管理程序,將會完全掌控底層硬體伺服器的「虛擬化擴充功能」(Virtualization Extensions),並且防止其他軟體和上層VM虛擬主機內的客體作業系統使用,所以管理人員便無法在第一層主機的作業系統中安裝和啟用Hyper-V虛擬化功能,如圖4所示。

圖4  舊版Hyper-V虛擬化平台不支援巢狀式虛擬化。 (圖片來源:Microsoft Docs - Run Hyper-V in a Virtual Machine with Nested Virtualization)

而現在只要採用Windows Server 2016或後續版本,安裝並啟用Hyper-V虛擬化功能,Hyper-V Hypervisor虛擬化管理程序,便支援向上層VM虛擬主機公開並傳遞底層硬體輔助虛擬化技術。所以,第一層的VM虛擬主機內的客體作業系統,便能順利感知底層公開並傳遞而來的硬體輔助虛擬化技術,進而安裝和啟用Hyper-V虛擬化功能並建立第二層VM虛擬主機,如圖5所示,達成巢狀式虛擬化運作架構,也就是VM虛擬主機內可以再產生VM虛擬主機。

圖5  新版Hyper-V虛擬化平台完全支援巢狀式虛擬化。 (圖片來源:Microsoft Docs - Run Hyper-V in a Virtual Machine with Nested Virtualization)

實戰Azure VM啟用巢狀式虛擬化

在過去,企業組織通常僅在內部資料中心內,組態設定和啟用Hyper-V虛擬化平台支援巢狀式虛擬化,然而在Microsoft Build 2017年大會中,微軟官方正式宣佈Azure公有雲環境新增Dv3和Ev3規模的VM虛擬主機,簡單來說,這兩種新增的VM虛擬主機規模,支援啟用巢狀式虛擬化技術,如圖6所示。

圖6  Azure VM虛擬主機支援巢狀式虛擬化運作架構示意圖。 (圖片來源:Channel 9 | Build 2017 | Azure Compute: New features and roadmap)

因此,管理人員即便在地端資料中心內沒有額外的硬體資源的情況下,無須準備任何硬體伺服器和網路交換器,也能透過建立Azure VM虛擬主機並啟用巢狀式虛擬化技術,輕鬆地建構研發和測試環境,例如建構Azure Stack HCI、AKS on Azure Stack HCI等等,以及HCI超融合叢集和Kubernetes叢集運作環境。

建立Dv3或Ev3的Azure VM虛擬主機

在本文實作環境中,建立一台「Standard D16s v3」(16 vCPU、64 GB vRAM)規模的VM虛擬主機,採用的客體作業系統為「Windows Server 2019 Datacenter」版本,在這樣的VM虛擬主機規模環境下,每小時大約花費新台幣23元,如圖7所示。

圖7  部署Standard D16s v3規模的VM虛擬主機。

除此之外,額外建立一台「Standard A8 v2」(8 vCPU、16 GB vRAM)規模的VM虛擬主機,同樣採用Windows Server 2019 Datacenter客體作業系統版本,以便稍後與Standard D16s v3規模VM虛擬主機進行對照了解差異。

啟用巢狀式虛擬化技術

首先,登入不支援巢狀式虛擬化技術的Standard A8 v2規模VM虛擬主機,雖然採用支援巢狀式虛擬化技術的Windows Server 2019客體作業系統,然而在嘗試安裝Hyper-V伺服器角色時,便會發現系統在檢查程序執行完畢後,會出現「The processor does not have required virtualization capabilities」的錯誤訊息,如圖8所示。

圖8  無法順利安裝和啟用Hyper-V伺服器角色。

此時,管理人員可以透過Coreinfo工具(https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo?WT.mc_id=WDIT-MVP-4039747),檢查主機CPU處理器的各項指令集和硬體輔助虛擬化支援情況。此工具下載完畢並解壓縮之後,無須執行安裝程序即可直接在命令提示字元視窗中執行,鍵入「coreinfo64.exe -v」指令,立即檢查在Standard A8 v2規模的VM虛擬主機中的CPU處理器型號,以及是否擁有Intel VT-x及EPT硬體輔助虛擬化功能。

如圖9所示,從檢查結果中可以看到,Standard A8 v2規模VM虛擬主機,並沒有獲得底層Hyper-V虛擬化平台傳遞的硬體輔助虛擬化功能,因此才會導致安裝和啟用Hyper-V伺服器角色時失敗。

圖9  Standard A8 v2規模VM虛擬主機,沒有支援相關硬體輔助虛擬化功能。

同樣的情況,透過Coreinfo工具檢查Standard D16s v3規模的VM虛擬主機時,從檢查結果中可以發現,Standard D16s v3規模的VM虛擬主機,確實獲得底層Hyper-V虛擬化平台傳遞的Intel VT-x及EPT硬體輔助虛擬化功能,如圖10所示,因此管理人員可以放心安裝和啟用Hyper-V伺服器角色。 建立NAT vSwitch虛擬交換器 在前述「巢狀式虛擬化環境需求」小節中已經說明,由於在Azure公有雲環境中,管理人員無法碰觸到Azure公有雲基礎架構中底層的Hyper-V虛擬化平台,因此必須建立NAT vSwitch虛擬交換器,以便稍後建立的第二層VM虛擬主機,能夠透過這個第一層Hypervisor虛擬化管理程序,所建立的NAT vSwitch虛擬交換器進行網路封包的路由。

圖10  Standard D16s v3規模VM虛擬主機,獲得Intel VT-x及EPT硬體輔助虛擬化功能。

在本文實作環境中,建立的NAT vSwitch虛擬交換器名稱為「NestedVM-NATSwitch」,屆時負責進行網路位址轉譯處理的IP網段為「10.10.75.0/24」,並且第二層VM虛擬主機指向的預設閘道IP位址是「10.10.75.1」。

然後,在順利安裝及啟用Hyper-V伺服器角色的Azure VM虛擬主機中,開啟PowerShell指令視窗並鍵入「New-VMSwitch -Name "NestedVM-NATSwitch" -SwitchType Internal」指令,以便建立給屆時第二層VM虛擬主機使用的NAT vSwitch虛擬交換器。

接著,執行「New-NetIPAddress -IPAddress 10.10.75.1 -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (NestedVM-NATSwitch)"」指令,建立第二層VM虛擬主機使用的預設閘道IP位址「10.10.75.1」。最後,執行「New-NetNat -Name " NestedVM-NATSwitch" -InternalIPInterfaceAddressPrefix "10.10.75.0/24"」,指定NAT網路位址轉譯處理的IP網段為「10.10.75.0/24」。

上述建立NAT vSwitch虛擬交換器的動作完成後,分別執行「Get-VMSwitch」、「Get-NetIPAddress -IPAddress 10.10.75.1」、「Get-NetNat」指令,確認剛才組態設定內容是否正確無誤,如圖11所示。

圖11  檢查NAT vSwitch虛擬交換器組態設定內容。

建立第二層VM虛擬主機

在前述「巢狀式虛擬化環境需求」小節中已經說明,管理人員必須確認Hyper-V虛擬化平台中,稍後建立的第二層VM虛擬主機組態設定版本支援「8.0」或後續版本,屆時才能順利為第二層VM虛擬主機啟用巢狀式虛擬化功能。

在本文實作環境中,Hyper-V虛擬化平台為Windows Server 2019版本,在PowerShell指令視窗中執行「Get-VMHostSupportedVersion」指令,確認目前Hyper-V虛擬化平台支援哪些VM虛擬主機組態設定版本,再次執行並加上參數「-Default」,查詢預設建立VM虛擬主機時採用哪個VM虛擬主機組態設定版本,在本文實作環境中將會採用最新的「9.0」VM虛擬主機組態設定版本,如圖12所示。

圖12  查詢Hyper-V虛擬化平台支援的VM虛擬主機組態設定版本。

接著,透過Hyper-V管理員工具建立第二層VM虛擬主機,值得注意的是,在「巢狀式虛擬化環境需求」小節中已經強調過,請勿為第二層VM虛擬主機啟用動態記憶體功能,若是建立VM虛擬主機的過程中不慎啟用,那麼可以在建立VM虛擬主機後到組態設定視窗中進行取消。

此外,在第二層VM虛擬主機虛擬網路卡的部分,連接至剛才建立的「NestedVM-NATSwitch」NAT vSwitch虛擬交換器,如圖13所示,並且之後採用「10.10.75.0/24」的IP位址,並將預設閘道指向至「10.10.75.1」,那麼第二層VM虛擬主機的網路封包便能順利路由,也就是可以順利接觸網際網路。

圖13  第二層VM虛擬主機停用動態記憶體功能,並連接至NAT vSwitch虛擬交換器。

在為第二層VM虛擬主機開機並安裝客體作業系統之前,還必須為第二層VM虛擬主機的vCPU處理器,執行啟用vCPU虛擬處理器硬體輔助虛擬化擴充功能的動作,屆時第二層VM虛擬主機才能正確接收到,由底層Hyper-V虛擬化平台所公開和傳遞而來的Intel VT-x及EPT硬體輔助虛擬化技術。

在PowerShell指令視窗中執行「Set-VMProcessor -VMName Level2-VM -ExposeVIrtualizationExtensions $true」指令,為名稱為「Level2-VM」的第二層VM虛擬主機,啟用vCPU虛擬處理器硬體輔助虛擬化擴充功能的動作,順利啟用後須再次確認「ExposeVirtualizationExtensions」欄位值是否為「True」,以確保啟用的工作任務已套用生效,如圖14所示。

圖14  為第二層VM虛擬主機啟用vCPU虛擬處理器硬體輔助虛擬化擴充功能。

順利為第二層VM虛擬主機安裝客體作業系統後,管理人員同樣可以透過Coreinfo工具,檢查第二層VM虛擬主機是否獲得底層Hyper-V虛擬化平台傳遞的Intel VT-x及EPT硬體輔助虛擬化功能。

同樣地,從檢查結果中可以看到,第二層VM虛擬主機確實獲得底層Hyper-V虛擬化平台,向上傳遞的Intel VT-x及EPT硬體輔助虛擬化功能,如圖15所示。當然,管理人員也能為第二層VM虛擬主機順利安裝和啟用Hyper-V伺服器角色。

圖15  第二層VM虛擬主機順利獲得Intel VT-x及EPT硬體輔助虛擬化功能。

建立第三層VM虛擬主機

至此,已經從一開始建立Azure VM虛擬主機(擔任第一層VM虛擬主機的角色),進而為第二層VM虛擬主機啟用巢狀式虛擬化技術,讓管理人員只需要一台Azure VM虛擬主機,即可透過巢狀式虛擬化技術,產生許多第二層VM虛擬主機,建構企業需要的研發和測試環境。

或許,有一些管理人員可能有這種想法,既然第二層VM虛擬主機已經獲得Intel VT-x及EPT硬體輔助虛擬化功能,那麼是否能夠建立第三層或第四層甚至第五層VM虛擬主機呢?答案是肯定的,只要第三層、第四層、第五層的VM虛擬主機,能夠滿足巢狀式虛擬化環境需求,那麼便可以達到VM虛擬主機再產生VM虛擬主機的目標。

但必須留意的是,雖然底層的硬體輔助虛擬化功能可以層層傳遞上去,但是每多出一層Hyper-V虛擬化層級時,整體的儲存效能便會下降,所以越上層的VM虛擬主機儲存效能將會越發低落。

如圖16所示,名稱為「NestedVM-Level1」的第一層VM虛擬主機,是一開始建立的Azure VM虛擬主機,而名稱為「Level2-VM」則是啟用巢狀式虛擬化的第二層VM虛擬主機,名稱為「Level3-VM」的VM虛擬主機,則是由第二層VM虛擬主機在啟用巢狀式虛擬化技術後,再產生的第三層VM虛擬主機。

圖16  在Azure VM虛擬主機中透過巢狀式虛擬化,建立第三層VM虛擬主機。

事實上,可以看到第三層VM虛擬主機仍然正確獲得底層傳遞而來的Intel VT-x及EPT硬體輔助虛擬化功能,所以可以再建立「第四層」VM虛擬主機,甚至再建立「第五層」VM虛擬主機,這部分就留給有興趣的管理人員繼續實作下去吧!

建構HCI超融合與K8s容器環境

在現代化敏捷基礎架構的浪潮下,企業建構HCI超融合叢集和Kubernetes容器叢集環境的需求不斷升高。然而,管理人員在眾多廠商推出的產品中,又該如何簡單地搭建PoC概念性驗證環境,確保選擇的解決方案符合公司的需求,並且能夠解決遭遇的痛點。

舉例來說,管理人員希望搭建微軟Azure Stack HCI超融合叢集運作環境,在最小雙節點的運作架構中,除了至少需要準備二台通過驗證並支援Azure Stack HCI的硬體伺服器之外,每台硬體伺服器至少要配置2顆SSD固態硬碟、4顆HDD機械式硬體、1張10GbE網路卡。此外,也必須準備至少1台10GbE網路交換器和10GbE線材,才能夠建構Azure Stack HCI超融合叢集運作環境。

在一般情況下,企業組織要擁有對應的硬體伺服器和相關零組件配置相對困難。此時,管理人員便可以透過巢狀式虛擬化技術,在地端資料中心內以一台硬體伺服器,建立多台第二層VM虛擬主機並啟用巢狀式虛擬化機制,進而搭建Azure Stack HCI超融合叢集運作環境。

倘若企業和組織在地端資料中心內沒有多餘並且符合巢狀式虛擬化技術的硬體伺服器,更可以直接在Azure公有雲環境中選擇支援巢狀式虛擬化技術的Azure VM虛擬主機,輕鬆地搭建Azure Stack HCI超融合叢集環境,甚至是AKS on Azure Stack HCI的Kubernetes容器叢集環境。

結語

相信大家已經了解Hyper-V虛擬化平台中,內建支援的巢狀式虛擬化技術所帶來的強大功能,不僅能夠提供容器更高的隔離安全性,並且在企業內部資料中心硬體資源不足時,還能借助Auzre公有雲環境輕鬆建構研發和測試環境。

<本文作者:王偉任,Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用,目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構,部落格weithenn.org。>

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!