You can place replicas and clones on separate datastores with different performance characteristics. This configuration can speed up disk-intensive operations such as provisioning or running antivirus scans, especially for Composer linked clones.
For example, you can store the replica VMs on a solid-state disk-backed datastore. Solid-state disks have low storage capacity and high read performance, typically supporting 20,000 I/Os per second (IOPS). A typical environment has only a small number of replica VMs, so replicas do not require much storage.
You can store clones on traditional, spinning media-backed datastores. These disks provide lower performance, typically supporting 200 IOPS. They are cheap and provide high storage capacity, which makes them suited for storing the a large number of clones.
Configuring replicas and clones in this way can reduce the impact of I/O storms that occur when many clones are created at once, especially for Composer linked clones. For example, if you deploy a floating-assignment pool with a delete-machine-on-logoff policy, and your users start work at the same time, Horizon 7 must concurrently provision new machines for them.
You must follow certain requirements when you store the replica and clones in a pool on separate datastores:
- You can specify only one separate replica datastore for a pool.
- The replica datastore must be accessible from all ESXi hosts in the cluster.
- For Composer linked clones, if the clones are on local datastores, VMware strongly recommends that you store the replica on the same volume as the linked clones. Although it is possible to store linked clones on local datastores and the replica on a shared datastore if all ESXi hosts in the cluster can access the replica, VMware does not recommend this configuration.
- This feature is not available you use vSAN datastores or Virtual Volumes datastores. These types of datastores use Software Policy-Based Management, so that storage profiles define which components go on which types of disks.