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.