HP OpenVMS systems documentation

In a multihost SCSI OpenVMS cluster system, you can increase disk storage availability by configuring the cluster for both types of multipath failover (direct SCSI to direct SCSI and direct SCSI to MSCP served SCSI), as shown in Figure 6-3.

Figure 6-3 Direct SCSI to MSCP Served Configuration With Two Interconnects

Note the following about this configuration:

• Both nodes are directly connected to both storage interconnects.
• Both nodes are connected to a second interconnect for cluster communications.
• Each HSx storage controller is connected to only one interconnect.
• Both HSx storage controllers are in the same cabinet.

This configuration provides the advantages of both direct SCSI failover and direct to MSCP served failover.

6.2 Configuration Requirements and Restrictions

The requirements for multipath SCSI and FC configurations are presented in Table 6-1.

Table 6-1 Multipath SCSI and FC Configuration Requirements

Component	Description
Host adapter	For parallel SCSI, the KZPBA-CB must be used. It is the only SCSI host adapter that supports disk multipath failover on OpenVMS. For Fibre Channel, both the KGPSA-BC and the KGPSA-CA support multipath failover on OpenVMS.
Alpha console firmware	For systems with HSZ70 and HSZ80, the minimum revision level is 5.3 or 5.4, depending on your AlphaServer. For systems with HSG80, the minimum revision level is 5.4
Controller firmware	For HSZ70, the minimum revision level is 7.3; for HSZ80, it is 8.3; for HSG80, it is 8.4. For MDR, the minimum revision level is 1170.
Controller module mode	Must be set to multibus mode (disks only). The selection is made at the HS x console.
Full connectivity	All hosts that are connected to an HS x in multibus mode must have a path to both HS x controller modules. This is because hosts that are connected exclusively to different controllers will switch the logical unit back and forth between controllers, preventing any I/O from executing. To prevent this from happening, always provide full connectivity from hosts to controller modules. If a host's connection to a controller fails, then take one of the following steps to avoid indefinite path switching: Repair the connection promptly. Prevent the other hosts from switching to the partially connected controller. This is done by either disabling switching to the paths that lead to the partially connected controller (see Section 6.7.11), or by shutting down the partially connected controller. Disconnect the partially connected host from both controllers.
Allocation classes	For parallel SCSI, a valid HSZ allocation class is required (see Section 6.5.3). If a SCSI bus is configured with HSZ controllers only, and all the controllers have a valid HSZ allocation class, then it is not necessary to adhere to the older SCSI device naming rules for that bus. That is, the adapters require neither a matching port allocation class nor a matching node allocation class and matching OpenVMS adapter device names. However, if there are non-HSZ devices on the bus, or HSZ controllers without an HSZ allocation class, you must follow the standard rules for shared SCSI buses for node and port allocation class assignments and for controller device names. Booting from devices with an HSZ allocation class is supported on all AlphaServers that support the KZPBA-CB except for the AlphaServer 2 x00(A). The controller allocation class is not used for FC devices. Note: If you are using Volume Shadowing for OpenVMS, every disk must have a nonzero allocation class. All FC disks attached to HSG and HSV controllers are automatically assigned the allocation class value of 1, which satisfies the volume shadowing requirement.

The restrictions for multipath FC and SCSI configurations are presented in Table 6-2.

Table 6-2 Multipath FC and SCSI Configuration Restrictions

Capability	Description
Devices supported	DKDRIVER disk devices attached to HSZ70, HSZ80, HSG60, HSG80, and HSV110 controller modules are supported. MKDRIVER tapes and GKDRIVER tape robots attached to an MDR are supported. Other device types, such as tapes, and generic class drivers, such as GKDRIVER, are not supported. Note that under heavy load, a host-initiated manual or automatic switch from one controller to another may fail on an HSZ70 or HSZ80 controller. Testing has shown this to occur infrequently. This problem has been fixed for the HSZ70 with the firmware HSOF V7.7 (and later). The problem will be fixed for the HSZ80 in a future release. This problem does not occur on HSG x or HSV x controllers, nor on the MDR.
Mixed-version and mixed-architecture clusters	All hosts that are connected to an HSZ, HSG, or HSV in multibus mode must be running OpenVMS Version 7.2 or higher. To use multipath failover to a served path, MPDEV_REMOTE must be enabled on all systems that have direct access to shared SCSI or Fibre Channel devices. The first release to provide this feature is OpenVMS Alpha Version 7.3-1. Therefore, all nodes on which MPDEV_REMOTE is enabled must be running OpenVMS Alpha Version 7.3-1 or later.
SCSI to MSCP failover MSCP to SCSI failover	Multiple hosts must be attached to SCSI disk devices via a shared SCSI bus (either parallel SCSI or Fibre Channel). All the hosts on the shared SCSI bus must be running OpenVMS Alpha Version 7.3--1, and the MPDEV_REMOTE system parameter must be set to 1 on these hosts.
Volume Shadowing for OpenVMS	The use of default settings for certain system parameters may lead to the occasional removal of shadow set members that are configured for multipath support. The shadow set members where this has been observed are using Volume Shadowing for OpenVMS. Therefore, when configuring multipath shadow sets using Volume Shadowing for OpenVMS, observe the following recommended setting for these system parameters: System Parameter Recommended Setting MSCP_CMD_TMO 60 as a minimum. The value of 60 is appropriate for most configurations. Some configurations may require a higher setting. SHADOW_MBR_TMO At least 3 x MSCP_CMD_TMO. SHADOW_SYS_TMO At least 3 x MSCP_CMD_TMO. MVTIMEOUT At least 4 x SHADOW_MBR_TMO.

6.3 HSx Failover Modes

The HSZ70, HSZ80, and HSGx implement two modes of failover operation when they are in a dual-redundant configuration, transparent failover mode, and multibus failover mode. HSVx supports multibus failover only.

For the system to operate correctly, the HSx failover mode must be compatible with the configuration of the interconnect hardware and the host operating system software, as described in the following sections.

6.3.1 Transparent Failover Mode

In transparent failover mode, the HSx presents each logical unit on one port of the dual controller pair. Different logical units may be assigned to different ports, but an individual logical unit is accessible through one port at a time. As shown in Figure 6-4, when the HSZ detects that a controller module has failed, it moves the logical unit to the corresponding port on the surviving controller.

Figure 6-4 Storage Subsystem in Transparent Mode

The assumption in transparent mode is that the two ports are on the same host bus, so the logical unit can move from one port to the other without requiring any changes to the host's view of the device. The system manager must ensure that the bus configuration is correct for this mode of failover. OpenVMS has supported transparent failover for HSZ controllers since Version 6.2.

To select transparent failover mode on the HSZ or HSG, enter one of the following commands at the console, depending on your configuration:

HSZ> SET FAILOVER COPY=THIS_CONTROLLER

or

HSZ> SET FAILOVER COPY=OTHER_CONTROLLER

An example of the output of a console SHOW command on an HSZ in transparent mode follows:

z70_A => SHOW THIS_CONTROLLER Controller: HSZ70 ZG64100160 Firmware XB32-0, Hardware CX25 Configured for dual-redundancy with ZG64100136 In dual-redundant configuration Device Port SCSI address 7 Time: 02-DEC-1998 09:22:09 Host port: SCSI target(s) (0, 2, 3, 4, 5, 6) Preferred target(s) (3, 5) TRANSFER_RATE_REQUESTED = 20MHZ Host Functionality Mode = A Allocation class 0 Command Console LUN is target 0, lun 1 Cache: 32 megabyte write cache, version 4 Cache is GOOD Battery is GOOD No unflushed data in cache CACHE_FLUSH_TIMER = DEFAULT (10 seconds) NOCACHE_UPS

6.3.2 Multibus Failover Mode (Disks Only)

In multibus failover mode, the HSx responds to SCSI Inquiry commands from the host on all ports of the dual controller pair. This allows the host to be aware of all the possible paths to the device. There are two advantages to having the host aware of all the paths to a device:

• The host can select an alternate path if it detects a failure on the current path. This is in addition to the failover that occurs when the HSx controller detects a failure, as is provided in transparent mode.
• The paths do not need to be on the same host bus. When the host is aware of the alternate paths, it can adjust its addressing methods appropriately to select a different path. This removes the SCSI bus as a single point of failure.

Note that, although the logical unit is visible on all ports, it is on line and thus capable of doing I/O on the ports of only one controller at a time. Different logical units may be on line to different controllers, but an individual logical unit is on line to only one controller at a time, as shown in Figure 6-5.

Figure 6-5 Storage Subsystem in Multibus Mode

You can determine which controller a logical unit is on line to by entering the HSx console command, as follows:

z70_A => SHOW UNIT FULL LUN Uses -------------------------------------------------------------- D200 DISK20300 Switches: RUN NOWRITE_PROTECT READ_CACHE MAXIMUM_CACHED_TRANSFER_SIZE = 32 ACCESS_ID = ALL State: ONLINE to the other controller PREFERRED_PATH = OTHER_CONTROLLER Size: 2050860 blocks

The host executes I/O to a logical unit on one path at a time, until that path fails. If a controller has two ports, as the HSZ80 and the HSG80 controllers do, then different hosts can access the same logical unit over different ports of the controller to which the logical unit is on line.

An HSx in multibus failover mode can only be used with the multipath functionality introduced in OpenVMS Version 7.2.

To select multibus failover mode, enter one of the following commands at the HSx: console, whichever is appropriate to your configuration:

HSZ> SET MULTIBUS_FAILOVER COPY=THIS_CONTROLLER

or

HSZ> SET MULTIBUS_FAILOVER COPY=OTHER_CONTROLLER

An example of the output of a console SHOW command on an HSx controller in multibus mode follows:

z70_B => SHOW THIS_CONTROLLER Controller: HSZ70 ZG64100136 Firmware XB32-0, Hardware CX25 Configured for MULTIBUS_FAILOVER with ZG64100160 In dual-redundant configuration Device Port SCSI address 6 Time: NOT SET Host port: SCSI target(s) (0, 2, 3, 4, 5, 6) TRANSFER_RATE_REQUESTED = 20MHZ Host Functionality Mode = A Allocation class 0 Command Console LUN is target 0, lun 1 Cache: 32 megabyte write cache, version 4 Cache is GOOD Battery is GOOD No unflushed data in cache CACHE_FLUSH_TIMER = DEFAULT (10 seconds) NOCACHE_UPS

6.3.3 Port Addressing for Controllers in Multibus Mode

There is a difference between parallel SCSI and FC in the way that the ports on multibus controllers are addressed. In parallel SCSI (the HSZ70 and the HSZ80), all the ports are assigned the same SCSI target IDs. This is noted for the HSZ80 configuration shown in Figure 6-6.

Figure 6-6 Port Addressing for Parallel SCSI Controllers in Multibus Mode

The reason all the ports have the same target ID is that the target ID is part of the OpenVMS device name (for example, the 6 in $4$DKC600), and the device name must be the same for all paths. This means that each port must be on a separate SCSI bus or there will be an address conflict.

In Fibre Channel configurations with the HSGx or the HSVx, all the ports have their own FC address and WWID, as noted in Figure 6-7. The same is true for the MDR.

Figure 6-7 Port Addressing for Fibre Channel Controllers in Multibus Mode

The ports on the HSGx and the HSVx have separate FC addresses and WWIDs because these items are not used in the OpenVMS FC device name. This means that any number of ports can be connected to the same FC interconnect. In fact, all the ports of the HSGx or HSVx in multibus mode should be connected, even if there is just one interconnect, because this can improve availability and performance.

6.4 Parallel SCSI Multipath Configurations (Disks Only)

The figures in this section show systems configured for transparent failover and for multipath failover. The special considerations for controller modules that have multiple ports, such as the HSZ80, are also described.

6.4.1 Transparent Failover

Transparent failover in a parallel SCSI configuration, as shown in Figure 6-8, requires that both controller modules be on the same SCSI bus.

Figure 6-8 Parallel SCSI Configuration With Transparent Failover

In this configuration:

• Each logical unit is visible to the host on only one controller module at a time. The other controller module does not answer at the same SCSI address, but it can be used for other SCSI addresses.
• One HSZ controller module detects the failure of the other controller and fails over the logical unit to itself. The surviving controller takes over the SCSI address or addresses of the failed controller.

A parallel SCSI configuration with multiple paths from the host to storage offers higher availability and performance than a configuration using transparent failover. Figure 6-9 shows this configuration.

Figure 6-9 Parallel SCSI Configuration With Multibus Failover and Multiple Paths

Note the following about this configuration:

• Each logical unit is visible to the host at the same ID on both controller modules so it can be configured. The logical unit responds to read/write I/O on only one controller at a time, the controller to which it is online.
• The controller modules must be on different SCSI buses to prevent a bus ID conflict.
• The HSZ moves a logical unit to the other controller if either of the following events occurs:
  • HSZ detects a controller failure.
  • Host sends a SCSI START command for the logical unit to the other controller.

Higher levels of availability and performance can be achieved with the use of multiported storage controllers, such as the HSZ80. The HSZ80 storage controller is similar to the HSZ70 except that each HSZ80 controller has two ports.

This section shows three configurations that use multiported storage controllers. The configurations are presented in order of increasing availability.

Figure 6-10 shows a single host with a single interconnect, using an HSZ80 in transparent mode.

Figure 6-10 Multiported Parallel SCSI Configuration With Single Interconnect in Transparent Mode

Note the following about this configuration:

• Each logical unit is visible on one port per storage controller.
• If a port fails, the HSZ80 fails over the traffic to the corresponding port of the other HSZ80.

Figure 6-11 shows a system configured in transparent mode using two paths from the host.

Figure 6-11 Multiported Parallel SCSI Configuration With Multiple Paths in Transparent Mode

In this configuration:

• Physically corresponding ports must be on the same SCSI bus.
• A maximum of two buses can be connected to each storage controller.

Note that in this configuration, although there are two buses, there is only one path from the host to a particular logical unit. When a controller fails, the logical unit moves to the corresponding port on the other controller. Both ports are on the same host bus.

This configuration has better performance than the one in Figure 6-10 because both SCSI buses can be simultaneously active. This configuration does not have higher availability, however, because there is still only one path from the host to the logical unit.

Figure 6-12 shows a system using the multiported HSZ80 storage controller configured in multibus mode.

Figure 6-12 Multiported Parallel SCSI Configuration With Multiple Paths in Multibus Mode

In this configuration:

• Each logical unit is visible to the host at the same ID on all ports (so they all will be configured by the host).
• All the ports must be on different SCSI buses.
• The host uses one path at a time.
• Each logical unit can execute I/O simultaneously over the two ports of the controller to which it is "on line." This means that if there are multiple hosts, then two paths to the storage device may be simultaneously active.

SCSI device names have evolved as systems have become larger and more complex. At first, SCSI device names were entirely path dependent. The device name indicated the node, host adapter, SCSI bus ID, and logical unit number (LUN) used to access the device. Path-based names are not suitable for multiple host and multiple path environments because:

• The node name can not be used when there are multiple nodes with direct access to a device.
• The host adapter's controller letter can not be used when the controller letters on a shared bus do not match.
• The host adapter's controller letter can not be used when a node is connected to a device with multiple adapters.

The first two of these issues were addressed by the use of the node allocation class and the port allocation class. The third issue requires the introduction of an HSZ controller-based allocation class. These three allocation classes are reviewed in the following sections.

6.5.1 Review of Node Allocation Classes

A node allocation class is used in a device name in place of a node name. A node allocation class is needed to produce a unique device name when multiple nodes have a direct connection to the same SCSI device.

A node allocation class can only be used in a device name when all nodes that share access to a SCSI storage device:

• Have only one direct path to the device.
• Use the same host controller name on the shared bus.
• Have sufficient SCSI IDs to produce unique names for nonshared devices.

Figure 6-13 shows a configuration whose devices are named using a node allocation class.

Figure 6-13 Devices Named Using a Node Allocation Class

A port allocation class in a device name designates the host adapter that is used to access the device. The port allocation class replaces the node allocation class in the device name, and the adapter controller letter is set to the constant A.

The port allocation class can be used when SCSI systems need more SCSI IDs to produce unique device names, or when the controller letter of the adapters on a shared bus do not match. A port allocation class can only be used in a device name when all nodes that share access to a SCSI storage device have only one direct path to the device.

Figure 6-14 shows a configuration whose devices are named using a port allocation class.

Figure 6-14 Devices Named Using a Port Allocation Class