Database Cluster

Configure Database Cluster

Now that you have all the certificates uploaded to the CMS servers you can configure and enable database clustering between the three nodes. The first step is to initialize the cluster on one node, making it the master. All other nodes, once joined, will have read-only copies of the database and will not share in the load in any way. If the master has a failure, then one of the others will become the master.

Configure Master Database

The first step in setting up database replication is to specify the certificates that will be used for the database. This is done by using the database cluster certs command. The command takes the following parameters: database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>.

Connect to your cms1a server via SSH:

Cisco Meeting Server Name Password
cms1a.pod2.cms.lab c1sco123

Issue the following commands to configure the master database. First, set the certificates:

cms1a> database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer Certificates updated

Now we tell CMS which interface to use for database clustering. The servers in this lab only have a single interface, a.

cms1a> database cluster localnode a Localnode updated

Next we initialize the cluster database on the master. 

cms1a> database cluster initialize WARNING!!! Are you sure you wish to initialize this node as a new database cluster? (Y/n) Y The contents of this node's database will become the master version of the database in the new cluster. The callbridge and web administration will restart at the end of this procedure. Server certificate/key validated.. Client certificate/key validated.. Please wait... Initialization started...

Note:  Please be sure that Y gets pressed after entering the database cluster initialize command. It is not sufficient to just press Enter. The system will look like its hung otherwise.

Check the status until initialization has completed.

cms1a> database cluster status Status : Enabled Nodes: 10.0.102.51 (me) : Connected Master Node in use : 10.0.102.51 Interface : a Certificates Server Key : dbclusterserver.key Server Certificate : dbclusterserver.cer Client Key : dbclusterclient.key Client Certificate : dbclusterclient.cer CA Certificate : cmslab-root-ca.cer Last command : 'database cluster initialize' (Success)

Configure Client Database Nodes

Now you can focus on the other database nodes. As before, we must specify the database certificate information. The command to do this is identical to cms1a as shown below. Connect to cms1b to configure the database.

Cisco Meeting Server Name Password
cms1b.pod2.cms.lab c1sco123

Initially the database cluster status shows everything blank.

cms1b> database cluster status Status : Disabled Node in use : None Interface : -unset- Certificates : None

Assign the certificates for cms1b.

cms1b> database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer Certificates updated

Next, assign the interface for database communications.

cms1b> database cluster localnode a Localnode updated

The database cluster status reflects these changes.

cms1b> database cluster status Status : Disabled Node in use : None Interface : a Certificates Server Key : dbclusterserver.key Server Certificate : dbclusterserver.cer Client Key : dbclusterclient.key Client Certificate : dbclusterclient.cer CA Certificate : cmslab-root-ca.cer

Finally, join cms1b to the existing master (cms1a.pod2.cms.lab) by specifying its hostname or IP address as follows.

cms1b> database cluster join 10.0.102.51 WARNING!!! Are you sure you wish to join this node to an existing database cluster? (Y/n) Y The contents of this node's database will be destroyed! The callbridge and web administration will restart at the end of this procedure. Server certificate/key validated.. Client certificate/key validated.. Please wait... Join started...

Now check the progress with the database cluster status command.

cms1b> database cluster status Status : Attaching (Started 5 seconds ago) Node in use : None Interface : a Certificates Server Key : dbclusterserver.key Server Certificate : dbclusterserver.cer Client Key : dbclusterclient.key Client Certificate : dbclusterclient.cer CA Certificate : cmslab-root-ca.cer Last command : 'database cluster join 10.0.102.51' (In Progress)

Eventually it should yield Success.

cms1b> database cluster status Status : Enabled Nodes: 10.0.102.51 : Connected Master 10.0.102.52 (me) : Connected Slave ( In Sync ) Node in use : 10.0.102.51 Interface : a Certificates Server Key : dbclusterserver.key Server Certificate : dbclusterserver.cer Client Key : dbclusterclient.key Client Certificate : dbclusterclient.cer CA Certificate : cmslab-root-ca.cer Last command : 'database cluster join 10.0.102.51' (Success)

Perform the same steps on cms1c as follows.

Cisco Meeting Server Name Password
cms1c.pod2.cms.lab c1sco123

Now perform the exact same commands on CMS1c, but send them all at once.

database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer database cluster localnode a database cluster join 10.0.102.51 Y

Then check the progress with the database cluster status command.

Cisco Meeting Server Name Password
cms1a.pod2.cms.lab c1sco123
cms1b.pod2.cms.lab c1sco123
cms1c.pod2.cms.lab c1sco123

Once all slave nodes are joined, the status from all should show a Connected Master and two Connected Slaves which are both In Sync.  The last command status will be specific to the particular server.

cms1a> database cluster status Status : Enabled Nodes: 10.0.102.51 (me) : Connected Master 10.0.102.52 : Connected Slave ( In Sync ) 10.0.102.53 : Connected Slave ( In Sync ) Node in use : 10.0.102.51 Interface : a Certificates Server Key : dbclusterserver.key Server Certificate : dbclusterserver.cer Client Key : dbclusterclient.key Client Certificate : dbclusterclient.cer CA Certificate : cmslab-root-ca.cer Last command : 'database cluster initialize' (Success)

You now have a functioning database cluster and can start working on administrative access.