CallManagers Publishers and Subscribers

Answered Question
Apr 17th, 2008

Hi, this might be a silly question but it is my 3rd day working in the voip world, thanks in advance. What exactly is the purpose of the subscriber, is is running parallel to the publisher and backing up everything?

I have this problem too.
0 votes
Correct Answer by jbarcena about 8 years 7 months ago

"To maintain data consistency throughout the cluster, the publisher database server uses one-way or unidirectional replication to each subscriber. All information is stored on one server (the publisher server) and replicated to the other servers (subscriber servers) in the cluster. Replicating the SQL database is a core function inside teh CCM clusters.

Configuration changes on CCM systems are possible only while teh publisher server is available.

CCM writes information to the publisher database only if the CCM web components are installed o CCM Administration is performed directly on the publisher server. All entries that are made using the CCM Administration page of the subscriber are written to the database on the publisher server. If the publisher is down, no updates can be made in the CCMAdmin page of the subscriber server.

The publisher holds the only copy of the database that is allowed to be written to. All subscribers replicate with the database of the publisher only, so they are in read-only mode."

This info is taken from the Cisco IP Telephony book for the CCVP certification.

HTH

//Jorge

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.2 (10 ratings)
Loading.
Rajesh Revuru Thu, 04/17/2008 - 08:31

Publisher server hosts database with read+write access. Subscriber server has databases with read only access.

In an IP telephony infrastructure, there can only 1 publisher, but many subscribers.

This explanation is very high level. For more you have to follow cisco SRND.

HTH

Correct Answer
jbarcena Thu, 04/17/2008 - 09:10

"To maintain data consistency throughout the cluster, the publisher database server uses one-way or unidirectional replication to each subscriber. All information is stored on one server (the publisher server) and replicated to the other servers (subscriber servers) in the cluster. Replicating the SQL database is a core function inside teh CCM clusters.

Configuration changes on CCM systems are possible only while teh publisher server is available.

CCM writes information to the publisher database only if the CCM web components are installed o CCM Administration is performed directly on the publisher server. All entries that are made using the CCM Administration page of the subscriber are written to the database on the publisher server. If the publisher is down, no updates can be made in the CCMAdmin page of the subscriber server.

The publisher holds the only copy of the database that is allowed to be written to. All subscribers replicate with the database of the publisher only, so they are in read-only mode."

This info is taken from the Cisco IP Telephony book for the CCVP certification.

HTH

//Jorge

rob.huffman Thu, 04/17/2008 - 09:30

Hi Efrain,

Just to add a note to the great info from Rajesh and Jorge (two of my faves :) There are some nice diagrams and descriptions of this relationship between the Pub and Sub(s) in the SRND (Solution Reference Network Design Guides) These guides also have some really great info for anyone getting started in IP Telephony;

Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/callpros.html#wp1043559

Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42clproc.html

Hope this helps!

Rob

mightyking Thu, 04/17/2008 - 10:34

Publisher = Master

Subcriber = Slave

You can have only one Master in a cluster but multiple Slaves.

gonzalezel Fri, 04/18/2008 - 08:14

why would I want multiple slaves? I read that the subscribers are read only is this correct? thanks in advance this stuff is way over my head.

Rajesh Revuru Fri, 04/18/2008 - 08:32

Subscriber is slave only with "Database perspective". In bigger environment organizations use multiple subscribers to distribute load. Say subscriber-1 wiill have 300 phones registered and subscriber-2 will have another 300 phones registered. This will eliminate single point of failure and also not cause any burden on publisher.

jbarcena Fri, 04/18/2008 - 09:17

Well the best practice is to have redundancy in your environment, if your system is small then only one Publisher and one Subscriber, is also recommended to have all the phones registered only on the Subscribers, since the Pub is in charge on handling the database lets help him with the phones and avoid some high CPU. Now the number of subscribers actually depends on how big is your system and also it depends on the type of server, for example, 7815-I1 supports 300 phones per cluster

7825-I1 supports 1000 phones per cluster

7835-I1 supports 2500 phones per cluster

7845-I1 supports 7500 phones per cluster

So it all depends on your design, it also depends on the level of redundancy that you want on your system.

If you are new on Cisco VoIP I strongly recommend you the Cisco IP Telephony book:

http://www.ciscopress.com/markets/detail.asp?st=44706

And also the SRND link that has already been provided by Rob.

//Jorge

rob.huffman Fri, 04/18/2008 - 09:25

Hi Efrain,

Don't worry, this will all start to make sense :)

By design, you can specify where a phone registers by assigning it to a specific Device Pool this in turn will look at a Callmanager Group that lists a Primary, Secondary and Tertiary Callmanager server.

Here is some related info;

You will want multiple Subscribers to "Load Balance" IP Phone registrations and Call processing. In the Best Practice design you won't actually have any phones registered to the Publisher Callmanager so it can be left free to perform other tasks.

By design, you can specify where a phone registers by assigning it to a specific Device Pool this in turn will look at a Callmanager Group that lists a Primary, Secondary and Tertiary Callmanager server. Here is some related info;

Here is some info about CCM Load Balancing;

Balanced Call Processing

After installing the Cisco Unified CallManagers that form a cluster, you should, as much as possible, evenly balance the call-processing load across the system by distributing the devices (such as phones, gateways, CTI route points, CTI ports, and route lists) among the various Cisco Unified CallManagers in the cluster. To distribute the devices, you configure Cisco Unified CallManager groups and device pools and then assign the devices to the device pools in a way that achieves the balance you want.

Cisco Unified CallManager groups and device pools represent logical groupings of devices that you can arrange in any way that you want. For ease of administration, make sure that all the devices in a group or pool share a common and easily identified characteristic, such as their physical location on the network.

You can also use Cisco Unified CallManager groups to establish redundancy (backup call processors) for the primary Cisco Unified CallManager in the group. A Cisco Unified CallManager group comprises an ordered list of up to three Cisco Unified CallManager servers. During normal operation, the first (primary) Cisco Unified CallManager in the group controls all device pools and devices that are assigned to that group. If the primary Cisco Unified CallManager in a group fails, control of the device pools and devices that are registered with the primary Cisco Unified CallManager transfers to the next Cisco Unified CallManager in the group list.

From this good doc;

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00806b036a.html#wp1025126

Cisco Unified CallManager Groups

A Cisco Unified CallManager group comprises a prioritized list of up to three Cisco Unified CallManagers. The first Cisco Unified CallManager in the list serves as the primary Cisco Unified CallManager for that group, and the other members of the group serve as secondary (backup) Cisco Unified CallManagers.

Cisco Unified CallManager groups associate with devices through device pools. Each device belongs to a device pool, and each device pool specifies the Cisco Unified CallManager group for all of its devices.

Cisco Unified CallManager Groups:

Call processing load balancing You can configure device pools and Cisco Unified CallManager groups to distribute the control of devices across multiple Cisco Unified CallManagers.

Device Pools

Device pools provide a convenient way to define a set of common characteristics that can be assigned to devices.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a008073ee5d.html#wp1059777

Hope this helps!

Rob

jbarcena Fri, 04/18/2008 - 09:29

Wow, Rob I will give you five points for that great detailed answer.

rob.huffman Fri, 04/18/2008 - 09:44

Hi Jorge,

Thanks for that my friend :) Such a nice note to make my day, especially from someone I admire so much! This type of thing really makes participating here most worthwhile.

Cheers!

Rob

Actions

This Discussion