Cisco Acano X-series

ページ / 160
Cisco Meeting Server Release 2.0 : Scalable and Resilient Meeting Server Deployments
30
Figure 10: Multi Core & Edge server deployment
2.12.3 Database clustering
Points to note relating to a database cluster:
n
All inter-database communication between database cluster peers is handled through SSL
for security.
n
Within a database cluster, only one database is used at any time by all the Call Bridges; this is
the “master”. All reads and writes are performed on this database instance.
n
This master database’s contents are replicated to the “slaves/hot-standbys” for resilience:
this is indicated in the figures in
.
n
In case of master failure, a slave database will be "promoted" to being the new master, and
other slaves will reregister with the new master database. After the failure has been
corrected, the old master will assign itself as a slave and will also register with the new
master:
l
Loss of power to the master database results in that database reverting to being a slave
on startup.
l
Loss of all network connectivity to and from the master database results in that database
becoming a slave when connectivity is restored.
n
In cases where a network partition occurs, only databases that can see more than half of the
total number in the cluster are considered for promotion to being a master database.
Likewise, any existing master that cannot see more than half of the cluster databases will be
demoted to a slave. This ensures that multiple masters are not created, and that the contents
of the database remain consistent across the cluster.
2   General concepts for deployment