Electrical computers and digital processing systems: memory – Storage accessing and control – Control technique
Reexamination Certificate
1997-06-24
2003-06-10
Kim, Matthew (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Control technique
C711S114000, C714S006130
Reexamination Certificate
active
06578120
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to loosely-coupled copy operations between a primary and a remote secondary direct access storage device (DASD) through paths managed by a host CPU. More particularly, the invention relates to maintaining consistency between the primary and remote DASD volumes even when the CPU is updating the primary volume at the same time. This is critical where such updating occurs during initial primary-to-secondary volume synchronization and during resynchronization of the volumes after the occurrence of an I/O error or other outage.
DESCRIPTION OF RELATED ART
The following paragraphs summarize the prior art. First, it is well known that a CPU randomly and sequentially updates tracks of one or more DASDs in an attached cache-based, staged storage subsystem. It is further known that remote electronic copying of DASD volumes is a frequently-used strategy toward maintenance of full-time information handling system availability in the presence of fault or failure of system components. Among the several copy operations, duplexing is favored over point-in-time copying because of the very low latency when the backup is substituted for the primary volume.
The prior art further teaches that remote volume-to-volume duplexing can be made transparent to applications on the CPU and with no CPU overhead. This can be accomplished synchronously by control unit-to-control unit volume copying. However, no new CPU access of the primary volume can be made until the current update is copied to the second site. In contrast, where the remote copying is performed asynchronously by CPU controlled paths, then the CPU access rate of the primary volume is independent of the backup copying. This is at the price of CPU copy management overhead. Lastly, it is known to use bit maps and volume addresses to place updates to primary volume tracks in a copy serial order for recording on a backup volume in a remote copy context, notwithstanding that such suffer from significant throwaway recording and overhead.
CPU Accessing Staged Storage
When an application runs on a multiprocessing CPU, such as an IBM S/390 with an MVS operating system, it will generate read or write calls for data to the operating system (OS). If the data is not present in CPU main memory, the OS will invoke an access method and establish a path to the data. The path will lead to data stored or to be written on one or more DASDs in an attached storage subsystem. The storage subsystem may be of the demand/responsive, hierarchically organized storage type. Illustratively, the IBM 3990 Model 6 storage control unit (SCU) is of that type. It includes a large multimegabyte cache, a nonvolatile store (NVS), and several redundant pathways to each of a plurality of 3390 DASDs or their equivalents.
If the application running on the S/390 has generated a read request, then the data would likely be stored in the SCU cache and transferred to main memory. Alternatively, if not in SCU cache, the read data would be staged to cache from one or more DASDs. It would then be copied to CPU main memory. In the case of an application-generated write, the changed or updated data would be moved from the host CPU main memory to the SCU cache. It would then be copied over to the NVS. This would permit the SCU to signal completion of the write operation and release the path coupling the SCU to the CPU. At a time subsequent, the data can be written out to the DASDs from NVS.
Remote Electronic Copying
Shomler et al., U.S. Pat. No. 5,446,871, “Method and Arrangement for Multi-System Remote Data Duplexing and Recovery”, issued Aug. 29, 1995, emphasized that data copying as a storage function was the principle form of data preservation. According to Shomler, data copying was originally little more than an archive function. That is, trucks moved copies of magnetic tape recorded business transactions to remote mountain caves on a weekly or monthly basis such that businesses might restart in a post-nuclear holocaust era. However, today it is a necessity to maintain constant availability of data and systems. Thus, equipment and data are duplexed both locally and remotely. In this latter regard, Shomler proposed a method of remote electronic copying of locally stored DASD data using a token and unique sequence number responsive to each write operation at a primary site. His method relied upon the number and a list of items already sent to establish a sequence order, and thereby define gaps from which missing updates could be ascertained in the event of error, fault, or outage.
Even Shomler pointed out there was no single flavor of the copy function that would accommodate the relevant system and storage management factors. He listed several factors that should be considered in copy method design and use. These include: (1) protection domain (system and/or environmental failure or device and/or media failure), (2) data loss (no loss/partial loss), (3) time where copying occurs as related to the occurrence of other data and processes (point in time/real time), (4) the degree of disruption to applications executing on said computer, and (5) whether the copy is application or storage subsystem based.
Echoing Shomler's recognition for the need of several copy functions, large systems offer a suite of copy functions as an optional part of the resident operating system. One such suite is offered as part of the IBM MVS/DFSMS package. This package includes volume-to-volume copy operations under the control of the SCU, such as Dual Copy or Peer-to-Peer Remote Copy (PPRC). It also includes single or multivolume copying under host S/390 level control such as Concurrent Copying or Extended Remote Copy (XRC). Dual Copy is a local or same site volume duplexing feature usually under a RAID 1 rubric.
Synchronous Remote Copying and Concurrent Updating
Duplexing means rendering a second volume to be the mirror image of a primary volume. Remote data copying (duplexing) may be either synchronous or asynchronous. A synchronous remote copy function is termed Peer-to-Peer Remote Copy (PPRC). PPRC involves a direct path between DASD storage subsystems avoiding the host CPU. In PPRC, one or more tracks from the primary volume are copied through a first SCU. The copied tracks are then sent to a remote or secondary SCU location over a direct SCU/SCU ESCON-like channel.
Significantly, confirmation must be received by the primary site of the fact that copied tracks have been written to remote secondary NVS or DASD before terminating the path between the host CPU and the primary storage subsystem (SCU). This means that the next I/O access of the SCU cannot start until after the confirmation. This confirmation requirement substantially reduces the host/primary storage subsystem access rate. Relatedly, as die distance between the primary and secondary increases, the delay between accesses is further increased. This still further reduces the primary subsystem access rate. However, a consistent set of tracks and updates can be communicated between the SCUs with virtually no host CPU overhead and low SCU-to-SCU overhead.
In PPRC, the secondary or remote SCU must also recognize when the secondary volume is out of synchronization with the primary volume. Responsively, the primary SCU can suspend the remote copy function, mark the updates in some manner, and queue the updates for subsequent transmission to the secondary SCU. Note, new host accesses of the primary are still held up until the previous transfers (updates) have been synchronized at the secondary volume. A description of such a PPRC system with an efficient peer coupling may be found in the copending Hathorn et al. application, U.S. Ser. No. 08/782,474, now U.S. Pat. No. 5,920,695, “Method and Means for Bidirectional Peer-coupled Communication Across a Single ESCON Interface”, filed Jan. 10, 1997.
One problem is that of serializing updates to datasets which occur during the copy interval. The serialization of write updates in such a PPRC arrangement is set out in the copending Blount et al. application. U.S. Ser. No.
Crockett Robert Nelson
Micka William Frank
Shomler Robert Wesley
Stanley Warren Keith
Bataille Pierre Miche
Kim Matthew
Konrad Raynes & Victor & Mann LLP
Victor David W.
LandOfFree
Synchronization and resynchronization of loosely-coupled... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronization and resynchronization of loosely-coupled..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronization and resynchronization of loosely-coupled... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3163632