- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Naming quorum disk
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 02:06 AM
тАО01-21-2007 02:06 AM
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)
OpenVMS Developer & System Manager
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 03:32 AM
тАО01-21-2007 03:32 AM
SolutionSo 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 04:07 AM
тАО01-21-2007 04:07 AM
Re: Naming quorum disk
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
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 04:26 AM
тАО01-21-2007 04:26 AM
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.
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 05:31 AM
тАО01-21-2007 05:31 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 05:44 AM
тАО01-21-2007 05:44 AM
Re: Naming quorum disk
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 06:14 AM
тАО01-21-2007 06:14 AM
Re: Naming quorum disk
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 07:28 AM
тАО01-21-2007 07:28 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 07:40 AM
тАО01-21-2007 07:40 AM
Re: Naming quorum disk
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-21-2007 08:19 AM
тАО01-21-2007 08:19 AM
Re: Naming quorum disk
In this case: $
OpenVMS Developer & System Manager