As one of the more Isilon-centric vSpecialists at EMC, I see a lot of questions about leveraging Isilon NFS in vSphere environments. Most of them are around the confusion of how SmartConnect works and the load balancing/distribution it provides.
Not too long ago, a question arose around mounting NFS exports from an Isilon cluster, and the methods to go about doing that.
Duncan Epping published an article recently titled How does vSphere recognize an NFS datastore?
I am not going to rehash Duncan’s content, but suffice to say, a combination of the target NAS (by IP, FQDN, or short name) and a complete NFS export path are used to create the UUID of an NFS datastore. As Duncan linked in his article, there is another good explanation by the NetApp folks here: NFS Datastore UUIDs: How They Work, and What Changed In vSphere 5
Looking back at my Isilon One Datastore or Many post, there are a couple ways to mount NFS presented datastores from an Isilon cluster if vSphere 5 is used. Previous versions of vSphere are limited to a single datastore per IP address and path.
Using vSphere 5, one of the recommended methods is to use a SmartConnect Zone name in conjunction with a given NFS export path.
In my lab, I have 3 Isilon nodes running OneFS 7.0, along with 3 ESXi hosts running vSphere 5.1. The details of the configuration is:
- Isilon Cluster running OneFS 7.0.1.1
- SmartConnect Zone with the name of mavericks.vlab.jasemccarty.com
- SmartConnect Service IP of 192.168.80.80
- Pool0 with the range of 192.168.80.81-.83 & 1 external interface for each node
- SmartConnect Advanced Connection Policy is Connection Count
- NFS export with the following path
- vCenter Server 5.1 on Windows 2008 R2 with Web Client
- 3 ESXi hosts running vSphere 5.1
Read more…
Looking back that the SmartConnect Part I post, remember that SmartConnect is handling DNS delegation of the SmartConnect Zone name (FQDN)… So… What happens if the SmartConnect Zone for an NFS data network is on an isolated network? Keep in mind, that DNS needs to contact the SmartConnect Service IP to request an IP resolution for the FQDN. How can this happen if the SmartConnect Service IP for that zone is on an isolated network?
The first network defined for the “front-end” is typically configured as subnet0. It is a common practice to leverage subnet0 for the management of an Isilon cluster. When using IP based storage in vSphere environments, it is a best practice to have the storage traffic isolated from the regular network. In my previous posts (SmartConnect Part I & SmartConnect Part II) the SmartConnect Zone was on the same subnet/pool. When this is the case, and isolated networks are being used, it is impossible to leverage SmartConnect on the isolated network, unless there is a DNS, and subsequent delegation, in that isolated network.
Read more…
In Part I, I covered SmartConnect Basic, an included feature of OneFS, that handles connections to Isilon node IP addresses based on a Round Robin connection policy.
What do you do if you want a more dynamic, more resilient, and better load balanced solution? You implement SmartConnect Advanced. Remember, that SmartConnect Advanced requires an additional license.
So why is SmartConnect Advanced so much better than SmartConnect Basic? From a previous post, I mentioned:
SmartConnect Basic has the following features:
- Static IP allocation to nodes
- Connection Policy Algorithms
- Round Robin (which node is next)
- No Rebalancing
- No IP Failover
Read more…
I posted an article on VMware vSphere and EMC Isilon (VMware vSphere and EMC Isilon – One datastore or many?) and covered some of the basics of SmartConnect when used with NFS datastores. I talked about some of the abilities of SmartConnect, but didn’t really cover how to configure it.
As mentioned in my previous post, SmartConnect Basic handles Round Robin IP distribution as nodes are added to a cluster, while SmartConnect Advanced handles advanced IP distribution as nodes are added, removed, or are unavailable, to the cluster. In addition to managing IP addresses for a cluster, through DNS delegation, SmartConnect provides IP addresses for address resolution when connecting to a FQDN, rather than an IP address.
SmartConnect Basic is included with the OneFS operating system without an additional licensing requirements. SmartConnect Basic does provide the ability to use a DNS round-robin connection policy to distribute connections to all nodes in a SmartConnect Zone.
Additionally, as nodes are taken offline for maintenance, or in the event of a failure, are no longer made available from the SmartConnect Zone. This is not a high availability mechanism, but rather a process that indicates that a node, or IP address, is no longer available to answer requests. To truly leverage the round-robin benefits of SmartConnect Basic, clients have to continually perform DNS look-ups to determine if a destination node is available.
Configuring SmartConnect Basic
Configuring SmartConnect Basic is very straightforward. SmartConnect is a network component, click on Cluster > Networking from the Isilon Action menu in the Administrative Web Interface.
Read more…
Recent Comments