Message store migration question

Question

Howdy. We are currently testing migration methods between a currently running 5.2 Messaging Server (iPlanet Messaging Server 5.2 HotFix 2.18) to a newly installed 6.3 Messaging Server (Sun Java(tm) System Messaging Server 6.3-0.15).
We are not running a front end Message Multiplexer so we will suffer some downtime when switching from the old hardware to the new hardware.
In order to minimize the downtime, we thought that the quickest approach would be to rsync the 5.2 message store onto the 6.3 machine. Due to the fact that the old machine has 8 message store partitions and the new machine has 20 message store partitions, we are doing rsyncs at the user level of the message store (i.e. users end up in different partitions on the new server). Because of this, we cannot migrate the message store databases.
It appears to us that the message store itself is capable of holding all necessary flags/states/etc. and that we only need to reconstruct on the new system. However, it also appears that stored is "lazy" about updating new data in the databases out to the "store.sub,store.usr,etc." files. When we do our final shutdown of the 5.2 system, we would obviously want the store.* files updated so as to be consistent with the data in the message store databases so that our final rync copies complete consistent data.
We are at a loss as to how to cause stored to flush/backup/whatever its database information out to the store.* files.
Is there some way to do this or is our whole migration strategy bogus?
Vern Gerein
Senior Systems Administrator
Server & Database Services
University of Saskatchewan
Great White North

Answer 1

trepan wrote:
If you are migrating I would highly recommend that the newly installed machine be at the latest patch release. 120228-28 is available on sunsolve.We were waiting for the latest from sun support but they didn't toss it our direction yet. I'll get a co-worker that has an account to grab it from sunsolve.You should be able to access it using the same login as you are using to post to this forum. It is a publicly available patch.
How large a move are we talking here (size/messages/users)? Also are you using messaging express or just IMAP/POP access?1.4 TB / 35 Million messages / 85,000 users. We are using messaging express and IMAP/POP on the old hardware. We will only be using IMAP/POP on the new hardware (no messaging express).
Expect to see an increase in overall disk usage due to single-message-copy links being expanded with the increased number of partitions.Our first test rsync from a live system went from 1.4 TB on the old system to 1.6 TB on the new. It is no worse than we expected. I was assuming we'd get a bit of that back if we ran a relink step after the migration.Correct -- the relinker will help to recover some space.
If I was in your position (and I used to be), I would be looking to add an MMP into the equation so that you could perform user-by-user migrations. This would > allow slower/online migrations which will reduce risk of something going wrong in the move. You can gradually increase the load on the MS6.3 system.We love the idea of being able to do a slower/online migration as you suggest. We had thought about this already be we foresaw one problem with this approach:
Our current email machine (mail.usask.ca) is used by a LOT of clients so we cannot just deploy a new MMP front end and then ask our client base to now point to that. The only way for us to deploy a MMP front end would be to have it named mail.usask.ca and to change the name of the current 5.2 box to something else. Actually there is another approach that you may not have considered.
1. Install a 5.2 MMP on the current email machine and reconfigure the existing server to listen on another port for IMAP/POP e.g. 1143 for IMAP and thenn specify the backend port with the MMP so mail.usask.ca:143 (MMP) goes to mail.usask.ca:1143 (backend) for example.
2. Install and configure new system with a different hostname e.g. mail-server1.usask.ca and configure to listen on the same ports as used in (1)
3. To migrate the accounts, use the MoveUser utility, this will change the mailhost so email will be redirected and client connections will go mail.usask.ca:143 -> mail-server1.usask.ca:1143
4. Once all users are migrated, assign the IP for mail.usask.ca to a new MMP frontend server running MS6.3 MMP and MS6.3 MTA.
NOTE: Step (3) WILL break Messenger Express access but as you said there was no plans on providing ME access on the MS6.3 server this shouldn't be an issue.
Alas, I don't know of any way to quickly rename an existing Messaging Server (the host name etc. is embedded everywhere, LDAP, configuration files, etc.). The only way I can think of is to reinstall the software. And even if one managed to rename the box, what would it then do with messages that are still in the queues? Of course, I could be missing something simple/obvious.It is possible to do this and requires a lot of planning and testing. Basically the idea is to configure messaging server to recognise itself as two names (mail.usask.ca and mail-server1.usask.ca) and then slowly change the various settings (e.g. users mailhosts: value) from the old hostname to the new hostname. Eventually you work through all the settings till only the clients themselves are actively using mail.usask.ca at which point you assign the IP to a new MMP. If there is a problem you assign the IP back, fix the issue then try again.
When migrating from Netscape 4.15 to iMS5.2 I had the exact same issue but it was further complicated due to the use of Messenger Express. Since you are not planning on using this going forth this makes things much easier.
Is there a easy/quick/utterly-and-completely-safe way to rename an existing production 5.2 Messaging Server?Easy, no. Quick, no. Utterly-and-completely-safe, no. But with time, planning and testing it can be achieved.
Or am I thinking about this in a completely wrong way?There are two approaches mentioned above. I suggest you think which one is going to work for you. In my case I was told in no uncertain terms, the 'migration' must be flawless (i.e. completely transparent to the end-user). It was -- from planning/(re)testing/debugging/customisation/integration to completion took me 12 months (albeit elapsed not effort time).
Regards,
Shane.