Cisco Redundancy Models for Cisco TMS
Cisco TMS redundancy configuration and overview
Page 14 of 32
Maintenance
Users should regularly backup the SQL database. The interval between backups defines the
maximum time window over which data would be lost. Typical installations would perform full nightly
backups of the database. Please see Section
0 Backup and Recovery of the TMS database
of this
document for additional details on how to perform backups and restores of the Cisco TMS database.
Upgrading Cisco TMS
This installation model requires no additional steps or procedures to follow when performing upgrades
or patches.
Model Summary
Immediate fail-over available – No
Amount of data lost – Call data during outage can be lost for some system types if Cisco TMS
Server is down. No system or configuration data lost if SQL Server does not fail. If SQL Server
fails, Cisco TMS is unavailable until the SQL Server is restored to service. Call and Scheduling
information created since last backup will be lost if database restored from backup
Time to restore service – For the Cisco TMS Server, it is dependent on time to repair the server or
replace with another server on the same IP address and DNS hostname and perform a recovery.
For the SQL Server, it is dependent on time to repair the server or replace with another server on
the same IP address and perform a recovery. Estimate a few hours to a day.
Administrative Capabilities Required – Low, only requires basic skills and SQL backup/recovery
procedures
Cost – Low, only requires a second server which may be tasked with other SQL jobs
Single Server, Clustered Database
This model is identical to the previous Section
0 Single Server, Separate Database
except the remote SQL Server is a part of a SQL Server cluster, rather than a stand-alone server.
SQL Clustering allows multiple servers to operate as a group and provide fail-over for a SQL Server in
case of a failure. A SQL cluster consists of a shared disk array that can be accessed by multiple
nodes. Virtual SQL Servers are created and hosted on a node, with the information for each Virtual
Server being stored on the shared disk array. When a node fails, any Virtual Server being hosted by
the node can automatically fail-over to another node in the cluster and continue operation. The SQL
Cluster itself and the fail-over of the SQL Server is transparent to Cisco TMS as the Cluster serves the
database via a virtual IP address or name. For more information on SQL Clustering requirements,
capabilities, and configuration, please see Microsoft’s SQL Server 2000 documentation.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx
http://www.microsoft.com/sql/techinfo/administration/2000/availability.mspx
One of the main benefits of using a SQL cluster is you can pool redundancy resources to share
among several servers. An organization may already have a high performance, high availability SQL
Cluster. Using this cluster will provide Cisco TMS redundancy with quick fail-over to prevent failure of
the database component of Cisco TMS.
In this scenario, if the Cisco TMS server were taken offline due to network or equipment failure, Cisco
TMS would be unavailable. If the SQL Server were to fail, the SQL cluster would detect the server
becoming unavailable and would initiate a fail-over to another server in the cluster. The time required
to fail-over is specific to your SQL Cluster configuration, but normally is on the order of seconds to
minutes and can be fully automatic, with no administrative input.
Recovery Methods
Cisco TMS Server Failure
•
Repair the existing server and bring it back online or
•
Replace failed server with new server using same IP address and DNS hostname as the
original Cisco TMS. Install a new copy of Cisco TMS from the installation media. During the
