Cisco Meeting Server VKM Configuration Guide

Overview

The Cisco Meeting Server (CMS) was formerly known as the Acano Server. The CMS software can be hosted on specific servers based on the Cisco Unified Computing Server (UCS) technology and Acano X-Series hardware or on a specification-based VM server.

Note

Meeting Server and CMS can be used interchangeably in this guide for Cisco Meeting Server. Meeting Server is also used to refer to the UCS-based servers, specification based VM hosts, and Acano X-Series servers.

A Meeting Server comprises a number of components that can be used to adapt a solution to the customer's video conferencing needs. The components can be hosted on a single server or split between a server core and an Edge server in the system for increased security. The flexibility of the Meeting Server architecture enables the customer's system to expand as their video conferencing requirements grow. System capacity can be increased by adding Meeting Servers and clustered together for resiliency.

There are two types of component clustering between the CMS servers:

Database Clustering

Call Bridge Clustering

Database Clustering

In a scalable and resilient deployment, the database can be detached from the Call Bridge and run as a separate component. It can be on the same server as the Call Bridge or on a different server. Multiple instances of the database can be clustered together to provide resiliency in the deployment.

When database clustering is employed, one CMS server database component will be the master database and generally co-located with the Call Bridge component on that server.

Database clustering works differently to Call Bridge clusters. A database cluster creates what is essentially an 'online' backup of the running database that is maintained as the system runs. It also provides the ability to move to using the backup in an automated fashion in the event a failure is detected.

Note

Only five database nodes are allowed in a cluster.

Database clustering does not have any kind of load balancing or caching. It also does not have any data sharing for more efficient local access within any kind of geographically distributed arrangement. All queries are directed at the current master. The replicas are not available as read only instances.

Call Bridge Clustering

Within a Meeting Server deployment, Call Bridge clustering will allow multiple Call Bridges to operate as a single entity and scale beyond the capacity of any single Call Bridge.

Note

A maximum of 24 Call Bridge nodes are allowed in a cluster. A cluster design of eight or more nodes must be approved by Cisco.

About this Guide

This guide explains how to enable and configure the CMS VKM, including:

Enable the CMS Module

Configure CMS

Configure CMS VKM

View Inventory

Manage CMS Clusters

Supported Software Versions

• Nectar UCMP v8.7
• CMS v2.2 and later

Enable the CMS Module

Follow these steps to enable the CMS module:

1. Navigate to RIG > Module Configuration. The Module Configuration window appears.
2. Select Cisco Meeting Server.

1. Click Apply.

Figure 2-1 Enable Cisco Meeting Server

1. To restart the RIG and apply the changes:
   1. Navigate to RIG > Admin > Restart.
   2. When the following message appears, click Yes.

Figure 2-2 Restart

Configure CMS

The CMS software has two layers:

• Platform
• Application.

The Platform is configured through the Mainboard Management Processor (MMP). (For more information, see Cisco Meeting Server Release 2.5 MMP Command Line Reference (PDF - 932 KB)). The MMP is used for low-level bootstrapping and configuration via its command line interface. For example, the MMP is used to enable components and configure SNMP and admin/ API users.

The Application runs on this managed platform with configuration interfaces of its own. The application level administration (call and media management) is performed using either the Call Bridge's Web Admin Interface or through the API. (For more information, see Cisco Meeting Server Release 2.4 and later API Reference Guide (PDF - 4 MB)). The Web Admin interface is suitable for configuring a single Call Bridge. To configure multiple Call Bridges, it is necessary to use the API.

Note

If clustering is not configured, then each CMS server is administered and maintained separately.

Configuring the CMS includes the following tasks:

Configure CMS SNMP

Configure Nectar User

Configure CMS SNMP

Use the following information to configure CMS SNMP.

MMP SNMP Commands

The Meeting Server supports SNMP versions 1, 2c, and 3.

• For SNMP versions 1 and 2c, access control is based on ‘communities’. These can be created using the MMP interface when SNMP is disabled.

*snmp community add 

Example: snmp community add cmpreadonly

• For SNMP version 3, access control is based on ‘users’. These can be created using the MMP interface.

snmp user add (MD5|SHA) (DES|AES)

SNMP Trap Receiver Configuration

• Configure an SNMP trap receiver(s) using the MMP interface.

snmp trap enable 

• 
  
  • is the host name of the machine that will receive traps.
  • is the community string that will be used. Example: snmp trap enable cms.mycorp.com cmpreadonly

Note

The Meeting Servers should be onboarded successfully before being configured to send SNMP traps to the RIG.

Configure Nectar User

Use the following information to configure the Nectar (API) User to be used when you onboard a CMS cluster.

MMP User Account Commands

The MMP User Account Commands require you to be logged into a MMP account with admin

rights.

The MMP user account roles are:

• admin - MMP administrator; permitted to do all tasks.
• crypto - MMP cryptography operator; permitted to do crypto-related tasks.
• audit - Sends audit logs to a Syslog server.
• appadmin - Performs application level configuration using the WebAdmin Interface.
• api - Uses the API.

The CMS VKM requires a user to be created with the api role.

user add (admin|crypto|audit|appadmin|api)

Example: user add nectarapi api

Configure CMS VKM

Server architecture enables the customer’s system to expand as their video conferencing requirements grow. Capacity can be increased by adding meeting servers that are clustered together for resiliency.

The most common deployments use the following scenarios:

• Single combined server
• Single split server
• Scalable and resilient

When configuring CMS, a single database can be a ‘cluster’ because it can have one or more Call Bridges using it. However, there is no resilience. For this reason, Nectar CMS VKM will refer to any CMS system (single node or multi-node systems employing clustering) as a cluster for onboarding/monitoring purposes.

Note

If the API service is not enabled for a database cluster node in CMS, then disable all API-specific pollers in the RIG for the agent that is created for that database cluster node.

For more information, see Remote Intelligence Administration Guide.

This section explains how to:

Add a CMS Cluster

View Collections

Add a CMS Cluster

Follow these steps to add a CMS cluster.

1. Navigate to Modules > Cisco > Meeting Server.

Figure 4-1 Modules > Cisco > Meeting Server

The Cisco Meeting Server Setup - Configurations window appears.

1. Click Add.

Figure 4-2 Cisco Meeting Server Setup - Configurations

The Add Cisco Meeting Server - General window appears.

Figure 4-3 Add Cisco Meeting Server - General

1. Enter the following information; then click Next.

Table 4-1 Add Cisco Meeting Server - General

The Add Cisco Meeting Server - SNMP window appears.

Figure 4-4 Add Cisco Meeting Server - SNMP

1. Enter the following primary CMS server and SNMP information; then click Next.

Table 4-2 Add Cisco Meeting Server - SNMP

Table 4-2 Add Cisco Meeting Server - SNMP

Note

For more information, see also Configure CMS SNMP.

The Add Cisco Meeting Server - API window appears.

Figure 4-5 Add Cisco CMS - API

1. Enter the following API User information.

Note

The API settings must be the same for all peers in the cluster.

1. Click Next.

Table 4-3 Add Cisco Meeting Server - API

The Add Cisco Meeting Server - Cluster window appears populated with the onboarded CMS cluster/peer.

Single-Node System:

Figure 4-6 Cluster Tab - Single-Node System

Multi-Node System/Cluster:

Figure 4-7 Cluster Tab - Multi-Node System/Cluster

1. Select and configure the peer(s) you want to use.

Note

The values for the SNMP and API tabs for each peer are inherited from the values entered for the CMS (peer).

Click Edit to make changes to the peer (SNMP settings only). The API settings are not editable; therefore, must be the same for all peers in the cluster.

For more information, see Edit a CMS Cluster.

1. Click Finish.

The new cluster appears in the Cisco Meeting Server Setup - Configurations window.

Figure 4-8 Cisco Expressway Cluster

The VKM collection processes and Nectar monitoring are also initiated. For more information, see View Collections.

View Collections

Follow these steps to view a list of collections for a CMS cluster:

1. Navigate to Modules > Cisco > Meeting Server. The Cisco Meeting Server Setup window appears.
2. Select the new CMS cluster; then click View Collections.

Figure 4-9 View Collections

The Collections window appears.

Figure 4-10 Collections

1. Notice that the status of the Collection changes from Executing to Success.

When the status of all Collections shows Success, the cluster is onboarded and being monitored.

Note

For more information on collections, see Manage Collections.

5.View Inventory

When a CMS server is part of a cluster, most configuration/collections are replicated across the peer(s) in the cluster and only need to be collected from the CMS primary server used to onboard the CMS cluster. However, some configuration/collections are peer-specific and need to be collected from each peer server in the cluster.

Follow these steps to view inventory data for a specific CMS cluster or all clusters.

1. Navigate to Reports > Inventory > Cisco > Meeting Server.

Figure 5-1 Reports > Inventory > Cisco > Meeting Server

The Cisco Meeting Server Inventory window appears.

Figure 5-2 Cisco Meeting Server Inventory

1. Select an inventory category, such as Cluster Servers.

The Listing pane appears to the right along with information about the selected inventory category, in this case, Cluster Servers.

Single-Node System:

Figure 5-3 Example - Single-Node System

Multi-Node System/Cluster:

Figure 5-4 Example - Multi-Node System/Cluster

1. Notice the MeetingServer Clusters drop-down.

You can click the drop-down to select a specific CMS cluster when there are more than one onboarded clusters to filter the list.

Single-Node System:

Figure 5-5 Example - Single-Node System

Multi-Node System/Cluster:

Figure 5-6 Example - Multi-Node System/Cluster

Manage CMS Clusters

This section explains several tasks that can be used to manage the CMS clusters, including:

Edit a CMS Cluster

View Agents and Poll Functions

View Dependency Tree

Manage Collections

View CMS Alarms

Edit a CMS Cluster

Follow these steps to edit a CMS cluster, as needed:

1. Navigate to Modules > Cisco > Meeting Server.

The Cisco Meeting Server Setup - Configurations window appears.

Figure 6-1 Cisco Meeting Server Setup - Configurations

1. Select an existing CMS cluster that you want to edit; then click Edit. The Edit Cisco Meeting Server window appears.

Figure 6-2 Edit Cisco Meeting Server

1. Click one of the following tabs:

General

SNMP

API

Cluster

1. Edit the CMS cluster, as needed.

Note

The Name of the cluster under the General tab cannot be edited. The IP Address

under the SNMP tab cannot be edited.

To edit a peer under the Cluster tab:

1. Click Edit.

Figure 6-3 Cluster Tab

The Edit Peer window appears.

Figure 6-4 Edit

1. Make changes to the SNMP settings, as needed, for the peer; then click OK.

Note

Repeat Step a and Step b for each additional peer to be edited.

The API settings are not editable here; therefore, must be the same for all peers in the cluster.

1. Click OK again.

Remove or Offboard a CMS Cluster

Follow these steps to remove or offboard a CMS cluster, as needed:

1. Navigate to Modules > Cisco > Meeting Server.

The Cisco Meeting Server Setup - Configurations window appears.

Figure 6-5 Cisco Meeting Server Setup

1. Select an existing CMS cluster that you want to remove or offboard; then click Remove.
2. When the following message appears, click Yes.

Figure 6-6 Remove

The CMS cluster is removed and no longer listed on the Cisco Meeting Server Setup - Configurations window.

1. When the following window appears, click OK.

Figure 6-7 Offboarding Complete

View Agents and Poll Functions

The Cisco Meeting Server VKM adds an agent and poll functions for each onboarded cluster.

Option 1 - View Agents

Follow these steps to view the new agent and poll functions that were created for each cluster:

1. Navigate to Health > Elements.

1. Click Agents.

Figure 6-8 Elements > Agents

A list of agents appears.

Note

The actual list of agents will depend on the architecture of each individual Cisco Meeting Server deployment.

1. Click on an CMS agent to view the poll functions for that agent. View the following example.

Figure 6-9 Agent > Poll Functions

You can also select a poll function and modify parameters and thresholds.

View Agents - Option 2

Follow these steps to view the new agent and poll functions that were created for each cluster:

1. Navigate to Health > Elements.

The Elements window appears.

Figure 6-10 Health > Elements

1. Click Folders.

Figure 6-11 Elements > Folders

A list of folders appear.

1. Click the Cisco CMS folder.

The Infrastructure pane appears and contains a folder for the cluster, such as CiscoCMS.

Single-Node System:

Figure 6-12 Infrastructure/Cluster Folder - Single-Node System

Multi-Node System/Cluster:

Figure 6-13 Infrastructure/Cluster Folder - Multi-Node System/Cluster

1. Click a cluster folder, such as CiscoCMS, to view the agent(s) for that cluster.

Single-Node System:

Figure 6-14 Infrastructure/Agent - Single-Node

Multi-Node System/Cluster:

Figure 6-15 Infrastructure/Agent - Multi-Node System/Cluster

1. Click on a CMS agent, such as CiscoCMS-CMS-PRI-192, to view the poll functions for that agent.

View the following example.

Figure 6-16 Poll Functions

You can also select a poll function and modify parameters and thresholds.

View Dependency Tree

Follow these steps to view the dependency tree for an agent/cluster:

1. Navigate to Configure > Dependency Trees. The Dependency Trees window appears.

Figure 6-17 Dependency Trees

1. Select a Cisco CMS dependency tree in the left pane; then click View.

The dependency tree appears in the right pane.

Figure 6-18 View Dependency Tree

Manage Collections

Managing collections includes the following tasks:

Enable a Collection

Disable a Collection

Change a Collection Schedule

Execute a Collection

Note

To view a list of collections for a Cisco Expressway cluster, see View Collections.

Enable a Collection

Follow these steps to enable a collection for a particular CMS cluster:

1. Select a collection you want to enable.
2. Right-click and select Enable.

The Enabled column for the collection changes to Yes.

Disable a Collection

Follow these steps to disable a collection for a particular CMS cluster:

1. Select a collection you want to disable.
2. Right-click and select Disable.

The Enabled column for the collection changes to No.

Change a Collection Schedule

Follow these steps to change the collection schedule for a particular CMS cluster:

1. Select a collection you want to change.
2. Right-click and select Change Cron String. The Update Cron String window appears.

Figure 6-19 Update Cron String

1. Enter the new collection schedule using a Cron expression.
2. Click OK.

The updated collection schedule appears in the Cron column.

Execute a Collection

Follow these steps to execute a collection:

1. Select a collection you want to execute.
2. Right-click and select Execute Now.

The collection executes. The Status column changes to Executing; then changes to Success

when completed.

View CMS Alarms

Alarms occur when an event or configuration change has taken place on the CMS. Other events may also be raised for system events, hardware, and environmental issues, such as faulty disks and fans or high temperatures. SNMP traps are also generated. For additional information, see Configure CMS SNMP.

CMS alarms are retrieved in the CMS VKM using the CMS API. When received, an event is created. To view alarms, navigate to Health > Events.