By Narasimha Krishnakumar, Product Management, End-User Computing, VMware
This post provides a detailed overview of the storage optimization features of Horizon View 5.3.
Unbounded Storage Overcommit Policy
Horizon View enables customers to select one or more datastores for storing their desktop virtual machines. For linked-clone pools, customers can control the number of virtual machines that can be placed on a datastore by selecting one of several Storage Overcommit options.
Customers are presented with the Storage Overcommit options when they create a linked-clone desktop pool in View Administrator, as in Figure 1.
Figure 1: Horizon View Administrator User Interface–Pool Creation Wizard Showing Storage Overcommit Options
These storage options allow the customer to commit more storage space per linked-clone virtual machine than they could with full clones. The number of full-clone virtual machines that can be placed on the datastore is a function of the storage capacity of the datastore and the storage capacity of the virtual machine. For example, if the size of the datastore is 200GB, and the size of the virtual machine is 20GB, the number of full-clone virtual machines that can be placed on the datastore is 200/20, or 10 virtual machines. Following are the Storage Overcommit options.
None–Storage capacity is not overcommitted relative to space allotted for full clones on the datastore. In the example, 10 linked-clone virtual machines are placed on the datastore.
Conservative overcommit–With Conservative overcommit, the number of linked-clone virtual machines that is placed on the datastore is equal to 4 times the number of full-clone virtual machines that could be placed on the same datastore. With Conservative overcommit, using the example, this translates to 4×10, or 40 linked-clone virtual machines on the selected datastore.
Moderate overcommit–With Moderate overcommit, customers can place 7 times the number of full-clone virtual machines on the selected datastore. With the same example, this translates to 7×10, or 70 linked-clone virtual machines on the selected datastore.
Aggressive overcommit–With the Aggressive overcommit policy, the number of virtual machines that can be placed on the datastore is 15×10, or 150 linked-clone virtual machines.
Unbounded overcommit–Starting with Horizon View 5.3, we have introduced this fourth option. When customers select the Unbounded overcommit option, they can place as many linked clones on the selected datastore as they desire. This feature is beneficial to customers who use third-party storage technologies (for example, Atlantis Computing VSA), which optimize the space consumed by the virtual disks of the individual virtual machines.
Note: When the Unbounded overcommit option is chosen for a particular datastore, Horizon View 5.3 does not calculate or manage the space on the datastore. It is completely up to the administrator to calculate the space and determine the number of linked-clone virtual machines.
Virtual SAN Tech Preview
VMware vSphere 5.5 introduced the public beta of Virtual SAN. Virtual SAN aggregates local ESXi storage into software-defined pooled storage and provides a single datastore, which can be used for various types of workloads. Horizon View 5.3 enables the use of Virtual SAN as a Tech Preview for use with virtual desktops. Customers can download the Virtual SAN beta (www.vsanbeta.com) and try it with Horizon View 5.3.
Virtual SAN is highly beneficial in a VDI environment–it can deliver an ultra-low-cost virtual desktop, as well as provide simple management and setup options. VMware Virtual SAN uses a combination of SSD/flash and magnetic disks on each ESXi server. The SSD/flash disks on the server are used as a caching tier, while the magnetic disks (spinning disks) are used to provide capacity for the various workloads. This particular design of Virtual SAN benefits VDI deployments in two ways:
- The SSD/flash disk-based caching tier provides high performance (IOPS density and low-latency IO). The SSD/flash-based caching tier is used for Read caching and Write-back buffering for all IO from the virtual desktops, which translates to low-latency Read and Write IO.
- The magnetic disks provide the capacity for the virtual machines. Because the storage for VDI is local to the ESXi hosts, the initial CAPEX incurred for storage is low. Server-based SSDs offer a very good cost point in terms of cost per IOPS, and direct-attached HDDs (either 15K RPM, 10K RPM, or 7.2K RPM) provide low cost per GB depending on the type of drives used. In addition, if customers want to scale their VDI environment, they can now do so with the addition of just one server, thereby reducing the cost of scaling.
Using Horizon View 5.3 with Virtual SAN
Following are the steps to use Virtual SAN with Horizon View 5.3:
1. Set up a cluster of ESXi nodes (minimum of three) with at least one SSD and one hard disk in each of the nodes. It is best to use the same number of drives on each ESXi node and keep the environment homogeneous.
2. Enable Virtual SAN using the vSphere Web Client interface as shown in Figure 2. Select Turn ON Virtual SAN.
Figure 2: vSphere Web Client Interface Showing Cluster Settings
3. Set the default policy for Virtual SAN; Virtual SAN is policy-driven object-based storage. An object in Virtual SAN is typically a virtual disk (“VMDK”), and there are four different characteristics of each object that can be controlled via policy. The policy characteristics are:
- Stripes: Number of stripes of data
- Resiliency: Number of failures to tolerate
- Storage Provisioning: Thick or Thin
- Cache Reservation: Read-Cache reservation
Customers can enable and use policies in two different ways:
- Define and use a default policy that can be applied to all virtual machines
- Define and use different policies for each “VMDK,” based on the requirements of the workload
Because Horizon View 5.3 is enabling use of Virtual SAN as a Tech Preview, it is best if customers use the first option. The following commands illustrate the definition and use of a default policy.
- Display the Virtual SAN default policy:
~ # esxcli vsan policy getdefault
Object Policy Class Policy Value
cluster ((“hostFailuresToTolerate” i1) (“forceProvisioning” i1))
vdisk ((“hostFailuresToTolerate” i1) (“forceProvisioning” i1))
vmnamespace ((“hostFailuresToTolerate” i1) (“forceProvisioning” i1))
vmswap ((“hostFailuresToTolerate” i1) (“forceProvisioning” i1))
- Set the Virtual SAN default policy for each virtual disk (VMDK) by setting the number of stripes to 1, the host failures to tolerate as 1:
~# esxcli vsan policy setdefault -c vdisk -p “((\”stripeWidth\”
i1)(\”hostFailuresToTolerate\” i1))”While it is recommended that customers use the default policy, customers are free to tweak the policy based on the use cases for which Horizon View and Virtual SAN are being deployed.
4. Create a desktop pool using the standard workflow. When presented with the option to select a datastore for virtual machines, select the datastore with type “vsan” as shown in Figure 3.
Figure 3: Choosing a vsan Datastore
Once the above steps are performed, Horizon View 5.3 will start using the vsanDatastore to store the VMDKs of the virtual desktops, delivering an ultra-low desktop TCO and great end-user experience.
Performance Characteristics of VDI on Virtual SAN
The Horizon View Performance Engineering team ran a series of tests with Horizon View 5.3, and the results are made available at http://blogs.vmware.com/performance/2013/10/vdi-benchmarking-using-view-planner-on-vmware-virtual-san-vsan.html.
View Composer API for Array Integration Support
Horizon View 5.1 introduced the capability to offload the creation of clones to a NAS array using VAAI NAS primitives as a Tech Preview feature (http://blogs.vmware.com/euc/2012/05/view-composer-array-integration-tech-preview.html). Horizon View 5.3 fully supports this feature with select Partners, and I would like to thank our design Partner Hitachi Data Systems (HDS) for working closely with us to help support this feature. At this time, Horizon View 5.3 supports VCAI with HDS, with other Partners to follow. VMware is working with other NAS storage partners to support this highly valuable feature that allows customers to get the best image management from Horizon View and native storage-array snapshots. Support for this feature is driven by a set of test cases that validate the operation of Horizon View, vSphere, and the Partner technology (i.e., NAS VAAI Plug-in) at scale. The details of support from different Partners can be found at http://kb.vmware.com/kb/2061611.
These are a few of the storage-optimization features that have been introduced in Horizon View 5.3 to both reduce TCO and deliver ease of management and deployment for our customers. Check out some of the other features of Horizon View 5.3 at http://blogs.vmware.com/euc/2013/10/read-all-about-it-vmware-horizon-view-5-3.html. VMware is committed to delivering the best end-user experience and the simplest management capabilities of an end-user computing platform. Stay tuned for more to come in future versions.
