Posts Tagged ‘Long Term Support’

All aboard the 9.1.x CD train. First stop is IBM MQ V9.1.1.

November 27, 2018

steam-train-north-shore-scenic-railroad-two-harbors-minnesota-17-9-00159

I am sure everyone knows the phrase about buses. If you miss one, don’t worry. There’ll be another one along in a minute. And while it could be said that applies to Continuous Delivery releases, I think it is more like getting on board a train. The destination is the next Long Term Support release, and you think you know what stops will be coming up. But maybe you don’t know exactly what you will find at each destination. You know there will be something new to discover at each stop. You could almost think of the train growing at each stop with the content of each new continuous delivery release, ready to be delivered finally to the Long Term Support destination.

 

Which brings us to the latest MQ CD release, MQ V9.1.1, announcing today, which is the first CD release in the 9.1.x set of releases. The experience we have of our 9.0.x CD releases is that we have seen a lot of interest from customers. Some have been able to move quickly to take up the CD stream into their environments and run them in production, at least for some of their queue managers. Others have been able to experiment with the new features in their test environments to see whether it is worth their while adopting the content early. And there seems to be a larger set of users who, while they haven’t been adopting the CD content into the production systems, the earlier availability and visibility of the new content has helped them move much more rapidly to adoption and use of the MQ V9.1 LTS release than we might have previously expected. I have personally talked with a lot of existing MQ customers who have either already started using MQ V9.1 LTS or are planning to move to use it very shortly.

Screenshot 2018-11-27 at 08.47.09

The MQ V9.1.1 release isn’t a destination in itself. It is the first part of our continuing journey. The MQ team works to accommodate a mix of strategic development priorities into releases to move the MQ offering forward, as well as other customer driven priorities, and reacting to and supporting other offerings and platforms as they change and adapt. Let’s find out how this mix has shaped the release. As well as suggesting you read the announcement content in the announcement letter, I will call out a few of the interesting new features.

 

One important new set of capabilities, driven by customer requests, is around the choice and negotiation of the use of TLS ciphers. Security of the MQ environment is hugely important in the current environment and is likely to remain a key area of focus. The importance of security and data protection is one reason customers are moving to MQ Advanced or MQ Appliance as a way to get the end to end encryption in MQ AMS. But this release focusing on enhancement to the security used in the TLS ciphers – used for encryption on the wire, not encryption at rest. As time passes, some ciphers become less secure and customers need to take prompt action in their environments to ensure the ciphers they use are updated to meet their own business requirements as well as the needs of the different systems.

In MQ v9.1.1 the choice of ciphers can be negotiated dynamically from a set or ‘whitelist’ available on each MQ channel. This reduces the potential for downtime and administrative overhead through faster movement to new ciphers when an old cipher is deprecated. Weaker ciphers can be removed from the list of allowable ciphers without needing to wait for a security fix update from IBM.

 

Another update driven by customer requests is the new support in MQ V9.1.1 for .NET Core for Windows. Customers who choose .NET as a framework for running applications on Windows environments have been looking to move to .NET Core. Following a number of requests, we have now added support for .NET Core for Windows environments to help support those customers.

 

As we have seen in the 9.0.x CD stream, one of the important set of capabilities that was added was the REST API for Admin for MQ. And at the end of that set of releases we started to look at adding REST API calls for the administration of MQ Managed File Transfer features, available with MQ Advanced and MQ Appliance. Many customers find it value to ingest and move data through MQ, even when the starting point or destination for this data is a file on the file system. To MQ, it is all just data moving in MQ messages. Therefore, from an administration point of view, it is important to offer similar features and controls for managing the movement of this data through MQ as is available for MQ exchanges of application data. In MQ V9.1.1 the MQ MFT feature gains REST API calls to list the resource monitors as an alternative to previous methods.

 

A further update is to provide support for pausing message delivery to Message Driven Beans running in WebSphere Liberty, in addition to the support previously made available for WebSphere Application Server.

 

The MQ V9.1.1 release offers a good foundation to start the journey through the various 9.1.x CD releases. There was a mix of updates driven by customer needs, wider platform and offering support as well as some functions to enhance longer term MQ strategic plans. We are now pulling out of this station and heading to the next one. Hitch up the V9.1.1 wagon to your V9.1 MQ train, hop on board and enjoy the ride.

glacier-express-furka-pass

Ensuring your business and customers see you as Highly Available thanks to MQ Advanced

July 19, 2018

Screen Shot 2018-07-19 at 15.24.18

How high is high? If you are considering climbing, then Everest is pretty high after all at 8848M above sea level. Although without the right equipment, team and preparation, trying to climb just 2M can be impossible. But ‘high’ is used in other contexts as well. Like when you are trying to keep a business running these days. If you are then it’s likely the high you may be thinking about is High Availability. Without the right approach, tools and infrastructure you may be trying to solve a problem that can seem to be the same scale as Everest.

Screen Shot 2018-07-19 at 15.48.09

With business becoming more global, and being more responsive to events, and with mobile or web traffic coming direct from partners, customers or suppliers, downtime has to be avoided. How do you keep your systems up, your applications running and your data available all the time? Even when, inevitably, there are failures?

Screen Shot 2018-07-19 at 15.48.23

IBM MQ is a critical part of your business connectivity. It provides a reliable, secure, scalable and robust middleware layer connecting applications, systems and services and exchanging data between them. Making use of IBM MQ ensures your applications can be simpler and more agile, yet more reliable, and also easier to shift between deployment environments. Your applications will rely on IBM MQ persisting their messages, ensuring that messages are never lost. How do you reap these rewards of simpler applications unless the MQ middleware is highly available to ensure the applications can keep running?

 

Having been around for 25 years, IBM MQ understands this need very well. As such it provides a variety of ways to configure and manage High Availability. And the most recent innovation, based on the High Availability approach used in the MQ Appliance is designed to not only offer extremely robust and effective high availability, but at the same time ensuring it is simple to set up and maintain, without additional external complexity: Replicated Data Queue Managers.

 

Many clients were facing the same set of problems: they didn’t like the costs and complexity of providing and maintaining network attached storage, which was a common way of providing high availability for MQ. The request was high availability that was more self-contained, without external dependencies. A way to deploy MQ in highly available configurations without the requirement for an environment that needs lots of setup, with highly skilled resources and additional costs.

RDQM1

With IBM MQ V9.1, our new Long-Term Support release, customers can now take advantage of Replicated Data Queue Managers, which offer a 3-node configuration, making use of replicated local storage, which make the MQ messages available on each of 3 MQ systems, instead of relying on a single copy of data on network storage.

 

Instead of requiring lots of setup, and ongoing extensive maintenance, MQ itself will do almost all the setup during the initial MQ install. Then, when you are creating a Queue Manager, you simply request it as a RDQM resource, and that’s pretty much all that’s needed. And it’s not just simple in the configuration of the Queue Managers. As it supports Floating IP, when one Queue Manager fails, and another instance automatically starts up on one of the other 2 nodes, the original Queue Manager IP address will move with it, meaning the applications are essentially unaware of the move, and the workload is uninterrupted as the messages and logs had been kept up to date synchronously on all 3 systems.

 

With an additional option allowing for manual startup in a replicated pair of systems by choosing either synchronous or asynchronous replication to provide Disaster Recovery configurations, this new approach to HA really goes a long way to make it much simpler to reach the highest peaks of high availability.

 

There are already a few places to look for more information on this exciting new development. There is a technical blog entry by John Colgrave, along with a GitHub community, and of course the Knowledge Center.

 

Suitable for customers on RedHat Linux on the x86 platform, you need MQ Advanced licensing on just one system node, and MQ Advanced High Availability Replica licensing on the other 2 nodes. Also, this can’t be used with container deployments – but virtual machine images or bare metal is fine. With RDQM now part of the Long-Term Support release of MQ V9.1, you can scale the highest peaks of availability. You are not starting at base camp. You are already close to the summit. Let’s get to the top.

everest-guide

 

When 9.1 + 3 equals 2002 – the new MQ Appliance M2002 with MQ V9.1

July 3, 2018

Screen Shot 2018-07-03 at 10.05.08

Children seem to grow up so fast. One day they are new to us, and exploring what they can do, but very quickly they grow up, learn new skills and impress us with their capabilities.

 

For the MQ Appliance it was first released just 3 years ago, as the MQ Appliance M2000. Then 1 year later there was a minor update, released as the M2001 providing bigger, faster SSD storage and more 10Gb networking. Now, stepping out confidently into the world is the 3rd generation of MQ Appliance – the new model M2002, coming out along with the new MQ V9.1 software. Read the announcement letter here.

 

So, what do you need to know about the new model? Many of the benefits are the same. It still is very simple and rapid to deploy and get running. And applying maintenance is also straightforward as a single flash image. And it is still MQ Advanced in a box, with the major benefits of MQ Advanced such as unlimited free connectivity to MFT Agents, end to end message level encryption and access to the Blockchain Bridge. But the M2002 model provides some significant hardware improvements that also lead to pretty outstanding performance improvements.

M2002performance

There are now 24 cores (Intel Skylake architecture with hyperthreading). The storage has expanded with now 4 SSDs, each with 3.2TB capacity. They are now making use of RAID 10, with a doubled RAID cache. And networking has been increased with there now being 6 of the 10Gb network ports. Plus, there are now 40Gb ports – there are 2 pairs of ports, with each pair being able to provide 40Gb in total.

Screen Shot 2018-07-03 at 10.07.22

There are still 2 models available – the M2002A and the M2002B. As before the ‘A’ model provides access to the full capacity of the Appliance, including all cores and all storage (about 6TB of usable storage). The M2002B model had access to 6 cores, and access to half of the storage capacity (about 3TB). As before there is an additional capacity option to enable the conversion of the M2002B to the M2002A without any hardware changes or modifications.

 

The combination of the additional number of SSDs and the change to RAID 10 with an increased cache, plus the increased, faster networking means that operational performance can be dramatically increased. Particularly with HA connectivity being able to use the 40Gb networking to reduce latency of the synchronous replication, increased workload can be driven through the appliances at very high rates. Due to various other improvements in MQ V9.1, even customers with the M2001 appliances will see performance boosts.

 

The 40Gb networking ports can be used individually or aggregated together, and while many businesses will yet to have 40Gb networks, if MQ Appliances are in the same rack, they can be cabled directly together.

 

With link aggregation now supported for the 10 Gb network ports, and with 6 of them now provided, the connectivity is far more resilient than before.

 

In another important change, with MQ V9.1’s release, the MQ Appliance will now move to the same mix of Long Term Support and Continuous Delivery releases that have been available for MQ software delivery. MQ V9.1 itself is a Long Term Support release, so MQ Appliance customers will be able to put that into production with stability assured and only fixes in fixpacks, but then subsequent Continuous Delivery updates with additional features will be available, with customers being able to choose to deploy one or other releases on each MQ Appliance.

 

The M2002 models will only be able to have MQ V9.1 or later releases. MQ V9.1 can be installed on all MQ Appliance models, including the M2000 and M2001. With the release of the M2002, the M2001 will be withdrawn from marketing, and the end of support date will be set at 10 July 2023, so that even customers buying the last of the M2001s will get 5 years of regular support. You can read the withdrawal announcement letter here.

 

Another point to note is that the M2002 does not include the Host Bus Adapter that was used in the previous model to provide SAN connectivity. Based on customer feedback, this is no longer viewed as strategic, and will not be progressed any further.

 

The new M2002 Appliances, the 3rd generation of appliances, will be available later in July, and as before with the previous models of MQ Appliances, will connect easily and seamlessly into existing MQ environments, or be a great way to start out a MQ deployment.

Everyone gets the point. MQ V9.1 delivers the latest features in a Long Term Support release.

July 3, 2018

Screen Shot 2018-07-03 at 09.42.14They say anticipation is half the fun. And one of the good things about the split release approach for MQ with Continuous Delivery releases and Long Term Support Releases is that as new function is developed and made available in the CD stream, customers intending to use the LTS release can build their anticipation for the new function for up to 2 years.

 

Of course, there is nothing to stop early experimentation with the CD releases even though you may be waiting for the LTS availability. But the good news is that the wait is now over and IBM has published the announcement letter for MQ V9.1 and MQ Advanced on distributed platforms here. Also MQ V9.1 is being announced for the MQ Appliance, as well as a new model of the MQ Appliance – the M2002. You can read that announcement letter here, and a blog about it here. Also we have announced MQ V9.1 for z/OS – there is an announcement letter here for the MLC offering, and another announcement letter for MQ Advanced for z/OS VUE and other z/OS OTC offerings here.

 

Has it been worth the wait? What has been the most anticipated new capability? It’s not like a Christmas present where you are not sure what’s under the tree. Almost every feature, function and enhancement in MQ V9.1 has been already available in one of the CD releases, so there shouldn’t be much of a surprise. You can read some of my past blog entries covering the prior V9.0.x releases (V9.0.1, V9.0.2, V9.0.3, V9.0.4, and V9.0.5)

 

And don’t forget than the previous LTS release – MQ V9.0 included important updates that have proved very useful such as the enhancements to MQ AMS providing end to end encryption, including encryption at rest without performance impacts, which can be very helpful in addressing GDPR requirements.

 

However, let’s cover here some of the most interesting areas of focus over the last couple of years of function, and which ones seem to have attracted the most customer interest.

 

There are many different areas of enhancement, which hopefully means pretty much all users have something to interest them.

Screen Shot 2018-07-03 at 09.52.28

Simple and more powerful Administration

  • MQ Console – a customized browser based for configuration and operations
  • REST API for admin – an extensive set of APIs enabling new tools to be written using REST HTTP calls, usable across older releases as well
  • Improved awareness of MQ activities and logging – Publishing MQ statistics to Prometheus and Grafana; forwarding MQ error logs to ElasticSearch or Splunk; Error logs output JSON for improved parsing
  • Automation of Linear Logging – simplifying the operations and administration of logging and management of those logs.

 

Supporting Developers

  • REST API for messaging – Enabling developers writing simple applications and micro-services to access MQ capabilities.
  • Additional API and protocol support – as well as publishing a new online tutorial for using MQ
  • Connecting to Salesforce – the MQ bridge to Salesforce allows for the 2 way publishing of information between SalesForce and MQ
  • The MQ Bridge to blockchain – only available for MQ Advanced or MQ Appliance customers.

RDQM1

High Availability and Disaster Recovery without complexity and cost

  • Replicated Data Queue Managers for HA – synchronous replication across 3 nodes using local disks instead of network attached storage.
  • Replicated Data Queue Managers for DR – manual failover with synchronous or asynchronous replication across 2 nodes.
  • RDQM requires MQ Advanced licenses. But with specific licenses to reduce cost.

 

Managed File Transfers

  • Licensing, packaging and pricing changes. MFT Agents are now free with MQ Advanced or MQ Appliance, and both embeddable and redistributable.
  • FTP Protocol Bridge enhancements
  • Improved reliability and monitoring for Transfers

 

 

z/OS enhancements

Many of the updates described above also apply to MQ on z/OS. There are also some additional enhancements specific to z/OS

  • AMS Confidentiality Performance. MQ Advanced for z/OS VUE sees enhancements in performance of this feature in MQ V9.1
  • Extended deployment for MFT – with MQ Advanced for z/OS VUE.
  • The MQ Bridge for blockchain now using the Hyperledger Composer API to build out the connectivity.
  • Connecting CICS and MQ – Java programs running on a CICS Liberty JVM server can now use MQ classes for JMS to access MQ capabilities.

 

AS MQ now moves to MQ 9.1, this time the point is available for everyone. All the features above, and more I haven’t had a chance to describe will be available later in July 2018. Whether deploying in on-premises environments, on physical Appliances, on VMs, in containers, on private clouds like IBM Cloud Private, or public clouds like IBM Cloud, AWS, or Azure, the Long Term Support release now means the 2 years of functional enhancements, tested already in multiple Continuous Delivery releases are now available for more to use.

UPDATE: MQ V9.1 now available as of July 23rd 2018. Read more here.

And there is plenty more to come. Watch this space both for more updates and use cases of these features, and well as future updates in the next Continuous Delivery releases.

Putting out a new release like IBM MQ V9.0.5 is more than a 9-5 job

March 16, 2018

9-5clocks

At least in the UK, the traditional hours worked in a day job were 9 to 5. You would ‘clock-in’ at 9am and leave at 5pm. I guess it is common as there was a 1980s film called “9 to 5” starring Dolly Parton. These days office life is rather more flexible, and certainly the idea of clocking in and out at fixed times is gone.

 

For 25 years, virtually every major IT infrastructure has been able to rely on the secure and reliable exchange of data between applications and systems thanks to IBM MQ. Previously called MQSeries, then WebSphere MQ, this software offering, developed in the IBM Hursley Lab in the UK has been a critical part of the business world. So much so that most people living their lives have no idea they use IBM MQ so much on a daily basis as it ‘just works’.

 

There is a great team of developers who work hard day-in and day-out to enhance and update IBM MQ, and . We have now released IBM MQ V9.0.5, going GA on Friday March 16th. And our developers have worked for months, giving up evenings and weekends to not just add new features, but to make sure it is another offering that works when put into use. So not 9-5 at all.

 

Now for some customers this will be more of a prelude to the main act. This is referring to V9.0.5 being a Continuous Delivery release. When we brought out V9.0 we split it into 2 streams: Continuous Delivery and Long Term Support. This release marks the final release in the initial set of Continuous Delivery releases. The next release will be the first of a new Long Term Support release. And customers can expect that the functions delivered in the 5 CD releases will be made available in the new Long Term Support release.

 

When that new LTS release is available, you can expect me to summarize all the new features, but for now in this blog I will call out a few of the new features in V9.0.5.

 

The new Easy HA feature (Replicated Data Queue Managers) delivered in MQ Advanced V9.0.4 gets updated to add support for a Disaster Recovery mode, with manual takeover after either synchronous, or asynchronous replication between a pair of MQ servers.

 

The MQ Managed File Transfer capability, available with MQ Advanced or MQ Appliance gets the first support for the REST API admin interface for listing current transfers and querying MFT Agent status.

 

MQ Advanced itself will do more to identify itself when it is installed, and so prevent compliance issues, and ensures that components can recognize Queue Managers.

 

Other updates include a MQ Console refresh, and for customers who use MQ with WebSphere Application Server, performance enhancement through implicit syncpointing.

 

For MQ Appliance users there is an enhancement for better reliability by allowing aggregated IP interfaces for the Floating IP feature. This removes a potential single point of failure.

 

And for users of MQ Advanced for z/OS Value Unit Edition there have been improvements including enhancements to MQ AMS which will see increased performance.

MQ clouds puttenham

Perhaps even more exciting is the new availability of a hosted instance of MQ on the Cloud. More about this can be found here, but it creates a great opportunity to quickly and easily make use of MQ without needing to install, deploy or manage the environment. Just configure and go! Nice that after 5 years of talking about it on this blog we have an explicit offering running in the cloud. This is of course alongside MQ already being able to run in AWS as a QuickStart. Or deployed as containers in IBM Cloud private.

 

As well as looking forward in the future to a new Long Term Support release, the statement of direction indicated that the Blockchain bridge, available in MQ Advanced, will be updated to be based on the Hyperledger Composer interfaces. And additionally, customers deploying MQ in containers will in the future be able to track the size of the container, and the duration of use, and license based on that container size, rather than the full capacity of the system where the container is running. The intent will be to support existing pricing metrics such as PVUs and VPC monthly metrics, but also a future VPC Hourly metric.

ibmthink

IBM MQ, along with many other IBM and business partner solutions will be some of the highlights discussed at IBM Think in Las Vegas running March 19th-22nd. I will be there and I hope to see some of you there as well. Famously Las Vegas never sleeps, so I guess that’s something else that’s not 9 to 5. Lucky we have IBM MQ V9.0.5 now though.

9to5dolly

 

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.