Mixed architecture cluster sharing QMAN$MASTER DB

[John Gillings]

Dave,

Physically sharing the QMAN$MASTER is MANDATORY in a cluster.

The requirements are even more stringent - the logical name QMAN$MASTER must be defined on all nodes with IDENTICAL text, which resolve on all nodes to the same physical disk, directory and QMAN$MASTER.DAT file. The disk containing the master file must be visible and mounted on each node as it starts the queue manger.

You may have multiple queue MANAGERS in a cluster, but not multiple MASTER files. Please make sure you understand the distinction.

If this rule is broken You may find that things seem to work, but if you experience a queue manager failover event (multiple possible triggers), all your queues and entries will vapourise! Very ugly, and very un-VMS, but that's the way it's always been.

(IMHO, queue manager startup should validate the configuration and issue a strong warning if it's not correct, if not flatly refuse to start. Unfortunately engineering don't share that opinion).

[Volker Halle]

Dave,

if you carefully set up your qman database with START/QUE/MANA/ON=(nodes,...) and select only the subset of the nodes, which can access the qman db files, you could even run in a cluster with more than one qman database. You cannot share the queues across those different qman databases.

In your case, you would need to shut down the queue-manager on both the Alpha and Itaniums (STOP/QUE/MANA/CLUSTER), move QMAN$MASTER.DAT, SYS$QUEUE_MANAGER.QMAN$JOURNAL and SYS$QUEUE_MANAGER.QMAN$QUEUES from ONE (probably the Itanium) of the system disks to a common disk, mount that common disk clusterwide, DEF/SYS/EXEC QMAN$MASTER common_disk:[qmandir] and then START/QUE/MANA common_disk:[qmandir]. Then add the queues, which were previously defined on the Alpha.

It would be a good idea to document the current queues and jobs with SHOW/QUE/FULL/ALL/OUT=file, before you combine your qman databases.

Make sure to add the QMAN$MASTER logical definition and the mount of the common disk into SYLOGICALS.COM.

Volker.

[The Brit]

Volker,
This option has been suggested to me. Do you see any corruption issues with this?

1. mount the Itanium System disk on the Alpha, (ensuring that it is mounted before the Alpha queue manager starts).

2. Redefine the QMan Logicals on the Alpha to point to the Queue Database files on the Itanium system disk.

3. define all Alpha queues in the Itanium Queue Database (only ~3 or 4 queues run on the Alpha anyway)

4. Dont use the Alpha database at all.

Dave.

[Volker Halle]

Dave,

that should work. Also consider this:

$ START/QUE/MANA/ON=(itan1,itan2) i64disk:[VMS$COMMON.SYSEXE]

Prevent the Queue-Manager from trying to fail over to the Alpha and make the name of the queue-manager db location cluster-wide unique.

Normally, I would put the qman db files in the same cluster-common directory with all the other cluster-commion files (SYSUAF, RIGHTSLIST etc.)

Volker.

[Robert Gezelter]

Dave,

This thread does not mention what the mass storage configuration of the mixed architecture cluster is.

If the configuration uses a shared disk controller (e.g., an EVA or equivalent). It is a good idea to put the queue manager database on a separate disk, with other architecture-independent but shared files. Then redefine the logical names as has been mentioned previously.

I recommend not putting the queue manager database and shared files on one of the system disks for operational flexibility in the event of a failed updated or restore. If the files are on a separate disk, they can be preserved without change.

If they reside on the system disk, problems ensue when it becomes necessary to use an alternate system disk.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings · Accepted solution]

Dave,

>2. Redefine the QMan Logicals on the Alpha
>to point to the Queue Database files on
>the Itanium system disk.

RG>I recommend not putting the queue
RG>manager database and shared files on
RG>one of the system disks

I want to reinforce Robert's recommendation, for another reason. It is CRITICAL that the logical name QMAN$MASTER be defined IDENTICALLY on all nodes. That is, it must be the same text, not just that it translates to the same physical file.

When the queue manager database is on one of your system disks, the temptation is to leave the definition on the "owner" system(s) as their default "SYS$SYSTEM", which cannot be the same text as on other nodes.

This probably should be considered a bug in the queue manager, that it doesn't recognise that different text strings can point to the same file, but it's been like that for a long time, and probably won't ever change.

The danger is a "working" queue configuration can completely vanish on a queue failover.

[Hoff]

FWIW, the SYLOGICALS.TEMPLATE file has a list of files that must be coordinated in a cluster, including how to set up the queue manager logical name properly. Read the comments for details.

[The Brit]

Thanks Guys