eva5000 OS Unit ID and LUN for and Open Vms cluster system

[Luis Alberto González B]

I have a munual that say that there is that get special caution when assign a OS Unit ID to a system with VMS.

Also there is a note that say:
The OS Inuit ID must be unique in the host cluster.

My question are:

If a configure for example 10 virtual disk,

1-I have to assign differents OS Unit ID to each virtual disk, example from 1 to 10?

2-For the LUN also will be a good idea that be 1,2,4,5,6,7,8,9, and 10 respectively.

Also there is a note that say:

The OS Unit ID must be unique in the cluster host, really I am a little confuse,

[Uwe Zessin]

Salvatore,
in short form: 1=yes,absolutely! 2=it is ok that way

And now some details:
The 'OS Unit ID' and the LUN address are two different things.

The 'OS Unit ID' is a characteristic of a Virtual Disk (VD). When a VD is presented, OpenVMS takes this number and creates the device name from it. E.g. OS Unit ID = 4 gives device '$1$DGA4:', ID = 1357 gives '$1$DGA1357:'. The first part ('$1$DGA') is hard-coded in the OpenVMS device driver.

The LUN number is at which SCSI LUN address you map the Virtual Disk into the LUN adress space of the host. Each host has a different address space, so you can, e.g. map VD:'DATA01' to LUN #1 for host A and LUN #2 for host B. Assuming you have given the Virtual Disk the 'OS Unit ID':9 - on both hosts the resulting device will be '$1$DGA9:'.

You can leave the LUN address selection to the EVA and it will select a free number or you can assign them yourself (the EVA will not allow you to double-map two Virtual Disks to the same LUN address).

I hope it has become clear why you *MUST* make the OS Unit ID unique - otherwise an OpenVMS host is not able to tell devices apart. You risk crashing the system or corrupting your data.

[Luis Alberto González B]

Uwe.
I have another question:
How does OpenVms know whitch disk is going to be access by the cluster.
I mean if I present a LUN to a cluster, both system ;in my case are going to see the same LUN .

[Ken Robinson]

That's the beauty of VMS Clusters. You can mount the drives "/cluster" and all systems will be able to read and write to the drives.

[Uwe Zessin]

The EVA does only present blocks of data to the servers - like an ordinary SCSI disk.

OpenVMS has a distributed lock manager (DLM) embedded. You can mount the disk on both members and access it from both members concurrently and directly. The file system is cluster-aware and ensures volume integrity with the help of the DLM. That is nothing new - it has worked since the mid-eighties (one of my previous employers implemented a cluster with shared disks in 1985) - only the disk technology was different.

This is a different working like a Microsoft Windows Cluster (MSCS) which works on a 'shared-nothing' principle. Both servers can 'see' the disk, but only one server will mount it and lock the other out with a 'SCSI reserve'.

Do you have any experience with clusters?

[Mike Naime]

The VMS lock manager allows you to have multi-node clusters ( I have seen a 100 node cluster back in the mid 90's) that can read/write the same disk volume all at the same time without corrupting your data like an MS cluster would.

I good example of how this cluster technology is used today is Oracle Parallel server running on a 2-node cluster. Both nodes can see and access the database drives at the same time.

[Anton van Ruitenbeek]

Salvatore,

The SAN doesn't know or the node is a cluster member or not. Even for VMS it doen't matter. Actualy the message should be: The OS Unit ID should be unique on the whole SAN (per Fabrik ofcourse).
So if you're a VMS node in or without a cluster, the OS-U-ID should be unique because VMS is (as posted before) connecting to $1$DGA,

AvR

[Uwe Zessin]

An EVA system is usually connected to two different fabrics. As all virtual disks are presented through all four controller ports, the same ID will be visible in both fabrics. That is not a problem for OpenVMS, because it has multipath handling built in, so it knows that all paths belong to the same virtual disk. The problem comes up when a second virtual disk has the same ID and is presented to the same server(s).

[Mike Naime]

There are 3 different ID's that the EVA uses to track the Vdisks.

The WWID of the LUN is a long string that uniqely identifies the VDISK.

The "LUN ID" is equivalent to the Dxx unit number in an HSG80 controller. This is the ID that AIX uses to identify the LUN. VMS ignores this ID number.

The OS unit ID is what VMS uses to present the LUN to the VMS OS. (Widoze uses this too)

If you used OS ID of 5, your VMS system would then see a $1$dga5 device.

As Uwe stated, this needs to ber unique for the cluster that it is being presented too. At the EVA controller level, I could have multiple disk with OS ID of 5. The EVA itself does not have a problem with this since it tracks by the LUN WWID. The VMS system would only see 1 $1$dga5 device that was the size of the first one presented to it.


Worry about your OS UNIT ID numbers. Let the EVA assign the LUN ID's as it will. They do not matter to the VMS system.

We also try to make these OS LUN ID's unique within the SAN fabric. We now have over 1500 LUNS active on our SAN fabrics. About 250 Servers using 48 storage array controllers.


Mike Naime

[Uwe Zessin]

Windows does not use the 'OS unit ID'. This is a special implementation for AlphaServer boot + dump support and OpenVMS unit number assignment using a vendor specific SCSI mode page.