How to Configure a Database Cluster of CMS version 3.0

Introduction

This document describes a Cisco Meeting Server (CMS) Database (DB) Cluster configuration step by step.

Contributed by Amadeus Ubaldo and Octavio Miralrio, Cisco TAC Engineers.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• CMS general configuration
• Secure Shell (SSH) client
• Secure File Transfer Protocol (SFTP) client

Components Used

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

• CMS version 3.0
• Putty SSH client
• Windows Secure Copy (winSCP) client

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Configure

Network Diagram

Configurations

Step 1. Select one CMS to be the primary node of the database cluster.

Note: CMS database cluster requires an odd number of servers and maximun 5. Please review the documentation for more detail CMS Configuration Guide.

Step 2. On the CMS you selected for the primary role, use SSH client to open its Mainboard Management Processor (MMP) interface.

Step 3. Generate a Certificate Signing Request (CSR) for client role. Use the next format:

Note: The Common Name (CN) for the client CSR must be postgres.

pki csr  <key/cert basename> CN:postgres
pki csr DBClient CN:postgres

Step 4. Generate a CSR for server role. Use the next format:

Note: Add the Fully Qualified Domain Names (FQDNs) from the other servers part of the same Database cluster as Subject Alternative Name (SAN).

pki csr  <key/cert basename> CN:<server1.domain.com> subjectAltName: <server2.domain.com,server3.domain.com>

pki csr DBServer CN:cms01.mxc-cmspod3.lab subjectAltName:cms02.mxc-cmspod3.lab,cms03.mxc-cmspod3.lab

Step 5. Validate that there are now four files created with the name you used from the previous commands.

DBServer.csr

DBServer.key

DBClient.csr

DBClient.key

Step 6. Follow steps 3 and 4 with the rest of your CMS servers part of the DB cluster.

Note: The same client and server CSRs and key pair generated from the first server can be used for the rest of the peers on the cluster. In order to to this copy the .key files and the certificates already signed to the rest of the CMS servers with an SFTP software.

Step 7. Use an SFTP software of your preference to access each server in order to collect the CSR files.

Step 8. Provide the CSR files from each server to the Certificate Authority (CA) you plan to use for certificate sign.

Step 9. Once the certificate is already signed, use an SFTP client to upload the signed certificates to each CMS server respectively.

Step 10. Access via CLI to your CMS server and assign the certificate and key files to the database cluster service. Use the next syntaxis:

database cluster certs <server.key> <server.cer> <client.key> <client.cer> <ca.crt>

database cluster certs DBServer.key DBServer.cer DBClient.key DBClient.cer CA_Root.cer

Step 11. Repeat step 10 for the rest of your CMS servers in order to assing the certificates respectively.

Step 12. Access via CLI to the CMS desginated to be the master node for the DB cluster, select the interface assigned to be used for the DB service, in this example it is the interface a and run the command:

database cluster localnode a

Step 13. Repeat step 12 on the rest of the CMS servers planned to become part of the CMS DB cluster.

Step 14. Access via CLI to the CMS with master DB role to initialize the database service, run the next command:

database cluster initialize

Note: The confirmation is case sensitive, ensure you type the letter Y with upper case. This command must be run only in the database primary and not in the next nodes.

Step 15. The next warning is shown. Select Y.

database cluster initialize WARNING!!! Are you sure you wish to initialize this node as a new database cluster?(Y/n)
The contents of this node's database will become the primary version of the database in the new cluster.

Initialization started...

Step 16. Verify the status of the initialization, run the command database cluster status.

Status:               initializing
Nodes:        
172.16.85.108 (me):   Connected primary
Interface:            a

Note: The status shows initializing if the database service initialize processs is not completed yet.

Step 17. Run the command database cluster status until the status is Enabled, that means the initilize process is successful as shown in the next output:

Status:       Enabled
Nodes:        172.16.85.108 (me) : Connected primary
Interface:    a

Step 18. Access via CLI to the next CMS peer that is part of the database cluster.

Step 19. Run the command database cluster join <primary_database_ip_address>.

Step 20. Select Y.

cms> database cluster join 172.16.85.108

WARNING? ! !
Are you sure you wish to attach this node to an existing database cluster? (Y/n)
The contents of this node's database will be destroyed!

Attachment started...

Step 21. Repeat the procedure described on steps 18, 19 and 20 for the rest of the servers.

Verify

You can verify the status of the database cluster directly on the CLI. Run the command database cluster status. the next output shows the cluster process is not completed yet:

cms> database cluster status

Status:              Attaching
Nodes:
172.16.85.108:       Connected Primary
172.16.85.117 (me):  Connected Replica
172.16.85.118:       Connected Replica
Interface:           a

When the database cluster join processs is completed successfully you must see the status as Enabled:

cms> database cluster status

Status:                Enabled
Nodes:
172.16.85.108:         Connected Primary
172.16.85.117 (me):    Connected Replica
172.16.85.118:         Connected Replica

Node in use:           172.16.85.108
Interface:             a     

Certificates
Server Key:            DBServer.key
Server Certificate:    DBServer.cer
Client Key:            DBClient.key
Client Certificate:    DBClient.cer
CA Certificate:        CA_root.cer
Last command:          'database cluster join 172.16.85.108' (Success)