Definition and Scope of a Resilient CMS Deployment.

Introduction

This document describes the logic of a resilient deployment for each of the core components in the Cisco Meeting Server (CMS)  3.0 version.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Callbridge, Webbridge3, Database, Webadmin
• Cisco Meeting Server web app
• CMS Application Programing Interface (API)
• Domain Name Server (DNS)
• Network Time Protocol (NTP)
• Cisco Meeting Management (CMM)

Components Used

The information in this document is based on these software versions:

• CMS 3.0 version
• Expressways version X12.6

The information in this document was created from the devices in a specific lab environment and CMS official guides. If your network is live, ensure that you understand the potential impact of any change in your environment.

Definitions

Resilient Deployment

The core components run as separate instances that can work in resiliency which means that the environment recovers capabilities when instances of a core component are lost.

Deploy more than one component in resiliency mode increases resource capabilities that makes the component scalable and allows to plan geographic locations. CMS can handle several feature services, as shown in the image:

All core services can be integrated to provide resiliency except Webadmin which is the component that allows Hypertext Transfer Protocole Secure (HTTPS) access to the Grafical User Interface (GUI) of each individual server either for the administrator or management applications like Cisco Meeting Management (CMM) or Telepresence Management Server (TMS).

Note: In CMS version 3.0 Extensible Messaging and Presence Protocol (XMPP), load balancer, Session Initiation Protocol (SIP) edge, and h.323 gateway components have been removed.

Note: It is not required to enable all components on every server. All components can coexist in the same server which is called Combined Deployment or configured across different servers providing the flexibility that achieves Scalability and Resiliency.

Database

Database components are created automatically upon CMS server installation. Database stores all configuration objects of the CMS server.

Few examples are spaces, members of each space, and dial plan configurations which consist of inbound and outbound rules. If databases are configured in a cluster,  Callbridges on all servers read these configuration items to act as a single entity.

Database components in resiliency have two roles, one is the leader or primary database. If the leader/primary database goes down an election takes placee to select a new leader. The candidates are considered slaves. This ensures that database objects remain available for the rest of the elements in the environment. If the database cluster exceeds 5 number of components, new instances of databases can be added as connected instances to the database cluster. Connected instances read the primary database in the cluster but are not considered part of the database cluster.

Database cluster requirements

• Round trip time of 200ms or less between database servers and Callbridge and primary database.

Considerations

• Do not have a cluster of 2 database nodes, in case of failure the slave server is not able to promote itself as primary
• In a database cluster, only the primary database is used at any time by all Callbridges
• The primary database’s contents are replicated to the rest of the participants in the cluster
• If the primary fails, a new participant is promoted/elected as primary
• If the primary comes back, it remains as a participant and don't claim the primary role
• Loss of network connection to and from the primary result in that database to become a participant
• If there are network connection issues between nodes only databases that see more than half of the total number of the cluster are considered for election.  If there’s no database that sees more than half then the database cluster revers and contan no primary databases
• If no primary database can be elected the cluster must be reinitialized by the administrator
• When there’s no primary database, no changes are allowed either web GUI or API however SIP calls can work
• In CMS 3.0 certificates are required. It provides Secure Sockets Layer (SSL) security for all inter-database communication
• Wan optimizers may prevent keep-alive checks to complete signaling, this can cause errors in database clustering communication

Note: It is recommended for a Database Virtual Machine (VM) host to enable hyper-threading and keep default ESXi system parameters.

Note: It is not necessary to enable a database component in every call bridge.

Callbridge

Callbridge component bridges conference connections and it is in charge of all SIP processing within the server.  The component work in resiliency by configure it in the cluster and add it to the configuration of the Webadmin interface as a Callbridge.

Callbridge cluster configuration is only available after databases are clustered. This allows multiple call bridges to operate as a single entity to increase call capacity and distribute meetings across multiple call bridges. After Callbridge cluster configuration is finished, all Callbridge components read configuration objects from the same database component regardless of the geographic location.

Webbridge 3

Webbridge3 allows end-users to connect to conferences via CMS Web App. Webbridge3 instances can work in resiliency by add them to the Callbridges objects via API through the Webadmin interface. Callbridges identify each Webbridge3 component by a unique hostname or IP address.

Note: if CMS is used only as a conference resource and end-user don't need to use the Cisco Meeting Server web app, Webbridge 3 is not required to be deployed.

Recorder and streamer

In CMS 3.0, recorder and streamer components are SIP-based. In earlier versions of CMS, these two components were dependent upon the XMPP component which in version 3.0 is deprecated. These components work in resiliency by add them to the Callbridges. Callbridges select the best component based on the preference configured via API interface to call bridge objects.

Uploader

The uploader work in resiliency by add them to the Callbridges.  Callbridges select the best component based on to the preference configured via API interface to callbridge objects.

Examples

The flexibility of the CMS components allowa that many topologies can be designed. The next images are examples of deployments that this flexibility provides they allow installation of components in the servers according to the needs of the environment.

Example 1:

In the example below there are three CMS servers where CMS01 and CMS02 have the illustrated components enabled however CMS03 is dedicated to only one core component, in this case the database.

Example 2

Resiliency deployments can be tuned and segmented with Callbridge Groups to load-balanced calls across a fewer number of Callbridge to avoid redistribution of the calls of the same conference split through different locations.

In the neext example there are 5 CMS servers with the bellow core components enabled.

Example 3

Streamer and recorder components can be integrated with the solution in a combined/split solution and also in a resiliency deployment. Streamer and recorder components are not aware that they are working in resiliency however the Callbridge via API configuration connects to the recorder and streamer components. If there are more than one instance, allow Callbridges to select the preferred server.

The next image shows a CMS single combined server integrated with Streamer, Recorder, and Uploader configured in dedicated servers:

Example 4

The next image integrates Example 1 with a number of Streamer, Recorder, and Uploader components.

Note: In production environments Callbridge must be configured separated from Streamer, Recorder, and Uploader.

Licensing

In resilient environments licensing can be provided by the Smart Licensing model or traditional Activation Key (PAK).

Web app

For end users to join Webbridge 3 components, the experience is seamless.

Cisco Meeting Management

CMM is required for all 3.0 deployments.