All nodes are running on MCS-7845H2. The Publisher had HDD upgraded to 146GB, the rest of the nodes still have the original 72GB HDD. All servers have 4GB RAM. My plan is to upgrade to CUCM 8.6.2aSU2 and at the same time convert the hardware to UCS 210M2. I have verified the supported upgrade path, compatibility matrix, supported hardware, etc, but I want to skip a number of steps (ie upgrading all the existing servers, backing up, only then to convert them to UCS and restore them again). I'm considering the following upgrade method:
Upload CCM 8.x software feature license ahead of time
Upgrade the Publisher to 8.6.2aSU2 on the MCS-7845H2
Once pub is running 8.6.2aSU2, shutdown the 7.1.5SU4 TFTP servers on MCS-7845H2
Spin up the 8.6.2aSU2 replacement servers on UCS with OVA template for TRC1 (using same hostname, ip addr, password, etc). This will be like replacing a subscriber or adding a new subscriber to an existing cluster.
Upload all the necessary custom logo, phone firmware, etc, start the tfp service
Once TFTP servers are ready, shutdown call processing nodes (one by one of course) on MCS-7845H2
Spin up the 8.6.2aSU2 replacement servers on UCS (same OVA template for TRC1). Again using the same hostname, ipaddr, password of the server it is replacing. Because the original server is already shutdown, there is no ip conflict
Once all nodes are replaced with 8.6.2aSU2 running on UCS 210M2 hardware, verify DB replication is good (all 2) and phones are registered, backup the entire 8.6.2aSU2 cluster using DRS
At this point, the cluster has the following:
1 Pub on MCS-7845H2
8 subscribers on UCS 210M2
All nodes are running the same CCM version
Verified back up is 100% completed, power down the Pub on MCS.
Spin up the replacement servers on UCS (again same hostname, ipaddr, pw, etc)
Restore the DB from previous backup (only restore the Pub node). Same as restoring a Publisher procedure
Rehost the license before the 30 days grace period
At this point, all servers are running on UCS hardware with 8.6.2aSU2 version
I have tested this procedure in the lab with a smaller cluster duplicating as much of the production environment as possible. Everything seems to be working. However, I'm concern that the lab don't represent the true production cluster and I may have missed something. Also this is not a secure cluster, so I don't think certificate will be an issue.
Will work or will I have problems? I appreciate any comments or input.
Any reason why I need to shutdown all the SUBs? I believe if there is a version mismatch, DB replication will not work anyway. Although this will be done during maintenance window, there are about 15K phones registered and I want to minimize service impact as much as possible. This is how I plan to minimize impact:
Upgrade PUB. No phone reset (no change can be made to the system). Ensure device defaults use the same phone firmware as before the upgrade (avoid phone firmware upgrade)
Upgrade TFTP servers. No phone reset. New TFTP servers will sync with new PUB
Upgrade secondary Subscribers. No phone reset. New subscribers will sync with new PUB
Upgrade primary Subscribers. Phone re-register to new secondary Subscribers (no firmware upgrade). New subscribers will sync with the new PUB
Cluster should now be synced (verify on PUB with command "utils dbrep runtimestate")
Although, I've enabled PFS (peer-firmware-sharing), I still want to avoid upgrading phone fw en-masse because it could have huge impact on our WAN.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...