T.R | Title | User | Personal Name | Date | Lines |
---|
5306.1 | Seems straightforward to me | GIDDAY::GILLINGS | a crucible of informative mistakes | Fri May 09 1997 01:48 | 14 |
| Simon,
>unless I can
>justify the action to him and I just can't find the words
How about:
If you want to stop the "lost connection to quorum disk" messages then
you should adjust QDSKINTERVAL upwards. Otherwise just ignore the messages
as they are self correcting and not harming anything.
Even better, change the cluster configuration so you don't need a quorum
disk at all!
John Gillings, Sydney CSC
|
5306.2 | | COMICS::MILLSS | "Jump! Jump now!" ...Kosh | Fri May 09 1997 11:39 | 13 |
| Re .1
Thanks, John. I've tried that approach but the customer was having none of it.
He won't change anything unless we can state specifics, i.e. "change this
parameter here to prevent that timeout there from exceeding this limit, etc"
I think if I were just to tell him that an i/o from the q disk watcher will
timeout after 0.1 seconds then that might satisfy him. It might not. Its worth a
try, though!
Thanks,
Simon.
|
5306.3 | _VAXcluster Principles_ | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Fri May 09 1997 14:42 | 14 |
|
Get the customer a copy of Roy Davis' VAXcluster Principles manual.
If the quorum disk cannot be reached in 2*QDSKINTERVAL, then the
VMScluster will begin recalculating the quorum. All VMScluster
nodes should (normally) have the same values for QDSKINTERVAL.
I would also determine if there is a need for a quorum disk in
this configuration, or if there is a better configuration that
may be created. (There are a number of folks that have a quorum
disk when they do not need one, and there are a number of folks
that have a mis-set EXPECTED_VOTES value, etc. A comparison of
the SYSGEN> SHOW/SCS output for each node will catch most of these
common errors.)
|
5306.4 | | COMICS::MILLSS | "Jump! Jump now!" ...Kosh | Mon May 12 1997 08:17 | 19 |
| Re .3
Thanks for the info, Steve. What I'm after is the time that the quorum disk
watcher waits before deciding it can't complete its read and/or write to the
QUORUM.DAT file. Is it really 2*QDSKINTERVAL ? My customer is saying that he
does have a lot of outstanding i/o's at the time, but none of them take anywhere
near 1*QDSKINTERVAL let alone 2*QDSKINTERVAL to complete.
QDSKINTERVAL is not the issue here. Its the time that the touch of QUORUM.DAT
takes that the customer wants clarifying.
As for configuration, its a two node cluster. I suggested a quorum VAX but he
doesn't want to do that.
Thanks for any input and please correct me if I'm misunderstanding anything :^)
Regards,
Simon.
|
5306.5 | 2*QDSKINTERVAL; Need Info... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon May 12 1997 11:20 | 23 |
|
Please acquire the manual, and pass it along to the customer. Also
pass along an internals and data structures manual. This combination
usually either overwhelms the customer, or it educates them. :-) And
in either case, we all benefit.
The interval before the quorum watcher "gets upset" is twice QDSKINTERVAL.
:As for configuration, its a two node cluster. I suggested a quorum VAX but he
:doesn't want to do that.
The quorum host makes for faster quorum transitions.
I need to know the hardware configuration of the quorum disk. It is
distinctly possible that the quorum disk is unnecessary, depending on
the particular disk interconnect configuration. (That you have a two
node VMScluster is useful; it's the most common configuration found
with a quorum disk... But is this quorum disk on a SCSI bus, a DSSI
bus, via a CI storage controller, and what are the two host types?
And as requested, the SHOW/SCS settings are also of interest here.
(I've seen more than a few customers with errors on their VOTES values,
their EXPECTED_VOTES values, or other VMScluster SYSGEN settings...)
|
5306.6 | See note 4491.* | CSC32::T_SULLIVAN | | Mon May 12 1997 13:52 | 2 |
|
Check out note 4491.*
|