can I exclude DGA devices from SYSMAN IO AUTO?

[H_Bachner]

With MC SYSMAN IO SET EXCLUDE=DKB* I can permanently exclude disks from SCSI controller B from autoconfiguration.

Can I also exclude fibre channel (DGA) devices? The docs (and help for IO AUTO /EXCLUDE) say this is not possible (the text is somewhat strange, but that's a different topic). But the docs also say that FGA devices can be excluded.

Lacking my own SAN playground, may I ask the community whether IO SET EXCLUDE=FGA* will exclude dga devices from autoconfiguration or not? (Except for the system disk, of couse, in case I boot from the SAN)

If yes, can I configure specific devices with

$ MC SYSMAN
IO SET EXCLUDE=""
IO AUTO /SELECT=(dga10,dga20)
IO SET EXCLUDE=FGA*

and won't see any other SAN disks even if zoning allows me to see them? (Similar code works for SCSI). Or do I need to IO AUTO /SELECT=FG as well?

Thanks for your ideas,
Hans.

[John Gillings · Accepted solution]

Hans,

I don't think that will work. Consider, you need to talk to the SAN device, FG* to find out what devices are available. If you exclude FGA* then you can't see the DGAs at all.

I'm not sure I understand your objective. You want to make sure disk devices which are visible on the SAN, but you don't expect, to be unavailable? An alternate way to achieve that would be to execute the MOUNT commands for the disks you want, then do a device scan for DGA*. Any disks you find that aren't mounted, set to /NOAVAILABLE

$ IF .NOT.F$GETDVI(dev,"MNT") THEN SET DEVICE 'dev'/NOAVAILABLE

This will block attempts to allocate or mount the devices.

You could also generate a warning list to be sent to your SAN manager so fix the zoning ;-)

Also remember that if you did manage to block unexpected DGA devices from being configured, you will almost certainly confuse any future system managers (or even yourself) when you can't work out why you can't see a disk you WANT to configure!

[Jon Pinkley]

I wasn't successful in excluding DG devices in my try. See attached logfile of boot on ES47 connected to SAN with EVA6000.

It does appear you can select only specific DG devices, but any subsequent auto configs will grab all DG devices that are being presented to the system.

Can you explain what you are attempting to do?

If your SAN disk controller has selective presentation, then that would be the better solution. I am not sure if it would be possible to have an SSSI script that unpresented devices before doing an io auto; probably not in the VMS Cluster case (see below).

I think the problem is that once the port driver is loaded, you can't exclude DG devices, and if you booted from a DG device, the PG and FG drivers are already loaded.

I just tried booting off a locally attached SCSI disk to test that, but I also booted as a "cluster", and in that case, the auto configure occurs very early in the boot process. If there is a way to control that auto config, I don't know off the top of my head.

I still think your best bet to prevent the system from ever seeing the devices. I don't think zoning will help unless you can exclude LUNs (this isn't a standard feature of our switch), and the EVA6000 has selective presentation, which is a cleaner solution in my opinion. Essentially you tell the EVA that you want a vdisk presented to a set of hosts. All other hosts will not see the device.

Perhaps Uwe Zessin will read this. He will probably know if there is a way to prevent VMS from seeing DG devices.

Good luck,

Jon

[Anton van Ruitenbeek]

Hans,

To be honest, I can't find a reason for doing this. To see a device doesn't mention you need to use it. First, the devices must have a LUN ID before you can use it. Secondly, if you were using an agressive operatingsystem like MSWindows you need this because during boot it grabs what it sees and this create corrupted other then MSWindows disks.
If zoning isn't correct and LUNs are added you only see the disks and it's up to the manager (you) to use or not use it.
Otherwise, its fine to see the disks so you know there is a false configuration.
The only thing we realy need is a method to remove disks out of memory of the OpenVMS system. Once created you can't remove it without a reboot. I know a systemengineer mentioned he created such a tool but only for own perpose.

AvR

[H_Bachner]

Thanks for all of the suggestions, especially to Jon for the extensive testing.

I'm aware about the possibility to SET DEV /NOAVAIL and this will probably be the way to go, lacking better alternatives.

I certainly owe you the reason for the question, i.e. what I really want to achieve. One of my clients runs a dozen or so Alphaservers (DS20, DS20e, DS25) in a 24*7 production environment. Disks are all in the SAN (several HSG80s). We are currently working on making the Alphaserver configurations (mainly network, and SCSI adapter for tapes) match as close as possible so we can configure a spare machine which can replace any of them in case of a hardware failure.

If a problem arises at - say - 2 a.m. and the staff on duty finds out that the hardware can't be fixed within two or three hours, they should be able to:
- move the spare machine close to the broken one
- take off network and SCSI cables, connect them to the spare machine
- define the boot device in the SAN at the console of the spare machine according to a node-specific cookbook
- boot the spare machine with the identity of the broken one

This all should require a minimum of system management effort (basically defining the boot device with wwidmgr as mentioned above), as the level of VMS knowledge varies.

So we want to present each of the SAN devices to two nodes: the one who "owns" them, and the spare node. To exclude the possibility of corruption of disks in use by other nodes but visible to the spare node, I wanted to configure only those dga devices which the replaced node actually uses, and not show the rest at all. As this doesn't seem possible, we probably (have to) go the SET DEVICE /NOAVAILABLE route.

Again, thanks much for all the suggestions!

Best regards,
Hans.

[Jan van den Ende]

Hans,

pardon my (probably over-)simplistic view, but would a cluster solution not provide the same (or even more) functionality, with MUCH less risk for errors, and a much simpler, (and certainly faster) switch potential?


>>>
If a problem arises at - say - 2 a.m. and the staff on duty
<<>>
as the level of VMS knowledge varies.
<<<
That does not look promising considering the configuration you are planning!

To me, it looks like your biggest problem will be "selling" the real capabilities of VMS clusters to their management!

(yeah, I know the feeling. Been there, and got hurt by it).

At the very least, I 'd say that you did not do your job all that well if you did not at least TRY it that way!

-- just my EUR 0.02

Success!

Proost.

Have one on me.

jpe

[H_Bachner]

Jan,

> pardon my (probably over-)simplistic view,
> but would a cluster solution not provide the
> same (or even more) functionality, with MUCH
> less risk for errors, and a much simpler,
> (and certainly faster) switch potential?

sure, in a perfect world this would be a dozen clusters instead of a dozen standalone systems. The existing systems have been in place for many years - some started as Alphaserver 2100 (iirc), others came in later. As they control different parts of the plant, different machinery with different maintenance schedules, you can't just combine them into one huge cluster. The applications have been developed with standalone systems in mind, and I wasn't (yet) involved at that time.

Current goal is to provide a "universal" spare machine to be used when something breaks which cannot be fixed in a rather short period of time.

Hans.

[Peter Zeiszler]

Are all of the VMS systems Zoned as one Zone?
Does the EVA6000 present the devices available to the zone or zones based on the WWID or WWN of the VMS system?

If the EVA6000 presents a set of devices based on zones then the spare system should use the fiber cables to the SAN to see the devices the original could see.

If the EVA6000 presents devices based on the WWN then the Spare system could be set to see ALL devices. That would be the only time the system could see all the devices.

The key thing is if it does see devices its not suppose to mount that you set then noavail or simply not use them.

If the switches though are setup with no zones and no WWN presentation I would definitely make a note on the cabinet that the SAN switches are in to NEVER connect a windows system to those switches. (can't emphasize that never enough)

[Jon Pinkley]

>>>
So we want to present each of the SAN devices to two nodes: the one who "owns" them, and the spare node. To exclude the possibility of corruption of disks in use by other nodes but visible to the spare node, I wanted to configure only those dga devices which the replaced node actually uses, and not show the rest at all. As this doesn't seem possible, we probably (have to) go the SET DEVICE /NOAVAILABLE route.
<<<

Hans,

Can a laptop with a terminal emulator be included in the "spare" setup? If so, key parts of the node-specific cookbook can be there to cut'n paste into the SRM console, but also it would be possible to connect to the HSG80 consoles and change the presentations to the "spares" WWID. Then the spare would see only the disks that the original systems saw. Then the cookbook would need a chapter on "dishwashing" so everything could be returned to its original configuration, with the HSG80's presenting only to the original "owner" of the devices.

You will still have a good bit of work making your startup smart enough to adapt to different device names, etc, and make sure you use logical names for things like tape devices, etc.

Alternatively, if the spare system had local drive it could boot from, and that system had something that could communicate with the HSG80 then that system could have a script that could configure the HSG80's presentations, (I don't know what the HSG80's scripting software was, we went from HSZ70 with hszterm to EVA6000).

But if you have all your devices "partitioned" into ranges for each system, then it should be easy to have the spare system always set all $1$DGA devices that weren't in it's "range" to /noavailable in the system startup, before any accidents could occur.

Have fun,

Jon

[H_Bachner]

@Peter:

> Does the EVA6000 present the devices available to the zone
> or zones based on the WWID or WWN of the VMS system?

Presentation happens based on WWN.

> If the EVA6000 presents devices based on the WWN then the
> Spare system could be set to see ALL devices. That would
> be the only time the system could see all the devices.

This is exactly what I want to achieve, see my earlier posting.

> The key thing is if it does see devices its not suppose to mount
> that you set then noavail or simply not use them.

Right :-)

> If the switches though are setup with no zones and no
> WWN presentation I would definitely make a note on the cabinet [...]

As mentioned earlier, presentation rules *are* defined for all devices. This is a serious production site, not a playground.

Thanks,
Hans.