I'm not sure that hopping through 8.5.x buys you anything except more work here. The compability matrix shows the version you listed to be a single-hop path.
Before the switch versions' takes place, will there be any issues that the Linux OS has been upgraded from REL4 and REL5 and the CUCM is still running 7.1.5 in the active partition? Will this cause call-processing issues?
The problem in this case is that you're looking at a refresh upgrade. The node must reboot to the Anaconda installer to install RHEL5. Because of this each node will be offline for most of the upgrade you can't separate the upgrade from switching version process; it happens all at once. Here's how it'll play out:
- DRS backup.
- Install refresh upgrade COP on all nodes.
- Start administrative change lockout.
- Perform upgrade on publisher (~3.5 hours or longer on MCS hardware)
- Perform upgrade of TFTP and secondary subscribers. Additional comments about the subscribers in the next question. (~3 hours)
- Ensure that the database is in sync on the now-upgraded nodes. (~30-60 minutes)
- Perform upgrade on primary subscribers at the same time. This should be the first step that is user-impacting. (~3 hours)
- Phones will failover to secondary node and then reboot for firmware upgrades. If you have Peer Firmware Filesharing enabled on them this will only take ~20 minutes, excluding WAN delay.
- Phones will then register.
- Gateways/trunks, if properly configured, should also failover. The cluster should effectively be running on the new version now.
- Ensure the database is in sync once the primary subscribers have upgraded. Phones, gateways and trunks will likely fall back before the database syncs so be prepared for a few small oddities during this period.
- Take a new backup.
What would be the longest period that call-processing and device registration will be unavailable during this upgrade? Only when the phones re-home back to primary Subs?
In the 'cucm-readme-862asu2.pdf' document, it states in the Important notes that "...register all devices to servers that are running the same versions of Cisco Unified Communications Manager software. Make sure that you register all devices to the backup Cisco Unified Communications Manager server or to the primary Cisco Unified Communications Manager server, but not to both the backup and primary servers". Will this be an issue with the implementation procedure outlined above?
This is also covered in the SRND under Call Processing Subscriber Redundancy. Nodes can only form an SDL link with other nodes running the same version. If you do not have a clean 1:1 primary/secondary CallManager Group configuration this will result in the cluster being fragmented during the upgrade. Here's an example:
- CMG A uses subscriber 1 for primary and 2 for secondary.
- CMG B users subscriber 3 for primary and 2 for secondary.
- Subscriber 2 capacity is only sufficient to handle one node failing over to it, not both. This is a 2:1 design.
- You upgrade subscriber 2 first, then subscriber 1. When the phones failover to subscriber two they are now on the new version.
- The phones on subscriber three are still on the old version and you cannot upgrade this node until the phones from CMG A have returned to node 1.
- Phones on 3 three can call each other (old version). Phones on subscriber 2 can call each other (new version). Phones cannot call between nodes though; the SDL link is down.
The recommendation is to always keep 1:1 CMG designs (i.e. CMG A has subscribers 1 and 2, CMG B has subscribers 3 and 4). In this design you can upgrade both of the secondary subscribers together without anyone noticing. Once that's complete you start the upgrade of both the primary subscribers forcing all phones/gateways/trunks to failover to their secondary nodes in a coordinated fashion. Essentially you're doing a Side A/Side B "flip the switch."
So, what will the outage to phones be? If you're following the 1:1 design it should only be as long as it takes the phone to upgrade firmware and re-register to the secondary subscriber. A subscriber can complete ~100 device registrations per second so take ~20 minutes for firmware upgrade and tack on a few minutes to account for WAN delay and registration processing. There will be a secondary blip when phones fallback to their primary node but this only take a moment.
Will a cluster reboot of the phones be required at the 'Enterprise Parameter' level once the cluster has been upgraded to 8.6? I saw a comment somewhere about this being a requirement.
Usually not. You can use this as a trick to force a reboot to notice the new firmware on the TFTP server. Just keep a phone near you and see if it auto-upgrades its firmware when failing over. If not just force a reboot of the devices, optionally in smaller chunks (e.g. by device pool).
Please remember to rate helpful responses and identify helpful or correct answers.
