For a View 5.2 test environment, View Composer replica virtual machines were placed on high-read-performance solid-state drives (SSD), which support tens of thousands of I/Os per second (IOPS). Linked clones were placed on traditional, lower-performance spinning media-backed datastores, which are less expensive and provide higher storage capacity.
Storage design considerations are one of the most important elements of a successful View architecture. The decision that has the greatest architectural impact is whether to use View Composer desktops, which use linked-clone technology. The ESXi binaries, virtual machine swap files, and View Composer replicas of parent virtual machines are stored on the shared storage system.
The external storage system that vSphere uses can be a Fibre Channel or iSCSI SAN (storage area network), or an NFS (Network File System) NAS (network-attached storage). With the Virtual SAN feature, available with vSphere 5.5 Update 1 or later, the storage system can also be aggregated local server-attached storage.
The following example describes the tiered storage strategy used in a View 5.2 test setup in which one vCenter Server managed 10,000 desktops.
This example was used in a View 5.2 setup, which was carried out prior to the release of VMware Virtual SAN. For guidance on sizing and designing the key components of View virtual desktop infrastructures for VMware Virtual SAN, see the white paper at http://www.vmware.com/files/pdf/products/vsan/VMW-TMD-Virt-SAN-Dsn-Szing-Guid-Horizon-View.pdf.
EMC VNX7500-block only
1.8TB Fast Cache (SSD)
Eight 10Gbit FCoE front end connections (4 per controller).
SSD storage tier
A single RAID5 storage pool:
12 * 200GB EFD
250GB LUN for parent images
500GB LUN for infrastructure
75GB LUNs for replica stores (1 per desktop pool cluster)
Virtual machine desktop storage tier
Two RAID 1/0 storage pools:
For pool 1:
360 15K 300GB HDD (47TB usable)
97 450GB LUNs for desktops
For pool 2:
296 15K 300GB HDD (39TB usable)
7 450GB LUNs for infrastructure
85 450GB LUNs for desktops
This storage strategy is illustrated in the following figure.
From an architectural perspective, View Composer creates desktop images that share a base image, which can reduce storage requirements by 50 percent or more. You can further reduce storage requirements by setting a refresh policy that periodically returns the desktop to its original state and reclaims space that is used to track changes since the last refresh operation.
If you use View Composer with vSphere 5.1 or later virtual machine desktops, you can use the space reclamation feature. With this feature, stale or deleted data within a guest operating system is automatically reclaimed with a wipe and shrink process when the amount of unused disk space reaches a certain threshold. Note that the space reclamation feature is not supported if you use a Virtual SAN datastore.
You can also reduce operating system disk space by using View Composer persistent disks or a shared file server as the primary repository for the user profile and user documents. Because View Composer lets you separate user data from the operating system, you might find that only the persistent disk needs to be backed up or replicated, which further reduces storage requirements. For more information, see Reducing Storage Requirements with View Composer.
Decisions regarding dedicated storage components can best be made during a pilot phase. The main consideration is I/Os per second (IOPS). You might experiment with a tiered-storage strategy or Virtual SAN storage to maximize performance and cost savings.
For more information, see the best-practices guide called Storage Considerations for VMware View.