Clone NFS export settings to target cluster

Hello Burhan,

This is a great question and we appreciate you posting it on the forum.

I don't have a simple answer for you and will need to research this.

Pat

We have replication policies that synchronize fairly large sets of data (this is because of  limitation of SyncIQ for number of policies that can run simultaneously). So we replicate on higher level directory (in my example /ifs/data) than the exports (in my example /ifs/data/export1 and /ifs/data/export2 ).

To prepare for failover, we need to create these same exports on the target cluster, so the clients can be redirected after disaster.

Since we add exports all the time, and also change export settings (add/delete clients) it's very difficult to replicate these changes to the target cluster's exports. So my question was about how to clone these exports settings ? For example have a command to print export setting in xml or text format which then can be used to recreate/update the export on the target cluster. Or have a way to print the isi command that the export was created with with all options.

maybe get creative with perl and output from "isi nfs exports list -v"

I don't recall what the tool is named.  I've seen a tool that will backup and restore the configuration of an array on other EMC Products like Celerra.

This feature hasn't made it into OneFS.

As you have a strong case for this functionality, have you had an opportunity to forward this request to your account team as a feature request? 

The team will then present the business justification for development and have visibility into when this feature might become available.

In earlier versions of OneFS, we could copy out the isi_nfs_exports.xml over to the target cluster.

As OneFS 6.5 and 7.0 have become so feature rich, the complexity involved in importing the exports file might be problematic.  I.E.: Role Based Access and AIMA / Provider handling.

Sounds like the cluster workflow involves frequent updates of clients and ip addresses on the export.  Migrating a periodic copy of the exports to a restore directory on the target cluster would be helpful for reference should failover need to be exercised.

It's also available in the log gathers should it be needed in a pinch.

Pat

I've successfully tested copying over /ifs/.ifsvar/modules/nfs/nfs_override.xml (OneFS 7.0.1.2) to our DR cluster gives us the expected results. Just make sure that the underlying directory structure exists on the target cluster otherwise you'll get alerts.

As for SMB, it was mentioned in Google Groups that you can do this as well although it's a bit trickier. (I am quoting the author from the Google Group's posting)

To export the current SMB settings to a file (then copy this file to the desired cluster):

grep "registry.Services.lwio.Parameters.Drivers.srv.shares.[s.._]" /ifs/.ifsvar/main_config.gc >> /ifs/smblist.out

To import the SMB settings to new cluster (I suggest removing any current shares to prevent any possible naming collisions):

Step 1 make a backup of the file we will modify!

cp /ifs/.ifsvar/main_config.gc /ifs/.ifsvar/main_config.gc.bak

Step 2 append the new values to the end of the file (the SMB settings are long and each value needs to remain on a single line so copy paste of output to a terminal will break your main_config.gc file):

cat /ifs/smblist.out >> /ifs/.ifsvar/main_config.gc

You should now see the same SMB shares and SMB share permissions set between each cluster (make sure the authentication sources are the same first before importing!).

For the above, I've not personally tested this so this is best tested in the virtual environment.

I know that there is a KB article explaining how to export/import SmartQuotas however I've not traveled down this path yet in our deployment.

This IS what I'm talking about !

SCR512,

i can confirm that the CIFS instructions work on OneFS 6.5.5.12. Very nice, thank you for sharing. It preserved share permissions which is nice but also in created the shares despite the fact that the actual directories that they point to do not exist.

So, just to be sure that I'm clear...

In order to bring up shared resoruces on a TARGET Isilon array I need to export the CIFS shares from the primay and then import them on the Target?

So, this needs to be done (exporting) on a regular basis in the event the primary goes down.

This is where Celerra replication and VDM's clearly have the advantage and EMC needs to integrate THAT component into Isilon.  Just my opinion.

yes and yes to both of your comments

What you are doing is mucking with the gconfig database directly.  This is the DB that stores a lot of the cluster configuration.  The huge caveat here is that if you mess up, you can really do major damage to the system.

If you are OneFS 7.0, the way I would recommend backup up NFS and SMB is through PAPI. It provides a nice stable interface for doing this backup and restore.

There is work internally on a tool to backup entire cluster configurations.  It will probably be available to the EMC solution architects as well as internal employees.  End user usage would be allowed but not supported unless there is a professional services agreement in place for support.

[Edit]

After reading some additional posts, the script I am mentioning can be used in a cron job on the cluster to backup config on a regular basis.  The output of the backup could then be replicated to the destination.  It is in limited use by some customers for DR situations.

so you are saying we need to purchase profession services to get our hands on the script ?

Unfortunately the API does not support SyncIQ as of current OneFS 7 and the CLI is  in process of redesign. So you can't completely use the API and if you create perl/bash scripts they will probably break with 7.1.

UGH..

Does anyone have examples of what they do to ensure they can bring the shares up on a target in the event of a claimed Disaster or for Disaster Recovery Testing?

If so, can you share what you've done?

i will take the script as is