HP Volume Shadowing for OpenVMS |
Ensuring Shadow Set Consistency |
|
|
| |
| All members might contain the new data. |
| All members might contain the old data. |
| Some members might contain new data and others might contain old data. |
The merge operation is managed by one of the OpenVMS systems that has the shadow set mounted. The members of a shadow set are physically compared to each other to ensure that they contain the same data. This is done by performing a block-by-block comparison of the entire volume. As the merge proceeds, any blocks that are different are made the same -- either both old or new --- by means of a copy operation. Because the shadowing software does not know which member contains newer data, any full member can be the source member of the merge operation.
A full merge operation can be a very lengthy procedure. During the operation, application I/O continues but at a slower rate.
A minimerge operation can be significantly faster. By using information about write operations that were logged in volatile controller storage, the minimerge is able to merge only those areas of the shadow set where write activity was known to have occurred. This avoids the need for the entire volume scan that is required by full merge operations, thus reducing consumption of system I/O resources.
The shadowing software always selects one member as a logical master for any merge operation, across the OpenVMS Cluster. Any difference in data is resolved by a propagation of the information from the merge master to all the other members.
The system responsible for doing the merge operation on a given shadow set, updates the merge fence for this shadow set after a range of LBNs is reconciled. This fence "proceeds" across the disk and separates the merged and unmerged portions of the shadow set.
Application read I/O requests to the merged side of the fence can be satisfied by any source member of the shadow set. Application read I/O requests to the unmerged side of the fence are also satisfied by any source member of the shadow set; however, any potential data differences---discovered by doing a data compare operation---are corrected on all members of the shadow set before returning the data to the user or application that requested it.
This method of dynamic correction of data inconsistencies during read requests allows a shadow set member to fail at any point during the merge operation without impacting data availability.
Volume Shadowing for OpenVMS supports both assisted and unassisted merge operations in the same cluster. Whenever you create a shadow set, add members to an existing shadow set, or boot a system, the shadowing software reevaluates each device in the changed configuration to determine whether it is capable of supporting the merge assist.
Unassisted Merge Operations ![]()
For systems running
software earlier than OpenVMS Version 5.5-2, the merge
operation is performed by the system and is known as an unassisted merge
operation.
To ensure minimal impact on user I/O requests, volume shadowing implements a mechanism that causes the merge operation to give priority to user and application I/O requests.
The shadow server process performs merge operations as a background process, ensuring that when failures occur, they minimally impact user I/O. A side effect of this is that unassisted merge operations can often take an extended period of time to complete, depending on 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 the beginning.
Note that data availability and integrity are fully preserved during merge operations regardless of their duration. All shadow set members contain equally valid data.
Assisted Merge Operations ![]()
Starting with OpenVMS
Version 5.5-2, the merge operation includes enhancements
for shadow set members that are configured on controllers that implement assisted merge
capabilities. The assisted merge operation is also referred to as
a minimerge. The minimerge feature significantly
reduces the amount of time needed to perform merge operations. Usually,
the minimerge completes in a few minutes. HSC and HSJ controllers support
minimerge.
By using information about write operations that were logged in controller memory, the minimerge is able to merge only those areas of the shadow set where write activity was known to have been in progress. This avoids the need for the total read and compare scans required by unassisted merge operations, thus reducing consumption of system I/O resources.
Controller-based write logs contain information about exactly which LBNs in the shadow set had write I/O requests outstanding (from a failed node). The node that performs the assisted merge operation uses the write logs to merge those LBNs that may be inconsistent across the shadow set. No controller-based write logs are maintained for a one member shadow set. No controller-based write logs are maintained if only one OpenVMS system has the shadow set mounted.
| The shadowing software does not automatically enable
a minimerge on a system disk because of the requirement to consolidate
crash dump files on a nonsystem disk. Dump off system disk (DOSD) is supported on both OpenVMS VAX and OpenVMS Alpha, starting with OpenVMS VAX Version 6.2 and OpenVMS Alpha Version 7.1. If DOSD is enabled, the system disk can be minimerged. |
Volume Shadowing for OpenVMS automatically disables minimerges if:
The following transient conditions can also cause a minimerge operation to be disabled:
| Controller failure causes write logs to be lost or deleted. |
| A device that is dual ported to multiple controllers fails over to its secondary controller. (If the secondary controller is capable of maintaining write logs, the minimerge operations are reestablished quickly.) |
|
|