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.
Log into cms1a.pod8.cms.lab (password: c1sco123), then copy/paste the following:
database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer
database cluster localnode a
database cluster initialize
Y
Log into cms1b.pod8.cms.lab (password: c1sco123), then copy/paste the following:
database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer
database cluster localnode a
database cluster join 10.0.108.51
Y
Log into cms1c.pod8.cms.lab (password: c1sco123), then copy/paste the following:
database cluster certs dbclusterserver.key dbclusterserver.cer dbclusterclient.key dbclusterclient.cer cmslab-root-ca.cer
database cluster localnode a
database cluster join 10.0.108.51
Y
On each of the CMS servers, run database cluster status to ensure the nodes are in a 'Connected' state.
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>.
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.108.51 (me) : Connected Master
Node in use : 10.0.108.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.
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.pod8.cms.lab) by
specifying its hostname or IP address as follows.
cms1b> database cluster join 10.0.108.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.108.51' (In Progress)
Eventually it should yield Success.
cms1b> database cluster status
Status : Enabled
Nodes:
10.0.108.51 : Connected Master
10.0.108.52 (me) : Connected Slave ( In Sync )
Node in use : 10.0.108.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.108.51' (Success)
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.108.51 (me) : Connected Master
10.0.108.52 : Connected Slave ( In Sync )
10.0.108.53 : Connected Slave ( In Sync )
Node in use : 10.0.108.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.
LTRCOL-2250 - Multiparty Conferencing for Audio, Video and Web Collaboration using Cisco Meeting Server
This lab provides participants hands-on experience with design and implementation fundamentals
of the Cisco Meeting Server (CMS), bringing premises-based multiparty conferencing of video,
audio, and web collaboration together in one platform.
Students will learn to configure CMS
and deploy a secure, scalable, and resilient collaboration solution following Cisco's Preferred
Architecture including the ability to extend the platform beyond the corporate firewall and
allow external Internet participants. The lab will allow students to configure the various
components of CMS, such as Call Bridge, Web Bridge, and XMPP server. These systems will be
integrated with Cisco Unified CM for call control, an LDAP server for authentication and
directory services, and Cisco Expressway for firewall traversal, TURN server and Web Proxy
capabilities to enable secure access for external, WebRTC-enabled browser clients.
Third-party integrations, such as Skype for Business, are explored as well.