Hi Nick,

I haven't done MQ in MSCS for quite a while, but my recollection is that after moving the files to the shared disk, you have to run a command to actually make the queue manager clustered.

Additional to moving the queue manager to cluster storage, and not mentioned in your list of pages is:

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control

This documents the steps required in MSCS to make the queue manager managed by the cluster.

Although the queue manager was running on the original server, perhaps it was not actually running under MSCS control.

I would check the cluster configuration and make sure that the cluster does know about the queue manager. Follow the instructions in the manual if it is not.

If it is already known to the cluster then it should also be known to the cluster member, so it sounds like something must have gone wrong in that case, which might call for a case to be raised with IBM.

Regards

Hi Neil,

At first many thanks for your time and response.

You are correct about your assumption that MSCS cluster config should be cross-checked in order to verify that the new QMGR is running under MSCS and also that it is known to the cluster so that it can be started and failover if needed.

According to cust, feedback there were problems occurred during the step of putting the QMGR under MSCS control, according to article posted at    https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control.

Actually, based on the input received, they were unable to configure properly the properties of MQSeries MSCS resources and specifically name & dependencies, causing MQSeries MSCS resource to get offline and impact production msg flows, considering that an older existing QMGR currently supports several production business services.

Considering the above,  I assume there are two options: 

1. A case to IBM in order to investigate the cause of the symptom, along with resolution (without impacting the other production flows)
2.  Assign a new  DEDICATED shared drive NOT used by any other QMGR, and assign it as Cluster resource  and try all the steps from the beginning, not being afraid about impacting other production flows.

Thanks & Rgds, 

Nick

Hi Nick,

I haven't done MQ in MSCS for quite a while, but my recollection is that after moving the files to the shared disk, you have to run a command to actually make the queue manager clustered.

Additional to moving the queue manager to cluster storage, and not mentioned in your list of pages is:

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control

This documents the steps required in MSCS to make the queue manager managed by the cluster.

Although the queue manager was running on the original server, perhaps it was not actually running under MSCS control.

I would check the cluster configuration and make sure that the cluster does know about the queue manager. Follow the instructions in the manual if it is not.

If it is already known to the cluster then it should also be known to the cluster member, so it sounds like something must have gone wrong in that case, which might call for a case to be raised with IBM.

Regards

Hi Nick,

Adding a queue manager to the role should not have impacted the existing cluster, unless the qmgr was not defined properly to the cluster and the hamvmqm was not pointing to the correct storage!!! I expect the failure of the first to result from the failure of the second...

Hi Neil,

At first many thanks for your time and response.

You are correct about your assumption that MSCS cluster config should be cross-checked in order to verify that the new QMGR is running under MSCS and also that it is known to the cluster so that it can be started and failover if needed.

According to cust, feedback there were problems occurred during the step of putting the QMGR under MSCS control, according to article posted at    https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control.

Actually, based on the input received, they were unable to configure properly the properties of MQSeries MSCS resources and specifically name & dependencies, causing MQSeries MSCS resource to get offline and impact production msg flows, considering that an older existing QMGR currently supports several production business services.

Considering the above,  I assume there are two options: 

1. A case to IBM in order to investigate the cause of the symptom, along with resolution (without impacting the other production flows)
2.  Assign a new  DEDICATED shared drive NOT used by any other QMGR, and assign it as Cluster resource  and try all the steps from the beginning, not being afraid about impacting other production flows.

Thanks & Rgds, 

Nick

Hi Nick,

I haven't done MQ in MSCS for quite a while, but my recollection is that after moving the files to the shared disk, you have to run a command to actually make the queue manager clustered.

Additional to moving the queue manager to cluster storage, and not mentioned in your list of pages is:

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control

This documents the steps required in MSCS to make the queue manager managed by the cluster.

Although the queue manager was running on the original server, perhaps it was not actually running under MSCS control.

I would check the cluster configuration and make sure that the cluster does know about the queue manager. Follow the instructions in the manual if it is not.

If it is already known to the cluster then it should also be known to the cluster member, so it sounds like something must have gone wrong in that case, which might call for a case to be raised with IBM.

Regards

Hi Neil,

At first many thanks for your time and response.

You are correct about your assumption that MSCS cluster config should be cross-checked in order to verify that the new QMGR is running under MSCS and also that it is known to the cluster so that it can be started and failover if needed.

According to cust, feedback there were problems occurred during the step of putting the QMGR under MSCS control, according to article posted at    https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control.

Actually, based on the input received, they were unable to configure properly the properties of MQSeries MSCS resources and specifically name & dependencies, causing MQSeries MSCS resource to get offline and impact production msg flows, considering that an older existing QMGR currently supports several production business services.

Considering the above,  I assume there are two options: 

1. A case to IBM in order to investigate the cause of the symptom, along with resolution (without impacting the other production flows)
2.  Assign a new  DEDICATED shared drive NOT used by any other QMGR, and assign it as Cluster resource  and try all the steps from the beginning, not being afraid about impacting other production flows.

Thanks & Rgds, 

Nick

Hi Nick,

I haven't done MQ in MSCS for quite a while, but my recollection is that after moving the files to the shared disk, you have to run a command to actually make the queue manager clustered.

Additional to moving the queue manager to cluster storage, and not mentioned in your list of pages is:

https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-putting-queue-manager-under-control

This documents the steps required in MSCS to make the queue manager managed by the cluster.

Although the queue manager was running on the original server, perhaps it was not actually running under MSCS control.

I would check the cluster configuration and make sure that the cluster does know about the queue manager. Follow the instructions in the manual if it is not.

If it is already known to the cluster then it should also be known to the cluster member, so it sounds like something must have gone wrong in that case, which might call for a case to be raised with IBM.

Regards

Ni Nick,

Are you sure you don't have any confusion between MSCS queue manager and multi-instance qmgr?

In the MSCS set up the shared disk is used for the cluster heartbeat.

Cluster storeage is used for the qmgr data and logs. Usually the cluster storeage is only on the active member of the cluster.
The start up of the queue managers is set to manual and controlled by the cluster resource.

Hope that helps clarify some of the setup.

Hi Francois,

At first thanks for your time.

There is no confusion at all. It is not about having instances of the same queue manager in different nodes or systems. It is just a new QMGR  recently created and added under MSCS control moving its data & logs to MSCS Shared disk.

Yes it is a shared disk since this is the terminology used by IBM at hamvmqm and other statements in article posted at https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-moving-queue-manager-storage. It is actually reflects the MQ cluster resource with its own IP (MQ Service IP) where client apps target to. 

Furthermore, in our case during failover (from active to passive) the QMGR keeps the same IP address (MQ Service IP) which is the desired instead of changing IP address as it happens during failover in Multi instance deployment.  

Also, all QMGRs under MSCS control have been configured with manual startup type.  

BTW, when you refer to shared disk for the heartbeat,  you mean the quorum disk which is exclusively used for checking both cluster nodes health via private cluster connection (LAV). 

Rgds, Nick.

------------------------------
Nick Dakoronias
------------------------------


Original Message:
Sent: Tue September 26, 2023 04:06 AM
From: Francois Brandelik
Subject: New QMGR added to existing MQ Cluster resource / Installation Instance doesn't failover

Ni Nick,

Are you sure you don't have any confusion between MSCS queue manager and multi-instance qmgr?

In the MSCS set up the shared disk is used for the cluster heartbeat.

Cluster storeage is used for the qmgr data and logs. Usually the cluster storeage is only on the active member of the cluster.
The start up of the queue managers is set to manual and controlled by the cluster resource.

Hope that helps clarify some of the setup.

------------------------------
Francois Brandelik

what I am trying to say is there is no shared drive in MQ => MSCS. 

There are cluster controlled drives that are defined as cluster role resources and they are dependencies for the qmgr resource on the role, just like the VIP is a cluster role resource and a dependency.

Shared drive meaning it is available on both sides at the same time. This is only for the MSCS cluster Heartbeat.

Point 5 says clearly:

Test the shared disk by using the MSCS Cluster Administrator to move it from one cluster node to the other and back again. 

Talking about a shared disk is a misnomer comparing this to other mounts because, clearly, if you have to check the availability of the shared disk, it is not shared.

The point here is the Shared Disk is shared TO the cluster but NOT WITHIN the cluster. It is a cluster resource that is assigned to the active node in the role... and should not be confused with the heartbeat storage that is on a drive shared within the cluster.

Thanks

------------------------------
Francois Brandelik
------------------------------


Original Message:
Sent: Tue September 26, 2023 07:50 AM
From: NICK DAKORONIAS
Subject: New QMGR added to existing MQ Cluster resource / Installation Instance doesn't failover

Hi Francois,

At first thanks for your time.

There is no confusion at all. It is not about having instances of the same queue manager in different nodes or systems. It is just a new QMGR  recently created and added under MSCS control moving its data & logs to MSCS Shared disk.

Yes it is a shared disk since this is the terminology used by IBM at hamvmqm and other statements in article posted at https://www.ibm.com/docs/en/ibm-mq/9.2?topic=mscs-moving-queue-manager-storage. It is actually reflects the MQ cluster resource with its own IP (MQ Service IP) where client apps target to. 

Furthermore, in our case during failover (from active to passive) the QMGR keeps the same IP address (MQ Service IP) which is the desired instead of changing IP address as it happens during failover in Multi instance deployment.  

Also, all QMGRs under MSCS control have been configured with manual startup type.  

BTW, when you refer to shared disk for the heartbeat,  you mean the quorum disk which is exclusively used for checking both cluster nodes health via private cluster connection (LAV). 

Rgds, Nick.

------------------------------
Nick Dakoronias


Original Message:
Sent: Tue September 26, 2023 04:06 AM
From: Francois Brandelik
Subject: New QMGR added to existing MQ Cluster resource / Installation Instance doesn't failover

Ni Nick,

Are you sure you don't have any confusion between MSCS queue manager and multi-instance qmgr?

In the MSCS set up the shared disk is used for the cluster heartbeat.

Cluster storeage is used for the qmgr data and logs. Usually the cluster storeage is only on the active member of the cluster.
The start up of the queue managers is set to manual and controlled by the cluster resource.

Hope that helps clarify some of the setup.

------------------------------
Francois Brandelik