UNSOLVED
I
InsaneGeek
46 Posts
0
1610
December 16th, 2013 12:00
Suggestions on filesystem layout/structure
We are new to Isilon and I'm trying to find out suggestions how others have designed and built out their filesystem hierarchy. I've not found a discussion about it so I figured I'd ask what others have found works well and what doesn't work well in the real world.
My nirvana land would be a single top-level mount for all of our servers everywhere that then the app owners traverse down to controlled by export permissions. Within the filesystem would be some level of self-documenting path, documenting that it's replicated, has snapshots, etc by having something in a directory name. My reasons are to fend off the "is this replicated", etc type questions and to empower the users a bit to be able to make some of their own decisions and possibly shoot their own foot (no it's not replicated, why did you put in a place that explicitly says it's not replicated).
Something like this:
/toplevel/product/rep/snapshot/filesystem
/toplevel/product/rep/no_snap/filesystem
/toplevel/product/no_rep/snap/filesystem
/toplevel/product/no_rep/no_snap/filesystem
I don't know if I'm reaching a point of over thinking/designing things or not, and when it becomes a burden to manage, etc. where it works good on paper but sucks in reality. So looking for opinions as to what others are doing.
InsaneGeek
46 Posts
835
0
Posted December 16th, 2013 15:00
For good/bad 95% of my environment is nfs only, most of the rest being mixed mode and only a couple of windows only shares. Because it's so small the cifs side isn't as painful to manage as the nfs, which is probably the inverse of most organizations
ahh, i like your idea of directory naming convention. That's probably better than replicating top level and configure exceptions. In my shop (very heavy CIFS users) i did something like this:
\ifs\data
\cifs
\Marketing
\HR
\IT
\nfs
\apache
\randomlinuxapp
the reason i wanted to separate cifs and nfs is because sometimes we have inexperienced system admins who go in and change permissions at level too high and impacting nfs files so by separating them we can avoid that. We also don't have multi-protocol requirements. Typically our customers are trained to request replication for business critical directories (after fiasco with dual drive failure on Celerra NS80 that resulted in data loss).
crklosterman
450 Posts
835
1
Posted December 17th, 2013 12:00
Good Morning IG,
I've seen this same question from a number of customers, and I've told them all the same thing. There are 2 key factors to understand before you decide on a filesystem layout.
1. Understand Isilon Refresh Cycles:
Just about any other NAS platform on the market has a refresh cycle that looks like this:
Other Model
In 3-5 years (depending on your depreciation schedule), you'll replace the box. This may mean a fairly easy migration while on the platform such as using VDM mobility, or with vFilers, or a very complex migration that is host-based. Regardless in the end you're left with a new NAS to manage, and it has a new, albeit perhaps copied from the old array, configuration.
Isilon Model
Isilon hardware depending on your business processes and needs is most likely still refreshed in that 3-5 year bracket. There is one key difference however. The way an Isilon tech refresh works, is by adding new nodes to your existing cluster, then smart-failing out the existing nodes. That's it. Your configuration, your data, your DNS info, all stay the same. An in the context of this discussion the important points are the cluster name remains the same and the filesystem structure remains the same.
2. Understand Isilon DR:
Disaster Recovery for any NAS product consists of 3 things.
1. Sync the data
2. Sync the configuration (meaning shares and exports)
3. Re-direct the clients
Syncing the data on Isilon is done by SyncIQ.
Syncing the configuration can be done either manually or via script, contact your account team if you need assistance with this, and they can engage EMC Professional Services.
Re-directing the clients with Isilon is done via a DNS change, and again we can leave that to a separate discussion.
This is all important to filesystem layout because you have to think about the fact that when you failover, you want your failover target path to be exactly the same (soup-to-nuts) from source to target.
This is critical for 2 reasons:
1. any script that is matching your shares and exports from source to target needs a consistent path as a baseline.
2. mount entries for any NFS connections must have a consistent mountpoint, in the format of sczonename.domain.com:/ifs/path, so that when you failover, they don't have to manually edit their fstab or automount entries.
Ok so now, with that primer out of the way, what do i recommend?
On ClusterA:
/ifs/clustera/
On ClusterB:
/ifs/clusterb/
Because the clustername should never change, even with refreshes, you're safe there, also now if you would cross-replicate our 2 examples above, you'd end up with:
On ClusterA:
/ifs/clustera/ SyncIQ'ed to clusterb
/ifs/clusterb/
On ClusterB:
/ifs/clusterb/ SyncIQ'ed to clustera
/ifs/clustera/
Beyond that, I usually recommend grouping data based upon importance to the business, so that it's easy to establish replication schedules, so you may have a directory:
/ifs/clustera/users01/ (for all normal user homedirs, protected at N+2:1, SyncIQ set to every 4 hours)
/ifs/clustera/users99/ (for all executives, protected at 2x (mirrored), SyncIQ set to every 30 minutes)
Again, this is not a formal best practice; yet, but has a lot of thought behind it.
Thanks,
Chris Klosterman, ICSP, ICIE, CCNA, VCP
Twitter: @croaking
Senior Solution Architect
Offer and Enablement Team
EMC Isilon
crklosterman
450 Posts
835
0
Posted December 17th, 2013 14:00
yep it did, i edited my post above.
dynamox
11 Legend
•
20419 Posts
•
87439 Points
835
0
Posted December 16th, 2013 14:00
this structure will be visible to *nix client, what about Windows clients ..will your share have explicit indication that something is replicated ?