See Also
Topic Last Modified: 2010-04-27
This section describes what is required to enable Call Detail Record (CDR) and Quality of Experience (QoE) data collection and reporting in a Microsoft Communications Server 2010 deployment, including components, supported topologies, recommended deployment sequence, prerequisites for deployment, and the deployment process.
Feature Components
To enable CDR and QoE data collection and reporting, deploy Monitoring Server, which is a server role in Communications Server 2010. To do so, define the deployment using Topology Builder, and then run the Communications Server deployment tool using the configuration information defined by Topology Builder.
Monitoring Server also requires Monitoring Server databases that use Microsoft SQL Server. The databases can be collocated on the same computer as Monitoring Server, or on a different computer. For more information about deploying Monitoring Server, including requirements, see Deploying Monitoring.
Supported Topologies
The Monitoring Server feature includes the following components:
- The Monitoring Server, which is the server role that
captures usage data and media quality data. This includes two
parts: The CDR service for capturing CDRs (usage data), and the QoE
service for capturing media quality data
- The Monitoring Server databases, which run on SQL Server
and store the captured data. There are separate databases for CDR
and QoE information, but both always run on the same server in the
same instance.
- The Data Collection Agents, which are installed
automatically on every Front End Server. The CDR agent intercepts
SIP messages and uses them to send data to the destination queue on
the Monitoring Server. The QoE agent receives QoE data reports from
endpoints through SIP SERVICE requests, and sends the data to the
destination queue on the Monitoring Server and/or to third-party
consumers using HTTP POST.
- Microsoft Message Queuing, which must run on each
Monitoring Server and on each Front End Server that reports data to
Monitoring Server.
- The Systems Center Operation Management (SCOM) pack is
an optional component. This component can perform server monitoring
for your entire deployment, and it can use Monitoring Server data
to generate near real-time alerts showing the health of the A/V
Conferencing Server component on your Front End Servers, as well as
the health of Mediation Servers and network locations.
- The Monitoring Server Reports are out-of-the-box reports
providing usage and media quality information, based on CDR and QoE
data stored in the CDR and QoE databases. The reports are generated
with the SQL Server Reporting Services.
For details, including a list of hardware and software requirements for Monitoring Server and the server running the Monitoring Server database, see Components Required for Enterprise Voice.
Each Monitoring Server can capture data from one or more Standard or Enterprise Edition pools, Standard Edition servers, and Mediation Servers. When you deploy a Monitoring Server, you associate it with the pools or servers that it is to monitor. The following figure illustrates two possible Monitoring Server topologies.
Monitoring Server topologies
 Note: |
|---|
| You can associate multiple Monitoring Servers with a single Monitoring database that runs on a different computer. In this topology, it is important to configure the purge time for the Monitoring Servers to avoid potential database lockouts that can occur when purges run simultaneously. |
Supported Collocation
Communications Server 2010 supports a variety of collocation scenarios, allowing you flexibility to save hardware costs by running multiple components on one physical server, if you have a small organization, or to separate components onto different servers, if you have a larger organization that needs scalability and performance. Scalability factors should certainly be considered before you decide to collocate Monitoring Server or its databases with other server roles or databases.
Monitoring Server can be collocated with a Standard Edition server. If your deployment is a single Standard Edition Server, collocating Monitoring Server with it can save you from needing a separate computer for Monitoring Server.
Monitoring Server can also be collocated with other Communications Server roles, such as Archiving Server. If Monitoring Server and Archiving Server are collocated, their databases can be hosted on that same server as well, or located together on another server, or separated onto different database servers.
| Note: |
|---|
| If you collocate Monitoring Server with a Standard Edition server, you must install a full edition of SQL Server on the server, instead of using the SQL Server Express Edition normally used with a Standard Edition server. |
The Monitoring Server and the Monitoring Server databases can be collocated on the same server or installed on separate servers, as illustrated in the following figure.
Monitoring Server database collocation
The server hosting the Monitoring Server databases can also host other databases. The following scenarios are supported:
- Monitoring Server databases collocated with one or more other
Communications Server databases, (including the back-end database,
Archiving database, and Response Group application database, for
example).
- Monitoring Server databases collocated with databases of
third-party products.
Scaling
When you deploy Monitoring Server, you associate it with one or more Front End pools, and/or Mediation Servers. Monitoring Server then collects data from the pools you have associated it with. It is recommended, but not required, to have all Front End pools in the same Enterprise pool associated with a single Monitoring Server.
For best scalability, do not collocate the Monitoring Server with another server role or collocate the Monitoring Server databases with any other databases. Hosting the Monitoring Server databases on a separate computer from the Monitoring Server itself does not significantly improve performance.
A single Monitoring Server can serve up to 300,000 users. If you have multiple pools that total less than 300,000 users, we recommend that you associate all these pools with a single Monitoring Server, to simplify administration. Alternatively, if you have pools at different physical locations, it may make more sense to deploy a Monitoring Server at each location.
Monitoring Database Performance
For optimal performance, we recommend putting these files on four physical disks:
- System file and Message Queuing (MSMQ) file on the same
physical disk
- QoE database data file and CDR database data file on the same
physical disk
- QoE database log file
- CDR database log file
If you collocate the Monitoring Server databases with other databases on the same server, you should run the Monitoring Server databases in a separate instance from other databases. Additionally, you should put the Monitoring Server database data files and log files on separate physical disks, for optimal performance. You should carefully evaluate performance impacts before deciding to collocate the Monitoring Server databases with other databases.
Monitoring Database Size
Based on the Communications Server user model, the CDR database grows 8.8 KB per user per day, and the QoE database grows 16.8 KB per user per day. To get an estimate of your database size, use this formula:
Database size = (DB growth per user per day) *
(Number of users) * (Number of days)
For example, 60 days of data in the CDR database for
50,000 users would be 8.8*50000*60 for a total of 25
GB. If your organization’s Communications Server differs
significantly from the user model, adjust the daily database growth
estimate.
You can use this formula, along with the knowledge of your available database disk space, to help decide how many days of data to keep on your database (the default is 60 days).
Report Performance
Reporting is another factor affected by performance.
The provided standard set of reports are designed to work in most
scenarios, but if you need reports on very large data, such as a
QoE report on 10 million calls, an offline reporting solution may
be more appropriate. The reports use the tempdb
database in SQL Server as an internal cache, so we recommend that
you put tempbd on a separate physical disk, with at
least 10 GB available space. One additional thing to consider is
that if your Monitoring database size is larger than the database
server’s physical memory, Monitoring Server report performance can
be affected.
Monitoring Server
Prerequisites
Before deploying Monitoring Server, you must install the following software:
- Message Queuing on the server running Monitoring Server
- Microsoft SQL Server and SQL Server Reporting Services
Load Balancer Port Requirement
To collect CDR or QoE data, you must open port 5069 on the Front End servers. The port is used for message queuing RCP operations.
Deployment Sequence
Deploy Monitoring Server after you have deployed at least one Enterprise Edition or Standard pool. Be sure to associate a pool with a deployed Monitoring Server when you enable QoE and CDR data collection on that pool, so that the data will be collected and stored.Deploying Monitoring Server relatively early in your deployment process can be useful so that you can collect CDR and QoE data and see the usage and media quality of your network during your planning and predeployment phases.
Deploying Monitoring Server relatively early in your deployment process can be useful so that you can collect QoE data and see the media quality of your network during your planning and predeployment phases.
Monitoring Server Deployment
Process
Before you deploy Monitoring Server, you need to verify that your system infrastructure and the server on which you will install Monitoring Server meet the hardware and software requirements previously described in this section. When the environment is ready, you install the Monitoring Server files and associate the Monitoring Server with the pools that it will monitor. For details see Deploying Monitoring.