1748015 Members
4802 Online
108757 Solutions
New Discussion юеВ

Re: Naming quorum disk

 
SOLVED
Go to solution
Willem Grooters
Honored Contributor

Naming quorum disk

Accorsing the manuals, a shared system disk can be quorum disk in a two-node cluster. My porblem is the naming.
I have set up NodeA and NodeB to have their shared system disk as quorum disk as well; this disk in on shared SCSI, on both systems connected to PKB. The "other" side is a HSZ50 controller, and the system disk is configured as DISK100 - so both machines will therefor boot from DKB100 (as seen from SRM), but the disk will be accessable from VMS as "$116$DKA100" - 116 is the port's alloclass.

Both nodes have a local SCSI controller PKA with disks attached. NodeA has just one disk on LUN 0, therefore this disk is accesable as :DKA0. NodeB's disks are on LUN.s 1 and 2, therefore the disks are know as "DKA100" and "DKA200".

I have set up the quorunm disk to be "DKA100" on NodeA", but that will be a problem on NodeB.

My problem nw is: What name for quorum disk should I give to the question in CLUSTER_CONFIG (and MODPARAMS.DAT):
DKA100?
$116$DKA100?
DKB100?

Or should I use another disk? Since it must be directly accesable to all nodes, the only way I can think of, is use any disk on the shared SCSI. But that gave me trouble as well: Specifying "$116$DKA101" gives me a problem booting NodeA: The startup log gives me a message it will use remote access the quorum disk, and it won't boot at all. That is: it will try to form a cluster and there it ends.
Does a quorum disk need to be mounted when requested?
($$16$DKA100 didn't work either: same problem)
Willem Grooters
OpenVMS Developer & System Manager
10 REPLIES 10
Hein van den Heuvel
Honored Contributor
Solution

Re: Naming quorum disk

>> on shared SCSI, on both systems connected to PKB

So the quorum disk MUST be on that bus.

>> Both nodes have a local SCSI controller PKA with disks attached.
>> I have set up the quorunm disk to be "DKA100" on NodeA.

Willem, is there a typo / poor word choice in this? (ok, other than the quoruNm :-). The quorum disk has to be shared, as you indicate, yet you picked a disk on a local bus?

The "Port Allocation Class" is supposed to resolve this naming conflict for you.

From the manual:

"A port allocation class in a device name designates the host adapter that is used to access the device. The port allocation class replaces the node allocation class in the device name, and the adapter controller letter is set to the constant A. "

"http://h71000.www7.hp.com/doc/732FINAL/6318/6318pro_006.html#hsz_alloc_h
6.5.2 Review of Port Allocation Classes
Picture 6.5.3

hth,
Hein.
Willem Grooters
Honored Contributor

Re: Naming quorum disk

Not sure, that's the point. There is no local device "DKA100" on NodeA, there is on NodeB (and that may cause a problem there).
But I did try another disk on shared SCSI ($116$DKA101) but for some reson, NodeA didn't boot with that spec, IIRC.

-- Just done: Quorum disk = $116$DKA100 (the system disk). At some point, I got the message "Quorum lost" and all activity would stall, but luckily, quorum was regained and the system came up as it should.

Why QURUN_DISK="$116$DKA101" didn't work, I cannot tell, but it _might_ have to do with other votes/expected_votes values. That disk is mounted later on in the startup process. Would that matter?

Anyway, it seems I indeed had to add the port allocation class, and the right answer was indeed "$116$DKA100".

Case closed
Willem Grooters
OpenVMS Developer & System Manager
Willem Grooters
Honored Contributor

Re: Naming quorum disk

Not yet...

On VMS, port allocation is now set to be 116 on both machines (obviously). The HSZ50 however, has no such functionality as on HSZ70 (there seems to be no "SET THIS_CONTROLLER ALLOCATION_CLASS = " command.

Secondly, the cards on the VMS boxes specify SCSI_ID 7 and 6 respectively. The HSZ50 hoewver shows SCSI_ID =7 as well. Does this matter, of should that be changed as well? (I don't have a fail-over configuration, need just multiple servers access all disks without requiering another system). The HSZ70 and HSZ80 examples show this, but no data is found on HSZ50.
Willem Grooters
OpenVMS Developer & System Manager
Hein van den Heuvel
Honored Contributor

Re: Naming quorum disk


>> On VMS, port allocation is now set to be 116 on both machines (obviously). The HSZ50 however, has no such functionality as on HSZ70 (there seems to be no "SET THIS_CONTROLLER ALLOCATION_CLASS = " command.

I got the impression that the piece of documentation i pointed to tried to address this as well.

>> Secondly, the cards on the VMS boxes specify SCSI_ID 7 and 6 respectively. The HSZ50 hoewver shows SCSI_ID =7 as well. Does this matter, of should that be changed as well?

An HSZ50 has 2 types of SCSI IDs.
The first type is listed in "SHOW THIS FULL", before the "Host Port:" as "SCSI address x" and this it address it uses to control the attached disks on the back-end scsi bus. That number must not conflict with any of its attached disks and not conflict with the 'other' control. Typically it is 6 or 7.

The second type is a group of IDs.
It lists under "Host port:" as for example.
SCSI target(s) (1, 2, 3, 4), Preferred target(s) (1, 2).

Those are visible to VMS and must not conflict with any of the VMS HBA SCSI addresses. They are typically below 5, as the OS HBA addresses are typically 6 or 7.
These SCSI addresses end up as the N in DKxNnn

Hein.



Hoff
Honored Contributor

Re: Naming quorum disk

The process of mounting the quorum disk is a secondary issue, and mounting the disk is not necessary for the quorum disk to contribute its votes to the cluster. The only time that mounting is central is when you are initially setting up the quorum disk, and when it is not yet contributing its votes. You do want to mount the disk, but the disk contributes its votes long before you can mount it.

The device name specified for the quorum disk must be the same name for all nodes referencing it.

If you have the same physical device represented with different units or different allocation classes across various hosts in a cluster, then the configuration is probably broken. The device name is how OpenVMS knows the disk is the same disk; multiple different unit numbers for the same device is usually a recipe for corruptions. (There are a few select cases where there can be two names for the same device, such as scsnode$ddcu: and $alloc$ddcu: for the same device.) This whether the particular disk is a system disk or a quorum disk or otherwise.

There are cases with shadowing where you can have multiple different disks as the system disk, and that's permissible.

You can have controller-based mirroring for system disk or a quorum disk, and host-based shadowing for the system disk, but you cannot have host-based volume shadowing for the quorum disk.

And with the StorageWorks RAID Array 450 series HSZ50, pick one to four SCSI ids for the controller, and yes, these must be unique across the SCSI bus. This includes across the host controllers, which themselves must be unique, and across any disks or tapes directly connected to the SCSI bus.

The port allocation class is how you can usually deal with cross-linking SCSI buses. Both nodes sharing the SCSI must be configured with the bus in the same allocation class.

And as for the system parameter, you'll want to specify the same $alloc$ddcu: disk name on both nodes; as the quorum disk.

Or hang a disk (directly) off a shared SCSI, and use that. With or without allocation class.

Stephen Hoffman
HoffmanLabs
Willem Grooters
Honored Contributor

Re: Naming quorum disk

Just for confirmation:
HSZ50
Controller: SCSI_ID = 7
Host port: SCSI targets (0,1,2,3)

Then:
NodeA-PKB should have SCSIID = 6
NodeB-PKB should have SCSIID = 5
NodeC-PKB should have SCSIID = 4

and that would never give a conflict - unless I want to connect a NodeD on that bus.

Willem Grooters
OpenVMS Developer & System Manager
Hein van den Heuvel
Honored Contributor

Re: Naming quorum disk


> Controller: SCSI_ID = 7
> Host port: SCSI targets (0,1,2,3)

Thanks. So my suspicsions were correct. No conflict. With that scsi_id = 7, as is it on a different bus, the backend/drive bus.

> NodeA-PKB should have SCSIID = 6
> NodeB-PKB should have SCSIID = 5
> NodeC-PKB should have SCSIID = 4
> and that would never give a conflict -

Right.

> unless I want to connect a NodeD on that bus.

Yes, in which case you could stop using scsi target 3 on the HSZ. But more than 2 active initiators on a shared parallel scsi but feels like a bit much.

If all those nodes are created equal or very similar, then a 4th node might be the moment to consider going to fibre. The parallel scsi cabling would get a bit excessive / error prone at that time:

Terminator - Y(A) - BN21 - Y(B) - BN21 - Y(C) - BN21 - Y(D) - BN21 - Trilink(HSZ) - Terminator.
Adding a node would halt the cluster.

If one were to desire more than 3 nodes then I would consider using MSCP served devices instead of shared parallel scsi bus devices.

fwiw,
Hein.

Willem Grooters
Honored Contributor

Re: Naming quorum disk

I just wonder - if NodeA has SCSI-ID of 7 on PKB0: why is there no problem with SCSI-ID of 7 on the HSZ50? Just when NodeB (with SCSI_ID=6) comes into play, there is this trouble of disk dropping offline and into mount verification - and succeeding.
Willem Grooters
OpenVMS Developer & System Manager
Willem Grooters
Honored Contributor

Re: Naming quorum disk

The basic issue has been solved: naming is now clear: should be as VMS knows it.
In this case: $$
Willem Grooters
OpenVMS Developer & System Manager