Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

1118

July 19th, 2013 14:00

Is it a good idea/best practice to use an Isilon SmartConnect Zone FQDN for VMware vSphere NFS datastore mounts?

Is it a good idea/best practice to use an Isilon SmartConnect Zone FQDN for VMware vSphere NFS datastore mounts?

20 Posts

July 19th, 2013 14:00

No.  DNS server request overload can negatively affect NFS datastore performance.  Also, if the Isilon nodes are already busy with activity (new NFS client connects/disconnects) when the NFS datastores are initially mounted on each ESXi host, the NFS mounts will not be distributed evenly across the nodes/interfaces of the cluster.

30 Posts

September 11th, 2013 17:00

I don't know that there's any one correct answer to this question. Certainly there ARE valid reasons to use IP addressing rather than SmartConnect FQDNs, e.g.:

  • Using vSphere 4 or earlier versions
  • Corporate security restrictions that limit name-resolution services to authorized DNS servers
  • The possibility of introducing a circular dependency into the environment in the event of a shutdown (DNS servers reside on VMs, which reside on Isilon datastores, which require DNS to be online before any VMs can be booted up)
  • Personal preference, or the desire to know exactly which paths are in use for vSphere storage traffic, and by what workloads...

  

But as long as the version of ESXi in use on the hosts is vSphere 5.x, there are also some pretty compelling reasons not to use IP-based datastores:

  1. Using IP addresses for all Isilon datastores means mounting a separate datastore on every host, using every path. If you have a 10-node storage cluster and plan to use all available 10Gb paths for vSphere data, that's 20 separate datastores that need to be mounted on every ESXi host. The number of unique datastores that need to be maintained in that scenario very quickly rises to an unmanageable number...
  2. Every NFS datastore requires a certain amount of bandwidth per host for NFS session traffic. If there are 10 ESXi hosts using the 20 NFS datastores in the above example, then a significant chunk of each 10Gb path will be consumed by that session traffic. Unless the vSphere host cluster is really small, there's likely to be a much greater performance hit than the overhead that SmartConnect introduces to the environment.


If all the necessary components are in place (vSphere 5.x, fully licensed SmartConnect module on the Isilon cluster), then using FQDNs for datastore mounts reduces the number of separate datastore connections required since each ESXi host can have its own dedicated network path to reach the data. It also means that NFS session overhead per path is reduced, which also results in improved performance.


For more information on how to use vSphere 5 with SmartConnect, download the Isilon/vSphere 5 Best Practices Guide.

No Events found!

Top