HP OpenVMS Systems Documentation

Multipath failover, as described in Section 6.7.9, applies to MSCP served paths as well. That is, if the current path is via an MSCP served path and the served path fails, mount verification can trigger an automatic failover back to a working direct path.

However, an I/O error on the MSCP path is required to trigger the failback to a direct path. Consider the following sequence of events:

• A direct path is being used to a device.
• All direct paths fail and the next I/O to the device fails.
• Mount verification provokes an automatic path switch to the MSCP served path.
• Sometime later, a direct path to the device is restored.

In this case, the system would continue to use the MSCP served path to the device, even though the direct path is preferable. This is because no error occurred on the MSCP served path to provoke the path selection procedure.

The automatic failback feature is designed to address this situation. Multipath polling attempts to fail back the device to a direct path when it detects that all of the following conditions apply:

• A direct path to a device is responsive.
• The current path to the device is an MSCP served path.
• The current path was not selected by a manual path switch.
• An automatic failback has not been attempted on this device within the last MPDEV_AFB_INTVL seconds.

The automatic failback is attempted by triggering mount verification and, as a result, the automatic failover procedure on the device.

The main purpose of multipath polling is to test the status of unused paths in order to avoid situations such as the following:

• A system has paths A and B to a device.
• The system is using path A.
• If path B becomes inoperative, it goes unnoticed.
• Much later, and independently, path A breaks.
• The system attempts to fail over to path B but finds that it is broken.

The poller would detect the failure of path B within 1 minute of its failure and would issue an OPCOM message. An alert system manager can initiate corrective action immediately.

Note that a device might successfully respond to the SCSI INQUIRY commands that are issued by the path poller but might fail to complete a path switch or mount verification successfully on that path. A system manager or operator can control automatic failback in three ways:

1. Specify the minimum interval between automatic failback attempts on any given device by the MPDEV_AFB_INTVL system parameter. The default value is 300 seconds.
2. Prevent automatic failback by setting the value of MPDEV_AFB_INTVL to 0. If set to 0, no automatic failback is attempted on any device on this system.
3. Temporarily disable automatic failback on a specific device by manually switching the device to the MSCP served path. You can do this even if the current path is an MSCP served path.

Because of the path selection procedure, the automatic failover procedure, and the automatic failback feature, the current path to a mounted device is usually a direct path when there are both direct and MSCP served paths to that device. The primary exceptions to this are when the path has been manually switched to the MSCP served path or when there are no working direct paths.

6.7.11 Enabling or Disabling Paths as Path Switch Candidates

By default, all paths are candidates for path switching. You can disable or re-enable a path as a switch candidate by using the SET DEVICE command with the /[NO]ENABLE qualifier. The reasons you might want to do this include the following:

• You know a specific path is broken, or that a failover to that path will cause some members of the cluster to lose access.
• To prevent automatic switching to a selected path while it is being serviced.

Note that the current path cannot be disabled.

The command syntax for enabling a disabled path is:

The following command enables the MSCP served path of device $2$DKA502.

$ SET DEVICE $2$DKA502/ENABLE/PATH=MSCP 

The following command disables a local path of device $2$DKA502.

$ SET DEVICE $2$DKA502/ENABLE/PATH=PKC0.5 

Be careful when disabling paths. Avoid creating an invalid configuration, such as the one shown in Figure 6-21.

6.7.12 Performance Considerations

The presence of an MSCP served path in a disk multipath set has no measurable effect on steady-state I/O performance when the MSCP path is not the current path.

Note that the presence of an MSCP served path in a multipath set might increase the time it takes to find a working path during mount verification under certain, unusual failure cases. Because direct paths are tried first, the presence of an MSCP path should not affect recovery time.

However, the ability to switch dynamically from a direct path to an MSCP served path might significantly increase the I/O serving load on a given MSCP server system with a direct path to the multipath disk storage. Because served I/O takes precedence over almost all other activity on the MSCP server, failover to an MSCP served path can affect the reponsiveness of other applications on that MSCP server, depending on the capacity of the server and the increased rate of served I/O requests.

For example, a given OpenVMS Cluster configuration might have sufficient CPU and I/O bandwidth to handle an application work load when all the shared SCSI storage is accessed by direct SCSI paths. Such a configuration might be able to work acceptably as failures force a limited number of devices to switch over to MSCP served paths. However, as more failures occur, the load on the MSCP served paths could approach the capacity of the cluster and cause the performance of the application to degrade to an unacceptable level.

The MSCP_BUFFER and MSCP_CREDITS system parameters allow the system manager to control the resources allocated to MSCP serving. If the MSCP server does not have enough resources to serve all incoming I/O requests, performance will degrade on systems that are accessing devices on the MSCP path on this MSCP server.

You can use the MONITOR MSCP command to determine whether the MSCP server is short of resources. If the Buffer Wait Rate is nonzero, the MSCP server has had to stall some I/O while waiting for resources.

It is not possible to recommend correct values for these parameters. However, note that, starting with OpenVMS Alpha Version 7.2-1, the default value for MSCP_BUFFER has been increased from 128 to 1024.

As noted in the online help for the SYSGEN utility, MSCP_BUFFER specifies the number of pagelets to be allocated to the MSCP server's local buffer area, and MSCP_CREDITS specifies the number of outstanding I/O requests that can be active from one client system. For example, a system with many disks being served to several OpenVMS systems might have MSCP_BUFFER set to a value of 4000 or higher and MSCP_CREDITS set to 128 or higher.

For information about modifying system parameters, see the OpenVMS System Manager's Manual.

HP recommends that you test configurations that rely on failover to MSCP served paths at the worst-case load level for MSCP served paths. If you are configuring a multiple-site disaster-tolerant cluster that uses a multiple-site SAN, consider the possible failures that can partition the SAN and force the use of MSCP served paths. In a symmetric dual-site configuration, HP recommends that you provide capacity for 50 percent of the SAN storage to be accessed by an MSCP served path.

You can test the capacity of your configuration by using manual path switching to force the use of MSCP served paths.

6.7.13 Console Considerations

This section describes how to use the console with parallel SCSI multipath disk devices. See Section 7.6 for information on using the console with FC multipath devices.

The console uses traditional, path-dependent, SCSI device names. For example, the device name format for disks is DK, followed by a letter indicating the host adapter, followed by the SCSI target ID, and the LUN.

This means that a multipath device will have multiple names, one for each host adapter it is accessible through. In the following sample output of a console show device command, the console device name is in the left column. The middle column and the right column provide additional information, specific to the device type.

Notice, for example, that the devices dkb100 and dkc100 are really two paths to the same device. The name dkb100 is for the path through adapter PKB0, and the name dkc100 is for the path through adapter PKC0. This can be determined by referring to the middle column, where the informational name includes the HSZ allocation class. The HSZ allocation class allows you to determine which console "devices" are really paths to the same HSZ device.

>>>SHOW DEVICE 
dkb0.0.0.12.0              $55$DKB0                       HSZ70CCL  XB26 
dkb100.1.0.12.0            $55$DKB100                        HSZ70  XB26 
dkb104.1.0.12.0            $55$DKB104                        HSZ70  XB26 
dkb1300.13.0.12.0          $55$DKB1300                       HSZ70  XB26 
dkb1307.13.0.12.0          $55$DKB1307                       HSZ70  XB26 
dkb1400.14.0.12.0          $55$DKB1400                       HSZ70  XB26 
dkb1500.15.0.12.0          $55$DKB1500                       HSZ70  XB26 
dkb200.2.0.12.0            $55$DKB200                        HSZ70  XB26 
dkb205.2.0.12.0            $55$DKB205                        HSZ70  XB26 
dkb300.3.0.12.0            $55$DKB300                        HSZ70  XB26 
dkb400.4.0.12.0            $55$DKB400                        HSZ70  XB26 
dkc0.0.0.13.0              $55$DKC0                       HSZ70CCL  XB26 
dkc100.1.0.13.0            $55$DKC100                        HSZ70  XB26 
dkc104.1.0.13.0            $55$DKC104                        HSZ70  XB26 
dkc1300.13.0.13.0          $55$DKC1300                       HSZ70  XB26 
dkc1307.13.0.13.0          $55$DKC1307                       HSZ70  XB26 
dkc1400.14.0.13.0          $55$DKC1400                       HSZ70  XB26 
dkc1500.15.0.13.0          $55$DKC1500                       HSZ70  XB26 
dkc200.2.0.13.0            $55$DKC200                        HSZ70  XB26 
dkc205.2.0.13.0            $55$DKC205                        HSZ70  XB26 
dkc300.3.0.13.0            $55$DKC300                        HSZ70  XB26 
dkc400.4.0.13.0            $55$DKC400                        HSZ70  XB26 
dva0.0.0.1000.0            DVA0 
ewa0.0.0.11.0              EWA0              08-00-2B-E4-CF-0B 
pka0.7.0.6.0               PKA0                  SCSI Bus ID 7 
pkb0.7.0.12.0              PKB0                  SCSI Bus ID 7  5.54 
pkc0.7.0.13.0              PKC0                  SCSI Bus ID 7  5.54 

The console does not automatically attempt to use an alternate path to a device if I/O fails on the current path. For many console commands, however, it is possible to specify a list of devices that the console will attempt to access in order. In a multipath configuration, you can specify a list of console device names that correspond to the multiple paths of a device. For example, a boot command, such as the following, will cause the console to attempt to boot the multipath device through the DKB100 path first, and if that fails, it will attempt to boot through the DKC100 path:

BOOT DKB100, DKC100 

A major benefit of OpenVMS is its support of a wide range of interconnects and protocols for network configurations and for OpenVMS Cluster System configurations. This chapter describes OpenVMS support for Fibre Channel as a storage interconnect for single systems and as a shared storage interconnect for multihost OpenVMS Cluster systems. With few exceptions, as noted, this chapter applies equally to OpenVMS Alpha systems and OpenVMS Integrity server systems.

The following topics are discussed:

• Overview of OpenVMS Fibre Channel support ( Section 7.1)
• Fibre Channel configuration support ( Section 7.2)
• Example configurations ( Section 7.3)
• Fibre Channel addresses, WWIDs, and device names ( Section 7.4)
• Fibre Channel tape support ( Section 7.5)
• Using the AlphaServer console for configuring Fibre Channel ( Section 7.6)
• Booting on a Fibre Channel Storage Device on OpenVMS Integrity server Systems ( Section 7.7)
• Setting up a storage controller for use with OpenVMS ( Section 7.8)
• Creating a cluster with a shared Fibre Channel system disk ( Section 7.9)
• Using interrupt coalescing for I/O performance gains ( Section 7.10)
• Using Fast Path in your configuration ( Section 7.11)
• Using FIBRE_SCAN for displaying devices ( Section 7.12)

For information about multipath support for Fibre Channel configurations, see Chapter 6.

Fibre Channel is an ANSI standard network and storage interconnect that offers many advantages over other interconnects. Its most important features and the support offered by OpenVMS for these features are shown in Table 7-1.

Figure 7-1 shows a logical view of a switched topology. The FC nodes are either Alpha hosts, or storage subsystems. Each link from a node to the switch is a dedicated FC connection. The switch provides store-and-forward packet delivery between pairs of nodes. Concurrent communication between disjoint pairs of nodes is supported by the switch.

Figure 7-1 Switched Topology (Logical View)

Figure 7-2 shows a physical view of a Fibre Channel switched topology. The configuration in Figure 7-2 is simplified for clarity. Typical configurations will have multiple Fibre Channel interconnects for high availability, as shown in Section 7.3.4.

Figure 7-2 Switched Topology (Physical View)

Figure 7-3 shows an arbitrated loop topology. Two hosts are connected to a dual-ported StorageWorks MSA 1000 storage system. OpenVMS supports an arbitrated loop topology only on this storage system.

Figure 7-3 Arbitrated Loop Topology Using MSA 1000

OpenVMS supports the Fibre Channel devices listed in the Software Product Description. For Fibre Channel fabric components supported by OpenVMS, refer to the latest version of HP StorageWorks SAN Design Reference Guide (order number AA-RMPNM-TE).

Note that Fibre Channel hardware names typically use the letter G to designate hardware that is specific to Fibre Channel. Fibre Channel configurations with other Fibre Channel equipment are not supported. To determine the required minimum versions of the operating system and firmware, see the release notes.

HP recommends that all OpenVMS Fibre Channel configurations use the latest update kit for the OpenVMS version they are running.

The root name of these kits is FIBRE_SCSI, a change from the earlier naming convention of FIBRECHAN. The kits are available from the following web site:

http://welcome.hp.com/country/us/eng/support.html

OpenVMS supports the Fibre Channel SAN configurations described in the latest HP StorageWorks SAN Design Reference Guide and the Data Replication Manager (DRM) user documentation. This includes support for:

• Multiswitch FC fabrics.
• Support for up to 500 meters of multimode fiber, and support for up to 100-kilometer interswitch links (ISLs) using single-mode fiber. In addition, DRM configurations provide longer-distance ISLs through the use of the Open Systems Gateway and Wave Division Multiplexors.
• Sharing of the fabric and the HSG storage with non-OpenVMS systems.

The StorageWorks documentation is available from their web site, which you can access from the OpenVMS web page:

http://www.hp.com/go/openvms

Select HP Storage (from related links in the left navigational bar). Next, locate the storage product. Then you can access the product's documentation.

Within the configurations described in the StorageWorks documentation, OpenVMS provides the following capabilities and restrictions:

• All OpenVMS disk functions are supported: system disk, dump disks, shadow set member, quorum disk, and MSCP served disk. Each virtual disk must be assigned an identifier that is unique clusterwide.
• OpenVMS provides support for the number of hosts, switches, and storage controllers specified in the StorageWorks documentation. In general, the number of hosts and storage controllers is limited only by the number of available fabric connections.
• The number of Fibre Channel host bus adapters per platform depends on the platform type. Currently, the largest platforms support up to 26 adapters (independent of the number of OpenVMS instances running on the platform).
• OpenVMS requires that the HSG operate in SCSI-3 mode, and if the HSG is in a dual redundant configuration, then the HSG must be in multibus failover mode. The HSG can only be shared with other systems that operate in these modes.
• The OpenVMS Fibre Channel host bus adapter must be connected directly to the FC switch. The host bus adapter is not supported on a Fibre Channel loop, nor in a point-to-point connection to another Fibre Channel end node.
• Neither the KGPSA-BC nor the KGPSA-CA can be connected to the same PCI bus as the S3 Trio 64V+ Video Card (PB2GA-JC/JD). On the AlphaServer 800, the integral S3 Trio must be disabled when the KGPSA is installed.
• Hosts on the fabric can be configured as a single cluster or as multiple clusters and/or nonclustered nodes. It is critical to ensure that each cluster and each nonclustered system has exclusive access to its storage devices. HSG/HSV selective storage presentation and FC switch zoning or both can be used to ensure that each HSG/HSV storage device is accessible to only one cluster or one nonclustered system.
• The HSG supports a limited number of connections. A connection is a nonvolatile record of a particular host bus adapter communicating with a particular port on the HSG. (Refer to the HSG CLI command SHOW CONNECTIONS.) The HSG ACS V8.6 supports a maximum of 96 connections, whereas HSG ACS V8.5 allows a maximum of 64 connections, and HSG ACS V8.4 allows a maximum of 32 connections. The connection limit is the same for both single and dual redundant controllers.
  If your FC fabric is large, and the number of active connections exceeds the HSG limit, then you must reconfigure the fabric, or use FC switch zoning to "hide" some of the adapters from some of the HSG ports, in order to reduce the number of connections.
  The HSG does not delete connection information from the connection table when a host bus adapter is disconnected. Instead, the user must prevent the table from becoming full by explicitly deleting the connection information using a CLI command.

This configuration support is in effect as of the revision date of this document. OpenVMS plans to increase these limits in future releases.

In addition to the configurations already described, OpenVMS also supports the SANworks Data Replication Manager. This is a remote data vaulting solution that enables the use of Fibre Channel over longer distances. For more information, see the HP StorageWorks web site, which you can access from the OpenVMS web page:

http://www.hp.com/go/openvms

Select HP Storage (from related links in the left navigational bar). Next, locate the storage product.