Use Scheduled Nightly PCD Migration instead of DRS to restore CUCM Publisher to VM with different IP address

[kevin.vines]

I'm wondering if anyone is using PCD to perform nightly migrations as an alternative to using DRS.

My use case: We have a CUCM cluster spread between 2 data-centres. The Pub is in DC1. If DC1 becomes a smoking hole in the ground, I need to rebuild the CUCM Pub in DC2 with a different IP address space in a timely enough manner to restore full functionality and having to create a "dead net" to mimic the previous network environment down to DNS reverse lookups is frankly a ridiculous expectation and seriously short-sighted on Cisco's part. /rant *Deep breath* 

Possible Solution: Instead of using DRS backup and restore, use PCD to perform a nightly migration of production data from the PUB in DC1 to a non-production cold-standby PUB in DC2. This would provide the same RPO (Recovery Point Objective) as a DRS backup and restore, but would save the time it would take to build a dead net, build the new PUB and then re-IP it.

Does this sound feasible? Follow-up question: what about the existing SUBs in DC2? They still have a RO copy of the old PUB's DB and are providing call-processing services to the users.

Provided the OS and APP admin users/credentials and the cluster security passwords are the same and the existing subscribers are added to the new publisher either manually or via the PCD migration, can you run "set network cluster publisher" on the old SUBs to point them to the new PUB, then maybe a "utils dbreplication reset all" or would we need to build new SUBs? Provided we have the compute resources available on our hypervisors, it would not be too onerous to have PCD build them for us while the old SUBs continue to process calls, but obviously swinging over the existing ones would be less work.

Thanks for any feedback, additional thoughts, ideas, or comments.

K

[Chris Deren]

I would not recommend that as the PCD process is much longer than DRS backup process and depending on how many nodes are in the cluster and how large is the configuration it might take hours.  Even if you do that and new CUCM is deployed with new IP/Hostnames you would need to update all integrations, gateways, etc to point to new servers. Also, how would you handle ITL certificates, since the reason you would use this is failure of existing cluster you would lose ability of exchanging CallManager/Phone-SAST certificates and you would need to clear all ITL certs manually from all of your phones.

My suggestion is to develop a DR plan that relies on re-store of your system from DRS backup.

[Anthony Holloway]

I had all the same thoughts reading the OP post.

I'm also curious as to why there is a hurry to bring the publisher back up? Why not just run off the subs, and take your time with the Pub?

[kevin.vines]

Hi Anthony, 

I haven't been back to this thread in a while but this problem has come up again. As the Pub is the only node with a RW copy of the configuration DB in the cluster, we would need to restore it as soon as possible to to be able to continue normal business operations. 

Cisco's restore requirements have not changed in years. So either they have deemed the process sufficient or I'm missing a relatively easy way of accounting for the scenario where the DC housing the Pub is a smoking hole. Our networking team is not about to migrate a whole server subnet in the middle of a major disaster when as you noted, the subs are still up and call processing is still working. 

I'm still curious if anyone has been in the same boat and what they did about it. Cisco advises against creating a "dead net" with required network services like DNS, NTP, etc but I'm not sure there is any other solution.