Update request due to new NFS storage

[wirowka]

Dear IBM Azure supports now NFS4.1 share storage which fulfills IBM MQ requirements and can be used for MQ HA installations: https://azure.microsoft.com/en-us/updates/azure-files-nfs-ga/ Could you please update the site with the usage of the above NFS? NFS from azure supports both:

• LRS (local redundant discs)
• ZRS (zone redundant discs) - valid for HA installation accross Azure zones within one Azure region

Many thanks in advance ps.: we are now working on HA setups in azure for several customers (IaaS) - would be great to have your assistance/help here

[john-colgrave]

Microsoft did the testing of Azure Files NFS v4.1 with MQ multi-instance as mentioned at https://docs.microsoft.com/en-us/azure/storage/files/storage-files-faq#network-file-system-nfs-v41 so I would ask them for details of how they configured NFS and how they mounted it on the MQ systems.

[wirowka]

great, thank you! In our case we are will run two main scenarios:

• MQ HA using multi-instance with NFS4.1 (do not require external clustering - I guess)
• MQ HA without multi-instance with NFS4.1 (requires external clustering - like described here) - in this scenario we cannot use MQ multi-instance because we have some legacy software which is running with MQ locally (in the binding mode) in one "package" and must be handled by the cluster as one package/unit (e.g.: moved from one node to another)

[john-colgrave]

Have you considered using an MQ service object to manage your legacy software so it is always colocated with the queue manager? See https://www.ibm.com/docs/en/ibm-mq/9.2?topic=objects-working-services for more details.

That is how an IBM App Connect Enterprise (ACE) integration node can be managed by MQ so that it is always co-located with a queue manager. See https://www.ibm.com/docs/en/app-connect/11.0.0?topic=service-starting-stopping-integration-node-as-mq for details of that. ACE provides commands to manage this, but it uses an MQ Service under the covers.

[wirowka]

hi John No, our services linked to MQ are java or C/C++ applications some offer additionally UI and use small DB (mariaDB), so the overall setup is pretty complex. MQ is just one of the components (there are 5 queue managers in total dedicated to different types of traffic) which offer reliable messaging, but there are other components which handle old/legacy tcp transport protocols and use MQ only for storing messages. In Azure:

• floating IPs will be attached to a Azure load balancer which is in front of two/three cluster nodes
• shared FS - will be from Azure NFS4.1 - which shall be ok from MQ requirements, it will be attached to all MQ nodes - we need to do it properly
• MQ qmgrs will be standalone (multi-instance cannot be used since we have to switch qmgrs together with components which are linked with qmgrs - as one "bundle")
• We need to use either RedHat cluster or pacemaker (I am not an expert here) to monitor/control processes running in the cluster nodes - this is the main TODO on our list - to do this properly

[john-colgrave]

Before we shipped RDQM I published an unsupported sample showing how Pacemaker could be used to manage MQ: https://github.com/ibm-messaging/mq-aws/blob/master/drbd/part_2/README.md

This uses DRBD for storage but you can replace that with NFS.

It was on AWS but you should be able to do something similar on Azure.

You will have to use the appropriate Resource Agents, and perhaps write your own, to manage all the other components, and add the necessary constraints to ensure that everything moves as one.