Cisco Cisco TMS Architecture Requirements for Redundancy
Cisco TMS redundancy configuration and overview
Page 9 of 32
Cisco TMS Architecture Requirements for
Redundancy
Implementation of Cisco TMS in any redundant or fail-over model hinges on maintaining compatibility
with several key concepts from Cisco TMS. The following hold true regardless of which redundancy
model you choose to implement. Keeping these concepts in mind will allow you to consider alternative
redundancy models or combinations of the ones presented in this document. The requirements are as
follows:
Only one live database per Cisco TMS ‘installation’.
The core of Cisco TMS is its database. You may only have one running copy of the database
active at any time. Multiple copies of the database may exist, but only one copy may be ‘live’ and
used at a time Any redundancy methods used for the database will consist of fail-over or backup
methods for one database. Two Cisco TMS servers pointing at two different live Cisco TMS
databases would be considered two separate installations, not a redundant installation.
MSDE SQL Server cannot be used.
Earlier versions of Cisco TMS shipped with the freely distributable version of SQL Server, MSDE
2000. This version is only intended for small deployments. MSDE 2000 is feature limited and can
not be used for larger deployments or any deployment that involves multiple Cisco TMS servers
or multiple SQL servers. Any deployment considering a redundant solution should be based on
Microsoft SQL Server 2000 or SQL Server 2005.
Local File paths used on the Cisco TMS Servers must be the same across all Cisco TMS Servers.
The local file system paths used for Cisco TMS files, such as uploaded software files, should be
the same on all Cisco TMS servers
Multiple Cisco TMS servers must all be members of the same domain.
When using multiple Cisco TMS servers, all Cisco TMS servers must be a member of the same
domain and all Cisco TMS users must be members of that domain, or a domain trusted by the
Cisco TMS server’s domain. Using workgroups and local user accounts is not supported when
using multiple Cisco TMS servers.
You must maintain a low latency (sub 10ms) between a Cisco TMS server and the database.
User responsiveness will be severely crippled if there is latency between the Cisco TMS servers
and the database they are attached to.
All servers must be time synchronized.
All servers making up the redundancy solution must be time synchronized through NTP or the
Windows Domain
Each actual Cisco TMS server must be addressable by the managed devices.
Because devices communicate unsolicited to Cisco TMS, they must be able to communicate
directly TO each Cisco TMS server (each server must have a unique, reachable IP address)
Cisco TMS must ‘know’ what specific address is to be used to reach the Cisco TMS servers.
Within Cisco TMS’s configuration the Cisco TMS Server Addresses are used to configure what
addressees are used to identify Cisco TMS to devices it is managing.. (Note: there are now IPv4
and IPv6 values, and local and public values). In a redundant solution, these addresses could be
a Cisco TMS server, or addresses to the load balancer depending on the solution in place. The
Cisco TMS configuration values for it’s addresses must always be the current, valid addresses to
reach Cisco TMS.
Cisco TMS relies on multiple protocols, not just HTTP.
Whatever distribution or load balancing model is used, both HTTP and SNMP are used from
managed devices for unsolicited connections so both types must be forwarded by a load
balancing solution.
Cisco TMS is multi-vendor and device methods vary between devices.
Due to difference in vendors and products, not all devices communicate the same to Cisco TMS.
Care must be taken to account for all protocols required between Cisco TMS and the devices to
be managed
When using multiple web servers, all should have the same validation key and methods.
When using multiple web servers, all Cisco TMS websites should be configured with the same
