Shares and Failover

Hello caritobito,

Thanks for your question! I'll try to get to everything you have in here as best as I can.

1. Setting up directory structure is completely up to each customer.I have seen it where NFS exports are segregated from the SMB shares, and also where they are all together.

2. The document you are looking for for failover/failback is here: https://support.emc.com/docu60094_OneFS-7.2.1-Backup-and-Recovery-Guide.pdf?language=en_US

[NOTE: this guide DOES require a login to EMC Online Support]

Let me know if you still have questions after reviewing the guide!

things you might want to migrate during / after / before failover

speaking of OneFS 7.2.x and lower

- Quotas

- Shares

- Sharepermissions

- Accesszones

- Smartconnectzonenames

in OneFS8 and up you wont need to care about quotas anymore.

in 7.0.x you also need to care about the Kerberos passwords

Some people use scripts which are potentially written by Professional Services or by themself

You could also use Superna Eyglass. AndrewMacKay might be a person you want to talk about this

shares, exports, nfs aliases, quotas, access zones, smartconnect zones are all synced automatically for failover with Eyeglass   We are planning to add SnapshotIQ schedules and paths, Dedupe paths .  includes cluster reporting (all configuration, RPO reporting and graphing of syncIQ data, REST api, pre and post failover scripting, 3 failover modes Access zone based, DFS integrated and per SyncIQ policy

If you want to schedule a demo, let me know  andrew.mackay@superna.net

Andrew

Thanks. I did initially inquire about PS doing a script but was steered away from that to the more expensive superna product.

Thanks for the link. I've started to look over it but I think perhaps it doesn't have everything I need. I believe all we would want to do is fail over the entire cluster, not a specific zone etc.

I don't see anything in the guide near pg 52 that says how to handle the clients. So there are the 6 dns records that were created during setup. 3 for each cluster. 2 are test though.

isidata that points to isiclus1-ssip.domain.com and the ip (pinging pings round robin each node for data zone)

isiview1 that points to isiclus1-ssip.domain.com and the ip (pinging pings round robin each node for the system zone)

(then two others for the RO cluster isidata2 and isiview2)

Any shares currently created with DFS using the online cluster are like \\isidata\sharename

Naturally I would rather have dfs point to \\isidata\sharename.

So if I was not using DFS and going to failover the whole cluster, am I going to change the isidata record to point to isiclus2.domain.com and associated IP? My understanding from an initial call with superna was you never change the dns records because it breaks Kerberos etc.

Then there is DFS. If I create two targets in DFS. One to \\isidata\share and one to \\isidata2\share with isidata2 being the normal RO cluster, am I going to always keep one target disabled then after failover go through and disable the one that was the live cluster and enable the one that was the RO?

The other thing is I'm still not clear on what else I need to manually change. I know every share I create on the online cluster, those share permissions don't go over. Also none of the ABE stuff does either. While we have had an initial call with Superna, if we were to go that route, it wont be until after October.

Hi Caritobito,

Not sure which one of us at Superna was on the call, it was likely myself. 

To answer a couple of your questions.

DFS  mode in Eyeglass does not require DNS changes during failover and since smartconnect zones used for each DFS target can be different on each cluster the SPN entries to conflict in AD - so no Kerberos issues to deal with on failover.

The DNS dual delegation with access zones preserves the smartconnect zone name on failover, which does mean you need to handle SPN's since its also moving from one cluster machine account to another one. This is handled by Eyeglass failover automation automatcially

Dual delegation solution also avoids needing to touch DNS during failover (details are here )

If all of your configuration data is in the system access zone - then Access zone failover of system = Whole cluster failover.

I am not sure on your use of access zones.

In terms of pricing,  you should be aware we have per node (least cost for small node count clusters) and a cut off where per cluster pricing makes more sense (approximately > than 15 total nodes across both clusters its lower cost to go with per cluster pricing).

We offer this to match the price of the solution for the size of the environment and provide both options same features.

Let me  know if you want a follow up call.

Regards

Andrew

Believe me;

Superna is far cheaper than having scripts custom written for you.  Beyond price, if EMC PS provided you with a script it would be provided to you with no support, for 2 key reasons.

1. EMC Support cannot support every custom-written script, and EMC PS cannot re-engage every time you find a bug.

2. As the product changes or CLI or API calls change with new versions the script might stop working, or not have new features that now are deemed critical.  A single engagement of professional services to build something like this for you ends with a deliverable, which is not what you want; and end to the development.

Superna gives you the best of both worlds on that front, because

1. It's supported both by Superna and by EMC Support under a joint-support agreement.

2. They maintain and update it under your maintenance contract with them

3. They stay in close lock-step to our code releases.

4. If there is something Superna doesn't do that you want them to do; I've found their pricing structure to be very reasonable, and their enhancement/development timelines to be very short.

side-note:

Also the scripting skills of our PS resources like those of any of you vary a lot simply based upon what they've encountered in their careers.  Some may know powershell and others python or perl, or just bash.  Keeping something like that consistent is nearly impossible.  While some of our PS resources might have development backgrounds, that's not a given, nor is it even desirable to have a homogeneous base like that.  Our more diverse skill sets, experience, and training are what help us provide value to our customers.

Hope this makes it clearer why your account team would suggest Superna is the right fit here instead of custom PS-written scripts.

~Chris Klosterman

chris.Klosterman@emc.com

Advisory SA

EMC Enablement Team