Migration from old cluster to new with DNS

[sc...@tacomadata.com]

I have 2 Isilon clusters.  An old one and a new one. 

OLD Cluster

\\oldisilon.company.com\

NEW Cluster 

\\smb.newisilon.company.com\

Most of the shares have been migrated using SyncIQ policies, and recreating the shares on the new cluster.  Schedule an app down-time, reconfigure the app. Start things again.  

Now what I'm left with are a bunch of difficult to move applications - and I'm wondering - could I re-point the remaining clients with a DNS update?   If this were a standalone file server I believe it would be easy, but I'm not exactly sure how smartconnect might handle this.  

It seems like I should be able to update the NS record that points to the smartconnect address of oldisilon.company.com to point instead to the smartconnect  address of newisilon.company.com.  

Am I going down the right path here? Is there something easier?

Thanks

[mandar kolhe]

Hello Scott,

In records you can point to new smartconnect IP so clients will get connected to new cluster. But their is a catch I believe client side and DNS side cache might came into play. 

Thanks

Mandar

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/6e3cb12e-4f58-40cc-aa0f-7d8fb0160996n%40googlegroups.com.

[bob flynn]

we hit same problem ( but for re IP'ing clients ) where the isilon DNS cache for the client still referred to the old IP address so NFS mounts failed as NFS export was resolving incorrectly until DNS cache expired.

so we simply told folks looking after the re IP process to reboot the client as by the time they had completed the initial boot, saw issue and rebooted the DNS cache entry had cleared and the problem was resolved.

-Bob

To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/CAJH3o5GDQPmgAJo4unKu6kWLaM6Odz6NCisbCQtCwLJu8dwdAg%40mail.gmail.com.

[Alistair Stewart]

You could do it with DNS but don't forget to change the SPNs in AD so that clients accessing the new cluster using the path of the old cluster can authenticate using kerberos.

If they're NFSv3 clients, this won't be a problem.

--

[Chris Klosterman]

Many correct points here, but you need to:

1.  A few days or weeks ahead, yes decrease the DNS TTL value as low as possible.

2. Update the smart connect zone on the target cluster to add the new name as a smart connect zone alias.

3. Pre-create all the Shares/Exports on the target to match the source.  If you own Superna EyeGlass for Isilon, it can help with this.

4. On the target cluster create snapshot schedules to match the source snapshot schedules.

5. Cutover event:

a. Stop client access to the source shares and exports

b. Do a final incremental sync, so you don't miss anything

c. Remove the SPN from the source cluster (or from it's AD machine account)

d. Add the SPN to the target cluster (or to it's AD machine account, you could do this from the CLI with `isi auth ads spn` syntax)

e. Update the NS delegation from pointing at the old cluster to pointing at the new cluster's SSIP (SmartConnect Service IP address)

6. Delete the SyncIQ jobs from the source cluster, set them up to the new DR cluster wherever that may be. (assuming there is one).  If the DR cluster is existing, you might need to use the CLI to create the job with --target-aware-initial-sync set to yes.

Might be missing a few small steps, but hope it helps.

~Chris

[sc...@tacomadata.com]

Thank you for putting this together for me.  

On further thought, while I can share SMB traffic on the new cluster from my IPs at pool0 making

OLD Cluster

\\oldisilon.company.com\

NEW Cluster 

\\newisilon.company.com\

I need to do some studying on manipulating SPNs as I don't really understand them - I'm guessing they are some kind of Kerberos ticket - I'm seen them on our clusters but haven't needed to fix or change them yet. 

[mandar kolhe]

Spn means service principal name, its used while using kerberos authentication so when user gets authenricate it will sent ticket to kdc and isilon cluster for successful authentication incase kerberos authentication does not work due to some issue then ntlm authentication will be used. Coming back to spn you should only add spn which is need for example

Protocol/fqdn

Nfs/ision.com or smb/isilon.com 

Their should be no duplicate entries of spn on either side isilon or ad or else it will get fail and only add which is needed. You can also search for kbs at support site

To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/c494eb9e-4e06-4bd3-8d24-4e25a1eed3ben%40googlegroups.com.

[sc...@tacomadata.com]

EPILOGUE

I had my cutover this last weekend & everything worked great.

before) sync the data and replicate the share permissions

  

a) At 'go time' disable SMB access to the old cluster.

b) perform a final sync of the smb shares

c) swing the NS record over to the smartconnect address of the new cluster

d) tell the new cluster he has an alternate name - the old cluster name

isi network pools modify groupnet0.subnet0.pool0 --sc-dns-zone-aliases oldcluster.company.com

e) remove the old cluster SPNs from the old cluster, and create the old cluster SPN's on the new cluster.

f) delete the sync policies on old_cluster to make the new shares read/writable.  

I was bracing myself for 2-3 days of obscure application problems.   This move included over 150 departments moved including entire subsidiary companies.  I didn't have a single problem with this move. Everything fell into place automagically.  

Thanks to the help from this group.

-Scott

 

 

On Wednesday, November 18, 2020 at 9:29:55 AM UTC-8 croa...@gmail.com wrote:

[bob flynn]

great. monitor old DNS cluster traffic for use and set a removal date of say 6 months from now and publìze widely to avoid dependency creeping in and any remaining migration effort stalling.

To view this discussion on the web visit https://groups.google.com/d/msgid/isilon-user-group/36369ad2-8014-4787-b6f1-dc4eec39b48an%40googlegroups.com.