Storage and Maintenance of CDR Data

The CallManager cluster stores all CDR data in a central location. This can be either a central CDR database, or in comma-separated values (CSV or simply comma-delimited) flat files stored in a central location. This is referred to as the central CDR data store. Normally the CDR data is inserted into a central CDR database. This section describes how the central data store collects and stores CDR data and how the architecture provides fault tolerance and redundancy. Topics include the following:

• Why use a central database?
• What happens when the central database is not available?
• What happens to CDR data when a CallManager node fails?
• How to control the transport and storage of CDR data?

Read this section to discover some of the design goals and history relating to the current architecture. Furthermore, this section describes what happens when a CallManager node loses its link to the central CDR database and how the system recovers the data and makes it available in the central CDR data store.

Why Use a Central Database?

All CallManager nodes in a cluster form what is essentially one large system. Therefore, it is essential that all CDR data is collected and treated as if it is a single system. This section reviews the design decisions and tradeoffs that were made and why.

In very early versions of the software, CallManager wrote CDR data into comma-delimited files and stored them on the local disks because the whole system was on a single server. One file contained each day's records. Each CallManager was a complete system, as clustering technology was not available in versions 2. x and before.

Cisco's design team decided to enhance the system to make it a distributed, fault-tolerant, and redundant system. They designed it to have a scalable architecture so that it could grow into very large systems. Based on the design goals of creating a distributed system that is fault-tolerant and redundant, the team decided that having CDR data scattered on different servers did not fit well into the architecture for the new system. The team considered four major design goals when creating the current architecture of the system:

• Prevent the loss or unavailability of CDR data
• Store the CDR data in a fault-tolerant, redundant facility
• Make the data accessible from a single location
• Make the system handle very high traffic volumes

The team decided that putting the CDR data into a central CDR data store was the best way to meet these design goals. The central data store is normally a central database, but it can also be a folder on a server that holds the CDR CSV files. Having a central storage location makes it easier to secure the data and control access to it. A central data store can be either backed up or replicated as required to create a fault-tolerant and redundant storage facility. The data store can be made as secure as requirements for a particular customer demand.

There are a number of advantages in using a central data store for CDR data, including the following:

• When a CallManager node crashes and takes the server down also, it does not affect the accessibility of the CDR data unless the CallManager node is running on the Publisher, which is where the central data store is normally located.
• The data store can be made redundant and secure by specifying an off-cluster CDR connection string, as described in Table 7-2.
• Billing systems interface with a single point of contact.
• The data store does not need to be part of the CallManager cluster.

Table 7-2. CDR Enterprise Parameters

Parameter	Description	Default	Valid Values
Local CDR Path	Identifies the directory for local CDR files written by the CallManager node on the local server where CallManager is executing.	C:Program FilesCiscoCallDetail	The local path CallManager uses to write CDR files.
CDR UNC Path	Identifies the central collection point for CDR files. If this parameter is blank, CDR files will not be moved from the local server.	Supplied during system installation.	Specifies a fully qualified Universal Naming Convention (UNC) path that is pointing to a read/write NT share for CDR file collection.
Off Cluster CDR Connection String	Optional This parameter specifies the optional data set name (DSN) to use when you do not want CDRs inserted into the CDR database on the Publisher server. This string points to a central CDR data store on a server outside of the CallManager cluster. This server does not need to have CallManager installed, but it must point to an ODBC database server with matching CDR database schema. The DSN should include any necessary user and password information. Specifying a path in this parameter enables insertion of the CDRs into the specified off cluster database. It requires a trusted relationship between the Publisher and the external database. If this parameter is blank, CDRs are inserted into the CDR database on the Publisher using the path specified in the CDR UNC Path parameter.	N/A	Up to 255 alphanumeric characters.
CDR Format	Determines whether the files get inserted into the database.	CDRs will be inserted into database	CDRs will be inserted into database. CDRs will be kept in flat files. Note: Files will not be deleted.
CDR File Time Interval (min)	This parameter specifies the time interval for collecting CDR data. For example, if this value is set to 1, each file will contain 1 minute of CDR data or 1 minute of CMR data. CDR and CMR data is stored in separate files. The files will not be pushed to the CDR data store until the interval has expired, so consider how quickly you want access to the CDR data when you decide what interval to set in this parameter. For example, setting this parameter to 60 means that each file will contain 60 minutes worth of data, but that data will not be available until the 60-minute period has elapsed and the records are written to the CDR database.	1 minute	0 to 1440 minutes
Cluster ID	This parameter provides a unique identifier for this cluster. Because this parameter gets used in CDRs, collections of CDRs from multiple clusters can be traced to the sources.	StandAloneCluster	Up to 50 alphanumeric characters.

As the number of phones and other endpoints increased on the system, the amount of CDR data also increased accordingly. CallManager release 4.1 again increased the size of the system so that it supports as many as 7500 endpoints on a single node with up to 4 active nodes. The CDR data is written in comma-delimited format in flat files on the local disk of each CallManager server in the cluster with an active CallManager node that generates CDRs.

Release 3.3 and all later releases provide two distinct forms for the CDR data. The CDR data is initially written in comma-delimited format in flat files on the local disk. The Cisco Database Layer Monitor service then transfers these files via a TCP/IP connection to a central CDR data store on the Publisher. The data can either be stored as a set of flat files in the data store, or inserted into a SQL database. This transport occurs on an interval specified by the CDR File Time Interval service parameter (default is 1 minute).

You can choose how you want to store the CDR data by setting the CDR Format enterprise parameter appropriately (see Table 7-2). Most deployments choose to insert the CDR data into a SQL database by setting CDR Format to CDRs will be inserted into database. This choice enables the CDR Insert service, which monitors the CDR directories for new CDR data files. When a new file is written into the directory, CDR Insert reads the file and the CDR data it contains is inserted into the CDR database. CDR Insert then deletes the file. Figure 7-2 shows a CDR flow through the system. The CDR subsystem scales very well with this design and handles traffic loads well in excess of the current system capabilities.

Figure 7-2. CDR Flow Through CallManager System

When a CallManager server crashes, it does not affect the accessibility of the CDR data for calls handled by that node because the CDR data is stored in a central data store.

The clustering technology used in CallManager supports a significant number of CallManager nodes. Release 4.0 and later systems support a single cluster of eight CallManager nodes. As the number of nodes in a cluster grows, the collection and processing of CDR data becomes increasingly complex for a call management application, if the data must be collected and processed from each node in the cluster. In this architecture, the cluster looks and functions like a single system.

Storing the CDR data in a central data store provides a single location where all CDR data can be retrieved and processed. Software billing packages do not have to gather data from individual CallManager servers, and, therefore, they are not sensitive to the particular configuration of CallManager.

What Happens When the Central Database Is Not Available?

As in any distributed system, it's possible to lose a link between any of the nodes in the cluster and a central data storage facility.

The design team faced three major challenges in handling this contingency:

• How do you handle CDR data when the link between a CallManager node and the central database has been lost?
• How do you make the data secure on local drives in a cost-effective manner?
• How do you handle the CDR data when the amount of data during peak traffic periods from all CallManager nodes exceeds the capabilities of the database?

To resolve these challenges, the team decided to have all CDR data written as comma-delimited flat files on the local server as soon as data is generated. The data is then transferred to the central CDR data store in background mode. The directory where these files are stored on the local machine is monitored, and when a new CDR file closes (the system is finished writing data into it), the file is moved. After transferring the data successfully to the central CDR data store, the system removes the local copy.

If the link to the central data store is lost for any reason, CallManager stores CDR data on the local drives until the link is restored. The local drives on CallManager servers are mirrored drives so that no data is lost when a single drive fails. Mirrored drives minimize the potential loss of data until the link is restored. When the link is restored, the system transfers the CDR data in background mode to the central CDR data store. After transferring the data successfully, the local copy is removed.

Historical Background

The CDR processing design used in CallManager release 3.0 caused all CDR data to be written directly into the central database. Losing the link to the central database caused the Database Layer to write the CDR data into the local database on the CallManager server. When the link was recovered, the Database Layer transferred the CDR data to the central CDR database in background mode. After successfully transferring the data to the central database, the Database Layer removed the local copy.

During stress tests on CallManager release 3.0, the integration team discovered that the central database could not handle the volume of CDR data being generated within the cluster during peak traffic loads. This caused a design change in CallManager release 3.1 so that the Database Layer would write all CDR data to the local database on the CallManager server first.

As we scaled the cluster for CallManager release 3.2, we found that writes into the local database consumed more processor time than we desired, so we altered the design such that the system writes CDR data in comma-delimited flat files on the local disk, which is very fast. A background process called Aupair then transfers the CDR data to the CDR central data store. This design change enables handling the high traffic loads anticipated as we continue to scale the cluster.

 

What Happens to CDR Data When a CallManager Node Fails?

When a CallManager node fails, it loses all CDR data for all calls that it is controlling that are currently in progress but not completed. If call preservation is provided for the endpoints in question, the calls remain active even after CallManager fails, but there is no way to collect CDR data for those calls. Partial CDRs are never written.

When the CallManager node fails but the server hardware is working and Windows 2000 and the other services such as the database on the server platform that CallManager node is running on do not fail, the system continues transferring CDR data from the local disks to the central database until all local CDR data has been moved. If Windows 2000 crashes due to hardware failure or a system error or any other reason, the local CDR data is not accessible until the Windows 2000 server is brought back online and the system transfers the data to the main CDR data store.

How to Control the Storage and Transport of CDR Data

The two different aspects of CDR storage and processing that you can control are as follows:

• Where CDR data is stored
• How CDR data is stored

Where CDR Data Is Stored

You can control both the location of the central CDR data store, and in what form the CDR data is stored through the Enterprise Parameters page in CallManager Administration (System > Enterprise Parameters).

Table 7-2 identifies the enterprise parameters that control the storage of CDR data.

How CDR Data Is Stored

The CDR data is stored in one of two forms:

• Inserted into a SQL database
• Kept as CSV files in the specified CDR data store

The CDR Format enterprise parameter determines in which form the data is stored. See Table 7-2 for a definition of this parameter. If you use CDR data to create billing records, troubleshoot calls, or need to search the data for any particular reason, you might want the data inserted into a database. This makes the data more easily available for diagnostic, billing, or other such purposes.

On the other hand, if you just need to store the call records to fulfill either government or corporate requirements, you might consider leaving it in CSV files. These files can be compressed and stored in a much smaller space. CallManager is not designed to support storage of CDR data on the CallManager servers. This data must be moved to other servers for long-term storage.

Tip

If CDR data is stored as CSV files in the CDR data store, the files will not be deleted by the system. You need to establish proper file maintenance procedures and make sure the files are removed if appropriate.