Mixed architecture cluster sharing QMAN$MASTER DB

[The Brit]

Is it acceptable for a Queue database to be shared between Itanium and Alpha systems in the same cluster. (Itanium is 8.3-1H1, and Alpha is 8.3).

All systems are running decnet phase V however we haven't resolved the name resolution issue yet, so init/batch/start/on=:: doesn't work. At the moment the alpha has its own Queue DB on its system disk, and the itaniums have their own DB on their system disk.

The nodes share many common disks and so it would be simple to set it up so that all nodes can see a single DB, the question is whether the DB is compatible with both architectures.

Thanks for any help,

Dave.

[Steven Schweda]

> Is it acceptable [...]

I thought that it was required. I do it.

[Volker Halle]

Dave,

sure, sharing the queue manager database is supported and strongly suggested as well. Note that you should also share a lot of other files (SYLOGICALS.TEMPLATE has the list).

Make sure to MOUNT the common disk, containing QMAN$MASTER.DAT and all the other common files, in SYLOGICALS.COM and DEF/SYS/EXE QMAN$MASTER to point to that common QMAN$MASTER file. Make sure you named the database location of the Queue-Manager files in a cluster-wide unique way (don't use SYS$SYSTEM !). Check with SHOW QUE/MANA/FULL

What do you mean with: 'we haven't resolved the name resolution issue yet, so init/batch/start/on=:: doesn't work' ?
This would have nothing to do with DECnet whatsoever. Please explain...

Volker.

[Robert Gezelter]

Dave,

In a word, YES.

That is how rolling upgrades work with mixed versions as well.

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

[Hakan Zanderau ( Anders]

Dave,

One thing....

When the queuemanager starts it looks for the location of QMAN$MASTER.DAT

The defaultlocation is SYS$SYSTEM, but if you move it to another location you need to define the logical QMAN$MASTER.

The QueueManager uses three files
QMAN$MASTER.DAT
SYS$QUEUE_MANAGER.QMAN$QUEUES
SYS$QUEUE_MANAGER.QMAN$JOURNAL

The logical is the pointer to the location of QMAN$MASTER.DAT.

QMAN$MASTER.DAT holds the location of the queue & journal files.

If you move QMAN$MASTER, define the logical and start the QueueManager with

$ START/QUEUE/MANAGER

The location of the queue & jounal files will still be SYS$SYSTEM.

The format for starting the queuemanager is

$ START/QUEUE/MANAGER [location of queue and jornal files ]

After you have moved all three files, start the QueueManager using

$ START/QUEUE/MANAGER QMAN$MASTER

Hakan

[The Brit]

Volker,
I assumed it was something to do with DECnet because of the error, but I see now that it is not, it is with the Job Controller.

i.e.
$ init/batch/start/on=SPEEDY:: TEST_Q
%JBC-E-NOSUCHNODE, remote node is unknown or not reachable

however SPEEDY is a cluster Node, vis.

$ show cluster

View of Cluster from system ID 1059 node: BUD 15-FEB-2009 07:39:42
â â â â â â â â â â â â â â â â â â â â â â â â â ¬â â â â â â â â â â
â SYSTEMS â MEMBERS â
â â â â â â â â â â ¬â â â â â â â â â â â â â â â ¼â â â â â â â â â â ¤
â NODE â SOFTWARE â STATUS â
â â â â â â â â â â ¼â â â â â â â â â â â â â â â ¼â â â â â â â â â â ¤
â Node1 â VMS V8.3-1H1 â MEMBER â
â SPEEDY â VMS V8.3 â MEMBER â
â Node2 â VMS V8.3-1H1 â MEMBER â
â Node3 â VMS V8.3-1H1 â MEMBER â
â â â â â â â â â â ´â â â â â â â â â â â â â â â ´â â â â â â â â â â

Dave

[The Brit]

Sorry about that last entry, it is a show cluster command.

Dave

[Volker Halle]

Dave,

check with SHOW QUE/MANAGER/FULL on all your cluster nodes, whether they share the SAME qman database.

Do the JOB_CONTROL and QUEUE_MANAGER processes exist on node SPEEDY ? Can you execute the command on node SPEEDY itself sucessfully ?

Also see HELP/MESS NOSUCHNODE

Volker.

[Volker Halle]

Dave,

your Alpha (V8.3, node SPEEDY) system does NOT share the queue manager database with your Itanium systems. You can DEFINE a batch queue on the I64 systems with /ON=SPEEDY::, but as soon as you try to START the queue, it will fail with %JBC-E-NOSUCHNODE, as there is a different QUEUE_MANAGER running on SPEEDY, which cannot communicate with the I64 systems, because it's qusing a different queue-manager database. SHO QUE/MANA/FULL will tell. Don't be mislead by the fact, that all systems may show SYS$COMMON:[SYSEXE] as the db location. This points to a DIFFERENT device on your Alpha or your Itanium systems !

If you want to share queues between the systems, you need to have a COMMON queue-manager database.

Volker.

[Steven Schweda]

> Make sure to MOUNT the common disk, [...]

Or else expect to (re-)do the queue start-up
command(s) sometime after that disk is
mounted. As I recall, JBC-E-JOBQUEDIS is
what you may get if the disk is unavailable.

[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