Hard though it is to believe, it’s now coming up to 4 years since we announced the first model of the MQ Appliance (M2000).

In that time, a huge amount has changed. We’ve had two hardware refreshes, massive usability improvements and performance gains, added support for asynchronous DR and more complex HA/DR configurations, and delivered loads of extra features in areas like monitoring and remote management (many in direct response to customer RFEs.) And it goes without saying that some things have stayed the same: such as our central aim to provide an easy to consume, reliable messaging infrastructure for your applications. Whenever possible, we want to take away the hassle of thinking about the underlying hardware and system maintenance day-to-day.

In the last few months we have delivered the M2002 hardware update and our Long Term Support (LTS) 9.1 firmware release. Since then we’ve received a number of queries from customers interested in how to plan for migration from existing appliances to the newer hardware models. In response, we’ve recently overhauled the ‘Upgrading’ section of the Knowledge Center to give more guidance and best practice on this topic.

There are always many possible approaches to migration planning, and the appliance is no exception. In the expanded documentation you will therefore find a number of these approaches outlined. We have tried to make clear the pros and cons of these different methods and the preferred ‘default’ option.

Do follow the link for more details, but in summary we suggest a simple 3 step approach to migrating queue managers:

  • Configure your new hardware.
  • Migrate queue managers one at a time using ‘mqbackup’ and ‘mqrestore’ (independently and at appropriate time for your applications).
  • Re-deploy each queue manager’s HA and DR configuration (if applicable) in the new environment.

The eagle-eyed will be thinking that there is a major drawback in this strategy… It does require a period of outage for an individual queue manager as it is migrated. We believe that in most cases the simplicity and lack of ‘room for error’ still make this the best approach if possible. In circumstances where that cannot be considered you should of course consult the more advanced migration scenarios. There you’ll find advice on maximising queue manager uptime using the HA/DR facilities to assist the migration process.

Whatever approach you choose, we always recommend planning and documenting the specific steps you will be taking in your environment thoroughly in advance. We hope this provides useful guidance for that process – as always let us know through the Knowledge Center comments form (or any other contact routes) if you feel there are areas of the documentation we can improve.

Join The Discussion

Your email address will not be published.