topic Re: OpenVMS cluster print queue setup in Operating System - OpenVMS

OpenVMS cluster print queue setup

M C_1 — Mon, 26 Jan 2004 15:13:40 GMT

OK - I know this is not a very popular topic but I have some questions about Cluster Print Queue Setup..

I have a two node cluster running VMS 7.2-2 with one system disk. No LPD no DQS just plain terminal printing via LAT and Multinet. There is only one queue manager.

System1 runs the queue manager

Both system1 and system2 have queues defined in their startup. The queue manager running on System1 is set to failover onto System2 in the event System1 goes down.

I would like to set all my queues to autostart failover to the opposite system they are defined on. I know that I would have to re-init each queue with /autostart_on=(system1::,system2::) and then in my startup start/queue on each queue and then $enable autostart/queue on system1 and system2.

However, my question is two-fold:

1) If system1 crashes, the queue manager will move to run on system2, however, will the autostart queues defined on system1 automatically move over to system2? The VMS documentation says on a system shutdown a $ disable autostart/queue is issued to move the queues over to the existing node if they are defined for failover. However, there is no mention of on a Crash...

2) If indeed the queues do move over on a shutdown and/or a crash, once system1 is back up and stable, how do you move the queues that failed over back to the original system?

3) Also, if system1 crashed and the queue manager moved to system2, when system1 comes back on-line will it attempt to start the queue manager? What about system2?

Sorry for the long note... Thanks so much for your feedback..

MC

Re: OpenVMS cluster print queue setup

David Harrold — Mon, 26 Jan 2004 17:39:54 GMT

Hi MC,

I can't answer quesiton 1 about the queue failover. I think they do, but it has been so long since I tested that, I don't remember.

About failing queues back, no they don't move back to SYSTEM01 when the startup performs the ENABLE AUTOSTART/QUEUE. The way I move them is a stop/queue/reset followed by a start/queue .

for the third question, it depends. How do you do the start up of the queue manager in you SYSTARTUP_VMS.COM? If you do something like START/QUEUE/MANAGER/ON=(SYSTEM1,SYSTEM2,*), then it should move it back to SYSTEM1 when it boots. Otherwise I believe it stays where it is.

Hope that helps.

Dave Harrold

Re: OpenVMS cluster print queue setup

Jan van den Ende — Tue, 27 Jan 2004 04:17:21 GMT

Hello MC.

The answer to 1):
IF you have set up your queues to be allowed to run on both (all) systems, they DO failover correctly.
(Only jobs-in-progress might fail, depending on what is already in the printers' buffer and what still needs sending. If you set up your queue /RETAIN=ERROR you will recognise those immediately, and you can re-issue them.) Jobs pending are not affected.

If you set up your queues to be /ON=(node1,node2,...), then after STOP/QUE & START/QUE they run on the first available the list that has autostart enabled. If you set them /ON=*, then they will run on the node where you issued the command.

More important:
Do you have a really urgent reason to have them fail back when the failed node reboots?
The load caused by printqueues is negligable, the effort to fail them back by hand is not. I understand that your configuration DOES allow failover ( most important issue: all disks from which files might be printed must be mounted on all nodes where the queue might be running).
So essentially: Why care WHERE the queue is running, as long as it IS running.

As far as I can judge from here (meaning: I might be wrong but I don't think so) you are trying to solve a problem that has already been solved much more fundamentally by the VMS cluster engeneers.

hth,

Jan

Re: OpenVMS cluster print queue setup

Mac Lilley — Tue, 27 Jan 2004 05:33:08 GMT

Hello

You could consider using generic and execution queues. Initialize the execution queues like this for example

$ init/queue system1$q1/on=system1::lta100:
$ init/queue system2$q1/on=system2::lta100:

and the generic queue

$ init/queue/generic=(system1$q1,system2$q1) q1

Print to the generic queue q1. Jobs then get transferred to either of the execution queues for processing. If say system1 crashes print jobs still get processed on system2$q1. When system1 reboots print jobs will then be processed by both execution queues. No need to move queues "by hand".

HTH

ML

Re: OpenVMS cluster print queue setup

M C_1 — Tue, 27 Jan 2004 09:01:35 GMT

David - start/queue/manager/on=(system1,system2,*) was issued way back when. According to the doc's it does not need to be reissued in startup unless a stop/queue/manager/cluster is issued.

Jan - Currently when I define queues, I set them up for one system only (i.e. /ON=(system1::xyz). I would like to re-init all queues with /AUTOSTART_ON=(sys1,sys2) so that they will failover on a system shutdown or crash.

The reason I want them to fail back once the other node is rebooted is because, we have between 600 and 650 queues. We are very print intensive. Lots of printing going on every minute,hour,day... My biggest consern is that printing continues to execute in the event we loose a system for a period of time. Second biggest consern, ballance print load between two systems.

Mac - I considered this option, but because of the sheer number of queues that we have this could be a bit complicated..

Thanks
MC

Re: OpenVMS cluster print queue setup

Jan van den Ende — Tue, 27 Jan 2004 10:14:34 GMT

Well M C,

with us 800+ printer queues effectively all running on the same node present no problem at all. We print some 5000 pages daily, with peaks over 15000. Of course I don't know HOW intensive is "intensively used", but you have to get WAY over that before you should begin worrying.

I hope this give you some peace of mind.

Jan

Re: OpenVMS cluster print queue setup

Ian Miller. — Tue, 27 Jan 2004 12:11:09 GMT

I think the queues stay where they are without you stopping and starting them to move back. You define them /AUTOSTART=(node1::,node2::)

Re: OpenVMS cluster print queue setup

M C_1 — Tue, 27 Jan 2004 15:16:04 GMT

Jan,
This does give me some piece of mind. I mean we have lots of printers, and I am not really sure how much paper we eat each day but its a bunch.

With respect to my question, I wanted this information to help analyze redundancy, availability, and failover of our cluster.

The documentation is not 100 % clear as to what failover means with respect to these queues(Crash/Shutdown).

Thanks for all the input.

MC

Re: OpenVMS cluster print queue setup

M C_1 — Tue, 02 Mar 2004 17:32:04 GMT

Quick question regarding this old topic...

When you configure autostart on the cluster (in my case a 2 node cluster) does each system have to execute a start/queue on all queues for failover to be setup properly?

For example: Our current setup includes during startup; defining and configuring LAT and Multinet ports, then start individual queues on their respective nodes.

What I intend to do is re-configure all queues to be autostart. In the startup define and configure all ports on both systems, then enable autostart on both nodes in after the queue manager startes. Then start / queue each of the queues.

However, when both nodes boot do both nodes need to execute the start/queue portion?

Also on a system crash, the queues fail over to the other node. When the problem node comes back up does it really need to execute the start/queue part?

Can anyone out there share their config preferences?

Thanks,

MC

Re: OpenVMS cluster print queue setup

Wim Van den Wyngaert — Wed, 03 Mar 2004 02:43:42 GMT

Q>However, when both nodes boot do both nodes need to execute the start/queue portion?

A> No. As long as the queue database is intact, none of the nodes have to do any queue setup. Only enable autostart/que is needed.

Q>Also on a system crash, the queues fail over to the other node. When the problem node comes back up does it really need to execute the start/que part?
A>Not when they are setup as autostart. Only the enable autostart/que is needed. Of course, you must make sure they are not stopped by stop/que.

Also : if you happen to have multiple system disks, make sure you spool to a shared disk.

Re: OpenVMS cluster print queue setup

Jan van den Ende — Mon, 08 Mar 2004 04:38:58 GMT

MC,

if you specify /AUTOSTART, then there are two ways to specify your nodes: simply specify "*" for your nodename. It defines ALL nodes eligable for exeution; and your que will keep running on a node, until it is forced to fail over, when it will run on another node until etc...
The other way is to specify /AUTOSTART=(node_1,node_2,...). Now the queue will try to run on the first node specified, etc.
So if you want to spread the load (if various nodes are available), then specify a portion as (node_1, node_2,...), a portion as (node_2, node_1,...) etc...
If a node fails, its queues fail over. When if comes back (more precisely, when it enables autostart), then those queues that have that node in their /AUTOSTART list ahead of the current execution node, those will fail over ( = fail back)

hth,

Jan

Re: OpenVMS cluster print queue setup

Uwe Zessin — Mon, 08 Mar 2004 05:13:59 GMT

Haven't seen this mentioned yet, but for AUTOSTART queues to work you need to execute the following command on any node that uses queues with that feature:

$ enable autostart /queues

Re: OpenVMS cluster print queue setup

Wim Van den Wyngaert — Mon, 08 Mar 2004 05:49:26 GMT

Jan,

Just did a test. The failback has to be done by hand. (sorry for the bad format, they should make this form 80 char).

I am on node sbetv1.

>@wim.lis
>ty wim.lis
$ INITIALIZE /QUEUE wim -
/BATCH -
/START -
/AUTOSTART_ON = (sbetv1::,sbetv2::)
>sh que wim/fu
Batch queue WIM, idle, on SBETV1::
/AUTOSTART_ON=(SBETV1::,SBETV2::) /BASE_PRIORITY=4 /JOB_LIMIT=1
/OWNER=[SYSMGR,SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)
>disab auto/q
>sh que wim/fu
Batch queue WIM, idle, on SBETV2::
/AUTOSTART_ON=(SBETV1::,SBETV2::) /BASE_PRIORITY=4 /JOB_LIMIT=1
/OWNER=[SYSMGR,SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)
>enab auto/q
>sh que wim/fu
Batch queue WIM, idle, on SBETV2::
/AUTOSTART_ON=(SBETV1::,SBETV2::) /BASE_PRIORITY=4 /JOB_LIMIT=1
/OWNER=[SYSMGR,SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)

Re: OpenVMS cluster print queue setup

Jan van den Ende — Mon, 08 Mar 2004 09:50:08 GMT

Wim,

I never had to use it (on the contrary, we try to be as homogeneous as possible), but that is why I remebered the help text:

"
INIT/QUE/AUTO

... you can specify more than one node ... in the preferred order in which nodes should claim the queue.
"
So, eigther my understanding of English is not exact enough, or the help text is not clear enough, or the text is not (any more?) correct.

Sorry for any confusion I may have caused....

Jan

Re: OpenVMS cluster print queue setup

Wim Van den Wyngaert — Mon, 08 Mar 2004 11:02:15 GMT

Jan,

No problem. But if you were right, the command had to close the queue gracefully (/next) and then move it to the other node.
Since /next can take ages ...

Wim

Re: OpenVMS cluster print queue setup

M C_1 — Tue, 09 Mar 2004 09:30:36 GMT

Jan,
I agree with Wim, the autostart queues will not fail back to the problem node after its back up. And that is not necessarily a bad thing.

The reason I revived this topic was because I was unsure of how the queue manager worked with autostart queues. I understand how to set them up, just was not clear on how VMS started them on boot up. I confirmed what Wim said in a earlier reply, that autostart queues never stop unless someone or something issues stop/queue(even on shutdown). Therefor, there is no need to start queues on the cluster during boot only Enable Auto/Que in startup.

Thanks to everyone for their input. It has been very helpful.

MC

Re: OpenVMS cluster print queue setup

Wim Van den Wyngaert — Wed, 10 Mar 2004 02:48:45 GMT

MC,

If you want to do load balancing, schedule a job each day. For each queue, do a stop/que/next, wait until the queue is stopped, do a stop/que/reset (and a stop/id of the tcp symbionts because the symbion not always stops when doing stop/que) and a start/que.

This will
1) start the queue on the first node listed in the autostart list
2) reset the queue and will eliminate 80% of your printer problems (e.g. symbiont bugs, quota problems, etc)

Wim