Hardware Environment

24 KB per node is required on OpenVMS Integrity server systems and OpenVMS Alpha systems. These requirements are in effect even if you do not use Volume Shadowing for OpenVMS, unless you change the default setting.

If this memory is not available, the node does not boot.

4.5 KB per shadow set per node is required.

This amount of memory is required before a 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 issues the following message:

%MOUNT-F-INSFMEM, insufficient dynamic memory

For every GB of storage of a shadow set member, 2.0 KB per node is required for the bitmaps for each shadow set mounted on a node.

(Each shadow set can have up to six bitmaps. And, with HBMM support, a shadow set can have a maximum of 12 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, 400 KB of memory is required for its bitmaps for every node in the cluster. If this memory is not available on the node where the bitmap request occurs, the bitmap is not created.

If the master bitmap is created but sufficient memory is not available on another node on which the shadow set is subsequently mounted, a local 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 is first mounted.

0024 KB per node (regardless of whether you use volume shadowing)

0045 KB (10 shadow sets x 4.5 KB per unit mounted on the system)

1000 KB (50 x 2.0 KB (per GB of disk size) x 10 shadow sets)

1069 KB total memory required

Starting with OpenVMS Alpha Version 7.3–2, different size devices can be used to form a shadow set. This functionality is called dissimilar device shadowing (DDS). To use DDS, all systems that have mounted a shadow set whose members differ in size must be running OpenVMS Integrity serversVersion 8.2 or later or OpenVMS Alpha Version 7.3–2 or later.

Prior to OpenVMS Alpha Version 7.3–2, Volume Shadowing for OpenVMS required that all members of a shadow set be the same size, that is, that each member have the exact same number of blocks. The rapid advance of disk technology has made this requirement impractical. The flexibility of using different size devices outweighs the space that is unused on the larger device.

Operationally, shadowing dissimilar devices means that you can add a larger disk device to an existing shadow set. The shadow set retains the file system size of the original shadow set. After adding a larger disk, if you remove a smaller disk, the geometry (cylinders, tracks, and sections) of the shadow set changes to the smallest remaining disk, but the logical volume size (that is, the file system size) is not changed.

All members of the shadow set must have a MAXBLOCK size equal to or greater than the logical volume size stored in the storage control block SCB$L_VOLSIZE of the shadow set. All mounted members have this value. When the smaller volume is no longer needed, or if you have to increase the file system size of the shadow set, you can use the dynamic volume expansion (DVE) feature introduced in OpenVMS Alpha Version 7.3–2. Together, the features of DDS and DVE enable you to continually grow a logical volume without ever having to take it offline again. For more information about DVE, see “Dynamic Volume Expansion (Integrity servers and Alpha)”.

	NOTE: In volume expansion, you must disable and re-enable HBMM so that write bitmaps are recreated that encompasses the new volume size. Failing to do this might result in longer than expected merge times as the expansion area is subjected to a complete merge.

You can determine the block size for each disk with the SHOW DEVICE /FULL command. The block size is displayed as Total blocksn.

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:

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 “Using SDA to Obtain Information About Third-Party SCSI Devices” for how to determine whether a SCSI disk supports READL and WRITEL commands.

Smart Array 5300 (KZPDC) and XP storage array devices can be shadow set members, provided that all members in the shadow set are fault-tolerant devices. A fault-tolerant device on the KZPDC controller is one that can repair data errors when the media yields errors on one of the underlying LUNs (devices identified by their logical unit numbers (LUNs)). The XP storage array family of controllers require that all LUNs that are presented be formed of fault-tolerant devices.

Volume Shadowing for OpenVMS can be used with the KZPDC controller subject to the restriction that all shadow set members are formed using devices composed of fault-tolerant devices, such as the following:

For all previous OpenVMS versions, all devices must report the same number of total blocks for Volume Shadowing for OpenVMS to create a multiple-member shadow set. The configuration utility sets the total number of blocks on a KZPDC or MSA1000 device to the closest match that it can make to the requested size. Because the KZPDC and the MSA1000 device use the same calculation, a device created on both with the same requested size is set to the same size. This allows Volume Shadowing to create multiple-member shadow sets.

	CAUTION: There are instances where it is not possible to use Volume Shadowing to create a multiple-member shadow set if a fault-tolerant device is not used. For example, a single member shadow set is formed using a device (physical disk or non-fault-tolerant device). If the device develops non-recoverable data errors, it is not possible to use Volume Shadowing successfully to add another member to this shadow set. When the second member is added to the shadow set, Volume Shadowing reads the source device and copies it to the target device. When the data error is read from the source shadow set member, Volume Shadowing forces all the current shadow set members (the source member and the copy target) to create a ‘‘bad spot’’. If the request to create a bad spot fails on either shadow set member, the shadow set is reduced to one member.