Document revision date: 15 July 2002

Order Number: AA--PVXMH--TE

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

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

Software Version: OpenVMS Alpha Version 7.3--1 OpenVMS VAX Version 7.3

Compaq Computer Corporation
Houston, Texas

© 2002 Compaq Information Technologies Group, L.P.

Compaq, the Compaq logo, OpenVMS, Tru64, VAX, VMS, and the DIGITAL logo are trademarks of Compaq Information Technologies Group, L.P. in the U.S. and/or other countries.

All other product names mentioned herein may be trademarks of their respective companies.

Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license.

Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

ZK5423

The Compaq OpenVMS documentation set is available on CD-ROM.

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 the following chapters and appendix:

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 the minicopy operation can be used, in a carefully controlled environment, to shorten the time required for a member to be returned to a shadow set. Typically, the member is removed for backing up data.
Chapter 8	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 9	Includes helpful information and guidelines for achieving better performance from shadow sets.
Appendix A	Lists messages related to volume shadowing that are returned by the Mount utility and the VOLPROC, shadow server, and OPCOM facilities.
Glossary	Lists the terms used in this manual with definitions.

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 Alpha System Analysis Tools Manual
• OpenVMS System Services Reference Manual

For additional information about OpenVMS products and services, access the Compaq website at the following location:

http://www.openvms.compaq.com/

Reader's Comments

Compaq welcomes your comments on this manual. Please send comments to either of the following addresses:

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

How To Order Additional Documentation

Visit the following World Wide Web address for information about how to order additional documentation:

http://www.openvms.compaq.com/

Conventions

The following conventions are used in this manual:

[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 or more options, or no options. (Note, however, that brackets are not optional 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 separate choices within brackets or braces. Within brackets, the choices are optional; within braces, at least one choice is required. Do not type the vertical bars on the command line.
{ }	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.

Any entity that is designated as a disk class device to OpenVMS is a device that can be used in a shadow set. You can mount one, two, or three compatible disk volumes, including the system disk, to form a shadow set. Compatible disk volumes are those with the same number of physical blocks (see Section 1.3.2). Each disk in the shadow set is a shadow set member. Volume Shadowing for OpenVMS logically binds the shadow set disks 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.

Note that the term disk and device are used interchangeably throughout this manual to refer to a disk volume. A disk volume is a disk that was prepared for use by placing a new file structure on it.

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

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. Before the good data is returned to the process, it is written to the member that could not originally read it.

Prior to OpenVMS Version 6.2, two forms of volume shadowing were supported: host-based, also known as Phase II shadowing, and controller-based, also known as Phase I shadowing. Starting with OpenVMS Version 6.2, controller-based shadowing was discontinued --- Volume Shadowing on OpenVMS is host based only. Consequently, the term Phase II is no longer used in this manual.

1.2 Volume Shadowing Tasks and Operations

The primary volume shadowing operations used to create shadow sets and to maintain consistent data on each member are mount, copy, assisted copy, minicopy (introduced with OpenVMS Version 7.3), merge, and minimerge. When these operations are in progress, the system continues to process read and write requests, thus providing continuous availability.

All volume shadowing operations, except for merges and minimerges, are under the control of the system manager. Merges and minimerges are started automatically by the volume shadowing software if a hardware or software failure occurs that could affect the consistency of the data on the shadow set members.

System managers turn on volume shadowing with the SHADOWING system parameter. They can control the number of concurrent merge or copy operations on a given node by the SHADOW_MAX_COPY system parameter. These volume shadowing system parameters, and all other system parameters used with volume shadowing, are described in Section 3.2 and in Section 3.3.

Volume Shadowing for OpenVMS is never invoked directly. Instead, you invoke the DCL commands MOUNT and DISMOUNT. The MOUNT command works with the volume shadowing software to create shadow sets. The DISMOUNT command works with the volume shadowing software to remove shadow set members and to dissolve entire shadow sets.

HSJ and HSC controllers, when present in a configuration, provide software assists for the minimerge and assisted copy operations.

OpenVMS also provides a programming interface for creating and managing shadow sets with the $MOUNT, $DISMOU, and $GETDVI system services. This programming interface is described in Chapter 5.

Table 1-1 shows the main volume shadowing tasks, the operations associated with them, and the software used to perform the operation. These operations are described in more detail in Chapter 4, Chapter 6, and Chapter 7.

Table 1-1 Main Volume Shadowing Tasks, Operation Name, and Related Software

Task	Operation	Software Used
Create a shadow set.	Copy	MOUNT/SHADOW command with the SHADOWING system parameter set, which starts the copy automatically. When a second or third member is added, the shadowing software starts a copy operation.
Remove a member from a shadow set.	Dismount a disk	DISMOUNT command.
Dissolve a shadow set.	Dismount the shadow set (specify its virtual unit name)	DISMOUNT command.
Ensure that the data is identical on all shadow set members in the event of a hardware failure.	Merge or minimerge	Shadowing software does this automatically when it detects a hardware or software failure. If an HSJ or HSC controller is present in the configuration, a minimerge might be done.
Return a dismounted shadow set member to the shadow set.	Copy, assisted copy, or minicopy	MOUNT command, with shadowing software that initiates either a copy or, if properly configured, a minicopy.

1.3 Hardware Environment

Volume Shadowing for OpenVMS does not depend on specific hardware in order to operate. All shadowing functions, with the exception of minicopy, can be performed on Alpha and VAX computers using the OpenVMS operating system. The minicopy operation can be performed only on an OpenVMS Alpha system. However, an OpenVMS VAX system can be a member of an OpenVMS Cluster system that uses this feature.

Volume shadowing requires a minimum of:

• One CPU
• One mass storage controller
• One of the following kinds of disk drives:
  • Digital Storage Architecture (DSA)
  • Small Computer Systems Interface (SCSI)
  • Fibre Channel

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.3.1 Memory Requirements

Starting with OpenVMS Version 7.3, the following additional memory is required to run Volume Shadowing for OpenVMS:

• 24 KB per node are required on OpenVMS Alpha systems; 5 KB per node are required on OpenVMS VAX systems. These requirements are in effect even if you do not use Volume Shadowing for OpenVMS.
  If this memory is not available, the node will not boot.
• 4.5 KB per shadow set per node is required.
  This amount of memory is required before a write bitmap can be created. If this memory is not available, the mount fails (that is, the shadow set is not mounted on the node). The MOUNT command that fails will issue the following message:

  %MOUNT-F-INSFMEM, insufficient dynamic memory

• For every gigabyte of storage of a shadow set member, 2.1 KB per node is required for the write bitmaps for each shadow set mounted on a node. (Each shadow set can have up to six write bitmaps.) When calculating memory requirements, note that a two-member shadow set with 50 GB per member counts as 50 GB, not 100 GB.
  For example, for a shadow set with 200 GB of storage per member, 420 KB of memory is required for its write bitmaps for every node in the cluster. If this memory is not available on the node where the write bitmap request occurs, the write bitmap is not created.
  If the master write bitmap is created but sufficient memory is not available on another node on which the shadow set is subsequently mounted, a local write bitmap is not created. If the WBM_OPCOM_LVL system parameter is set to 1 (the default) or 2, the following OPCOM message is displayed:

  Unable to allocate local bitmap - running in degraded mode.

  
  Writes from nodes without local bitmaps are registered with the node on which the shadow set was first mounted.

These memory requirements are cumulative. For example, a system with 10 shadow sets mounted, with each shadow set consisting of 50-GB member disks, would require an additional 1,119 KB of memory. The calculation follows:

24 KB per node (regardless of whether you use volume shadowing)
45 KB (10 shadow sets x 4.5 KB per unit mounted on the system)
1050 KB (50 x 2.1 KB (per GB of disk size) x 10 shadow sets
1119 KB total memory required

The compatibility requirements for the physical disks that form a shadow set follow:

• Each disk must have the same number of physical blocks. You can determine the block size for each disk with the SHOW DEVICE /FULL command. The block size is displayed as Total blocks nnnnnnnn .

  Note Starting with OpenVMS Version 7.2 (and available for OpenVMS Version 7.1-2 in a remedial kit), disks of different types and different geometries are supported in the same shadow set provided they have the same number of physical blocks.

• Disks 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.
• Disks and controllers must be one of the following types:
  • StorageWorks Fibre Channel
  • StorageWorks SCSI
  • MSCP (mass storage control protocol) conformant
• Disk volumes cannot have hardware write protection enabled. Hardware write protection stops volume shadowing software from maintaining identical volumes.
• 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. Such disks can cause members to be removed from the shadow set, if certain error conditions arise that cannot be corrected. See Section 4.9.4.1 for how to determine if a SCSI disk supports READL and WRITEL commands.

	privacy and legal statement
5423PRO.HTML