topic queues+clustering in Operating System - OpenVMS

queues+clustering

nipun_2 — Wed, 20 Apr 2005 14:19:55 GMT

Hello all,
I recently added a 3rd node (EV68-ds25alpha station) to a common environment cluster running 7.3-1. (for all of you who were answering my previous questions of blue screen - it needed graphics drivers for the new machine)

So currently we have
DS25-main node
XP1000- satellite node
EV68 - Satellite node (new)

Now when I can clearly see the decwindows and software applications on the New node EV68. However, when I run evaluations(other such high processing applications) on EV68 it does not use it's own CPU but of the other two nodes?

I saw that when I looked at Monitor cluster command

Can anyone please guide me as to how I can check the current queing setup and how I should add my node to it. Please mention the *.com files as well as their path if possible.

Thanks in advance
Nipun

Re: queues+clustering

Uwe Zessin — Wed, 20 Apr 2005 14:56:39 GMT

Hello Nipun,
it's great to hear that you got your system working.

To get an overview over all queues:
$ show queue *

If you're interested in batch queues only:
$ show queue /batch *

For details, add the /FULL qualifier and if you like to see all jobs from all users use the /ALL qualifier.

I usually use a queue name that has the nodename as part of the queue name, e.g.:
$ initialize/queue/batch/job_limit=2 athena_batch /on=ATHENA::

Then, as part of the system startup (I put it in SYS$MANAGER:SYSTARTUP_VMS.COM):
$ start /queue athena_batch

Jobs can easily sent to this queue with:
$ submit /queue=athena_batch job.com

Re: queues+clustering

Wim Van den Wyngaert — Thu, 21 Apr 2005 01:19:09 GMT

Also check if the failover of the queue manager is OK. If not, a node failure may stop all queue activity.

$ sh que/man/fu
should show all 3 servers in the /on part.

To correct :
$ start/que/man/on=(n1,n2,n3)
or
$ start/que/man/on=(*)
but if you have cluster stations or quorum stations the first format is better.

Wim

Re: queues+clustering

Joseph Huber_1 — Thu, 21 Apr 2005 03:12:05 GMT

In general You should have at least on every cluster manager one dedicated queue, which has /(AUTOSTART_)ON=mynode. This way You can have whatever programs running on this node.
You need such a queue e.g. for jobs fired from sys$startup_vms.
My practice then is to have a /GENERIC queue, which includes all of these node-specific queues:
$ init/queue/batch/generic=(nodea_batch,nodeb_batch,nodec_batch) sys$batch

Then jobs submitted to the generic queue will run on any node selected by the queue manager.
This generic queue can of course have any name other than sys$batch: it is just convenient to have a sys$batch queue for submit without a /QUEUE=specific.

On the other hand You may choose to have jobs by default executing on the node where it is SUBMITted, then define a /system logical SYS$BATCH pointing to the node specific queue in sys$startup_vms:
$ define/system sys$batch 'f$getsyi("NODENAME")'_BATCH

Re: queues+clustering

Ian Miller. — Thu, 21 Apr 2005 03:23:38 GMT

I basically do what Joseph does - queue called nodename_BATCH and define SYS$BATCH on each system to point to it. Often there are other specific purpose queues e.g queues with a job limit of 1 to co-ordinate jobs and queues with different working set limits or base priorities and so on.

Re: queues+clustering

Joseph Huber_1 — Thu, 21 Apr 2005 03:51:40 GMT

To correct a typo in my previous respone:

on every cluster manager one dedicated
should of course read as:
on every cluster MEMBER one dedicated

Re: queues+clustering

Wim Van den Wyngaert — Thu, 21 Apr 2005 03:58:00 GMT

I would say cluster SERVER. Stations and quorum stuff excluded.

Re: queues+clustering

Joseph Huber_1 — Thu, 21 Apr 2005 04:18:41 GMT

Wim, well it's just personal taste:
I have a dedicated queue on every member node in the cluster: at system startup I submit some utility/package startup in a batch job to make system startup shorter. Especially on a workstation: don't have to wait longer until I can login.

Re: queues+clustering

Wim Van den Wyngaert — Thu, 21 Apr 2005 04:20:58 GMT

Jos : ignore my comment. I read to fast.

Re: queues+clustering

Jan van den Ende — Thu, 21 Apr 2005 14:43:48 GMT

Nipun,

maybe just a matter of taste, but personally I do not like the idea of SYS$BATCH as name or alias for a clusterwide queue.
And here is why: during bootstrap it is just too convenient to KNOW that any job submitted withit explicit queuue specification will run ON THE BOOTING NODE.
Otherwise you will have to check (and re-check at every new release and new software product) that there is NOT any default submit command!

That is the reason I 100% agree with Ian: on each node a /SYSTEM logical name SYS$BATCH for the queue that is bound to that node.

OTOH, the concept of dedicated queues can (maybe; should) be applied generously.

We run multiple applications in the cluster, and each application has at least one queue. The queue is owned by the application's Resource Identifier, and resp. the application managers have management control over their queues.
A very pleasant way to delegate a lot of standard work to those that have the functional application knowledge, so now we get only the really technical issues.

Proost.

Have one on me.

jpe

Re: queues+clustering

Wim Van den Wyngaert — Mon, 25 Apr 2005 01:21:16 GMT

During boot, I create/adjust 2 queues.

The first is called node$startup and has a job limit of 99. It is NOT a autostart queue and can be used during the boot to start things. The queue is emptied in the beginning of the boot.

The seconds one is node$batch with a job limit of 3 to which I map sys$batch. It is an autostart queue and everything that is started in it is only started when the boot is complete, t.i. the last thing I do during startup is enable autostart. It is not emptied during boot.

If an applications requires timely execution of a job, it must create its own queue. If not, it can use sys$batch but the queue may be busy and the job is delayed.

The advantage is that all applications queues are autostart queues and only start doing things after the boot, thus not delaying the boot. Also, the jobs start only after the boot, so their environment should be present.

And all my queues are retain=error. Don't understand why it's not the default.

Wim

Re: queues+clustering

Uwe Zessin — Mon, 25 Apr 2005 01:30:50 GMT

A self-resubmitting job that ends with an error status every time can fill up the queue file.

Re: queues+clustering

Wim Van den Wyngaert — Mon, 25 Apr 2005 01:40:25 GMT

Uwe,

Yes but why are they present ? We also had jobs that terminated in error but we corrected them all. Only in case of exceptions, they may or must terminate in error. And we monitor error entries, of course.

Wim

Re: queues+clustering

Uwe Zessin — Mon, 25 Apr 2005 01:47:07 GMT

What works good for you does not work well for somebody else and engineering had to make a decision. Of course, mine's only a guess - it is quite possible that today nobody can tell on what base the decision was made many years ago.

Re: queues+clustering

Anton van Ruitenbeek — Mon, 25 Apr 2005 01:53:56 GMT

Nipun,

Possibly I'm missing the begin of the discussion, but I don't understand what you mean with 'main node' and 'satellite node'.
Don't you have a CI/SCSI/SAN-cluster but do you have LAVC idea of a cluster ?
Other words: Do you have a (boot)node and the other nodes are satelites ?

I know this is not the major reason for difference setting up, but the QUEUE/MANAGER can't be clusterwide if you have a LAVC sort of.

To be honest: I think the solutions (what ever you choose) is given in one of the previous postes.

AvR

Re: queues+clustering

Joseph Huber_1 — Mon, 25 Apr 2005 02:15:22 GMT

Anton,
who/what manual told You in a LAVC there can't be a cluster-wide queue management ?
Must be a on a different VMS planet ...

Re: queues+clustering

Karl Rohwedder — Mon, 25 Apr 2005 03:22:22 GMT

May be, he meant, that is not useful to start the queuemanager on satellite nodes, when the queuefiles reside on the bootnode...

regards Kalle

Re: queues+clustering

Anton van Ruitenbeek — Mon, 25 Apr 2005 03:35:46 GMT

Joseph,

I was on planet Eath.

Thanks Karl.

I ment if you realy have satelites (in the contents of LAVC) these satelites don't have any disks (only for paging/swapping) localy. For NI clusters there is a difference. So if the queue manager is running and the bootnode(s) are gone (and in this way the systemdisk(s) (and if exists the cluster comman data disk) are gone), and the queuemanager is running on all the node, the queuemanager maybe will work but not as expected.
And as good VMS manager, if something will work but cannot be garenteed: IT IS NOT WORKING (properly....)

AvR

Re: queues+clustering

Jan van den Ende — Mon, 25 Apr 2005 03:49:31 GMT

Anton wrote:

if something will work but cannot be garenteed: IT IS NOT WORKING (properly....)

Can someone make a nice tune for this, and turm it into a mantra that needs to be sung 3 times by _EVERY_ IT worker AND MANAGER before each working day?
.. even reading it once will probably be enlightening for most managers..

Proost.

Have one on me.

jpe

Re: queues+clustering

Uwe Zessin — Mon, 25 Apr 2005 03:56:46 GMT

I think that argument is flawed.

If your boot node is down, then your satellite nodes can't do any work anyway while they stall.

So you can't use any satellites with a single boot node, because it is not *guaranteed* that they will be working 'properly' all the time ;-)