Cluster Switch Version - Minimizing Downtime

[Sean McQuade]

Hi guys,

We are due to do a switch version for a customer with a PUB/SUB configuration. Both have had the update installed and sitting in the inactive partition.

In the past, what I would have done is to disconnect the SUB from the network, switch version on the PUB, allow it time to come up and for the phones to upgrade and re-register. After this, I would switch version on the SUB, allow it to come up, and then re-connect it to the network.

In this case, there is no time when the business is completely closed so the customer is worried about minimizing the amount of dowtime. Reading the documentation, I have found:

All servers in a cluster must run the same release  of Cisco Unified Communications Manager. The only exception is during a  cluster software upgrade, during which a temporary mismatch is allowed.

Does this mean I can switch version on the PUB whilst leaving the SUB connected and have the phones failover to it, then wait for the PUB to come back up again before performing the switch version on the SUB? To me this seems a bit dangerous as there will be a version of the database on two different version numbers?

Thanks

Sean

[will.alvord]

Yes to the last section.  The best practice which is pretty much a version-agnostic way to do it (but check the SRND for any possible changes):

1) Upgrade the pub

2) Upgrade sub 1

3) Upgrade sub 2

etc

edit: I didn't address your database concern.  That was the 'mismatch allowed' caveat which you found.  This is part of the upgrade process.

[Jaime Valencia · Accepted solution]

That's perfectly normal, and that's what most people do.

Obviously at that time, there won't be any communication between servers until they reboot and load the new version.

Bear in mind that the upgrade only contains up to whatever you had at the point where you installed it, any changes made to the system going forward, will be lost once you switch.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Sean McQuade]

Thanks guys,

Yep we are aware of the database only contraining info at the time of the upgrade but this isn't a problem. Just to clarify, can I safely:

• Switch version on the Pub to v7 leaving the Sub running v6. While the Pub is down, the phones will register to the Sub
• When the Pub switch version to v7 is complete, the phones re-register back to the Pub and pull down updated firmware
• Switch version on the Sub from 6v to 7v

This will all work correctly with no sort of database issues?

Many thanks

Sean

[Aaron Harrison]

Yep.

1) Upgrade all servers, pub first.

2) Reboot one-by-one.

Usually the biggest outage is when (assuming it doesn't break :-)) the phones are downloading firmware. Not a huge amount you can do about that....

Aaron

[will.alvord]

You can check the release notes for firmware versions and upgrade firmware prior to the cluster upgrade.  Then you have more control as to when the phones upgrade their code and which groups of phones get upgraded when, etc.

[Rob Huffman]

Hi Sean,

Your process is spot on! Make sure you leave lots of time for the Pub

to fully come back online after doing the switch version before starting the Sub.

Other than that you look good to go;

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cucos/7_1_2/cucos/iptpch7.html#wp1179637

Cheers!

Rob

PS: +5 for Will, Java & Aaron for their great work here

"Clocks go slow in a place of work
Minutes drag and the hours jerk" 

-The Clash

[Sean McQuade]

Thanks for all your great answers guys