Best way to copy NFS exports from one Isilon to another

Hi Andy,

Are you talking about setting up these 100 NFS exports on the DR cluster?  Or are you primarily concerned about copying data over to the DR cluster?  (If the latter, have you looked into SyncIQ as a possible workaround for your needs?)

- Rob

Hi AndrewSamon

Superna has a solution for this and is referenced here on the SyncIQ Hub SyncIQ - Isilon Info Hub at the bottom of the page.  The product will sync your NFS exports (first time) and then maintain sync on all changes you make to any export (or share or quota).

Many other features as well beyond this.

Let me know if you have questions on how this can help you.  Online training and demo is located here Superna - Eyeglass Online Virtual Training Booking System,  Feature list and matrix here Superna - Eyeglass Isilon Feature Matrix

Regards

Andrew

Andy,

You can certainly script it out using the Isilon Platform API and python or powershell, but honestly the easiest approach in this space is to use Superna Eyeglass for Isilon. If you’re not familiar with it, there are some youtube videos out there. It does more than copying just the configuration and the cost is extremely reasonable. Your EMC account team can co-ordinate a demo or a quote if you are interested.

Chris Klosterman

Cell: +1.913.200.1483

Email: chris.klosterman@emc.com

Senior Solution Architect

Offer and Enablement Team

EMC²| Emerging Technologies Division

You will definitely need to test this, but in earlier releases of OneFS, I believe you could copy over /ifs/.ifsvar/modules/nfs/nfs_override.xml from the source cluster to the target cluster and it might work.  It could easily break between releases.

You will likely have other issues if the hosts at your DR site don't have the same names or subnets as your source site.  For example, if you're exporting to 10.0.0.0 on your production site and your DR site is 10.1.0.0, your exports may not be valid.

good, fast, cheap -  pick at most two.  This solution may simply be in the "fast and cheap" camp.

ed.wilts wrote: good, fast, cheap -  pick at most two.  This solution may simply be in the "fast and cheap" camp.

Fast, cheap and totally unsupported :-)

If you're tired of scripting , let us know or try a trial download version.

Regards

Andrew

lun1 wrote: ed.wilts wrote: good, fast, cheap -  pick at most two.  This solution may simply be in the "fast and cheap" camp. Fast, cheap and totally unsupported :-)

Oh yeah, totally unsupported.  I don't even believe the existence of the file is in any customer-facing documentation.

On the other hand, I did say you need to test.  If you do not do regular disaster recovery tests, you do not have a viable plan.  Some recovery companies in the past have even gone so far as to explicitly state in their contracts that if the customer does not test (I think at least annually), the contract is cancelled.

And it should go without saying that if you implement what I wrote, and you later upgrade to a newer OneFS release and don't re-test, you better hope you get really, really lucky if a disaster strikes...  Furthermore, if your production and DR clusters are not running the identical version of OneFS, including all patches, you're playing with fire. 

This is one of those times where you really get close to what you pay for.