MQ

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Hi John,

I think you are missing the target on a couple of things, which might change your mind about what might provide the best option for implementing HA and DR in your cloud environment.

I tend to agree with you on MIQM disk issues. MIQM shifts the availability problem from the queue manager/QM server to the storage/storage server. Finding a storage implementation that meets your performance and availability needs can be very difficult.

Native HA is as you say currently only supported on OpenShift. This is available as part of CP4I so you don't need to manage it separately, but if it's a new technology to your environment and you don't plan on using it for more the just MQ, then the infrastructure overheads may overkill for you.

I would disagree on the production readiness of a CD though. Especially in a cloud environment where automated CI/CD pipelines and comprehensive automated regression testing are both possible, the short (12 month or so) lifetime of a CD release doesn't have to be a barrier to production implementation. Code quality is not compromised by the support and delivery changes between CD and LTS in my experience, and IBM tell you when a CD feature isn't ready for production yet (Native HA in 9.2.2 for example).

As to container suitability for MQ, IBM have done a lot of work to ensure that MQ runs well in containers and is indeed suitable. Elasticity is not the only objective of containerisation. Reliable tested software stacks that are independent for each container in your environment can also dramatically reduce the difficulty in things like security patching. The container is also much lighter weight that a full VM. MQ can run easily on as little as 0.05 cores (50 millicores) and I've seen it demonstrated on 20 millicores (although startup was a bit slow). It's also much easier to pick up a container and deploy it somewhere else (like another availability zone) than to rebuild a VM.

Your comment about RDQM requiring RedHat OpenShift isn't quite right. It does require RHEL, but not OpenShift. It is deployed to a cluster (of 3) RHEL servers, not OpenShift containers. In the Azure space, you would need to deploy 3 RDQM servers onto RHEL instances as VMs I believe, although I haven't checked exactly what's in the Azure catalog. For DR, you need another 3 servers.

I think for many organisations containers are here already. There are other organisations that aren't ready for containers, but containers are probably ready for them.

I definitely wouldn't be building my own containers for MQ as a starting point. IBM have already done a huge amount of work and provide a supported container.

I agree that RDQM provides HA and DR, and is great, and doesn't rely on complex shared disk, but you CAN'T put it in a container. RDQM uses kernel modules that are NOT available in a container.

One of the biggest differences between RDQM and Native HA is that they don't use the same replication technology, which is why Native HA runs in containers, and RDQM doesn't. Native HA performs its own replication of the MQ log, and does its own management of the log state, rebuilds and working out what needs to be active where. In RDQM, all of that is offloaded from MQ onto the DRBD and Pacemaker components which are root or kernel level components outside of MQ itself. In Native HA, all of that is moved inside the queue manager.

Native HA also reduces the replication load by only replicating log writes, not all writes to either the log or queue files.

As to DR, you are right at the moment. The 9.2.3 implementation of Native HA doesn't provide DR. You may be able to use a replicated disk technology though to make your data available outside the availability zone, and implement your own DR on top of that. NOTE: This is entirely supposition as I haven't tried it. It would also have performance implications as it would increase the latency of the disk writes.

So, the bottom line...
I don't think you have all your facts quite right, but you are pretty close to the mark with your conclusion. If you want both HA and DR, then RDQM is more capable in that area than Native HA. If you are running OpenShift, then either MIQM or Native HA might do the job for you, depending on what disk technology you have access to, and whether DR is needed.

All the best

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
------------------------------

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Thanks for this Neil,

re native HA: If a company doesn't use Openshift then this tech is out of the window - Skills and paradigms are too big a leap for my liking. Although, IBM seems to sell everything as part of a cloud pak nowadays so I doubt think Licencing would be an issue ;-)

I don't think that the MQ provided containers are supported on anything other than openshift?:

You can run IBM MQ using the IBM MQ Operator on Red Hat® OpenShift®. This can be done using IBM Cloud Pak® for Integration, IBM MQ Advanced or IBM MQ Advanced for Developers.

You can also run IBM MQ in a container you build yourself.

Thus, making them inaccessible (at the moment) to many environments/customers. I'm also not quite sure what "supported" means in that case - If I use those containers  on another environment am I supported for MQ but not any of the HA support? If I create my own container what am I supported for?? MQ only I guess, as IBM would probably use the old adage of "if you can create the problem outside the container we'll support you" (as they used to do with VMs)?

re DR in containers. If MQ does only support IBM container environments then I'm on my own there too.

I take your point about containers and security - I often forget that this is a benefit  and, IMO, the most important single benefit. But, I can see that the other smaller wins combine to a whole.

re RDQM requiring Openshift - that was a typo on my behalf - sorry !
re CD: Yep, was only talking about Native MQ support not being prod ready. However, I do question what the percentage of customers are who actually deploy CD to prod !? That's a hell of a lot of work every couple of months to upgrade to a supported version.

So, the conclusion is still clear to me - RDQM is the only supported option that is clearly supported on Azure by IBM and has clear DR capabilities. And, it doesn't rely on IBM container platform.

btw: I just did a *very* quick calculation and get the impression that containers on Azure would be very cheap versus VMs but the openshift service is the same/more expensive than VMs - but that was a *very* quick look - I'd be interested to know what others have found in reality?

thanks for the conversation - just what I was looking for :-)
John.






------------------------------
John Hawkins
Integration Consultant
------------------------------

Original Message:
Sent: Mon August 09, 2021 02:05 AM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I think you are missing the target on a couple of things, which might change your mind about what might provide the best option for implementing HA and DR in your cloud environment.

I tend to agree with you on MIQM disk issues. MIQM shifts the availability problem from the queue manager/QM server to the storage/storage server. Finding a storage implementation that meets your performance and availability needs can be very difficult.

Native HA is as you say currently only supported on OpenShift. This is available as part of CP4I so you don't need to manage it separately, but if it's a new technology to your environment and you don't plan on using it for more the just MQ, then the infrastructure overheads may overkill for you.

I would disagree on the production readiness of a CD though. Especially in a cloud environment where automated CI/CD pipelines and comprehensive automated regression testing are both possible, the short (12 month or so) lifetime of a CD release doesn't have to be a barrier to production implementation. Code quality is not compromised by the support and delivery changes between CD and LTS in my experience, and IBM tell you when a CD feature isn't ready for production yet (Native HA in 9.2.2 for example).

As to container suitability for MQ, IBM have done a lot of work to ensure that MQ runs well in containers and is indeed suitable. Elasticity is not the only objective of containerisation. Reliable tested software stacks that are independent for each container in your environment can also dramatically reduce the difficulty in things like security patching. The container is also much lighter weight that a full VM. MQ can run easily on as little as 0.05 cores (50 millicores) and I've seen it demonstrated on 20 millicores (although startup was a bit slow). It's also much easier to pick up a container and deploy it somewhere else (like another availability zone) than to rebuild a VM.

Your comment about RDQM requiring RedHat OpenShift isn't quite right. It does require RHEL, but not OpenShift. It is deployed to a cluster (of 3) RHEL servers, not OpenShift containers. In the Azure space, you would need to deploy 3 RDQM servers onto RHEL instances as VMs I believe, although I haven't checked exactly what's in the Azure catalog. For DR, you need another 3 servers.

I think for many organisations containers are here already. There are other organisations that aren't ready for containers, but containers are probably ready for them.

I definitely wouldn't be building my own containers for MQ as a starting point. IBM have already done a huge amount of work and provide a supported container.

I agree that RDQM provides HA and DR, and is great, and doesn't rely on complex shared disk, but you CAN'T put it in a container. RDQM uses kernel modules that are NOT available in a container.

One of the biggest differences between RDQM and Native HA is that they don't use the same replication technology, which is why Native HA runs in containers, and RDQM doesn't. Native HA performs its own replication of the MQ log, and does its own management of the log state, rebuilds and working out what needs to be active where. In RDQM, all of that is offloaded from MQ onto the DRBD and Pacemaker components which are root or kernel level components outside of MQ itself. In Native HA, all of that is moved inside the queue manager.

Native HA also reduces the replication load by only replicating log writes, not all writes to either the log or queue files.

As to DR, you are right at the moment. The 9.2.3 implementation of Native HA doesn't provide DR. You may be able to use a replicated disk technology though to make your data available outside the availability zone, and implement your own DR on top of that. NOTE: This is entirely supposition as I haven't tried it. It would also have performance implications as it would increase the latency of the disk writes.

So, the bottom line...
I don't think you have all your facts quite right, but you are pretty close to the mark with your conclusion. If you want both HA and DR, then RDQM is more capable in that area than Native HA. If you are running OpenShift, then either MIQM or Native HA might do the job for you, depending on what disk technology you have access to, and whether DR is needed.

All the best

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Hi John,

I'm always happy to have a conversation about MQ.

You're right about the IBM certified container. There have been changes that I didn't keep track of properly. When the switch was made from native kubernetes to OpenShift and Operators (v9.1.5 by the look of things), the independent certified container seems to have gone away. It looks like MQ 9.2.3 in containers is only delivered directly on OpenShift. For other container orchestration environments, it seems you do need to build your own container, which is a non-trivial task, even according to the IBM manuals.

Native HA went full GA with 9.2.3, so IBM are saying that it's ready for the big time (at least in my view). They addressed the missing features (like some of the resync scenarios) that made 9.2.2 a pre-release test only capability.

Keeping on a supported version using CDs isn't quite as hard as you make out though. Although the original CD support model was that only the latest CD (and n-1) were supported, the current CD support is for 12 months from GA release of the CD or 2 releases (whichever is longer). You don't have to take every CD to stay supported. See https://www.ibm.com/support/pages/ibm-mq-faq-long-term-support-and-continuous-delivery-releases.

Even going with RDQM, you may want to review the new capabilities that have been added in MQ 9.2.2 and MQ 9.2.3 which provide improved detection of RDQM cluster failures and an ability to recover from some failure scenarios using locally available information rather than needing to call IBM Support for assistance. See https://www.ibm.com/docs/en/ibm-mq/9.2?topic=wnim9-whats-new-in-mq-923-multiplatforms-advanced-entitlement-only and https://www.ibm.com/docs/en/ibm-mq/9.2?topic=922-whats-new-in-mq.

Good luck with your project.

Regards

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
------------------------------

Original Message:
Sent: Mon August 09, 2021 04:28 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Thanks for this Neil,

re native HA: If a company doesn't use Openshift then this tech is out of the window - Skills and paradigms are too big a leap for my liking. Although, IBM seems to sell everything as part of a cloud pak nowadays so I doubt think Licencing would be an issue ;-)

I don't think that the MQ provided containers are supported on anything other than openshift?:

You can run IBM MQ using the IBM MQ Operator on Red Hat® OpenShift®. This can be done using IBM Cloud Pak® for Integration, IBM MQ Advanced or IBM MQ Advanced for Developers.

You can also run IBM MQ in a container you build yourself.

Thus, making them inaccessible (at the moment) to many environments/customers. I'm also not quite sure what "supported" means in that case - If I use those containers  on another environment am I supported for MQ but not any of the HA support? If I create my own container what am I supported for?? MQ only I guess, as IBM would probably use the old adage of "if you can create the problem outside the container we'll support you" (as they used to do with VMs)?

re DR in containers. If MQ does only support IBM container environments then I'm on my own there too.

I take your point about containers and security - I often forget that this is a benefit  and, IMO, the most important single benefit. But, I can see that the other smaller wins combine to a whole.

re RDQM requiring Openshift - that was a typo on my behalf - sorry !
re CD: Yep, was only talking about Native MQ support not being prod ready. However, I do question what the percentage of customers are who actually deploy CD to prod !? That's a hell of a lot of work every couple of months to upgrade to a supported version.

So, the conclusion is still clear to me - RDQM is the only supported option that is clearly supported on Azure by IBM and has clear DR capabilities. And, it doesn't rely on IBM container platform.

btw: I just did a *very* quick calculation and get the impression that containers on Azure would be very cheap versus VMs but the openshift service is the same/more expensive than VMs - but that was a *very* quick look - I'd be interested to know what others have found in reality?

thanks for the conversation - just what I was looking for :-)
John.






------------------------------
John Hawkins
Integration Consultant

Original Message:
Sent: Mon August 09, 2021 02:05 AM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I think you are missing the target on a couple of things, which might change your mind about what might provide the best option for implementing HA and DR in your cloud environment.

I tend to agree with you on MIQM disk issues. MIQM shifts the availability problem from the queue manager/QM server to the storage/storage server. Finding a storage implementation that meets your performance and availability needs can be very difficult.

Native HA is as you say currently only supported on OpenShift. This is available as part of CP4I so you don't need to manage it separately, but if it's a new technology to your environment and you don't plan on using it for more the just MQ, then the infrastructure overheads may overkill for you.

I would disagree on the production readiness of a CD though. Especially in a cloud environment where automated CI/CD pipelines and comprehensive automated regression testing are both possible, the short (12 month or so) lifetime of a CD release doesn't have to be a barrier to production implementation. Code quality is not compromised by the support and delivery changes between CD and LTS in my experience, and IBM tell you when a CD feature isn't ready for production yet (Native HA in 9.2.2 for example).

As to container suitability for MQ, IBM have done a lot of work to ensure that MQ runs well in containers and is indeed suitable. Elasticity is not the only objective of containerisation. Reliable tested software stacks that are independent for each container in your environment can also dramatically reduce the difficulty in things like security patching. The container is also much lighter weight that a full VM. MQ can run easily on as little as 0.05 cores (50 millicores) and I've seen it demonstrated on 20 millicores (although startup was a bit slow). It's also much easier to pick up a container and deploy it somewhere else (like another availability zone) than to rebuild a VM.

Your comment about RDQM requiring RedHat OpenShift isn't quite right. It does require RHEL, but not OpenShift. It is deployed to a cluster (of 3) RHEL servers, not OpenShift containers. In the Azure space, you would need to deploy 3 RDQM servers onto RHEL instances as VMs I believe, although I haven't checked exactly what's in the Azure catalog. For DR, you need another 3 servers.

I think for many organisations containers are here already. There are other organisations that aren't ready for containers, but containers are probably ready for them.

I definitely wouldn't be building my own containers for MQ as a starting point. IBM have already done a huge amount of work and provide a supported container.

I agree that RDQM provides HA and DR, and is great, and doesn't rely on complex shared disk, but you CAN'T put it in a container. RDQM uses kernel modules that are NOT available in a container.

One of the biggest differences between RDQM and Native HA is that they don't use the same replication technology, which is why Native HA runs in containers, and RDQM doesn't. Native HA performs its own replication of the MQ log, and does its own management of the log state, rebuilds and working out what needs to be active where. In RDQM, all of that is offloaded from MQ onto the DRBD and Pacemaker components which are root or kernel level components outside of MQ itself. In Native HA, all of that is moved inside the queue manager.

Native HA also reduces the replication load by only replicating log writes, not all writes to either the log or queue files.

As to DR, you are right at the moment. The 9.2.3 implementation of Native HA doesn't provide DR. You may be able to use a replicated disk technology though to make your data available outside the availability zone, and implement your own DR on top of that. NOTE: This is entirely supposition as I haven't tried it. It would also have performance implications as it would increase the latency of the disk writes.

So, the bottom line...
I don't think you have all your facts quite right, but you are pretty close to the mark with your conclusion. If you want both HA and DR, then RDQM is more capable in that area than Native HA. If you are running OpenShift, then either MIQM or Native HA might do the job for you, depending on what disk technology you have access to, and whether DR is needed.

All the best

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Very interesting discussion. Just to add my two cents, building your own MQ container is not as difficult as one might think. IBM has provided excellent scripts (can be found from GitHub) that can be adapted to your needs. Anyways, the biggest benefit of using MQ containers for us has been the ability to migrate the workloads between private and public clouds with ease. Also patching, as Neil pointed out as an example, is a lot faster nowadays. 

What comes to HA, we are really hoping that IBM would provide the support for native HA (other than Openshift) in the upcoming releases. We are currently using multi-instance queue managers and have experienced a lot of stability issues due to various reasons. For example, the "unannounced" file storage maintenance breaks that take place in the public cloud are causing locking problems that obviously create issues to our MIMQ setup. OpenShift isn't an option for us either because everything else runs on native Kubernetes and setting up OpenShift just to get native HA up-and-running is a total overkill.

Hope this helps,

------------------------------
Hermanni Pernaa
------------------------------

Original Message:
Sent: Mon August 09, 2021 07:01 PM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I'm always happy to have a conversation about MQ.

You're right about the IBM certified container. There have been changes that I didn't keep track of properly. When the switch was made from native kubernetes to OpenShift and Operators (v9.1.5 by the look of things), the independent certified container seems to have gone away. It looks like MQ 9.2.3 in containers is only delivered directly on OpenShift. For other container orchestration environments, it seems you do need to build your own container, which is a non-trivial task, even according to the IBM manuals.

Native HA went full GA with 9.2.3, so IBM are saying that it's ready for the big time (at least in my view). They addressed the missing features (like some of the resync scenarios) that made 9.2.2 a pre-release test only capability.

Keeping on a supported version using CDs isn't quite as hard as you make out though. Although the original CD support model was that only the latest CD (and n-1) were supported, the current CD support is for 12 months from GA release of the CD or 2 releases (whichever is longer). You don't have to take every CD to stay supported. See https://www.ibm.com/support/pages/ibm-mq-faq-long-term-support-and-continuous-delivery-releases.

Even going with RDQM, you may want to review the new capabilities that have been added in MQ 9.2.2 and MQ 9.2.3 which provide improved detection of RDQM cluster failures and an ability to recover from some failure scenarios using locally available information rather than needing to call IBM Support for assistance. See https://www.ibm.com/docs/en/ibm-mq/9.2?topic=wnim9-whats-new-in-mq-923-multiplatforms-advanced-entitlement-only and https://www.ibm.com/docs/en/ibm-mq/9.2?topic=922-whats-new-in-mq.

Good luck with your project.

Regards

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Mon August 09, 2021 04:28 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Thanks for this Neil,

re native HA: If a company doesn't use Openshift then this tech is out of the window - Skills and paradigms are too big a leap for my liking. Although, IBM seems to sell everything as part of a cloud pak nowadays so I doubt think Licencing would be an issue ;-)

I don't think that the MQ provided containers are supported on anything other than openshift?:

You can run IBM MQ using the IBM MQ Operator on Red Hat® OpenShift®. This can be done using IBM Cloud Pak® for Integration, IBM MQ Advanced or IBM MQ Advanced for Developers.

You can also run IBM MQ in a container you build yourself.

Thus, making them inaccessible (at the moment) to many environments/customers. I'm also not quite sure what "supported" means in that case - If I use those containers  on another environment am I supported for MQ but not any of the HA support? If I create my own container what am I supported for?? MQ only I guess, as IBM would probably use the old adage of "if you can create the problem outside the container we'll support you" (as they used to do with VMs)?

re DR in containers. If MQ does only support IBM container environments then I'm on my own there too.

I take your point about containers and security - I often forget that this is a benefit  and, IMO, the most important single benefit. But, I can see that the other smaller wins combine to a whole.

re RDQM requiring Openshift - that was a typo on my behalf - sorry !
re CD: Yep, was only talking about Native MQ support not being prod ready. However, I do question what the percentage of customers are who actually deploy CD to prod !? That's a hell of a lot of work every couple of months to upgrade to a supported version.

So, the conclusion is still clear to me - RDQM is the only supported option that is clearly supported on Azure by IBM and has clear DR capabilities. And, it doesn't rely on IBM container platform.

btw: I just did a *very* quick calculation and get the impression that containers on Azure would be very cheap versus VMs but the openshift service is the same/more expensive than VMs - but that was a *very* quick look - I'd be interested to know what others have found in reality?

thanks for the conversation - just what I was looking for :-)
John.






------------------------------
John Hawkins
Integration Consultant

Original Message:
Sent: Mon August 09, 2021 02:05 AM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I think you are missing the target on a couple of things, which might change your mind about what might provide the best option for implementing HA and DR in your cloud environment.

I tend to agree with you on MIQM disk issues. MIQM shifts the availability problem from the queue manager/QM server to the storage/storage server. Finding a storage implementation that meets your performance and availability needs can be very difficult.

Native HA is as you say currently only supported on OpenShift. This is available as part of CP4I so you don't need to manage it separately, but if it's a new technology to your environment and you don't plan on using it for more the just MQ, then the infrastructure overheads may overkill for you.

I would disagree on the production readiness of a CD though. Especially in a cloud environment where automated CI/CD pipelines and comprehensive automated regression testing are both possible, the short (12 month or so) lifetime of a CD release doesn't have to be a barrier to production implementation. Code quality is not compromised by the support and delivery changes between CD and LTS in my experience, and IBM tell you when a CD feature isn't ready for production yet (Native HA in 9.2.2 for example).

As to container suitability for MQ, IBM have done a lot of work to ensure that MQ runs well in containers and is indeed suitable. Elasticity is not the only objective of containerisation. Reliable tested software stacks that are independent for each container in your environment can also dramatically reduce the difficulty in things like security patching. The container is also much lighter weight that a full VM. MQ can run easily on as little as 0.05 cores (50 millicores) and I've seen it demonstrated on 20 millicores (although startup was a bit slow). It's also much easier to pick up a container and deploy it somewhere else (like another availability zone) than to rebuild a VM.

Your comment about RDQM requiring RedHat OpenShift isn't quite right. It does require RHEL, but not OpenShift. It is deployed to a cluster (of 3) RHEL servers, not OpenShift containers. In the Azure space, you would need to deploy 3 RDQM servers onto RHEL instances as VMs I believe, although I haven't checked exactly what's in the Azure catalog. For DR, you need another 3 servers.

I think for many organisations containers are here already. There are other organisations that aren't ready for containers, but containers are probably ready for them.

I definitely wouldn't be building my own containers for MQ as a starting point. IBM have already done a huge amount of work and provide a supported container.

I agree that RDQM provides HA and DR, and is great, and doesn't rely on complex shared disk, but you CAN'T put it in a container. RDQM uses kernel modules that are NOT available in a container.

One of the biggest differences between RDQM and Native HA is that they don't use the same replication technology, which is why Native HA runs in containers, and RDQM doesn't. Native HA performs its own replication of the MQ log, and does its own management of the log state, rebuilds and working out what needs to be active where. In RDQM, all of that is offloaded from MQ onto the DRBD and Pacemaker components which are root or kernel level components outside of MQ itself. In Native HA, all of that is moved inside the queue manager.

Native HA also reduces the replication load by only replicating log writes, not all writes to either the log or queue files.

As to DR, you are right at the moment. The 9.2.3 implementation of Native HA doesn't provide DR. You may be able to use a replicated disk technology though to make your data available outside the availability zone, and implement your own DR on top of that. NOTE: This is entirely supposition as I haven't tried it. It would also have performance implications as it would increase the latency of the disk writes.

So, the bottom line...
I don't think you have all your facts quite right, but you are pretty close to the mark with your conclusion. If you want both HA and DR, then RDQM is more capable in that area than Native HA. If you are running OpenShift, then either MIQM or Native HA might do the job for you, depending on what disk technology you have access to, and whether DR is needed.

All the best

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Hi, if you have access to the IBM Cloud Container Registry (cp.icr.io) then the container image can be pulled directly.  You need to login with an entitlement key. Login: docker login cp.icr.io --username cp --password entitlement_key .  Then to pull (9.2.3.0-r1): docker pull


------------------------------
Brian S Paskin
Sr. WebSphere, Liberty and MQ Architecture
Cloud Automation
IBM Expert Labs
------------------------------

Original Message:
Sent: Mon August 09, 2021 07:01 PM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I'm always happy to have a conversation about MQ.

You're right about the IBM certified container. There have been changes that I didn't keep track of properly. When the switch was made from native kubernetes to OpenShift and Operators (v9.1.5 by the look of things), the independent certified container seems to have gone away. It looks like MQ 9.2.3 in containers is only delivered directly on OpenShift. For other container orchestration environments, it seems you do need to build your own container, which is a non-trivial task, even according to the IBM manuals.

Native HA went full GA with 9.2.3, so IBM are saying that it's ready for the big time (at least in my view). They addressed the missing features (like some of the resync scenarios) that made 9.2.2 a pre-release test only capability.

Keeping on a supported version using CDs isn't quite as hard as you make out though. Although the original CD support model was that only the latest CD (and n-1) were supported, the current CD support is for 12 months from GA release of the CD or 2 releases (whichever is longer). You don't have to take every CD to stay supported. See https://www.ibm.com/support/pages/ibm-mq-faq-long-term-support-and-continuous-delivery-releases.

Even going with RDQM, you may want to review the new capabilities that have been added in MQ 9.2.2 and MQ 9.2.3 which provide improved detection of RDQM cluster failures and an ability to recover from some failure scenarios using locally available information rather than needing to call IBM Support for assistance. See https://www.ibm.com/docs/en/ibm-mq/9.2?topic=wnim9-whats-new-in-mq-923-multiplatforms-advanced-entitlement-only and https://www.ibm.com/docs/en/ibm-mq/9.2?topic=922-whats-new-in-mq.

Good luck with your project.

Regards

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Mon August 09, 2021 04:28 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Thanks for this Neil,

re native HA: If a company doesn't use Openshift then this tech is out of the window - Skills and paradigms are too big a leap for my liking. Although, IBM seems to sell everything as part of a cloud pak nowadays so I doubt think Licencing would be an issue ;-)

I don't think that the MQ provided containers are supported on anything other than openshift?:

You can run IBM MQ using the IBM MQ Operator on Red Hat® OpenShift®. This can be done using IBM Cloud Pak® for Integration, IBM MQ Advanced or IBM MQ Advanced for Developers.

You can also run IBM MQ in a container you build yourself.

Thus, making them inaccessible (at the moment) to many environments/customers. I'm also not quite sure what "supported" means in that case - If I use those containers  on another environment am I supported for MQ but not any of the HA support? If I create my own container what am I supported for?? MQ only I guess, as IBM would probably use the old adage of "if you can create the problem outside the container we'll support you" (as they used to do with VMs)?

re DR in containers. If MQ does only support IBM container environments then I'm on my own there too.

I take your point about containers and security - I often forget that this is a benefit  and, IMO, the most important single benefit. But, I can see that the other smaller wins combine to a whole.

re RDQM requiring Openshift - that was a typo on my behalf - sorry !
re CD: Yep, was only talking about Native MQ support not being prod ready. However, I do question what the percentage of customers are who actually deploy CD to prod !? That's a hell of a lot of work every couple of months to upgrade to a supported version.

So, the conclusion is still clear to me - RDQM is the only supported option that is clearly supported on Azure by IBM and has clear DR capabilities. And, it doesn't rely on IBM container platform.

btw: I just did a *very* quick calculation and get the impression that containers on Azure would be very cheap versus VMs but the openshift service is the same/more expensive than VMs - but that was a *very* quick look - I'd be interested to know what others have found in reality?

thanks for the conversation - just what I was looking for :-)
John.






------------------------------
John Hawkins
Integration Consultant

Original Message:
Sent: Mon August 09, 2021 02:05 AM
From: Neil Casey
Subject: Best HA/DR Options in cloud?

Hi John,

I think you are missing the target on a couple of things, which might change your mind about what might provide the best option for implementing HA and DR in your cloud environment.

I tend to agree with you on MIQM disk issues. MIQM shifts the availability problem from the queue manager/QM server to the storage/storage server. Finding a storage implementation that meets your performance and availability needs can be very difficult.

Native HA is as you say currently only supported on OpenShift. This is available as part of CP4I so you don't need to manage it separately, but if it's a new technology to your environment and you don't plan on using it for more the just MQ, then the infrastructure overheads may overkill for you.

I would disagree on the production readiness of a CD though. Especially in a cloud environment where automated CI/CD pipelines and comprehensive automated regression testing are both possible, the short (12 month or so) lifetime of a CD release doesn't have to be a barrier to production implementation. Code quality is not compromised by the support and delivery changes between CD and LTS in my experience, and IBM tell you when a CD feature isn't ready for production yet (Native HA in 9.2.2 for example).

As to container suitability for MQ, IBM have done a lot of work to ensure that MQ runs well in containers and is indeed suitable. Elasticity is not the only objective of containerisation. Reliable tested software stacks that are independent for each container in your environment can also dramatically reduce the difficulty in things like security patching. The container is also much lighter weight that a full VM. MQ can run easily on as little as 0.05 cores (50 millicores) and I've seen it demonstrated on 20 millicores (although startup was a bit slow). It's also much easier to pick up a container and deploy it somewhere else (like another availability zone) than to rebuild a VM.

Your comment about RDQM requiring RedHat OpenShift isn't quite right. It does require RHEL, but not OpenShift. It is deployed to a cluster (of 3) RHEL servers, not OpenShift containers. In the Azure space, you would need to deploy 3 RDQM servers onto RHEL instances as VMs I believe, although I haven't checked exactly what's in the Azure catalog. For DR, you need another 3 servers.

I think for many organisations containers are here already. There are other organisations that aren't ready for containers, but containers are probably ready for them.

I definitely wouldn't be building my own containers for MQ as a starting point. IBM have already done a huge amount of work and provide a supported container.

I agree that RDQM provides HA and DR, and is great, and doesn't rely on complex shared disk, but you CAN'T put it in a container. RDQM uses kernel modules that are NOT available in a container.

One of the biggest differences between RDQM and Native HA is that they don't use the same replication technology, which is why Native HA runs in containers, and RDQM doesn't. Native HA performs its own replication of the MQ log, and does its own management of the log state, rebuilds and working out what needs to be active where. In RDQM, all of that is offloaded from MQ onto the DRBD and Pacemaker components which are root or kernel level components outside of MQ itself. In Native HA, all of that is moved inside the queue manager.

Native HA also reduces the replication load by only replicating log writes, not all writes to either the log or queue files.

As to DR, you are right at the moment. The 9.2.3 implementation of Native HA doesn't provide DR. You may be able to use a replicated disk technology though to make your data available outside the availability zone, and implement your own DR on top of that. NOTE: This is entirely supposition as I haven't tried it. It would also have performance implications as it would increase the latency of the disk writes.

So, the bottom line...
I don't think you have all your facts quite right, but you are pretty close to the mark with your conclusion. If you want both HA and DR, then RDQM is more capable in that area than Native HA. If you are running OpenShift, then either MIQM or Native HA might do the job for you, depending on what disk technology you have access to, and whether DR is needed.

All the best

------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------

Hi John,

Your wish is my command. :-)

I have replied to your follow-up question but I have a few comments on this thread too.

If you are running MQ on Windows in Azure you can use Azure Files with MQ multi-instance.

Native HA is not using the same technology as RDQM for replication as RDQM requires a Linux kernel module for replication (DRBD) and that is not a good fit for containers. Native HA has implemented replication directly in MQ itself.

At the moment, RDQM is the only MQ solution (with the possible exception of z/OS) that provides integrated DR and HA but from your other question it sounds like you are looking at an alternative for DR anyway so that may not be a major factor. Looking just at HA, the usual MQ options for VMs in Azure are multi-instance for MQ on Windows and RDQM for MQ on RHEL.

You could also look at an external cluster solution which does not require any support in MQ itself but there are more moving parts in those solutions.

------------------------------
John Colgrave
DR and HA Architect
IBM MQ
------------------------------

Original Message:
Sent: Fri August 06, 2021 04:34 AM
From: John Hawkins
Subject: Best HA/DR Options in cloud?

Hi Folks,
I just want to check my logic on the best options for MQ HA/DR on Azure please...?

Multi-instance has got such a bad rep with disk issues - Azure or otherwise (and I'm not clear on whether Azure shared disk options allow for the right locking from the last time I read up on this?). I do have issues with this if I'm honest. Don't clouds give us enough SLA guarantees that multi-instance should be just fine in a cloud env nowadays ? Making an HA disk is also reasonably easy to make DR in a cloud too?

Native HA is a container solution that relies on a CDS (i.e. not prod ready yet) and openshift - something my customer doesn't have. As an attachment to this - I personally get a little confused as to the benefits of putting MQ in a container environment anyhow? MQ is permanently on, so it's not as if container elasticity is usually an issue? In a cloud environment, containers are usually more expensive than a long-term VM contract? (not that I've done the maths on this specific use-case). Containers are usually associated with being flexible and being switched on and off and moved around - something that is completely opposite of where MQ has been for decades! And, at the time of writing, RDQM requires RedHat openshift - another licence? Why would I put that on Azure which, presumably (I don't know) already has the same function?

The one thing I can see for containers is that they are relatively easy to setup, once you have all the surrounding, complex infrastructure. All, in all, I just don't get the impression that containers are quite "there yet" - is that fair to say??

Alternatively, I could build my own container - again, I have issues with the concept of containers and MQ. Plus I now don't get some of the nice self-management things that Multi-instance used to give me i.e. recognising when an instance was broken and auto-moving. 

RDQM uses standard VM tech - customers know it and can price for it. It gives me both HA and DR clearly managed from the MQ perspective (whether you think this is good or bad - i.e. you might want it managed by the environment?). And, worst comes to worst - I could put it in a container. However, I get the impression, at that point that the Native MQ is using RDQM disk replication under-the-hood. So, if Native Ha was available in non redhat Form and was LTS, I should use that if I wanted it in containers - but I still wouldn't get DR?

Is all that reasonably factual and make sense? At the moment, I think the conclusion is, that unless you're container centric, stick MQ into a few VMs and run RDQM over multiple data centres? 

Nice if Mr Colgrave could respond to this :-)
thanks for your thoughts folks !

------------------------------
John Hawkins
Integration Consultant
------------------------------