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

When any node has multiple buses connecting to the same storage device, the new HSZ allocation class shown in Figure 6-15 must be used.

Figure 6-15 Devices Named Using an HSZ Allocation Class

An HSZ allocation class is similar to the HSC, HSD, and HSJ allocation classes. The device name, using an HSZ allocation class number, takes the following form:

$HSZ-allocation-class$ddcu

where:

• HSZ-allocation-class is a decimal value from 1 to 999, assigned to a particular HSZ storage controller by the system manager
• dd represents the device class, which is DK for disk
• c represents the controller, which must be A when using an HSZ allocation class
• u represents the device unit number, which is determined by the SCSI bus ID and the logical unit number (LUN) of the device

The system manager sets an HSZ allocation class from the HSZ console, using one of the following commands, as appropriate to the configuration:

HSZ> SET THIS_CONTROLLER ALLOCATION_CLASS = n

or

HSZ> SET OTHER_CONTROLLER ALLOCATION_CLASS = n

where n is a value from 1 to 999.

When the allocation class is set on one controller module in a dual redundant configuration, it is automatically set to the same value on the other controller.

In the following example, the allocation class is set to 199. The example shows that the value is set for both controllers.

z70_B => SET THIS ALLOCATION_CLASS=199 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 199 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 z70_B => SHOW OTHER_CONTROLLER Controller: HSZ70 ZG64100160 Firmware XB32-0, Hardware CX25 Configured for MULTIBUS_FAILOVER with ZG64100136 In dual-redundant configuration Device Port SCSI address 7 Time: NOT SET Host port: SCSI target(s) (0, 2, 3, 4, 5, 6) TRANSFER_RATE_REQUESTED = 20MHZ Host Functionality Mode = A Allocation class 199 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

The following rules pertain to the use of an HSZ allocation class in SCSI device names:

1. In multibus mode, an HSZ allocation class must be used in a device name (otherwise, the device is not configured).
2. In transparent mode, an HSZ allocation class can be used in a device name but it is not required.
3. The HSZ allocation class number must be the same for both controllers of an HSZ. This is handled automatically by the HSZ firmware.
4. The HSZ allocation class number must be unique among all types of allocation classes throughout the cluster.
5. The HSZ allocation class must be specified when referring to devices that have an HSZ allocation class. For example, the names DKA500 and NODE10$DKA500 can not be used. In addition, the $GETDVI system service will only return the fully specified name, including the HSZ allocation class, for these devices.

Figure 6-16 shows a multipath configuration with both a tape storage subsystem and a disk storage subsystem. Note that the disk storage controllers are configured in multibus mode.

Figure 6-16 Single Host With Two Dual-Ported Storage Controllers, One Dual-Ported MDR, and Two Buses

Note the following about this configuration:

• Host has two adapters, each attached to a different bus.
• Each port on each HSGx or HSVx storage controller is attached to a different interconnect.
• Each port on the Modular Data Router (MDR) or the Network Storage Router (NSR) is attached to a different interconnect.
• Both storage controllers can access the same disk.
• Host has four paths to the same logical unit.

Note that each HSG80 port has its own Fibre Channel address and Fibre Channel port WWID. This is different from an HSZ80 in multibus mode where all the ports respond to the same SCSI address and must, therefore, be connected to different SCSI buses. The separate FC addresses enable both ports of the dual HSG80 to be on the same FC.

Figure 6-17 is similar to Figure 6-16, except it has two additional Fibre Channel interconnects.

Figure 6-17 Single Host With Two Dual-Ported Storage Controllers, One Dual-Ported MDR, and Four Buses

Note the following about this configuration:

• Host has four adapters, each attached to a different interconnect.
• Each port on each HSGx or HSVx storage controller is attached to a different interconnect.
• Each port on the Modular Data Router (MDR) or the Network Storage Router (NSR) is attached to a different interconnect.
• Host has four paths to the same logical unit.

Figure 6-18 builds on the previous two figures. Instead of a single host, it has two hosts.

Figure 6-18 Two Hosts With Two Dual-Ported Storage Controllers, One Dual-Ported MDR, and Four Buses

Note the following about this configuration:

• Each host has four adapters, each attached to a different interconnect.
• Each port on each HSGx or HSVx storage controller is attached to a different interconnect.
• Each port on the Modular Data Router (MDR) or the Network Storage Router (NSR) is attached to a different interconnect.
• Each host has four paths to the same logical unit of the disk storage subsystem and two paths to the tape storage subsystem.

Parallel SCSI, SAS, and Fibre Channel interconnects support multipath configurations. Implementation of these configurations is similar, and the system parameters and the command for specifying paths are the same. The syntax for the path identifiers differs.

Implementing multiple paths to devices consists of the following steps:

1. Configuring a system or systems with multiple physical paths to those devices for which you want multipath support.
2. Setting the HSx controller to multibus mode (disks only).
3. Optionally qualifying multipath support by setting certain multipath system and console parameters, as appropriate for your configuration.
4. Optionally tailoring the operation of multipath functionality, using the DCL command SET DEVICE/qualifier/PATH=path-identifier.

Figure 6-19 shows a valid multipath, multihost configuration.

Figure 6-19 Two Hosts With Shared Buses and Shared Storage Controllers

Note the following about this configuration:

• Each host has two adapters.
• Both hosts are connected to the same two buses.
• Both hosts share the storage.
• Each storage controller is connected to one bus only.
• The two storage controllers are connected to the same disks.

This configuration provides each host with two direct paths and one MSCP served path to each device.

Figure 6-20 shows a valid multipath configuration for systems that are not configured on the same bus.

Figure 6-20 Two Hosts With Shared, Multiported Storage Controllers

Note the following about this configuration:

• Each host has two adapters.
• Each host is connected to two buses but the hosts do not share a bus.
• Both hosts share the storage.
• Each storage controller has two connections, one to each host.
• The two storage controllers are connected to the same disks.

This configuration provides each host with two direct paths, one to each storage controller, and one MSCP served path to each device.

6.7.2 Invalid Multipath Configuration

Figure 6-21 shows an invalid multipath configuration. The configuration is invalid because, if multiple hosts in a cluster are connected to an HSZ or HSG, they must all have connections to the same controller modules (see Table 6-1). In this configuration, each host is connected to a different controller module.

Figure 6-21 Invalid Multipath Configuration

Multipath support is enabled and qualified by the use of the system parameters described in Table 6-3. (Certain multipath system parameters are reserved for the operating system.)

Table 6-3 Multipath System Parameters

Parameter	Description
MPDEV_ENABLE	Enables the formation of multipath sets when set to ON (1). When set to OFF (0), the formation of additional multipath sets and the addition of new paths to existing multipath sets is disabled. However, existing multipath sets remain in effect. The default is ON. MPDEV_REMOTE and MPDEV_AFB_INTVL have no effect when MPDEV_ENABLE is set to OFF.
MPDEV_LCRETRIES	Controls the number of times the system retries direct paths to the controller that the logical unit is on line to, before moving on to direct paths to the other controller, or to an MSCP served path to the device (MSCP paths apply only to disks). The valid range for retries is 1 through 256. The default is 1.
MPDEV_POLLER	Enables polling of the paths to multipath set members when set to ON (1). Polling allows early detection of errors on inactive paths. If a path becomes unavailable or returns to service, the system manager is notified with an OPCOM message. When set to OFF (0), multipath polling is disabled. The default is ON. Note that this parameter must be set to ON to use the automatic failback feature.
MPDEV_REMOTE (disks only)	Enables MSCP served paths to become members of a multipath set when set to ON (1). When set to OFF (0), only local paths to a SCSI or Fibre Channel device are used in the formation of additional multipath sets. MPDEV_REMOTE is enabled by default. However, setting this parameter to OFF has no effect on existing multipath sets that have remote paths. 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). If MPDEV_ENABLE is set to OFF (0), the setting of MPDEV_REMOTE has no effect because the addition of all new paths to multipath sets is disabled. The default is ON.
MPDEV_AFB_INTVL (disks only)	Specifies the automatic failback interval in seconds. The automatic failback interval is the minimum number of seconds that must elapse before the system will attempt another failback from an MSCP path to a direct path on the same device. MPDEV_POLLER must be set to ON to enable automatic failback. You can disable automatic failback without disabling the poller by setting MPDEV_AFB_INTVL to 0. The default is 300 seconds.
MPDEV_D1	Reserved for use by the operating system.
MPDEV_D2	Reserved for use by the operating system.
MPDEV_D3	Reserved for use by the operating system.
MPDEV_D4	Reserved for use by the operating system.

6.7.4 Path Identifiers

The system management commands described in the following sections allow you to monitor and control the operation of multipath failover. These commands provide a path identifier to uniquely specify each path in a multipath set.

Direct Fibre Channel paths are identified by the local host adapter name and the remote Fibre Channel port WWID --- that is, the initiator and the target. For example, in Figure 6-22, the path identifier for the path from the host adapter on the left to the HSG storage controller on the left is PGB0.5000-1FE1-0000-0201. (The second port on each HSG is omitted for convenience.) You can obtain the WWID for a storage controller from its console.

Figure 6-22 Fibre Channel Path Naming

Direct parallel SCSI paths are identified by the local host adapter name and the remote SCSI bus ID --- that is, the initiator and the target. For example, in Figure 6-23, the path identifiers for node Edgar's two direct paths to the disk would be named PKB0.5 and PKC0.5.

The path identifier for MSCP served paths is MSCP .

Figure 6-23 Configuration With Multiple Direct Paths