Accepted Solutions
There is no way to have two actual Publishers or to promote a Sub to Pub at this time. But in the newer CUCM versions there is an extra measure of redundancy.
Publisher
The publisher is a required server in all clusters, and there can currently be only one per cluster. This server is the first to be installed and provides the database services to all other members in the cluster. The publisher server is the only server that has full read and write access to the configuration database. On larger systems with more than 1250 users, Cisco recommends a dedicated publisher to prevent administrative operations from affecting the telephony services. A dedicated publisher does not have any call processing services or TFTP services running on the server. Other servers run the TFTP and Unified CM services.
Subscriber servers in the cluster attempt to use the local database when initializing. This reduces the Cisco CallManager Service initialization time. In prior versions of Unified CM, subscriber servers in the cluster attempted to use the publisher's database when initializing. If the publisher was not available, they would use the local read-only copy from their hard drives.
The choice of hardware platform for the publisher is based on the scale and performance of the cluster. Cisco recommends that the publisher have the same performance capability as the call processing subscribers. Ideally the publisher should also be a high-availability server to minimize the impact of a hardware failure.
Call Processing Subscriber
When installing the Unified CM software, you can define two types of servers, publisher and subscriber. These terms are used to define the database relationship during installation. Once the software is installed, only the database and network services are enabled. All subscribers will subscribe to the publisher to obtain a copy of the database information.
A call processing subscriber is a server that has the Cisco CallManager Service enabled. A single server license is required to enable this service on a subscriber. The Cisco CallManager Service cannot be enabled on a server if the publisher is not available because the publisher acts as a licensing server and distributes the licenses needed to activate the Cisco CallManager Service. Once this service is enabled, the server is able to perform call processing functions. Devices such as phones, gateways, and media resources can register and make calls only to servers with this service enabled. Unified CM supports up to eight servers in a cluster with the Cisco CallManager Service enabled.
Depending on the redundancy scheme chosen (see Call Processing Redundancy), the call processing subscriber will be either a primary (active) subscriber or a backup (standby) subscriber. In the load-balancing option, the subscriber can be both a primary and backup subscriber. When planning the design of a cluster, you should generally dedicate the call processing subscribers to this function. In larger-scale or higher-performance clusters, the call processing service should not be enabled on the publisher and TFTP server. Call processing subscribers normally operate in either dedicated pairs or shared pairs, depending on the redundancy scheme adopted. One-to-one redundancy uses dedicated pairs, while two-to-one redundancy uses two pairs of servers that share one server from each pair (the backup server).
The choice of hardware platform depends on the scale, performance, redundancy, and cost of the servers. Scale and performance are covered in the section on Unified CM Platform Capacity Planning, and redundancy is covered in the section on Call Processing Redundancy.
Intracluster Communications
There are two primary kinds of intracluster communications, or communications within a Unified CM cluster (see Figure 8-2 and Figure 8-3.) The first is a mechanism for distributing the database that contains all the device configuration information (see "Database replication" in Figure 8-2). The configuration database is stored on a publisher server, and a read-only copy is replicated to the subscriber members of the cluster. Most of the database changes are made on the publisher and are then communicated to the subscriber databases, thus ensuring that the configuration is consistent across the members of the cluster and facilitating spatial redundancy of the database.
Database modifications for user-facing call processing features are made on the subscriber servers to which the IP phones are registered. The subscriber servers then replicate these database modifications to all the other servers in the cluster, thus providing redundancy for the user-facing features. (See "Call processing user-facing feature replication" in Figure 8-2.) These features include:
•
Call Forward All (CFA)
•Message waiting indicator (MWI)
•Privacy Enable/Disable
•Extension Mobility login/logout
•Hunt Group login/logout
•Device Mobility
•Certificate Authority Proxy Function (CAPF) status for end users and applications users
•Credential hacking and authentication
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/callpros.html
From this CCM SRND;
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42clproc.html
This changes with the release of CCM 6.x;
In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached. With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster. When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.
Database modifications for CallProcessing
User Facing features can be made on subscribers. These include updates for:
Call Forward All (CFA)
Message Waiting Indication (MWI)
Privacy Enable/Disable
Do Not Disturb Enable/Disable (DND)
Extension Mobility Login (EM)
Monitor (for future use, currently no updates at the user level)
Hunt Group Logout
Device Mobility
CTI CAPF status for end users and application users
Credential hacking and authentication
HTH
PS:Rate Useful Posts!
There is no way to have two actual Publishers or to promote a Sub to Pub at this time. But in the newer CUCM versions there is an extra measure of redundancy.
Publisher
The publisher is a required server in all clusters, and there can currently be only one per cluster. This server is the first to be installed and provides the database services to all other members in the cluster. The publisher server is the only server that has full read and write access to the configuration database. On larger systems with more than 1250 users, Cisco recommends a dedicated publisher to prevent administrative operations from affecting the telephony services. A dedicated publisher does not have any call processing services or TFTP services running on the server. Other servers run the TFTP and Unified CM services.
Subscriber servers in the cluster attempt to use the local database when initializing. This reduces the Cisco CallManager Service initialization time. In prior versions of Unified CM, subscriber servers in the cluster attempted to use the publisher's database when initializing. If the publisher was not available, they would use the local read-only copy from their hard drives.
The choice of hardware platform for the publisher is based on the scale and performance of the cluster. Cisco recommends that the publisher have the same performance capability as the call processing subscribers. Ideally the publisher should also be a high-availability server to minimize the impact of a hardware failure.
Call Processing Subscriber
When installing the Unified CM software, you can define two types of servers, publisher and subscriber. These terms are used to define the database relationship during installation. Once the software is installed, only the database and network services are enabled. All subscribers will subscribe to the publisher to obtain a copy of the database information.
A call processing subscriber is a server that has the Cisco CallManager Service enabled. A single server license is required to enable this service on a subscriber. The Cisco CallManager Service cannot be enabled on a server if the publisher is not available because the publisher acts as a licensing server and distributes the licenses needed to activate the Cisco CallManager Service. Once this service is enabled, the server is able to perform call processing functions. Devices such as phones, gateways, and media resources can register and make calls only to servers with this service enabled. Unified CM supports up to eight servers in a cluster with the Cisco CallManager Service enabled.
Depending on the redundancy scheme chosen (see Call Processing Redundancy), the call processing subscriber will be either a primary (active) subscriber or a backup (standby) subscriber. In the load-balancing option, the subscriber can be both a primary and backup subscriber. When planning the design of a cluster, you should generally dedicate the call processing subscribers to this function. In larger-scale or higher-performance clusters, the call processing service should not be enabled on the publisher and TFTP server. Call processing subscribers normally operate in either dedicated pairs or shared pairs, depending on the redundancy scheme adopted. One-to-one redundancy uses dedicated pairs, while two-to-one redundancy uses two pairs of servers that share one server from each pair (the backup server).
The choice of hardware platform depends on the scale, performance, redundancy, and cost of the servers. Scale and performance are covered in the section on Unified CM Platform Capacity Planning, and redundancy is covered in the section on Call Processing Redundancy.
Intracluster Communications
There are two primary kinds of intracluster communications, or communications within a Unified CM cluster (see Figure 8-2 and Figure 8-3.) The first is a mechanism for distributing the database that contains all the device configuration information (see "Database replication" in Figure 8-2). The configuration database is stored on a publisher server, and a read-only copy is replicated to the subscriber members of the cluster. Most of the database changes are made on the publisher and are then communicated to the subscriber databases, thus ensuring that the configuration is consistent across the members of the cluster and facilitating spatial redundancy of the database.
Database modifications for user-facing call processing features are made on the subscriber servers to which the IP phones are registered. The subscriber servers then replicate these database modifications to all the other servers in the cluster, thus providing redundancy for the user-facing features. (See "Call processing user-facing feature replication" in Figure 8-2.) These features include:
•Call Forward All (CFA)
•Message waiting indicator (MWI)
•Privacy Enable/Disable
•Extension Mobility login/logout
•Hunt Group login/logout
•Device Mobility
•Certificate Authority Proxy Function (CAPF) status for end users and applications users
•Credential hacking and authentication
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/callpros.html
From this CCM SRND;
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42clproc.html
This changes with the release of CCM 6.x;
In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached. With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster. When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.
Database modifications for CallProcessing
User Facing features can be made on subscribers. These include updates for:
Call Forward All (CFA)
Message Waiting Indication (MWI)
Privacy Enable/Disable
Do Not Disturb Enable/Disable (DND)
Extension Mobility Login (EM)
Monitor (for future use, currently no updates at the user level)
Hunt Group Logout
Device Mobility
CTI CAPF status for end users and application users
Credential hacking and authentication
HTH
PS:Rate Useful Posts!
