This post is more than 5 years old
9 Legend
•
20.4K Posts
0
3276
September 5th, 2011 18:00
NS80 to VNX migration and usermapper
Hello guys,
just need confirmation my procedure will work, here is the plan. I currently have one NS80 and we purchased two VNX5700.
Site 1
NS80
VNX5700-1
Site 2
VNX5700-2
We are using internal usermapper. Both sites are considered active/active. My plan is to configure VNX5700-1 usermapper as secondary and point to NS80. I just have a couple of CIFS servers that will migrate to VNX5700, the rest will be migrated to Isilon. When i finish migrating everybody off NS80, i will schedule downtime on VNX5700-1 and export usermapper on NS80, delete usermapper on VNX5700-1 and import usermapper from NS80. So at this point VNX5700-1 becomes my primary usermapper. Once that is done i can configure VNX5700-2 as secondary usermapper and point to VNX5700-1. Since both sites are production i don't really care which one is the primary site. I also don't have to have replication between 5700-1 and 5700-2 right away. Am i missing anything ?
Steps:
1) During downtime
- on NS80
NS80$ server_usermapper server_2 -Export -user /home/nasadmin/users.db
NS80$ server_usermapper server_2 -Export -group /home/nasadmin/groups.db
- on VNX5700-1.
VNX5700-1$ server_usermapper server_2 -Import -user /home/nasadmin/users.db
VNX5700-1$ server_usermapper server_2 -Import -group /home/nasadmin/groups.db
Thanks
christopher_ime
2K Posts
0
September 14th, 2011 11:00
To answer these questions, let me first recap from my older referenced post the traffic flow between the primary and secondary usermapper databases (UMDB).
NOTE: Reference to "primary array" and "secondary array" below is simply reference to the UMDB role configured on the array
User accesses CIFS share on array: "secondary"
======================================
1) Searches for a local match mapping name/SID <-> UID/GID
2) If it does not exist, then queries primary usermapper (think of secondary as R/O)
a) If it exists on "primary", then skip to "c"
b) If it does not exist on "primary", as primary usermapper it will generate mapping
c) Then, single entry (not entire db) is copied to secondary usermapper
3) or, if it does exist on "secondary", it will be a consequence of step #2 from a previous session by user
NOTE: If it does exist already either on primary or secondary, it is probably being read from secmap cache which saves the system from having to read from the file on disk and instead allows for requests to be serviced from memory where it is cached.
User accesses CIFS share on array: "primary"
====================================
1) Searches for a local match mapping name/SID <-> UID/GID
2) If it does not exist, then locally (as primary usermapper), creates mapping
3) or, if it does exist, then nothing needs to be done (again, likely being read from secmap cache)
NOTE: In this scenario, there is not any communication between primary and secondary usermapper or, in other words, the primary usermapper does not push its entries to the secondary usermappers.
Back to your questions... just to recap your scenario in regards to the first question:
Before starting migration activity (from NS80 to VNX5700-1):
No, nothing changes in your process. Again, you could also before your migration activity set NS80 as secondary and VNX5700-1 as primary usermapper with the steps in the older referenced post which saves you from doing it at the very end when your last CIFS server is scheduled to be cut-over. Either is just as effective though and ensures the VNX5700-1 has all of the existing mappings from the NS80 upon the final cut-over (and more importantly, the same user doesn't have two separate mappings).
In regards to the second question, if you follow the traffic flow for a user that only ever accesses a CIFS share on the array with the primary usermapper, the array with the secondary usermapper won't have a mapping for that user. Therefore, upon switch/fail-over to an array with the secondary usermapper, the following would not be mapped:
btw, I'll have to figure out how you formatted your response with the inline references to the previous post.
christopher_ime
2K Posts
0
September 13th, 2011 02:00
Firstly, let me mention that making sure the usermapper database's (UMDB) are identical in all participating arrays in a migration or replication scenario so that the SRC/PROD and TGT/DR have the same user and group mappings is only strictly required in the following scenarios:
If your environment is simply Windows users accessing CIFS shares comprised of filesystems set at default NATIVE access-checking policy and without quotas, technically you don't need to worry about making sure that user/group names and associated SID's maps to the same UID/GID on both sides. However, I get in the habit of making the relationships below in a simple replication scenario regardless (or exporting/importing the original db's when migrating filesystems):
It takes very little effort, can be done online as noted in the referenced post below, and protects the client in the case they ever do decide to later, for example, enable quotas.
Usermapper primary/secondary in a DR scenario
This previous post also explains the traffic flow between UMDB's and how mappings are "mirrored" in this relationship.
So just to make sure I have it correct:
Then just to recap what you originally proposed:
Yes, I agree changing the default primary/primary UMDB relationship on the arrays is the first step and rarely makes sense to have more than one primary UMDB in your environment. As noted also in the referenced post, the other obvious alternative before you start migrating could be to set the NS80 as the secondary and the VNX5700-1 as primary then migrate the data by following the outlined steps. This would save you having to set it upon cut-over and protect you from the possibility of forgetting to do it before you bring the shares online during the maintenance window. This requires that you start at a common baseline as noted in the post for it to be effective.
Of course, setting the VNX5700-1 as secondary (simply change role and point to primary; an import/export is also unnecessary at this point as it would eventually get out-of-sync relative to the primary since you do not have any users accessing the VNX) then on the cut-over change to primary is fine also, and the steps you listed are accurate. The key is the "-remove -all" as it is not enough to just disable and enable when converting from secondary to primary.
Finally, as for the decision between the VNX5700-1 and VNX5700-2, if you only want to use the internal usermapper databases and have production environments on both sides, I agree since your process already has the VNX5700-1 as the primary, it makes sense to configure the VNX5700-2 as the secondary; again, as long as you don't leave both as primary. If you knew that you were never going to replicate between the two, then of course, there is no reason to make the effort to keep them in-sync, but then again, it really is very little effort to do so just-in-case and your comments did imply they will eventually be protecting assets from each other (bi-directional replication).
Now, keep in mind in an environment where you have users accessing both sides, replication is configured, and you limit yourself to the internal usermappers, note the following scenario you might want to consider where a user only exists on the VNX5700-1. This could happen as follows:
As a result, in its secondary state which is effectively "read-only", dynamox and its associated sid could not be mapped. Depending on business requirements, it may or may not make sense to temporarily change it to primary in consideration of any unmapped entries (which would include any new users never seeing storage on either side). There would be some work to consider on failback when the VNX5700-1 comes back online in this example. With this in mind, you may want to eventually consider an external primary usermapper and point your internal db's on both arrays to that single centralized database. There is a whitepaper describing this process.
dynamox
9 Legend
•
20.4K Posts
0
September 13th, 2011 06:00
Thank you Christopher, this is excellent. Follow up questions:
So let's say i have this scenario: I have two CIFS servers (SERV1 and SERV2). SERV1 gets migrated to VNX5700-1 first, all new and existing users are accessing it on VNX5700-1. At this point all usermapping is still handled by NS80. Now a few week later i need to migrate SERV2. At that point i will perform the export/import steps ..etc. Does this scenario change anything in terms of my procedure ?
Help me understand but i thought that user "dynamox" will be in secmap cache on VNX5700-2 and usermapping will still happen, no new users would be able connect but existing users would work just fine ?
Thank you so much
dynamox
9 Legend
•
20.4K Posts
0
September 18th, 2011 19:00
thank you very much Christopher !
crixsus
9 Posts
0
January 31st, 2012 01:00
Another awesome post Christopher. So I suppose the best practice in a bi-directional Replicator setup between 2 VNX5300s (where both VNX5300s are serving out production data) is to use an external usermapper?