© 2014 IBM Corporation

Building a Scalable & Continuously AvailableIBM 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 ClusterWorkload Balancing

MQ ClusterWorkload Balancing

Overview – architecture view

Every sender/requester uses two connectionsEvery receiver/service has two listenersMake each Queue Manager HA to recover persistent messagesSimple to interoperate with co-located Queue ManagersSimple to interoperate with z/OS Queue Sharing Groups Pattern discussed in detail here: http://ow.ly/vrUUV

App1 QM1App1 QM1

App1QM2App1QM2

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

MQ1Standby

MQ2Standby

Machine 1 Machine 2

HA failover

HA failoverMQ2

(Sending &Receiving GW)

MQ1(Sending &

Receiving GW)

Highly availablenetwork-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

MQ

Cluster

Receiver 1

Receiver 2

Receiver 3

Receiver 4

Sender 1

Sender 2

Sender 3

Sender 4

Sender 5

Sender 6

Sender 7

Sender 8

MQGateway 1

MQGateway 2

MQGateway 3

MQGateway 4

MQGateway 5

MQGateway 1

MQGateway 2

MQGateway 3

MQGateway 4

MQGateway 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 connectto two different remote queue managers

Sendingapplication

Connectionlogic

(CCDT orcustom)

SendingGateway 1

SendingGateway 2

MQ connection 1

MQ connection 2

MQ

Clust er

Sending messages – choices for multi-QM client attachmentCONNAME list CCDT (multi-QMGR) Load balancer Code stub

Scale of code change required for existing apps that connect to a single QM

+iveMQCONN("QMNAME") to MQCONN("*QMNAME")QMName might be in JNDI config for Java EE apps.Otherwise requires a one character code-change.

-iveReplace existing JMS/MQI connection logic with code stub.

Support for different WLM strategies

-ivePrioritized only

=Prioritized + Random

+iveAny, including per-connect round-robin

+iveAny, including per-message round-robin.

Performance overhead while primary QM is down

-iveAlways tries first in list

+iveRemembers last good

+ivePort monitoring avoids bad QMs

+iveCan remember last good, and retry intelligently

XA Transaction Support

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

+iveCode 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

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

+iveCode stub can handle failback flexibly, with little/no performance overhead.

Admin flexibility to hide infrastructure changes from apps

-iveDNS only

=DNS and/or shared file-system / CCDT file push

+iveDynamic 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

Receivingapplication

Active

Active

MQ Listener 1

MQ Listener 2

MQ

Clust er

ReceivingGateway 1

ReceivingGateway 2

Synchronous request/response

Response 1Requesterapplication

Connectionlogic

(CCDT orcustom)

MQ 1

MQ 2

MQ connection 1

MQ connection 2

MQ

Clust er

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

AsynchronousReceiver

Two-way asynchronous messaging

The optimal use of messaging is fully asynchronousRequests 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

Receivingapplication

Active

Active

MQ Listener 1

MQ Listener 2

MQ

Cluste

r

ReceivingGateway 1

ReceivingGateway 2

Fire &ForgetRequester

CCDTor custom

SendingGateway 1

SendingGateway 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/S

ub Fan

-Ou

t+

MQ

Clu ster W

LM

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

MQGateway 1

MQGateway 2

MQGateway 1

MQGateway 2

MQGateway N1

MQGateway N2

MQGateway N1

MQGateway 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

MQ

Clu

ster W

orklo

ad M

ana

gem

ent

. .

. . .

. . .

.. .

.

SenderSendinggateway

Receivinggateway 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

MQGW1

MQGW2

Receiver 1

Receiver 2

Receiver 3

Receiver 4

Sender 1

Sender 2

Sender 3

Sender 4

SenderSendinggateway

Receivinggateway

Receiver

MQGW1

MQGW2

Integration Node 1

Integration Node 2

Routing& filtering

MQ

Clust er

MQ

Clust er

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.