Has Anyone Successfully Deployed Unity Connection Across the WAN ?

Answered Question

Hi all,

I am looking into deploying Unity Connection 7.x with a Pub and a Sub connecting across a WAN link. I've gone through Cisco design doc regarding Unity Connection cluster requirements and the requirement is rediculous. Cisco wants a 50MB link with a round-trip of 20ms or less for a 48-voiceport deployment which is what I have. I am wondering if anyone has done any Unity Connection deployment over a 45MB DS3 connection with a round-trip of under 40ms successfully !!! Does anyone know the reasons with the strict requirements ? Thanks in advance !!! I appreciate any inputs/suggestions !!!

D.

I have this problem too.
0 votes
Correct Answer by David Hailey about 6 years 6 months ago

There is a cold standby model for Unity Connection.  Essentially, you build the system and keep it updated to the same revision of code as the production server(s).  However, you need to make sure you have current DRS backups.  In the event of a failure, you could restore the DRS backups to the failover Unity Connection server (cold standby).  This requires some licensing work and of course, good backups...but that's an option.  The architecture for Unity and Unity Connection is completely different - in obvious ways - but also from a clustering perspective.  There is no such concept in Unity.

Hailey

Please rate helpful posts!

Correct Answer by David Hailey about 6 years 6 months ago

The reasons for the requirements are likely tied to a few things.  My thoughts:

With Connection clustering, each server plays a specific role.  The Publisher should primarily handle database, web, and IMAP connections and be a secondary for call processing.  The Subscriber should primarily only take calls.  So, you would be essentially piping all of your voicemail calls across the WAN for at least one or more sites - so you would need to take this call volume into account and you need to account for the CODEC being used as well as QoS there.  If you misconfigure the ports and failover for line groups, the HA redundancy does not function properly so keeping calls to a site may cause more problems than anything else.

Replication.  Due to the HA nature of the Connection cluster, everything is replicated almost immediately between servers. If you login to the Pub and make a change, it is replicated to the Sub.  If you make a change in the Sub, it is replicated to the Pub.  So, again - these are transactions that would start to take away bandwidth depending on how active you are with changes - not just administratively, but letting end users handle changes from within PCA as well.

Digital Networking.  Connection doesn't really have a clustering over the WAN model.  Instead, you'll note that it's distinctively referred to as deploying servers within different buildings.  Essentially, Connection is designed to be a localized solution where you can deploy across buildings or possibly high-speed MAN but not really the typical WAN, persay.  However, you can configure digital networking for up to 10 nodes (7x).  When you do this, each site has a local VM system but you can network them together to "appear" almost like one large cluster.  When you do this, SMTP is used for networking between clusters.

So, here's the bottom line - if you want support from Cisco, i.e., you want to be able to call TAC then you need to fit within the parameters given.  Does that mean that deploying across the WAN won't work?  Not necessarily but it's not supported and typically for good reason.  Call volume, replication, and web operations could hog up more bandwidth than you expect and suddenly no one is happy.

Hailey

Please rate helpful posts!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
David Hailey Wed, 05/26/2010 - 17:44

The reasons for the requirements are likely tied to a few things.  My thoughts:

With Connection clustering, each server plays a specific role.  The Publisher should primarily handle database, web, and IMAP connections and be a secondary for call processing.  The Subscriber should primarily only take calls.  So, you would be essentially piping all of your voicemail calls across the WAN for at least one or more sites - so you would need to take this call volume into account and you need to account for the CODEC being used as well as QoS there.  If you misconfigure the ports and failover for line groups, the HA redundancy does not function properly so keeping calls to a site may cause more problems than anything else.

Replication.  Due to the HA nature of the Connection cluster, everything is replicated almost immediately between servers. If you login to the Pub and make a change, it is replicated to the Sub.  If you make a change in the Sub, it is replicated to the Pub.  So, again - these are transactions that would start to take away bandwidth depending on how active you are with changes - not just administratively, but letting end users handle changes from within PCA as well.

Digital Networking.  Connection doesn't really have a clustering over the WAN model.  Instead, you'll note that it's distinctively referred to as deploying servers within different buildings.  Essentially, Connection is designed to be a localized solution where you can deploy across buildings or possibly high-speed MAN but not really the typical WAN, persay.  However, you can configure digital networking for up to 10 nodes (7x).  When you do this, each site has a local VM system but you can network them together to "appear" almost like one large cluster.  When you do this, SMTP is used for networking between clusters.

So, here's the bottom line - if you want support from Cisco, i.e., you want to be able to call TAC then you need to fit within the parameters given.  Does that mean that deploying across the WAN won't work?  Not necessarily but it's not supported and typically for good reason.  Call volume, replication, and web operations could hog up more bandwidth than you expect and suddenly no one is happy.

Hailey

Please rate helpful posts!

Hi David,

I very much appreciate your inputs/suggestions !!! Let me give you some background on my existing Unity 4.0.3 environment, hopefully can give me your best recommendation. At this point I still like the idea of having the Sub in DR location in Tx I am not giving up on that idea just yet, I understand the Unity Connection cluster requirements but I just want to make sure I've done my homework before making my final decision. In my existing Unity 4.0.3 environment I have the primary server and off-box MS Exchange 2k message store in Ca and secondary server in Tx. I understand even in my existing set up I still don't have full redundance but atleast my auto attendant still work and callers can still leave voice messages when my Ca side is off-line. And so far per Cisco design doc for Unity Connection there is no way that I can accomplish the same results as I could with my existing Unity 4.0.3 environment. Do you know of anybody who has successfully deployed Unity Connection across a typical WAN ? in my case it will be across a DS3 MPLS WAN link. And if I go with what Cisco design doc said for Unity Connection then I would be dead in the water if my data center in Ca goes off-line. I see not being able to cluster across the WAN and not having that same level of redundancy is a big loss for me.

Thanks again !!! Any inputs/suggestions are highly appreciated.

D.

Correct Answer
David Hailey Wed, 05/26/2010 - 21:45

There is a cold standby model for Unity Connection.  Essentially, you build the system and keep it updated to the same revision of code as the production server(s).  However, you need to make sure you have current DRS backups.  In the event of a failure, you could restore the DRS backups to the failover Unity Connection server (cold standby).  This requires some licensing work and of course, good backups...but that's an option.  The architecture for Unity and Unity Connection is completely different - in obvious ways - but also from a clustering perspective.  There is no such concept in Unity.

Hailey

Please rate helpful posts!

Actions

This Discussion