Time Estimate for Luminis Platform IV Upgrade

0
No votes yet

I have been reading some of the scary posts about upgrading to Luminis IV. I am currently sitting at Luminis III.3 and was wondering how long it would take to get Luminis IV installed. We are going to try a 2 box install with a Solaris 10 T2000 server. As I understand it, I would need to first install 4.0 on the new servers. Then migrate the data from 3.3 to 4.0. Then upgrade to 4.0.1. Then upgrade to 4.0.2. Then finally to 4.1. The trouble I am seeing is that since the data is going to migrated at the 4.0 stage, this could involve some lengthy down time of our production environment (we don't want people logging into 3.3 once we migrate the data).

Does anyone have a time estimate of how long this upgrade should take?

I read where SungardHE took 3 weeks to install this for a client. My boss will kill me if I suggest a 3 week down time. I hope the install has gotten better since some of these scary posts were made. Any insight would help. Thanks.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Time estimate details

I just did this a few weeks ago. (III.3.3 to IV.1.0.15 on Solaris 10).
Planned downtime was 24 hours, actual was about 12. Could have done it in 8, but for an unexpected problem with calendar import that took a number of live hours to solve.

The key(I think) is preparation. Practice installs and migration a lot and have a checklist.
We had our LP4 box sitting and waiting at 4.0.0.0 prior to migration day.

Migration timetable looked something like this;
- Export from III.3.3 30min
- copy to LP4 30min
- migrate platform and calendar 3hrs. ( +4 hours fixing calendar import core dump)
- perform 4 updates to 4.1.0.15 2hrs
- customizations and cleanup 2hrs.

Bob.

platform change

Ok - so I read that and you have to import your III.3.x data into a 4.0 instance ... not a 4.1.x.x.x.whatever-they're-up-to version ?

Oh crap.

Plus I heard a NASTY NASTY rumor that the migrations scripts don't support cross platform migration. So since I wanna leave windows for Linux .. it sounds like I'm SOL.

Can anyone verify both of those horrid thoughts ?

I knew I should have stayed in bed this morning.

-Jon

Hey Jon, I would do some

Hey Jon, I would do some testing on that. We went cross platform from HPUX to Linux successfully (still in test mode though). Also you may be able to migrate without using the migration script. Brad Vacura from SCT gave a good session on this at Summit 08.

As of the last documentation that I have, they say you have to migrate to 4.0.0. We found that applying the patches was pretty quick and painless though.

One problem we just found out was that, the migration script does not export anything out of the database during export, but rather does it "on the fly" when doing the import. We wanted to do an export of our production data to try and make an estimate of how much downtime we will need when doing the actual migration. But knowing this, I don't know how feasible this will be if we have to have the system unavailable while doing the import as well. Has anyone tackled this issue?

vmware

we cloned our production environment into VMWare, then using some network/host file mojo, used that as our 'production source' while testing our migration. We're windows, so there are a lot more tools on the free end. If you license VMWare, I think you can easily clone unix boxes as well (although that clone tool is pretty freaky.)

cloning using vm

Has anyone tried cloning, for instance, a PROD system into a virtual machine, then modding/reconfiguring that vm into TEST?
This would involve some configman settings as well as lots of files with hardcoded references to the my.prod.school.edu URL and so on. I can use Oracle to make a duplicate database, and the network team will take care of changing the IP address, MAC addcress, etc. Seems like if that could be figured out, it would be a lot easier than the 'replicator' process which involves a fresh install and then reconfiguration (which I haven't tried yet).
Please, someone who knows more than I do, tell us if this is feasible.

yes on cloning

We use the zfs snapshot along with zfs send/receive to create our test systems.

No configman or other changes are necessary. Simply create a small DNS server+host files that makes all the addresses map to the test machines rather than the live.

givin' in a whirl

I'll get set up to try out a migration, I'll post my success/failures as I go.
I'll back my box down to 4.0.0 again - I had modded the heck out (go figure) of it thinking I'd backend the data later - oh well. If I did it right, it shouldn't take too long to remod

-Jon

Time Estimate for Luminis 4 Upgrade

I have the same concern regarding the migration time. We're planning to upgrade from Luminis 3.3 to 4.x Running on Solaris 10 w/containers. The mail size is 475GB and we've been told that based on 70 GB ,it can take 32-40 hours to complete. Obviously being down even 40 hours is unacceptable.

Surely there must be alternative methods to migrate with minimal downtime.

mail server

I was able to do my migration in about six to eight hours, but I was only doing a platform and calendar migration. If your migrating email, it could be a huge and long ordeal.

More info

A few comments:
Cross - Platform: Yes Jon, it's true. Cross platform migrations are not supported, but there are a number of institutions that seem to have done it. Mostly, however, they are from unix to unix (HP to linux, or whatever). I think Windows to unix probably ratches it up a bit. You will probably need to dig into the migrator script and export files. I would imagine the first thing to be concerned about in Windows to unix is CR/LF vs LF on the exported text files. That's the first thing I'd check. Write a script, or get one written for you, that makes this change to the Windows exported text files. However, I think that moving from Windows to unix is such a worthy cause that it is worth the effort. Lock yourself in a room for a while.

Database access during migration: Yes it is true that the LPIII database must be available during migration. However, this is a read only operation. I did a number of test installs and migrations of Luminis 4 while my LPIII was still up and running and being used as a production system. The database component of Luminis is fairly small compared to the other stuff such as group tools data and LDAP.

As well, the migration manual says you must use a different database instance for LP4. You don't really have to. We use the same Oracle database instance for LPIII and LP4, but use a different schema name. LPIII used a schema name of luminis and LP4 uses a schema name of luminis4. The migration operation reads from luminis schema and writes to the luminis4 schema in the same database instance. Of course, after a test migrate, I would truncate all the luminis4 tables and did a final truncate before the real migration.

Email size: We use Messenger Server as our enterprise mail server and so had to upgrade this as well. Not sure the size of our mail store, probably over 100G but maybe not as high as 500G. Our mail team did a trick that was suggested by a consultant we had in. The made sure the mail store was backed up, then they unhooked (sorry for the non-technical terms) the mailstore from the MS5.2 and mounted it to the MS6.2 new server, then transformed the store in place. I think this saved a lot of time. It took about 6 hours to complete.

Test it yourself, lots of times....

bob.

Database Migration Question

Hey Bob... When doing the import, you didn't see any issues while running this against your production database? Did you do this at an off hour/day? We would really like to arrange a time to do this ourselves, but were concerned about the downtime.

Thanks!

Migration using a live server

I did a number of test installs while our productions Luminis III server was running. No problems.
As mentioned, the database component is quite small.
Bob.

database during imports

Hi,
I think it's possible to expor the L3 database at the same time as you run the migrator script in export mode (for us simply use Oracle "exp") then use oracle export to populate another offline database and use the settings

source.database.type=oracle
source.database.host=mydbhost
source.database.name=luminislive
source.database.user.id=luminis
source.database.user.password=****

in the migrator import properties file to get use the copy rather than live.

If I've got this wrong please say !
rich

Another database instance

I can't see why this wouldn't work. The migration process doesn't care where the supposed live LPIII database is, as long as it can read it.
Bob.

Diary of a Madman

Thanks to Bob and everyone who have posted helpful comments about the time estimate. I think the most helpful comment (so far) was to do a lot of test installs. I am currently on my 9th failed install! Yeah, I am happy!! I have been creating a diary for each install attempt. Most of the problems are OS related so far. What scares me is that I have not even gotten to the migration or customization phase yet. I am still in the very beginning trying to kick off the initial install:

./LP-4.0.0.0-solaris ./install.conf

If this ever works without failure I think I will start crying tears of joy.

Here is my recommendation to SungardHE. Sell servers pre-installed with version 4.0.0.0. Everyone has to start on new servers anyway, right? Then we would only have to worry about the migration phase!

Review this lumdev thread

If you have not done so, review this lumdev thread that many of us used to post our Solaris installation woes and fixes : http://www.lumdev.net/node/1232. You have to remove some of the Sun packages that come pre-installed with Solaris when doing the IV install, as some of the items will conflict with the ones the Luminis installer wants to put into place when it runs the JES installer.

&bnsp;  Alice Kim