Example Architectural Decision – Storage Protocol Choice for a VMware View Environment using Linked Clones

Problem Statement

What is the most suitable storage protocol for a Virtual Desktop (VMware View) environment using Linked Clones?

Assumptions

1.  The Storage Array supports NFS native snapshot offload
2. VMware View 5.1 or later

Motivation

1. Minimize recompose (maintenance) window
2. Minimize impact on the storage array and HA/DRS cluster during recompose activities
3. Reduce storage costs where possible
4. Simplify the storage design eg: Number/size of Datastores / Storage Connectivity
5. Reduce the total solution cost eg: Number of Hosts required

Architectural Decision

Use Network File System (NFS)

Justification

1. Using native NFS snapshot (VAAI) offloads the creation of VMs to the array, therefore reducing the compute overhead on the ESXi hosts
2. Native NFS snapshots require much less disk space than traditional linked clones
3. Recomposition times are reduced due to the offloading of the cloning to the array
4. More virtual machines can be supported per NFS datastore compared to VMFS datastores (200+ for NFS compared to max recommended of 140, but it is generally recommended to design for much lower numbers eg: 64 per VMFS)
5. Recompositions/Refresh activities can be performed during business hours, or at Logoff (for Refresh) with minimal impact to the HA/DRS cluster, thus giving more flexibility to maintain the environment
6. Avoid’s potential VMFS locking issues – although this issue is not as important for environments using vSphere 4.1 onward with VAAI compatible arrays
7. When sizing your storage array, less capacity is required. Note: Performance sizing is also critical
8. The cost of a FC Storage Area Network can be avoided
9. Fewer ESXi hosts may be required as the compute overhead of driving cloning has been removed

Implications

1.  In the current release, 5.1, View Storage Accelerator (formally Content Based Read Cache or CBRC) is not supported when using Native NFS snapshots (VAAI)
2. Also in the current release 5.1, “Use native NFS snapshots (VAAI) is in “Tech Preview” – This is rumored to change in View 5.2

Alternatives

1. Use VMFS (block) based datastores and have more VMFS datastores – Note: Recompose activity will be driven by the host which adds an overhead to the cluster.

2 thoughts on “Example Architectural Decision – Storage Protocol Choice for a VMware View Environment using Linked Clones

  1. Hi.

    “Using native NFS snapshot (VAAI) offloads the creation of VMs to the array, therefore reducing the compute overhead on the ESXi hosts”

    I am skeptical of the NFS recommendation. Your assumption is specifically geared towards the recommendation you gave, yet your alternatives don’t mention anything about iSCSI. I would suggest that iSCSI with jumbo frames would be a far better solution than NFS.

    iSCSI will out perform NFS on all IO activity (can realistically compete with 4Gb FC), yes there is some local host compute costs, but no indication of the host configuration has been given, so it can’t be ruled out of the proposed solution. Given that UX of a VDI solution is critical, the use of NFS seems flawed in this case.

    Just my “view” 🙂

    • Gday Michael,

      Firstly, thanks for your comment.

      In this example, your correct in that my assumption was geared toward the recommendation, as if the array did not support this feature the benefits are reduced. I will be adding other examples on a similar topic in the near future with different assumptions/constraints etc.

      Generally speaking, having used FCoE/FC/iSCSI/NFS numerous times with great success, my experience is these days there is very little (I/O or Throughput) performance difference between them although FC/FCoE generally is slightly lower latency. In benchmarks I see, generally the performance difference is only a couple of percent, which in most environments is neither here nor there.

      My opinion is both iSCSI and NFS can compete with even 8Gb FC when using 10GbE connections for the IP storage traffic and MTU9000.

      In this specific example, the Native NFS snapshot offload allows linked clones to be intelligent cloned by the array without the I/O being driven by the ESXi host. This is not available in block based storage (FC/FCoE/iSCSI).

      The other benefit of NFS is a larger number of machines can be hosted per NFS datastore, compare with VMFS datastores which helps drive storage efficiencies.

      As for user experience, this comes down to a number of factors, and storage performance is certainly one of them, as I have mentioned earlier my experience is all storage protocols perform at a more than acceptable level for use in a production VDI environment. What i would point out in the maintenance and deployment of linked clones is a large impact to any array, and offloading the work and using intelligent cloning (basically FlexClone/RapidClone in the Netapp world) dramatically reduces the overheads on the array, thus leading to a better user experience.

      Cheers