MQTT message broker deployment options with IBM Engineering Lifecycle Management solution

In IBM Engineering Lifecycle Management (ELM) 7.0.3, there are four primary reasons why an MQTT message broker is needed.

1. EWM or ETM clustering for user scalability
   • see Change and Configuration Management clustered environment and Quality Management clustered environment
2. Deep skew detection in global configurations of contributions from EWM SCM or RMM
   • see Finding multiple different configurations of the same component in EWM SCM and RMM contributions (Detecting deep component skew)
3. Live logging of running builds
   • see Live logging for builds
4. Building global configurations with contributions from other GCM servers (experimental)
   • see Enabling GCM servers to contribute configurations to other GCM servers

It is quite possible and highly likely that a client deployment will need a supported MQTT message broker for one or more of the reasons stated.  Note the currently supported MQTT message broker is Eclipse Amlen which only runs on CentOS and RHEL operating systems (see Provisioning your operating system).

We recommend that

• The MQTT message broker be clustered for both scalability and high availability purposes.  See Configuring the cluster membership of an Eclipse Amlen server and Configuring your system for high availability. ELM provides several JMX MBeans that reporting on aspects of the MQTT message broker used by ELM. In particular, see the MQTT service metrics MBean in Common Managed Beans.
• Each ELM instance requiring an MQTT message broker should have its own independent cluster. For example: one MQTT message broker cluster in QA and one in production where each cluster is providing EWM and ETM clustering and GC deep skew detection.
• In cases where you are deploying the experimental capability to build global configurations with contributions from other GCM servers, you are required to share the cluster between ELM instances contributing to the common global configuration.