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).

IBM recommends 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.

IBM recommends that ELM instances requiring an MQTT message broker for clustering or deep skew detection have their own independent cluster (vs shared with other ELM instances).

IBM recommends that production, test, development, etc. environments have their own independent MQTT message broker clusters.

IBM requires that a MQTT message broker cluster be shared between ELM instances that are implementing the experimental capability allowing contributing to a common global configuration.