Cisco – Multisite Single Cluster Call Manager 4.1 Design
| On the heels of my CIPT test (call manager test), I’ve completely redesigned from the ground up our call manager configuration. I’ve changed the way the system works pretty much completely…hehe. I spent a good bit of time putting together the Visio, so I figured I would share it with you guys, and also explain it in laymen’s terms.Here’s the PDF version that you can download(
CallManager Design (1147 downloads)
), or simply take a peek at the below jpg. Names and places have been changed to protect the innocent.
As you can see, it looks somewhat confusing at first…that’s what I call job security! Actually, if you familiarize yourself with the different components, it will actually make sense. What we have are two separate sites, S1 and S2. This is a single cluster with the publisher at S1. Since callmanager 4 runs on windows using SQL 2000, you are limited to 8 subscribers. The publisher has a writable database and the subscribers replicate that database to themselves. The subscribers maintain a READ-ONLY copy of the database. Since we are limited to only 8 subscribers, this limits the number of servers we can have in a single cluster. There is also a restriction of a round trip time(the time it takes for a packet to hit a remote callmanager and return) of 40ms. Since our sites are only across town, we will be well within this limitation. We are going to have L2 transit between the sites, which also helps the speed So, we have our cluster and within this cluster, we have two callmanager groups. A callmanager group is a prioritized list of callmanager servers within your cluster. This will list the callmanagers your phone will attempt to register with. We have two, one for site 1 and one for site 2. The idea being, site 2 will home off of callmanager 2 first and failover to callman1, and vice-versa; site 1 will home off of callman1 and failover to callman2.
We then create the Device Pools. These allow you to apply like attributes to groups of phones. We are creating two so that we can specify a handful of settings along with specifying the callman group. We are creating two, one for S1 and one for S2. There will be a handful of phones that deviate from these settings, but device level settings override the device pool settings.  Device Pool We create partitions next. Partitions are a method to segregate route patterns, phones and translation patterns. We have a set of SQL queries that bill based on partition, so we have each group in a partition. I also put my route patterns in partitions.
 partitions Our next step is to create some gateways in our system. Gateways are conduits to the PSTN, be it a digital PRI or a good old fashioned FXO pots line. We also add each gateway to a route group. A route group is a prioritized list of gateways. One generally adds gateways that are geographically close into a single route group. I want my route groups as flexible as possible, so I add a single gateway her route group. Another quark about route groups is that you can only use a gateway once. This means you can only assign a single gateway to a single route group OR you can only point a route patter to a gateway once. You can’t have a route patter point directly to a gateway and add that same gateway to a route group. The best course of action is to add each gateway to a route group for later use in a route list.  Gateway and Route Group  Route Lists  calling search space  Translation Pattern So, with this blue print, you can build a scalable redundant callmanager. There are more nuts and bolts that are necessary, setting up your resources, voicemail ports, users, blah blah blah…;) Adding users is a snap using the bulk administrative tool. There is another cool tool to use with adding new users called JTAPS. It basically lets you dial a number with an auto registered phone, and it will pull the proper config. SOOOOoooooOOoo, if you guys found this interesting or useful in the least, let me know in the comments section. |
