This article guides you to configure IBM MQ high availability using Microsoft Cluster Service (MSCS)
What is MQ?
IBM MQ supports the exchange of information between applications, systems, services, and files by sending and receiving message data via messaging queues. This simplifies the creation and maintenance of business applications. IBM MQ works with a broad range of computing platforms and can be deployed across a range of different environments including on-premise, in cloud, and hybrid cloud deployments. IBM MQ supports number of different APIs including Message Queue Interface (MQI), Java™ Message Service (JMS), REST, .NET, IBM MQ Light and MQTT.
What is Microsoft Cluster Service (MSCS)?
MSCS clusters are groups of two or more computers connected and configured in such a way that, if one fails MSCS performs a failover. Failover means transferring state of applications from failing computer to another computer in cluster mode and re-initiating their operation from there.
What is MQ high availability?
A two MQ machine under MSCS cluster comprise of two computers (for ex: “A” and “B”) that are jointly connected to a network using virtual IP address. They might also be connected to each other by one or more private networks. A shared disk, which must be a redundant array of independent disks (RAID) Level 1 (RAID 1 stands for Redundant Array of Independent Disk level 1 are the categories of RAID, where Disk mirroring is used). For exclusive use of MSCS; this is known as quorum disk. MSCS monitors both computers to check that the hardware and software are running correctly.
In a simple setup, both computers have all applications installed on them, but only computer “A” runs with live applications; computer “B” is just running and waiting. If computer “A” encounters any one of the range of problems, MSCS shuts down disrupted application in an orderly manner. MSCS will transfers its state data to other computer “B” and re-initiates application from there.
Two modes in which you might run a cluster system with IBM® MQ on Windows: Active/Passive or Active/Active.
Active/Passive mode:
In Active/Passive mode, computer A has the running application on it, and computer B is backup, only being used when MSCS detects a problem. You can use this mode with only one shared disk, but, if any application causes a failover, all the applications must be transferred as a group (because only one computer can access the shared disk at a time). You can configure MSCS with A as the preferred computer. Then, when computer A has been repaired or replaced and is working properly again, MSCS detects this and automatically switches the application back to computer A. If you run more than one queue manager, consider having a separate shared disk for each. Then put each queue manager in a separate group in MSCS. In this way, any queue manager can failover to the other computer without affecting the other queue managers.
Active/Active mode:
In Active/Active mode, computers A and B both have running applications, and the groups on each computer are set to use the other computer as backup. If a failure is detected on computer A, MSCS transfers the state data to computer B, and reinitiates the application there. computer B then runs its own application and A's. For this setup you need at least two shared disks. You can configure MSCS with A as the preferred computer for A's applications, and B as the preferred computer for B's applications. After failover and repair, each application automatically ends up back on its own computer. For IBM MQ this means that you could, for example, run two queue managers, one on each of A and B, with each exploiting the full power of its own computer. After a failure on computer A, both queue managers will run on computer B. This will mean sharing the power of the one computer, with a reduced ability to process large quantities of data at speed. However, your critical applications will still be available while you find and repair the fault on A.
Please note: MSCS with the Microsoft Transaction Server (COM+), you cannot use Active/Active mode.
Prerequisites of MQ and How to achieve MQ high availability under MSCS control?
You configure IBM® MQ for clustering by making the queue manager the unit of failover to MSCS. You define a queue manager as a resource to MSCS, which can then monitor it, and transfer it to another computer in the cluster if there is a problem.
To set your system up for this, you start by installing IBM MQ symmetrically on each computer in the MSCS machine “A” & “B”. As queue manager is associated with IBM MQ installation name, IBM MQ installation name on all computer “A” & “B” machine should be same.
Important points to be noted:
1. Configure both Computer (“A” and “B”) Identical/Symmetrical.
2. Windows OS service levels should be similar. (Windows 2022 or later)
3. IBM MQ Ver & FixPack levels should be similar. (MQ v9.3.x)
4. Both Computer “A” and “B” connected to same Domain name.
5. Using Non mqm user i.e. A domain user can be used as MQ admin, make sure it’s been added onto domain mqm as well as local mqm group with proper folder & file level permission granted.
Please note: During a failover or move, IBM MQ MSCS support ensures that all files that contain queue manager objects have equivalent permissions on the destination node. Explicitly, the code checks that the Administrators and mqm groups, and the SYSTEM account, have full control, and that if Everyone had read access on the old node, that permission is added on the destination node. You can use a domain account to run your IBM MQ Service. Make sure that it exists in the local mqm group on each computer in the cluster.
The queue manager must have their MQ data & Log folders on MSCS (quorum disk), and not on local drive for MQ high availability to function.
Assuming all pre-requisites required for MQ high availability has been met, Windows server identical installation, IBM MQ Server identical installation has been accomplished. Here we will be covering MQ & MSCS configuration steps to achieve high availability and Frequently Asked Question.
First Step: Create/Move Queue Manager under MSCS control:
Create Queue Manager (On Default/Local Disk Drive)
crtmqm MyQmgr
You may replace “MyQmgr” with the actual Queue Manager name.
Next, move “MyQmgr” Queue Manager to SAN (Quorum disk “I”), here Quorum disk (I) is your SAN Disk storage location.
Start queue manager MyQmgr
strmqm MyQmgr
High available registration type /r Register and /u Unregister.
haregtyp /r
Run the program to move the queue manager under Microsoft Cluster Service (MSCS) control.
hamvmqm /m MyQmgr /dd "I:\IBM\MQ\qmgrs" -/ld "I:\IBM\MQ\log"
hamvmqm is IBM MQ MSCS support utility to move QueueManager from local disk to quorum (I) disk, where /m for Queue manager name, /dd MQ DataPath and /ld MQ Log DataPath.
Note: Make sure MQ Data and Log path exist on quorum (I) disk before running above command.
Second Step: Put a queue manager under MSCS control on Windows Server:
1. Log in to the cluster node computer hosting the queue manager, or log in to a remote workstation as a user with cluster administration permissions, and connect to the cluster node hosting the queue manager.
2. Start the Failover Cluster Management tool.
3. Right-click Failover Cluster Management > Connect Cluster ... to open a connection to the cluster.
4. In contrast to the group scheme used in the MSCS Cluster Administrator on previous versions of Windows, the Failover Cluster Management tool uses the concept of services and applications. A configured service or application contains all the resources necessary for one application to be clustered. You can configure a queue manager under WSFC as follows:
a. Right-click on the cluster and select Configure Role to start the configuration wizard.
b. Select Other Server on the "Select Service or Application" panel.
c. Select an appropriate IP address as a client access point.
This address should be an unused IP address to be used by clients and other queue managers to connect to the virtual queue manager. This IP address is not the normal (static) address of either node; it is an additional address that floats between them.
d. Assign a storage device for exclusive use by the queue manager. This device needs to be created as a resource instance before it can be assigned.
You can use one drive to store both the logs and queue files, or you can split them up across drives. In either case, if each queue manager has its own shared disk, ensure that all drives used by this queue manager are exclusive to this queue manager, that is, that nothing else relies on the drives. Also ensure that you create a resource instance for every drive that the queue manager uses.
e. Select the MQSeries MSCS resource on the "Select Resource Type" panel.
f. Complete the remaining steps in the wizard.
5. Before bringing the resource online, the MQSeries® MSCS resource needs additional configuration:
a. The Role in the active machine as shown below.
b. Select the newly defined service which contains a resource called 'New MQSeries MSCS'.
c. Right-click Properties on the MQ resource.
d. Configure the resource.
Under general name choose a name that makes it easy to identify which queue manager it is for.
e. Run in a separate Resource Monitor ; for better isolation.
f. Possible owners ; set both nodes
g. Dependencies ; add the drive and IP address for this queue manager.
h. Parameters ; as follows:
QueueManagerName (required); the name of the queue manager that this resource is to control. This queue manager must exist on the local computer.
i. The Failover Policy is set by default to sensible values, but you can tune the thresholds and periods that control Resource Failover and Group Failover to match the loads placed on the queue manager.
6. Test the queue manager by bringing it online in the MSCS Cluster Administrator and subjecting it to a test workload.
Test that the queue manager can be taken offline and back online using the MSCS Cluster Administrator.
7. Simulate a failover.
In the MSCS Cluster Administrator, right-click the group containing the queue manager and select Move Group. This can take some minutes to do.
Debugging Issue of IBM MQ under MSCS?
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=multiplatforms-collecting-information-microsoft-cluster-service-problems
https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mscs-putting-queue-manager-under-control
https://techcommunity.microsoft.com/t5/failover-clustering/how-to-create-the-cluster-log-in-windows-server-2008-failover/ba-p/371283
https://learn.microsoft.com/en-us/powershell/module/failoverclusters/get-clusterlog?view=windowsserver2022-ps
Frequently Asked Question
Q1: During queue manager creation can we directly create queue manager on quorum disk using -ld and -md option.
Ans: No, hamvmqm utility will fail stating that you are using multi instance queue manager.
Q2: Is it advisable to use MQ control command once queue manager is moved to MSCS
Ans: Once we move queue managers to MSCS control we shouldn’t start or stop manually or by using MQ control command. Please note MSCS Failover Cluster Management will perform all MQ operation of start and stop.
Q3: Is it advisable to create separate resources and roles for MQ queue mangers.
Ans: Ideally, it is advisable to create separate quorum disk & Virtual IPs for each queue manager and allocate separate MSCS resources such as roles and resource monitor under cluster resource.
Q4: Can we have default queue manager under MSCS control.
Ans: No, MSCS doesn’t recognise any default queue manager, MQ only has that default record.
Q5: Can MSCS cluster support and run queue managers in Active/Active mode.
Ans: Yes, you can run queue manager Active/Active mode, but you won’t be able to run queue manager with same name at both machines. In such case when failover happens there will be conflict on queue manager names and both will crash.
Q6: How to run listener under Queue Manager control. If you want to automate Failover & Failback.
Ans: Perform below steps to change control from Manual to QMGR.
a> runmqsc <QueueManagerName>
b> display listener(listener_name)
c> alter listener(listener_name) TRPTYPE(TCP) control(QMGR)
Q7: How to start or initiate Queue manager channel to start automatically. If you want to automate Failover & Failback.
Ans: Perform below steps to trigger channel initiation and set disconnect interval.
a> runmqsc <QueueManagerName>
b> alter ql(Queue name) INITQ(SYSTEM.CHANNEL.INITQ)
c> alter CHANNEL('channel name') CHLTYPE(SVRCONN) DISCINT(0)
Note: QueueName can be any Local or Transmission Queue.
Channel name can be any Server connection or Sender channel.
Q8: Why do we need to exclude virus scanning on MQ Data & Logs folder.
Ans: It is advisable to disable/exclude scanning on MQ Data & Log folder. Cause during scanning it locks crucial files that could be fatal, and possibilities are MSCS will think there is no MQ resource and would move to another server)
Q9: Is there any way where we can share or submit MQ Product features & Idea for IBM development team.
Ans: Yes, you can submit and share your idea for MQ product feature.
Our MQ product development team will review your input and provide status updates.
Log in to IBM
Brief Author Biography:
Ershadahemad S. Shaikh is working as Senior Technical Account Manager (Sr. TAM). Working with IBM India from past 18+ years and overall 24+ year of experience.
The Senior Technical Account Manager (Sr. TAM) is responsible for ensuring clients receive a higher level of service and added value when using their licensing software from IBM. The TAM has a close working relationship with the client’s team and plays an integral role in helping determine the overall life cycle of their IBM software implementation. The Senior Technical Account Manager (Sr. TAM) highly specialized subject matter experts bring the right skills, methodology and experience for successful Traditional, cloud and cognitive solutions.
Documents Reference: