Possible Difficult SCSI Question

[Jason Berendsen]

I have two N class servers identical with respect to hardware connected to a HP 1200EX Optical Jukebox. Both these servers are connected to both SCSI buses on this Jukebox. As you can probably guess this is a Service Guard environment. The primary server is connected to bus one of the Jukebox with the card at hardware path 1/8/ with it's initiator using the SCSI ID of 7. The secondary server is connected to bus one of the Jukebox with the card at hardware path 1/8/ with it's initiator using the SCSI ID of 6. When the package is running on the primary server all is hunky dory. The server can see the 4 Optical drives on the 1/8/0/0.1-4 path as well as the Optical changers arm at 1/8/0/0.5. When the package switches to the secondary server the server is able to see the drives at 1/8/0/0.1-4 but is unable to see the Optical changer arm at 1/8/0/0.5.

We changed the SCSI ID of the initiator on the secondary server from 6 to 7 and shutdown the primary server and everything worked fine. But, this defeats the purpose of having Service Guard for this because we can't change the SCSI ID of the card on the fly. And, we can't keep the card at 7 because this is on the same bus as the primary which is using 7.

Does anyone know why HPUX doesn't see this arm properly when the SCSI initiator is at ID 6?

Thanks

Jason

[Chris Wilshaw]

Can you post the output of ioscan -fn when the initiator is set at 6. That may help in tracking down the issue.

[Jason Berendsen]

This is the primary servers ioscan of the bus in question:
ba 11 1/8 lba CLAIMED BUS_NEXUS Local PCI Bus Adapter (782)
ext_bus 10 1/8/0/0 c720 CLAIMED INTERFACE SCSI C875 Fast Wide Differential
target 31 1/8/0/0.1 tgt CLAIMED DEVICE
disk 90 1/8/0/0.1.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t1d0 /dev/rdsk/c10t1d0
target 32 1/8/0/0.2 tgt CLAIMED DEVICE
disk 73 1/8/0/0.2.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t2d0 /dev/rdsk/c10t2d0
target 33 1/8/0/0.3 tgt CLAIMED DEVICE
disk 74 1/8/0/0.3.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t3d0 /dev/rdsk/c10t3d0
target 34 1/8/0/0.4 tgt CLAIMED DEVICE
disk 75 1/8/0/0.4.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t4d0 /dev/rdsk/c10t4d0
target 35 1/8/0/0.5 tgt CLAIMED DEVICE
autoch 1 1/8/0/0.5.0 schgr CLAIMED DEVICE HP C1107J
target 36 1/8/0/0.7 tgt CLAIMED DEVICE
ctl 8 1/8/0/0.7.0 sctl CLAIMED DEVICE Initiator
/dev/rscsi/c10t7d0



This is the secondary that is using initiator 6

ba 11 1/8 lba CLAIMED BUS_NEXUS Local PCI Bus Adapter (782)
ext_bus 10 1/8/0/0 c720 CLAIMED INTERFACE SCSI C875 Ultra Wide Differential
target 31 1/8/0/0.1 tgt CLAIMED DEVICE
disk 110 1/8/0/0.1.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t1d0 /dev/rdsk/c10t1d0
target 32 1/8/0/0.2 tgt CLAIMED DEVICE
disk 105 1/8/0/0.2.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t2d0 /dev/rdsk/c10t2d0
target 33 1/8/0/0.3 tgt CLAIMED DEVICE
disk 106 1/8/0/0.3.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t3d0 /dev/rdsk/c10t3d0
target 34 1/8/0/0.4 tgt CLAIMED DEVICE
disk 107 1/8/0/0.4.0 sdisk CLAIMED DEVICE HP C1113J
/dev/dsk/c10t4d0 /dev/rdsk/c10t4d0
target 35 1/8/0/0.5 tgt CLAIMED DEVICE
autoch 0 1/8/0/0.5.0 schgr CLAIMED DEVICE HP C1107J
/dev/rac/c10t5d0
target 36 1/8/0/0.6 tgt CLAIMED DEVICE
ctl 10 1/8/0/0.6.0 sctl CLAIMED DEVICE Initiator
/dev/rscsi/c10t6d0

[A. Clay Stephenson]

Notice that the /dev/rac/xxxx device nodes are present on one of the servers but not on the other. It appears that you need to run insf on the remaining host.

Because the robotic device is not associated with a volume group, you will need to make certain that the /dev/rac/xxxx names are the same on both nodes. The minor numbers may differ if you create using insf so you may have to manually run mknod to make certain that you have matching device node names even if the monor numbers differ.

[Chris Wilshaw]

What versions of the OS and patch release are you running?

[Dave Unverhau_1]

Jason,

It looks like the system that is not working correctly associates the raw autochanger (rac) device with the arm, so I'm not sure that an insf is the answer...

I noticed that the system that works correctly IDs the SCSI bus as a FAST WIDE DIFFERENTIAL bus, while the problem system IDs its bus as ULTRA WIDE DIFFERENTIAL.

My *GUESS* is that, because a FAST SCSI bus has a characteristic impedance of 50 ohms and an ULTRA SCSI bus has a characteristic impedance of 100 ohms, you've got standing waves on the bus when both systems are powered on. These standing waves may affect the ULTRA bus more, due to its higher impedance.

You're probably also terminating the busses with inline 50 ohm terminators. Check with HP hardware support to see if they can confirm if this is a problem.

Unfortunately, I only get to play with older hardware these days, so I'm not intimately familiar with the RP-series systems. Is there a way to set the ULTRA interface to operate as FAST SCSI, instead of ULTRA?

BTW, have you tried setting the primary server's host address to 6 and the secondary's to 7?

Regards,

Dave

[melvyn burnard · Accepted solution]

Well the first statement that has to be made is that this configuration is unsupported.

There are other ways to do this, one I believe is using hte FileNet application, the other way would be to use ATS in ServiceGuard, but then you need to put in a supported FC/SCSI/MUX, and have the relevant FC cards etc. in the two servers.
Take a look at:
http://docs.hp.com/hpux/onlinedocs/B3936-90032/B3936-90032.html

[Jason Berendsen]

Dave,
Unfortunately, I sent an older ioscan. I have already changed the SCSI in question to FAST Wide from Ultra. This didn't change the situation.

Melvyn,
You hit this one on the head. We are using Filenet software, and this configuration supposedly worked in the past. I have my Filenet admins checking into the hte you spoke of.

[Jason Berendsen]

Melvyn,

My fellow admins got a kick out of me trying to find out what hte Filenet was. I now know you meant THE Filenet application.

[melvyn burnard]

dont you love finger problems? :-]

[Jason Berendsen]

Melvyn,

I can't get these guys to stop laughing at my misunderstanding.

Seriously, are you at all familiar with the way Filenet accomplishes the sharing of this Jukebox between two systems? Filenet doesn't seem too up on the concept with HPUX. Also, if this isn't supported why does the HP 1200EX come with two ports for each SCSI bus?

Once again, this supposedly worked in the past but something must have changed. Of course everyone denies any changes to the system.

Thanks,

Jason

[melvyn burnard]

well, I do not know the FileNet application (got the `the` right this time) but they (FileNet) should know how this is configured/works.
When I say unsupported, I meant UNLESS you are using ATS or FileNet application. I would suggest you possibly get the FileNet people to dig deeper, or even log a call with your local HP support office, assuming you have a support contract with them.

[melvyn burnard]

As you have launched another thread regarding this, I thought I might add some info I found regarding thte FileNet application:

FileNET is responsible for supporting their applications,
including the FileNET IMS applicationsG?? interaction with
MO devices and libraries in an MC/ServiceGuard environment.
With FileNET applications; HP supports HP-UX, FileNET OSARs,
HP MO device hardware on a shared FWD SCSI bus, the SCSI
pass through driver needed to control MO devices, and
MC/ServiceGuard. There are configuration restrictions for this
environment.
Joint HP/FileNET testing of FileNET applications which control
MO devices has shown specific configurations to work within
an MC/ServiceGuard environment. FileNET is responsible for
testing and supporting their applications with new revisions
of HP-UX and additional MO devices.

Supplemental Support Information:
1. HP supports certain MO devices and MO library robotics
attached on a dedicated, shared FWD SCSI bus. Only one
MO device is allowed per shared bus. The MO device can
be shared between no more than two nodes.
2. HP supports HP-UX, FileNET OSARs, the SCSI pass through driver
used for sending control commands to MO devices, HP MO devices,
HP MO library robotics and MC/ServiceGuard.
MC/ServiceGuard provides the capability for HP and non-HP
applications to be integrated with it (e.g. FileNET applications)
to provide high availability services.
3. 3rd party applications integrated with MC/ServiceGuard are
not supported by HP (unless special support agreements are defined).
FileNET applications are supported by FileNET.
4. Since MC/ServiceGuard does not directly interact or control
MO devices or MO libraries, they are not considered
MC/ServiceGuard supported devices. However, there is nothing
in MC/ServiceGuard that would preclude the use of MO devices
within an MC/ServiceGuard configuration.
The FileNET IMS application directly controls and manages
the MO devices and MO library robotics. FileNET IMS also
manages access to the MO library and MO devices so that only
one copy of FileNET IMS can access the MO library and
associated MO drives.
5. In the July 1997 timeframe, FileNET and HP performed some initial
integration and testing of specific FileNET applications, MO
devices, MO libraries and MC/ServiceGuard. The FileNET
applications tested were Document Services (DS) and Image
Management Services (IMS). MO libraries are vital to the
IMS applications operation.

The result of this integration and testing effort was that
the FileNET IMS application and MO devices were shown to work in
an MC/ServiceGuard configuration based on specific software and
hardware revisions and configuration rules.

Again I repeat, MC/SG does not support sharing an optical drive, other than using ATS. With FileNet, Sg is not controlling the optical drive, FileNet does this