Operating System - OpenVMS
1748289 Members
3110 Online
108761 Solutions
New Discussion юеВ

Re: Two Queuemanagers without shared db on cluster.

 
SOLVED
Go to solution
SDIH1
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

To elaborate: the main concern against using MSCP is that this is supposed to be a disaster tolerant cluster. Using MSCP would introduce a dependency of the quorum node on the other nodes serving the common disk.

The quorum node is not participating in providing production services, it's just there to keep the cluster from splitting.

Never will any jobs running on the 'real' production machines run on the quorum node or the other way around. Also this node will share almost no users, identifiers, processes or what you have with the 'real' production machines.

In the case of real trouble I am afraid of what MSCP would do when nodes serving the common disk start to get unreachable.

Initially we just went for this node having no queuemanager at all, as per the guidelines in the documentation. This proved to be a major issue for the management sofware that is supposed to run on all machines.

I'll try to schedule some tests this weekend
or early next week to see what the exact behaviour of the independent queue managers is in case of nodes leaving the cluster etc,
and respond with the results.

Jiri_5
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

We have NodeA, NodeB + NOdeQ (quorum) and 2 queue manager, 1 for NodeA and nodeB, 2nd fore NodeQ:
1st queue manager:
Master file: CLUSTER$COMMON:[SYSEXE]QMAN$MASTER.DAT;

Queue manager SYS$QUEUE_MANAGER, running, on NodeA::
/ON=(NodeA,NodeB)
Database location: CLUSTER$COMMON:[SYSEXE]

second manager:
Master file: SYS$SYSROOT:[SYSEXE]QMAN$MASTER.DAT;

Queue manager SYS$QUEUE_MANAGER, running, on NodeQ::
/ON=(NodeQ)
Database location: SYS$COMMON:[SYSEXE]
Jan van den Ende
Honored Contributor

Re: Two Queuemanagers without shared db on cluster.

Jose,

>>>
Using MSCP would introduce a dependency of the quorum node on the other nodes serving the common disk.
<<<
If _NE_ of the production nodes is reachable, that will also mean MSCP will work. _IF_ the nodes are both not there (as seen from the quorum node), then your whole production environment is gone, making the disk holding queman irrelevant, or the production nodes still se one another, and happily go on "producing". Interestingly, the latter case is the one John warns about: the continuing part of the cluster no longer sees the quorum node, and so WILL be FORCED to start that quemanager on one of the prd nodes: the fatal scenario.

Please take John G's advise!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
SDIH1
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

Jiri's configuration of queuemanagers was the one I had in mind. In his configuration the two queuemanagers are prevented from failing over to conflicting nodes by clever use of the /on qualifier ( no * in the node list) when starting the queuemanagers, unless he and the documentation are mistaken, which sounds unlikely.

Considering the contradictory answers and experiences of people, not even to mention the unclear status of support, I will do some testing, to actually see if it works, or not.



Volker Halle
Honored Contributor

Re: Two Queuemanagers without shared db on cluster.

I'm running the same configuration as shown by Jiri. If you prevent the QUEUE_MANAGER from ever failing over to another node, it should be fine.

You certainly cannot use the queues/printers on the other nodes. But for having a local batch queue on the 'quorum' node, this setup seems to work. The location of the qman database files as well as the nodes to be run on is stored in QMAN$MASTER.DAT. This file is opened by JOB_CONTROL, which then creates the QUEUE_MANAGER process. The related locks have a parent lock, which includes the device name on which the QMAN$MASTER.DAT file resides. This is supposed to be unique in a cluster !

If you want to run a 'pure' quorum node, you don't want to mount the disks in the SAN.

Volker.
Jiri_5
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

We have the same configuration on 4 cluster which work 7 years and clusters are under HP gold support.
SDIH1
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

Yes I see the locks: on all production nodes job_control holds a nl lock called qman$msr_dsa3 (dsa3 is the disk the queuemanager is on), and on the node running the queuemanager there is an EX child lock called qman$jbc_alive_01. There is no dsa3 device on the quorum node, as it is not connected to the SAN, there never will be.

If I understand Volker correctly, I have to take care not to put the 'quorum' queue database on a device called dsa3?
Volker Halle
Honored Contributor

Re: Two Queuemanagers without shared db on cluster.

You won't be able to create a 'local' DSA3: device on your quorum node, if there already exists a DSA3: shadowset volume in your prodction nodes within the cluster. This is also protected via cluster-wide locks.

Just put the 'local' qman database onto the system disk of your quorum node (in SYS$SYSTEM: as by default). The disk device name must be unique within the cluster anyway...

Volker.
SDIH1
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

I know, the only way would be to mount the production DSA3 over MSCP :-).

This was a hypothetical question. In a cluster all disknames are supposed to be unique, aren't they? Local disks get the allocation class before the device name, shared disks are seen by all members, and so have to be unique.
So I didn't really understand your point, as by design the device name should be unique anyway.

Would there be a problem if you would make another qman$master.dat in another directory on the same disk?

No idea what happens if you would attach the quorum node to another SAN having the same DGA devices as the 'production' SAN, probably you would get 'unpredictable results', but that's another discussion.
Jiri_5
Frequent Advisor

Re: Two Queuemanagers without shared db on cluster.

Why do you want make another qman$master.dat in another directory on the same disk (DSA3), why you don't use sys$sysdevice of quorum node? We mount cluster disk (DSA from 2 $1$DGA from SAN) on quorum node too, but you need for it license for shadowing on quorum node. We use this this for HP product over all cluster (ISEE and SHC) but not for both qman$master.dat.