Cisco Call Manager DR situation

Answered Question
Apr 21st, 2010

Hello,


We have 2 Cisco Call Manager in  our site and place in 2 different locations connecting via a layer 2  network.

They form a cluster group and the production one is the  publisher and the DR one is the subscriber.


In the DR situation, if the  layer 2 connection between 2 CCM is broken, is it possible to change the  subscriber to be the publisher and make changes on that?


Would you  please guide me how to do so?


Thank you.


Best Regards,


Terry Chow

Correct Answer by Aaron Harrison about 6 years 10 months ago

Hi


What you need to do is either:


1) Have your publisher permanently situated on the other site, so you can make admin changes when the main site dies.


- OR -


2) Have the normal configuration set up so that if the call arrives on your DR number that it is already configured to go to site C.


This would mean that you need to have your 'DR' number of 12340000, when it arrives at the gateway at Site B, translated to 56789012. This will mean you need a dedicated number assigned for DR; this way the only thing you need to do in a DR scenario is have your service provider do the rerouting.


If 1234000 is the same number that arrives in non-DR scenarios at Site A, then you would need different CSSs assigning to the gateways at Site A and Site B so that depending on where the call arrives, it will be sent to the correct destination.


Regards


Aaron


Please rate helpful posts..

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
David Hailey Wed, 04/21/2010 - 21:09

Terry,


This is unfortunately not a DR setup that you have.  In fact, it actually goes against the best practices of the SRND for designing a CUCM cluster.  So, to answer your question - can you change the Subscriber to be a Publisher and make changes on that?  The answer is NO.  This is currently IMPOSSIBLE.  There has been talk of Publisher redundancy being added to CUCM versions; however, there is none to date.  If the Publisher is down, the primary DB is down.


As for your setup, this is how a CUCM cluster is supposed to be configured:


Publisher - no active phone registrations, no call processing.  It can run the CCM service but in ordinary circumstances all registrations and call processing are done by the Subscriber.  This leaves the Publisher to handle 2 primary services - the first being the Database and replication.  The second typically being TFTP.


Subscriber - subscribes to the DB on the publisher.  Cannot be converted to a Publisher in any scenario other than complete rebuild and essentially creating a new cluster.  All phones should register to the Subscriber and all call processing should be done by the Subscriber.  In the event that the Subscriber fails, phones can register to the Publisher as a backup call processing agent.  When the Subscriber comes back online, phones failback to it.


These are best practices and well documented in the SRND.  You also do not need to extend an L2 VLAN across locations to accomodate a cluster.  In fact, I don't like this approach at all personally.  The cluster can exist with L3 routing as long as latency between sites is within the specs outlined in the SRND.


My recommendation would be to revisist your architecture and if you need a viable DR solution, then we can discuss ways to achieve this.


Hailey


Please rate helpful posts!

Jaime Valencia Wed, 04/21/2010 - 21:33

As Hailey said, you should follow SRND recommendations. You're doing the total opposite of what's recommended.


Unified Communications Deployment Models

For a distributed call processing deployment, each site has its own call processing agent. The design of each site varies with the call processing agent, the functionality required, and the fault tolerance required. For example, in a site with 500 phones, a Unified CM cluster containing two servers can provide one-to-one redundancy, with the backup server being used as a publisher and Trivial File Transfer Protocol (TFTP) server.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/models.html


In your current scenario having a DR plan would mean to configure regular backups in case something goes wrong. Then you could restore your servers.


HTH


java


if this helps, please rate


www.cisco.com/go/pdihelpdesk

chowterry Wed, 04/21/2010 - 23:11

Dear Friends,


Thank you for your reply, the case I have is, when in DR situation, that means the production site is totally failure including data and voice network connectivity. The service provider will re-route our numbers to another location, that is our DR site, we have router and CCM to handle the call come in.


However, the users are not sit in the DR site, they sit in the 3rd site, let's say Site C. Site C has some legacy PABX phone with another range of phone numbers, we want to make use of the DR CCM, the Subscriber to forward one number to the number in site C. For example, when outsider call our number 12340000 will forward to site C number 56789012.


When I try last time, the connection between Publisher and Subscriber broken, I can not change the config in the Subscriber. I also read the document in Cisco, it said that there is no way to "promote" the Subscriber to be a Publisher.


I will read the document you advise me, but I am not sure our CCM license is covered the SRND or not. Would you mind to give me some hints how to perform this task?


Thank you.


Best Regards,


Terry Chow

Correct Answer
Aaron Harrison Thu, 04/22/2010 - 00:30

Hi


What you need to do is either:


1) Have your publisher permanently situated on the other site, so you can make admin changes when the main site dies.


- OR -


2) Have the normal configuration set up so that if the call arrives on your DR number that it is already configured to go to site C.


This would mean that you need to have your 'DR' number of 12340000, when it arrives at the gateway at Site B, translated to 56789012. This will mean you need a dedicated number assigned for DR; this way the only thing you need to do in a DR scenario is have your service provider do the rerouting.


If 1234000 is the same number that arrives in non-DR scenarios at Site A, then you would need different CSSs assigning to the gateways at Site A and Site B so that depending on where the call arrives, it will be sent to the correct destination.


Regards


Aaron


Please rate helpful posts..

chowterry Thu, 04/22/2010 - 01:54

Dear Aaron,


Thank you for your reply, however, the 12340000 is a production number, only when the DR situation, it will forward to 56789012, at site C. During normal situation, users will answer that call in production site.


Thank you.



Best Regards,


Terry Chow

Aaron Harrison Thu, 04/22/2010 - 02:52

Hi Terry


I understand that.


You said 'in a dr scenario, 1234000 will be delivered to site b'.


So when delivered to site B, route it differently to when it is delivered to site A.


Regards


Aaron

David Hailey Thu, 04/22/2010 - 05:27

Terry,


I'm not sure your experience with CUCM but some of the other tips you are getting here may be a bit too much for you IMO. The SRND is a free resource for how to design every aspect of CUCM. It has nothing to do with licensing. It's available publicly on Cisco.com. So, I have designed DR sites similar to what you describe but your architecture or need to send to another PBX is a bit different. Honestly, this would be what I think is the easiest and probably most feasible solution for your needs. I will assume that your legacy PABX has some sort of Auto Attendant functionality or there is a voicemail system at that site that could provide such functionality. Almost all carriers will do call forwarding of a main number in the event of an outage - some call it route advance, some call it simply call forwarding. Sounds like you have this set up - and I would guarantee it requires some manual intervention on your part to call the carrier and ask for the calls to 12340000 to be forwarded to your gateway/PRI at Site B where your Subscriber sits. However, if the PABX is the ultimate destination it would be easiest for you to ask the carrier to forward all calls from 12340000 DIRECTLY to site C at 56789012. If not already configured this way, 56789012 should be configured as an Auto Attendant that gives an indication of "currently experiencing issues" (if you want) OR simply provides options to transfer to the appropriate folks who will be stationed at your alternate numbers that hang off the PABX.


Hailey


Please rate helpful posts!

PETER NEGUS Thu, 04/22/2010 - 02:11

For the immediate problem of re-routing to a backup gateway, you could have a work around using an auto-attendant - a number of products including Unity and UCCX can do this quite well. The redirected call would be landed onto a common pilot number, and the user then hears the prompt "please enter the last 6 digits of the number that you want to reach" or whatever.  With UCCX, you could actually drag out the RDNIS and do an automated redirect on that with a relatively simple script.


To restore the publisher after a complete loss of site, you need a network on your local site with the same IP address range as the remote site. This could be configured as part of the DR procedure, as you definitely do not want the DR network floating around with the same IP address during normal production. To restore the publisher, you do a re-install on fresh hardware, with the old IP address in the DR location, and reinstall the config from backup. This assumes that you will never see the original publisher ever again - the re-introduction to service procedure would need to move the newly restored pub back to the original site and take the old one out of service forever with a hard disc format.


Publisher restoration in an encrypted environment is a bit more complex as you may invalidate the CTL and need to rebuild, plus reboot the entire cluster..it's not very pretty.


Peter

chowterry Fri, 04/23/2010 - 00:05

Dear All friends,


Our final decision is to move the Publisher to DR site and move the Subscriber to the production site. And all users will register to the Subscriber.


I think that will solve all problem in the long run.


Thank you



Best Regards,


Terry Chow

Actions

This Discussion