Specifications

MBG Engineering Guidelines, Release 8.0
10 Clustering
10.1 Overview
Clustering in this context refers to the ability of multiple MBG servers to communicate with one another via TCP,
sharing data and providing the capability to manage multiple nodes thus joined as if they were a single unit.
Clustering also provides load balancing for supported MiNet devices, making the job of distributing devices
across servers to share workload simple and effective. Set resiliency is also used within clustering, so that
supported MiNet sets which can persistently store up to four IP addresses will have their resiliency list populated
based on the cluster members.
Clustering relies on a mesh of TCP connections between the nodes in the cluster. TCP port 6809 must be
reachable between all nodes for cluster comms to be established. SSL/TLS is used to encrypt communications,
so it is safe to use over the Internet.
Administrative access to each server in the cluster is required to establish a trust relationship between the
nodes. The trust model is based on the IP addresses used to establish cluster comms. Each node is configured
via the clustering tab to trust a connection coming in from a particular IP address. These addresses are shared
across the cluster, so they must be reachable by all nodes involved, and any use of NAT will break the trust
model. A summary of the steps to create a three-node cluster are shown below. Refer to the Mitel Border
Gateway Blade Installation and Maintenance Guide for full instructions on creating a cluster.
• Create the cluster from the master node, entering the IP address of the first slave node.
• Join the cluster from the first slave node, entering the IP address of the master node.
• Assuming no networking issues, the clustering tab will show established connections, and the slave
node will show a backlog of events from the master (or it will finish too quickly to be seen).
• Add a node on the master, entering the IP address of the second slave node
• At this time, the first slave will receive the same data regarding the second slave via cluster comms.
• Join the cluster on the second slave, entering the IP address of the master node.
• Assuming no networking issues, the clustering tab on all nodes should show the peer nodes for that
node.
• The three node cluster is now established.
Once cluster communications are established, the master node will “push” data to the slaves until they are in
sync with the master. Conflicting data is overwritten. Data that the master node does not have a copy of is not
modified, and is not pushed to the master. Merging data is accomplished by taking ownership from each slave
node (i.e. making that node the master) in turn, causing the new master to push its data to all other nodes, until
all data is in sync across the cluster. Unwanted records can then be deleted from the master node.
10.2 Cluster Zones
A cluster zone is a non-overlapping subset of nodes within an existing cluster. All nodes start out in the “Default”
zone. The “Default” zone can be renamed but it cannot be deleted. It is easily identified because it appears first
in the zone list, and has no “delete” link. Nodes can be left in the default zone if additional zoning is not required.
Additional zones can be created, and nodes can be moved to any zone. Zones can be created based on
geographic location, the intended purpose for the nodes, or whatever reason the admin chooses. The purpose of
zones is to provide device affinity.
33