Posts Tagged ‘IBM MQ Appliance’

Beginning the new, looking back to the old

January 17, 2017

janus2

The month of January is named after the God Janus – who both looked forward to the new year and back to the old one. So it is perhaps time to set ourselves up for what will be no doubt another very busy year for IBM MQ by a quick review of 2016 – looking at what you should have seen, and also finding time to tell you something new, which you are unlikely to be aware of.

So a quick recap first. In June we released a hardware refresh for the IBM MQ Appliance, adding large capacity SSDs and additional 10Gb network ports as described here. And IBM MQ brought out MQ V9.0 with a new option for end-to-end encryption with an order of magnitude performance boost, and CCDTs now accessed through a URI – and this was described here.

There were additional enhancements in November with IBM MQ moving to MQ V9.0.1 – the first Continuous Delivery release, with MFT enhancements and repackaged MFT Agents, availability of the new MQ Console, and the initial delivery of REST API verbs. These were all described here. And the IBM MQ Appliance also moved the MQ V9.0.1 and added additional features like Floating IP support, SNMP and LDAP authentication of admin accounts. This was written up here.

pvu_1

So if we are all ok with that, I had better share the news that you missed at the end of last year. First a word or two about Processor Value Units. This is IBM’s typical capacity based pricing metric for software. Each machine type and processor type has a PVU rating per core. And software products like IBM MQ have a price per PVU. So as a customer you buy a number of PVU entitlements to meet your capacity need and then deploy IBM MQ on the hardware that matches the PVUs you have bought. However this means you need to always count and be sure that the capacity you have provided to IBM MQ is in line with the entitlement you have, and the physical machines you are running on. But more and more these days software is being deployed on environments that are more abstracted from the actual physical machines – and the capacity being allocated, either on premise or in a cloud, is assigned as virtual cores. But with IBM MQ (and other products) priced only by PVUs, there was some confusion in mapping PVUs to virtual cores.

vcpu

On December 6th 2016, IBM MQ addressed this by adding a Virtual Processor Core metric to its pricing. This is only available as a monthly pricing metric but provides a new simple, and possibly more appropriate way of buying capacity for IBM MQ deployed in these virtual environments either on premise or in clouds where IBM MQ is deployed with a number of virtual cores of capacity rather than into a fixed physical machine. This is an additional metric. The PVU metric with both perpetual and monthly pricing is still available, but customers now have an additional option of the Virtual Processor Core pricing. There is no announcement letter for this, but the pricing is already available for IBM MQ and for IBM MQ Advanced, so simply ask your IBM sales rep or business partner about this if you want to know more.

Certain customers who can find it difficult to count PVUs might find this very useful. These might include customers such as retailers or retail banks where IBM MQ can be installed in 1000+ different environments, and for customers like this there are other ways to price for this type of deployment so again ask your IBM rep.

That was the last news and updates from 2016, but there is plenty to come in 2017. And you don’t need to wait for long. Just one week to go and I expect to have something new to share here. Not long to wait.

keepcalm

IBM MQ V9 – A fast, secure, reliable and more agile MQ

April 19, 2016

edwin-moses-getty_2129850b

Some of you reading this blog may recall the great athlete Ed Moses – who had a record 122 race winning streak in just about the hardest event – the 400M Hurdles. You need to be strong, fast, and agile just to compete, and to keep winning you need to be reliable. Well, this is how we view IBM MQ, especially with the latest release – IBM MQ V9. You may have seen a recent blogpost on here that had a Statement of Direction talking about a new way of delivering IBM MQ – one that provided a Long Term Support release, and a Continuous Delivery release. The aim of this model is to give customers more choice to select either highly stable releases with just fixes, or releases that benefitted from additional function in the fixpacks.

TRY IT: Click here to get a free trial of MQ

UPDATE: There is a FAQ on the new support model. Read it here.

On April 19th, IBM announced MQ V9 which is the first release that moves to this new more agile delivery model. As such at the initial release it delivers a small set of additional capabilities that will be available to all customers. Then subsequent mod-level updates will deliver even more updates to customers choosing the continuous delivery stream, but all customers moving to V9 will get the benefit of the new capabilities being delivered in this release.

As with previous releases of IBM MQ, customers have a lot of choice in where and how they may want to deploy this version. IBM supports deployment of MQ – and MQ Advanced pretty much on every commercial IT environment where business critical applications may be exchanging data reliably, securely, and at scale. This could be on-premise, deployed in cloud environments like IBM Softlayer, Microsoft Azure or Amazon AWS. IBM also supports virtualization with many customers deploying in VM images, and also in Docker containers, which can be deployed anywhere, including in IBM’s Bluemix platform. This flexibility enables customers to make use of enterprise messaging to support deployments on-premise, on cloud or in hybrid environments.

So what are the key new features of MQ V9 being delivered in this release? Well there are a number of them that are called out in the announcement letters – so you can read the MQ V9 distributed announcement letter here. And the MQ V9 z/OS MLC announcement letter here. And you can read the MQ V9 One Time Charge announcement letter here. But below I will call out a few of the features that I think will be most important to customers.

One of the features likely to be most interesting is a change to the MQ Client Channel Definition Table (CCDT), which is needed by the MQ Client application to provide the channel definitions needed to connect to the MQ Queue Manager. This file is created automatically and prior to MQ V9 needed to be distributed to the client application prior to use. The big change from this new release is that the CCDT can be a web addressable file instead of needing to be distributed out to every client, and to then need to do that with every change. By having a web addressable CCDT accessed by URI, then there are much lower administration needs, and also the MQ infrastructure can be much more dynamic as changes can be made centrally and take effect quickly and without application disruption.

 

The second big change to the new release of MQ is in MQ Advanced Message Security (MQ AMS). This feature, which is a priced extension to MQ (available either separately or as a part of MQ Advanced) provides policy based encryption at rest of the MQ message contents. By using this capability, businesses can be assured that their message contents can only be unencrypted and read by the targeted application destination, and there is no risk of exposure should any security breach take place which provides access to the system or storage where the MQ Queue Manager holds its queues. This privacy and integrity has been assured by the generation of asymmetric keys for every exchange between client and queue manager, which provides an extremely high level of security, but can introduce a high overhead in terms of the processor cost of the asymmetric key generation.

MQ AMS performance

With MQ V9, a new mode of operation is added to MQ AMS, called ‘Confidentiality’. In this mode there is an initial asymmetric key exchange then subsequent exchanges can reuse (to an extent that can be configured) a symmetric key. This still provides a high level of security and protection for the message content, but with a dramatically lower level of overhead in terms of encryption workload cost. IBM expects that due to the increasing importance of security and protecting systems and data from breaches, that this new feature of MQ AMS will help more customers protect their message contents and therefore their business and customer data. IBM expects to produce performance data for the new AMS configuration around the time that MQ V9 is generally available. But the early testing shows considerable improvement.

 

A further change for MQ AMS is the support of non-IBM JREs for use with MQ AMS. Previously applications written in Java that relied on a non-IBM JRE wouldn’t work with MQ AMS. In MQ V9 this has now changed so that suitable non-IBM JREs can be used, as well as IBM JREs, extending the ability of more customers to use MQ AMS.

 

There are a number of other new functions and capabilities available in MQ V9, such as updates to MQ Managed File Transfer capabilities – which are described in the announcement letter, and with the movement to a Continuous Delivery model customers should expect to see more capabilities being delivered in mod levels on top of MQ V9 in the future.

 

With the recent announcement of the End of Support for MQ V7.1 – announced here – along with the related end of support of the older separate versions of MQ FTE and MQ AMS, this latest release of MQ V9, along with the recent announcement of the update to the MQ Appliance provides customers with a strong set of choices of how to take advantage of the latest new releases as they plan to move off the older releases of MQ they may be using, keeping their deployment of MQ up to date and supported.

When you are taking advantage of the benefits of IBM MQ, you may not need to have to work as hard as Ed Moses did to be #1.

UPDATE: Mark Taylor has provided one of his highly useful videos detailing more of the new function in MQ V9. Watch it here.

 

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

November 30, 2015

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