[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here Overview
HP Volume Shadowing for OpenVMS: OpenVMS Version 8.4 > Chapter 1 Introduction to HP Volume Shadowing for OpenVMS

Overview

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

HP Volume Shadowing for OpenVMS is available on HP OpenVMS Integrity servers, OpenVMS Alpha, and on OpenVMS VAX.

NOTE: This manual covers volume shadowing on OpenVMS Integrity servers and OpenVMS Alpha. For information on volume shadowing on OpenVMS VAX, see the OpenVMS Version 7.3-1 HP Volume Shadowing for OpenVMS manual.

All volume shadowing features that are available on OpenVMS Integrity servers are also available on OpenVMS Alpha.

An implementation of RAID 1 (redundant arrays of independent disks) technology, HP 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 identical-size disk volumes, including the system disk, to form a shadow set.

Starting with OpenVMS Alpha Version 7.3–2, disk volumes can differ in the number of physical blocks (see “Supported Devices ”). Starting from OpenVMS Version 8.4, you can mount a maximum of six disk volumes. 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, as shown in Figure 1-1. 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 prepared for use by placing a new file structure on it.

Figure 1-1 Virtual Unit

Virtual Unit

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

Figure 1-2 Elements of a Shadow Set

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.

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 is discontinued --- Volume Shadowing for OpenVMS is host based only. Consequently, the term Phase II is no longer used in this manual.

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 non-shadowed I/O operations. System managers manage and monitor shadow sets using the same commands and utilities they use for non-shadowed disks. The only difference is that access is through the virtual unit, not to individual disk.