Replacing Quorum Disk

[issinoho]

Should we wish to swap quorum disk, DISK1 to another disk, DISK2 on a 2 node cluster, can I just confirm that the process would be as follows.

Modify sys$system:modparams.dat on server 1 so that,

Code: Select all

DISK_QUORUM="DISK1"

Becomes,

Code: Select all

DISK_QUORUM="DISK2"

Autogen and reboot server 1.
Reboot above on server 2.

Can I further confirm that nothing in the above sequence will initialise or otherwise affect any data already on DISK2 ?

Thanks.

[shael_richmond]

Yes that's all there is to it. The quorum disk is just the file quorum.dat so it won't initialize/overwrite a disk.

I've moved my quorum disk around when turning on host based shadowing for migrating storage.


Shael Richmond

[issinoho]

Great! Thanks, for the prompt reply.

[volkerhalle]

Careful !

Please note the following:

- there can only be ONE active quorum disk in a cluster
- after you reboot the first node, the NEW quorum disk will not become active
- if you then reboot the second node (after AUTOGEN), both nodes will see each other and should agree on the quorum disk
- if the 2 nodes can form a cluster WITHOUT the votes of the quorum disk (note: QUORUM.DAT has NOT YET BEEN CREATED on the new disk), then one of the nodes will create QUORUM.DAT on the new quorum disk, if that disk is mounted ! And then the QDSKVOTES of the quorum disk will be counted !
- you need to make sure, that the 2 nodes can form a cluster WITHOUT the quorum disk votes being present
- the typical setup would be: VOTES=1 for each node, EXPECTED_VOTES=3 and QDSKVOTES=1

Volker.

[issinoho]

- the typical setup would be: VOTES=1 for each node, EXPECTED_VOTES=3 and QDSKVOTES=1

Thanks, Volker, this is indeed how things are currently set up.

[baldrick]

Couple of additional notes here...

QUORUM.DAT is only created IF the cluster already has quorum so if the votes of the quorum disk are needed (to provide quorum) the quorum file will not be created and your cluster will still hang.

When rebooting, one mitigation for the above is to use the REMOVE_NODE option which causes effectively a SET CLUSTER/EXPECTED_VOTES after the removal of the leaving node's vote. This should ensure that quorum was maintained, and the new QUORUM.DAT file can be created on the new disk. This may reduce the "dynamic" expected votes to be lower than the proper and correct expected votes, so caution is advised.

The general mechanism is that systems with access to that file "announce" their presence to that file, and the rest of the systems present in the cluster reads that file and check that they have a direct link to all the systems listed in that file.

This can be another symptom of "sending request to... sending request to..."