MQ Clustering and Shared Queues for High Availability

Transcription

1 MQ Clustering and Shared Queues for High Availability Doug Burns - burnsd@uk.ibm.com IBM UK 08/11/2017 Session JK

2 Abstract IBM WebSphere MQ for z/os can be made highly available using features of the product or operating system. This session will describe and compare those features, and show how they can be effectively used together for extremely reliable environments. Included in this session are queue-sharing groups with shared channels, queue manager clusters with cluster channels, and how these types of channels operate differently to traditional channels.

3 Agenda Queue Sharing Groups with Shared Queues MQ Queue Manager Clustering Channel Technologies A Comparison Shared channels Cluster channels Normal channels Best Practice Scenario Example

4 Queue Sharing Groups

5 What is a queue-sharing group (QSG)? High availability for MQ resources Queue managers share queues Applications can access messages on shared queues from any queue manager in the same QSG Each queue manager also has its own private queues Shared queues stored in the Coupling Facility (CF) Large messages offloaded to DB2 or SMDS to maximise capacity Applications can connect to a named queue manager or any available queue manager using the QSG name Queue manager Queue-sharing group Private Private queues queues CF Shared queues Queue manager Private queues Queue manager Private queues

6 What is a queue-sharing group (QSG)? A queue-sharing group (QSG) is a co-operating set of queue managers running in the same z/os sysplex. Each queue manager has its own private queues, but also has access to shared queues that are held in the Coupling Facility. Multiple queue-sharing groups can be defined in the same sysplex, but each queue manager can belong to only one QSG. An application that accesses shared queues can connect to any of the queue managers in the queue-sharing group. This is because all the queue managers in the queue-sharing group can access the same set of shared queues, so the application does not depend on the availability of a particular queue manager. If an individual queue manager or LPAR fails an application can reconnect to any other available queue manager in the group. Client applications can similarly connect to any available queue manager using a virtual IP address for the QSG. Notes

7 Components of a Queue-Sharing Group MQ Queue-Sharing Group DB2 Data-Sharing Group SMDS Channel Initiator QMGR Shared Objects DB2A DB2B DB2C SMDS Channel Initiator QMGR Private Queues Private Objects CF Private Queues Private Objects Shared Queues

8 Components of a queue-sharing group Queue-sharing groups are comprised of the following components: Two or more queue managers there is very little benefit in having a QSG with only one member One or more Coupling Facilities to hold the share queues A DB2 data-sharing group Shared object definitions for a queue-sharing group are maintained for MQ by DB2. Shared access to these definitions is by DB2 data sharing: You must have DB2 You can have more than one data-sharing group, but all members of one QSG must be members of the same data-sharing group Shared object definitions are cached in the queue managers A DB2 outage does not bring down the QSG (but you cannot add or change shared objects if DB2 is unavailable) If using shared messages larger than 63KB then a small portion of each message is stored in the CF, and the remainder is stored in either DB2 or SMDS (VSAM) data sets Notes

9 Advantages of shared queues Allows MQ applications to be: Scalable Highly available Allows workload balancing to be implemented Natural pull-workload balancing based on processing capacity of each queue manager No outages for shared queue applications Can stagger outages of each queue manager in the QSG even during upgrades Flexible capacity management Can dynamically add or remove queue managers and queues Peer recovery MQ detects if a queue manager abnormally disconnects from the Coupling Facility Another queue manager in the QSG completes pending units of work, where possible Uncommitted gets (under sync-point) are backed out Messages can be re-got by another queue manager Uncommitted puts (under sync-point) are committed Message made available as soon as possible

10 Advantages of shared queues There are a number of advantages to using shared queues Messages are highly available because they can be accessed from any queue manager in the QSG. Workloads using shared queues naturally scale because they can be accessed from multiple queue managers concurrently, using any of the available LPARs in the sysplex Shared queues naturally support pull-workload balancing because each queue manager responds to queuing requests independently, based on the available processing capacity. If the performance of one application instance or queue manager degrades, the remaining instances automatically process a greater proportion of the messages. Maintenance, including upgrades, can be independently applied to queue managers in a QSG. By staggering queue manager outages access to the shared queues can be maintained at all times. Queue managers can be dynamically added or removed from a QSG to support growth or reduction in capacity. Similarly, shared queues can be defined, altered or deleted from any queue manager in the QSG. The queue managers in a QSG use the z/os XCF facility for intercommunication. If a queue manager fails, or abnormally disconnects from the Coupling Facility, the other queue managers are notified. One of the available queue managers can complete pending updates for the failed queue manager. This allows pending gets or puts to be committed, or rolled back, as appropriate so messages can be made available without the need to wait for the failing queue manager to be restored. This is called Peer Recovery. Version introduced group units of recovery for 2-phase commit transactions. Units of work for some types of application can be owned by the queue-sharing group instead of an individual queue manager, which allows a transaction manager to also resolve in-doubts from any member of the QSG. Notes

11 Failure and Persistence Queue manager failure Coupling facility failure Queue manager Nonpersistent messages on private queues OK (kept) Queue manager Queue manager Queue manager Private queues Private queues Private queues Private queues Shared queues Shared queues Messages on shared queues OK (kept) Queue manager Private queues Nonpersistent messages on private queues lost (deleted) Queue manager Private queues Nonpersistent messages on shared queues lost (deleted) Persistent messages on shared queues restored from log

12 Failure and persistence The previous slide shows implications of failures in a queue-sharing group. The left side shows a queue manager failure. If one or more queue managers in a queue-sharing group fail, or are stopped normally: Non-persistent messages on queues private to the failing queue manager or queue managers are lost in fact they are deleted when the queue manager restarts Persistent or non-persistent messages on shared queues are not lost, they are kept even if all queue managers in the queue-sharing group fail The right side shows a Coupling Facility (CF) structure failure. For simplicity the chart shows an entire CF failing. If one or more CF structures fail: Messages on queues in other CF structures are not affected Non-persistent messages on queues in failing CF structures are lost Persistent messages on queues in failing CF structures must be restored from backup and log information. The queue manager restoring the structure accesses the logs of all queue managers in the QSG. Regular (sub-hourly) backups of the CF structures is recommended. Backup is fairly quick if queues are not heavily loaded. Remember, a good queue is one that is being served and hence generally empty! Notes

13 A history of large shared-queue messages Coupling Facility storage is limited Balance between number of messages and size of messages Version 5.2 Non-persistent messages < 63KB only Version 5.3 Persistent messages also supported, but still limited to < 63KB Version 6.0 Large messages supported up to 100MB Messages > 63KB offloaded to DB2 as BLOBs Version 7.1 Support for Shared Message Data Sets (VSAM) Alternative to DB2 for large messages much better performance Custom offload rules zec12 with Flash Express SCM storage can also be exploited to increase CF capacity

14 A history of large shared-queue messages Queue-sharing groups were introduced in version 5.2, but originally only supported non-persistent messages less than 63KB. In subsequent releases support for persistent messages and those up to 100MB was also added. Coupling Facility (CF) storage is limited and it is also more expensive than traditional DASD. To support a large volume of messages, those larger than 63KB are offloaded to another storage medium, with only minimal data for these messages stored in the CF. Prior to version 7.1 large messages were stored in DB2 as BLOBs, but Shared Message Data Sets (VSAM) are now also supported for improved performance. In version 7.1 support for custom offload rules was also introduced. These rules allow the message size threshold to be tuned based on the remaining capacity of the Coupling Facility structure. Messages larger than 63KB must always be offloaded, but as a structure becomes full smaller messages can also be offloaded to maximise the remaining capacity. With the introduction of the zec12 hardware it is now possible to supplement Coupling Facility storage using Flash Express cards, otherwise known as SCM storage. This can significantly increase capacity, for example to provide additional storage for messages during maintenance windows. Notes

15 Large Shared Queue Messages (using SMDS) APP MQPUT APP MQGET Shared queue QM1 2 3 QM2 QM2 SMDS 1 Ptr to 100K message 4 QM1 SMDS One SMDS per queue manager per CF structure Each queue manager only writes large messages to its own SMDS Queue managers can get messages from any queue manager s SMDS 14

16 Large Shared Queue Messages (SMDS) Offloaded message data for shared messages is stored in VSAM linear data sets (LDS). Each application structure has an associated group of SMDSs, with one data set per queue manager (hence a possible maximum of 32 SMDSs per application structure). Each SMDS must be on shared direct access storage that is accessible to all queue managers in the queue-sharing group. The group of SMDSs is named using the DSGROUP parameter on CFSTRUCT definition. Each queue manager owns a data set for each structure, opened for read/write access, to which it writes new large messages. Each queue manager opens the data sets managed by the other queue managers for read-only access so that it can read the payload for large messages that has been off-loaded to these data sets by the other queue managers. When a message with offloaded data needs to be deleted, the queue manager processes the delete request by transferring the Coupling Facility entry for the message to a clean-up list monitored by the owning queue manager. The owning queue manager reads and deletes the entries and the offloaded data in the SMDS thus freeing up the space in the data set. In the diagram: Application connects to QM1 to put a 100KB message to a shared queue. QM1 writes the message payload to the SMDS managed by QM1. QM1 puts a pointer to the message payload in the application structure in the CF. Application connects to QM2 to get a message from the shared queue. QM2 recognises that this is a shared message. QM2 retrieves the message payload from the SMDS managed by QM1. Notes

17 Transactions / Second Transactions / Second 3 LPAR Test - DB2 SMDS performance 3 LPAR Test - SMDS 64KB Non-Persistent Messages In-Syncpoint - DB2 64KB Non-Persistent Messages In-Syncpoint - SMDS Queue Pairs Queue Pairs NP SIS Scaling 3 qmgr NP SIS Scaling 6 qmgr NP SIS Scaling 9 qmgr NP SIS Scaling 3 qmgr NP SIS Scaling 6 qmgr NP SIS Scaling 9 qmgr Tests show comparable CPU savings, making SMDS a more usable feature for managing your CF storage SMDS per CF structure provides better scaling than DB2 BLOB storage

18 SMDS performance SIS (Server in Syncpoint) This means that while the requester task is putting and getting messages out of syncpoint, the server task is getting and putting messages in syncpoint 3 LPARs in the performance test Sysplex Each LPAR had 1, 2, then 3 queue managers each Queue pairs Each requester task puts to a request queue and gets-specific from a reply queue. The server task then gets the next available message from the request queue and puts to the reply queue. With 1 queue pair, there is 1 requester and 1 server per queue manager With n queue pairs, there are n requesters and n servers per queue manager Notes

19 MQ Queue Manager Clusters 18

20 Goals of Clustering Multiple Queues with single image Failure isolation Scalable throughput MQI applications to exploit clusters transparently Definition through usage (MQOPEN) MQGET always local

21 Goals of Clustering Consider a client using the black queue that is available in the cluster on three server queue managers. A message is MQPUT by the client and is delivered to *one* of the servers. It is processed there and a response message sent to a ReplyToQueue on the client queue manager. In this system, if a server becomes unavailable, then it is not sent any further messages. If messages are not being processed quickly enough, then another server can be added to improve the processing rate. It is important that both these behaviors are achieved by existing MQI applications, i.e. without change. It is also important that the administration of clients and servers is easy. It must be straight forward to add new servers and new clients to the server. We see how a cluster can provide a highly available and scalable message processing system. The administration point in processing is MQOPEN as this is when a queue or queue manager is identified as being required by an application. Note that only one message is sent to a server; it is not replicated three times, rather a specific server is chosen and the message sent there. Also note that MQGET processing is still local, we are not extending MQGET into the network. Notes

22 The Purpose of Clustering Simplified administration Large MQ networks require many object definitions Channels Transmit queues Remote queues Workload balancing Spread the load Route around failures Flexible connectivity Overlapping clusters Gateway Queue managers Pub/sub Clusters

23 How can we process more messages? It would be nice if we could place all the queues in one place. We could then add processing capacity around this single Queue manager as required and start multiple servers on each of the processors. We would incrementally add processing capacity to satisfy increased demand. We could manage the system as a single entity. A client application would consider itself to be talking to a single Queue manager entity. Even though this is highly desirable, in practice it is almost impossible to achieve. Single machines cannot just have extra processors added indefinitely. Invalidation of processor caches becomes a limiting factor. Most systems do not have an architecture that allows data to be efficiently shared between an arbitrary number of processors. Very soon, locking becomes an issue that inhibits scalability of the number of processors on a single machine. These systems are known as "tightly coupled" because operations on one processor may have a large effect on other processors in the machine cluster. By contrast, "loosely coupled" clusters (e.g. the Internet) have processors that are more or less independent of each other. Data transferred to one processor is owned by it and is not affected by other processors. Such systems do not suffer from processor locking issues. In a cluster solution, there are multiple consumers of queues (client queue managers) and multiple providers of queues (server queue managers). In this model, for example, the black queue is available on multiple servers. Some clients use the black queue on both servers, other clients use the black queue on just one server. A cluster is a loosely coupled system. Messages flow from clients to servers and are processed and responses messages sent back to the client. Servers are selected by the client and are independent of each other. It is a good representation of how, in an organization, some servers provide many services, and how clients use services provided by multiple servers. The objective of WebSphere MQ clustering is to make this system as easy to administer and scale as the Single Queue Manager solution. Notes

24 Simplified administration Large MQ networks require many object definitions Manually defining the network For each Queue Manager you connect to:- Transmission Queue Sender Channel Remote Queue (Optional) so we won t count it And a single generic Receiver Channel Cluster network Cluster-Sender channel to a full repository Cluster-Receiver channel as the model back to me. #Objects = ((#QMgrs-1) * 2 +1) * #Qmgrs Which is:- #Objects = 2 x #Qmgrs 2 - #Qmgrs #Objects = 2 x #QMgrs Number of QMgrs Manually Defined Objects Objects for Cluster

25 Simplified administration Notes When creating a fully connection mesh of queue managers using distributed queuing, you need to create the sender channel and transmission queues for connectivity to each queue manager you wish to connect to, plus you ll need a single generic receiver channel for them to connect back. For each queue manager you want to connect to, that is a minimum of two objects let s say we don t count queue remote definitions as they are optional per connected queue manager, plus the one receiver. This ends up with a logarithmic algorithm which grows exponentially. Whereas for the cluster example, we just need two definitions on each queue manager, regardless of how many queue managers are in the network, so it scales nice and linearly. For more details see Notes

26 Split cluster transmit queue Much requested feature for various reasons Separation of Message Traffic With a single transmission queue there is potential for pending messages for cluster channel 'A' to interfere with messages pending for cluster channel 'B' Management of messages Use of queue concepts such as MAXDEPTH not useful when using a single transmission queue for more than one channel. Monitoring Tracking the number of messages processed by a cluster channel currently difficult/impossible using queue monitoring (some information available via Channel Status). Not about performance... V8

27 Split cluster transmit queue This has been a very long standing requirement from a number of customers Introduced for distributed platforms in MQ V7.5 Available in MQ for z/os from V8 All the reasons on this slide are valid, but the number one reason often quoted in requirements was performance In reality splitting out the transmit queue does not often buy much here, hence often other solutions (e.g. improving channel throughput) were really needed. Main reason for delivery now is to allow application separation Notes

28 Split cluster transmit queue - automatic New Queue Manager attribute which effects all cluster-sender channels on the queue manager ALTER QMGR DEFCLXQ( SCTQ CHANNEL ) Queue manager will automatically define a PERMANENT-DYNAMIC queue for each CLUSSDR channel. Dynamic queues based upon new model queue SYSTEM.CLUSTER.TRANSMIT.MODEL Well known queue names: SYSTEM.CLUSTER.TRANSMIT.<CHANNEL-NAME> Authority checks at MQOPEN of a cluster queue will still be made against the SYSTEM.CLUSTER.TRANSMIT.QUEUE even if CLUSSDR is selected.

29 Splitting out the S.C.T.Q. per channel CLUSTER1 QM_B Q1 QM_A..B..C QM_C Q2

30 Split cluster transmit queue - manual Administrator manually defines a transmission queue and using a new queue attribute defines the CLUSSDR channel(s) which will use this queue as their transmission queue. DEFINE QLOCAL(APPQMGR.CLUSTER1.XMITQ) CLCHNAME(CLUSTER1.TO.APPQMGR) USAGE(XMITQ) The CLCHNAME can include a wildcard at the start or end of to allow a single queue to be used for multiple channels. In this example, assuming a naming convention where channel names all start with the name of the cluster, all channels for CLUSTER1 use the transmission queue CLUSTER1.XMITQ. DEFINE QLOCAL(CLUSTER1.XMITQ) CLCHNAME(CLUSTER1.*) USAGE(XMITQ) Multiple queues can be defined to cover all, or a subset of the cluster channels. Can also be combined with the automatic option Manual queue definition takes precedence.

31 Splitting out by cluster (or application) Cluster 2 Cluster 1 QM_B..1.B CLUSTER1.QM_B Q1 Q2 QM_A..2.B

32 Channel Technologies 31

33 QM1 (Local) Normal Channels QM2 (Remote) MQ Application MCA Message Flow MCA Transmission Queue Channel Application Queues SyncQ Network SyncQ Channel name match both ends Manual definition Sender MQGET from XmitQ Sync state written to SyncQ Receiver MQPUT to app queues Sync state written to SyncQ

34 Normal Channels Notes Normal channels, that is those which are non cluster channels have their definitions created with an administrative command, DEFINE CHANNEL The name used as the channel name must match for both ends, that is the sender must have the same name as the receiver. A normal sender has a transmission queue (XmitQ) defined as part of it s channel definition and sits in an MQGET call on the XmitQ waiting for messages to send to the receiver end of the channel. When transactional messages are sent over a channel (that is persistent messages; or all messages when channel is defined to use NPMSPEED(NORMAL)) then synchronisation state is persisted. On z/os this is done by writing a message to the synchronisation queue (SyncQ) which is the SYSTEM.CHANNEL.SYNCQ. Channels use a protocol which we call the channel FAP (Format and Protocol) to ensure messages are sent/received in a manner which means they have assured delivery. Notes

35 Shared Channels Inbound CHLDISP(PRIVATE) CHLDISP(SHARED) G e n e r I c LP SP Queue Manager QM1 SyncQ QSG LP SP Coupling Facility Queue Manager QM2 SyncQ SyncQ Port disposition determines channel disposition LP SP Queue Manager QM3 SyncQ

36 Shared Channels Outbound QSG XmitQ disposition determines channel disposition Queue Manager QM1 SyncQ Queue Manager QM2 SyncQ XmitQ SyncQ Coupling Facility CHLDISP(SHARED) CHLDISP(PRIVATE) XmitQ Queue Manager QM3 SyncQ

37 Shared Channels Notes Inbound Channel Each queue manager in the queue-sharing group is connected to the Generic address and an inbound session request to the group will result in a session being established with one of the queue managers in the group. This Generic Port (GP) gives high front end availability since the sending queue manager can resynchronise with any member of the queue-sharing group. The most common technique for implementing the Generic Port is Sysplex Distributor, but it is a natural fit for others too such as VTAM GR, Network dispatcher, RYO. Each queue manager is now listening on two addresses. The Group Listener listens on the Shared Port (SP): START LSTR INDISP(GROUP) PORT(SP) The default listener command is: START LSTR INDISP(QMGR) PORT(LP) Outbound Channel A private channel moves messages from a private transmission queue to the target system. A shared channel is simply a channel which moves messages from a shared transmission queue to the target system. Very high availability is achieved through peer channel restart which occurs after Comms subsystem, Channel Initiator or Queue Manager failure. Members are identified at the Client queue manager by exchanging the Group Name instead of the Queue Manager name so they appear logically as the same instance. Any member can then resynchronise with the partner. Synchronisation state is written to the shared SyncQ to facilitate this. It is named SYSTEM.QSG.CHANNEL.SYNCQ Shared channel starts are workload balanced across all the systems in the queue-sharing group Increased capacity is achieved by having more queue managers available to access transmission queues and deliver the messages on to target systems. Notes

38 QM1 (Local) Cluster Transmission Queue DEFINE MQGET By CorrelId SyncQ MCA Cluster Channels Message Flow Channel Network CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME( QM1.mach.ibm.com ) CLUSTER(DEMOCLUS) Channel Definition Bootstrap CLUSSDR (point to repository) Manual CLUSRCVR (defines model back to this queue manager) Automatic CLUSSDR (for routes to all other queue managers) Transmission Queue SYSTEM.CLUSTER.TRANSMIT.QUEUE With Split Cluster XmitQ Feature could be other Synchronisation As for normal channels BATCHHB can reduce likelihood of ending INDOUBT(YES) MQGET off XmitQ Uses CorrelId of Channel Name

39 Cluster Channels Notes Cluster channels are created by automatically installing definitions based on some manually created bootstrap channel definitions. An auto-cluster-sender channel will be created by using information from the manually defined cluster-receiver channel for the partner queue manager it wants to send messages to. A cluster-sender channel does not have a transmission queue named in its channel definition but instead uses a locally nominated queue by default the SYSTEM.CLUSTER.TRANSMIT.QUEUE, but if the recently provided split cluster transmit queue feature is in effect, then it may be another transmit queue. A cluster-sender channel differs from a normal sender channel when it does the MQGET off the XmitQ because it uses an MQGET with CorrelId where the CorrelId is the channel name. Once the channel definition is in place, and the MQGET is done, the channel operates in the same way as a normal channel with very few exceptions. Sequence numbers: Cluster channels do not suffer from sequence number errors as normal channels do. This is because the cluster-receiver will always do what the cluster-sender says. When a cluster channel cannot connect to the target queue manager, messages destined for the queue on that system may be able to be reallocated to another target queue manager hosting the same named queue, over a different channel. To be reallocated they must have been sent using MQOO_BIND_NOT_FIXED, and they cannot be part of an INDOUBT UoW. Use of BATCHHB on the channel can drastically reduce the likelihood of the channel ending with INDOUBT(YES). Notes

40 Comparison of Channel Technologies Channel Definition in place Manually defined, or automatically installed Transmission Queue identified Named on definition, or pick up cluster one QSGDISP(PRIVATE) or QSGDISP(SHARED) Synchronisation Queue identified QSGDISP(PRIVATE) or QSGDISP(SHARED) MQGET on XmitQ qualifier Channel name for cluster channel Now all sending channels work the same Target CONNAME and Port resolved Specific queue manager or Generic Port Synchronisation Queue identified QSGDISP(PRIVATE) or QSGDISP(SHARED) Now all receiving channels work the same Shared Cluster Normal Shared Synchronisation State Can deliver messages to shared queues High Availability for connections High Availability for delivery of new & in-transit messages Definition administration Group Auto Manual

41 Comparison of Channel Technologies Here we bring together a comparison of the channel technologies we looked at on the previous few pages. Once all the definition and initialisation for channels is done, they all essentially operate in the same way when they are running. The protocol (FAP) used by them all is the same. Notes

42 Best Practise Scenario Example 41

43 Scenario Combining clusters and queue-sharing groups MQ Cluster MQ on AIX MQ on z/os CICS on z/os Application operation Queue manager operation For triggering (optional) QM_GW_01 QM_CB_01 CICS1 MQPUT1 MQ Clients MQGET wait TRANSFER.REPLY.01 (QLOCAL, cluster) TRANSFER.REQUEST.I NIT.QUEUE MQGET wait and LOOP TRANS backend processing MQPUT TRANSFER.REQ UEST.QA.01 (QALIAS) QM_GW_02 Cluster workload balancing QM_CB_02 TRANSFER.REQUEST.01 (shared, cluster) CKTI CKTI CICS2 MQ Clients MQPUT TRANSFER.REQ UEST.QA.01 (QALIAS) TRANSFER.REQUEST.I NIT.QUEUE MQGET wait and LOOP TRANS backend processing MQGET wait TRANSFER.REPLY.01 (QLOCAL, cluster) MQPUT1

44 Scenario The previous slide illustrates how a cluster and a queue-sharing group can be combined to provide a highly available and scalable end-to-end solution. 1. Clients connect to one of a number of distributed queue managers to send requests and receive their replies. Multiple queue managers are used for availability and workload balancing. If required, multi-instance (standby) queue managers can be used to improve their availability. 2. Requests are routed to a shared queue on z/os using a cluster. Clustering greatly simplifies channel administration and messages are automatically routed to any available z/os queue manager. Cluster workload balancing is used to distribute network traffic and reroute messages if one of the z/os queue managers is unavailable. The z/os queue managers typically run on different LPARs in the sysplex. 3. Multiple CICS regions serve the requests via the z/os queue managers using either a get-wait loop or triggering. CICS transactions and/or regions can be added or removed as necessary to satisfy demand. If one of the z/os queue managers is unavailable the CICS regions connected to the remaining z/os queue managers are used to process all the requests. 4. The CICS regions process each request and clustering similarly routes any replies back to queues on the distributed queue managers where they can be retrieved by the client applications. The Coupling Facility hosting the shared queue may appear a single point of failure. However, this is itself highly resilient to failure and may be duplexed for redundancy. Notes

45 Where can I get more information? IBM Messaging developerworks developer.ibm.com/messaging IBM Messaging Youtube LinkedIn Ibm.biz/ibmmessaging IBM MQ Facebook Facebook.com/IBM-MQ / 44

46 45 Thank you and any questions?

47 Notices and Disclaimers Copyright 2017 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law 46

48 Notices and Disclaimers Con t. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained h erein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Aspera, Bluemix, Blueworks Live, CICS, Clearcase, Cognos, DOORS, Emptoris, Enterprise Document Management System, FASP, FileNet, Global Business Services, Global Technology Services, IBM ExperienceOne, IBM SmartCloud, IBM Social Business, Information on Demand, ILOG, Maximo, MQIntegrator, MQSeries, Netcool, OMEGAMON, OpenPower, PureAnalytics, PureApplication, purecluster, PureCoverage, PureData, PureExperience, PureFlex, purequery, purescale, PureSystems, QRadar, Rational, Rhapsody, Smarter Commerce, SoDA, SPSS, Sterling Commerce, StoredIQ, Tealeaf, Tivoli, Trusteer, Unica, urban{code}, Watson, WebSphere, Worklight, X-Force and System z Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: 47

49 Session feedback Please submit your feedback online at: Paper feedback forms also available from the Chair person This session is JK