While I'm not 100% sure on the current version of OneFS you are running, I'll supply information for 7.2.0.x, previous versions will have much of the same information however may be on a different page.
A little confused by the following statement I will try to answer the best I can. A confirmation on which site is being removed would be helpful. I have bolded what I would like a little clarification on. (I'm assuming B is going away, but you want to get C up to date before breaking the sync)
"I am working on a client migration project and it require migrating data from Cluster A ----> C The data is currently replicated from A ----> B we are getting rid of site C. Also there is no direct network connection from A to C, it has to go through A --> B--->C.
Current Sorce - A
Current DR -B ---> this is going away
New Source -C"
A)You can do a cascading method of sync, as you said just make sure to keep them at different times. If they do happen to over lap, the sync will fail but will attempt again at next specified interval. While nothing with the sync will break it will cause cluster events.
B) Either way if site B or C is going away the need to make both sites read-write would involve utilizing the break command or breaking target association from the source cluster.
Do keep in mind that doing this will result in the need for a full re-sync.
In regards to redirecting users that will be at your discretion, suppling them with a new smartconnect zone name to connect to, or adjusting your DNS delegation, the choice is yours.
An outline of the DNS configuration on the Windows Server can be found here.
Thank you so much for the response, and I am sorry I confused in the question and I have corrected it. You are right, the site that is going away is B. The OneFS version we are using is 7.1
If I do a break at the target, and then redirect the users by simply by creating the exports/shares, would that work or I need to make changes for the configs with Smartconnect or DNS etc? The New site is being build for the purpose of migration and it has same domains/ network configurations etc as in site B. Or do I still need a smart connect zone/DNS changes required?
many options, which one is less painful is up to you ..you know your environment best:
1) redirect clients to new SmartConnect on cluster C (change login scripts on client side, AD policy, DFS ...whatever is being used to connect clients. I am assuming CIFS only. If NFS will need to touch every single *nix host and update fstab
2) if using CNAME that points to NS records on Isilon, change CNAME to point to new SmartConnect name on cluster C. Might have to create a SmartConnect alias, you need to investigate that.
3) If cluster B is going away completly and cluster C has access to the same subnet/vlan/DNS ..i would re-create smartconnect on cluster C after final SyncIQ copy is complete and SyncIQ policy is deleted.
Stdekart
104 Posts
1
August 17th, 2015 14:00
Prathi1234,
While I'm not 100% sure on the current version of OneFS you are running, I'll supply information for 7.2.0.x, previous versions will have much of the same information however may be on a different page.
A little confused by the following statement I will try to answer the best I can. A confirmation on which site is being removed would be helpful. I have bolded what I would like a little clarification on. (I'm assuming B is going away, but you want to get C up to date before breaking the sync)
"I am working on a client migration project and it require migrating data from Cluster A ----> C The data is currently replicated from A ----> B we are getting rid of site C. Also there is no direct network connection from A to C, it has to go through A --> B--->C.
Current Sorce - A
Current DR -B ---> this is going away
New Source -C"
A)You can do a cascading method of sync, as you said just make sure to keep them at different times. If they do happen to over lap, the sync will fail but will attempt again at next specified interval. While nothing with the sync will break it will cause cluster events.
B) Either way if site B or C is going away the need to make both sites read-write would involve utilizing the break command or breaking target association from the source cluster.
Do keep in mind that doing this will result in the need for a full re-sync.
Page 592:
https://support.emc.com/docu56048_OneFS-7.2.0-CLI-Administration-Guide.pdf?language=en_US
In regards to redirecting users that will be at your discretion, suppling them with a new smartconnect zone name to connect to, or adjusting your DNS delegation, the choice is yours.
An outline of the DNS configuration on the Windows Server can be found here.
https://support.emc.com/kb/183530
Prathi1234
3 Posts
0
August 18th, 2015 13:00
Hello Shane,
Thank you so much for the response, and I am sorry I confused in the question and I have corrected it. You are right, the site that is going away is B. The OneFS version we are using is 7.1
If I do a break at the target, and then redirect the users by simply by creating the exports/shares, would that work or I need to make changes for the configs with Smartconnect or DNS etc? The New site is being build for the purpose of migration and it has same domains/ network configurations etc as in site B. Or do I still need a smart connect zone/DNS changes required?
Thanks,
Prathi
dynamox
9 Legend
•
20.4K Posts
0
August 19th, 2015 20:00
many options, which one is less painful is up to you ..you know your environment best:
1) redirect clients to new SmartConnect on cluster C (change login scripts on client side, AD policy, DFS ...whatever is being used to connect clients. I am assuming CIFS only. If NFS will need to touch every single *nix host and update fstab
2) if using CNAME that points to NS records on Isilon, change CNAME to point to new SmartConnect name on cluster C. Might have to create a SmartConnect alias, you need to investigate that.
3) If cluster B is going away completly and cluster C has access to the same subnet/vlan/DNS ..i would re-create smartconnect on cluster C after final SyncIQ copy is complete and SyncIQ policy is deleted.