Sdílet prostřednictvím


Planning for Monitoring

 

Topic Last Modified: 2012-10-17

This section describes what is required to enable call detail recording (CDR) and Quality of Experience (QoE) data collection and reporting in a Microsoft Lync 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 Lync Server 2010. To do so, define the deployment using Topology Builder, and then run the Lync Server Deployment Wizard 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 details about deploying Monitoring Server, including requirements, see Deploying Monitoring in the Deployment documentation.

In order to deploy Monitoring Server Reports, you need to deploy SQL Server Reporting Services. You can install Reporting Services on the same instance of the SQL Server that hosts the Monitoring Server database, or on a different instance of SQL Server.

Supported Topologies

The Monitoring Server feature includes the following components:

  • Data Collection Agents   Installed automatically on every Front End Server. The CDR agent intercepts SIP messages and sends 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 or to third-party consumers using HTTP POST.

  • Monitoring Server   Persists data received from Message Queuing to the SQL Server Monitoring Server database. This includes two parts: The CDR service and the QoE service. In order to collect data from a Registrar pool, you must use Topology Builder to associate the Monitoring Server with the Registrar pool.

  • Monitoring Server databases   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 instance of SQL Server. Monitoring Server databases require the full edition of SQL Server. SQL Server Express is not supported.

  • Message Queuing   Must run on each Monitoring Server and on each Front End Server that reports data to Monitoring Server. For each server, Message Queuing must be installed as Active Directory Domain Services (AD DS) integration mode so that the data can be delivered from Data Collection Agents to Monitoring Server.

  • (Optional) System Center Operations Manager management pack   This is an optional component. The Call Reliability and Media Quality Monitoring of component of the System Center Operations Manager management pack uses Monitoring Server CDR and QoE data to generate near real-time alerts that show the health of call reliability and media quality.

  • (Optional) Monitoring Server Reports   This is an optional component. This component contains out-of-the-box reports providing usage, call diagnostic information and media quality information, based on CDR and QoE data stored in the CDR and QoE databases. The reports are generated with 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 in the Planning documentation.

Each Monitoring Server can capture data from one or more Enterprise Edition pools, and Standard Edition servers. When you deploy a Monitoring Server, you associate it with the pools or servers that you want to monitor. The following figure illustrates two possible Monitoring Server topologies.

Monitoring Server topologies

Monitoring Server Topology with Multiple Pools

Supported Collocation

Lync 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.

You can also collocate Monitoring Server with 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.

You can collocate the Monitoring Server and the Monitoring Server databases on the same server or install them on separate servers, as illustrated in the following figure.

Monitoring Server database collocation

Database Collocation diagram

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 Lync Server databases, (including the back-end database, Archiving database, and Response Group application database).

  • Monitoring Server databases collocated with databases of third-party products.

For details about collocation of databases and server roles, see Supported Server Collocation in the Supportability documentation.

Scaling

When you deploy Monitoring Server, you associate it with one or more Front End pools. Monitoring Server then collects data from the pools you have associated it with. We recommend, but it is not required, that you have all Front End pools in the same Enterprise deployment 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 does not significantly improve performance.

When you use the recommended hardware configuration, and you collocate the Monitoring Server and Monitoring database on the same computer, a single Monitoring Server can serve up to 250,000 users. If you have multiple pools that total less than 250,000 users, we recommend that you associate all of these pools with a single Monitoring Server to simplify administration. Alternatively, if you have pools located in different physical locations, it may make more sense to deploy a Monitoring Server at each location.

Monitoring Database Performance

For optimal performance, we recommend that you put the following files on four physical disks:

  • System file and Message Queuing 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 Lync Server user model, the CDR database grows 31.5 KB per user per day, and the QoE database grows 28 KB per user per day. For details about the user model, see Lync Server 2010 User Models in the Planning documentation. To estimate your database size, use the following 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 31.5*50000*60 for a total of 90 GB. If your organization’s Lync 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 might be more appropriate. We recommend that you query reports during a non-busy time in order to avoid resource conflicts with data insertion. Also, if your Monitoring database size is larger than the database server’s physical memory while querying, 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, which must run in AD DS integration mode.

  • Microsoft SQL Server database software and SQL Server Reporting Services

Note

During Microsoft SQL Server setup you must choose a Case Insensitive collation. For example, SQL_Latin1_General_CP1_CI_AS is a Case Insensitive collation and is the default collation on a SQL Server with an English US Windows system locale.
Default collations settings used during SQL Server setup are determined by the Windows system locale. For details, see Collation Settings in Setup at https://go.microsoft.com/fwlink/p/?LinkId=204356.

Deployment Sequence

If you deploy Monitoring Server relatively early in your deployment process, you can collect CDR and QoE data and see the usage and 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 want to install Monitoring Server meet the hardware and software requirements previously described in this section. When the environment is ready, you can install the Monitoring Server files. For details see Deploying Monitoring in the Deployment documentation.

See Also

Other Resources

Deploying Monitoring