Replacing a Quorum Disk

[comarow]

No, you should not mirror a quroum disk.
It is possible each part of the cluster will see another part of the quorum disk and you'll partition the cluster.

That's why shadow disks are not supported for clustering.

As far as building quorum disk, the trick is it doesn't use the quorum disk until after you boot. So boot once with enough votes to build the quorum.dat file.

example set votes 3, expected 4 and qdskvotes 1 for 1 vote, then reset it back to 1 vote.

good luck. It's easy

[Richard W Hunt]

good point, comarow

Host-shadowed system disks should not be used for quorum disks. Controller-mirrored disks, since they are mirrored even when the system isn't "up," are viable candidates.

[Robert Brooks_1]

With respect to quorum disks and host-based volume shadowing -- you CANNOT use either
a shadow set virtual unit or a shadow set member device as a quorum disk.

Statements like "you should not do this" are somewhat irrelevant, since you CANNOT do this.

This restriction is enforced in the code. If you attempt to violate this, you'll see the error message

\%CSP-E-QDSHADOW, Quorum disk may not be a shadow set or a shadow set member\

(For those with access to the source listings, this is found in module [SYSLOA]CSPQUORUM)

You can, of course, use a controller-based mirrored set as a quorum disk.

Some of our more paranoid customers use mirrorsets as shadow set members for important devices.

[Jan van den Ende]

That DOES raise an interesting question.

I am not well enough into storage, but _IS_ it possible nowadays to create multi-site _MIRROR_ sets?
Because that _WOULD_ open up the possibility of configurations which are so rightly prohibited by not allowing to shadow quorum disks.

-- and I happen to know just the person to immedeately implement it!

Uwe, maybe this fall in your area of expertise?

Proost.

Have one on me.

jpe

[Uwe Zessin]

Sure, any half-way competent in-band virtualization appliance can mirror between two different storage arrays that can be located in two different data centers. They are true mirrors and not a 'replication' implementation like DRM/CA.

Another way is the XIOTECH Magnitude storage arrays. There is a configuration that puts both controllers into different data centers. Last time I checked, the back-end connects via FC_AL to the controllers and can be distributed as well.

OpenVMS support... well that's a different thing.

[Jack Trachtman]

For those of you still interested, here's what I wound up doing (after much discussion w/HP).

1) Because there were still 2
"Transactions"/channels open to the Quorum disk on one node in the cluster, I was not able to cleanly DISMOUNT it. HP was not sure what would happen in this case if I simpley recreated the same virtual-disk.
So the usual method of replacing the failed disk and rebooting 1 node was riskly and not acceptable to me. For this reason & because I needed to minimize the downtime, I decided to replace the failed disk with a disk with a different unit #.

2) Created new v-disk. Confirmed accessibility from both nodes. INITed disk.

3) Changed MODPARAMS.DAT DISK_QUORUM & ran AUTOGEN on both nodes.

4) Shut down what I'll call our "non-production" node, using the SYSHUTDOWN option of REMOVE_NODE. Other node successfully transitioned to 1-node cluster.

5) Shutdown "production" node and rebooted in Converstational mode.

6) Set EXPECTED_VOTES to 1 & continued boot.

7) Node successfully created QUORUM.DAT file on new disk.

8) Successfull rebooted other node.

I want to thank everyone for their input. This was obviously a situation I had no experience with and both HP's docs and tech support help were not giving me enough insight so that I felt comfortable with my plans. The info from this forum (plus some testing) got me through it.

PS - Not done yet! I'm about to post another question in the same category!