This post is more than 5 years old
9 Posts
0
3235
October 2nd, 2017 14:00
How to force a NFS Export to read-only for all clients
I have a migration coming up from a Legacy Isilon (7.0) to new Isilon (8.0) and the SyncIQ replication will be used to do the data migration. I'm looking for a procedure to force all NFS exports as Read/Only from CLI so that I can stop all Writes to the source NFS exports. The syntax option "isi nfs exports modify --id=XX --read-only yes" still allows R/W clients to mount it as R/W and modify things for clients in export list. Any idea how this can be done ?
0 events found
No Events found!


crklosterman
450 Posts
1
October 3rd, 2017 07:00
It really depends on what software you're using for the migration.
WITH RSYNC
If you're just using rsync, or some other host-based tool, then the best approach would be to take all of your existing lists; R/O, RW, ROOT, and CLIENTS, single instance them, and then put all of those IPs into Read Only clients before you do your final copy (except for any systems being used as migration hosts/proxies). You would also at the same time empty out all the other client export lists, root, rw, clients, etc.. My company's software DobiMiner does this automatically for you, and creates them on the other side. It's not an easy manual process, and even more difficult when you consider how you would back them up and roll-back if needed.
WITH SYNCIQ
If as you stated above you're using SyncIQ then honestly the best approach is to either
1. Just delete the exports from the source or
2. do the same (move all clients into RO clients) as listed above.
Then you would perform the final incremental with SyncIQ followed by a failover (allow writes) on the target.
----------------------------
A BETTER WAY WITH SYNCIQ
But I personally suggest something else altogether. Redirect your clients to the NEW cluster first, then do the final incremental. Why in that order? Because if you redirect them first, they have access to a read-only set of the data on the other side (assuming the matching exports are already in place). A SyncIQ protection domain will ensure that no data is modified on the target. Yes the downside is that they're seeing a version of the data that's a few hours old (depending on your SyncIQ frequency), but you can run the jobs in the background, and when they are done, allow writes to the SyncIQ Targets and you're golden. Leave it like that for a few days, then hit break, to sever the relationship, assuming the old source cluster is going away.
Hope this helps,
~Chris Klosterman
Principal SE, Datadobi
chris.klosterman@datadobi.com
emctec112
9 Posts
0
October 16th, 2017 12:00
Thanks Chris for the suggestions. We will be deleting the NFS exports on the source, then do the final sync to traget and then delete replication sessions an create NFS exports/Tree quota on target and do the cut-over. We've scripted the tasks and got all the commands ready. If roll backup is needed we will recreate NFS export on source.