IBM Integration Bus High Availability Overview
22 likes26,287 views
The document provides an overview of high availability (HA) topologies for IBM Integration Bus (IIB), comparing active/active and active/passive configurations. It details the failover processes, infrastructure requirements, and different options available for implementing HA, including the use of multi-instance setups or HA cluster software. Additionally, it discusses the integration of global caches and the performance implications of each configuration, emphasizing their suitability for various workloads.
IBM Integration Bus High Availability Overview
- 1. IBM Integration Bus High Availability Overview Peter Broadhurst IBM Messaging & Integration
- 2. © 2013, 2014 International Business Machines Corporation 2 Introduction These charts provide a high-level overview of IIB HA topologies: • Comparison of active/active and active/passive HA • Solutions for active/passive HA failover with IBM Integration Bus • Solutions for active/active processing with IBM Integration Bus • Adding Global Cache to active/active processing • Combining all of the above Only HTTP and JMS (MQ) workloads are shown
- 3. © 2013, 2014 International Business Machines Corporation 3 Active/active vs. active/passive Scale High Availability Design Considerations Active/Active All N instances contribute to the processing capacity of the system New requests can be serviced immediately after the planned or unplanned termination of an active instance. Often referred to as continuous availability. Each instance must be able to operate independently, without relying on the availability of any other instance in the environment. The order of processing for two items of work cannot be guaranteed, as there are multiple instances that might perform each item of work Active/Passive Only one of N instances contributes to the processing capacity of the system There is a failover period after the planned or unplanned termination of an active instance. This failover period commonly lasts for a small number of minutes, depending on the technology used. An infrastructure for HA failover must exist, that ensures only one instance is ever activated, as well as detecting when one instance fails to initiate the failover. The active and the passive system must have identical copies of persistent data, such as persisted transaction state, and persisted messages. In IBM Integration Bus this is achieved by sharing a filesystem between the two machines.
- 4. © 2013, 2014 International Business Machines Corporation 4 Active/passive high availability Machine 1 Machine 2 IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server Shared file system HA failover • Single instance of the IIB runtime • Single instance of all state – Configuration, MQ messages and Transaction coordinator • Highly available due to automatic fail-over. Two options available for HA failover: – Out-of-the-box with Multi-Instance capability, – Or using external HA cluster software JMS workloads HTTP workloads
- 5. © 2013, 2014 International Business Machines Corporation 5 Option 1: Out of the box Multi-Instance failover • IP address of each machine is different – IP address redirect is required for HTTP workloads – MQ client libraries automatically handle IP redirect for JMS workloads • Requires highly available network-attached storage (NAS). Examples: – IBM GPFS – Veritas Cluster File System – Highly available NFSv4 • More information on choosing a suitable NAS: – https://ibm.biz/BdFxfz Machine 1 – IP addr 1 Machine 2 – IP addr 2 IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server Network- attached file system (NAS) TCP/ IP Failover managed via NAS file locks IP redirect (Gateway / Load Balancer) JMS workloads TCP/ IP
- 6. © 2013, 2014 International Business Machines Corporation 6 Option 2: HA cluster failover • Allows use of direct-attached storage • IP address failed over by HA cluster software • Requires HA cluster software. Examples: – IBM PowerHA (HACMP) – Veritas Cluster Server (VCS) – Microsoft Cluster Service (MSCS) – Red Hat Cluster Machine 1 – IP addr 1 Machine 2 – IP addr 1 IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server Direct-attached file system switched by HA Failover managed via health checking Fibre/SCSI HA cluster Software HA cluster Software Heartbeat Healthcheck Healthcheck JMS workloads HTTP workloads Fibre/SCSI IP addr failover
- 7. © 2013, 2014 International Business Machines Corporation 7 Multi-instance or HA cluster? Multi-instance queue manager • Integrated into the IIB and MQ products • Faster failover than HA cluster* • Delay before queue manager restart is much shorter* • Runtime performance of networked storage must be considered • IP address of standby instance is different to primary • No automatic fail-back to primary hardware when restored • More susceptible to MQ and OS defects HA cluster • Capable of handling a wider range of failures • Failover historically rather slow, but some HA clusters are improving • Some customers frustrated by unnecessary failovers • Require MC91 SupportPac or equivalent configuration • Extra product purchase and skills required Storage distinction • Multi-instance queue manager typically uses NAS • HA clustered queue manager typically uses SAN *depends on NAS file-system tuning and specific customer environment
- 8. © 2013, 2014 International Business Machines Corporation 8 Active/active topologies Machine 1 Machine 2 IIB Integration Node MQ Messaging IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server WESB AppTargetWESB AppTargetIntegration Server Gateway / Load Balancer for HTTP workloads HTTP workloads JMS workloads • Each Integration Node operates independently • Continuous availability of the service during a failure – Individual in-flight requests on the failed node receive errors, but the service stays available • HTTP workloads require external workload balancing – Hardware load balancer is the most common solution • JMS workloads require load balancing – Via an MQ cluster when remote applications have their own MQ queue managers – Options for direct MQ client attachment (over TCP/IP) described here: https://ibm.biz/BdFxfS
- 9. © 2013, 2014 International Business Machines Corporation 9 Adding Global Cache to active/active topologies Machine 1 Machine 2 IIB Integration Node MQ Messaging Global Cache IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server WESB AppTargetWESB AppTargetIntegration Server • Highly available in-memory state store – High performance compared to disk persistence (DB/MQ Messaging) – High availability through redundancy – cannot be recovered if all nodes are stopped concurrently – Built with WebSphere eXtreme Scale technology • Alternative to using MQ or a Database for state storage/retrieval – Correlation state between asynchronous request/reply flows • Only needed if replies might be routed via a different runtime, otherwise simply use memory (LocalEnvironment etc.) – Regularly accessed reference data, such as routing tables
- 10. © 2013, 2014 International Business Machines Corporation 10 Global Cache Putting it all together • Active/active processing. HA fail-over for state and in-flight message recovery • Individual queues/flows can be configured active/passive if required – Single flow instance for message ordering or file-based processing – Single correlation state queue shared between active flow instances Machine 1 Machine 2 IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server IIB Integration Node MQ Messaging WESB AppTargetWESB AppTargetIntegration Server Shared Filesystem Failover Failover Gateway / Load Balancer for HTTP workloads JMS workloads HTTP workloads
- 11. © 2013, 2014 International Business Machines Corporation 11 More information • Knowledge Center starting points: IIB Active/passive HA: https://ibm.biz/BdFxfe IIB Active/active HA for HTTP: https://ibm.biz/BdFxfb IIB Global cache: https://ibm.biz/BdFxfp MQ HA Cluster configurations: https://ibm.biz/BdFxf8 • Wiki article with detailed description of IIB topology choices Tailored to customers migrating from WebSphere WESB, but useful to all https://ibm.biz/BdFxfa • MQDev blog on attaching MQ clients to active/active qmgrs: https://ibm.biz/BdFxfS • Testing and support statement for multi-instance https://ibm.biz/BdFxfz