Actually, there is no restriction on the number of servers that can have TFTP service enabled, in Cisco Unified CallManager 4.2 cluster may contain as many as 20 servers, of which a maximum of eight may run the Cisco CallManager service that provides call processing. The other servers may be configured as a dedicated database publisher, dedicated Trivial File Transfer Protocol (TFTP) server, or music on hold (MoH) servers. Media streaming applications (conference bridge or media termination point) may also be installed on a separate server that registers with the cluster.
So your answer is 20...but...
With Cisco Unified CallManager 4.2, you can choose from the following redundancy configurations:
?Two to one (2:1) ? For every two primary subscribers, there is one shared backup subscriber.
?One to one (1:1) ? For every primary subscriber, there is a backup subscriber.
Depending on the redundancy scheme chosen, 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).
Cisco recommends that you enable the Cisco Trivial Transfer Protocol (TFTP) service on two Cisco Unified CallManager servers. Cisco also recommends that you do not enable more than one server with the Cisco TFTP service at a location remote to publisher, over a low-speed WAN link. More than two TFTP servers can be deployed in a cluster, however this configuration can result in an extended period for rebuilding all the TFTP files on all TFTP servers.
You can run the TFTP service on either a publisher or a subscriber server, depending on the site and the available capacity of the server.
When a change occurs in the database for a device, the Database Layer Monitor notifies all the nodes in the cluster that this change has occurred. The TFTP service running on the TFTP servers will see that this change notification occurred, will check the database, read that record, and create the new .cnf.xml file, based on the data in the database.
Hence, no additional configuration is required to 'sync' the TFTP servers, however, any manual updates, new firmware loads for example, will need to be done on each TFTP servers.
For dedicated TFTP servers, you need the TFTP service and Database Layer Monitor activated. Note, no CCM process is required but you still need to purchase a copy of CCM for (SQL) licensing reasons.
By default, the TFTP service supports 60 simultaneous threads. The suggested value for a dedicated TFTP server is 150 for a single processor system and 300 for a dual processor system. A maximum of 500 is allowed to be configured from the application.
Devices that are requesting a configuration file while the TFTP server is processing the maximum number of requests will receive an error message from the TFTP server, which causes the device to wait a length of time and request the configuration file later.
Basically, performance is the most important part when enabling Cisco TFTP service, that why we recommend no more that two Cisco TFTP servers in the cluster...
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...