HP Volume Shadowing for OpenVMS

Ensuring Shadow Set Consistency

Copy Operations

Controlling HSC Assisted Copy and Minimerge Operations

Merge Operations   

• A system failure results in the possibilityof incomplete writes.
  
  For example, if a write request is made to a shadow set butthe system fails before a completion status is returned from allthe shadow set members, it is possible that:

  All members might contain the newdata.

  All members might contain the old data.

  Some members might contain new data and others mightcontain old data.

  The exact timing of the failure during the original writerequest defines which of these three scenarios results. When thesystem recovers, Volume Shadowing for OpenVMS ensures that correspondingLBNs on each shadow set member contain the same data(old or new). It is the responsibility of the application to determineif the data is consistent from its point of view. The volume mightcontain the data from the last write request or it might not, dependingon when the failure occurred. The application should be designedto function properly in both cases.



• If a shadow set enters mount verification with outstandingwrite I/O in the driver's internal queue, and the problemis not corrected before mount verification times out, the systemson which the timeout occurred require otehr systems that have theshadow set mounted to put the shadow set into a merge transientstate.
  
  For example, if the shadow set were mounted on eight systemsand mount verification timed out on two of them, those two systemswould each check their internal queue for write I/O. If one werefound, the shadow set would enter a merge transient state. cause

The merge operation is managed by one of the OpenVMS systemsthat has the shadow set mounted. The members of a shadow set arephysically compared to each other to ensure that they contain thesame data. This is done by performing a block-by-block comparisonof the entire volume. As the merge proceeds, any blocks that aredifferent are made the same -- either both old or new ---by means of a copy operation. Because the shadowing software doesnot know which member contains newer data, any full member can be the source memberof the merge operation.

A full merge operation can be a very lengthy procedure. Duringthe operation, application I/O continues but at a slower rate.

A minimerge operation can be significantly faster. By usinginformation about write operations that were logged in volatilecontroller storage, the minimerge is able to merge only those areasof the shadow set where write activity was known to have occurred.This avoids the need for the entire volume scan that is requiredby full merge operations, thus reducing consumption of system I/Oresources.

The shadowing software always selects one member as a logicalmaster for any merge operation, across the OpenVMS Cluster.Any difference in data is resolved by a propagation of the informationfrom the merge master to all the other members.

The system responsible for doing the merge operation on agiven shadow set, updates the merge fence for thisshadow set after a range of LBNs is reconciled. This fence "proceeds" acrossthe disk and separates the merged and unmerged portions of the shadowset.

Application read I/O requests to the merged side of the fencecan be satisfied by any source member of the shadow set. Applicationread I/O requests to the unmerged side of the fence are also satisfiedby any source member of the shadow set; however, any potential datadifferences---discovered by doing a data compare operation---arecorrected on all members of the shadow set before returningthe data to the user or application that requested it.

This method of dynamic correction of data inconsistenciesduring read requests allows a shadow set member to fail at any pointduring the merge operation without impacting data availability.

Volume Shadowing for OpenVMS supports both assisted and unassistedmerge operations in the same cluster. Whenever you create a shadowset, add members to an existing shadow set, or boot a system, the shadowingsoftware reevaluates each device in the changed configuration todetermine whether it is capable of supporting the merge assist.

Unassisted Merge Operations   

For systems runningsoftware earlier than OpenVMS Version 5.5-2, the mergeoperation is performed by the system and is known as an unassisted mergeoperation.

To ensure minimal impact on user I/O requests, volume shadowingimplements a mechanism that causes the merge operation to give priorityto user and application I/O requests.

The shadow server process performs merge operations as a backgroundprocess, ensuring that when failures occur, they minimally impactuser I/O. A side effect of this is that unassisted merge operationscan often take an extended period of time to complete, dependingon user I/O rates. Also, if another node fails before a merge completes,the current merge is abandoned and a new one is initiated from thebeginning.

Note that data availability and integrity are fully preservedduring merge operations regardless of their duration. All shadowset members contain equally valid data.

Assisted Merge Operations   

Starting with OpenVMSVersion 5.5-2, the merge operation includes enhancementsfor shadow set members that are configured on controllers that implement assisted mergecapabilities. The assisted merge operation is also referred to asa minimerge. The minimerge feature significantlyreduces the amount of time needed to perform merge operations. Usually,the minimerge completes in a few minutes. HSC and HSJ controllers supportminimerge.

By using information about write operations that were loggedin controller memory, the minimerge is able to merge only thoseareas of the shadow set where write activity was known to have beenin progress. This avoids the need for the total read and comparescans required by unassisted merge operations, thus reducing consumptionof system I/O resources.

Controller-based write logs contain information about exactlywhich LBNs in the shadow set had write I/O requests outstanding(from a failed node). The node that performs the assisted mergeoperation uses the write logs to merge those LBNs that may be inconsistentacross the shadow set. No controller-based write logs are maintainedfor a one member shadow set. No controller-based write logs aremaintained if only one OpenVMS system has the shadow set mounted.

The shadowing software does not automatically enablea minimerge on a system disk because of the requirement to consolidatecrash dump files on a nonsystem disk. Dump off system disk (DOSD) is supported on both OpenVMS VAXand OpenVMS Alpha, starting with OpenVMS VAX Version 6.2 and OpenVMSAlpha Version 7.1. If DOSD is enabled, the system disk can be minimerged.

Volume Shadowing forOpenVMS automatically disables minimerges if:

• The shadow set is mounted on a clusternode that is running an OpenVMS release earlier than Version 5.5-2.



• A shadow set member is mounted on a controller runninga version of firmware that does not support minimerge.



• A shadow set member is mounted on a controller thathas performance assists disabled.



• If any node in the cluster, with a shadow set mounted,is running a version of Volume Shadowing that has minimerge disabled.



• The shadow set is mounted on a standalone system.(Minimerge operations are not enabled on standalone systems.)



• The shadow set is mounted on only one node in theOpenVMS Cluster.

The following transient conditions can also cause a minimergeoperation to be disabled:

• If an unassisted merge operation isalready in progress when a node fails.
  
  In this situation, the shadowing software cannot interruptthe unassisted merge operation with a minimerge.



• When not enough write log entries are availablein the controllers.
  
  The number of write log entries available is determined bycontroller capacity. The shadowing software dynamically determineswhen there are enough entries to maintain write I/O informationsuccessfully. If the number of available write log entries is toolow, shadowing temporarily disables logging for that shadow set,and it returns existing available entries on this and every nodein the cluster. After some time has passed, shadowing will attemptto reenable write logging on this shadow set.
  
  A controller retains a write log entry for each write I/Orequest until that entry is deleted by shadowing, or the controlleris restarted.
  
  A multiple-unit controller shares its write log entries amongmultiple disks. This pool of write log entries is managed by theshadowing software. If a controller runs out of write log entries,shadowing disables minimerges and will perform an unassisted mergeoperation, should a node leave the cluster without first dismountingthe shadow set. Note that write log exhaustion does not typicallyoccur with disks on which the write logs are not shared.



• When the controller write logs become inaccessiblefor one of the following reasons, a minimerge operation is not possible.

  Controller failure causes write logsto be lost or deleted.

  A device that is dual ported to multiple controllersfails over to its secondary controller. (If the secondary controlleris capable of maintaining write logs, the minimerge operations arereestablished quickly.)

Copy Operations

Controlling HSC Assisted Copy and Minimerge Operations