| 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 00: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 10: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 13: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 07: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 10: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 12:52 | 2 | 
|  |     
    Check out note 4491.*
 |