Cluster overview

As of this release, all instances of BMC Discovery are referred to as machines. In previous releases, the term appliance was used to refer to a BMC Discovery instance.

Clusters

A group of coordinated BMC Discovery machines is called a cluster. A cluster consists of two or more BMC Discovery machines, one of which is in control of the group and is referred to as the coordinator.

All machines are capable of acting as:

• A standalone BMC Discovery machine
• A member of a cluster
• A cluster coordinator

A cluster is not removed; it stops being a cluster when the last member is removed from the coordinator.

What is a cluster for?

Clusters are designed for organizations with very large IT infrastructures, where the performance required is greater than that of a single BMC Discovery machine. The problem and the solution are described in Big Discovery.

Cluster recommendations

The individual machines that make up a cluster are intended to be in the same location. The data in the datastore is distributed across all machines so there is significant traffic between cluster members. Putting the cluster machines into different locations increases the communication overhead and slows cluster operations. Clustering is designed with the intention that machines are located on the same fast LAN.

Clusters should be built from machines of similar specifications and performance.The datastore is distributed over multiple machines, with each machine holding a roughly equal share of the stored data. The total capacity of the distributed datastore is therefore limited by the machine with the lowest disk capacity allocated to the datastore. The performance of the cluster is affected by the lowest performing machine, but as the discovery workload is shared, the impact is not a limit, but a reduction in overall performance.

All machines in the cluster must be of exactly the same major and minor version, for example version 11.1.0. Generally, the patch levels may differ to aid deployment. For example, an 11.2 patch n machine may be added to an existing cluster of 11.2 patch m machines. If for any reason, this is not possible in a particular patch release, it will be noted here and in the release notes. 

BMC recommend that all cluster members be upgraded to match the highest versioned member of the cluster.

11.3 patch 6 on Red Hat Enterprise Linux

The 11.3 patch 6 is available running on Red Hat Enterprise Linux 7 (RHEL 7). You cannot have a cluster containing RHEL and CentOS based appliances.

Naming of machines in a cluster

The individual machines in a cluster are named according the the following scheme:

• Coordinator—clustername-01
• First member added—clustername-02
• Next member added—clustername-03
• And so on

Cluster communications

Clustered machines communicate on the following TCP ports:

• 25030—Cluster management
• 25031—Datastore communication
• 25032—Reasoning communication

For more information, see Firewall port summary.

Clusters and JDBC drivers

In a cluster, JDBC drivers for querying databases using integration points that are uploaded through the Administration > JDBC Drivers page are synchronized across the cluster automatically. Where you create a new driver, the driver JAR and properties files must be copied manually. You must restart the tideway services on all machines in the cluster before using the drivers.

When replacing a JDBC driver with a newer version through the Administration > JDBC Drivers page on the coordinator UI, the changes are synchronized across the cluster, but you must also restart the tideway services on all machines in the cluster.