CUC 8.x Clustering Questions / Concerns

[dtran]

Hi all,

I am looking into deploying a CUC 8.x cluster with Pub and Sub at two separate locations connecting over a 45MB DS3 link. I have about 1500 subscribers with 48 voice messaging ports on each server. According Cisco specs for CUC 8.x below I am completely within specs. I am wondering if anyone has run into this scenario with CUC 8.x and could share your experience. Per Cisco recommendation, the subscriber sever will be the primary call processor and the Publisher will be handling replication, maintaining the DB, and MWI. I am wondering if there will be any issues with MWI with Pub and Sub connecting over a WAN link even though my WAN link is completely within Cisco specs.

In my existing Unity 4.0.5 with failover environment. I have the primary Unity server and the Exchange server located in the same building and the secondary Unity server located at the remote site. And I know whenever I failover to the secondary Unity server I always have issue with MWI. I understand Cisco has completely changed the architecture with Unity Connection. I hope this won't an issue.

Connection Cluster Requirements When the Servers Are in Separate Buildings or Sites
Revised April16, 2010
•Both servers must meet specifications according to the Cisco Unity Connection 8.x Supported Platforms List at

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/connection/8x/supported_platforms/8xcucspl.html.

•For a cluster with two physical servers, both servers must have the same platform overlay.
•For a cluster with two virtual servers, both servers must have the same virtual platform overlay.
•For a cluster with one physical and one virtual server:
–The platform-overlay numbers of the physical server and the virtual server must match.
–With Platform Overlay 1 servers, you must add 2 GB of RAM to the physical server so the amount of RAM in the physical server matches the 4 GB of vRAM configured for Connection on the virtual server.
•Depending on the number of voice messaging ports on each Connection server, the path of connectivity must have the following guaranteed bandwidth with no steady-state congestion:
–For 50 voice messaging ports on each server—7 Mbps
–For 100 voice messaging ports on each server—14 Mbps
–For 150 voice messaging ports on each server—21 Mbps
–For 200 voice messaging ports on each server—28 Mbps
–For 250 voice messaging ports on each server—35 Mbps

Thanks in advance !!! I appreciate any inputs / suggestions !!

D.

[Markus Schneider · Accepted solution]

Just one comment... you don't want to have the sub with the primary role.  That's considered a failed over system and it won't properly fail back if there's a problem with the sub.  A failover will only occur if the publisher is the primary.

The audio/prompts are all played back from the server answering the call.  So whichever pub/sub answers the call, that's the one that will be playing prompts locally.  For logging into a mailbox, the sub has to contact the pub (on a working system), but that should not be a significant delay in your case (but is a potential source of delay).  If there is a delay issue, you will typically see delays after entering the password or (when taking a message) before the record beep (after the greeting).

[dtran]

Hi Markus,

I very much appreciate your inputs !!! You are correct, the delay occurs after entering the PIN. Also there is a delay when press option 1 to listen to old messages, when press option 1 there is a delay before you can hear the message announcement but after that the message plays back normally. The delay is noticeable and I am afraid users will not be happy about it.

Do you see any issues or concerns with having the Pub handles all the functions and the Sub for failover purpose only ?

Thanks Markus !!!

D.

[Markus Schneider · Accepted solution]

You should be fine having the pub handle calls--for the exact reasons the TAC engineer mentions--but I think it would be good to get some diagnostic traces and figure out what the real delay is in getting a response and if there isn't something else going on.  All of the bandwidth restrictions on the product deployment boil down to needing a low latency, lossless connection between the two servers.  If checking messages by dialing the pub is noticeably better performance than checking on the sub, then there may well be something wrong.  It would be better to find out now since these delays could just be the canary in the coal mine for other things, like replication, to be affected. 

[David Hailey]

I agree.

Sent from my iPhone

[dtran]

Thank you David / Markus !!! I very much appreciate your inputs !!!

D.

[David Hailey · Accepted solution]

I was out and about earlier so I wanted to elaborate on my response:

I still think you ultimately have to do what works best for your environment.  If that means running everything on the Publisher then so be it.  BUT, I think there are too many variables to just move to that solution without further investigation both internally and from TAC.  Understandably, a single server can handle the load - if it couldn't, there wouldn't be a standalone option for CUC.  However, the concept of clustering is not simply about load balancing to provide high availability.  That's a big part of it - but the separation of roles is also intended to provide better performance, scalability, as well as the active-active HA fault-tolerance.  If you meet the specs for clustering over the WAN, then I think the product should perform as expected.  My expectation would be for there to be very little, if any, noticeable lag in performance especially as far as end user operations are concerned.  If what you are experiencing is par for the course for clustering over the WAN with CUC, I would say there are a lot of customers that would be disappointed.  I know I would. In saying that, it doesn't meant that there is an inherent issue with CUC.  It could be perfectly fine.  However, given that you are running an 8.0 release - I would push for some further inspection of the health of the system.  If everything is up to spec then there could be something on the WAN link that is at fault.  These types of things always take a little more time to investigate but as Markus said - it would still be in your best interest to figure out what is going on here. Even if you have the Publisher sitting at your HQ site doing all the work, it still has to replicate data within the cluster which would be traversing the WAN. So, I would want to pursue both sides of the coin.  You may still end up running everything from one box but at least you will have tried to rule out as many potential issues as possible.

Hailey

Please rate helpful posts!

[dtran]

Hi David,

I very much appreciate your valuable inputs. I perfectly understand your point of view. When I first start looking into Unity Connection I think miss understood the term Active/Active redundancy. I was under the impression that whichever server answers the call, it will use its local DB to process that call and that was how interpret the term Active/Active redundancy. But that is not the case according Markus, the server that takes the call will have to contact the primary server to process that call. And that is mainly the reason why I experience the delay in my scenario. At this point I am still looking at the Pub being the primary and also handling all the functions. I am just not confortable with  splitting functions while having the Pub and Sub connecting over the WAN.

Thank you very much David !!

D.