Here are a few recommendations.
For CUCM 6.x and above, only the Publisher server need be upgraded first. Once
the Publisher has been upgraded, parallel upgrades of TFTP and Subscribers is
supported. The following note indicates exactly what point in the Publisher
upgrade you need to wait for, prior to initiating subscriber upgrades:
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/cucos/7_1_2/cucos/iptpch7.html#wp1179699
General recommendations:
1) I recommend staging any phone firmware upgrades during a maintenance
window prior to the upgrade itself; this will ensure that the TFTP server is
not overwhelmed serving firmware files during the switchover.
2) I recommend performing the upgrades by pointing to a remote FTP server
where you’ve loaded the UCSInstall_UCOS_X.X.X.X.X.sgn.iso upgrade file,
rather than burning individual DVDs for each server in the cluster.
3) I do not recommend disabling the I/O throttling; even though disabling
may speed up the upgrade slightly, leaving it enabled ensures that Call
Processing is not affected during the upgrade process.
4) I recommend selecting “Do not reboot after upgrade” to ensure that
the cluster remains on the original/old version until you are completely done
with the upgrade. For an L2 upgrade such as this, this means there will be
*no* call processing interruption during the upgrade itself.
5) I recommend staging all of the upgrades during one maintenance window
but postponing the switch-over and checkout until a
different maintenance window . Note that between the
“Upgrade” window and the “Switchover” window, all Administrative
changes should be frozen. Any exceptions should be documented so that they can
be re-applied after the switchover. User changes do not need to be restricted
since those will be maintained after the switchover, as documented here:
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/cucos/7_1_2/cucos/iptpch7.html
6) I recommend upgrading the Publisher by itself; once the Publisher is
has completed, I next recommend upgrading half the cluster in parallel, based
on the CM standard Group redundancy configuration; once half the cluster has
been upgraded, I then recommend upgrading the other half. I’d expect
individual subscribers to upgrade in 45-60 minutes (publisher may be twice
this). Most of that time will be spent waiting for the upgrades to complete.
After the upgrade is completed, I would schedule another window for the actual
switchover to the new version:
1) A switch-version should be completed on the publisher first.
2) After the publisher comes up, a switch-version should then be completed
on both of the TFTP servers.
3) After both TFTP servers have come up, all Device Defaults should be
verified to confirm that the desired firmware is selected. Any special
firmware or cop files should be installed on Pub and both TFTP at this
point.
4) After all firmware has been confirmed, the remainder of the cluster
should be rebooted following the reboot order documented this past summer
(likely in two groups… rebooting “backup” subscribers first, then
“primary” subscribers). Unlike a regular reboot window, keep in mind that
the cluster will be “split” during this process, so the reboots should be
done relatively quickly... since no intra-cluster-communication occurs between
servers running different versions, phones/gateways registered to a “new”
subscriber will not be able to signal with phones/gateways registered to an
“old” subscriber. I would expect an individual subscriber to switch-over
and reboot in 15-30 minutes.
Pierre.
