VMware的VDI桌面虛擬化解決方案，從早期2008年發行的VMware View Manager 3版本開始，經過多年的演變已經是非常成熟的解決方案，最新穩定版本為2015年9月發佈的VMware Horizon 6.2，除了相關特色功能不斷增強之外，對於其他非Windows作業系統（例如Linux）也不斷提升支援度。
建置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：24GB
·Storage：100GB
規劃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，並且使用350MHz的CPU運算資源，同時預估vCPU額外負載為10%。
在ESXi主機部分，總共有7台實體伺服器，每台伺服器配置2顆CPU處理器且每顆處理器擁有12顆運算核心，每個運算核心的時脈為2.7GHz，所以每顆CPU擁有32.4GHz的運算能力，每台ESXi主機擁有64.8GHz的運算能力。
然後，扣除ESXi運作Virtual SAN的額外負載10%之後，保留80%的運算能力，也就是「46.65GHz」。因此，每台ESXi主機在CPU運算能力方面的使用率，可以運作這樣的VDI虛擬桌面超過100台，如表1所示。
表1 ESXi主機之CPU使用率估算
 |
| （資料來源：VMware白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture） |
ESXi主機之Memory使用率估算
同樣地，預計每台VDI虛擬桌面運作Windows 7作業系統（32位元）及使用1920×1600解析度，並且配置2GB記憶體空間，每台VDI虛擬桌面的vRAM額外負載為41MB，未設定「Memory Reservation」記憶體空間預先保留機制。
在ESXi主機方面，總共有7台實體伺服器，每台伺服器配置256GB記憶體空間，扣除運作100台VDI虛擬桌面所需記憶體空間204GB，以及ESXi運作Virtual SAN的額外負載5GB，保留80%的記憶體使用率之後，每台ESXi主機在記憶體方面的使用率，可以運作這樣的VDI虛擬桌面超過100台，如表2所示。
表2 ESXi主機之Memory使用率估算
 |
| （資料來源：VMware白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture） |
ESXi主機之虛擬網路規劃
由於要管理的ESXi主機數量不少，因此不適合使用標準型交換器vSS（vNetwork Standard Switch），建議採用分佈式交換器vDS（vNetwork Distributed Switch），否則會造成營運管理上很大的負擔。
舉例來說，在本文的運作架構中共有11台ESXi主機，當需要變更某個虛擬交換器名稱時，在vDS環境中只要修改一次即可，但在vSS環境中就必須修改11次（逐台修改）。
此外，在每台ESXi主機上皆配置1張雙埠的10Gbps網路卡，分別連接到不同台實體網路交換器上，以避免網路卡或網路交換器發生故障損壞事件而造成SPOF單點失敗的問題。
並且，規劃出「四種」依不同網路流量的Port Group，以便搭配vDS當中的NIOC（Network I/O Control）網路流量管控機制，同時也便於管理人員掌握各種網路流量的傳輸情況以利故障排除作業，如圖8所示。
·Management：ESXi主機的管理流量。
·VMNnet：管理用途的VM虛擬主機對外流量，以及VDI虛擬桌面對外提供服務的流量。
·Storage：Virtual SAN儲存網路傳輸流量。
·vMotion：用於vSphere vMotion線上即時遷移VM虛擬主機的傳輸流量。
 |
| ▲圖8 針對不同用途的網路流量規劃出四種Port Group。（圖片來源：VMware白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture） |
配置Connection/Security Server
在Horiozn運作架構中的Connection Server，為負責擔任「代理人（Broker）」的角色，在平常運作時VDI虛擬桌面透過代理程式（Agent）隨時將目前的運作狀況回報給Connection Server。
如此一來，Connection Server便能得知每台VDI虛擬桌面的狀態，例如桌面目前狀態為可用、更新中、重開機中等等。
在Security Server方面，因為會直接接觸到從網際網路來的VDI連線需求，所以會置放於「非軍事區DMZ（Demilitarized Zone）」，並且此台主機不會加入Windows AD網域中，同時視連線需求在第一道防火牆中開啟相關連接埠號，如圖9所示。
 |
| ▲圖9 View Connection/Security運作架構示意圖（圖片來源：VMware白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture） |
譬如，開啟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：16GB
·Storage：50GB
建構Composer Server
在Horiozn運作架構中，Composer Server提供「連結複製（Linked Virtual Machine Clones）」機制，會為每個VM虛擬主機建立「唯一指標（Unique Pointers）」，因此每台VM虛擬主機所佔用的空間只有「差異」的部分而已，與Master Image佔用空間相較之下，通常可以減少50?70%的空間大小，如圖10所示。
 |
| ▲圖10 VDI虛擬桌面範本運作機制示意圖。（圖片來源：VMware Education – Horizon (with View) Fundamentals v6.0） |
將VDI虛擬桌面架構中相關伺服器角色安裝及設定完成後，便可以登入Horizon View Administrator管理介面（安裝Connection伺服器角色後便具備），新增vCenter和Composer伺服器資訊，以利後續VDI虛擬桌面的佈建作業。
登入管理介面之後，依序點選「View 組態 > 伺服器 > vCenter Server > 新增」，然後在彈出的新增vCenter Server視窗內填入vCenter伺服器管理者的資訊。
在預設情況下，進階設定內的並行作業設定值為「20、50、12、8」，但在本文的規劃運作架構中建議更改為「30、50、30、30」，如圖11所示，以達成一開始所預估的目標，佈建700台VDI虛擬桌面只要花費60分鐘即可部署完畢。
 |
| ▲圖11 準備進行vCenter和Composer匹配作業。 |
最後，在儲存空間設定頁面中，勾選「回收虛擬機器磁碟空間」或「啟用View儲存加速器」等功能，如圖12所示。
 |
| ▲圖12 每台負責運作VDI虛擬桌面的ESXi主機，都應啟用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）」特色功能。
採用App Volumes機制
透過App Volumes機制可以有效整合使用者端所使用的應用程式、資料檔案、環境設定並整合Windows AD網域環境，以達成快速佈建企業或組織常用的應用程式至VDI虛擬桌面內。除了整合VDI虛擬桌面之外，也可以整合RDSH工作階段，如圖13所示。
 |
| ▲圖13 App Volumes運作架構示意圖。（圖片來源：VMware白皮書 – VMware Horizon 6 with App Volumes and Virtual SAN Reference Architecture） |
必須注意的是，在本文大型VDI運作架構下，由於必須針對數量龐大的VDI虛擬桌面進行操作，因此建議修改App Volumes Manager之VM組態重新設定的逾期時間。