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 AXP Version 6.1 and OpenVMS
VAX Version 6.1.
Software Version:
OpenVMS Alpha Version 7.1 OpenVMS VAX Version 7.1
Digital Equipment Corporation Maynard, Massachusetts
November 1996
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 or an authorized sublicensor.
Digital conducts its business in a manner that conserves the
environment and protects the safety and health of its employees,
customers, and the community.
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:
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.
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.
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.
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.
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.
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 Manual1
OpenVMS System Services Reference Manual
For additional information on the Open Systems Software Group (OSSG)
products and services, access the Digital OpenVMS World Wide Web site.
Use the following URL:
http://www.openvms.digital.com
Note
1 This manual has been archived but is
available in PostScript and DECW$BOOK (Bookreader) formats on the
OpenVMS Documentation CD-ROM. A printed book can be ordered through
DECdirect (800-354-4825.)
Reader's Comments
Digital welcomes your comments on this manual.
Print or edit the online form SYS$HELP:OPENVMSDOC_COMMENTS.TXT and send
us your comments by:
Use the following table to order additional documentation or
information. If you need help deciding which documentation best meets
your needs, call 800-DIGITAL (800-344-4825).
Conventions
The name of the OpenVMS AXP operating system has been changed to the
OpenVMS Alpha operating system. Any references to OpenVMS AXP or AXP
are synonymous with OpenVMS Alpha or Alpha.
VMScluster systems are now referred to as OpenVMS Cluster systems.
Unless otherwise specified, references to OpenVMS Clusters or clusters
in this document are synonymous with VMSclusters.
In this manual, every use of DECwindows and DECwindows Motif refers to
DECwindows Motif for OpenVMS software.
The following conventions are also 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 or
GOLD
x
A sequence such as PF1
x or GOLD
x indicates that you must first press and release the key
labeled PF1 or GOLD and then press and release another key or a
pointing device button.
GOLD key sequences can also have a slash (/), dash (--), or
underscore (_) as a delimiter in EVE commands.
[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.)
...
Horizontal ellipsis points in examples indicate 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.
.
.
.
Vertical ellipsis points indicate 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, if you
choose more than one option, you must enclose the choices in
parentheses.
[ ]
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, braces indicate a required choice of
options; you must choose one of the options listed.
text style
This text style represents the introduction of a new term or the name
of an argument, an attribute, or a reason.
This style is also used to show user input in Bookreader versions
of the manual.
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
device-name contains up to five alphanumeric characters).
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 type
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.
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.
Note
Remember that volume shadowing protects against hardware problems that
cause a disk volume to be a single point of failure for both
applications and systems that use the disk. Volume shadowing does not
provide for recovery from software-related incidents, such as the
accidental deletion of files or errant software corrupting the contents
of a disk file. Do not use volume shadowing as a substitute for regular
backup or journaling.
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.
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.
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
sectors per track, the same number of tracks per cylinder, and the same
number of cylinders per volume. 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) 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 DSA and the MSCP (mass
storage control protocol) specifications or must be SCSI compliant (See
Section 1.2.2). These units and controllers include:
All Digital Equipment Corporation SCSI disks and controllers
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.
MicroVAX 2000 RD disks The integrated disk controller provided
in MicroVAX 2000 systems is not DSA compliant and thus is not supported
by Volume Shadowing for OpenVMS.
Older disk devices (such as MASSBUS, RK07, RL02)
RZ57 disk drives that do not have device revision level D01 and
microcode revision 6000 or higher.
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.7.4 for information about how to determine if a SCSI device
supports READL and WRITEL commands.
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 Version 7.1 Operating System: SPD 25.01.xx
For OpenVMS Cluster Version 7.1 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 130 shadow sets (up to 390 disks) in a
standalone or OpenVMS Cluster system. The number of shadow sets
supported is independent of controller and device types. 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.
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.1
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.
Note
1 You must have OpenVMS Cluster
software to run volume shadowing in a clustered system.