sysman io rebuild and EMC device configuration

[Dave PNCGIS]

We have experienced a performance issue when un-configuring EMC Symmetrix devices that are presented to OpenVMS 8.3a. This issue has been previously addressed by booting each cluster member where the devices were now un-available after the un-configure. We are not sure that this is due to EMC still thinking the devices are there because of the mapping to the device table, or VMS trying to continuously re-access devices which no longer exist. The actual question I have, is can you use MC SYSMAN IO REBUILD to have the same effect in un-mapping VMS devices as a reboot? Can we make the $1$dga devices "go away" as far as VMS is concerned? And also as far as the EMC frame is concerned?

[Andy Bustamante]

$ MC SYSMAN IO SCSI_PATH_VERIFY

will remove devices which are no longer available. If you've reconfigured a device, follow this with

$ MC SYSMAN IO AUTOCONFIGURE

See

$ MCR SYSMAN HELP

and chapter 24 of the System Management Utilities manual for OpenVMS 8.3 at http://h71000.www7.hp.com/doc/83final/6048/6048pro_073.html#sysman_part.

[Dave PNCGIS]

Thank you, we will look into this. We just need to know that it is non-disruptive to any other IO activity on the cluster.

[The Brit]

Andy,
Are you saying that doing an "IO SCSI_PATH_VERIFY" on a device (say a SAN lun) which is no longer available (i.e. no longer presented to the system) will remove it from the "show device" display??

Although I have never tried this explicitly, It is not my understanding, or experience. I am sure that at some point in the past I have executed the SCSI_PATH_VERIFY command when I had obsolete SAN units still being displayed, and I do not recall ever having seen these units removed from the display, at least not without rebooting the system.

If your comment is true however, I would be very happy since it is a real annoyance having these old units hanging around until is is convenient to reboot.

Dave

[Ian Miller.]

According to the Fine Manual
http://h71000.www7.hp.com/doc/84final/6048/6048pro_080.html#startsubcommand_480

"You usually enter the SYSMAN IO SCSI_PATH_VERIFY command after performing an online reconfiguration of a SCSI or an FC interconnect. The command reads the device type and device identifier on each SCSI and FC path in the system. If the device does not match the data stored in the IO database, then the path is disconnected in the IO database. Following a SYSMAN IO SCSI_PATH_VERIFY command, you usually enter a SYSMAN IO AUTOCONFIGURE command, which updates the IO database to match the new SCSI or FC configuration. "

[Andy Bustamante]

Dave,

As I recall, the $ SHOW DEVICE display continues to list the drive, but it's no longer available and will immediately return an error on any mount or init attempt. This was up to 7.3-2.

The original question, "Can we make the $1$dga devices "go away" as far as VMS is concerned?" It depends on how you define "go away."

[Dave PNCGIS]

I talked to someone here who had more detail on the issue. We believe that the problem is that the fibre channel paths are not being terminated even when we run IO SCSI and IO AUTO. We think that the reason the reboot clears up the problem is that it disconnects the fibre channel paths to the missing devices. What we are looking for is a way to disconnect the FC paths without rebooting.

[Andy Bustamante]

Are you up to date on patches?

(grumble)
If not, hopefully you have a support contract in place.
(/grumble)

[Dave PNCGIS]

We are at update 12. We probably will not apply update 13 until after year end. And, yes, we have a current HP support contract. The problem we continue to encounter is that EMC and VMS do not always work and play well together, but (sigh) we have been forced to use EMC disk. Not that it is bad, but it has created multiple problems for us.

[Dave PNCGIS]

In fact, at least for now, we are most interested in what the IO REBUILD command actually does, and how it differs from IO SCSI and IO AUTO.

[Bill Hall]

Dave,

$1$$DGA devices will remain around until the entire cluster is shutdown.

What is or where is the performance issue?

Bill

[Shriniketan Bhagwat]

Hi,

I am just thinking, will below commands help to solve the problem?

$ MC SYSMAN
SYSMAN> SET ENV/CLUSTER
SYSMAN> IO SCSI_PATH_VERIFY
SYSMAN> IO AUTOCONFIGURE
SYSMAN> EXIT
$
$

Regards,
Ketan

[Ian Miller.]

SYSMAN IO SCSI_PATH_VERIFY disconnects the paths to devices no longer available.

[Dave PNCGIS]

I have also contacted EMC. This is their take on why we have the issue. It sounds like IO SCSI should fix this:

EMC:
When OpenVMS boots or when using SYSMAN to scan the SCSI bus, OpenVMS replaces all it knows about storage with the new information supplied by arrays about what devices have been presented to that host. From then on OVMS uses that information to find devices and paths. Periodically OVMS queries devices to see if they are still there. If they respond in time, all is well. If not then OVMS goes into the mount verify process. That takes time and affects performance on all devices. I expect that mount verify errors would be logged in syslog.sys for the missing devices.

Follow HP's recommendations. This issue has nothing to do with the array. It is the way OpenVMS behaves. Just as you have to scan the bus to make newly provisioned devices known to OpenVMS, you have to scan the bus to make OpenVMS forget about devices removed.

[The Brit]

Hi Dave.

It sounds like a bit of double-talk to me. I would assume that you are not going to un-configure EMC Luns while they are mounted on the VMS system. And if they are not mounted, then "mount-verify", and any associated performance problem, is not a consideration.

I know they say it has nothing to do with the storage array, however OpenVMS behaves exactly the same with other compatable storage arrays, HSG, EVA, XP, etc (all HP of course), and these arrays do not experience any "performance" issue. LUNs are often "presented" and "unpresented", sizes modified, etc, and no performance issues are observed or experience.

Of course I might just be lucky.

I have no experience with EMC storage, however I do know several sites which use it, and most report "peculiarities" when using this storage with OpenVMS.

Just my 2c worth.

Dave