From version 3.5, Cisco Meeting Server can use other validations Hostname/IP AddressIf you are deploying or upgrading to version 3.6 (or 3.5). The database cluster nodes might fail to connect to each other. The reason is that each server will try to resolve the server’s name (or hostname) of each node in the cluster, which is not available in version prior 3.5.
To solve this issue, You need a DNS Record, fortunately a DNS RR record can be created on CMS to resolve the server identity locally.
Let’s take an example, if you have three Nodes running the database cluster with 3.6 version with hostname CMS1 10.1.5.61, CMS2 10.1.5.62 and CMS3 10.1.5.63, CMS1 as the primary or the master node:
Database configuration
On CMS1.
database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
database cluster localnode a
database cluster initialize
On CMS2 and CMS3.
database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
database cluster localnode a
database cluster join cms1.lab.local
CMS2 tries to resolve the server’s name CMS1 but cannot find the IP address 10.1.5.61.
CMS3 tries to resolve the server’s name CMS1 but cannot find the IP address 10.1.5.61.
CMS2 cannot find the IP address 10.1.5.63 of the hostname CMS3.
CMS3 cannot find the IP address 10.1.5.62 of the hostname CMS2.
On the primary node. The same issue is displayed, CMS1 fails to find the IP addresses of the server’s name CMS2 and CMS3.
On the primary node CMS1, the database cluster status command shows that the primary node fails to connect to CMS2 and CMS3.
you need the following DNS RR Records on each CMS so that it can resolve the server’s name of each node in the cluster:
On CMS1:
dns add rr “cms2. IN A 10.1.5.62”
dns add rr “cms3. IN A 10.1.5.63”
On CMS2:
dns add rr “cms1. IN A 10.1.5.61”
dns add rr “cms2. IN A 10.1.5.63”
On CMS3:
dns add rr “cms1. IN A 10.1.5.61”
dns add rr “cms3. IN A 10.1.5.62”
The database status of all nodes are now fine:
Demystify and Simplify 