SlideShare a Scribd company logo
© 2014 IBM Corporation
Building a Scalable &
Continuously Available
IBM MQ Infrastructure
AMC-1882
Please Note
IBM’s statements regarding its plans, directions, and intent are subject to change
or withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general
product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a
commitment, promise, or legal obligation to deliver any material, code or
functionality. Information about potential future products may not be incorporated
into any contract. The development, release, and timing of any future features or
functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance
that any user will experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in the user’s job stream,
the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results
similar to those stated here.
Introduction
Article series describing one possible MQ topology as a pattern
• ibm.co/1cz0MrL
Why?
• Make it easier to include MQ in a project
• Help meet ‘five nines’ or ‘continuous’ availability via a standard approach
• Help MQ admin teams do more with less through consistency
• Provide config and code samples to get started quickly in a DevOps culture
The approach is client/server, why?
• Applications increasing have a large number of instances
• Application instances come and go
• MQ should be seen as critical infrastructure, similar to a Database
• Provisioning and scaling MQ separately from the app gives flexibility
How many ‘hubs’ of MQ could you have?
• In general continue to provision MQ on a per-project basis – just like a DB
• Some sharing/multi-tenancy is likely based on risk assessment – just like a DB
MQ Cluster
Workload Balancing
MQ Cluster
Workload Balancing
Overview – architecture view
Every sender/requester uses two connections
Every receiver/service has two listeners
Make each Queue Manager HA to recover persistent messages
Simple to interoperate with co-located Queue Managers
Simple to interoperate with z/OS Queue Sharing Groups
Pattern discussed in detail here: http://ow.ly/vrUUV
App1 QM1App1 QM1
App1
QM2
App1
QM2
App2 QM1App2 QM1
Shared QM1Shared QM1
Shared QM2Shared QM2
App1 Inst1App1 Inst1
App1 Inst2App1 Inst2
App1 Inst3App1 Inst3
App1 Inst4App1 Inst4
App2 Inst1App2 Inst1
App2 Inst2App2 Inst2
App2 Inst3App2 Inst3
App2 Inst4App2 Inst4
App2 QM2App2 QM2
App2 QM3App2 QM3
App2 QM4App2 QM4
App1 Inst1App1 Inst1
App1 Inst2App1 Inst2
App1 Inst3App1 Inst3
App1 Inst4App1 Inst4
App2 Inst1App2 Inst1
App2 Inst2App2 Inst2
Overview – infrastructure view
Principal design philosophy is active/active
• Continuous availability of the service
Minimum number of queue managers is 2
• Sending and receiving gateway roles can be fulfilled by the same qmgr
HA failover is optional
• If you have persistent messages that you need to recover quickly after a failure
MQ1
Standby
MQ2
Standby
Machine 1 Machine 2
HA failover
HA failover
MQ2
(Sending &
Receiving GW)
MQ1
(Sending &
Receiving GW)
Highly available
network-attached
file-system
MQ Hub
Senders Receivers
Overview – 2 is the magic number
Every sender sends to two queue managers
• No single point of failure for sending messages
• Not too many places to look for messages
Every receiver listens to two queue managers concurrently
• Every queue manager has two app instances listening for messages
• Every app instance listens to two queue managers
• Note: cannot have more receiving gateways than receiving app instances
No single point of failure
• Any single component can fail, and all other components continue processing
MQCluster
Receiver 1
Receiver 2
Receiver 3
Receiver 4
Sender 1
Sender 2
Sender 3
Sender 4
Sender 5
Sender 6
Sender 7
Sender 8
MQ
Gateway 1
MQ
Gateway 2
MQ
Gateway 3
MQ
Gateway 4
MQ
Gateway 5
MQ
Gateway 1
MQ
Gateway 2
MQ
Gateway 3
MQ
Gateway 4
MQ
Gateway 5
Sending messages
Each app instance sends to two different queue managers
Need a workload management strategy
• Prioritised
• Random
• Round robin – my personal preference
Biggest practical concern for customers:
How do I create/change my app code to connect
to two different remote queue managers
Sending
application
Connection
logic
(CCDT or
custom)
Sending
Gateway 1
Sending
Gateway 2
MQ connection 1
MQ connection 2
MQCluster
Sending messages – choices for multi-QM client attachment
CONNAME list CCDT (multi-QMGR) Load balancer Code stub
Scale of code change
required for existing
apps that connect to a
single QM
+ive
MQCONN("QMNAME") to MQCONN("*QMNAME")
QMName might be in JNDI config for Java EE apps.
Otherwise requires a one character code-change.
-ive
Replace existing JMS/MQI
connection logic with code
stub.
Support for different
WLM strategies
-ive
Prioritized only
=
Prioritized + Random
+ive
Any, including per-
connect round-robin
+ive
Any, including per-
message round-robin.
Performance
overhead while
primary QM is down
-ive
Always tries first in
list
+ive
Remembers last good
+ive
Port monitoring
avoids bad QMs
+ive
Can remember last good,
and retry intelligently
XA Transaction
Support
-ive
The transaction manager needs to store recovery information that
reconnects to the same QM resource. An MQCONN that resolves to
different QMs generally invalidates this. e.g. in Java EE, a single
Connection Factory should resolve to a single QM when using XA.
+ive
Code stub can meet the
XA transaction manager’s
requirements. e.g.
multiple Connection
Factories.
Connection
rebalancing on
failback.
e.g. when a QM
restarts after a failure
or planned outage,
how long till apps
use it again
-ive
Connection pooling in Java EE will hold onto connections indefinitely,
unless connections are configured with an aged timeout. Using an aged
timeout might drive exceptions in some cases. An aged timeout also
introduces a performance overhead during normal operation.
Conversation sharing might need to be disabled (SHARCNV=1) with an
aged timeout to ensure reconnects always establish a new socket.
The ‘remembers last good’ CCDT behaviour might also delay failback.
+ive
Code stub can handle
failback flexibly, with
little/no performance
overhead.
Admin flexibility to
hide infrastructure
changes from apps
-ive
DNS only
=
DNS and/or shared file-
system / CCDT file push
+ive
Dynamic Virtual IP
address (VIP)
=
DNS or single-QMGR
CCDT entries
More detail on MQDev here: http://ibm.co/MM8rMl
Receiving messages
The application needs two active listeners
• Random/prioritised attachment can lead to stranded messages
• AMQSCLM is an alternative - discussed in AMC-1883
For Java EE this means two MDB endpoints
• EJB 2.1 style deployment descriptors
– Add a second endpoint to the XML
• EJB 3.0 style annotations
– Create a code hierarchy
EJB 2.1 & 3.0 samples on github:
https://github.com/ibm-messaging/mq-wlm-client
Receiving
application
Active
Active
MQ Listener 1
MQ Listener 2
MQCluster
Receiving
Gateway 1
Receiving
Gateway 2
Synchronous request/response
Response 1
Requester
application
Connection
logic
(CCDT or
custom)
MQ 1
MQ 2
MQ connection 1
MQ connection 2
MQCluster
Request 1
Response 2
Request 2
Use same MQ connection to receive the response
• e.g. the same JMS Session
MQ fills in the MQMD.ReplyToQMgr on send
• Back-end app must honour this when sending the response
Synchronous request/response – advanced case
A clustered reply queue for synchronous request/response
• Lets replies take a different route back from requests
• Only adds resilience for highly parallel nonpersistent request/reply, where requests
build up on back-end threads in business logic rather than in MQ
Requires correlation logic to pass responses back to waiting threads
This is not the same as two-way asynchronous messaging
Code samples: https://github.com/ibm-messaging/mq-wlm-client
Asynchronous
Receiver
Two-way asynchronous messaging
The optimal use of messaging is fully asynchronous
Requests are sent “fire & forget”, as are responses
• Critical requests are sent as persistent within a transaction that updates a DB
• Transactional state update + persistent send = exactly once delivery
Responses are handled by any app instance at any time
• No thread is left ‘hung’ in the requesting application
• If responses need to be correlated with requests, then a state store is used
– A Database – DB2 etc.
– An elastic cache – WebSphere eXtreme Scale
Must be designed into the application
• Can revolutionize responsiveness
• Truly decouples applications
Receiving
application
Active
Active
MQ Listener 1
MQ Listener 2
MQCluster
Receiving
Gateway 1
Receiving
Gateway 2
Fire &
Forget
Requester
CCDT
or custom
Sending
Gateway 1
Sending
Gateway 2
MQ connection 1
MQ connection 2
MQ Listener 1
MQ Listener 2
50% requests
50% requests
50% responses
50% responses
Publish/subscribe messaging
MQ gives the same QoS for pub/sub as for P2P
• Fan out messages one-to-many
• WLM across multiple subscriber instances
Achieved by bridging durable subscriptions to cluster queues
• Define subscriptions on queue managers where publishers
connect
Sub1 Inst1
Sub1 Inst2Pub Inst1
Pub Inst2
QM1
QM2
QM3
QM4
Pub/SubFan-Out
+MQClusterWLM
Sub2 Inst1
Sub2 Inst2
QM3
QM4
Limitations for message ordering
No active/active solution is provided here for ordered messages
• MQ only assures order when there is one path from
producing thread to consuming thread
The simplest solution, and as far as this presentation goes
• Allocate individual queue managers with HA Failover for ordered messages
MQ
Gateway 1
MQ
Gateway 2
MQ
Gateway 1
MQ
Gateway 2
MQ
Gateway N1
MQ
Gateway N2
MQ
Gateway N1
MQ
Gateway N2
Receiver 1
Receiver 2
Receiver 3
Receiver 4
Receiver N1
Receiver N2
Receiver N3
Receiver N4
Sender 1
Sender 2
Sender 3
Sender 4
Sender N1
Sender N2
Sender N3
Sender N4
MQClusterWorkloadManagement
..
.
..
.
..
.
..
.
Sender
Sending
gateway
Receiving
gateway
Receiver
Can be the same queue manager.
Might be in different hubs.
Including IBM Integration Bus
The architecture fits IBM Integration Bus
• Option 1: Add it as a separate tier
• Option 2: Compress everything into a single active/active IIB tier
For more on IIB architectures, try the following link (plug):
ibm.co/1a2Y2os
MQ
GW1
MQ
GW2
Receiver 1
Receiver 2
Receiver 3
Receiver 4
Sender 1
Sender 2
Sender 3
Sender 4
Sender
Sending
gateway
Receiving
gateway
Receiver
MQ
GW1
MQ
GW2
Integration
Node 1
Integration
Node 2
Routing
& filtering
MQCluster
MQCluster
Can be same the queue manager
Questions?
We Value Your Feedback
Don’t forget to submit your Impact session and speaker
feedback! Your feedback is very important to us – we use it to
continually improve the conference.
Use the Conference Mobile App or the online Agenda Builder to
quickly submit your survey
• Navigate to “Surveys” to see a view of surveys for sessions
you’ve attended
17
Thank You
Legal Disclaimer
• © IBM Corporation 2014. All Rights Reserved.
• The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained
in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are
subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing
contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and
conditions of the applicable license agreement governing the use of IBM software.
• References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or
capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to
future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you
will result in any specific sales, revenue growth or other results.
• If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete:
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will
experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
• If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete:
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs
and performance characteristics may vary by customer.
• Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM
Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server).
Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your
presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in
your presentation. IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International
Business Machines Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both.
• If you reference Adobe® in the text, please mark the first use and include the following; otherwise delete:
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
• If you reference Java™ in the text, please mark the first use and include the following; otherwise delete:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
• If you reference Microsoft® and/or Windows® in the text, please mark the first use and include the following, as applicable; otherwise delete:
Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.
• If you reference Intel® and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete:
Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and
other countries.
• If you reference UNIX® in the text, please mark the first use and include the following; otherwise delete:
UNIX is a registered trademark of The Open Group in the United States and other countries.
• If you reference Linux® in your presentation, please mark the first use and include the following; otherwise delete:
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of
others.
• If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta
Bank, Acme) please update and insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration
purposes only.

More Related Content

What's hot (20)

PPT
IBM Integration Bus & WebSphere MQ - High Availability & Disaster Recovery
Rob Convery
 
PDF
IBM Integration Bus High Availability Overview
Peter Broadhurst
 
PDF
Expanding your options with the MQ Appliance
Anthony Beardsmore
 
PPTX
Understanding mq deployment choices and use cases
Leif Davidsen
 
PPT
IBM WebSphere MQ: Managing Workloads, Scaling and Availability with MQ Clusters
David Ware
 
PPTX
Hhm 3474 mq messaging technologies and support for high availability and acti...
Pete Siddall
 
PDF
IBM MQ - better application performance
MarkTaylorIBM
 
PDF
InterConnect 2016: What's new in IBM MQ
David Ware
 
PPTX
Hhm 3479 mq clustering and shared queues for high availability
Pete Siddall
 
ODP
IBM MQ v8 and JMS 2.0
Matthew White
 
PDF
MQ Appliance - Intro and 8.0.0.5 updates
Anthony Beardsmore
 
PDF
IBM MQ - Monitoring and Managing Hybrid Messaging Environments
MarkTaylorIBM
 
PPT
Expanding your options with the IBM MQ Appliance - IBM InterConnect 2016
Leif Davidsen
 
PDF
HHM-3540: The IBM MQ Light API: From Developer Laptop to Enterprise Data Cen...
Matt Leming
 
PDF
IBM MQ Appliance - Administration simplified
Anthony Beardsmore
 
PPTX
Ame 4166 ibm mq appliance
Andrew Schofield
 
PDF
IBM MQ High Availabillity and Disaster Recovery (2017 version)
MarkTaylorIBM
 
PDF
MQ Security Overview
MarkTaylorIBM
 
PDF
InterConnect 2016: IBM MQ self-service and as-a-service
David Ware
 
PPTX
3429 How to transform your messaging environment to a secure messaging envi...
Robert Parker
 
IBM Integration Bus & WebSphere MQ - High Availability & Disaster Recovery
Rob Convery
 
IBM Integration Bus High Availability Overview
Peter Broadhurst
 
Expanding your options with the MQ Appliance
Anthony Beardsmore
 
Understanding mq deployment choices and use cases
Leif Davidsen
 
IBM WebSphere MQ: Managing Workloads, Scaling and Availability with MQ Clusters
David Ware
 
Hhm 3474 mq messaging technologies and support for high availability and acti...
Pete Siddall
 
IBM MQ - better application performance
MarkTaylorIBM
 
InterConnect 2016: What's new in IBM MQ
David Ware
 
Hhm 3479 mq clustering and shared queues for high availability
Pete Siddall
 
IBM MQ v8 and JMS 2.0
Matthew White
 
MQ Appliance - Intro and 8.0.0.5 updates
Anthony Beardsmore
 
IBM MQ - Monitoring and Managing Hybrid Messaging Environments
MarkTaylorIBM
 
Expanding your options with the IBM MQ Appliance - IBM InterConnect 2016
Leif Davidsen
 
HHM-3540: The IBM MQ Light API: From Developer Laptop to Enterprise Data Cen...
Matt Leming
 
IBM MQ Appliance - Administration simplified
Anthony Beardsmore
 
Ame 4166 ibm mq appliance
Andrew Schofield
 
IBM MQ High Availabillity and Disaster Recovery (2017 version)
MarkTaylorIBM
 
MQ Security Overview
MarkTaylorIBM
 
InterConnect 2016: IBM MQ self-service and as-a-service
David Ware
 
3429 How to transform your messaging environment to a secure messaging envi...
Robert Parker
 

Similar to IBM IMPACT 2014 - AMC-1882 Building a Scalable & Continuously Available IBM MQ Infrastructure (20)

PDF
Designing IBM MQ deployments for the cloud generation
David Ware
 
PDF
IBM MQ: Managing Workloads, Scaling and Availability with MQ Clusters
David Ware
 
PDF
Fault tolerant and scalable ibm mq
David Ware
 
PDF
IBM MQ High Availability 2019
David Ware
 
PDF
IBM MQ Basics
subbareddyalamur
 
PPTX
IBM Web Shpere MQ ppt
Parth Shah
 
PPT
WebSphere MQ introduction
MikhailVladimirov
 
PDF
An Introduction to the Message Queuing Technology & IBM WebSphere MQ
Ravi Yogesh
 
PDF
WebSphere MQ tutorial
Joseph's WebSphere Library
 
PDF
Websphere MQ admin guide
Ram Babu
 
PDF
IBM MQ - Comparing Distributed and z/OS platforms
MarkTaylorIBM
 
PDF
IBM MQ Clustering (2017 version)
MarkTaylorIBM
 
PDF
IBM MQ - Comparing Distributed and z/OS platforms
MarkTaylorIBM
 
PDF
On MQ Series & JMS
Ashokkumar T A
 
PPTX
IBM MQ Series For ZOS
Srinimf-Slides
 
PPTX
Message Queue (MQ) Testing
Ujjwal Gupta
 
PPTX
Message Queue (MQ) Testing
Ujjwal Gupta
 
PPS
Mq Talk
rgayss
 
PDF
AME-1934 : Enable Active-Active Messaging Technology to Extend Workload Balan...
wangbo626
 
PPT
IBM WebSphere MQ Introduction
ejlp12
 
Designing IBM MQ deployments for the cloud generation
David Ware
 
IBM MQ: Managing Workloads, Scaling and Availability with MQ Clusters
David Ware
 
Fault tolerant and scalable ibm mq
David Ware
 
IBM MQ High Availability 2019
David Ware
 
IBM MQ Basics
subbareddyalamur
 
IBM Web Shpere MQ ppt
Parth Shah
 
WebSphere MQ introduction
MikhailVladimirov
 
An Introduction to the Message Queuing Technology & IBM WebSphere MQ
Ravi Yogesh
 
WebSphere MQ tutorial
Joseph's WebSphere Library
 
Websphere MQ admin guide
Ram Babu
 
IBM MQ - Comparing Distributed and z/OS platforms
MarkTaylorIBM
 
IBM MQ Clustering (2017 version)
MarkTaylorIBM
 
IBM MQ - Comparing Distributed and z/OS platforms
MarkTaylorIBM
 
On MQ Series & JMS
Ashokkumar T A
 
IBM MQ Series For ZOS
Srinimf-Slides
 
Message Queue (MQ) Testing
Ujjwal Gupta
 
Message Queue (MQ) Testing
Ujjwal Gupta
 
Mq Talk
rgayss
 
AME-1934 : Enable Active-Active Messaging Technology to Extend Workload Balan...
wangbo626
 
IBM WebSphere MQ Introduction
ejlp12
 
Ad

Recently uploaded (20)

PDF
Achieving Consistent and Reliable AI Code Generation - Medusa AI
medusaaico
 
PDF
HubSpot Main Hub: A Unified Growth Platform
Jaswinder Singh
 
PDF
IoT-Powered Industrial Transformation – Smart Manufacturing to Connected Heal...
Rejig Digital
 
PDF
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
PDF
Smart Trailers 2025 Update with History and Overview
Paul Menig
 
PPTX
Q2 FY26 Tableau User Group Leader Quarterly Call
lward7
 
PDF
New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
PDF
CIFDAQ Market Insights for July 7th 2025
CIFDAQ
 
PDF
LLMs.txt: Easily Control How AI Crawls Your Site
Keploy
 
PDF
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
PDF
Empower Inclusion Through Accessible Java Applications
Ana-Maria Mihalceanu
 
PPTX
Webinar: Introduction to LF Energy EVerest
DanBrown980551
 
PDF
Transcript: New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
PDF
Newgen Beyond Frankenstein_Build vs Buy_Digital_version.pdf
darshakparmar
 
PDF
What Makes Contify’s News API Stand Out: Key Features at a Glance
Contify
 
PDF
The Rise of AI and IoT in Mobile App Tech.pdf
IMG Global Infotech
 
PDF
Mastering Financial Management in Direct Selling
Epixel MLM Software
 
PDF
Blockchain Transactions Explained For Everyone
CIFDAQ
 
PDF
"Beyond English: Navigating the Challenges of Building a Ukrainian-language R...
Fwdays
 
PDF
CIFDAQ Token Spotlight for 9th July 2025
CIFDAQ
 
Achieving Consistent and Reliable AI Code Generation - Medusa AI
medusaaico
 
HubSpot Main Hub: A Unified Growth Platform
Jaswinder Singh
 
IoT-Powered Industrial Transformation – Smart Manufacturing to Connected Heal...
Rejig Digital
 
Building Real-Time Digital Twins with IBM Maximo & ArcGIS Indoors
Safe Software
 
Smart Trailers 2025 Update with History and Overview
Paul Menig
 
Q2 FY26 Tableau User Group Leader Quarterly Call
lward7
 
New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
CIFDAQ Market Insights for July 7th 2025
CIFDAQ
 
LLMs.txt: Easily Control How AI Crawls Your Site
Keploy
 
HCIP-Data Center Facility Deployment V2.0 Training Material (Without Remarks ...
mcastillo49
 
Empower Inclusion Through Accessible Java Applications
Ana-Maria Mihalceanu
 
Webinar: Introduction to LF Energy EVerest
DanBrown980551
 
Transcript: New from BookNet Canada for 2025: BNC BiblioShare - Tech Forum 2025
BookNet Canada
 
Newgen Beyond Frankenstein_Build vs Buy_Digital_version.pdf
darshakparmar
 
What Makes Contify’s News API Stand Out: Key Features at a Glance
Contify
 
The Rise of AI and IoT in Mobile App Tech.pdf
IMG Global Infotech
 
Mastering Financial Management in Direct Selling
Epixel MLM Software
 
Blockchain Transactions Explained For Everyone
CIFDAQ
 
"Beyond English: Navigating the Challenges of Building a Ukrainian-language R...
Fwdays
 
CIFDAQ Token Spotlight for 9th July 2025
CIFDAQ
 
Ad

IBM IMPACT 2014 - AMC-1882 Building a Scalable & Continuously Available IBM MQ Infrastructure

  • 1. © 2014 IBM Corporation Building a Scalable & Continuously Available IBM MQ Infrastructure AMC-1882
  • 2. Please Note IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
  • 3. Introduction Article series describing one possible MQ topology as a pattern • ibm.co/1cz0MrL Why? • Make it easier to include MQ in a project • Help meet ‘five nines’ or ‘continuous’ availability via a standard approach • Help MQ admin teams do more with less through consistency • Provide config and code samples to get started quickly in a DevOps culture The approach is client/server, why? • Applications increasing have a large number of instances • Application instances come and go • MQ should be seen as critical infrastructure, similar to a Database • Provisioning and scaling MQ separately from the app gives flexibility How many ‘hubs’ of MQ could you have? • In general continue to provision MQ on a per-project basis – just like a DB • Some sharing/multi-tenancy is likely based on risk assessment – just like a DB
  • 4. MQ Cluster Workload Balancing MQ Cluster Workload Balancing Overview – architecture view Every sender/requester uses two connections Every receiver/service has two listeners Make each Queue Manager HA to recover persistent messages Simple to interoperate with co-located Queue Managers Simple to interoperate with z/OS Queue Sharing Groups Pattern discussed in detail here: http://ow.ly/vrUUV App1 QM1App1 QM1 App1 QM2 App1 QM2 App2 QM1App2 QM1 Shared QM1Shared QM1 Shared QM2Shared QM2 App1 Inst1App1 Inst1 App1 Inst2App1 Inst2 App1 Inst3App1 Inst3 App1 Inst4App1 Inst4 App2 Inst1App2 Inst1 App2 Inst2App2 Inst2 App2 Inst3App2 Inst3 App2 Inst4App2 Inst4 App2 QM2App2 QM2 App2 QM3App2 QM3 App2 QM4App2 QM4 App1 Inst1App1 Inst1 App1 Inst2App1 Inst2 App1 Inst3App1 Inst3 App1 Inst4App1 Inst4 App2 Inst1App2 Inst1 App2 Inst2App2 Inst2
  • 5. Overview – infrastructure view Principal design philosophy is active/active • Continuous availability of the service Minimum number of queue managers is 2 • Sending and receiving gateway roles can be fulfilled by the same qmgr HA failover is optional • If you have persistent messages that you need to recover quickly after a failure MQ1 Standby MQ2 Standby Machine 1 Machine 2 HA failover HA failover MQ2 (Sending & Receiving GW) MQ1 (Sending & Receiving GW) Highly available network-attached file-system MQ Hub Senders Receivers
  • 6. Overview – 2 is the magic number Every sender sends to two queue managers • No single point of failure for sending messages • Not too many places to look for messages Every receiver listens to two queue managers concurrently • Every queue manager has two app instances listening for messages • Every app instance listens to two queue managers • Note: cannot have more receiving gateways than receiving app instances No single point of failure • Any single component can fail, and all other components continue processing MQCluster Receiver 1 Receiver 2 Receiver 3 Receiver 4 Sender 1 Sender 2 Sender 3 Sender 4 Sender 5 Sender 6 Sender 7 Sender 8 MQ Gateway 1 MQ Gateway 2 MQ Gateway 3 MQ Gateway 4 MQ Gateway 5 MQ Gateway 1 MQ Gateway 2 MQ Gateway 3 MQ Gateway 4 MQ Gateway 5
  • 7. Sending messages Each app instance sends to two different queue managers Need a workload management strategy • Prioritised • Random • Round robin – my personal preference Biggest practical concern for customers: How do I create/change my app code to connect to two different remote queue managers Sending application Connection logic (CCDT or custom) Sending Gateway 1 Sending Gateway 2 MQ connection 1 MQ connection 2 MQCluster
  • 8. Sending messages – choices for multi-QM client attachment CONNAME list CCDT (multi-QMGR) Load balancer Code stub Scale of code change required for existing apps that connect to a single QM +ive MQCONN("QMNAME") to MQCONN("*QMNAME") QMName might be in JNDI config for Java EE apps. Otherwise requires a one character code-change. -ive Replace existing JMS/MQI connection logic with code stub. Support for different WLM strategies -ive Prioritized only = Prioritized + Random +ive Any, including per- connect round-robin +ive Any, including per- message round-robin. Performance overhead while primary QM is down -ive Always tries first in list +ive Remembers last good +ive Port monitoring avoids bad QMs +ive Can remember last good, and retry intelligently XA Transaction Support -ive The transaction manager needs to store recovery information that reconnects to the same QM resource. An MQCONN that resolves to different QMs generally invalidates this. e.g. in Java EE, a single Connection Factory should resolve to a single QM when using XA. +ive Code stub can meet the XA transaction manager’s requirements. e.g. multiple Connection Factories. Connection rebalancing on failback. e.g. when a QM restarts after a failure or planned outage, how long till apps use it again -ive Connection pooling in Java EE will hold onto connections indefinitely, unless connections are configured with an aged timeout. Using an aged timeout might drive exceptions in some cases. An aged timeout also introduces a performance overhead during normal operation. Conversation sharing might need to be disabled (SHARCNV=1) with an aged timeout to ensure reconnects always establish a new socket. The ‘remembers last good’ CCDT behaviour might also delay failback. +ive Code stub can handle failback flexibly, with little/no performance overhead. Admin flexibility to hide infrastructure changes from apps -ive DNS only = DNS and/or shared file- system / CCDT file push +ive Dynamic Virtual IP address (VIP) = DNS or single-QMGR CCDT entries More detail on MQDev here: http://ibm.co/MM8rMl
  • 9. Receiving messages The application needs two active listeners • Random/prioritised attachment can lead to stranded messages • AMQSCLM is an alternative - discussed in AMC-1883 For Java EE this means two MDB endpoints • EJB 2.1 style deployment descriptors – Add a second endpoint to the XML • EJB 3.0 style annotations – Create a code hierarchy EJB 2.1 & 3.0 samples on github: https://github.com/ibm-messaging/mq-wlm-client Receiving application Active Active MQ Listener 1 MQ Listener 2 MQCluster Receiving Gateway 1 Receiving Gateway 2
  • 10. Synchronous request/response Response 1 Requester application Connection logic (CCDT or custom) MQ 1 MQ 2 MQ connection 1 MQ connection 2 MQCluster Request 1 Response 2 Request 2 Use same MQ connection to receive the response • e.g. the same JMS Session MQ fills in the MQMD.ReplyToQMgr on send • Back-end app must honour this when sending the response
  • 11. Synchronous request/response – advanced case A clustered reply queue for synchronous request/response • Lets replies take a different route back from requests • Only adds resilience for highly parallel nonpersistent request/reply, where requests build up on back-end threads in business logic rather than in MQ Requires correlation logic to pass responses back to waiting threads This is not the same as two-way asynchronous messaging Code samples: https://github.com/ibm-messaging/mq-wlm-client
  • 12. Asynchronous Receiver Two-way asynchronous messaging The optimal use of messaging is fully asynchronous Requests are sent “fire & forget”, as are responses • Critical requests are sent as persistent within a transaction that updates a DB • Transactional state update + persistent send = exactly once delivery Responses are handled by any app instance at any time • No thread is left ‘hung’ in the requesting application • If responses need to be correlated with requests, then a state store is used – A Database – DB2 etc. – An elastic cache – WebSphere eXtreme Scale Must be designed into the application • Can revolutionize responsiveness • Truly decouples applications Receiving application Active Active MQ Listener 1 MQ Listener 2 MQCluster Receiving Gateway 1 Receiving Gateway 2 Fire & Forget Requester CCDT or custom Sending Gateway 1 Sending Gateway 2 MQ connection 1 MQ connection 2 MQ Listener 1 MQ Listener 2 50% requests 50% requests 50% responses 50% responses
  • 13. Publish/subscribe messaging MQ gives the same QoS for pub/sub as for P2P • Fan out messages one-to-many • WLM across multiple subscriber instances Achieved by bridging durable subscriptions to cluster queues • Define subscriptions on queue managers where publishers connect Sub1 Inst1 Sub1 Inst2Pub Inst1 Pub Inst2 QM1 QM2 QM3 QM4 Pub/SubFan-Out +MQClusterWLM Sub2 Inst1 Sub2 Inst2 QM3 QM4
  • 14. Limitations for message ordering No active/active solution is provided here for ordered messages • MQ only assures order when there is one path from producing thread to consuming thread The simplest solution, and as far as this presentation goes • Allocate individual queue managers with HA Failover for ordered messages MQ Gateway 1 MQ Gateway 2 MQ Gateway 1 MQ Gateway 2 MQ Gateway N1 MQ Gateway N2 MQ Gateway N1 MQ Gateway N2 Receiver 1 Receiver 2 Receiver 3 Receiver 4 Receiver N1 Receiver N2 Receiver N3 Receiver N4 Sender 1 Sender 2 Sender 3 Sender 4 Sender N1 Sender N2 Sender N3 Sender N4 MQClusterWorkloadManagement .. . .. . .. . .. . Sender Sending gateway Receiving gateway Receiver Can be the same queue manager. Might be in different hubs.
  • 15. Including IBM Integration Bus The architecture fits IBM Integration Bus • Option 1: Add it as a separate tier • Option 2: Compress everything into a single active/active IIB tier For more on IIB architectures, try the following link (plug): ibm.co/1a2Y2os MQ GW1 MQ GW2 Receiver 1 Receiver 2 Receiver 3 Receiver 4 Sender 1 Sender 2 Sender 3 Sender 4 Sender Sending gateway Receiving gateway Receiver MQ GW1 MQ GW2 Integration Node 1 Integration Node 2 Routing & filtering MQCluster MQCluster Can be same the queue manager
  • 17. We Value Your Feedback Don’t forget to submit your Impact session and speaker feedback! Your feedback is very important to us – we use it to continually improve the conference. Use the Conference Mobile App or the online Agenda Builder to quickly submit your survey • Navigate to “Surveys” to see a view of surveys for sessions you’ve attended 17
  • 19. Legal Disclaimer • © IBM Corporation 2014. All Rights Reserved. • The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. • References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. • If the text contains performance statistics or references to benchmarks, insert the following language; otherwise delete: Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. • If the text includes any customer examples, please confirm we have prior written approval from such customer and insert the following language; otherwise delete: All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. • Please review text for proper trademark attribution of IBM products. At first use, each product name must be the full name and include appropriate trademark symbols (e.g., IBM Lotus® Sametime® Unyte™). Subsequent references can drop “IBM” but should include the proper branding (e.g., Lotus Sametime Gateway, or WebSphere Application Server). Please refer to http://www.ibm.com/legal/copytrade.shtml for guidance on which trademarks require the ® or ™ symbol. Do not use abbreviations for IBM product names in your presentation. All product names must be used as adjectives rather than nouns. Please list all of the trademarks that you use in your presentation as follows; delete any not included in your presentation. IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines Corporation in the United States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both. • If you reference Adobe® in the text, please mark the first use and include the following; otherwise delete: Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. • If you reference Java™ in the text, please mark the first use and include the following; otherwise delete: Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. • If you reference Microsoft® and/or Windows® in the text, please mark the first use and include the following, as applicable; otherwise delete: Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. • If you reference Intel® and/or any of the following Intel products in the text, please mark the first use and include those that you use as follows; otherwise delete: Intel, Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. • If you reference UNIX® in the text, please mark the first use and include the following; otherwise delete: UNIX is a registered trademark of The Open Group in the United States and other countries. • If you reference Linux® in your presentation, please mark the first use and include the following; otherwise delete: Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. • If the text/graphics include screenshots, no actual IBM employee names may be used (even your own), if your screenshots include fictitious company names (e.g., Renovations, Zeta Bank, Acme) please update and insert the following; otherwise delete: All references to [insert fictitious company name] refer to a fictitious company and are used for illustration purposes only.