The operating system manages proper operation of hardware and software components and resources.

Figure 1.1 shows how the hardware and operating system components fit together in a typical OpenVMS Cluster system.

Optional storage enhancement software improves the performance or availability of storage subsystems.

System management software helps you manage your OpenVMS Cluster system.

In addition to these general rules, more detailed guidelines apply to different configurations. The rest of this manual discusses those guidelines in the context of specific configurations.

As with most business decisions, many of your choices will be determined by cost. Prioritizing your requirements can help you apply your budget resources to areas with the greatest business needs.

Reference: For more information about availability, see Chapter 8 in this guide.

Scalability is the ability to expand an OpenVMS Cluster in any system, storage, and interconnect dimension and at the same time fully use the initial configuration equipment. Scalability at the node level means being able to upgrade and add to your node's hardware and software. Scalability at the OpenVMS Cluster level means being able to increase the capacity of your entire OpenVMS Cluster system by adding processing power, interconnects, and storage across many nodes.

HPE offers a full range of OpenVMS Alpha and Integrity systems, with each supporting different processing, storage, and interconnect characteristics. Investing in the appropriate level means choosing systems that meet and perhaps exceed your current business requirements with some extra capacity to spare. The extra capacity is for future growth, because designing too close to your current needs can limit or reduce the scalability of your OpenVMS Cluster.

If you design with future growth in mind, you can make the most of your initial investment, reuse original equipment, and avoid unnecessary upgrades later.

Reference: See Chapter 9 for more help with analyzing your scalability requirements.

Physical restrictions can play a key role in how you configure your OpenVMS Cluster. Designing a cluster for a small computer room or office area is quite different from designing one that will be spread throughout a building or across several miles. Power and air-conditioning requirements can also affect configuration design.

You may want to allow room for physical growth and increased power and cooling requirements when designing your cluster.

Reference: See Section 8.6 and Section 9.3.8 for information about multiple and extended local area network (LAN) configurations.

For information about clusters formed using IP at different geographical locations, see Section C.2.

A secure environment is one that limits physical and electronic access to systems by unauthorized users. Most businesses can achieve a secure environment with little or no performance overhead. However, if security is your highest priority, you may need to make tradeoffs in convenience, cost, and performance.

Reference: See the VSI OpenVMS Guide to System Security for more information.

Systems require approximately 5% more memory to run in an OpenVMS Cluster than to run standalone. This additional memory is used to support the shared cluster resource base, which is larger than in a standalone configuration.

With added memory, a node in an OpenVMS Cluster generally can support the same number of users or applications that it supported as a standalone system. As a cluster configuration grows, the amount of memory used for system work by each node may increase. Because the per-node increase depends on both the level of data sharing in the cluster and the distribution of resource management, that increase does not follow fixed rules. If the node is a resource manager for a heavily used resource, additional memory may increase performance for cluster users of that resource.

Reference: See the OpenVMS Cluster Software Software Product Description for the memory requirements.

For more information about the Accounting utility, the AUTOGEN command procedure, the Monitor utility, the Show Cluster utility, and the System Communications Architecture Control Program (SCACP), refer to the VSI OpenVMS System Management Utilities Reference Manual.

The Fibre Channel interconnect transmits up to 2 Gb/s, 4 Gb/s, 8 Gb/s (depending on adapter). It is a full-duplex serial interconnect that can simultaneously transmit and receive over 100 MB/s.

The MEMORY CHANNEL interconnect has a very high maximum throughput of 100 MB/s. If a single MEMORY CHANNEL is not sufficient, up to two interconnects (and two MEMORY CHANNEL hubs) can share throughput.

The MEMORY CHANNEL adapter connects to the PCI bus. The MEMORY CHANNEL adapter, CCMAA–BA, provides improved performance over the earlier adapter.

Reference: For information about the CCMAA-BA adapter support on AlphaServer systems, go to the VSI OpenVMS web page at: https://vmssoftware.com/products/supported-hardware/.

Reference: For a detailed description of how to connect OpenVMS Alpha SCSI configurations, see Appendix A.

Shared SCSI storage support for two-node OpenVMS Integrity servers Cluster systems was introduced in OpenVMS Version 8.2-1. Prior to this release, shared SCSI storage was supported on OpenVMS Alpha systems only, using an earlier SCSI host-based adapter (HBA).

Figure 4.1 illustrates two-node shared SCSI configuration. Note that a second interconnect, a LAN, is required for host-to-host OpenVMS Cluster communications.(OpenVMS Cluster communications are also known as System Communications Architecture (SCA) communications).

Note, the SCSI IDs of 6 and 7 are required in this configuration. One of the systems must have a SCSI ID of 6 for each A7173A adapter port connected to a shared SCSI bus, instead of the factory-set default of 7. You use the U320_SCSI pscsi.efi utility, included on the IPF Offline Diagnostics and Utilities CD, to change the SCSIID. The procedure for doing this is documented in the HP A7173APCI-X Dual Channel Ultra320 SCSI Host Bus Adapter Installation Guide.

The maximum length of the SCSI interconnect is determined by the signaling method used in the configuration and, for single-ended signaling, by the data transfer rate.

There are two types of electrical signaling for SCSI interconnects: single ended and differential. Both types can operate in standard mode, fast mode, or ultra mode. For differential signaling, the maximum SCSI cable length possible is the same for standard mode and fast mode.

Reference: For information about the SCSI adapters supported on each OpenVMS Integrity server or Alpha system, go to the OpenVMS web page at: https://vmssoftware.com/products/supported-hardware/.

Reference: For information about the SCSI adapters supported on each AlphaServer system, go to the OpenVMS web page at: https://vmssoftware.com/products/supported-hardware/.

A multi-node cluster using SAS provides an alternative to clustered Fibre Channel local loop topologies. This highly scalable SAS architecture enables topologies that provide high performance and high availability with no single point of failure.

SAS solutions accommodate both low cost bulk storage (SATA) or performance and reliability for mission critical applications (SAS)allowing for maximum configuration flexibility and simplicity.

Multiple LAN adapters are supported. The adapters can be for different LAN types or for different adapter models for the same LAN type.

The Ethernet interconnect is typically the lowest cost of all OpenVMS Cluster interconnects.

Ethernet adapters do not provide hardware assistance, so processor overhead is higher than for CI or DSSI.

Consider the capacity of the total network design when you configure an OpenVMS Cluster system with many Ethernet-connected nodes or when the Ethernet also supports a large number of PCs or printers. Multiple Ethernet adapters can be used to improve cluster performance by offloading general network traffic.

Reference: For LAN configuration guidelines, see Section 4.10.2.

Logical LAN failover can be used and configured with IP addresses for cluster communication. This logical LAN failover feature provides high availability in case of any link failure drops. For more information about logical LAN failover, see Section 8.7.

A key challenge is to have comparable performance levels when using IP for cluster traffic. For long distance cluster the speed-of-light delay when dealing with geographically distant sites quickly becomes the dominant factor for latency, overshadowing any delays associated with traversing the IP stacks within the cluster member hosts. There may be a tradeoff between the latency of failover and steady-state performance. Localization of cluster traffic in the normal (non-failover) case as vital to optimizing system performance as the distance between sites is stretched to supported limits is considered.

One of the benefits of OpenVMS Cluster systems is that you can connect storage devices directly to OpenVMS Cluster interconnects to give member systems access to storage.

Before you finish determining your total disk capacity requirements, you may also want to consider future growth for online storage and for backup storage.

For example, at what rate are new files created in your OpenVMS Cluster system? By estimating this number and adding it to the total disk storage requirements that you calculated using Table 5.2, you can obtain a total that more accurately represents your current and future needs for online storage.

To determine backup storage requirements, consider how you deal with obsolete or archival data. In most storage subsystems, old files become unused while new files come into active use. Moving old files from online to backup storage on a regular basis frees online storage for new files and keeps online storage requirements under control.

Planning for adequate backup storage capacity can make archiving procedures more effective and reduce the capacity requirements for online storage.

Reference: See Section 9.5 for more information about how these performance optimizers increase an OpenVMS Cluster's ability to scale I/Os.

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.

Dual-domain SAS creates an additional domain to address the single SAS domain pathway failure. The additional domain uses an open port on an Smart Array controller that is capable of supporting dual-domain SAS. The second port on the dual-domain capable Smart Array controller generates a unique identifier and can support its own domain.

There are no external controllers supported on SAS, you can only connect JABODs such as MSA60/70 and internal disks to SAS HBA. However, P700m can be connected to MSA2000SA (SAS version of MSA2000).

The HSG and HSV storage controllers can connect to a single host or to a multihost Fibre Channel interconnect. For more information about Fibre Channel hardware support, see Section 7.2.

For more information about the buses supported, see the VSI OpenVMS I/O User's Reference Manual.

For the list of supported internal buses and local adapters, see the Software Product Description.

Direct SCSI to direct SCSI failover can be used on systems with multiported SCSI devices. The dual HSZ70, the HSZ80, the HSG80, the dual MDR, and the HSV110 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 for disk devices since Version 6.2.

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

The HS x failover modes are selected by HS x console commands. Transparent and multibus modes are described in more detail in Section 6.3.

The two logical disk devices shown in Figure 6.1 represent virtual storage units that are presented to the host by the HS xcontroller modules. Each logical storage unit is “on line” to one of the two HS x controller modules at a time. When there are multiple logical units, they can be on line to different HS x controllers so that both HS x controllers can be active at the same time.

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

In a multibus failover configuration, SAS and its controllers (LSI 1068 and LSI 1068e) can also be used.

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).

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.

In a direct SCSI to MSCP served failover configuration, SAS and its controllers (LSI 1068 and LSI 1068e) can also be used.

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.

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

In this type of configuration, SAS and its controllers (LSI 1068 and LSI 1068e) can also be used.

In transparent failover mode, the HS x 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.

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.

HSZ> SET FAILOVER COPY=THIS_CONTROLLER

HSZ> SET FAILOVER COPY=OTHER_CONTROLLER

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 

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.

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, then different hosts can access the same logical unit over different ports of the controller to which the logical unit is on line.

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

HSZ> SET MULTIBUS_FAILOVER COPY=THIS_CONTROLLER

HSZ> SET MULTIBUS_FAILOVER COPY=OTHER_CONTROLLER

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 

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.

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 bean address conflict.

In Fibre Channel configurations with the HSG x or the HSV x, all the ports have their own FC address and WWID, as noted in Figure 6.7. The same is true for the MDR.

The ports on the HSG x and the HSV x 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 HSG x or HSV x in multibus mode should be connected, even if there is just one interconnect, because this can improve availability and performance.

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

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.

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.11 shows a system configured in transparent mode using two paths from the host.

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.

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

Figure 6.13 shows a configuration whose devices are 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.

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.

$HSZ-allocation-class$ddcu

HSZ> SET THIS_CONTROLLER ALLOCATION_CLASS = n

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.

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 

Figure 6.19 shows a valid multipath, multihost configuration.

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.

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

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.

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.

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.

SHOW DEVICE/FULL device-name
SHOW DEVICE/MULTIPATH_SET device-name

The SHOW DEVICE/FULL device-name command displays the traditional information about the device first and then lists all the paths to a device by their path identifiers (described in Section 6.7.4).

The SHOW DEVICE/MULTIPATH_SET device-name command lists only some brief multipath information about devices that have multiple paths.

Multipath information is displayed only on nodes that are directly connected to the multipath device.

$ SHOW DEVICE/FULL $1$DGA23:

Disk $1$DGA23: (WILD8), device type HSG80, is online, mounted, file-oriented device, shareable, device has multiple I/O paths, served to cluster via MSCP Server, error logging is enabled.

  Error count                    3    Operations completed           32814199
  Owner process                 ""    Owner UIC                      [SYSTEM]
  Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
  Reference count                9    Default buffer size                 512
  WWID   01000010:6000-1FE1-0000-0D10-0009-8090-0677-0034
  Total blocks            17769177    Sectors per track                   169
  Total cylinders             5258    Tracks per cylinder                  20
  Host name                "WILD8"    Host type, avail HP AlphaServer GS160 6/731, yes
  Alternate host name     "W8GLX1"    Alt. type, avail HP AlphaServer GS160 6/731, yes
  Allocation class               1

  Volume label      "S5SH_V72_SSS"    Relative volume number                0
  Cluster size                  18    Transaction count                     8
  Free blocks             12812004    Maximum files allowed            467609
  Extend quantity                5    Mount count                           8
  Mount status              System    Cache name          "_$1$DGA8:XQPCACHE"
  Extent cache size             64    Maximum blocks in extent cache  1281200
  File ID cache size            64    Blocks currently in extent cache      0
  Quota cache size               0    Maximum buffers in FCP cache       1594
  Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-2, subject to mount verification, file high-water marking, write-back XQP caching enabled, write-through XFC caching enabled. Volume is also mounted on H2OFRD, FIBRE3, NORLMN, SISKO, BOOLA, FLAM10, W8GLX1.

  I/O paths to device              5
  Path PGA0.5000-1FE1-0000-0D12  (WILD8), primary path.
    Error count                    2    Operations completed        130666
  Path PGA0.5000-1FE1-0000-0D13  (WILD8), current path.
    Error count                    1    Operations completed        30879310
  Path PGA0.5000-1FE1-0000-0D11  (WILD8).
    Error count                    0    Operations completed        130521
  Path PGA0.5000-1FE1-0000-0D14  (WILD8).
    Error count                    0    Operations completed        130539
  Path MSCP (W8GLX1).
    Error count                    0    Operations completed        1543163

SHOW DEVICE/MULTIPATH_SET [device-name]

$ SHOW DEVICE/MULTIPATH
Device                  Device           Error  Paths  Current
 Name                   Status           Count Avl/Tot   path
$1$DGA8:      (H2OFRD)  Mounted              3   5/ 5  PGA0.5000-1FE1-0000-0D12
$1$DGA10:     (H2OFRD)  ShadowSetMember      1   5/ 5  PGA0.5000-1FE1-0000-0D14
$1$DGA11:      (WILD8)  ShadowSetMember      3   3/ 3  MSCP
$1$DGA23:     (H2OFRD)  Mounted              6   5/ 5  PGA0.5000-1FE1-0000-0D13
$1$DGA30:     (H2OFRD)  ShadowSetMember      8   5/ 5  PGA0.5000-1FE1-0000-0D13
$1$DGA31:      (WILD8)  ShadowMergeMbr       5   3/ 3  MSCP
$1$DGA33:     (H2OFRD)  Online               0   5/ 5  PGA0.5000-1FE1-0000-0D12
$1$DGA40:     (H2OFRD)  Mounted              2   5/ 5  PGA0.5000-1FE1-0000-0D13
$1$DGA41:     (H2OFRD)  ShadowMergeMbr       8   5/ 5  PGA0.5000-1FE1-0000-0D12
$70$DKA100:   (H2OFRD)  Mounted              0   3/ 3  PKD0.1
$70$DKA104:   (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.1
$70$DKA200:   (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.2
$70$DKA300:   (H2OFRD)  ShadowSetMember      0   3/ 3  PKC0.3
$80$DKA1104:  (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.11
$80$DKA1200:  (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.12
$80$DKA1204:  (H2OFRD)  ShadowSetMember      0   3/ 3  PKC0.12
$80$DKA1207:  (H2OFRD)  Mounted              0   3/ 3  PKD0.12
$80$DKA1300:  (H2OFRD)  Mounted              0   3/ 3  PKD0.13
$80$DKA1307:  (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.13
$80$DKA1500:  (H2OFRD)  Mounted              0   3/ 3  PKD0.15
$80$DKA1502:  (H2OFRD)  ShadowSetMember      0   3/ 3  PKD0.15 

All multipath devices on path PKB0.5 are either disabled or not reachable.

At least one multipath device on path PKB0.5 is enabled and reachable.

If all the devices on a path are removed, a path failure is reported. The path from the host to the HS xcontroller may still function, but this cannot be determined when there are no devices to poll.

SET DEVICE device/[NO]POLL/PATH=path-identifier

Turning off polling for a path that will be out of service for a prolonged period is useful because it can reduce system overhead.

You can switch a device's current path manually using the SET DEVICE command with the /SWITCH qualifier. The most common reason for doing this is to balance the aggregate I/O load across multiple HS x controller modules, MDRs, and buses.

SET DEVICE device-name/SWITCH/PATH=path-identifier

This command requires the OPER privilege. Additionally, if the device is currently allocated by another process, as tape devices often are, the SHARE privilege is needed.

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

Note that this command initiates the process of switching the path and then returns to the DCL prompt immediately. A delay may occur between when the DCL prompt reappears and when the path switch is complete.

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:23.05  %%%%%%%%%%%
 Device $1$DGA23: (H2OFRD PGA) is offline.
 Mount verification is in progress.

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:25.76  %%%%%%%%%%%
 09:04:25.76 Multipath access to device $1$DGA23: has been manually switched
 from path PGA0.5000-1FE1-0000-0D11 to path PGA0.5000-1FE1-0000-0D14

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:25.79  %%%%%%%%%%%
 Mount verification has completed for device $1$DGA23: (H2OFRD PGA)

You can check for completion of a path switch by issuing the SHOWDEVICE/FULL command, or the SHOW DEVICE/MULTIPATH command.

Note that if the path that is designated in a manual path switch fails during the switch operation, then automatic path switching takes over. This can result in a switch to a path different from the one designated in the command.

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:26.48  %%%%%%%%%%%
 Device $1$DGA23: (WILD8 PGA, H20FRD) is offline.
 Mount verification is in progress.

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:26.91  %%%%%%%%%%%
 09:04:29.91 Multipath access to device $1$DGA23: has been auto switched from
 path PGA0.5000-1FE1-0000-0D12 (WILD8) to path PGA0.5000-1FE1-0000-0D13 (WILD8)

 %%%%%%%%%%%  OPCOM  15-JUN-2001 09:04:27.12  %%%%%%%%%%%
 Mount verification has completed for device $1$DGA23: (WILD8 PGA, H20FRD)

The WILD8 node name is displayed for each path because each path is a direct path on node WILD8. The node name field in the mount verification in progress and completed messages shows both a local path and an MSCP alternative. In this example, the WILD8 PGA, H20FRD name shows that a local PGA path on WILD8 is being used and that an MSCP path via node H20FRD is an alternative.

The selection of the current path to a multipath device is determined by the device type as well as by the event that triggered path selection.

Path Selection for Initial Configuration at System Startup

When a new path to a multipath disk (DG, DK) or tape device (MG) is configured, the path chosen automatically as the current path is the direct path with the fewest devices. No operator messages are displayed when this occurs. (This type of path selection is introduced in OpenVMS Alpha Version 7.3-1.) A DG, DK, or MG device is eligible for this type of path selection until the device's first use after a system boot or until a manual path switch is performed by means of the SET DEVICE/SWITCH command.

When a new path to a generic multipath SCSI device (GG, GK) is configured, the path chosen automatically as the current path is the first path discovered, which is also known as the primary path. For GG and GK devices, the primary path remains the current path even as new paths are configured. GG and GK devices are typically the console LUNs for HSG or HSV controller LUNs or for tape media robots.

Path Selection When Mounting a Disk Device

The current path to a multipath disk device can change as a result of a MOUNT command. The I/O performed by the MOUNT command triggers a search for a direct path that does not require the disk device to fail over from one HS x controller to another.

The MOUNT utility might trigger this path selection algorithm a number of times until a working path is found. The exact number of retries depends on both the time elapsed for the prior attempts and the qualifiers specified with the MOUNT command.

HSG> SET UNIT PREFERRED_PATH=THIS_CONTROLLER
HSG> SET UNIT PREFERRED_PATH=OTHER_CONTROLLER

In addition, you can use the DCL commands for manual path switching described in Section 6.7.7, to select a different host bus adapter or a different port on the same HS x controller, or to force the device to fail over to a different HS x controller.

Path Selection When Mounting Tape Drive Device

When an I/O operation fails on a device that is subject to mount verification, and the failure status suggests that retries are warranted, mount verification is invoked. If the device is a multipath device or a shadow set that includes multipath devices, alternate paths to the device are automatically tried during mount verification. This allows the system to recover transparently from cases in which the device has failed over from one HS xcontroller or MDR to another, and to recover transparently from failures in the path to the device.

Note that foreign mounted disk volumes and generic SCSI devices (GG and GK) are not subject to mount verification and, therefore, are not eligible for automatic multipath failover.

This path selection procedure prefers direct paths over MSCP served paths because the use of an MSCP served path imposes additional CPU and I/O overhead on the server system. In contrast, the use of a direct path imposes no additional CPU or I/O overhead on the MSCP-server system. This procedure selects an MSCP served path only if none of the available direct paths are working. Furthermore, this path selection procedure tends to balance the use of available direct paths, subject to the constraint of avoiding unnecessary controller failovers.

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.

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 is attempted by triggering mount verification and, as a result, the automatic failover procedure on the device.

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.

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.

Note that the current path cannot be disabled.

SET DEVICE device-name/[NO]ENABLE/PATH=path-identifier

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

$ 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.

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 responsiveness 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 VSI OpenVMS System Manager's Manual.

VSI 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 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, VSI 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.

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.

>>>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

BOOT DKB100, DKC100

Shared Fibre Channel OpenVMS Cluster storage is supported in both mixed-version and mixed-architecture OpenVMS Cluster systems. Mixed-version support is described in the Software Product Description. Mixed-architecture support means a combination of OpenVMS Alpha systems with OpenVMS Integrity server systems. In an OpenVMS mixed-architecture cluster, each architecture requires a minimum of one system disk.

Figure 7.4 shows a single system using Fibre Channel as a storage interconnect.

Figure 7.5 shows multiple hosts connected to a dual-ported storage subsystem.

Figure 7.6 shows multiple hosts connected to two dual-ported storage controllers.

Figure 7.7 shows multiple hosts connected to two switches, each of which is connected to a pair of dual-ported storage controllers.

Figure 7.8 shows multiple hosts connected to two fabrics; each fabric consists of two switches.

The configurations shown in this section offer even higher levels of performance and scalability.

Figure 7.9 shows multiple hosts connected to two fabrics. Each fabric has four switches.

Figure 7.10 shows multiple hosts connected to four fabrics. Each fabric has four switches.

In most situations, Fibre Channel devices are configured to have temporary addresses. The device's address is assigned automatically each time the interconnect initializes. The device may receive a new address each time a Fibre Channel is reconfigured and reinitialized. This is done so that Fibre Channel devices do not require the use of address jumpers. There is one Fibre Channel address per port, as shown in Figure 7.11.

In order to provide more permanent identification, each port on each device has a WWID, which is assigned at the factory. Every Fibre Channel WWID is unique. Fibre Channel also has node WWIDs to identify multiported devices. WWIDs are used by the system to detect and recover from automatic address changes. They are useful to system managers for identifying and locating physical devices.

Figure 7.12 shows Fibre Channel components with their factory-assigned WWIDs and their Fibre Channel addresses.

$ SHOW DEVICE/FULL FGA0

Device FGA0:, device type KGPSA Fibre Channel, is online, shareable, error
    logging is enabled.

    Error count                    0    Operations completed                  0
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot              S:RWPL,O:RWPL,G,W
    Reference count                0    Default buffer size                   0
    FC Port Name 1000-0000-C923-0E48    FC Node Name        2000-0000-C923-0E48

There is an OpenVMS name for each Fibre Channel storage adapter, for each path from the storage adapter to the storage subsystem, and for each storage device. These sections apply to both disk devices and tape devices, except for Section 7.4.2.3, which is specific to disk devices. Tape device names are described in Section 7.5.

7.4.2.1. Fibre Channel Storage Adapter Names

Fibre Channel storage adapter names, which are automatically assigned by OpenVMS, take the form FGx0:

• FG represents Fibre Channel.

• x represents the unit letter, from A to Z.

• 0 is a constant.

The naming design places a limit of 26 adapters per system. This naming may be modified in future releases to support a larger number of adapters.

Fibre Channel adapters can run multiple protocols, such as SCSI and LAN. Each protocol is a pseudodevice associated with the adapter. For the initial implementation, just the SCSI protocol is supported. The SCSI pseudodevice name is PGx0, where x represents the same unit letter as the associated FGx0 adapter.

These names are illustrated in Figure 7.13.

7.4.2.3. Fibre Channel Disk Device Identification

The four identifiers associated with each FC disk device are shown in Figure 7.14.

The logical unit number (LUN) is used by the system as the address of a specific device within the storage subsystem. This number is set and displayed from the HSG or HSV console by the system manager. It can also be displayed by the OpenVMS SDA utility.

Each Fibre Channel disk device also has a WWID to provide permanent, unique identification of the device. The HSG or HSV device WWID is 128 bits. Half of this identifier is the WWID of the HSG or HSV that created the logical storage device, and the other half is specific to the logical device. The device WWID is displayed by the SHOW DEVICE/FULL command, the HSG or HSV console and the AlphaServer console.

The third identifier associated with the storage device is a user-assigned device identifier. A device identifier has the following attributes:

• User assigned at the HSG or HSV console.

• User must ensure it is cluster unique.

• Moves with the device.

• Can be any decimal number from 0 to 32767.

The device identifier has a value of 567 in Figure 7.14. This value is used by OpenVMS to form the device name so it must be unique throughout the cluster. (It may be convenient to set the device identifier to the same value as the logical unit number (LUN). This is permitted as long as the device identifier is unique throughout the cluster).

A Fibre Channel storage disk device name is formed by the operating system from the constant $1$DGA and a device identifier, nnnnn. Note that Fibre Channel disk device names use an allocation class value of 1 whereas Fibre Channel tape device names use an allocation class value of 2, as described in Section 7.5.2.1. The only variable part of the name is its device identifier, which you assign at the HSG or HSV console. Figure 7.14 shows a storage device that is known to the host as $1$DGA567.

Note

A device identifier of 0 is not supported on the HSV.

The following example shows the output of the SHOW DEVICE/FULL display for this device:

$ SHOW DEVICE/FULL $1$DGA567:

Disk $1$DGA567: (WILD8), device type HSG80, is online, mounted, file-oriented
    device, shareable, device has multiple I/O paths, served to cluster via MSCP
    Server, error logging is enabled.

    Error count                   14    Operations completed            6896599
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                9    Default buffer size                 512
    WWID   01000010:6000-1FE1-0000-0D00-0009-8090-0630-0008
    Total blocks            17769177    Sectors per track                   169
    Total cylinders             5258    Tracks per cylinder                  20
    Host name                "WILD8"    Host type, avail Compaq AlphaServer
                                        GS160 6/731, yes
    Alternate host name     "H2OFRD"    Alt. type, avail AlphaServer 1200 5/533
                                        4MB, yes
    Allocation class               1

    Volume label      "S5SH_V72_SSS"    Relative volume number                0
    Cluster size                  18    Transaction count                     9
    Free blocks             12811860    Maximum files allowed            467609
    Extend quantity                5    Mount count                           6
    Mount status              System    Cache name          "_$1$DGA8:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache  1281186
    File ID cache size            64    Blocks currently in extent cache1260738
    Quota cache size               0    Maximum buffers in FCP cache       1594
    Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-2, subject to mount verification, file high-water marking,
      write-back XQP caching enabled, write-through XFC caching enabled.
  Volume is also mounted on H2OFRD, FIBRE3, NORLMN, BOOLA, FLAM10.

  I/O paths to device              5
  Path PGA0.5000-1FE1-0000-0D02  (WILD8), primary path.
    Error count                    0    Operations completed              14498
  Path PGA0.5000-1FE1-0000-0D03  (WILD8), current path.
    Error count                   14    Operations completed            6532610
  Path PGA0.5000-1FE1-0000-0D01  (WILD8).
    Error count                    0    Operations completed              14481
  Path PGA0.5000-1FE1-0000-0D04  (WILD8).
    Error count                    0    Operations completed              14481
  Path MSCP (H2OFRD).
    Error count                    0    Operations completed             320530

This section provides detailed background information about Fibre Channel Tape device naming.

Tape and medium changer devices are automatically named and configured using the SYSMAN IO FIND and IO AUTOCONFIGURE commands described in Section 7.5.3. System managers who configure tapes on Fibre Channel should refer directly to this section for the tape configuration procedure.

%SYSMAN-E-NOWWID, error for device Product-ID, no valid WWID found.

0C000008:0800-4606-8010-CD3C

04100022:"COMPAQ  DLT8000         JF71209240" 

[Device $2$devnam]
WWID = displayable_identifier

!
[Device $2$MGA300]
WWID = 04100022:"COMPAQ  DLT8000         JF71209240"
!
[Device $2$mga23]
WWID = 04100022:"DEC     TZ89     (C) DECJL01164302"

This section lists the steps required to configure a new tape or medium changer on the Fibre Channel.

$ MCR SYSMAN IO FIND_WWID

%SYSMAN-I-OUTPUT, command execution on node SAMPLE
On port _SAMPLE$PGA0:, the following tape WWIDs and their proposed device
names have been found but not yet configured:

      [Device $2$GGA0]
      WWID=04100024:"DEC     TL800    (C) DEC3G9CCR82A017"

      [Device $2$MGA0]
      WWID=04100022:"DEC     TZ89     (C) DECCX939S2777"

      [Device $2$MGA1]
      WWID=04100022:"DEC     TZ89     (C) DECCX942S6295"

$ TYPE SYS$SYSTEM:SYS$DEVICES.DAT
!
! Updated 23-OCT-2000 14:17:41.85:  DEC TL800
!
[Device $2$GGA0]
WWID=04100024:"DEC     TL800    (C) DEC3G9CCR82A017"
!
!
! Updated 23-OCT-2000 14:17:41.93:  DEC TZ89
!
[Device $2$MGA0]
WWID=04100022:"DEC     TZ89     (C) DECCX939S2777"
!
!
! Updated 23-OCT-2000 14:17:42.01:  DEC TZ89
!
[Device $2$MGA1]
WWID=04100022:"DEC     TZ89     (C) DECCX942S6295"
!

$ MCR SYSMAN IO AUTOCONFIGURE/LOG

%SYSMAN-I-OUTPUT, command execution on node SAMPLE
%IOGEN-I-PREFIX, searching for ICBM with prefix SYS$
%IOGEN-I-PREFIX, searching for ICBM with prefix DECW$
%IOGEN-I-SCSIPOLL, scanning for devices through SCSI port PKA0
%IOGEN-I-SCSIPOLL, scanning for devices through SCSI port PKB0
%IOGEN-I-FIBREPOLL, scanning for devices through FIBRE port PGA0
%IOGEN-I-CONFIGURED, configured device GGA0
%IOGEN-I-CONFIGURED, configured device MGA0
%IOGEN-I-CONFIGURED, configured device MGA1

$ SHOW DEVICE/FULL $2$MG

Magtape $2$MGA0: (SAMPLE), device type TZ89, is online, file-oriented device,
   available to cluster, error logging is enabled, controller supports
   compaction (compaction  disabled), device supports fastskip.

   Error count                    0    Operations completed                  0
   Owner process                 ""    Owner UIC                      [SYSTEM]
   Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
   Reference count                0    Default buffer size                2048
   WWID   04100022:"DEC     TZ89     (C) DECCX939S2777"
   Density                  default    Format                        Normal-11
   Allocation class               2

   Volume status:  no-unload on dismount, position lost, odd parity.

Magtape $2$MGA1: (SAMPLE), device type TZ89, is online, file-oriented device,
  available to cluster, error logging is enabled, controller supports
  compaction (compaction  disabled), device supports fastskip.

   Error count                    0    Operations completed                  0
   Owner process                 ""    Owner UIC                      [SYSTEM]
   Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
   Reference count                0    Default buffer size                2048
   WWID   04100022:"DEC     TZ89     (C) DECCX942S6295"
   Density                  default    Format                        Normal-11
   Allocation class               2

   Volume status:  no-unload on dismount, position lost, odd parity.

$ write sys$output f$getdvi("$2$MGA0","WWID")
04100022:"DEC     TZ89     (C) DECCX939S2777"

SYSMAN> IO CREATE_WWID $2$MGA3/WWID=04100022:"DEC   TZ89   (C) DECCX939S2341"

Systm1> mcr sysman
SYSMAN> set env/clus
%SYSMAN-I-ENV, current command environment:
        Clusterwide on local cluster
        Username SYSTEM       will be used on nonlocal nodes

SYSMAN> io list_wwid

%SYSMAN-I-OUTPUT, command execution on node SYSTM2
On port _SYSTM2$PGA0:, the following tape WWIDs are not yet configured:

Target 8, LUN 1, HP       ESL9000 Series
WWID=0C000008:0050-8412-9DA1-0026

Target 8, LUN 2, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-84D1

Target 8, LUN 3, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-4E4E

On port _SYSTM2$PGB0:, the following tape WWIDs are not yet configured:

Target 6, LUN 1, HP       ESL9000 Series
WWID=0C000008:0050-8412-9DA1-0026

Target 6, LUN 2, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-84D1

Target 6, LUN 3, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-4E4E

%SYSMAN-I-OUTPUT, command execution on node SYSTM1
On port _SYSTM1$PGA0:, the following tape WWIDs are not yet configured:


Target 6, LUN 1, HP       ESL9000 Series
WWID=0C000008:0050-8412-9DA1-0026

Target 6, LUN 2, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-84D1

Target 6, LUN 3, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-4E4E


On port _SYSTM1$PGB0:, the following tape WWIDs are not yet configured:


Target 5, LUN 1, HP       ESL9000 Series
WWID=0C000008:0050-8412-9DA1-0026

Target 5, LUN 2, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-84D1

Target 5, LUN 3, COMPAQ   SDLT320
WWID=02000008:500E-09E0-0009-4E4E


%SYSMAN-I-NODERR, error returned from node SYSTM1
-SYSTEM-W-NOMORENODE, no more nodes
SYSMAN>

SYSMAN> io create_wwid $2$GGA40/WWID=0C000008:0050-8412-9DA1-0026
%SYSMAN-I-NODERR, error returned from node SYSTM1
-SYSTEM-W-NOMORENODE, no more nodes
SYSMAN> io create_wwid $2$mga40/WWID=02000008:500E-09E0-0009-84D1
%SYSMAN-I-NODERR, error returned from node SYSTM1
-SYSTEM-W-NOMORENODE, no more nodes
SYSMAN> io create_wwid $2$mga41/WWID=02000008:500E-09E0-0009-4E4E
%SYSMAN-I-NODERR, error returned from node SYSTM1
-SYSTEM-W-NOMORENODE, no more nodes
SYSMAN>

SYSMAN> io auto/lo

%SYSMAN-I-OUTPUT, command execution on node SYSTM2
%IOGEN-I-PREFIX, searching for ICBM with prefix SYS$
%IOGEN-I-PREFIX, searching for ICBM with prefix DECW$
%IOGEN-I-FIBREPOLL, scanning for devices through FIBRE port PGA0
%IOGEN-I-CONFIGURED, configured device GGA40
%IOGEN-I-CONFIGURED, configured device MGA40
%IOGEN-I-CONFIGURED, configured device MGA41
%IOGEN-I-FIBREPOLL, scanning for devices through FIBRE port PGB0
%IOGEN-I-CONFIGURED, configured device GGA40
%IOGEN-I-CONFIGURED, configured device MGA40
%IOGEN-I-CONFIGURED, configured device MGA41

%SYSMAN-I-OUTPUT, command execution on node SYSTM1
%IOGEN-I-PREFIX, searching for ICBM with prefix SYS$
%IOGEN-I-PREFIX, searching for ICBM with prefix DECW$
%IOGEN-I-FIBREPOLL, scanning for devices through FIBRE port PGA0
%IOGEN-I-CONFIGURED, configured device GGA40
%IOGEN-I-CONFIGURED, configured device MGA40
%IOGEN-I-CONFIGURED, configured device MGA41
%IOGEN-I-FIBREPOLL, scanning for devices through FIBRE port PGB0
%IOGEN-I-CONFIGURED, configured device GGA40
%IOGEN-I-CONFIGURED, configured device MGA40
%IOGEN-I-CONFIGURED, configured device MGA41
%SYSMAN-I-NODERR, error returned from node SYSTM1
-SYSTEM-W-NOMORENODE, no more nodes
SYSMAN> exit
Systm1>
Systm1>SHOW DEVICE/FULL $2$GG

Device $2$GGA40:, device type Generic SCSI device, is online, shareable, device
    has multiple I/O paths.

    Error count                    0    Operations completed                  0
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot    S:RWPL,O:RWPL,G:RWPL,W:RWPL
    Reference count                0    Default buffer size                   0
    WWID   0C000008:0050-8412-9DA1-0026

  I/O paths to device              2
  Path PGA0.1000-00E0-0242-86ED (SYSTM1), primary path, current path.
    Error count                    0    Operations completed                  0
  Path PGB0.1000-00E0-0222-86ED (SYSTM1).
    Error count                    0    Operations completed                  0

Systm1> sho dev/fu $2$MG

Magtape $2$MGA40: (SYSTM1), device type COMPAQ SDLT320, is online, file-oriented
    device, available to cluster, device has multiple I/O paths, error logging
    is enabled, device supports fastskip (per_io).

    Error count                    0    Operations completed                  2
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                0    Default buffer size                2048
    WWID   02000008:500E-09E0-0009-84D1
    Density                  default    Format                        Normal-11
    Host name               "SYSTM1"    Host type, avail AlphaServer DS10
                                        466 MHz, yes
    Alternate host name     "SYSTM2"    Alt. type, avail AlphaServer DS10
                                        466 MHz,  no
    Allocation class               2

  Volume status:  no-unload on dismount, position lost, odd parity.

  I/O paths to device              2
  Path PGA0.1000-00E0-0242-86ED (SYSTM1), primary path, current path.
    Error count                    0    Operations completed                  1
  Path PGB0.1000-00E0-0222-86ED (SYSTM1).
    Error count                    0    Operations completed                  1


Magtape $2$MGA41: (SYSTM1), device type COMPAQ SDLT320, is online, file-oriented
    device, available to cluster, device has multiple I/O paths, error logging
    is enabled, device supports fastskip (per_io).

    Error count                    0    Operations completed                  0
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                0    Default buffer size                2048
    WWID   02000008:500E-09E0-0009-4E4E
    Density                  default    Format                        Normal-11
    Host name               "SYSTM1"    Host type, avail AlphaServer DS10
                                        466 MHz, yes
    Alternate host name     "SYSTM2"    Alt. type, avail AlphaServer DS10
                                        466 MHz,  no
    Allocation class               2

  Volume status:  no-unload on dismount, position lost, odd parity.

  I/O paths to device              2
  Path PGA0.1000-00E0-0242-86ED (SYSTM1), primary path, current path.
    Error count                    0    Operations completed                  0
  Path PGB0.1000-00E0-0222-86ED (SYSTM1).
    Error count                    0    Operations completed                  0

Systm1>

Because SYS$SYSTEM:SYS$DEVICES.DAT is a text file, you can edit it but only to change the unit number of a Fibre Channel tape or medium changer device. However, as stated earlier, Fibre Channel tape and medium changer device information is stored internally by OpenVMS using clusterwide data structures, specifically clusterwide logical names. To clean up these data structures, you must do a complete cluster shutdown. A rolling reboot (leaving at least one node up during the reboot of other nodes) is inadequate to clean up the structures.

When you move a tape or medium changer device without changing its name, rebooting is not required. However, you must ensure that the NSR or MDR has assigned a FC LUN to the device at its new location, and you must then run SYSMAN IO AUTOCONFIGURE to configure the new physical path to the device. For changers only, you must also manually switch the changer to the new path using the SET DEVICE/SWITCH/PATH=new_path command. The previous paths will still show up in the SHOW DEV/FULL display, but those paths will be stale and unused, with no harmful side effects; after the next reboot the stale paths will disappear.

You can swap out an NSR without rebooting the Alpha system or Integrity server system.

After attaching the new NSR, use the Mapping submenu in the Visual Manager to populate the Indexed map on each Fibre Channel port of the NSR and reboot the NSR. An alternative way to map the new NSR is to copy the .cfg file from the previous NSR via the NSR's FTP utility.

Once the Indexed map is populated, run SYSMAN IO AUTOCONFIGURE to configure the new physical paths to the tape. For changers only, you must also manually switch the changer to the new path using the SET DEVICE/SWITCH/PATH=new_path command. The previous paths will still show up in the SHOW DEV/FULL display, but those paths will be stale and unused, with no harmful side effects; after the next reboot the stale paths will disappear.

In general, all OpenVMS Alpha or Integrity server nodes in an OpenVMS Cluster have a direct path to Fibre Channel tape devices if the nodes are connected to the same Fibre Channel fabric as the NSR or MDR.

Medium changers, whether connected to Fibre Channel or to parallel SCSI, cannot be TMSCP served.

If one tape drive must be physically replaced by another tape drive at the same FC LUN location within the MDR or NSR, update the appropriate data structures with the IO REPLACE_WWID command.

For example, you may need to replace a defective tape drive with a new drive without rebooting the cluster, and that drive may need to retain the device name of the previous tape at that location.

$ MCR SYSMAN IO REPLACE_WWID $2$MGA1

$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> IO REPLACE_WWID $2$MGA1

In some cases, this command may fail because the device name $2$MGA1 no longer exists in the SHOW DEVICE display. This happens when the system has been rebooted some time after the drive has malfunctioned. In such a case, you must specify both the device name and the WWID, as shown in the following example.

$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> IO REPLACE_WWID $2$MGA1/WWID=02000008:500E-09E0-0009-4E44

Fibre Channel tape devices can be configured in the context of booting from the CDROM distribution kit. The configuration steps are the same as the steps described in Section 7.5.4. Specifically, you must use the SYSMAN IO FIND_WWID and IO AUTOCONFIGURATION commands to configure the tape devices prior to use.

The file, SYS$DEVICES.DAT, is not created in this environment; therefore all pertinent naming information is stored in the memory data structures. Each time the CDROM is booted, you must repeat the IO FIND_WWID and IO AUTOCONFIGURE commands to name and configure the tape devices.

Note that the name of a Fibre Channel tape device in the CDROM boot environment does not persist through reboots, and may differ from the name that is assigned when booting from a read/write system disk

In a Fibre Channel configuration with SCSI tape devices attached to the Fibre Channel by means of an NSR or MDR, multiple paths can exist from an Alpha or an Integrity server system host to a SCSI tape. For example, an AlphaServer host with four KGPSA adapters has four distinct paths to a tape on the Fibre Channel. Furthermore, the NSR itself can be dual ported, allowing two paths into the NSR. An AlphaServer system with four KGPSAs leading to a dual-ported NSR actually has eight different paths from the AlphaServer system to a given tape drive.

Console SHOW commands can be used to display information about the devices that the console detected when it last probed the system's I/O adapters. Unlike other interconnects, however, FC disk devices are not automatically included in the SHOW DEVICE output. This is because FC devices are identified by their WWIDs, and WWIDs are too large to be included in the SHOW DEVICE output. Instead, the console provides a command for managing WWIDs, named the wwidmgr command. This command enables you to display information about FC devices and to define appropriate device names for the FC devices that will be used for booting and dumping.

Refer to the Wwidmgr Users' Manual for a complete description of the wwidmgr command. (The Wwidmgr Users' Manual is available in the [.DOC] directory of the Alpha Systems Firmware Update CD-ROM).

The following examples, produced on an AlphaServer 4100 system, show some typical uses of the wwidmgr command. Other environments may require additional steps to be taken, and the output on other systems may vary slightly.

P00>>>SET MODE DIAG
Console is in diagnostic mode
P00>>>wwidmgr -show wwid
polling kgpsa0 (KGPSA-B) slot 2, bus 0 PCI, hose 1
kgpsaa0.0.0.2.1            PGA0        WWN 1000-0000-c920-a7db
polling kgpsa1 (KGPSA-B) slot 3, bus 0 PCI, hose 1
kgpsab0.0.0.3.1            PGB0        WWN 1000-0000-c920-a694
[0] UDID:10 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016 (ev:none)
[1] UDID:50 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026 (ev:none)
[2] UDID:51 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027 (ev:none)
[3] UDID:60 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021 (ev:none)
[4] UDID:61 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022 (ev:none)

P00>>>wwidmgr -show wwid -full

kgpsaa0.0.0.2.1
- Port: 1000-0000-c920-a7db

kgpsaa0.0.0.2.1
- Port: 2007-0060-6900-075b

kgpsaa0.0.0.2.1
- Port: 20fc-0060-6900-075b

kgpsaa0.0.0.2.1
- Port: 5000-1fe1-0000-0d14
 - dga12274.13.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016
 - dga15346.13.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026
 - dga31539.13.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027
 - dga31155.13.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021
 - dga30963.13.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022

kgpsaa0.0.0.2.1
- Port: 5000-1fe1-0000-0d11
 - dga12274.14.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016
 - dga15346.14.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026
 - dga31539.14.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027
 - dga31155.14.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021
 - dga30963.14.0.2.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022

kgpsab0.0.0.3.1
- Port: 1000-0000-c920-a694

kgpsab0.0.0.3.1
- Port: 2007-0060-6900-09b8

kgpsab0.0.0.3.1
- Port: 20fc-0060-6900-09b8

kgpsab0.0.0.3.1
- Port: 5000-1fe1-0000-0d13
 - dgb12274.13.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016
 - dgb15346.13.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026
 - dgb31539.13.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027
 - dgb31155.13.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021
 - dgb30963.13.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022

kgpsab0.0.0.3.1
- Port: 5000-1fe1-0000-0d12
 - dgb12274.14.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016
 - dgb15346.14.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026
 - dgb31539.14.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027
 - dgb31155.14.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021
 - dgb30963.14.0.3.1 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022


[0] UDID:10 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0016 (ev:none)
 - current_unit:12274 current_col: 0 default_unit:12274
          via adapter       via fc_nport       Con     DID     Lun
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d14   Yes   210013     10
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d11   No    210213     10
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d13   Yes   210013     10
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d12   No    210213     10

[1] UDID:50 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0026 (ev:none)
 - current_unit:15346 current_col: 0 default_unit:15346
          via adapter       via fc_nport       Con     DID     Lun
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d14   Yes   210013     50
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d11   No    210213     50
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d13   Yes   210013     50
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d12   No    210213     50

[2] UDID:51 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0027 (ev:none)
 - current_unit:31539 current_col: 0 default_unit:31539
          via adapter       via fc_nport       Con     DID     Lun
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d14   Yes   210013     51
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d11   No    210213     51
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d13   Yes   210013     51
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d12   No    210213     51

[3] UDID:60 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0021 (ev:none)
 - current_unit:31155 current_col: 0 default_unit:31155
          via adapter       via fc_nport       Con     DID     Lun
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d14   Yes   210013     60
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d11   No    210213     60
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d13   Yes   210013     60
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d12   No    210213     60

[4] UDID:61 WWID:01000010:6000-1fe1-0000-0d10-0009-8090-0677-0022 (ev:none)
 - current_unit:30963 current_col: 0 default_unit:30963
          via adapter       via fc_nport       Con     DID     Lun
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d14   Yes   210013     61
 -      kgpsaa0.0.0.2.1  5000-1fe1-0000-0d11   No    210213     61
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d13   Yes   210013     61
 -      kgpsab0.0.0.3.1  5000-1fe1-0000-0d12   No    210213     61

You must use the wwidmgr command to set up each device that you will use for booting or dumping. Once a device is set up, the console retains the information it requires to access the device in nonvolatile memory. You only have to rerun the wwidmgr command if the system configuration changes and the nonvolatile information is no longer valid.

If neither description applies to your configuration, refer to the Wwidmgr Users' Manual for additional instructions.

P00>>>wwidmgr -quickset -udid 10

Disk assignment and reachability after next initialization:


6000-1fe1-0000-0d10-0009-8090-0677-0016
                          via adapter:         via fc nport:        connected:
dga10.1001.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d14      Yes
dga10.1002.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d11      No
dgb10.1003.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d13      Yes
dgb10.1004.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d12      No
P00>>>wwidmgr -quickset -udid 50

Disk assignment and reachability after next initialization:


6000-1fe1-0000-0d10-0009-8090-0677-0016
                          via adapter:         via fc nport:        connected:
dga10.1001.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d14      Yes
dga10.1002.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d11      No
dgb10.1003.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d13      Yes
dgb10.1004.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d12      No

6000-1fe1-0000-0d10-0009-8090-0677-0026
                          via adapter:         via fc nport:        connected:
dga50.1001.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d14      Yes
dga50.1002.0.2.1         kgpsaa0.0.0.2.1      5000-1fe1-0000-0d11      No
dgb50.1003.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d13      Yes
dgb50.1004.0.3.1         kgpsab0.0.0.3.1      5000-1fe1-0000-0d12      No
P00>>>initialize
Initializing...
P00>>>show device
polling ncr0 (NCR 53C810) slot 1, bus 0 PCI, hose 1   SCSI Bus ID 7
dka500.5.0.1.1     DKA500                   RRD45  1645
polling kgpsa0 (KGPSA-B) slot 2, bus 0 PCI, hose 1
kgpsaa0.0.0.2.1            PGA0        WWN 1000-0000-c920-a7db
dga10.1001.0.2.1   $1$DGA10                 HSG80  R024
dga50.1001.0.2.1   $1$DGA50                 HSG80  R024
dga10.1002.0.2.1   $1$DGA10                 HSG80  R024
dga50.1002.0.2.1   $1$DGA50                 HSG80  R024
polling kgpsa1 (KGPSA-B) slot 3, bus 0 PCI, hose 1
kgpsab0.0.0.3.1            PGB0        WWN 1000-0000-c920-a694
dgb10.1003.0.3.1   $1$DGA10                 HSG80  R024
dgb50.1003.0.3.1   $1$DGA50                 HSG80  R024
dgb10.1004.0.3.1   $1$DGA10                 HSG80  R024
dgb50.1004.0.3.1   $1$DGA50                 HSG80  R024
polling isp0 (QLogic ISP1020) slot 4, bus 0 PCI, hose 1   SCSI Bus ID 15
dkb0.0.0.4.1       DKB0                     RZ1CB-CS  0844
dkb100.1.0.4.1     DKB100                   RZ1CB-CS  0844
polling floppy0 (FLOPPY) PCEB - XBUS hose 0
dva0.0.0.1000.0    DVA0                      RX23
polling ncr1 (NCR 53C810) slot 4, bus 0 PCI, hose 0   SCSI Bus ID 7
dkc0.0.0.4.0       DKC0                     RZ29B  0007
polling tulip0 (DECchip 21040-AA) slot 3, bus 0 PCI, hose 0
ewa0.0.0.3.0       00-00-F8-21-09-74    Auto-Sensing

P00>>>set bootdef_dev dga50.1002.0.2.1,dga50.1001.0.2.1,dgb50.1003.0.3.1,
dgb50.1004.0.3.1
P00>>>b
(boot dga50.1002.0.2.1 -flags 0,0)
dga50.1002.0.2.1 is not connected
dga50.1002.0.2.1 is not connected
dga50.1002.0.2.1 is not connected
dga50.1002.0.2.1 is not connected
failed to open dga50.1002.0.2.1
(boot dga50.1001.0.2.1 -flags 0,0)
block 0 of dga50.1001.0.2.1 is a valid boot block
reading 919 blocks from dga50.1001.0.2.1
bootstrap code read in
Building FRU table
base = 200000, image_start = 0, image_bytes = 72e00
initializing HWRPB at 2000
initializing page table at 1f2000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code


    OpenVMS (TM) Alpha Operating System, Version V7.2
...

$ SHOW DEVICE

Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
$1$DGA10:     (FCNOD1)  Online               0
$1$DGA50:     (FCNOD1)  Mounted              0  V72_SSB        4734189   303   1
$1$DGA51:     (FCNOD1)  Online               0
$1$DGA60:     (FCNOD1)  Online               0
$1$DGA61:     (FCNOD1)  Online               0

$ SHOW LOGICAL SYS$SYSDEVICE
   "SYS$SYSDEVICE" = "$1$DGA50:" (LNM$SYSTEM_TABLE)

$ SHO DEV/MULTI

Device                  Device           Error         Current
 Name                   Status           Count  Paths    path
$1$DGA10:     (FCNOD1)  Online               0   4/ 4  PGB0.5000-1FE1-0000-0D11
$1$DGA50:     (FCNOD1)  Mounted              0   4/ 4  PGA0.5000-1FE1-0000-0D12
$1$DGA51:     (FCNOD1)  Online               0   4/ 4  PGA0.5000-1FE1-0000-0D13
$1$DGA60:     (FCNOD1)  Online               0   4/ 4  PGB0.5000-1FE1-0000-0D14
$1$DGA61:     (FCNOD1)  Online               0   4/ 4  PGB0.5000-1FE1-0000-0D11
Device                  Device           Error         Current
 Name                   Status           Count  Paths    path
$1$GGA42:               Online               0   4/ 4  PGB0.5000-1FE1-0000-0D11

Before you can boot on a FC device on OpenVMS Integrity server systems, you must update the EFI bootable firmware of the flash memory of the FC HBA.

To update the firmware, use the efiutil.efi utility, which is located on the IPF Offline Diagnostics and Utilities CD.

For more information on this utility, refer to the VSI OpenVMS System Manager's Manual.

For configuring additional nodes to boot with a shared FC Disk on an OpenVMS Cluster system, VSI requires that you execute the OpenVMS Integrity servers Boot Manager (BOOT_OPTIONS.COM).

When a Fibre Channel host bus adapter is connected (through a Fibre Channel switch) to an HSG controller, the HSG controller creates an entry in the HSG connection table. There is a separate connection for each host bus adapter, and for each HSG port to which the adapter is connected. (Refer to the HSG CLI command SHOW CONNECTIONS for more information).

Once an HSG connection exists, you can modify its parameters by using commands that are described in the HSG Array Controller ACS Configuration and CLI Reference Guide. Since a connection can be modified, the HSG does not delete connection information from the table when a host bus adapter is disconnected. Instead, when the user is done with a connection, the user must explicitly delete the connection using a CLI command.

The HSG controller supports a limited number of connections: ACS V8.5 allows a maximum of 64 connections and ACS V8.4 allows a maximum of 32 connections. The connection limit is the same for both single- and dual-redundant controllers. Once the maximum number of connections is reached, then new connections will not be made. When this happens, OpenVMS will not configure disk devices, or certain paths to disk devices, on the HSG.

The solution to this problem is to delete old connections that are no longer needed. However, if your Fibre Channel 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 adapters from some HSG ports to reduce the number of connections.

With redundant components, if one component fails, another is available to users and applications.

Reference: For more information about cluster aliases, generic queues, and autostart queues, refer to the VSI OpenVMS Cluster Systems Manual manual.

When using multiple LAN adapters with multiple LAN segments, distribute the connections to LAN segments that provide MOP service. The distribution allows MOP servers to downline load satellites even when network component failures occur.

It is important to ensure sufficient MOP servers for both Alpha and Integrity server nodes to provide downline load support for booting satellites. By careful selection of the LAN connection for each MOP server (Alpha or VAX, as appropriate) on the network, you can maintain MOP service in the face of network failures.

Figure 8.2 shows a sample configuration for an OpenVMS Cluster system connected to two different LAN segments. The configuration includes Integrity server and Alpha nodes, satellites, and two bridges.

Figure 8.3 shows a sample configuration for an OpenVMS Cluster system connected to three different LAN segments. The configuration also includes both Alpha and Integrity server nodes, satellites and multiple bridges.

Reference: See Section 10.2.4 for more information about boot order and satellite dependencies in a LAN. See VSI OpenVMS Cluster Systems Manual for information about LAN bridge failover.

Reference: For additional information about multiple-site clusters, see VSI OpenVMS Cluster Systems Manual.

The ability to add to the components listed in Table 9.1 in any way that you choose is an important feature that OpenVMS Clusters provide. You can add hardware and software in a wide variety of combinations by carefully following the suggestions and guidelines offered in this chapter and in the products' documentation. When you choose to expand your OpenVMS Cluster in a specific dimension, be aware of the advantages and tradeoffs with regard to the other dimensions. Table 9.2 describes strategies that promote OpenVMS Cluster scalability. Understanding these scalability strategies can help you maintain a higher level of performance and availability as your OpenVMS Cluster grows.

In Figure 9.2, three nodes are connected by two25-m, fast-wide (FWD) SCSI interconnects. Multiple storage shelves are contained in each HSZ controller, and more storage is contained in the BA356 at the top of the figure.

The advantages and disadvantages of the configuration shown in Figure 9.2 include:

Advantages

Disadvantage

Figure 9.3 shows four nodes connected by a SCSI hub. The SCSI hub obtains power and cooling from the storage cabinet, such as the BA356. The SCSI hub does not connect to the SCSI bus of the storage cabinet.

The advantages and disadvantages of the configuration shown in Figure 9.3 include:

Advantages

Disadvantage

In Figure 9.4, six satellites and a boot server are connected by Ethernet.

The advantages and disadvantages of the configuration shown in Figure 9.4 include:

Advantages

Disadvantage

If the boot server in Figure 9.4 became a bottleneck, a configuration like the one shown in Figure 9.5would be required.

Figure 9.5 shows six satellites and two boot servers connected by Ethernet. Boot server 1 and boot server 2 perform MSCP server dynamic load balancing: they arbitrate and share the work load between them and if one node stops functioning, the other takes over. MSCP dynamic load balancing requires shared access to storage.

The advantages and disadvantages of the configuration shown in Figure 9.5 include:

Advantages

Disadvantage

If the LAN in Figure 9.5 became an OpenVMS Cluster bottleneck, this could lead to a configuration like the one shown in Figure 9.6.

Figure 9.6 shows 12 satellites and 2 boot servers connected by two Ethernet segments. These two Ethernet segments are also joined by a LAN bridge. Because each satellite has dual paths to storage, this configuration also features MSCP dynamic load balancing.

The advantages and disadvantages of the configuration shown in Figure 9.6 include: