![Content starts here](http://welcome.hp-ww.com/img/s.gif) |
Volume Shadowing for OpenVMS
Order Number:
AA--PVXMH--TE
June 2002
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.
Preface
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.
|
Chapter 1 Introduction to Volume Shadowing for OpenVMS
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.
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.
|
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
1.3.2 Supported Devices
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.
|