This document will provide the reader with a high-level overview of VMware®’s Virtual SAN (Storage Area Network) technology, which is being used to support desktop workloads in a virtualized environment (VDI). It will describe an architecture supporting Virtual Desktop Infrastructure (VDI) that has been demonstrated as an effective alternative to traditional SAN storage for this type of application. The primary focus of this paper will be on meeting the typical challenges associated with the storage subsystem of a virtualized infrastructure, with respect to performance capacity, and operational considerations.
Up to now, the cost of flash storage has kept it primarily relegated for use in improving the performance of the highest priority workloads. SanDisk is changing the economics of this, and is opening up the use of solid-state drives (SSDs) to a broader set of deployments — such as on-line transaction processing (OLTP) systems, VDI deployments, and Analytics (e.g. Big Data) — at more accessible price points.
Desktop virtualization may be implemented in a variety of delivery models, each of which has value for certain roles and responsibilities. This Reference Architecture is targeted at the mainstream knowledge worker who requires access to multiple applications and multimedia. Other architectures may be preferable for mobile devices (e.g. smartphones) and/or remote users having specific needs (e.g. Bring Your Own Device (BYOD)).
VMware Virtual SAN enables server drives in a cluster to be used as a shared storage pool among the vSphere nodes in that cluster.
Solid-state drives (SSDs) have two purposes in Virtual SAN implementations: to provide a read cache and a write buffer. This approach dramatically improves the performance of virtual machines. In some respects, a Virtual SAN can be compared to a number of “hybrid” storage solutions in the market, which also use a combination of SSD and Hard Disk Drive (HDD) storage to boost the performance of the I/O and which have the ability to scale out based on low-cost HDD storage.
VMware Horizon View provides users with remote access to secure virtual desktops that are stored in the data center. This provides high availability for desktop services, as well as ensures greater business agility through flexible provisioning of those services, compared with those offered by traditional PCs, while greatly reducing the desktop total cost of ownership (TCO).
This reference architecture is part of the SanDisk’s Enterprise Storage Solutions library of reference documents and is intended for use by individuals who are responsible for architecting, designing, managing, and/or supporting virtualized infrastructures. Consumers of this document should be familiar with concepts pertaining to VMware vSphere®, VMware Horizon™ View, and basic server and storage technology.
This document will cover the following subject areas:
Customers that are considering implementing a Virtual Desktop Infrastructure (VDI) in order to reduce and/or contain their IT support costs are the focus of this Reference Architecture. In addition to virtualizing the desktop, this approach uses VMware’s Virtual SAN – a software-defined-storage architecture – to further optimize usage of the server and storage infrastructure.
This Reference Architecture was designed and tested against the virtual desktop of a knowledge worker using applications such as Microsoft® Office (Word, Excel, PowerPoint); web browsing (Internet Explorer, Firefox); email (Outlook), Adobe for document formatting; and multimedia applications (streaming audio/video). Details regarding the workload specifics can be found in the Test Environment section and Appendix of this document.
Virtual SAN is a new storage solution from VMware that is fully integrated with vSphere. It automatically aggregates server drives in a cluster to create shared storage that can be rapidly provisioned from VMware vCenter™ during VM creation. It is a platform for VM Storage Policies designed to simplify virtual machine (VM) storage placement decisions for vSphere administrators. It is integrated with core vSphere features such as vSphere HA, vSphere DRS and vMotion. It can also be used to address quality of service (QoS) requirements by creating VM Storage Policies that define the level of performance and availability required on a per–virtual machine basis.
Diagram 1: VMware Virtual SAN High Level Diagram
SanDisk SSDs are a valuable enhancement to Virtual SAN environments. They allow for the acceleration of I/O among the VMware ESX servers – using SSDs for high performance read/write caching and HDDs for cost-effective data persistence. Each vSphere host must have at least one SSD when participating in the Virtual SAN cluster. The more SSD capacity the host has, the greater the performance boost, because more I/O can be cached to the SSD.
VMware’s Horizon View is used for VDI, which connects multiple types of end user devices to their own personal virtual desktop running in the vSphere infrastructure in the data center.
Horizon View Desktop Agent sends screen updates to the end user’s device, while the end user sends back keyboard and mouse movements to update the applications being hosted at the central site. The end user’s Horizon View desktop consists of that person’s operating system, applications and data – all stored securely in the company’s private data center. Horizon View offers linked VM clones to save disk space when creating multiple VMs based on the same VM golden image.
Diagram 2: VMware Horizon View High Level Diagram
The following section will discuss in detail about the testing process, results and configuration used to validate the solution.
Diagram 3: 3 Node Virtual SAN Diagram
Testing Process and Workload Used:
For the validation testing in the Virtual SAN environment, we used the View Planner standard benchmark workload and used the Group A (CPU sensitive) and Group B (CPU and IO sensitive) score to determine the Virtual SAN environment capability for hosting VDI.
The view desktop is created using Windows® 7, 64-bit operating system standard image. Necessary configuration changes are done according to the View Planner installation and configuration user guide. All the applications, part of the View Planner pre-selected workload requirements, are installed inside this image.
View client desktop image is created with Windows® 7, 32-bit operating system and configured, according to the View Planner installation and configuration user guide.
A three-node Virtual SAN cluster is created, and floating pool view desktops are provisioned on top of it. View clients’ desktops and other Horizon View infrastructure VMs, such as View Planner Appliance, vCenter, AD-DNS, DHCP, VMware Horizon View, are provisioned in separate data store and computing nodes so that View desktop performance can be measured on top of Virtual SAN data store and computing nodes.
The following workloads were executed to get the results
Test Result 1:
We have run the View Planner “Standard Benchmark_5i” workload for 276 VM in a three-node Virtual SAN cluster. The 95th percentile response time for Group A, and Group B met the QoS (quality of service) threshold (<1 sec. for Group A and <6 sec. for Group B). Although the three-node cluster provisioned was having an adequate amount of disk capacity available to accommodate more desktops, but once the CPU usage level was within 95-100% range, we didn’t scale any further with the “Standard Benchmark_5i” workload.
In this test; View Clients, View Desktops, and View Planner harness were configured to run in the local area network (LAN) environment and all the virtual machines (VMs) were configured to run from same virtual local area network (VLAN) switch. Following are the application response time for Group A and Group B workload.
Fig 1: Application Response Time of “Group A” Operations for 276 VM
Fig 2: Application Response Time of “Group B” Operations for 276 VM
Further to application matrices, the below graph shows the utilization of CPU, drive and latency at drive level captured using View Planner report.
Figure 3: CPU Utilization on one host during Standard Benchmark workload run
Figure 4: Drive Utilization on one host during Standard Benchmark workload run
Figure 5: Drive Latency on one host during Standard Benchmark workload run
Test Result 2:
In this test we excluded the Internet Explorer (IE) and Firefox-based browser workload. The goal of this test is to run the workloads that are executed within the desktops and it does not include any network-related activities. We created a profile with all the preselected application workload (excluding all the workload containing either IE or Firefox operation) and set five iterations with 5-second think time.
Figure 6: Application Response Time of “Group A” Operations for 300 VM
Figure 7: Application Response Time of “Group B” Operations for 300 VM
Diagram 3: 3 Node Virtual SAN Diagram
A three-node Virtual SAN cluster is built using Virtual SAN beta version (build number 1439689). The Virtual SAN Datastore is presented to deploy the Horizon View desktops. The remaining VMs such as VMware Horizon View Manager, vCenter Server, and Composer are deployed on different clusters. The View Planner appliance and View Clients drive the workload and are configured to run from separate clusters. This is to ensure that Virtual SAN Datastore only carries the workload that is related to VMware Horizon View desktops.
Two disk groups are created in each node with one SanDisk SSD and seven HDDs. No storage policies were applied (default unchanged) for VDI desktops to achieve redundancy or tolerance.
The view client VMs, and Horizon View Desktop VMs are configured in a distributed switch and run from the same VLAN. The infrastructure components are configured in different VLANs, but were part of same LAN infrastructure. The View desktops connections are made using PCoIP protocol.
Using VMware Horizon View administrator, the default desktop pool is created and the workload is driven from the View Planner harness for different combination, as mentioned in the “Test Results” section above.
Diagram 4: View Planner Test Execution Setup
Following table describes the VM configuration used in the testing:
|VM Name||OS||Role(s)||Memory (GB)||No. of vCPU|
|AD-DNS-DHCP||Windows 2008 - 64 bit||DHCP server, Active Directory and Domain||4||1|
|Horizon View Manager||Windows 2012 - 64 bit||VMware horizon view connection manager||8||2|
|View Composer||Windows 2012 - 64 bit||View Composer, SQL Server 2008||4||2|
|vCenter||Windows 2008 R2 - 64 bit||vCenter for Horizontal View||32||4|
|View Desktop||Win 7 - 64 bit||Horizon View End User Desktops||2||1|
|View Client||Win 7 - 32 bit||Horizon View End User Clients||2||2|
|VMware View Planner||Cent OS - 32 bit||VDI Workload Generator||3||1|
Pass-through vs RAID
Virtual SAN uses no hardware or software RAID. Instead, RAID type functionality is performed at the VM level. The preferred drive-set up for Virtual SAN is to use JBOD disks, with a pass-through capable controller. Pass-through is the optimal configuration for Virtual SAN; however, Virtual SAN drives can also be configured as RAID0 drives. Usage of RAID in a Virtual SAN configuration may allow you to leverage existing infrastructure that may not have a pass-through capable controller, although RAID configurations will increase set-up complexity.
VMware ESXi™ on SD card to make more room for storage
This approach is used in order to save the server-side slot by putting the ESXi binaries on a SanDisk SD card. With the SD card, all the slots available in the server can be used to configure the disk groups. It allows the server to support more disks for greater capacity.
Number and Depth of Drive Group
Although there is no standard rule of thumb, using more drive groups will provide more total IOPS in the configuration. The SSD in a drive group is meant for “read cache” and “write buffer.” The ratio of SSDs to HDDs can be altered directly within a drive group, based on capacities of each, and also by the number of drive groups that are created. Determining the optimal configuration will depend on application behavior. This choice of configurations is very relative, and requires careful consideration of the workload that is supported.
Fault Tolerance of View Desktops
Virtual SAN provides storage policies for setting the redundancy and tolerance levels of VMs. In general, VDI environments require much less fault tolerance than general-purpose server-side applications – where the failure of the application will affect many end users. The level of fault tolerance needed for your VDI environment is dependent upon how critical these desktops are to your organization. It should be noted that the lower the need for fault tolerance (i.e. redundant VMs), the higher the density of VMs that any given physical server can support. As a best practice, VDI redundancy can be kept at a minimum, and some may choose to deploy no redundant VMs for VDI at all.
|Virtual SAN 101|
VMware’s Virtual SAN technology has been demonstrated to be an extremely effective alternative to traditional SAN storage for a VDI environment. Using VMware’s View Planner Standard Benchmark, our test results met the requirements for VMware’s VDI performance measures – achieving 95th percentile response time for QoS (CPU-sensitive operation < 1 sec., and Drive and CPU-sensitive operation < 6 sec.).
Similarly, in running VMware’s No Network Operation Workload (excluding Internet Explorer and Firefox-related operations), our test results met the 95th percentile response time QoS (CPUsensitive operation < 1 sec., and Drive and CPU-sensitive operation < 6 sec.).
The three-node Virtual SAN test environment scaled to 300 virtual desktops – at which point, CPU usage was within 95-100% that prevented additional VDI support. If additional CPU resources were added, the storage configuration used in this test could successfully achieve - (only 100 desktops per host is currently supported on VSAN) more than 300 desktops.
The use of SD cards as the ESXi boot device had the result of increasing the number of storage slots available on each host, potentially eliminating the need for external storage.
Our testing was run on pre-release Virtual SAN software. At time of this publication, Virtual SAN had achieved General Availability and the range of the hardware compatibility list (HCL) has been greatly increased and additional capabilities have been added.