VMware Virtual SAN 6.0 introduced an all-flash architecture that uses flash devices for both caching and persistent storage. This provides customers with choice of either a hybrid or an all-flash architecture for appropriate workload requirements. For VDI, an all-flash architecture provides a more scalable solution – higher VM density per server along with better application performance & response times – with ever reducing flash storage costs.
In a joint project with Cisco, we measured VDI scalability & application response times running Horizon 6 based linked-clones on Cisco UCS C240-M4 rack servers in an all-flash Virtual SAN configuration. The table below summarizes the findings of the reference architecture of a 4-node Virtual SAN cluster supporting 660 Horizon 6 virtual desktops.
| Test Results | Test Summary | Main Points | |
| Deployed 660 desktops | 660 linked-clones(100% concurrency) | · Excellent application response times hosting linked-clones executing Login VSI Knowledge Worker Workload: helps ensures excellent end-user performance for practical workloads.
· Proven resiliency and availability: Provides greater uptime for applications. · Faster desktop operations: Improves IT efficiency |
|
| 69 minutes | 660 linked-clones deployed | ||
| 6 minutes | 660 linked-clones started | ||
| 51minutes | 660 linked-clones refreshed | ||
| 102minutes | 660 linked-clones recomposed | ||
| Average application latency of less than 3 milliseconds (ms) | LoginVSI 4.1: Knowledge Worker workload | ||
| Average disk latency of less than 13ms | Virtual SAN disk latency | ||
So with this all-flash configuration we achieved 165 virtual desktops per host on C240-M4 UCS servers executing Login VSI Knowledge Worker workload. A Login VSI knowledge workload is profiled for a VM with 2vCPU and 1.5GB RAM with higher resource usage simulation to more closely mimic production workloads in comparison to the Login VSI Office workload that is profiled for a 1vCPU VM. For such lighter resource usage workload as the VSI Office workload, even further VM density could be achieved up to 200 VMs per host supported by VMware Virtual SAN.
In addition to performing scalability testing on a 4-node, we also performed operational testing of linked-clones such as time to deploy, refresh and recompose VMs in the environment to understand how the cluster behaves (CPU, IO, Network latency) for such operations. As the results shows, these tasks were performed in an acceptable timeframe and without any delays caused.
In terms of Virtual SAN and Horizon 6 configurations, the whitepaper goes into details of the host and cluster configurations such as disk groups, storage capacity and VM configurations so I won’t go through that here but I would like to highlight the underlying BOM for reference:
| Area | Component | Quantity |
| Host hardware | · Cisco UCS C240 M4 Rack Server | 4 |
| · Intel Xeon processor E5-2680 v3 CPU at 2.50 GHz | 8 | |
| · 16-GB DDR4 2133-MHz RDIMM, PC4-17000, dual rank, 1.2V | 96 | |
| · Cisco 12-Gbps SAS modular RAID controller with 1GB Cache | 4 | |
| · Cisco VIC 1227 dual-port 10-Gbps mLOM | 4 | |
| · 32-GB SD card | 8 | |
| · 800-GB 2.5-inch enterprise performance SAS SSD drive | 24 (for linked –clones capacity) | |
| · 400-GB 2.5-inch enterprise performance SAS SSD drive* | 4 (for caching) | |
| Networking | · Cisco UCS 6248UP 48-Port Fabric Interconnect | 2 |
| · Cisco Nexus® 9372PX Switch | 2 | |
| Software | · VMware ESXi 6.0 with Virtual SAN 6.1 | 4 |
| · VMware vCenter Server 6.0 | 1 | |
| · VMware Horizon 6.1.1 | 1 | |
| · Microsoft Windows 2012 R2 | 4 | |
| · Microsoft SQL Server 2012 R2 | 1 |
One thing to note here is that we used Enterprise Performance SSDs for caching tier due to availability in our labs when we commenced this project and that we recommend customers using enterprise value drives instead as per Virtual SAN HCL for caching tier to keep the cost down significantly.
In this project, we also performed basic cluster maintenance tasks such as placing a host under maintenance and also failure simulations of individual components (disks and network connectivity) to seek whether desired failure tasks are performed – such as migration of VMs to other hosts and the reduction in capacity.
Due to this being a 4-node cluster and the primary objective of providing scalability guidance, this architecture is not designed for an n+1 scenario with a stand-by host, which is also recommended for production environments.
Finally here are the multiple Virtual SAN and Cisco UCS white papers that the joint teams have produced so far for your reference:
