Unsolved
This post is more than 5 years old
58 Posts
0
2168
VNX Replicator and Usermapper
I'm trying to get a firm understanding of where usermapper actually comes into play.
I totally understand the need for usermapper in multiprotocol environments and with quotas which explicitly reference the unix UID. However, in a windows only environment, standard access checking with no quotas, which is replicated, is there a compelling reason to do this?
I see in the user mapping PDF:
"For connections from Windows users, file access checking is performed by using SIDs only. This is done to prevent errors due to UID mismatches and to reduce dependency on the Usermapper database."
So it is not possible e.g. that I am userid 40000 on primary VNX and joe is userid 40001, and on the secondary VNX I happen to be user 40001 and get access to all of Joe's files, right?
Standard windows domain only with no quotas represents a massive portion of the environments I work in, and unless I see the benefit of configuring primary/secondary usermappers I feel like it just adds an additional layer of complexity/potential failure point if there is an actual disaster and you have to failover.
Am I missing something in this standard but replicated scenario? I'm weighing my observations against a lot of documentation which seems to greatly encourage the usermapper setup in Windows only environments, and just find myself confused.
rzero
58 Posts
0
July 27th, 2015 08:00
Any thoughts or info on this one?
umichklewis
1.2K Posts
0
July 27th, 2015 10:00
When you have a replication context, configuring Usermapper ensures that 1) UNIX UIDs in the filesystems are preserved between replicating pairs and 2) if configured with primary/secondary roles, Usermapper ensures that user accounts can still be created/managed during a DR event e.g. failover.
In situations where you have a primary VNX replicating filesystems to a secondary VNX, it is common to configure the primary Usermapper on the secondary (DR) VNX. Why? Each time you create a new user on the VNX, the VNX adds the new SID to the Usermapper table as a new entry. This new SID is associated with a new UNIX UID. In the case of a replicating filesystem, this UNIX UID travels with the filesystem and is visible on the DR VNX. When the primary usermapper is on the DR VNX, the DR VNX has the R/W Usermapper table and will send new UID/SID entries to the primary VNX's Usermapper table. If the primary VNX goes down and you failover, you will be able to create new user entries, and still create new UID/SID entries in the DR VNX's Usermapper table.
The Usermapper table can be exported and imported, so you can easily import the primary VNX's Usermapper entries on the DR VNX, to ensure you have a one-to-match between the two arrays. If you don't want to go through the work of changing the primary/secondary Usermapper roles on your VNX, I suggest doing this.
Some user even cook up scripts to export the Usermapper entries and import via cron. That's not my preference - I would rather configure the primary/secondary roles and be done with it.
Let us know if that helps!
Karl
rzero
58 Posts
0
July 28th, 2015 05:00
Thanks for that info Karl.
I guess I'm wondering, in a situation where user access via NFS isn't in play, or a situation where you aren't specifying individual user quotas (e.g. UID 60001 gets a specific quota), is it even relevant that the UIDs are matched at each site?
It sounds like unlike NFS, with CIFS access is only verified by SID checks against AD, so the underlying UIDs are irrelevant.
I'm not seeing a benefit to configuring usermapper as you say in this case. And on top of that, it adds complexity and a point of failure. If I choose to configure usermapper as recommended (DR primary, prod secondary, which makes sense) and the DR site goes down, or becomes otherwise inaccessible over network like a WAN outage, then the production side can no longer allocate new UIDs. So new users would not have access until the DR site is fixed.
etaljic81
1K Posts
0
July 28th, 2015 07:00
I recommend you review this whitepaper: https://support.emc.com/docu48476_Configuring-VNX-User-Mapping-8.1.pdf?language=en_US
You statement "It sounds like unlike NFS, with CIFS access is only verified by SID checks against AD, so the underlying UIDs are irrelevant" is not accurate. Keep in mind that VNX File is Unix-based so it doesn't know SIDs. Without mapping it wouldn't know what is what and that's why the usermapper exists. The whitepaper above explains the usermapper process in detail. Also take a look at the secmap cache section, that will address your "if DR goes down" scenario.
umichklewis
1.2K Posts
0
July 28th, 2015 07:00
You're also correct about the DR WAN connectivity adding another layer of complexity. I, too, have seen PROD impacted while DR is unavailable. If you have "iffy" WAN connectivity, I would suggest using separate primary Usermappers, one on each VNX.
Thanks much!
etaljic81
1K Posts
0
July 28th, 2015 08:00
I wouldn't do that because what happens if you need to failover from one site to another? If one array is for DR then set up the usermapper per EMC best practices. Otherwise you will have permission issues when you actually have to perform a failover.
The whitepaper I provided above discusses this in detail. The secmap cache will take care of the bandwidth issues.
rzero
58 Posts
0
July 28th, 2015 09:00
Thanks for the info Ernes. The whitepaper you provided is actually where I found the statement in the original post. It is on PDF page 14:
"Note: For connections from Windows users, file access checking is performed by using SIDs only. This is done to prevent errors due to UID mismatches and to reduce dependency on the Usermapper database."
Unless I'm interpreting this wrong, this means that it is not relevant that UIDs at two sites match up for access purposes from a CIFS perspective.
In this case the requirement would be for user access via NFS (which does leverage VNX UIDs) and any specific features that leverage UIDs like user quotas.
So what would happen if you needed to failover from one site to another? As far as I can tell (again, with no NFS and no quotas) the UIDs would be different but access would not be impeded because it doesn't actually use the UID. I guess you could always export/import later if you wanted to leverage those specific features and needed the sites to be synced up.
My concern is if we configure usermapper as recommended and the DR site experiences some kind of partition from production, then the primary usermapper service at DR is no longer available. As you imply regular user access would continue at production due to secmap caching, but new user access would be disabled because the primary usermapper is down. So a DR outage would prevent any user which had not already accessed the VNX from accessing it.
Am I missing something here? Does what I'm describing make sense? Or is there some other mechanism built into usermapper to account for the primary being down?
etaljic81
1K Posts
0
July 28th, 2015 10:00
For access to the share, correct. However, file ownership will get screwed up.
Let's take an example. User1's uid is 1000. That is an AD user and he created files that are stored on VNX1. If you don't configure usermapper per best practices, when you failover, user1 will have a new uid and will not be the owner of the files he created. Create a test cifs server, user, etc. and perform the failover to see how it will work.