Using local CM (8.x) in a cluster?

[Ven Taylor]

Management wants to distribute CM servers to remote hospitals and have "local" phones (200+) register to "local" CM server, but have our HQ Publisher be the secondary if local CM fails. I'm not sure this will work the way they think it will.  Has anyone dont this before?

I know we can physically configure the phones for a primary and secondary tftp server, but is that the right approach?  Will it even work?

It kinda sounds like they want to do the opposite of SRST.

Ven

[Jonathan Schulenberg]

How many phones total in the cluster and how many locations?

How much WAN bandwidth do you have available? Intra-cluster server traffic is at probably at least 3Mbps.

You can only have eight (8) nodes total running the CallManager service. Above 1250 phones we need to talk about dedicating nodes to specific roles.

[Ven Taylor]

We're currently looking at eight remote hospitals (subscribers) and one data center (publisher).  Each site is dual GigE connected (RPR) (hub & spoke).  Each remote hospital will have at least 200 phones.

Based on what you're saying, I don't think this is a good idea.  Maybe distributing the roles is the best approach, but keeping the CallManager services on two main servers...  What do you think?

Ven

[yahsiel2004]

Ven,

In regards to the phones registereing to certain Call Managers you can just create Call Manager Groups per loaction and assign the apporiate Call Managers to them and have the secondary Call Manager be the Publisher. You can then assign these Call Manager Groups to Device Pools per location. The Call Manager service should run on all Call Managers if you want them to provide Call Processing. You can however load balance the way your TFTP servers are being used; try to only have around 500 phones accessing each TFTP Servers since each TFTP Server is running the Call Manager Service.

Regards,

Yosh

[Jonathan Schulenberg · Accepted solution]

If we take 8 * 200 we're at 1600 phones. This means the publisher should not be running the CallManager service and be dedicated to database operations. Your only way of making this work with one cluster would be to pair the eight hospital locations up and have them fail over between the call processing subscribers located at each site. Whether you choose to run TFTP/IPVMSA on the call processing subscribers; or, on separate nodes is another point to debate.

You're dancing around an uptime/functionality requirement conversation here. If the requirement is full local CUCM functionality in the event of a WAN failure then this would be a distributed call processing model (this is discussed in the SRND). Traditionally this means a separate cluster (two node each for the size sites you're talking about) and either a gatekeeper, SIP proxy, SME, or possibly SAF running at the head-end to route calls between clusters. Stretching a single CUCM cluster this thin isn't a good design IMO.

[yahsiel2004]

Jonathan you made a good point.

Regards,

Yosh

[Ven Taylor]

Jonathan:

Thanks for the info.  That definitely helps me out.  Using multiple clusters wasn't even on my radar.  I'm not even sure how that would work.  Time to crack open the SRND!!

Ven