Usermapper primary/secondary in a DR scenario

Ok...solved it

I've created an additional interface on both NS and point to this ip address and now all works...

[nasadmin@NSB00 ~]$ server_usermapper server_2
server_2 : Usrmapper service: Enabled
Service Class: Secondary
Primary = 172.31.79.200

thanks

Matteo

As pointed out earlier, you will typically want your DR environment (using your references: "NSb") to be running with the primary usermapper db and the production array ("NSa") running as secondary.  This is a strategy to ensure both db's are mirrored automatically.  Currently you have just configured it the opposite of what is recommended.

If you were to fail-over, switch-over, or reverse replication, unless you are handling exporting and importing the user and group mappings manually, the DR usermapper database configured as secondary would not have a copy of what is available on the production array.  In a disaster condition where the production array is not available, you will find that the DR Celerra would not have any way to associate the users to the data (or would do so incorrectly).  For what it is worth, at least you did not leave both at the default of primary which has worse consequences; in your current configuration there will simply not be any new mappings generated if just the secondary is available.  In the recommended configuration as noted above, the way the communication and updates to the db would occur is as follows:

I will assume the following (if any of the assumptions below do not pertain to your environment, then possibly this whole post is irrelevant):

a) Replication is occurring from Production array to DR array

b) This is a CIFS environment with users accessing just the Production array (until fail-over, switch-over, or reverse replication)

c) Bi-directional replication is not involved

d) For sake of this conversation, I will ignore secmapcache

PROCESS

========

1) User accesses share on CIFS server on "NSa"

2) Configured as secondary usermapper, "NSa" searches for a match mapping SID <-> UID/GID

3) If doesn't exist on "NSa", then queries primary usermapper "NSb".

a) If it exists on "NSb", then the mapping is copied to secondary usermapper "NSa".

b) If it doesn't exist on "NSb", as primary usermapper it will generate mapping, then entry is copied to secondary usermapper "NSa"

4) If it does exist on "NSa", it will be a consequence of step #3 from a previous session by user

If you were to step through the process with your current configuration, you would realize that the secondary usermapper will never get updated.  In a disaster scenario where the primary db is not available, the Celerra would not be able to map any users to their data which is now online in the DR environment.  Again, as noted above, at least both arrays were not left at the default of primary usermapper which would cause it to effectively remap all users that access it on the DR site, as it would start over at UID/GID of 32767 (or from the last entry in the db).

I hope this makes sense, and more importantly I am not misrepresenting anything.

Chris -

Professional services seems to have left me in that circumstance - my production NS is a primary usermapper and my DR NS is also a primary, but is only a replication target.  Is there a process/procedure to turn my DR NS into the primary userampper during an upcoming downtime window?

Thanks!

and to add to Karl's question. Is there a way to export usermapper from production to DR and reconfigure the roles ?

Hi,

during my first post I've not explained all my scenario.
There is 2 Datacenter in the same campus (1Km between then). The celerras are active-active:
NSa is primary for most FC lock access (Vmware, CAD/CAM, Exchange, ...) and 2 cifs server ( backup, home DIR)
NSb is primary for 10 cifs servers and SAP production (FC).

I've configured NSa as secondary usermapper because it has got less CIFS server than NSb. So I consider NSa as disaster recovery.

During NAS course, the teacher has told me that in case of really disaster, when the primary usermapper is unavailable I'm able to "promote" the secondary usermapper as primary without problems...is it correct? He told me that a only "client" usermapper can not be promoted.

thanks

Matteo

After re-reading the User Mapper documentation for DART 6.0, I've worked up the following procedure.  Can anyone who's been through this comment if these steps are correct and in the right order?  I have a downtime window when I can shutdown the production Celerra and know that no new accounts will be created.

Step 1. - Export the Usermapper database on the primary (production) Celerra:

primary-nas$ server_usermapper server_2 -Export -user /home/nasadmin/backup.passwd
primary-nas$ server_usermapper server_2 -Export -group /home/nasadmin/backup.group

Step 2. - Stop the Primary Usermapper on the primary Celerra:

primary-nas$ server_usermapper server_2 -disable

Step 3. - Import the Usermapper database on the secondary (DR) Celerra:

dr-nas$ server_usermapper server_2 -Import -user /home/nasadmin/backup.passwd
dr-nas$ server_usermapper server_2 -Import -group /home/nasadmin/backup.group

Step 4. - Start the Primary Usermapper on the DR Celerra:

dr-nas$ server_usermapper server_2 -enable primary=141.213.78.89 (a public IP on the DR Celerra)

Step 5. - Start the Secondary Usermapper on the production Celerra:

primary-nas$ server_usermapper server_2 -enable primary=141.213.78.100 (a public IP on the production Celerra)

I'm assuming I have to set an external IP address on the primary Usermapper in Step 4, so that the primary is listening on a public interface, not just loopback.

Please let me know.

Thanks!

Karl

As always, test if you can before (the usermapper -Export files are flat files that can be imported in any Data Mover usermapper)

Claude

On the DR site, you could first export the usermapper DB before processing (so that you have a "clean" DB that you can re-import)

This is more important if this is an active/active IP Replication configuration and you want to switch role between Primary and Secondary usermapper

On the DR side, when you import the usermapper DB you should not need to stop usermapper (I think it has to be started in order to import)

The -Import option will add any mapping which does not exists in the DB. If a user or group already has a mapping then it will not be overwritten

On the DR side when starting usermapper you do not need to specify an IP address (starting usermapper with an IP address tells that usermapper service that is is secondary and that the primary is at the IP you specify in the command line)

If you do not clear the usermapper DB on the Primary site, then the entries will remain there (but it's ok since they are already in secmap on Primary and already assigned to files that were created before the change)

Claude

Quick correction.  Step 0b should reflect test of network access from secondary to designated primary interface which was correctly stated in paragraph; just swapped in the sub-title and command.  Therefore it should read (corrections in red):

"PROD: Verify that you have network access between datamover interfaces"

prod-nas$ server_ping server_2 DR Celerra>

Don't see a way to edit my existing posts.

Firstly, let me repeat the assumptions I made in the post above before I begin:

primary-nas") to the DR array ("dr-nas")
b) This is a CIFS environment with users accessing just the Production array (until fail-over, switch-over, or reverse replication)
c) Bi-directional replication is not involved

Here are several new assumptions for the sake of this post:

==============
0a) PROD and DR: Export users and groups

Before I even start, I export the mappings on all Celerra's involved even if I expect one site to be blank.  Again, as noted above, it is simply validation of this ahead of time.  These files won't be the ones that get imported, and also during the process of disabling, transferring, diff'ing, merging (if necessary), etc. I feel more comfortable having a recent "backup".  However, this is largely optional.

I also have my own preference for naming, but of course this is arbitrary.

primary-nas$ server_usermapper server_2 -Export -user /home/nasadmin/users.bkp
primary-nas$ server_usermapper server_2 -Export -group /home/nasadmin/groups.bkp

dr-nas$ server_usermapper server_2 -Export -user /home/nasadmin/users.bkp
dr-nas$ server_usermapper server_2 -Export -group /home/nasadmin/groups.bkp

0b) DR: Verify that you have network access between datamover interfaces

Simply so you aren't finding out during the process in step #5 and aren't wasting time troubleshooting unnecessarily extending your change window.  The command will fail if the secondary can't reach the primary via the designated IP.  As noted though in step #5, it makes sense just to use the same interface already being used to replicate data so should not be an issue (in a healthy environment).

dr-nas$ server_ping server_2

0c) Confirm current usermapper roles

primary-nas$ server_usermapper server_2
dr-nas$ server_usermapper server_2

Output will inform you:

primary-nas:
Usrmapper service: Enabled
Service Class: Primary  <= Goal is to set this to Secondary

PROD: Disable primary usermapper

Why do this first?  This would ensure that no new users sneak in.  If you export first then disable, even in the split second that you can type/paste the commands in, a new user(s) may access the CIFS environment, and now your exported entries are out-of-sync.  It is also worth noting that this is the point at which new users won't be mapped, but again, existing users will continue to be read from secmap cache first:

primary-nas$ server_usermapper server_2 -disable

2) PROD: Export users and groups (these are the copies that will be used for the import and not the ones from step "0")

primary-nas$ server_usermapper server_2 -Export -user /home/nasadmin/users.db
primary-nas$ server_usermapper server_2 -Export -group /home/nasadmin/groups.db

Karl, you have a step to enable primary usermapper on the DR Celerra; however, again the scenario we are handling is that it was left at the default: both production and DR are primaries.  You would not need to do anything to the DR Celerra usermapper service except to import the mappings from the above step.  Also, as pointed out already, for a primary usermapper, you don't specify an IP, as it exists on the datamover to be accessible via any of the interfaces.

3) DR: Import usermapper entries (from step #2 above)

dr-nas$ server_usermapper server_2 -Import -user /home/nasadmin/users.db
dr-nas$ server_usermapper server_2 -Import -group /home/nasadmin/groups.db

4) PROD: Change source celerra's usermapper to be secondary
Makes sense to just use the interface you are already using to replicate the data.

primary-nas$ server_usermapper server_2 -enable primary=

Another recommended step could be:

3.5) DR: (Re)export the usermapper entries and perform a diff just to make sure they were imported correctly

this is good stuff Christopher. Let me give you another scenario ..how would your process change ?

Let's say i get a brand new Celerra today and need to migrate to it from another Celerra. I would like to perform "gradual" migration where i migrate a couple of VDMs at a time. So when the new Celerra is installed, i am going to configure its usermapper as secondary and point it to the old Celerra. When i am done with my migration and getting ready to push my old Celerra out of the door ..what do i do in terms of usermapper ? Same steps as you describe above ?

Thank you

What I would do in your migration scenario is perform the steps in my earlier post to achieve the following:

databases start out identically
3) set the original Celerra as the Secondary usermapper

You can even do this before you start migrating and you shouldn't have to think about it again.  You don't even have to wait until you bring the first VDM (and CIFS server, filesystems, and shares) online on the new array; really for all intense and purposes, it is no different than the replication scenario described above.  This way you know that the new Celerra, which is going to remain, will have at least the same mappings as the original but likely more; for instance, an unmapped user only accesses the new Celerra (Primary) and never accesses the original Celerra (Secondary).  Conversely, following the flow in my first post, if an unmapped user accesses the original Celerra, it will query its Primary usermapper which is the new Celerra, the new Celerra would as Primary assign the mapping, and then also sends that value to original Celerra.  Consider that for whatever reason you have to bring the filesystem back online on the original Celerra (typical "plan B" if you realize that upon cut-over the migration didn't go as planned), this is handled properly since as a secondary usermapper if it doesn't exist in its local database it queries the primary usermapper.  Again, follow the flow in my first post.

Alternatively, you could leave the original as primary and set the new to secondary as you mention and would be fine all the way up to the point when you are ready to power down the original array.  Before decommissioning it, you would have to remember to set the new array to primary and export/import the mappings.  Say, you forgot to; simply recall the flow from my first post and think about what would happen if a user only ever accessed the original array and never the new one in this relationship.  That user which already had a mapping on the original Celerra, now accesses the filesystem on the new array that you brought online, it will get mapped by default, to the next available UID/GID (starting at 32768).  Unlikely it would have the same value; and therefore, would potentially have access to files/folders it shouldn't and similarly not have access to files/folders it should.

Just to mention it, the conversion from a secondary role to a primary role involves the following steps:

NOTE: you can't simply disable it and reenable it as it will just reenable as a secondary usermapper (for conversion from primary to secondary, follow the steps in the earlier post)

1) server_usermapper server_2 -disable

2) server_usermapper server_2 -remove -all
Keep in mind that this step clears the local database effectively uninitializing usermapper

3) server_usermapper server_2 -enable

So in summary, in this scenario, leaving both as primaries could have undesirable results or setting the new to secondary as you suggest will be fine up to the point you finally decide to decommision the array but you have to remember to export/import the database and switch the new Celerra from secondary to primary.  Hopefully this all makes sense, and I was able to convince you that the relationship that makes the most sense would be as mentioned at the top of this post.

Christopher, this is absolute money!  Thanks very much for providing so much detail in every step, and especially the tests and comparison with diff.

These steps are so clear, this should go in the usermapper manual, since this is exactly why someone would even monkey with the usermapper in the first place!

excellent ..thank you so much Christopher.