網管人雜誌
本文刊載於 網管人雜誌第 122 期 - 2016 年 3 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。文章目錄
1、前言2、VDI 大型架構規劃
硬體資源架構規劃
軟體資源架構規劃
3、VDI 虛擬桌面佈建效能測試
4、結語
1、前言
VMware 的 VDI 桌面虛擬化解決方案，從早期 2008 年開始發行的 VMware View Manager 3 版本，經過多年的演變已經是非常成熟的解決方案，最新穩定版本為 2015 年 9 月發佈的 VMware Horizon 6.2，除了相關特色功能不斷增強之外對於其它非 Windows 作業系統，例如，Linux 也不斷提升支援度。隨著 VMware 軟體定義儲存技術 VSAN（Virtual SAN）不斷發展，新版的 VMware Horizon 也能整合最新版本的 Virtual SAN 6.1 一起協同運作，擔任 VDI 虛擬桌面的儲存資源。那麼，讓我們來看看 VMware Horizon 6.2 版本，以及在 2015 年 12 月推出的 VMware Horizon 6.2.1 修正版本中，有哪些重要的特色功能：
- 支援 Windows 10： 支援 Windows 10 作業系統為 VDI 虛擬桌面，同時 Horizon Client 應用程式及 Smart Card 裝置也都支援。
- 支援 RDS Desktops： View Composer 伺服器角色及 Linked Clones 機制，現在都可以管理及支援 RDS Desktops，同時 vDGA 及 GRID vGPU 等 3D 繪圖機制也能與 RDS Desktops 整合。
- 單向 AD 信任： 支援「單向 AD 信任網域」機制，有效解決 VDI 虛擬桌面與 Windows AD 網域環境的信任關係，無須像舊版一樣讓 View Connection Server 處於外部網域環境中。
- 支援 Virtual SAN 6.1： 支援以 vSphere 6.0 環境搭建的 All-Flash VSAN 運作架構，同時也支援以 vSphere 6.0 U1 版本搭建的 Stretched Cluster 運作架構，提供更大的高可用性及彈性。
- 整合 Access Point： 提供 DMZ Gateway 與 View Connection Server 之間的連線，讓使用者方便從網際網路透過 Smart Card 驗證機制，便能輕鬆連接至 VDI 虛擬桌面。同時，也支援「聯邦資訊處理標準（Federal Information Processing Standards，FIPS）」機制，以提供更高的安全性。
- 3D 繪圖機制增強： 除了支援 NVIDIA 的 vSGA、vDGA、vGPU 之外，現在採用 AMD GPU 顯示卡也可以運作 vSGA、vDGA 等 3D 繪圖機制，並且也支援 4K 解析度螢幕（3840 x 2160）。
- Linux 桌面支援度增強： 支援剪貼簿及 Smart Card 重新導向及 SSO 單一簽入機制之外，採用 RHEL 7.1 及 Ubuntu 14.04 等新版 Linux 作業系統時，將可支援 NVIDIA GRID vGPU、vSGA 等 3D 繪圖機制。
圖 1、VMware Horizon 6 系統運作架構示意圖
2、VDI 大型架構規劃
本文，將說明及建議當企業或組織需要規劃 VDI 大型運作架構時，不論在硬體伺服器規格或 VMware Horizon 管理用途角色方面，應該如何規劃才能達到最佳運作效能並有效提升使用者操作體驗。此 VDI 大型運作架構中 VDI 使用者數量為 960 位，其中以 Linked-Clone 機制建立的 VDI 虛擬桌面有 700 台，而 RDSH 機制所承載的虛擬桌面則為 260 台。只要根據本文的 VDI 參考建議進行規劃，即可規劃出 700 台 VDI 虛擬桌面只要花費 60 分鐘即可佈建完畢，並且當擔任儲存資源的 Virutal SAN 節點主機發生故障損壞事件時，只要花費 2 分鐘時間即可復原 VDI 虛擬桌面連線的運作架構。
圖 2、大型 VDI 運作架構效能測試參考數據
硬體資源架構規劃
有鑑於運作數量龐大的 VDI 虛擬桌面，因此在硬體資源架構的規劃上將會分開管理以避免互相影響，在 VMware Horizon 的運作架構中，每一個「View Pod」最大可以支援多達 10,000 位使用者或工作階段（Session）。因此，在本文的架構中只要一個 View Pod 即可承載，但是在 View Pod 當中會將 VMware Horizon 架構內擔任管理角色的主機，例如，vCenter Server、Connection Server、Composer Server 等運作在「Management Block」，而屆時的 960 台 VDI 虛擬桌面則運作在「Desktop Block」當中。
圖 3、大型 VDI 運作架構 View Pod 及 Block 規劃示意圖
Management Block 硬體伺服器規劃
在 Management Block 運作架構中，需要二台實體伺服器以避免發生故障損壞事件時產生 SPOF 單點失敗的問題，每台實體伺服器應配置 2 顆 CPU 處理器，並且建議採用 Intel Xeon E5 家族且至少 8 核心以上，記憶體的部分則至少應配置 256 GB，以及配置 1 張 2 Port 的 10 Gbps 網卡。
雖然，在 View Pod 的運作架構中可支援多達 10,000 台 VDI 虛擬桌面主機，但是「每一台」vCenter Server、View Connection Sever、View Security Server，建議管理的 VDI 虛擬桌面主機數量為 2,000 台比較適當，主要是為了效能以及操作時間上的考量。
此外，單台 Worksspace vApp 便可以承載 30,000 使用者，單台 vRealize Operations Manager vApp 便能承載 10,000 VDI 虛擬桌面主機，單台 App Volumes Manager Server 便能承載 10,000 使用者。但是，在管理主機方面為了避免發生 SPOF 單點失敗的問題，因此每台管理主機至少都建立 2 台以達成負載平衡及容錯備援機制。
圖 4、View Management Block 運作架構規劃示意圖
Desktop Block 硬體伺服器規劃
在 Desktop Block 運作架構中，除了 vCenter Server 與 Management Block 分開之外，也建立二個不同的 Cluster。首先，Virtual SAN Cluster 負責 700 台 VDI 虛擬桌面的部分由 7 台實體伺服器組成，每台實體伺服器配置 2 顆 CPU 處理器，並且建議採用 Intel Xeon E5 家族且至少 12 核心以上，記憶體的部分則至少應配置 256 GB，以及配置 1 張 2 Port 的 10 Gbps 網卡。
此外，這 7 台實體伺服器將會建立 Virtual SAN 運作環境，以便擔任 700 台 VDI 虛擬桌面的儲存資源（每台 VDI 虛擬桌面配置 1 vCPU、2 GB RAM），所以每台伺服器還配置了 1 顆 400GB SSD 以及 6 顆 600GB SAS 硬碟。
圖 5、Virtual SAN Cluster 硬體伺服器配置建議
RDSH Cluster 的部分，負責提供屆時 260 RDSH 虛擬桌面工作階段，並且需要二台實體伺服器以避免發生故障損壞事件時產生 SPOF 單點失敗的問題，每台實體伺服器應配置 2 顆 CPU 處理器，並且建議採用 Intel Xeon E5 家族且至少 8 核心以上，記憶體的部分則至少應配置 256 GB，以及配置 1 張 2 Port 的 10 Gbps 網卡。此外，因為 RDSH Cluster 內的叢集節點主機，屆時將存放 AppVolumes AppStacks 等資料，所以每台伺服器還配置了 2 張 1.6TB PCIe SSD。
圖 6、View Desktop Block 運作架構規劃示意圖
軟體資源架構規劃
整體運作的硬體資源架構規劃完成後接著規劃軟體資源的部分，在 VMware Horizon 的運作架構中，需要建置的角色共有 ESXi 虛擬化平台、vCenter Server，除此之外還需要 Windows AD 網域環境、View Connection Server、View Composer Server、WorkSpace、vRealize Operations...等。
圖 7、軟體資源規劃架構示意圖
vCenter Server
在線上營運環境中，VMware 官方建議應該將擔任管理任務的 VM 虛擬主機，以及擔任 VDI 虛擬桌面的 VM 虛擬主機，分別建置「不同台」vCenter Server 分開進行管理，除了避免運作架構（例如，虛擬網路）複雜化之外，在管理思維上也可以避免 SPOF 單點失敗的影響，舉例來說，若管理 VDI 虛擬桌面環境的 vCenter Server 發生故障損壞事件，短期之間難以修復的話可以先讓管理環境的 vCenter Server 暫時接手管理作業。
此外，雖然每台 vCenter Server 可以管理最多 1,000 ESXi 主機及 10,000 台 VM 虛擬主機，但是有鑑於組態配置及高可用性管理需求，最佳建議為每台 vCenter Server 管理數量 2,000 台 VDI 虛擬桌面。這樣的管理規模大小，建議為 vCenter Server 配置的資源如下：
- 作業系統： Windows Server 2012 R2
- vCPU： 4 vCPU
- vRAM： 24 GB
- Storage： 100 GB
vSphere Cluster
在此次的 VDI 大型運作架構中，將規劃建立 3 個 vSphere Cluster 並分別由 2 台 vCenter Server 進行管理，第 1 個 vSphere Cluster 為「Management」，此 Cluster 由 2 台 ESXi 主機組成並且運作所有擔任管理任務的VM虛擬主機，並且此 Cluster 必須啟用「vSphere HA」及「DRS」機制，以維持管理用途的 VM 虛擬主機負載平衡及服務高可用性。
第 2 個 vSphere Cluster 為「Desktop」，此 Cluster 由 7 台 ESXi 主機組成並且運作 700 台 VDI 虛擬桌面主機，規劃每台 ESXi 主機將運作 100 台 VDI 虛擬桌面主機，值得注意的是此 Cluster 只啟用「DRS」機制進行負載平衡機制即可。不建議啟用 vSphere HA 高可用性機制的原因在於，每台 ESXi 主機已經都運作 100 台 VDI 虛擬桌面主機，倘若啟用 vSphere HA 機制當某台 ESXi 主機發生故障損壞情況時，將會造成其它 ESXi 主機的工作負載瞬間加重，因此在此 Cluster 當中並不建議開啟 vSphere HA 機制。
第 3 個 vSphere Cluster 為「RDSH」，此 Cluster 由 2 台 ESXi 主機組成並且運作 260 RDSH 虛擬桌面工作階段，同時在這個 Cluster 當中「不啟用」vSphere HA 高可用性及 DRS 負載平衡機制。
ESXi 主機 – CPU 使用率估算
有經驗的管理人員對於每台 ESXi 主機，應該已經好奇是否能夠順利運作 100 台 VDI 虛擬桌面，讓我們來看看承載 100 台 VDI 虛擬桌面這預估數字是怎麼來的。首先，我們為每台 VDI 虛擬桌面配置 1 vCPU，並且使用 350 MHz 的 CPU 運算資源，同時預估 vCPU 額外負載為 10%。
在 ESXi 主機的部分總共有 7 台實體伺服器，每台伺服器配置 2 顆 CPU 處理器且每顆處理器擁有 12 顆運算核心，每個運算核心的時脈為 2.7 GHz，所以每顆 CPU 擁有 32.4 GHz 的運算能力，每台 ESXi 主機擁有 64.8 GHz 的運算能力，然後扣除 ESXi 運作 Virtual SAN 的額外負載 10 % 之後，保留 80 % 的運算能力也就是「46.65 GHz」。因此，每台 ESXi 主機在 CPU 運算能力方面的使用率，可以運作這樣的 VDI 虛擬桌面超過 100 台。
圖 8、ESXi 主機 – CPU 使用率估算
ESXi 主機 – Memory 使用率估算
同樣的，我們預計每台 VDI 虛擬桌面，運作 Windows 7 作業系統（32 位元）及使用 1920x1600 解析度，並且配置 2 GB 記憶體空間，每台 VDI 虛擬桌面的 vRAM 額外負載為 41 MB，未設定「Memory Reservation」記憶體空間預先保留機制。
在 ESXi 主機的部分總共有 7 台實體伺服器，每台伺服器配置 256 GB 記憶體空間，扣除運作 100 台 VDI 虛擬桌面所需記憶體空間 204 GB，以及 ESXi 運作 Virtual SAN 的額外負載 5 GB 之後，保留 80 % 的記憶體使用率之後，每台 ESXi 主機在記憶體方面的使用率，可以運作這樣的 VDI 虛擬桌面超過 100 台。
圖 9、ESXi主機 – Memory 使用率估算
ESXi 主機 – 虛擬網路規劃
有鑑於要管理的 ESXi 主機數量不少，因此並不適合使用標準型交換器 vSS（vNetwork Standard Switch），建議採用分佈式交換器 vDS（vNetwork Distributed Switch），否則將會造成營運管理上很大的負擔，舉例來說，在本文的運作架構中共有 11 台 ESXi 主機，當需要變更某個虛擬交換器名稱時，在 vDS 環境中只要修改一次即可，但在 vSS 環境中就必須要修改 11 次（逐台修改）。
此外，在每台 ESXi 主機上皆配置 1 張 2 Port 的 10 Gbps 網路卡，分別連接到不同台實體網路交換器上，以避免網路卡或網路交換器發生故障損壞事件造成 SPOF 單點失敗的問題，並且規劃出「四種」依不同網路流量的 Port Group，以便搭配 vDS 當中的 NIOC（Network I/O Control）網路流量管控機制，同時也便於管理人員掌握各種網路流量的傳輸情況以利故障排除作業。
- Management： ESXi 主機的管理流量。
- VMNet： 管理用途的 VM 虛擬主機對外流量，以及 VDI 虛擬桌面對外提供服務的流量。
- Storage： Virtual SAN 儲存網路傳輸流量。
- vMotion： 用於 vSphere vMotion 線上即時遷移 VM 虛擬主機的傳輸流量。
圖 10、針對不同用途的網路流量規劃出四種 Port Group
View – Connection / Security Server
在 Horiozn 運作架構中 Connection Server，為負責擔任「代理人（Broker）」的角色，在平常運作時 VDI 虛擬桌面透過「代理程式（Agent）」，隨時將目前的運作狀況回報給 Connection Server，如此一來 Connection Server 便能得知每台 VDI 虛擬桌面的狀態，例如，桌面目前狀態為可用、更新中、重開機中...等。
Security Server 的部分因為會直接接觸到網際網路來的 VDI 連線需求，所以會置放於「非軍事區 DMZ（Demilitarized Zone）」，並且此台主機不會加入 Windows AD 網域中，同時視連線需求在第一道防火牆中開啟相關連接埠號，舉例來說，開啟 Port 443 以允許 HTTPs 流量通過，開啟 Port 4172 以允許 PCoIP 流量通過。詳細的防火牆連接埠號，請參考 VMware KB 1026766、2061913、1027217 及相關文件。
此外，VMware 官方的最佳建議為，每台 View Connection Server 及 View Security Server 管理數量 2,000 台 VDI 虛擬桌面。同時，為了達成服務的負載平衡及高可用性考量，在本文規劃環境中將建置 4 台 View Connection Server 及 2 台 View Security Server，每台主機的建議配置資源如下：
- 作業系統： Windows Server 2012 R2
- vCPU： 4 vCPU
- vRAM： 16 GB
- Storage： 50 GB
圖 11、View Connection / Security 運作架構示意圖
View – Composer Server
在 Horiozn 運作架構中 Composer Server，提供的「連結複製（Linked Virtual Machine Clones）」機制，它會為每個 VM 虛擬主機建立「唯一指標（Unique Pointers）」，因此每台 VM 虛擬主機所佔用的空間只有「差異」的部份而以，與 Master Image 佔用空間相較之下通常可以減少 50 ~ 70 % 的空間大小。
圖 12、VDI 虛擬桌面範本運作機制示意圖
當您將 VDI 虛擬桌面架構中，相關伺服器角色安裝及設定完成後，便可以登入 Horizon View Administrator 管理介面（安裝完 Connection 伺服器角色後便具備），新增 vCenter 及 Composer 伺服器資訊，以利後續 VDI 虛擬桌面的佈建作業。登入管理介面後，請依序點選「View 組態 > 伺服器 > vCenter Server > 新增」，在彈出的新增 vCenter Server 視窗中，填入 vCenter 伺服器管理者資訊。
預設情況下，進階設定內的並行作業設定值為「20、50、12、8」，但在本文的規劃運作架構中建議更改為「30、50、30、30」，以達成一開始所預估的目標佈建 700 台 VDI 虛擬桌面只要花費 60 分鐘即可部署完畢。
圖 13、準備進行 vCenter 及 Composer 匹配作業
最後，在儲存空間設定頁面中，記得勾選「回收虛擬機器磁碟空間」或「啟用 View 儲存加速器」等功能。從 VMware vSphere 5.0 版本開始，便支援 ESXi Host Caching 機制「CBRC（Content-Based Read Cache）」，是 VMware vSphere 內建的「讀取快取」機制，並且從舊版 VMware View 5.1 版本便開始支援及整合此功能，當然最新版本的 Horizon 6.2 也支援整合將底層的 ESXi Host Caching CBRC 機制整合進來，稱之為「View 儲存加速器（View Storage Accelerator）」特色功能。
圖 14、每台負責運作 VDI 虛擬桌面的 ESXi 主機，都應啟用 View 儲存加速器機制
View – App Volumes
透過 App Volumes 機制可以有效整合，使用者端所使用的應用程式、資料檔案、環境設定並整合 Windows AD 網域環境，達成快速佈建企業或組織常用的應用程式至 VDI 虛擬桌面當中，並且除了整合 VDI 虛擬桌面之外，也可以整合 RDSH 工作階段。
圖 15、App Volumes 運作架構示意圖
值得注意的是，在本文大型 VDI 運作架構下，因為必須針對數量龐大的 VDI 虛擬桌面進行操作，因此建議修改 App Volumes Manager 的 VM 組態重新設定的逾期時間，請登入 App Volumes Manager 主機，建立新的環境變數名稱為「CV_RECONFIG_TIMEOUT」，並且指定「600」秒的組態重新設定逾期時間（若未重新指定，預設值為 300 秒）。設定後請重新啟動 App Volumes Manager 服務，以便新指定的 VM 組態重新設定逾期時間能夠套用生效。
圖 16、重新指定 VM 組態重新設定逾期時間為 600 秒
Windows AD 網域
以往在建構 vSphere 伺服器虛擬化環境時，可以選擇要或不要建置 Windows AD 網域環境。但是，當你需要建構 Horizon VDI 虛擬桌面環境時，因為 VDI 虛擬桌面通常採用 Windows 作業系統，因此「必須」要建置 Windows AD 網域環境，以便透過 Windows AD 網域的網域控制站 DC（Domain Controller），來達成使用者「驗證（Authentication） / 授權（Authorization）」的機制。
在本文實作環境中，額外建立 HorizonView-Test OU 容器，並且於其下再建立 Virtual Desktops、RDSH Servers 等二個子 OU 容器，以便存放 VDI 虛擬桌面及 RDSH 的電腦帳戶，以及針對不同虛擬桌面特色客製化而成的 GPO 群組原則。
圖 17、Windows AD 網域 OU 容器規劃示意圖
3、VDI 虛擬桌面佈建效能測試
經過上述硬體伺服器及 Horizon 軟體運作元件的適當規劃後，接著我們透過 View Planner 效能測試工具，來驗證在 Virtual SAN 儲存資源中佈建 700 台 Linked-Clone 的 VDI 虛擬桌面的運作情況。在 Desktop Cluster 當中，將透過 View Composer Server 佈建 700 台 Windows 7（32 位元）的 VDI 虛擬桌面，每台 ESXi 成員主機將會佈建 100 台 VDI 虛擬桌面。首先，View Composer Server 將會在 Virtual SAN Datastore 中建立 24 GB 的 Replica Base Image，接著透過 Linked-Clone 機制大量產生 VDI 虛擬桌面，並且加入 Windows AD 網域當中，最後透過 Agent 通知 View Connection Server 狀態為可用（可進行連接），整個效能測試的結果一共花費「60 分 54 秒」。
圖 18、在 Virtual SAN 儲存資源中佈建 700 台 VDI 虛擬桌面的測試數據
4、結語
透過本文的說明，從硬體伺服器的資源配置到 Horizon 軟體元件的角色規劃，相信讀者已經了解到如何規劃及建置大型 VDI 運作架構，同時整合 VSAN 軟體定義儲存技術，提供數量龐大的 VDI 虛擬桌面當儲存資源，仍然能夠在佈建時快速完成部署作業。因此，透過本篇文章的說明及實務建議，希望能夠協助讀者建置完整的 VDI 虛擬桌面運作架構，以便有效管理上百上千台 VDI 虛擬桌面，同時方便企業或組織進行 VDI 環境的導入評估及測試作業。
