Two Queuemanagers without shared db on cluster.

[SDIH1]

Hi,

We are building a multisite cluster, the main machines located on two sites, using a SAN also stretched over these 2 sites. We have foreseen placement of quorum node on a third site.

Due to economics it is not possible or even desirable to attach the quorum system to the SAN, it just boots from local disks, and provides a vote in the cluster.

Starting a separate queuemanger (i.e. a queuemanager not using the common queuemanager database) on this quorum node is unsupported, but it would be very handy to be able to print and submit batch jobs on this node. We also have considered MSCP mounting the disk where the queue database is residing on, but this is thought to be undesirable, considering the network load and instability this might cause.

From experience ( doing things wrong :-) ) I know having 2 queue managers using independent queue manager databases in a cluster does work,
but what are the actual risks of doing this?

[Robert Brooks_1]

. . .considering the network load and instability this might cause.

---

Huh? What instability might be caused by MSCP-serving a disk?

In general, supported configurations are preferable to unsupported ones, for a production system.

Unless you are doing a staggering amount of queue manager stuff from the remote node, I can't imagine that the I/O load will be an issue.

-- Rob

-- Rob

[Jan van den Ende]

Jose,

I fully agree with Rob!

MSCP ,ount is hardly ever an issue.
And considering you obviously do not intend to mount your SAN disks on the quorum node, I expect not many jobs to run on the quorum node.
The occasional (print-, batch) job that IS run on the quorum node, certainly do NOT warrant the extra complexity!
Just MSCP-mount your QUEMAN$MASTER disk, and forget about it!

hth

Proost.

Have one on me.

jpe

[Hoff]

I certainly wouldn't choose to run nor would I recommend a multiple-master queue database configuration within a production environment, but you're certainly welcome to choose to try this and to experiment here -- do consider reporting back with your findings, particularly as you gain experience with cluster and queue manager failures, and with the related transitions.

If you want to know if this is supported, you might want to contact HP directly and more formally. (AFAIK, there can be only one queue manager master database; all queue managers operating in a cluster must know about each other.)

Host queue files and such can certainly be local to a lobe, but I'd park the queue manager master file on the same disk with the authorization database.

Stephen Hoffman
HoffmanLabs LLC

[Jiri_5]

We have 3 clusters with this configuration (2 nodes + quorum node with 2 separated queue managers) 7 years - it is working ok and is supported by HP.

[SDIH1]

Thanks for the interesting feedback. It shows we were probably right about the alternatives, each having it's merits. I didn't read anyone having problems with the separate queuemanager setup, which was my main concern.

I would still be very interested in anyone having ever seen any problems using an independent second queuemanager.

I will also submit a formal request to HP
(with a pointer to this discussion) as to what exactly is supported and what not. The documentation says it's not, but this might
be not the current view anymore.

[Robert Brooks_1]

I agree you should get a formal response, but I am rather confident that we do not support multiple queue managers.

Note that many things that are not "supported" may still work, sometimes even correctly. However, things that seem to "work" can mysteriously fail, frequently at very inconvenient times.

I still vigorously asset that MSCP-serving is the correct choice here.

-- Rob (ex-VMS Engineering, still an HP employee, who spent a fair amount of time digging into the MSCP server and DUDRIVER (the MSCP client)

[John Gillings]

Jose,

>I would still be very interested in anyone
>having ever seen any problems using an
>independent second queuemanager.

Yes I've seen problems. BIG problems, numerous times.

There is no such thing as an "independent second queue manager". Having two separate queue manager data bases is a very dangerous configuration. Although it SEEMS to work when you initially set it up, WHEN (not IF) you have a queue manager failover event you will lose all queues, entries, and forms. Splat! Gone, vapourised!

Why? Because no matter what you do, the multiple queue managers know about each other. On failover, the algorithm to recover doesn't understand that two nodes have completely different "views" of the data, therefore assumes it's all bad and deletes it all.

This is NOT a bug. The configuration does not work, was never intended to work, and will never work.

If you have a cluster, you can only have a single physical queue manager master file (the managers themselves have their own journal and queue definition files). There are numerous other files which MUST be physically shared between all cluster nodes. That's how clusters work. You need to have some shared storage area visible to all cluster nodes in which the common files live.

The queue manager has an additional constraint - the file specification used to reference QMAN$MASTER.DAT must be identical on all nodes.

(my preference would be to have queue managers refuse to start if they don't correctly reference the QMAN$MASTER used by existing queue managers)

[SDIH1]

Interesting. So, if there never is a failover from the nodes running queuemanager 1 to nodes running queuemanager 2 it's ok?
That's configurable behaviour, did you ever try that?

[Jan van den Ende]

Jose,

>>>That's configurable behaviour, did you ever try that?
<<<
No, that is _NOT_ configurable.
Any time a node running a queue manager goes down, the manager is transfered. And if the node crashes, any surviving node takes over.
-- that is one of the things that make VMS clusters so resilient to various ways of failing hardware.

And John,
>>>
(my preference would be to have queue managers refuse to start if they don't correctly reference the QMAN$MASTER used by existing queue managers)
<<<

If you ever need any backing vote on this, mine is given herewith!

Proost.

Have one on me.

jpe