Longer Answer: Obviously, this will happen at cut-over time unless you're using something like DFS to handle the namespace. There are two ways I'd look at doing this:
1. If you can truly merge the servers (i.e. the share names don't clash, you're all under the same authentication providers, etc). you could set up the shares and use SmartConnect Zone aliases to allow the names to resolve to the same IP pool.
2. If you can't merge the servers, you can set up the servers in separate access zones each with its own SmartConnect zone with its own name that matches the name of the previous server. in this case, you can have share name clashes and, if needed, different authentication providers.
Also to be clear, use DNS Delegations and SmartConnect zone aliases as Adam mentioned above. Don't use CNAMES. Curious about why? I included a section on that subject in this document:
I went through most of the process of a migration from my NetApp CIFS share into an Access Zone with SmartConnect and things seemed to work pretty well.
We had a consultant suggest to us that if we are moving to isilon, we're going to want to use DFS simply for the reason that isilon wouldn't be as good with authentication(slowness). I'm sure that nearly all of our clients will be connecting via the short name rather than an FQDN. Though I'm really not opposed to DFS, I'm wondering if this is really a known isilon issue? I've seen the posts about verifying the SPNs (and I added mine during my test migration) and I'm wondering if maybe he just ran into a missing SPN issue and never figured it out.
DFS doesn't speed up authentication. In fact you have one authentication more than before
Without DFS:
you authenticate to access isilon
With DFS
you authenticate to access DFS
DFS tells you where the data resides (delivers an FQDN or Shortname of your Isilon)
you authenticate to access isilon
Only thing i could imagine is, that via DFS you can guarantee that the isilon is queried by fqdn which *could* help isilon in a multi-authenticationprovider Environment to figure out which AP to use for authentication.
So DFS would only help you in the case where all of the following applies:
* that there IS an issue with authentication using shortnames (which I don't know of)
* that you have a multi-Authentication Provider Setup (otherwise there are flags like "use Default Domain Name" which can help if there should be an issue as described above)
* you don't have other ways (like GPOs, other AD-Features or startupscripts) to force the use of fqdns
in my opinion DFS is only useful if
* you want one structure over several fileservers (which reduces when using scale-out systems) OR
* you want seamless fail/switchover and provide the same path to the user and you are unable to "move" dns-records / SPNs / SmartConnectZoneNames automatically
AdamFox
254 Posts
0
February 20th, 2017 12:00
Short Answer: Yes.
Longer Answer: Obviously, this will happen at cut-over time unless you're using something like DFS to handle the namespace. There are two ways I'd look at doing this:
1. If you can truly merge the servers (i.e. the share names don't clash, you're all under the same authentication providers, etc). you could set up the shares and use SmartConnect Zone aliases to allow the names to resolve to the same IP pool.
2. If you can't merge the servers, you can set up the servers in separate access zones each with its own SmartConnect zone with its own name that matches the name of the previous server. in this case, you can have share name clashes and, if needed, different authentication providers.
crklosterman
450 Posts
1
February 20th, 2017 13:00
Also to be clear, use DNS Delegations and SmartConnect zone aliases as Adam mentioned above. Don't use CNAMES. Curious about why? I included a section on that subject in this document:
~Chris
http://isiblog.emc.com/2015/05/emc-isilon-external-network-connectivity-guide/
brian__stewart
1 Rookie
•
4 Posts
0
February 20th, 2017 23:00
Thanks, Guys.
I went through most of the process of a migration from my NetApp CIFS share into an Access Zone with SmartConnect and things seemed to work pretty well.
We had a consultant suggest to us that if we are moving to isilon, we're going to want to use DFS simply for the reason that isilon wouldn't be as good with authentication(slowness). I'm sure that nearly all of our clients will be connecting via the short name rather than an FQDN. Though I'm really not opposed to DFS, I'm wondering if this is really a known isilon issue? I've seen the posts about verifying the SPNs (and I added mine during my test migration) and I'm wondering if maybe he just ran into a missing SPN issue and never figured it out.
sluetze
2 Intern
•
300 Posts
1
February 21st, 2017 04:00
DFS doesn't speed up authentication. In fact you have one authentication more than before
Without DFS:
you authenticate to access isilon
With DFS
you authenticate to access DFS
DFS tells you where the data resides (delivers an FQDN or Shortname of your Isilon)
you authenticate to access isilon
Only thing i could imagine is, that via DFS you can guarantee that the isilon is queried by fqdn which *could* help isilon in a multi-authenticationprovider Environment to figure out which AP to use for authentication.
So DFS would only help you in the case where all of the following applies:
* that there IS an issue with authentication using shortnames (which I don't know of)
* that you have a multi-Authentication Provider Setup (otherwise there are flags like "use Default Domain Name" which can help if there should be an issue as described above)
* you don't have other ways (like GPOs, other AD-Features or startupscripts) to force the use of fqdns
in my opinion DFS is only useful if
* you want one structure over several fileservers (which reduces when using scale-out systems) OR
* you want seamless fail/switchover and provide the same path to the user and you are unable to "move" dns-records / SPNs / SmartConnectZoneNames automatically
Good Luck
-- sluetze
brian__stewart
1 Rookie
•
4 Posts
0
February 21st, 2017 08:00
Yes...it was the idea that we'd only be sending FQDN over to isilon that was supposed to speed things up.