cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
672
Views
25
Helpful
5
Replies

UC Design

mightyking
Level 6
Level 6

Hello Experts,

We have 2 date centers (DC) which are being used as the primary (DC1) and secondary (DC2) for all our Unified Communication servers. We are moving from ISDN PRI to SIP Trunking and considering to install the HA CUBE in the DC2 but all primary UC servers are in DC1.  We have:

One CUCM Mega cluster version 10.5

Three Unity Connection Clusters version 10.5

Four UCCX Clusters version 11.6

Do you guys see any issues seperating the HA CUBEs from UC servers. Is there any recommandations that we need to take in consideration?

 

Thanks,

 

Mk

1 Accepted Solution

Accepted Solutions

Chris Deren
Hall of Fame
Hall of Fame

Absolutely fine, as long as the latency is within reason (under 300 ms), preferably under 150 ms, you did not state if your UC apps are already split between the data centers, but if so you are then already under the latency as UC apps have struck guidance i.e. 80 ms.  Splitting the environment between 2 data centers is always a good idea.

View solution in original post

5 Replies 5

Chris Deren
Hall of Fame
Hall of Fame

Absolutely fine, as long as the latency is within reason (under 300 ms), preferably under 150 ms, you did not state if your UC apps are already split between the data centers, but if so you are then already under the latency as UC apps have struck guidance i.e. 80 ms.  Splitting the environment between 2 data centers is always a good idea.

Hi,

As @Chris Deren mentioned, there is no issue if you deploy HA CUBE's at DC2 as long as the round trip delay is less than 150 msec. But there are other recommendations/best practices which you need to take into consideration. Such as:

1. Single Point of Failure

2. Geographic Redundancy

3. Codec Consideration

4. Network bandwidth for all PSTN calls

Please refer to below document which provides best practices for deployment of Cisco CUBE. 

https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/white_paper_c11-620461.html?cachemode=refresh 

 

 

Please rate helpful posts and if applicable mark "Accept as a Solution".
Thanks, Vaijanath S.

Thanks Chris & Vaijanath,

Yes, all of our primary servers are in DC1 and secondaries in DC2 but the HA CUBE is going to be installed in DC2. All the recommandations mentionned by Vaijanath have been taken in consideration. We will have a singl CUBE inatalled in DC1 with a dedicated SIP line for redundancy perposes.

.

I guess all we need to do is to creat a Device Pool which has the secondary CUCM server located in DC2 at the top of the Cisco Unified CM Groups list which will allow the CUBE to point to the local CUCM.

 

Thanks again,

 

MK

"I guess all we need to do is to creat a Device Pool which has the secondary CUCM server located in DC2 at the top of the Cisco Unified CM Groups list which will allow the CUBE to point to the local CUCM."

Well, not necessarily. Are you going to be using Run on All nodes (RoA <-- I think I just made that up) on your SIP Trunk to CUBE? If so, the contents and order of the CMG don't matter. And you probably should us RoA, since you have a mega cluster.

Let's say you had 16 subs, and were not using RoA, which means only 3 of your subs are allowed to talk to the CUBE. This means that for 13 of the subs, they need to proxy their connection to CUBE through one of those three subs, and worse still, all 16 subs will proxy their connection to CUBE through the primary CM in the CMG.

If you simply turn on RoA, then all 16 subs can talk directly to the CUBE, no proxying, no choke point.

Now, CUBE to CUCM is a different story. You will not likely know which CM to send SIP traffic to, based on the phone number dialed, since registration can be dynamic (and should be). So, you'd have two choices I'd think:

1) Load balance across all nodes
2) Load balance across all DC2 nodes
3) Order your CM nodes and target all or some

In any case, you'll definitely want to tune your retry timers on CUBE, and enable SIP OPTIONS so you can allow CUBE to mark the CM's as busyout, and not try them. A caller waiting to hunt through 13 subs to finally get through on the 14th, is going to result in them hanging up well before then.

Thanks Anthony!