Isilon folder layout - /ifs/data usage

Hi,

My experience is it is better to create your own folders beneath /ifs ,  leave /ifs/data for use by the OneFS and EMC support when upgrading or patching etc.

-Shane

Thank you Chris,

#1 - Ok, so this for shops/service providers that need to support multiple Active Directory environments (with no trust), as well as shops that need to have overlapping share names. On the point of overlapping share names ..how does that work with Access Zones. On Celerra/VNX each VDM would contain a different CIFS server so you could have multiple shares: IE: \\cifsserver1\home and \\cifsserver2\home . So how does that work on Isilon, can you access zone to a specific SmartConnect zone name ?

#2 Not following this example, isnt' it the same as #1 ..allow access from AD with no trusts ?

#3 Trying to understand this example, on VNX i am dealing with actual file systems so i know that file system mounted under specific VDM will not be access to any other VDMs (as where before if file system was mounted on physical datamover anyone could get to any file system simply by mapping to \\physicaldatamover\c$)

Thank you for taking the time to explain this Chris !

Sure dynamox,

Filesystem Layout and access zones at first may not seem to be related, and I wondered if anyone would grasp onto that point, when I put that in there.  Here is the basic logic:

#1 Each access zone has a totally separate group of users, by definition because in most cases it is used because of a lack of trust relationship between domains or forests. Unless your cluster is the small subset that use the feature just because of a duplicate share name.

#2 Because there are a separate group of users, the administration of that security (primarily ACLs), is usually done per dis-jointed domain or forest.  For the purposes of auditing, and maintaining separation of that administration, the data needs to stay separate per access zone, not intermingled.

#3 If you take the long-view of how you might design for multi-tenancy, akin to VDM's, each container (access zone), must contain all data within it, like how your VDM's today are mounted at /root_vdm_1/, and then all the filesystems shared or exported out through that VDM are mounted underneath that path.

I hope that helps give you a little insight into that reccomendation.  If you want further details you might ask your account team for an NDA roadmap presentation if available.

Thanks,

Chris Klosterman, ICSP, ICIE, CCNA, VCP

chris.klosterman@emc.com

Twitter: @croaking

Senior Solution Architect

Offer and Enablement Team

EMC Isilon

#1 - Correct, the access zone part is only for clusters with duplicate share names or in multiple untrusted domains or forests.  The way this works on Isilon today is to use a separate static smartconnect zone, and NS delegation (so that you have a new name).  That smartconnect zone is linked to a new access zone. So an example might be:

Access Zone     Sharename          path                                           ShareDisplayName

System               home1                    /ifs/clustera/system/home       home

DMZ                   home2                    /ifs/clustera/dmz/home             home

#2 This is just a continuation of the thoughts above, saying that you might for regulatory or audit reasons have to keep different data that is accessed and managed by different groups completely separate.

#3 Your analogy isn't lost here, you could create a share roughly equivalent given my examples above to get to all data like /ifs/ as ifs$ or /ifs/clustera as c$ if you want to be closer to what you see now.  But those should only be shared with administrators.

Thank you Chris,

#1 makes perfect sense. Do you see a lot of service providers go to this model, i guess they have to because customer 1 says i want to have a share called "software-deport" and then you can customer 2 who says i have to have the same share name.

#2 lagging on this one   . Above you said that "For the purposes of auditing, and maintaining separation of that administration, the data needs to stay separate per access zone, not intermingled." What defines that boundary, how is data kept "not intermingled". Customer data is still scatter all over OneFS file system right ?

I think i get the whole idea of Access Zones, create isolation in terms of SmartConnect zone name, permissions and authentication source.  I would love to see Windows MMC integration where "tenants" can connect to "their" CIFS server and manage share permissions, auditing ..etc (similar to what can be done today with VNX File).  Today i resell storage to different departments in my company, i try to give them sufficient permissions to where they can manage CIFS ACLs but they still have to come to me to change share permissions, create new shares ..etc. I want to give those tasks back to departmental IT groups, empower them to do anything they want in their little "world", where i am simply in charge of maintaining the infrastructure. That's what i did on NS80

Thank you all for posting your replies and relevant questions

Chris, thank you very much for your thoughtful reply

Defining the boundary as with everything else on Isilon is done at the folder level, so you might keep /ifs/clustera/system and put all the data shared out with the system access zone into that container, and likewise /ifs/clustera/dmz, and put all data shared out with a dmz access zone in that directory.  In the end you're certainly right, it's about separating your data and planning for multi-tenancy, though as I've mentioned it also has some large ramifications in the DR space.