CM 5.x to 7.0 upgrade

[sbtmgr]

First, I'd like to briefly introduce myself and thank everyone here willing to share information to the benefit of us all. I'm with a County Government Agency in Northern California, and given the current economic environment, we sure appreciate these sort of user to user forums where help is available when needed. Thank you all.

On to my question...
We're currently on Call Manager 5.1.x and looking to go to 7.0. Our cluster is comprised of four MCS 7835-H1 Chassis' (one pub and three subs) each populated with two 72.8GB drives in a mirror configuration. It has been our intention with our upgrade to look at increasing the disc space, since in the past we've run into problems, particularly with the log file system.

So we purchased eight 146GB U320 15K drives that are compatible with the equivalent HP DL360 servers, and we're told these drives will work with the MCS 7835 chassis.

Here is my dilemma. Our vendor is telling us that they now recommend the in-place upgrade from CM 5.x to 7.0, because it not only will take a lot less time, but will allow us to run the upgrade without any downtime, but when we're ready to migrate to the upgraded platform we simply reboot the boxes. However, this scenario would not allow us to install and make use of the new drives we purchased...we'd have to stick with the 72.8GB drives.

I don't want to do this, and I understand the only other option is some sort of export scenario to backup our existing 5.x Call Managers, and then after installing the new hard drives, do a fresh install of Call Manager 7.x and import our data.

I guess what I am looking for from the group is any thoughts around what we have planned, and any suggestions or things we should be looking out for.

Thanks again for all your help.

 

[whykap]

First of all your vendor is correct. You can upgrade the system with virtually no down time besides rebooting the servers to the upgraded 7,X partition and let all the phones upgrade to the new loads.
To use the new harddrives you would need to take a sub off line and rebuilt it as a pub to the EXACT same version of 5.1.X you are currently running.
Then restore the database to this server and then upgrade to 7.X. After that is done you will need to bring all the servers down and bring the new pub into service. Then replace all the rest of the harddrives and rebuild them as three new 7.X pubs.
A lot more work and a possible bigger outage. It will definately cost you a lot more service hours as the process will be a lot lengthier.
But if you have to have the 146gig drives you have no other option.

My question is what kind of logs are possibly filling up your drives? Have you turned detailed traces on, on all services and run them all the time?
That should not really be an issue unless you are keeping unnecessary detailed traces and your CDR files are enormous.

 

[whykap]

one clarification here.
I said build the servers as "three new 7.X pubs" previously.
Obviously I meant subscribers and not publishers, just a typo.

 

[pndscm]

I am not sure an H-1 server will meet minimum specs for UCM 7. Specifically the processor. Here are minimum specs for UCM 7.0

Cisco Unified CM is supported on specific Cisco MCS 7815, 7816, 7825, 7835, and 7845 servers or on customer-provided HP and IBM servers that have been verified by Cisco to meet the following minimum requirements:

•Processor speed must be 2.0 GHz or greater

•Physical memory size must be 2 GB or greater

•Physical hard disk size must be 72 GB or larger

For a complete list of currently supported hardware configurations, refer to the documentation available at

http://www.cisco.com/go/swonly

But I've been wrong before.

 

[sbtmgr]

Thanks pndscm. I think our Chassis' meet the hardware specs. I'm having my engineers look into this, although our vendor has never indicated any concern with being able to go from 5.x to 6.x or 7.x on our existing hardware.

Thanks whykap for the info. I'm not sure that the problem with the log filesystem is still an issue. But since we made the investment in the hardware, and we're probably a ways off before we'd consider moving off these hardware platforms, it just seems to make sense to try and make use of the drives if possible.