Document revision date: 19 July 1999

Order Number: AA--PVXMF--TE

This manual explains how to use Volume Shadowing for OpenVMS to replicate data transparently on multiple disks and provide high data availability.

Revision/Update Information: This manual supersedes Volume Shadowing for OpenVMS, OpenVMS Alpha Version 7.1 and OpenVMS VAX Version 7.1.

Software Version: OpenVMS Alpha Version 6.2 with the Cluster Compatibility Kit to OpenVMS Alpha Version 7.2-1 OpenVMS VAX Version 6.2 with the Cluster Compatibility Kit to OpenVMS VAX Version 7.2

Compaq Computer Corporation
Houston, Texas

Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital Equipment Corporation or an authorized sublicensor.

© Digital Equipment Corporation 1999. All rights reserved.

Compaq, the Compaq logo, and the DIGITAL logo are registered in the U.S. Patent and Trademark Office.

Alpha, AlphaServer, AlphaStation, DEC, DIGITAL, OpenVMS, Tru64, VAX, VMS, are trademarks of Compaq Computer Corporation.

Other product names mentioned herein may be the trademarks of their respective companies.

ZK5423

The OpenVMS documentation set is available on CD-ROM.

This document was prepared using VAX DOCUMENT, Version V3.2n.

Contents

Index

Intended Audience

This book is intended for system managers and system users who want to:

• Understand how Volume Shadowing for OpenVMS works
• Configure shadowed data storage subsystems to maximize data availability
• Set up and manage shadow sets
• Enhance shadow set performance

Although you do not need any previous volume shadowing experience to use the volume shadowing software or this documentation, you do need a familiarity with the OpenVMS operating system, the OpenVMS Mount utility or OpenVMS system services, and setting system parameters.

Document Structure

The Volume Shadowing for OpenVMS manual consists of eight chapters and two appendixes:

Chapter	Contents
Chapter 1	Introduces Volume Shadowing for OpenVMS and describes how it provides high data availability.
Chapter 2	Illustrates various shadow set configurations.
Chapter 3	Describes how to set up a volume shadowing environment, including information about setting shadowing system parameters, booting a system that uses a system disk in a shadow set, and booting satellite nodes from a shadowed system disk.
Chapter 4	Describes how to use DCL commands to create, mount, dismount, and dissolve shadow sets. The chapter also describes how to use the SHOW DEVICES command, the System Dump Analyzer, and the F$GETDVI lexical function to obtain information about shadow sets on a running system.
Chapter 5	Describes how to use the OpenVMS system services in a user-written program to create and manage shadow sets. The chapter also describes how to use the $GETDVI system service to obtain information about shadow sets.
Chapter 6	Describes how the copy and merge operations maintain data consistency and availability during changes in shadow set membership.
Chapter 7	Describes how to perform system management tasks on shadow sets, including performing backup and upgrade operations, performing shadowing operations in OpenVMS Cluster systems, and handling crash dumps on the shadow set.
Chapter 8	Includes helpful information and guidelines for achieving better performance from shadow sets.
Appendix A	Provides a comparison of phase I (sometimes referred to as VAX volume shadowing) and phase II volume shadowing and explains how to migrate your phase I shadow sets to phase II. Phase I shadowing was made unavailable in OpenVMS Version 6.2.
Appendix B	Lists messages related to volume shadowing that are returned by the Mount utility and the VOLPROC, shadow server, and OPCOM facilities.

Related Documents

The following documents contain information related to this manual:

• OpenVMS License Management Utility Manual
• OpenVMS Cluster Systems
• Guidelines for OpenVMS Cluster Configurations
• OpenVMS DCL Dictionary
• OpenVMS System Manager's Manual
• OpenVMS System Management Utilities Reference Manual
• OpenVMS System Messages and Recovery Procedures Reference Manual¹
• OpenVMS System Services Reference Manual

For additional information about the Open Systems Software Group (OSSG) products and services, access the following OpenVMS World Wide Web address:

http://www.compaq.com/openvms

Reader's Comments

Compaq welcomes your comments on this manual.

Print or edit the online form SYS$HELP:OPENVMSDOC_COMMENTS.TXT and send us your comments by:

Internet	openvmsdoc@compaq.com
Fax	603 884-0120, Attention: OSSG Documentation, ZKO3-4/U08
Mail	Compaq Computer Corporation OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698

How To Order Additional Documentation

Use the following World Wide Web address to order additional documentation:

http://www.compaq.com/openvms

To reach the OpenVMS documentation website, click the Documentation link.

If you need help deciding which documentation best meets your needs, call 800-ATCOMPA.

Conventions

The following conventions are used in this manual:

Ctrl/ x	A sequence such as Ctrl/ x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button.
PF1 x	A sequence such as PF1 x indicates that you must first press and release the key labeled PF1 and then press and release another key or a pointing device button.
[Return]	In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.) In the HTML version of this document, this convention appears as brackets, rather than a box.
...	A horizontal ellipsis in examples indicates one of the following possibilities: Additional optional arguments in a statement have been omitted. The preceding item or items can be repeated one or more times. Additional parameters, values, or other information can be entered.
. . .	A vertical ellipsis indicates the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed.
( )	In command format descriptions, parentheses indicate that you must enclose the options in parentheses if you choose more than one.
[ ]	In command format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification or in the syntax of a substring specification in an assignment statement.)
[|]	In command format descriptions, vertical bars separating items inside brackets indicate that you choose one, none, or more than one of the options.
{ }	In command format descriptions, braces indicate required elements; you must choose one of the options listed.
bold text	This text style represents the introduction of a new term or the name of an argument, an attribute, or a reason.
italic text	Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER= name), and in command parameters in text (where dd represents the predefined code for the device type).
UPPERCASE TEXT	Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege.
Monospace text	Monospace type indicates code examples and interactive screen displays. In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example.
-	A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line.
numbers	All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes---binary, octal, or hexadecimal---are explicitly indicated.

This chapter introduces Volume Shadowing for OpenVMS and describes how volume shadowing, sometimes referred to as disk mirroring, achieves high data availability.

1.1 Overview

Volume Shadowing for OpenVMS ensures that data is available to your applications and end users by duplicating data on multiple disks. Because the same data is recorded on multiple disk volumes, if one disk fails, the remaining disk or disks can continue to service I/O requests.

An implementation of RAID 1 (redundant arrays of independent disks) technology, Volume Shadowing for OpenVMS prevents a disk device failure from interrupting system and application operations. By duplicating data on multiple disks, volume shadowing transparently prevents your storage subsystems from becoming a single point of failure because of media deterioration or communication path failure, or through controller or device failure.

You can mount one, two, or three compatible disk volumes, including the system disk, to form a shadow set. Each disk in the shadow set is a shadow set member. Volume Shadowing for OpenVMS logically binds the shadow set devices together and represents them as a single virtual device called a virtual unit. This means that the multiple members of the shadow set, represented by the virtual unit, appear to applications and users as a single, highly available disk.

Applications and users read and write data to and from a shadow set using the same commands and program language syntax and semantics that are used for nonshadowed I/O operations. System managers manage and monitor shadow sets using the same commands and utilities they use for nonshadowed disks. The only difference is that access is through the virtual unit, not to individual devices.

Figure 1-1 shows how Volume Shadowing for OpenVMS propagates data through the virtual unit to three individual shadow set members.

Figure 1-1 Elements of a Shadow Set

An additional benefit of volume shadowing is its potential role in repairing data. For example, if data on a shadow set member becomes unreadable, the shadowing software can read the data from another member. Not only is good data returned to the process that requested the data, but the data is also written to a replacement logical block number (LBN) on the failing volume.

Volume Shadowing for OpenVMS is sometimes referred to as phase II shadowing or host-based shadowing. Migration information to phase II shadowing from VAX Volume Shadowing, sometimes referred to as phase I or controller-based shadowing, is discussed in Appendix A. Phase I shadowing is no longer available as of OpenVMS Version 6.2.

1.2 Hardware Environment

Volume Shadowing for OpenVMS does not depend on specific hardware in order to operate. All shadowing functions can be performed on Alpha and VAX computers using the OpenVMS operating system. Volume shadowing requires a minimum of one CPU, one mass storage controller, and Digital Storage Architecture (DSA) or Small Computer Systems Interface (SCSI) disk drives.

The following sections generically describe hardware support. See the most recent Volume Shadowing for OpenVMS Software Product Description 27.29.xx for more information.

1.2.1 Supported Devices

The following list describes compatibility requirements for the physical units (disk drives) that form a shadow set.

• Units must be the same type of disk and must have the same physical geometry. Compatible disks must have the same number of physical blocks. For example, an RF73 disk can shadow another RF73, but cannot shadow an RA72.
• Units must be Files-11 On-Disk Structure Level 2 (ODS-2) or On-Disk Structure Level 5 (ODS-5) data disks. The Files-11 structure prepares a volume to receive and store data so that the operating system can locate it easily. Volume shadowing accepts I/O requests from users and applications through the Files-11 interface and shadows data to the individual shadow set members.
• Units and controllers must conform to the MSCP (mass storage control protocol) specifications or must be SCSI compliant (See Section 1.2.2).
  These units and controllers include:
  • Some third-party SCSI devices that implement READL (read long) and WRITEL (write long) commands using the OpenVMS SCSI disk driver (DKDRIVER)
• Units cannot have hardware write-protection enabled. Hardware write protection stops volume shadowing software from maintaining identical volumes.

SCSI devices that do not use the OpenVMS SCSI disk driver (DKDRIVER). SCSI disks that do not implement READL and WRITEL have limited support because these disks do not provide for shadowing data repair (disk bad block errors) features. As a result, using unsupported SCSI disks can cause members to be removed from the shadow set, if certain error conditions arise that cannot be corrected. See Section 4.8.4 for information about how to determine if a SCSI device supports READL and WRITEL commands.

1.3 Supported Configurations

Volume Shadowing for OpenVMS provides data availability across the full range of configurations---from single nodes to large OpenVMS Cluster systems---so you can provide data availability where you need it most.

There are no restrictions on the location of shadow set members beyond the valid disk configurations defined in the SPDs for the OpenVMS operating system and for OpenVMS Cluster systems:

• For the OpenVMS Operating System: SPD 25.01.xx
• For OpenVMS Cluster Software: SPD 29.78.xx

You can shadow data disks and system disks. Thus, a system disk need not be a single point of failure for any system that boots from that disk. System disk shadowing becomes especially important for OpenVMS Cluster systems that use a common system disk from which multiple computers boot.

You can mount a maximum of 500 disks in two- or three-member shadow sets on a standalone system or in an OpenVMS Cluster. A limit of 10,000 single member shadow sets is allowed on a standalone system or on an OpenVMS Cluster system. These limits are independent of controller and device type. The shadow sets can be mounted as public or private volumes. Shadow sets also can be constituents of a bound volume set or a stripe set. Section 1.4 describes more about shadowing across OpenVMS Cluster systems. Chapter 8 contains more information about striping and how RAID (redundant arrays of independent disks) technology relates to volume shadowing.

1.4 Shadowing Disks Across an OpenVMS Cluster System

The host-based implementation of volume shadowing allows disks that are connected to multiple physical controllers to be shadowed in an OpenVMS Cluster system. There is no requirement that all members of a shadow set be connected to the same controller. Controller independence allows you to manage shadow sets regardless of their controller connection or their location in the OpenVMS Cluster system and helps provide improved data availability and flexible configurations.¹

For clusterwide shadowing, members can be located anywhere in an OpenVMS Cluster system and served by MSCP servers across any supported OpenVMS Cluster interconnect, including the CI (computer interconnect), Ethernet, Digital Storage Systems Interconnect (DSSI), and Fiber Distributed Data Interface (FDDI). For example, OpenVMS Cluster systems using FDDI can be up to 25 miles apart, which further increases the availability and disaster tolerance of a system.

Figure 1-2 shows how shadow-set member units are on line to local controllers located on different nodes. In the figure, a disk volume is local to each of the nodes ATABOY and ATAGRL. The MSCP server provides access to the shadow set members over the Ethernet. Even though the disk volumes are local to different nodes, the disks are members of the same shadow set. A member unit that is local to one node can be accessed by the remote node via the MSCP server.

Figure 1-2 Shadow Sets Accessed Through the MSCP Server

The shadowing software maintains virtual units in a distributed fashion on each node that mounts the shadow set in the OpenVMS Cluster system. In an OpenVMS Cluster environment, each node creates and maintains virtual units independently. The shadowing software on each node maps each virtual unit to its respective physical units. Virtual units are not served to other nodes. When a shadow set must be accessed by multiple nodes, each node creates an identical virtual unit. The shadowing software maintains clusterwide membership coherence for shadow sets mounted on multiple nodes.

For shadow sets that are mounted on an OpenVMS Cluster system, mounting or dismounting a shadow set on one node in the cluster does not affect applications or user functions executing on other nodes in the system. For example, you can dismount the virtual unit from one node in an OpenVMS Cluster system and leave the shadow set operational on the remaining nodes on which it is mounted.

Other notes:

• If an individual disk volume is already mounted as a member of an active shadow set, the disk volume cannot be mounted as a standalone disk on another node.
• System disks can be shadowed. All nodes booting from shadowed system disks must have shadowing licensed and enabled.
• Volume Shadowing for OpenVMS does not support the shadowing of quorum disks. This is because volume shadowing makes use of the OpenVMS distributed lock manager, and the quorum disk must be accessed before locking is enabled.

	privacy and legal statement
5423PRO.HTML