What is device name for IM Raid 1 on Integrates SAS controller?

[Cass Witkowski]

We are looking at using the built in SAS controller on the rx2660 to create RAID 1 sets. From my reading of the documentation it appears that the configuration utility generates a unit id for the newly created RAID set. I'v seen DKA4 or DKA1 and DKA3 in the documentation.

My question is is there any rhyme or reason for how these unit id's are selected. It would be nice to have some control over them.

Thanks,

Cass

[Hoff]

It is usually best to ignore the device names.

I've learned it is safer to assume that there is no rhyme or reason to what the operating system, the firmware and the current hardware configuration might concoct as a device name.

Each instance and each configuration might well be predictable at some moment, but then somebody somewhere (in a tall and sometimes rickety stack of related pieces of hardware and I/O controllers and firmware and host OS and application software) goes and changes something.

Even when I know I can reliably predict a disk name, I deliberately choose to not do so. This given I may eventually want to move the bits to a disk that's less predictable, or simply to another disk.

The device UUID/WWID/GUID gets a bit closer to an absolute and reliable name, but even that doesn't work the way I'd want.

This is what logical names are intended for on OpenVMS, and what hard and soft links are for on Unix, Linux and Mac OS X.

I've taken the view that device names are arbitrary handles solely for the convenience (and sometimes capriciousness) of the operating system and the lowest-level application software, and are otherwise something to be studiously ignored.

Protect yourself and your applications with proper and regular use of logical names.

[Cass Witkowski]

Hoff,

I understand the need for logical names. It is more of a maintenance issue. If I have 100 of these servers (at different locations) and I and others are managing them it is a lot easier if there was some consistency to the naming other than saying well the system disk may be named DKA1 at 30 of the sites or DKA4 at 40 or DKA2.5 at the rest (tongue in cheek)

I am comparing this to HBVS where I have control over the names I use.

[Bill Hall]

Unless you can dictate the exact same hardware for each system with absolutely no variances, you really have to go the "logical" route.

SYS$SYSDEVICE is always the boot device. If you don't like that logical name define another one in SYLOGICALS.COM. Example:

$define/system/exec Your_Own_LNM 'F$TRNLNM("SYS$SYSDEVICE")'

Mount all of your data disks specifying a consistent set of logical names across all of your systems. Example:
$mount/system [volume label] [Your Own LNM]

Use rooted logicals liberally to hide physical devices and/or directories from yourself and your users. Examples:

$define/system/exec/trans=conc APP_DATA01 USR_DISK09:[APP_DATA01.]
$define/system/exec/trans=conc APP_DATA02 USR_DISK12:[APP_DATA02.]

Bill

[Jon Pinkley]

RE:"I am comparing this to HBVS where I have control over the names I use."

You have control over the DSA name, but you still need to specify the physical name in the mount command.

In my opinion, the only place physical device names should be used is in the mount commands, and in modparams for things like the quorum disk (this won't apply for your built in RAID controller). Everything else should be using the logical names that mount creates (DISK$label unless you specify something else on the mount command), or application specific logical names that are generated at startup time after the disks are mounted.

Then you can use generic command files for everything except the startup files used to mount your disks. We have a file that does nothing but mount disks, and every time we add a drive or change a disk volume label, that file gets updated (manually).

There is no "mount/system/override=identification" and you can't mount a disk privately that is already mounted somewhere in the cluster. There are ways to determine the label of an arbitrary disk whether it is currently mounted for shared access or not, but if you choose to use such a mechanism, you must ensure there are no duplicate labels, otherwise the first one found will be the one used. The method used is to packack the device and then read the home block to determine the label.

So I am agreeing with Hoff and Bill, use logical names. Your documentation should use the logical names as well, e.g. The XYZ application has its data files on the XYZ$DATA disk, and its log files on the XYZ$LOG disk.

There really isn't any way to avoid this unless you have identical hardware at every location and never plan to change it. You have very little control over what names are assigned to the controllers (e.g. fibre channel disks are $1$dga)

RE:"is there any rhyme or reason for how these unit id's are selected?"

I don't have an IA64, but if the controller is similar to other built in controllers I have used, it probably assigns the lowest available unit number when a device is created. Hopefully it won't renumber the units if the lowest one is deleted.

Jon

[Cass Witkowski]

I understand about logical names. My point is that if I am trying to maintain 100 identical server with this IM and I don't have a good feel for how the how consistent the devices will be named then I have a potential maitenance problem.

It's not about after OpenVMS is booted and I can use logical names. It is about before OpenVMS is booted or there is some problem with the disk and OpenVMS can't boot. So I have these two IM and they may be called DKA1 or DKA3 or DKA4 or something else. I don't know. I don't know the naming scheme. I don't know if it will be consistent over 100 identical servers.

So at 3:00 in the morning how do I find out which one is my system disk if I can't boot from it? If there is a problem with the RAID sets and I can't access the disk how do I access the EFI routines to even run the SAS configurator to tell me which disks are actually making up the raid sets?

If I have a 100 servers and I can always depend on the fact the the raid set for the system disk will always be named DKA1 then it makes my life a little easier at 3:00 in the morning.

[Hoff]

Device names are to be avoided.

OpenVMS itself does not provide tools to manage physical devices in the fashion you seek; there's no analog to the logical volume manager (lvm) around within OpenVMS. (There are some hidden gems around, such as the SYS$EXAMPLES:MSCPMOUNT.COM tool. But no general solution is shipped within OpenVMS.)

It is entirely feasible to create an lvm for your requirements, or an installer tool, or a combination of these tools. And I'd make the tool as immune to the particular device configuration as I could manage. (I certainly would not mind rolling a custom lvm tool; that'd be a fun project. And an lvm for a fairly-similar collection of boxes would be easy.)

That written, using a grid or a cooperating collection of servers that request or that distribute the work are my general preferences. Beyond a baseline health-check, I'd rather not be polling or managing boxes. I'd rather build the boxes to manage themselves.

As for remotely managing and maintaining these boxes, I'd probably look to something akin to OpenView, or to acquire or build a tool more directly built on SNMP or such.

When I've managed these configurations for folks, I've often looked to create custom installation kits and recovery disks. This deals with a couple of issues, not the least of which is figuring out what disks are present.

And yes, you have one hundred (fairly or completely) similar systems now, but what happens when the next hundred somewhat or mostly-different systems arrive, or when some change in device names arises across your boxes? The correct answer is still logical names.

[Cass Witkowski]

Thanks for the discussion. We've decided to use HBVS

Now we are using the IM to save money.

Front what I can tell from messing around with these things is that the device name that is created is based on the physical slot of the first disk you put into the IM

We used the disks in slot 1 and slot 2 and the device was DKA1. The IM using disks in slot 3 and slot 4 has a device name of DKA3

[The Brit]

Cass just a quick comment, I'm not sure how HBVS helps you out here.

Your complaint is that you have no control over the physical disk names, specifically at the boot/efi level.

HBVS only makes your disk volume naming consistent after the system has booted, and as pointed out by John, you need the physical disk names to create your shadow sets.

This being the case, you could solve your naming problem just using logicals, as suggested earlier.

(I am not trying to talk you out of using Volume Shadowing, on the contrary, I think that is virtually a requirement for anyone who wants their apps to be UP most of the time)

???

Dave.

[Cass Witkowski]

Dave,

This is not an issue of logical name. It was figuring out the names of the devices at the physical level and trying to make them consistent for 100 sites. This is for dealing with them when disks fail. Not when OpenVMS is up and I can use logicals.


When I first posted this string I had no dealings with the SAS controller. Now I do.