Updated: 11 December 1998

Guidelines for OpenVMS Cluster Configurations

For storage subsystems, availability is determined by the availability of the storage device as well as the availability of the path to the device.

5.4.1 Availability Requirements

Some costs are associated with optimizing your storage subsystems for higher availability. Part of analyzing availability costs is weighing the cost of protecting data against the cost of unavailable data during failures. Depending on the nature of your business, the impact of storage subsystem failures may be low, moderate, or high.

Device and data availability options reduce and sometimes negate the impact of storage subsystem failures.

5.4.2 Device and Data Availability Optimizers

Depending on your availability requirements, choose among the availability optimizers described in Table 5-4 for applications and data with the greatest need.

Table 5-4 Storage Availability Optimizers

Availability Optimizer	Description
Redundant access paths	Protect against hardware failures along the path to the device by configuring redundant access paths to the data.
Volume Shadowing for OpenVMS software	Replicates data written to a virtual disk by writing the data to one or more physically identical disks that form a shadow set. With replicated data, users can access data even when one disk becomes unavailable. If one shadow set member fails, the shadowing software removes the drive from the shadow set, and processing continues with the remaining drives. Shadowing is transparent to applications and allows data storage and delivery during media, disk, controller, and interconnect failure. A shadow set can contain up to three members, and shadow set members can be anywhere within the storage subsystem of an OpenVMS Cluster system. Reference: See Volume Shadowing for OpenVMS for more information about volume shadowing.
System disk redundancy	Place system files judiciously on disk drives with multiple access paths. OpenVMS Cluster availability increases when you form a shadow set that includes the system disk. You can also configure an OpenVMS Cluster system with multiple system disks. Reference: For more information, see Section 11.2.
Database redundancy	Keep redundant copies of certain files or partitions of databases that are, for example, updated overnight by batch jobs. Rather than using shadow sets, which maintain a complete copy of the entire disk, it might be sufficient to maintain a backup copy on another disk or even on a standby tape of selected files or databases.
DECevent	DECevent, in conjunction with volume shadowing, can detect most imminent device failures with sufficient lead time to move the data to a spare device. Enhance device reliability with appropriate software tools. Use device-failure prediction tools, such as DECevent, where high availability is needed. When a shadow set member has an increasing fault rate that might indicate potential failure, DECevent works with Volume Shadowing for OpenVMS to make a shadow set copy of the suspect device to a spare device. After the copy is made, the suspect device can be taken off the system for examination and repair without loss of data availability.
Newer devices	Protect against failure by choosing newer devices. Typically, newer devices provide improved reliability and mean time between failures (MTBF). Newer controllers also improve reliability by employing updated chip technologies.
Implement thorough backup strategies	Frequent and regular backups are the most effective way to ensure the availability of your data.

5.5 CI Based Storage

The CI interconnect provides the highest OpenVMS Cluster availability with redundant, independent transmit-and-receive CI cable pairs. The CI offers multiple access paths to disks and tapes by means of dual-ported devices between HSC or HSJ controllers.

5.5.1 Supported Controllers and Devices

The following controllers and devices are supported by the CI interconnect:

• HSJ storage controllers
  • SCSI devices (RZ,TZ, EZ)
• HSC storage controllers
  • SDI and STI devices (RA, ESE, TA)
  • K.SCSI devices (RZ, TZ, EZ)

DSSI-based configurations provide shared direct access to storage for systems with moderate storage capacity. The DSSI interconnect provides the lowest-cost shared access to storage in an OpenVMS Cluster.

The storage tables in this section may contain incomplete lists of products.

5.6.1 Supported Devices

DSSI configurations support the following devices:

• EF-series solid-state disks
• RF-series disks
• TF-series tapes
• DECarray storage arrays
• HSD storage controller
  • SCSI devices (RZ,TZ, EZ)

Reference: RZ, TZ, and EZ SCSI storage devices are described in Section 5.7.

5.7 SCSI-Based Storage

The Small Computer Systems Interface (SCSI) bus is a storage interconnect based on an ANSI industry standard. You can connect up to a total of 8 or 16 nodes (3 of which can be CPUs) to the SCSI bus.

5.7.1 Supported Devices

The following devices can connect to a single host or multihost SCSI bus:

• RZ-series disks
• HSZ storage controllers

The following devices can connect only to a single host SCSI bus:

• EZ-series disks
• RRD-series CD-ROMs
• TZ-series tapes

The Fibre Channel interconnect is a storage interconnect that is based on an ANSI industry standard.

5.8.1 Storage Devices

The HSG storage controllers can connect to a single host or to a multihost Fibre Channel interconnect.

5.9 Host-Based Storage

Host-based storage devices can be connected locally to OpenVMS Cluster member systems using local adapters. You can make this locally connected storage available to other OpenVMS Cluster members by configuring a node as an MSCP server.

You can use local adapters to connect each disk to two access paths (dual ports). Dual porting allows automatic failover of disks between nodes.

5.9.1 Internal Buses

Locally connected storage devices attach to a system's internal bus.

Alpha systems use the following internal buses:

• PCI
• EISA
• XMI
• SCSI
• TURBOchannel
• Futurebus+

VAX systems use the following internal buses:

• VAXBI
• XMI
• Q-bus
• SCSI

Following is a list of local adapters and their bus types:

• KGPSA (PCI)
• KZPSM (PCI)
• KZPDA (PCI)
• KZPSC (PCI)
• KZPAC (PCI)
• KZESC (EISA)
• KZMSA (XMI)
• PB2HA (EISA)
• PMAZB (TURBOchannel)
• PMAZC (TURBOchannel)
• KDM70 (XMI)
• KDB50 (VAXBI)
• KDA50 (Q-bus)

This chapter describes multipath SCSI support for parallel SCSI and Fibre Channel configurations. Multipath support is available on OpenVMS Alpha Version 7.2.

The following topics are presented in this chapter:

• Overview of multipath SCSI support ( Section 6.1)
• HSx failover modes ( Section 6.2)
• Path selection by OpenVMS ( Section 6.3)
• Configuration requirements and restrictions ( Section 6.4)
• Parallel SCSI multipath configurations ( Section 6.5)
• Device naming for parallel SCSI multipath configurations ( Section 6.6)
• Fibre Channel multipath configurations ( Section 6.7)
• Implementing multipath configurations ( Section 6.8)

6.1 Overview of Multipath SCSI Support

Multipath SCSI configurations can use either parallel SCSI or Fibre Channel as the storage interconnect, as illustrated by Figure 6-1.

Two or more paths to a single device are called a multipath set. When the system configures a path to a device, it checks for an existing device with the same name but a different path. If such a device is found, and multipath support is enabled, the system either forms a multipath set or adds the new path to an existing set. If multipath support is not enabled, then no more than one path to a device is configured.

The system presents a multipath set as a single device. The system selects one path to the device as the "current" path, and performs all I/O over this path until there is a failure or the system manager requests that the system switch to another path.

Multipath SCSI support provides two types of failover:

• Direct SCSI to direct SCSI
• Direct SCSI to MSCP served

Direct SCSI to direct SCSI failover requires the use of multiported SCSI devices. Direct SCSI to MSCP served failover requires multiple hosts per SCSI bus, but does not require multiported SCSI devices. These two failover types can be combined. Each type and the combination of the two are described next.

6.1.1 Direct SCSI to Direct SCSI Failover

Direct SCSI to direct SCSI failover can be used on systems with multiported SCSI devices. The dual HSZ70, the HSZ80 and the HSG80 are examples of multiported SCSI devices. A multiported SCSI device can be configured with multiple ports on the same physical interconnect so that if one of the ports fails, the host can continue to access the device through another port. This is known as transparent failover mode and has been supported by OpenVMS since Version 6.2.

OpenVMS Version 7.2 introduces support for a new failover mode in which the multiported device can be configured with its ports on different physical interconnects. This is known as multibus failover mode.

The HSx failover modes are selected by HSx console commands. Transparent and multibus modes are described in more detail in Section 6.2.

A generic illustration of a multibus failover configuration is shown in Figure 6-1.

The two logical disk devices shown in Figure 6-1 represent virtual storage units that are presented to the host by the HSx controller modules. Each logical storage unit is "online" to one of the two HSx controller modules at a time. When there are multiple logical units, they can be online to different HSx controllers so that both HSx controllers can be active at the same time.

In transparent mode, a logical unit switches from one controller to the other when an HSx controller detects that the other controller is no longer functioning.

In multibus mode, a logical unit connection is switched from one controller to the other when one of the following events occurs:

• One HSx controller detects that the other controller is no longer functioning.
• The OpenVMS multipath software detects that the current path has failed.
• The OpenVMS system manager issues a command to cause a switch.

Figure 6-1 Multibus Failover Configuration

Note the following about this configuration:

• Host has two adapters.
• Interconnects can both be parallel SCSI (HSZ70 or HSZ80) or both be Fibre Channel (HSG80) but not mixed.
• Storage cabinet contains two HSx controllers configured for multibus failover mode.

The multibus configuration offers the following advantages over transparent failover:

• Higher aggregate performance with two host adapters and two HSx controller modules in operation.
• Higher availability because the storage is still accessible when a host adapter, the interconnect, or the HSx controller module on a path fails.

6.1.2 Direct SCSI to MSCP Served Failover

OpenVMS provides support for multiple hosts that share a SCSI bus. This is known as a multihost SCSI OpenVMS Cluster system. In this configuration, the SCSI bus is a shared storage interconnect. Cluster communication occurs over a second interconnect (LAN, DSSI, CI, or MEMORY CHANNEL).

Multipath support in a multihost SCSI OpenVMS Cluster system enables failover from directly attached SCSI storage to MSCP served SCSI storage, as shown in Figure 6-2.

Figure 6-2 Direct SCSI to MSCP Served Configuration With One Interconnect

Note the following about this configuration:

• Two hosts are connected to a shared storage interconnect.
• Two hosts are connected by a second interconnect (LAN, CI, DSSI, or MEMORY CHANNEL) for cluster communications.
• The storage devices can have a single port or multiple ports.
• If node Edgar's SCSI connection to the storage fails, the SCSI storage is MSCP served by the remaining host over the cluster interconnect.

6.1.3 Configurations Combining Both Types of Multipath Failover

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 HSx Failover Modes

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. When the HSx detects that a controller module has failed, it moves the logical unit to the corresponding port on the surviving controller.

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. Transparent failover has been supported by OpenVMS since V6.2.

To select transparent failover mode, enter the following command at the HSx console:

SET FAILOVER COPY=this_controller or other_controller

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

z70_A => sho this 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.2.2 Multibus Failover Mode

In multibus failover mode, the HSx makes each logical unit visible to 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 no 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 online, and thus capable of doing I/O, on the ports of only one controller at a time. Different logical units may be online to different controllers, but an individual logical unit is online to one controller at a time.

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

z70_A => sho 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 online.

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 the following command at the HSx: console:

SET MULTIBUS_FAILOVER COPY=this_controller or other_controller

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

z70_B => sho this 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

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6318PRO_005.HTML