Why does it take so long to build QUORUM.DAT

[Jim Geier_1]

Since the field test of clusters, I have wondered why it takes so long to create a QUORUM.DAT file on a new quorum disk. Back in the VAX/VMS V4 days with RA81 disks, it could take as long as 90 minutes for the quorum file to be created. Yesterday I added a quorum disk to an ES45-based cluster with HSG80-based storage and after 15 minutes of "waiting to form or join a VMScluster" I booted another node conversational, gave it enough votes to preclude the need for the quorum disk, and the cluster formed. I checked on the quorum disk, and the QUORUM.DAT file was indeed present in the MFD as expected. I then shut down all systems, booted the first one requiring the quorum disk, and no time at all was needed to find the quorum disk and form the cluster.

So just what takes so long to build QUORUM.DAT that from what I can tell is an empty file?

[Andy Bustamante · Accepted solution]

>>>I booted another node conversational, gave it enough votes to preclude the need for the quorum disk, and the cluster formed <<<

A cluster needs to have quorum available to create the quorum.dat file on the quorum disk. If you boot a single node with votes=1, expected_votes=3, qdskvotes=1 and disk_quorum="$1$dga99" You'll only have 1 vote available. The cluster won't have quorum and activity will be blocked. No creating quorum.dat. Your conversational boot is the usual solution.

VMS Engineering has warned against copying attempting to create this file manually in the past.

[Robert_Boyd]

What was your value of RECNXINTERVAL set to?

And what about QDSKINTERVAL ?

I'm not sure, but I'm thinking that both of these parameters could come into play under the circumstances you describe when there is no QUORUM.DAT already in place.

Robert

[Jim Geier_1]

RECNXINTERVAL is the default, 20 seconds, and QDSKINTERVAL is set to 10 seconds.

I suspect the previous answer make the most sense, that quorum has to exist before the QUORUM.DAT file can be created. And from years of experience, it seems that until the quorum file is there, the votes for the quorum disk are not counted, thus the need for the conversational boot and a temporary change in votes to get the requisite number of votes to create QUORUM.DAT.

[Ian Miller.]

What you have found makes sense

The quorum file has to be be there before the votes are counted - thats what its for really.
As the cluster is basically hung until quorum is available then it can't create QUORUM.DAT

IIRC QUORUM.DAT contains node names and time stamps. I have a vague mememory it can be dumped but don't remember the details.

[Volker Halle]

Jim,

as has already been said, a QUORUM.DAT file can only be created, if the node/cluster has enough votes to run without the QDSKVOTES to be provided by the quorum disk.

The QUORUM.DAT file will be created by the CLUSTER_SERVER process on the disk pointed to by DISK_QUORUM. Please note, that this disk must be MOUNTED to allow the QUORUM.DAT file to be created - not a problem if it's a system disk, but needs to be taken into account, if a non-system disk is used as a quorum disk.

The quorum disk votes (of a quorum disk with an existing QUORUM.DAT file) will be couted, even if the disk is NOT mounted, but you will get OPCOM messages asking to mount the quorum disk.

Volker.

[Garry Fruth]

QUORUM.DAT is not empty. DUMP/ALLOC xxx:[000000]QUORUM.DAT and you will see data.

If a system attempted to create the quorum file before quorum was reached, there would be a risk of corruption. E.G. Two systems booted simultaneously before a cluster is formed could try to create the quorum.dat file simultaneously. The two systems may not be able to communicate with each other. The two systems could have different ideas about what LBN to put the file on. You could even wind up with a partitioned cluster if the systems could not communicate with each other due to a bad cluster interconnect.

[comarow]

Just to be clear, the only supported way to build quorum.dat is to boot a cluster with enough votes.

I think you were waiting for enough votes.

There are several ways to deal with this. You could do ONE boot with disk_quorum = newdisk, qdskvotes =1 votes 3 expected 4 and it will boot and build quorum.dat

Then reboot the node and set the votes on the node back down.

The problem of booting both nodes at the same time if they share a system disk is they will be fighting for the same resources.

I suspect the time you were waiting was while you had enough votes to get quorum, or were booting nodes at the same time.

[Jim Geier_1]

The answer was clear in the second entry, and while some of the additional comments were useful, nothing new is emerging.