What can go wrong will go wrong! How the MQ Appliance helps save the day.

Dilbert-DR

Since IBM announced the MQ Appliance earlier in 2015, there has been a huge amount of interest in the solution from pretty much everyone. All the customers and business partners I have talked to (along with the many my IBM colleagues have also been talking to) have almost always seen a place for the MQ Appliance in their organizations.

As expected some of these use cases reflect one of our anticipated scenarios of using the MQ Appliance – deploying in a remote location away from the main data centre. Other use cases are based in the data centre with the MQ Appliance being used either to roll out new MQ capacity quickly and simply or to consolidate an existing MQ deployment that might be installed and running on multiple different machines which can make it complex and expensive to maintain, especially when deploying updates or making configuration changes.

MQAppliance

Other that the simple and quick deployment and the ease of maintenance that the MQ Appliance provides, probably the function which generates the most interest from customers and potential customers is the High Availability function. MQ is used pretty universally for work that is critical to the business. The messages being moved between applications and systems contain business critical data and it is crucial that these messages are delivered once and once only and in the case of failure at any point, the messages are recoverable and the business can continue. No one wants to lose the message with the new customer details or the big order.

 

So the High Availability (HA) in the MQ Appliance was seen as key – it was simple to set up – essentially just a single menu selection when defining a new Queue Manager and you would have another appliance ready to synchronously replicate the persistent messages and logs so that in the case of a failure in the production Queue Manager, a replacement queue manager is started on the second MQ Appliance with full access to the messages and logs already available on that appliance. This simple yet rapid and usable solution is compelling, and can also be used, with manual failover control, to enable seamless operation while applying fixpacks on the appliance.

 

However one of the key details to understand about the HA support was that this used synchronous replication of the data between the disks on each appliance, and as the original message can’t be counted as complete until the replication is also complete, the HA appliance needs to be close enough so that the latency of the replication doesn’t impact the application writing the message. The published recommendation is for latency of less than 10ms, but for best operations latency of 2ms or less is preferred.

 

Now, with the 8.0.0.4 fixpack available on the MQ Appliance from November 30 2015, we have added another key feature – which addresses the need for replication over longer distances where latency is always going to be too high for synchronous replication. The 8.0.0.4 fixpack adds asynchronous replication enabling offsite replication over far longer distances than supported for HA as there is no impact to each individual message completion – the replication takes place independently. This style of replication is typically used for requirements such as Disaster Recovery (DR), to enable business continuity out of region with the ability to continue work as close to the point of failure as possible.

 

Customers using this DR feature with the MQ Appliance will be able to configure individual Queue Managers in their appliance to replicate their persistent messages to another MQ Appliance that can be hundreds, or even thousands of kilometres away. And unlike the HA configuration where appliances need to be a defined and fixed pair, there are much more flexible options for this style of asynchronous replication.

 

As mentioned the DR configuration is done on a Queue Manager by Queue Manager basis – but different Queue Managers on the same production appliance can be replicated to different DR appliances. Also Queue Managers defined on different production appliances can all replicate to the same individual DR appliance.

 

As before with the HA appliance, there can be ongoing work and other active Queue Managers on the appliance being used as the DR appliance – there is no formal limitation for appliances to be DR or HA appliances – any appliance can be configured to offer this in conjunction with the other workload running on it.

 

With the addition of this asynchronous replication for Disaster Recovery, the MQ Appliance can be used for more deployment use cases as the ability to recover from failures to a running environment in another data centre is always going to be crucial, as so many businesses depend on MQ to keep them running.

<BLOG UPDATE> With this MQ Appliance fixpack delivering such an important update we also have blogs from our Appliance development lead Ant Beardsmore here, and from our Appliance HA and DR architect John Colgrave here going into more details on the enhancements and the technical details of how DR works.

With simple configuration for all these scenarios, rapid deployment and ‘push-button’ maintenance, it is no wonder so many businesses are looking at using the IBM MQ Appliance. Want to know more? Check out our main webpage. After all, if things can go wrong, they will go wrong. That’s why you use IBM MQ after all. It is better to be ready and to be able to cope with these disruptions. Your business needs to keep running. With the MQ Appliance you can do that with the minimum of effort.

ApplianceDR

Advertisements

Tags: , , , , , , , ,

4 Responses to “What can go wrong will go wrong! How the MQ Appliance helps save the day.”

  1. MQ Appliance firmware update 4 – new DR capabilities and much more | Community Test Says:

    […] of miles, rather than hundreds of meters.  Leif has already talked about this at a high level here, and John, our HA architect will be following up with a deeper technical dive on MQDev in the near […]

  2. MQGem Monthly (December 2015) | MQGem Software Says:

    […] What can go wrong will go wrong! How the MQ Appliance helps save the day. […]

  3. Setting out markers for MQ’s road ahead | Leifdavidsen's Blog Says:

    […] failover between them benefitting from synchronous replication. At the end of 2015, as detailed here . IBM extended this High Availability option with asynchronous replication to other MQ Appliances, […]

  4. Going faster by not moving – IBM Appliance M2001 | Leifdavidsen's Blog Says:

    […] Go faster. Faster. Move it! Or actually don’t move it. There are times when to go faster you need to stop moving. We are all familiar with the parable of the tortoise and the hare – where slow and steady wins the race. But what about not moving at all? Sometimes that makes you go much faster. And in the case of the latest update to the IBM MQ Appliance that is exactly what we are doing. Hopefully you already know about the MQ Appliance, which IBM releases early in 2015, and have continued to enhance since its release. You can read my original entry here, and the update at the end of last year here. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: