How to achieve IBM MQ with high availability configuration
High availability refers to the ability of a system or component to be operational and accessible when required for use for a specified period of time. The system or component is equipped to handle faults in an unplanned outage gracefully to continue providing the intended functionality.
Daisy chains: Bad for high availability:
Daisy-chained components represent a single point of failure as they do not allow for an alternative route in the event of a component failure. A failure of any individual component might result in an outage of the entire application infrastructure.
Active–active configuration:
To overcome this obstacle, we can employ redundant components . Network connectivity between the redundant components ensures that all components in the architecture are reachable even if one or more components fail. Redundant components can be added in an active pattern where they are actively participating in processing transactions. For push-based technologies (such as HTTP), a load balancer can distribute the traffic equally on the available components.
Active-Standby Configuration:
An active-passive deployment uses hot or cold standby components to take over in the event that the main component fails. The standby components often exchange heartbeat information with the active components at a configurable time. If a specific number of heartbeats are missed, the standby component takes over as the active component. Some hardware components can also take over the MAC addresses of the network interface card, which allows network switches and load balancers to function normally without having to change any network behaviour.
Different technologies to achieve WebSphere MQ High Avaiability
- Queue manager clusters
- Queue-sharing groups
- Multi-instance queue managers
- HA clusters
- Client reconnection
Queue manager clusters:
A queue manager cluster is a logical group of queue managers. The queue managers can be on most of the platforms supported by MQ. When queue managers are grouped in a cluster, each queue manager can make the queues(and other resources it hosts) available to every cluster member.
The queue manager cluster solution provides a highly available messaging service. It allows messages to be forwarded to any queue manager in the cluster hosting the target queue for application processing. If any queue manager in the cluster fails, new incoming messages continue to be processed by the remaining queue managers as long as at least one of the queue managers hosts an
instance of the target queue.
Sharing cluster queues on multiple queue managers prevents a queue from being a Single point of failures.Cluster workload algorithm automatically routes traffic away from failed queue managers.One of the benefits of queue manager clustering is workload balancing functionality.
Queue-sharing groups:
Shared queues are only available on WebSphere MQ for z/OS. They rely on z/OS-specific features not available on other platforms.
Multi-instance queue managers:
Two instances of a queue manager on different machines,Instances are the SAME queue manager – only one set of data files. One is the “active” instance, other is the “standby” instance.Active instance “owns” the queue manager’s files,Accepts connections from applications.Standby instance monitors the active instance,Applications cannot connect to the standby instance,If active instance fails, standby restarts queue manager and becomes active.
HA clusters:
HA clusters are groups of two or more computers an resources such as
disks and networks, connected together and configured in such a way that, if
one fails, a high availability manager, IBM PowerHA for AIX (formerly HACMP), Veritas Cluster Server,
Microsoft Cluster Server, HP Serviceguard performs
a failover. The failover transfers the state data of applications from
the failing computer to another computer in the cluster and re-initiates their operation there. This
provides high availability of services running within the HA
cluster.HA clusters can:
- Coordinate multiple resources such as application server database
- Consist of more than two machines
- Failover more than once without operator intervention
- Takeover IP address as part of failover
- Likely to be more resilient in cases of MQ and OS defects
- In HA clusters, queue manager data and logs are placed on a shared disk
- Disk is switched between machines during failover
- The queue manager has its own “service” IP address
- IP address is switched between machines during failover
- Queue manager’s IP address remains the same after failover
- The queue manager is defined to the HA cluster as a resource dependent on the shared disk and the IP address
- During failover, the HA cluster will switch the disk, take over the IP address and then start the queue manager.
Reference:
https://www.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/fa70161_.htm
Related Topic
