I've been asked to move CUCM servers from one data center to another data center.
The CUCM's currently have an IP on them and are part of the cluster, but have no phones on them at the moment. There is only 1 subscriber that has phones but we are not moving that server at the moment.
Yes you need to reboot the cluster to update the host files etc
Step 5 Reboot all other servers in the cluster, including the publisher node, to update the local name resolution files, such as hosts, rhosts, sqlhosts, and services.
Note These files get updated only during system startup, and the system needs to restart core network services, such as Cisco DB and Cisco Tomcat, after the files are updated. Restarting the servers ensures the proper update and service-restart sequence for the IP address changes to take effect.
They may not have phones on them at the moment, but they may be providing other services such as MoH or TFTP. At any rate you would want to test them after the move so you would want to register a phone them, check that configuration propogates, and that the phone can call phones on other servers.
Various files get updated when you reboot including host tables used for DB replication.. so you want to fix this now rather than cause yourself confusion when you actually come round to using the servers.
Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Short answer? Yes. You don't want to change IP addresses and let it ride. You don't need to reboot all servers at one time. You should reboot the pub, then the TFTP and secondary subscribers, then the primary call processing agent.
If I understand the situation then you will have a service disruption to phones. You have re-IP'd the secondary subscribers and the phones aren't aware of the new IP address until you push out the new config (soft reset should do it). Of course, you will want to have the secondary host on line so that the phones can establish a TCP channel to this node. Then you can bounce the primary. Phones should failover quickly (4,000 phones should take <1 min). Failback is controlled/throttled. It will take longer but the disruption is graceful and impact minimal.
That's assuming db replication isn't fowled up. You will want to check the health of things very closely.
You are correct about the situation I'm in. The subscriber that has all the phones does not know about the other secondary subscribers I have re-IP'd. What do you mean by "until you push out the new config (soft reset should do it)"?
So right now the only thing I've done is re-IP'd the 3 subscriber servers and moved them into a new DC. They are up and running and replication is fine, but they have no phones nor any MOH or TFTP services running.
My first thing would be to do is reboot the publisher.
After this I'm confused as to what to do? Do I need to reboot anything else or can I start moving phones to the secondary subscriber?
I'm confused too...I have about 500 phones i need to move over to another subscriber. There's a way in the web interface to do a controlled move of the phones to the new subscriber...how would i do that?
You need to make a new CM group and a device pool and assign another subscriber's IP address to CM group on top and assign this CM group to new device pool and assign that device pool to phones which you wanted to shift on another subscriber.
The intention is to have that subscriber' IP address on top in a CM group which is assigned to IP Phones.
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...