Posts Tagged ‘MQ Statement of Direction’

Reaching for SANity with the IBM MQ Appliance

October 24, 2017

Appliance reaching

We all like to keep our word, and even though a Statement of Direction is not always a promise, at IBM we like to try and deliver what we set out, as long as the market and need hasn’t changed.

And for customers who have been following the MQ Appliance since the start, back in March 2015, you might recall that there was a Statement of Direction about adding support for the fibre channel cards that were part of the MQ Appliance hardware to allow connectivity to a SAN for customers who wanted that. And we are delighted that as part of the MQ V9.0.4 update on the MQ Appliance, that IBM is delivered on that Statement of Direction.

MQ V9.0.4 is a very significant update for MQ and most of the updates that are not specific to the MQ Appliance are described in my other blog entry here. However, in addition to those features there are specific MQ Appliance updates, and a dedicated announcement letter which I will try to explain in more detail here.

Firstly, the SAN support. One of the reasons the MQ Appliance has been so popular with customers is the built-in storage (2x 3.2TB SSDs in a RAID 1 configuration) and the simple HA configuration allowing a pair of MQ Appliances to replicate messages and log data between them on a QM by QM basis with just a couple of clicks on setup. And a lot of the updates to the MQ Appliance has been to support the wider use of this popular deployment use case.

Appliance SAN options

However, some customers have always wanted us to add support for SANs for some of their use cases. One use case was that 3.2TB of onboard storage might not be enough. If you consider when a consuming application might fail over a long weekend and the queue depths might get very high. One of our customers recently said, “an empty queue is a happy queue” and this is true, but in the case of a protracted failure you want to ensure your queues can hold all the messages. So, if you are concerned about this scenario, then you might want to have the Queues supporting that use case on external storage where there is no effective limit to queue depth.

The other use case, which tends to come up more commonly in customer discussions is around the thought of “consistency groups”. This is when you are trying to recover from a site failure at your disaster recovery location. This is typically a manual task, unlike the automated High Availability configuration. Part of this manual task will be to establish the last known transactions of not just MQ but other parts of the IT infrastructure such as applications and databases. This is likely to be easier if all the data points from all these ‘moving parts’ are stored on a common storage area, and this is replicated consistently between the SAN on one site and the SAN on the disaster recovery site. So this use case is now supported by the MQ Appliance with customer selected Queue Managers able to choose the SAN storage instead of the internal storage and have a MQ Appliance in the disaster recovery site read the replicated messages and data from the SAN there.

A second update to the MQ Appliance specific features is to provide customers with a quicker and simpler way to ensure that Queue Managers on the MQ Appliance have the best allocation of resources on the MQ Appliance. When Queue Managers are initially created the MQ Appliance determines how much space to allow to them. However if workload on a Queue Manager grows faster than other Queue Managers, it is likely that the allocated resources might need to grow to match the likely workload. However, it hasn’t been easy to do that. But with the MQ V9.0.4 update on the MQ Appliance IBM has added dynamic disk allocation, enabling resources for a Queue Manager to be increases even after it was initially created. This will make the ongoing operation and support of production workloads on the MQ Appliance quicker and simpler.

Appliance MFT

Finally, an update off the MQ Appliance will have a positive impact on potential use cases for the MQ Appliance. Virtually every customer still moves large amounts of data around their business as files and file contents. Much of this is unmanaged, insecure and unreliable, and for a number of years IBM has provided a solution: MQ Managed File Transfer. This enables file contents to move from point to point over the MQ network as MQ messages, taking advantage of MQ’s reliability, security and manageability. Part of the MQ Managed File Transfer functions was a logger to track which files were sent over MQ, and this, if used, always needed to run on the same machine as the Queue Manager. This prevented some MQ MFT use cases from being deployed in environments where the MQ Appliance was the only MQ Queue Manager. Now, with MQ V9.0.4 the file logger component of MQ MFT can be deployed remotely from the Queue Manager, meaning it can be used in locations by pointing to a remote MQ Appliance, without the need to install anything on the MQ Appliance, which has always been prohibited. It’s always good to allow customers more flexibility in deployment.

This combination of enhancements, along with the many non-Appliance specific MQ updates in the MQ V9.0.4 release means that there should be a lot of increased opportunities to consider the MQ Appliance as the right deployment option. After all many customers who review it with regards to overall costs find it has the lowest Total Cost of Ownership, as well as outstanding reliability.

Advertisements

The rewards of patience – IBM MQ V8 for HPE NonStop

July 4, 2017

Rewards of Patience

Time can be subjective and objective. Subjective time is referenced by the frame of the observer. A period of a few seconds can seem very short, or incredibly long. Putting your hand on a hot surface teaches you a second can seem a long time. Yet reading the book by Penfolds winery “The Rewards of Patience” can make you understand that 10 years can be no time at all.

How then should we measure the time it takes to release a new version of an enterprise software product where it might be used for a decade or more without change. For at the heart of key parts of the world’s infrastructure are systems that run HPE’s NonStop Server platform, and on those systems they also use IBM’s MQ software. These systems are very stable and it is a testament to that longevity that the last time that IBM released a new version of MQ on this platform was in 2006.

However, just as a good wine ages until it is ready to enjoy, so the time has now been reached for a new version of IBM MQ to be available on the HPE NonStop platform as promised in a previous Statement of Direction. This announcement on June 20th 2017 of IBM MQ V8 for HPE NonStop comes at a time when customers using the HPE NonStop platform are looking at new hardware such as the new x86 based machines now available to support the platform. The new version of IBM MQ supports both the x86 and Itanium platforms, giving customers a choice of deployment with the same function on each.

Existing customers of the prior version of MQ on the HPE NonStop platform who have been paying S&S will be entitled to move to the latest version. Customers should be careful in assessing the number of PVUs of the system they are deploying on as the x86 based NS7 machines in the HPE NonStop line are rated at 120 PVUs per core, rather than 100 PVUs per core.

As mentioned in the announcement letter there are no immediate plans to announce End of Support for the MQ V5.3.1 offering on this platform until functional equivalence is reached. Expect further updates to allow this to be achieved. Please read the announcement letter linked above to understand what has been delivered in this version to date.

An additional blog is available on DeveloperWorks.

Setting out markers for MQ’s road ahead

February 16, 2016

2016-road-ahead

Working as the Offering Manager for IBM MQ and the IBM Messaging Portfolio, there are lots of parts of my day-to-day work that I can’t share on here until we announce it. However there are times when we can provide a small look ahead at what’s coming. This is called in IBM a “Statement of Direction”. And today IBM MQ has released a Statement of Direction for both IBM MQ and for the IBM MQ Appliance.

You can read the Statement of Direction here.
As you will see in reading it we are talking about a couple of important points. I will deal with the MQ Appliance statement first. As covered elsewhere in this blog, there has been a lot of interest in the MQ Appliance since we announced it at IBM InterConnect 2015 – just about 1 year ago. One of its key features has been about the High Availability function – the simple way to connect up two appliances and to allow for seamless 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, which could be deployed further away, offering Disaster Recovery. However, deployments needed to choose either one style of replication or another, on a Queue Manager by Queue Manager basis. So a Queue Manager on a MQ Appliance could be defined for High Availability, or for Disaster Recovery, but not both.
This created an obvious question when we discussed this with customers, who in some cases would want to have local MQ Appliances offering High Availability, but in the case of a whole site failure, wanted to then offer Disaster Recovery off-site. As giving forward looking statements can be an issue without legal clearance, we have ensured that with this Statement of Direction we can clearly state and assure customers that IBM indeed does intend to support the ability of Queue Managers to be configured for both High Availability and Disaster Recovery in a future update.

DR-phase2

For MQ itself the Statement of Direction covers less function, and more the delivery and support approach used for MQ itself. For many years IBM has released updates to IBM MQ every 2-3 years as major new versions, and sometimes with additional interim updates as incremental releases. But over the last few years IBM has been adding function into the regular fixpack deliverables where we also include maintenance updates alongside the new function.
While this approach allows IBM to add useful new functions between releases, and thus getting it to customers earlier, it can lead some customers to choose to keep their MQ implementations on older releases until IBM stops adding new function to that particular release. The concern is that adding new function in a release that will be used in production can create the need to have a major new testing cycle, even if IBM has designed that the new function is off by default.
As IBM thinks customers would benefit from being at the latest level of code, and certainly IBM wants to encourage customers to stay up to date with the latest fixpacks, IBM has decided to offer two separate code delivery and support options.

One option will be the Long Term Support Stream. A new version of MQ will be released, and from that point on, there will be no new function shipped on that code-stream. The fixpacks that IBM will continue to ship on a regular basis will only contain fixes to existing functions and no new functions will be added. As such it should be simpler and safer for customers to move more rapidly to this level of code and to then stay on it as fixes are rolled out, improving stability and performance.
The second option will be the Continuous Delivery option. Based off the same original code drop as the Long Term Support option, subsequent updates will be delivered containing not just fixes but also incremental new function. Each mod-level update will be designed to continue to add new function. And, important to understand, customers who choose to deploy the Continuous Delivery stream will have to keep taking the additional functional increments and fixes if they want to stay on that stream by moving to the most recent mod-level. If they decide they want to be on the Long Term Support stream then will need to change the MQ installed which will likely cause a degree of disruption as they will effectively be moving to a different release. While this continuous delivery of function will ensure that customers of MQ will have new functions that enhance MQ and the operation of their environment, those customers will need to be able to continue to update their environment with each update as it is delivered. For many customers this might be appropriate as they have a need for the new function or they may want to apply it only to a particular environment and set of applications.

LTS

After a number of functional updates to the Continuous Delivery Stream of IBM MQ, over probably a period of 2 years or so, it is expected that the incremental set of new functions delivered in the Continuous Delivery Stream will be released as the new starting point for the next version of the Long Term Support stream, and will reset the version for the Continuous Delivery Stream as well. The cycle them will repeat again, with fixes applied to the Long Term Support Stream and new mod-level updates with new function (as well as fixes) delivered to the Continuous Delivery Stream.

This new approach for delivering MQ may be significantly important for some customers as they make future plans, and IBM therefore thought it was important to set this out in a Statement of Direction prior to a future announcement of a new release of IBM MQ supporting this model.

As for when any new releases to backup these Statements of Direction are coming out? Well, keep watching this space.