Updated: 11 December 1998

Volume Shadowing for OpenVMS

Digital's StorageWorks RAID Software for OpenVMS provides ways to configure and use disk drives so that they achieve improved I/O performance. RAID (redundant arrays of independent disks) uses striping technology to chunk data and distribute it across multiple drives. RAID software is available in various levels, one of which is volume shadowing. Table 8-2 describes RAID levels.

Table 8-2 RAID Levels

RAID Level	Description
Level 0	Striping with no redundancy.
Level 1	Shadowing.
Levels 0 + 1	Striping and shadowing together.
Level 3	Striped data with dedicated parity drive. Drives are rotationally synchronized.
Level 5	Striped data and parity.
Level 6	Striped data and parity with two parity drives.

Shadowing striped drives can increase both performance and availability, because you can achieve faster response time with striping and data redundancy with shadowing. In addition to shadowing striped sets, you can also stripe shadow sets. Each strategy offers different advantages and tradeoffs in terms of availability, performance, and cost.

For more information about RAID 0, see the POLYCENTER product documentation set. For more information about RAID 5, see the StorageWorks RAID 5 Software for OpenVMS User's Guide.

As of OpenVMS AXP and OpenVMS VAX Versions 6.2, phase I Volume Shadowing was not available. You can migrate from phase I (controller-based) shadowing to phase II (host-based) shadowing using the information in this appendix, which contains:

• An overview of phase II shadowing features
• How to migrate from phase I to phase II
• A more detailed comparison of phase I and phase II shadowing

Phase II shadowing is designed to fully replace phase I with significantly enhanced features, such as:

• State-of-the-art failover and recovery features and superior data availability
• Support for many more disk controllers and devices in a wider range of configurations
• Support for the HSC60 and HSC90 cache option
• Simplified system management of shadow sets
• Increased availability of shadowed disks
• Improved data reliability
• Support for a large number of shadow sets on a standalone or OpenVMS Cluster system
• Opportunities to use the controller performance assists (see Chapter 6) for enhanced performance

Migrating from phase I to phase II requires dismounting and remounting disks and adjusting shadowing parameters and bootstrap values. This section contains instructions for this process.

A.2.1 Migrating Nonsystem Disk Shadow Sets

To migrate a nonsystem disk shadow set from phase I to phase II shadowing, dismount the phase I shadow set and remount it using the phase II mount semantics. No other preparation is necessary unless you are migrating a system disk shadow set or unless you are preparing to use the copy and merge performance assists. Section A.2.4 includes a sample migration session to help you migrate to phase II volume shadowing.

A.2.2 Migrating System Disk Shadow Sets

To migrate system disk shadow sets to phase II shadowing, you need to reset all system parameters for shadowing, change the VMB registers, and then reboot all systems that are using this shadow set.

A.2.3 Adjusting Parameters and Bootstrap Values

When you migrate the shadow sets to phase II volume shadowing, you must:

• Set the SHADOWING parameter to 2 to indicate phase II.
• Set the SHADOW_SYS_DISK parameter to 1 if the system disk is shadowed.
• Set the SHADOW_SYS_UNIT parameter to the desired virtual unit number.
• Remove any MOUNT commands for the system disk shadow set if you are migrating your system disk to a phase II shadow set. See also Section 3.3 for information about booting from a system disk shadow set.
• If the system disk was a phase I shadow set, change the value in the high-order word (bits <31:16>) of the VMB (primary bootstrap) R3 to zeros.

  Note The high-order word (bits <31:16>) of console register R3 should be set to zeros for phase II volume shadowing. This is input for VMB, the primary bootstrap image for OpenVMS, which is passed via the BOOT command or the boot command file. The low-order word (bits <15:0>) of register R3 should be set to the same value on nodes that are booting off a particular system disk shadow set.

• Prior to rebooting, edit SYSTARTUP_VMS.COM and other command files to change the syntax of all MOUNT command lines to reflect phase II volume shadowing naming conventions.
• Reboot the system or OpenVMS Cluster.

If you cannot reboot the entire OpenVMS Cluster system at the same time, you must dismount the phase I shadow sets and remount them as phase II shadow sets one at a time (see Section A.2.4).

See Section 3.2 for more information about shadowing parameters.

A.2.4 Sample User Session

Example A-1 demonstrates that you need to dismount the phase I shadow set and then remount it using the phase II DSAn virtual unit naming convention. If you migrate a system disk shadow set, you must also set the system parameters for system disk shadowing (see Section 3.2 for more information) and reboot your system. Example A-1 assumes that a phase I shadow set with a virtual unit named $255$DUS45 is already mounted and that all batch and print jobs to the device have been deleted from the queue databases.

Example A-1 Migrating a Phase I Shadow Set to Phase II

$ DISMOUNT/NOUNL $255$DUS45 (1) $ SHOW DEVICES $255$DUS45 (2) Device Device Error Volume Free Trans Mnt Name Status Count Label BlocksCount Cnt $255$DUS45: (DUD) Online 0 $ SHOW DEVICES $255$DUA45 (3) Device Device Error Volume Free Trans Mnt Name Status Count Label BlocksCount Cnt $255$DUA45: (MUD) Online 0 $ MOUNT/CLU DSA34/SHAD=$255$DUA45 VOLUMELABEL LOGICALNAME (4) %MOUNT-I-MOUNTED, VOLUMELABEL mounted on _DSA34: %MOUNT-I-SHDWMEMSUCC, _$255$DUA45: (DUD) is now a valid member of the shadow set

The following list describes the elements in Example A-1:

1. Dismounts the virtual unit $255$DUS45 to dissolve the phase I shadow set.
2. Shows that $255$DUS45 is on line, but it no longer represents a shadow set.
3. Shows that $255$DUA45 is on line, but it is not a shadow set member.
4. Mounts $255$DUA45 as a phase II shadow set represented by the DSA34 virtual unit.

Although there are many differences between the two shadowing phases, the most noticeable differences are:

• Phase II shadowing allows greater flexibility in configurations, especially in the types of controllers and disks supported. (Note that phase II requires that KDM70 disk controllers run a minimum of Version 3.0 microcode.)
  See Chapter 2 for information about shadow set configurations.
• Phase II shadowing allows more shadow sets in a configuration.
  As with phase I shadowing, a phase II shadow set can have a maximum of three shadow set members. However, phase II shadowing allows more shadow sets in standalone and in OpenVMS Cluster systems. See the most recent Volume Shadowing for OpenVMS Software Product Description for information about the maximum number of shadow sets supported. (For OpenVMS Version 7.1 systems, see SPD 25.01.xx.)
• The manner in which a shadow set is served in an OpenVMS Cluster configuration.
  For a phase II shadow set, the member units (not the virtual unit) are served to the OpenVMS Cluster system. All systems that mount a phase II shadow set manage that shadow set collectively.

Phase II volume shadowing allows shadowing on the same configurations as phase I. In addition, it provides distributed shadowing in a controller-independent manner. Phase II volume shadowing supports clusterwide shadowing of all DSA disks that are compliant with the MSCP protocol or SCSI devices having identical physical geometry. The disks can be on a single system or located anywhere in a OpenVMS Cluster system. Note, however, that you need not have OpenVMS Cluster software to run volume shadowing on a single, standalone node.

Shadowing also provides full support for all SCSI devices and for some third-party SCSI devices. Volume Shadowing for OpenVMS can support third-party devices that implement READL (read long) and WRITEL (write long) commands because phase II shadowing software uses the optional SCSI READL and WRITEL commands.

Phase II volume shadowing supports clusterwide shadowing of all DSA and supported SCSI devices. Phase II is not limited to HSC disks; rather, it extends volume shadowing capabilities to all DSA disks, including those on local adapters, all Digital Small Systems Interconnect (DSSI RF-series) disk devices on any VAX computer, all interfaces (CI, Ethernet, mixed interconnect), FDDI, and across MSCP servers.

The underlying design of phase II volume shadowing is different from phase I, but the user interface for the two shadowing products is similar. The OpenVMS Mount utility commands, SHOW commands, and system services for both shadowing products have only a few differences:

• Phase II shadowing uses the DSAn: format to name virtual units.
• You must set the SHADOWING parameter value to 2 to run phase II shadowing on each node. (See Chapter 3 for more information.)
• The Mount utility provides an additional qualifier (/INCLUDE) for phase II shadowing. The /INCLUDE qualifier is useful for automating the task of rebuilding former shadow sets. (See Chapter 4 and Chapter 5 for more information.)
• Nodes that mount a phase II shadow set must have a Volume Shadowing for OpenVMS license installed. For further information, see (regist_sect) or contact your local Digital sales office.

Application I/O semantics for shadow set manipulation are the same for both phase I and phase II shadowing.

A.3.1 Interdependencies Between Operating System Versions and Volume Shadowing Phases

Following are some dependencies to consider when you think about migrating to phase II volume shadowing:

• A VAX node that currently runs VMS Version 5.4 or earlier can use only VAX Volume Shadowing (phase I). Such nodes cannot access a phase II shadow set.
• Any phase I shadow sets that you have mounted are not accessible from OpenVMS Version 6.2 systems.
• Only phase II is supported as of OpenVMS AXP and OpenVMS VAX Versions 6.2.
• An OpenVMS Cluster that contains both Alpha and VAX computers has version interoperability requirements that are described in OpenVMS Cluster Version 7.1 Software Software Product Description 29.78.xx.

This appendix lists volume shadowing status messages that are displayed on the console device. For other system messages that are related to volume shadowing, use the Help Message utility. For information about the HELP/MESSAGE command and qualifiers, see DCL help (type HELP HELP/MESSAGE at the DCL prompt). Messages that can occur before a system is fully functional are also included in OpenVMS System Messages: Companion Guide for Help Message Users.

B.1 Mount Verification Messages

The following mount verification messages have approximately the same meaning for shadow sets as they do for regular disks. They are sent to the system console (OPA0) and to any operator terminals that are enabled to receive disk operator messages.

• virtual-unit: is off line. Mount verification in progress.
• virtual-unit: has completed mount verification.
• virtual-unit: has aborted mount verification.

The following OPCOM message is returned in response to shadow set operations. This message results when the shadowing code detects that the boot device is no longer in the system disk shadow set. If the boot device is not added back into the system disk shadow set, the system may not reboot, and the dump may be lost if the system crashes.

virtual-unit: does not contain the member named to VMB. System may not reboot.
Explanation: This message can occur for the following reasons:

• The boot device is dismounted or failed out of the system disk shadow set.
• Shadowing finds the boot device missing from the system disk shadow set membership during any dismount operations on the system disk.

• Mount the boot device back into the shadow set as soon as possible.
• If you cannot mount the boot device back into the shadow set, change the device name in VMB (primary bootstrap) so the system can reboot when necessary.

Shadow server operations can display the following status messages on the system console (OPA0) and on terminals enabled to receive operator messages.

Shadow server messages are always informational messages and include the prefix %SHADOW_SERVER-I-SSRVmessage-abbreviation. The following example includes the OPCOM banner and the shadow server message to illustrate what the messages look like when they are output to the console:

%%%%%%%%%%% OPCOM 24-MAR-1990 15:01:30.99 %%%%%%%%%%% (from node SYSTMX at 24-MAR-1990 15:01:31.36) Message from user SYSTEM on SYSTMX %SHADOW_SERVER-I-SSRVINICOMP, shadow server has completed initialization.

The following messages are returned by the shadow server in response to shadow set operations. Several of the messages refer to a copy thread number; this is a unique identifier denoting a copy or merge operation. The messages in this section are listed in alphabetical order by message abbreviation. For simplicity, the messages shown here do not include the SHADOW_SERVER-I- prefix.

SSRVCMPFCPY, completing copy operation on device _virtual-unit: at LBN: LBN-location, ID number: copy-thread-number
Explanation: The copy operation has completed.
User Action: None.

SSRVCMPMRG, completing merge operation on device _virtual-unit: at LBN: LBN-location, ID number: copy-thread-number
Explanation: The merge operation has completed.
User Action: None.

SSRVCOMPLYFAIL, still out of compliance for per-disk license units, new shadow members may be immediately removed
Explanation: The number of shadow set members on the node has exceeded the number of VOLSHAD-DISK license units for more than 60 minutes. Attempts to bring the node into compliance by removing unlicensed members from their shadow sets have failed. If any new members are mounted, they might be removed immediately.
User Action: Ensure that the number of VOLSHAD-DISK license units on each node is equal to the number of shadow set members mounted on that node. If necessary, dismount shadow set members until the number of mounted members equals the number of VOLSHAD-DISK license units loaded on the node. If you need more VOLSHAD-DISK license PAKs, contact a Digital support representative.

SSRVINICOMP, shadow server has completed initialization
Explanation: The shadow server has been initialized at boot time.
User Action: None.

SSRVINICPY, initiating copy operation on device _virtual-unit: at LBN: LBN-location, I/O Size: number-of-blocks blocks, ID number: copy-thread-number
Explanation: A copy operation is beginning on the shadow set whose virtual unit number is listed in the message.
User Action: None.

SSRVINIMRG, initiating merge operation on device _virtual-unit: at LBN logical-block-number, I/O Size: number-of-blocks blocks, ID number: copy-thread-number
Explanation: A merge operation is beginning on the shadow set. The merge can occur after a copy operation has completed.
User Action: None.

SSRVINIMMRG, initiating minimerge operation on device _virtual-unit: at LBN LBN-location, I/O size: number-of-blocks blocks, ID number: copy-thread-number
Explanation: A shadowing minimerge is beginning on the device indicated. The message identifies the minimerge with the name of the shadow set virtual unit, and the LBN location of the minimerge, the size of the I/O request (in blocks), and the ID number of the copy thread. For example:

%SHADOW_SERVER-I-SSRVINIMMRG, initiating minimerge operation on device _DSA2: at LBN 0, I/O size: 105 blocks, ID number: 33555161

User Action: None.

SSRVINSUFPDL, insufficient per-disk license units loaded, shadow set member(s) will be removed in number minutes
Explanation: The number of shadow set members mounted exceeds the number of VOLSHAD-DISK license units loaded on the node. If this condition is not corrected before the number of minutes displayed in this message has elapsed, Volume Shadowing will remove unlicensed members from shadow sets in an attempt to make the node compliant with the number of loaded VOLSHAD-DISK license units.
User Action: Dismount shadow set members until the number of mounted members is equal to the number of VOLSHAD-DISK license units on the node.

SSRVNORMAL, successful completion of operation on device _virtual-unit: at LBN LBN-location, ID number: copy-thread-number
Explanation: The copy or merge operation has completed.
User Action: None.

SSRVRESCPY, resuming copy operation on device _virtual-unit: at LBN: logical-block-number I/O size: number-of-blocks blocks, ID number: copy-thread-number
Explanation: A copy operation is resuming. The message identifies the copy with a unique sequence number, the name of the shadow set virtual unit, the LBN location of the copy, and the size of the I/O request (in blocks). For example:

%SHADOW_SERVER-I-SSRVRESFCPY, resuming Full-Copy copy sequence number 16777837 on device _DSA101:, at LBN 208314 I/O size: 71 blocks

User Action: None.

SSRVSPNDCPY, suspending operation on device _virtual-unit: at LBN: logical-block-number, ID number: copy-thread-number
Explanation: A copy operation is being interrupted before it completes. (If a crash occurs during a copy operation, a minimerge assist can interrupt the copy operation to resolve inconsistencies. The shadowing software can resume the copy operation when the minimerge completes.) The following message identifies the copy operation with the name of the shadow set virtual unit, the LBN location of the copy, and a unique ID number.

%SHADOW_SERVER-I-SSRVSPNDCPY, suspending operation on device _DSA101:. at LBN: 208314, ID number: 16777837

User Action: None.

SSRVSPNDMMRG, suspending minimerge operation on device _virtual-unit: at LBN: logical-block-number ID number: copy-thread-number
Explanation: A minimerge is interrupted before it completes. The message identifies the minimerge with the name of the shadow set virtual unit, the LBN location of the minimerge, and a unique ID number. For example:

%SHADOW_SERVER-I-SSRVSPNDMMRG, suspending minimerge operation on device _DSA101:. at LBN: 3907911, ID number: 16777837

User Action: None.

SSRVSPNDMRG, suspending merge operation on device _virtual-unit: at LBN: LBN-location, ID number: copy-thread-number
Explanation: A merge operation has been suspended while the shadow set undergoes a copy operation.
User Action: None.

SSRVTRMSTS, reason for termination of operation on device: _virtual-unit:, abort status
Explanation: This message always accompanies the SSRVTERM message to provide further information about the copy termination.
User Action: Possible actions vary depending on the reason for the error. You might need to check and repair hardware or restart the copy operation.

SSRVTERMCPY, terminating operation on device: _virtual-unit:, ID number: copy-thread-number
Explanation: The copy thread is aborting. See the accompanying SSRVTRMSTS message for more information.
User Action: None.

SSRVTERMMRG, terminating operation on device: _virtual-unit:, ID number: copy-thread-number
Explanation: The merge thread is aborting. See the accompanying SSRVTRMSTS message for more information.
User Action: None.

SSRVTERMMMRG, terminating operation on device: _virtual-unit:, ID number: copy-thread-number
Explanation: The minimerge thread is aborting. See the accompanying SSRVTRMSTS message for more information.
User Action: None.

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

5423PRO_010.HTML