Based on business and technical requirements, determine tiered storage configuration
View Composer supports the use of tiered storage. Generally, in most scenarios, the replica is placed on a separate high performance datastore such as an EFD. Doing so will give us a slight saving in shared storage and will give you much faster read operations. The replica storage must still be shared so that all hosts running desktops within the linked clone pool can access the replica’s disks.
It’s worth noting here, if the replica disk is placed on local storage, all the linked clones in that pool must be placed on local storage.
When moving the replica to a separate datastore you reduce each linked-clone dat store by the size of the replica. A replica is required for each pool, so if you have multiple pools allocated to the same datastore, the saving is equal to the sum of all replicas.
When placing the replica on EFD storage, you reap the following benefits:
- EFD supports much higher I/O than SAS or SATA disk
- EFD responds to high read rates, such as boot storm or logon operations
- During a boot lor login event the ration is 80/20 RW
- A large percentage of reads are from the replica, therefore placing it on faster storage enhances performance massively
Determine content to be tiered and appropriate placement within tiers
Aside from replica, the Windows profile can be redirected to a persistent disk. Typically profiles and user data are redirected to network shares, leveraging a lower-tier storage such as NFS data stores.
Replica – EFD
OS Disks – FC/iSCSI/NFS
Persistent disks – NFS (typically)
Disposable Disk (If used) – same datastore as the OS disk.
Establish sizing for each storage tier in the design
Help with sizing will come from the analysis already done on the existing environment. Remember that placing the replica on EFD will reduce the shared storage requirements overall. Keep in mind a replica is required for each pool!
Further work will be done on this when I finish the objectives and run through a mock design.