Native HA

Native HA on Linux

For a Linux implementation of Native HA, a node can be a single container (CRI-O, Docker, Podman, containerd), a Virtual Machine, or a bare-metal server that meets the current minimum system requirements for IBM MQ (see https://www.ibm.com/support/pages/system-requirements-ibm-mq-94).

All nodes must be deployed with the same processor architecture and located in the same geographical region. For the greatest levels of resiliency there should be no hardware resources shared between each node, and each node should be allocated the same amount of CPU, memory, and disk.

Each IBM MQ installation that hosts a Native HA instance must initially be using the same IBM MQ version and maintenance level and be installed in the same way, in the same locations. The minimum three packages required are:

• runtime (for example, ibmmq-runtime_9.4.4.0_amd64.deb)
• server (for example, ibmmq-server_9.4.4.0_amd64.deb)
• gskit (for example, ibmmq-gskit_9.4.4.0_amd64.deb)

The three nodes should have a consistent environment. For example, if a queue manager is configured to use a keystore in a specific location (such as SSLKEYR(‘/my/dir/keystore’), you must ensure the same file location is mounted and accessible wherever the active queue manager instance runs.

You can use default locations for installation (/opt/mqm) and data (/var/mqm), but if you change the install or data location on one node, ensure you mirror the same change across all other nodes.

Liveness – monitor and automatic restart

Native HA uses the raft consensus algorithm to ensure data integrity and consistency. The instances collectively elect the best copy of the log available to lead the group through a majority decision. The elected leader of the Native HA group becomes the active instance, accepting IBM MQ application connections.

Log updates are sent from the active instance over the network to the other replica instances and once a majority (or 'quorum') number of copies of the log acknowledge the same log write, it can at that point be confirmed back to the application that requested it. The raft algorithm ensures through requiring majority decisions in elections that future leaders must have written this log record.

Should an active Native HA instance lose the ability to form quorum, for example, if it loses network connections to both the other instances, it is then unable to progress any work that requires log writes. Under these circumstances, the active instance abdicates (ends itself).

When running in a container environment using OpenShift or Kubernetes, there are liveness probes to monitor in the state of the queue manager instances, and restart them where necessary. The liveness probes are not available in a Linux configuration. When Native HA is configured on Linux, there are different ways to run a queue manager instance as a service to provide this functionality, one example is using systemd and an example configuration is provided using systemd, see Monitoring, restarting, and ending queue manager instances.

Readiness - locating the current active instance

When connecting clients and channels to a Native HA queue manager running outside of OpenShift or Kubernetes, there must be a way to connect clients or other queue managers to the active instance. You can use a comma-separated list of three possible addresses in order the locate the currently active instance.

Log configuration and media image scheduling

Native HA handles replication of the recovery log extents for a queue manager, this enables each replica to replay data from its locally maintained replica copy of the log and rebuild the configuration and state of the queue manager.

The size of a log extent is calculated by multiplying the log page size (4KB) by the number of log file pages (defined by crtmqm -lf). The number of log file pages can be in the range 64 to 65535 and defaults to 4096, which results in 16 MB log extents. The size of a log extent is fixed at the time a queue manager instance is created and cannot be changed. The number of log file pages must be identical on all instances that form a Native HA queue manager.

The number of primary (set by crtmqm -lp) and secondary (defined by crtmqm -ls) log extents determine the size of the active log which bounds long-running transactions. The size of the active log can be changed by altering the stanza values for primary and secondary extents in the qm.ini file. Any changes to the size of the active log must be implemented consistently across all three instances.

When sizing the log and log filesystem requirements for a Native HA queue manager, you can use the same approach as used to size a queue manager with linear logs (see Calculating the size of the log).

Provided that at least 100 messaging operations have been logged (for example, persistent puts, gets, commits, or rollbacks), a Native HA queue manager records a media image for each recoverable queue manager object every 60 minutes using the default IMGINTVL setting. A Native HA queue manager also sets IMGLOGLN to 25% of the available log filesystem space at the time the queue manager is created.

The IMGLOGLN setting works as a backstop and ensures that new media images are scheduled before the log gets too full when under high messaging workload. If creating a queue manager instance with a large log filesystem that might be shared by multiple queue managers, you should review the IMGLOGLN value and alter as necessary.

Instance naming

Each instance must share the same queue manager name (together they form a single queue manager), but each instance must be given a unique name for identification purposes. When deploying Native HA in docker containers, virtual machines, or on bare-metal servers you can use the hostname as the instance name to identify the hosting location (but any three unique values would suffice, for example, athos, porthos, and aramis).

Instance names can be up to 48 characters in length. The names are case-sensitive and can include following valid characters:

• Uppercase (A-Z)
• Lowercase (a-z)
• Numerics 0-9
• Period (.)
• Forward slash (/)
• Dash (-)
• Underscore (_)
• Percent sign (%)