Addressing Isilon shares


The Isilon has a built in DNS server that responds to lookups with an ip address for one of its nodes, typically round robin or based on node activity.  The DNS name that it responds to depends on whther your namespace requires ACL isolation. If it's open to campus, which is what we recommend for most file content, it's an alias to our main share. On the Isilon in ssrb, for example, this corresponds to the name: .   

We also create a CNAME pointing to this to make this name easier to consume, and to provide a non-cluster centric address for people who have the Gold data tier to use in case of a DR scenario.  For the example above, the CNAME is In case of a disaster, we can change the pointer for the CNAME to point to the surviving cluster in the other datacenter, so client pointers and paths will not need to be updated in order to get reconnected to that data.

Windows clients

If you use DFS and have gold service, there's a potential gotcha if you configure the paths using the "real" names (like above) instead of using the CNAME ( in the example above). Data replication acts in an active/passive configuration - the primary side is read/write whereas the secondary side is read-only. If you configure the "real" names as a primary path and secondary path, in case of a DR scenario, DFS will point to the secondary cluster when the primary path fails, but it will be pointing to a read-only filesystem until the replica has been failed over.

The "catch" with using the CNAME in your paths for Windows clients can be a problem with Strict Name Checking, which is enabled by default on Windows hosts newer than Windows 7/2008.  Please see this note:

for more information about that.  

Mac and Unix clients

For Mac and Linux hosts that connect directly to the target, we will provide a CNAME address that points to the active cluster. In case of filesystem rollover, we will update that CNAME to point to the replicated copy when it becomes read/write.