Dynamic timer configuration for monitoring a long busy state in a remote mirror and copy environment

A system is disclosed that includes a host system to issue a write command, a primary storage controller to write data to a primary volume, and a secondary storage controller to mirror the data to a secondary volume. In the event the secondary storage controller is unable to mirror the data due to a busy state, a busy signal may be sent to the primary storage controller. The primary storage controller may initiate a timer in the event it receives the busy signal, and, in the event the busy state does not end before expiration of the timer, notify the host system that the primary and secondary volumes are in a suspended state. To alter the duration of the timer, the host system may be configured to dynamically alter the duration of the timer by sending a command to the primary storage controller.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to data storage devices and more particularly to systems and methods for dynamically configuring timers used to monitor long busy states in a remote mirror and copy environment.

2. Description of the Related Art

In a remote mirror and copy environment, whenever a primary (i.e., source) storage controller mirrors data to a secondary (i.e., target) controller, the primary controller monitors the state of the secondary volumes that are being used to mirror the data. The primary controller may utilize a “long busy” timer to monitor the state of the secondary volumes in a peer-to-peer remote copy (PPRC) relationship.

Conventionally, the long busy state timer in the primary storage controller has been hard coded to a certain value. Analysis of several critical field problems, however, has led to the discovery that the problems may have been prevented or mitigated if the long busy state timer had a different value than the hard coded value. Consequently, some customers may desire a long busy state timer that has a value greater than the hard coded value. This may reduce the likelihood that a suspended condition will occur when a secondary volume undergoes a lengthy error recovery process. Other customers, by contrast, may desire a long busy state timer with a reduced value so the suspended condition occurs more frequently. This may prevent application I/O from building up while a secondary storage controller undergoes a lengthy recovery process.

Currently, the only way a customer can change the value of the long busy state timer is using a peek-and-poke capability. The peek may be used to view the current value of the long busy state timer and the poke may be used to modify the value. When microcode in the primary controller detects a poke event, the microcode may replace the default value with a user-selected value. By design, the long busy state timer value may be persistent across initial microcode loads, warmstarts, and failure conditions in the storage controller.

Although a peek-and-poke process may provide a way to modify the value of the long busy state timer, it may still not be flexible enough to satisfy customer needs. Modifying the value may require user intervention and thus may be impossible to modify in real time. In addition, the peek-and-poke capability may be susceptible to errors because the timer value must normally be set in all clusters of one or more primary controllers, and the wrong variable may be poked. Poking the wrong variable may cause unpredictable behavior or even catastrophic failures in the storage system.

In view of the foregoing, what is needed is a system and method to dynamically alter the value of a long busy state timer. Ideally, the system and method could be used to modify the value in real time without requiring user intervention. Similarly, the system and method would ideally enable the timer value to be dynamically modified for different applications.

SUMMARY OF THE INVENTION

The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available systems and methods. Accordingly, the present invention has been developed to provide improved systems and methods to dynamically alter a long busy state timer in a remote mirror and copy environment.

In a first aspect of the invention, a system in accordance with the invention may include a host system to issue a write command. A primary storage controller may receive the write command and, in response, write data to a primary volume associated with the primary storage controller. A secondary storage controller may receive a copy of the data from the primary storage controller and mirror the data to a secondary volume associated with the secondary storage controller. In the event the secondary storage controller is unable to mirror the data because it is in a busy state, the secondary storage controller may send a busy signal to the primary storage controller. The primary storage controller may initiate a timer in the event it receives the busy signal. In the event the busy state does not end before expiration of the timer, the primary storage device may notify the host system that the primary and secondary volumes are in a suspended state. To alter the duration of the timer, the host system may be configured to dynamically alter the duration of the timer by sending a command to the primary storage controller.

In selected embodiments, the host system may be configured to dynamically alter the timer duration for different applications running on the host system. In other embodiments, the host system may be configured to dynamically alter the duration of the timer to correspond to other timers operated by the host system. In selected embodiments, the command is configured to modify the timer duration for at least one of a single volume pair, multiple volume pairs, and all volumes in a logical subsystem.

In another aspect of the invention, a method to dynamically alter a value of a long busy state timer in a remote mirror and copy environment may include issuing a write command and writing data to a primary volume in response to the write command. An attempt may be made to mirror the data to a secondary volume. In the event a busy condition exists that prevents mirroring the data to the secondary volume, a busy signal may be sent. A timer may be initiated in the event the busy signal is sent. The primary and secondary volumes may be suspended in the event the timer expires before the busy condition has ended. The method may further include dynamically altering the duration of the timer by issuing a command.

The present invention provides novel systems and methods for dynamically alternating a busy state timer in a remote mirror and copy environment. The features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

DETAILED DESCRIPTION OF THE INVENTION

Referring toFIG. 1, in selected embodiments, a system100in accordance with the invention may include a host system102, a primary storage device104, and a secondary storage device106. A host system102may be configured to write to the primary storage device104, which may include a primary storage controller108and one or more primary volumes110associated with the primary storage controller108. Whenever data is written to the primary storage device104, the data may be mirrored to a secondary storage device106, which may include a secondary storage controller112and one or more secondary volumes114. To keep the data in the volumes110,114consistent, the system100may utilize a protocol such as Remote Mirror and Copy, Peer-to-Peer Remote Copy (PPRC), or other similar protocol.

In selected embodiments, whenever a primary storage controller108mirrors data to the secondary controller112, the primary controller108may monitor the state of the secondary volumes114. In certain embodiments, the primary controller108may utilize a “long busy state” timer116to monitor the state of the secondary volumes114.

The long busy state timer116may be used to monitor the state of the secondary volumes114if the secondary storage controller112has rejected a primary volume I/O with a signal indicating it is in a long busy state. A secondary storage controller112may go into long busy state as a result of several conditions in the secondary storage controller112. For example, the secondary controller112may return a long busy signal if it receives I/O during a warmstart or failover recovery process. In other cases, the secondary controller112may return a long busy signal if a disk drive module (DDM) is undergoing a recovery process.

Once the primary storage controller I/O is rejected with a long busy signal, the primary storage controller108may send a long busy signal to the host system102where the I/O originated. At this point, one of two events may occur. The secondary volumes114may change state from long busy to no longer long busy. Alternatively, the long busy state timer116may expire in the primary storage controller108.

If the secondary volumes114transition from long busy to no longer long busy, the secondary storage controller112may notify the primary storage controller108that it is no longer in long busy state. The primary storage controller108may then notify the host system102that the volumes (i.e., the primary and secondary volumes110,114) are no longer in long busy state. The host102may then reinitiate the I/O that was previously rejected with long busy status.

Conversely, if the long busy state timer116expires, the primary storage controller108may query the secondary storage controller112to determine the state of the secondary volumes114. One of two events may occur in response to this query. The secondary storage controller112may respond that the secondary volumes114are no longer long busy or the secondary storage controller112may respond that the secondary volumes114are still in long busy state. If the secondary volumes114are no longer in long busy state, the primary storage controller108may notify the host102that the volume is no longer in long busy state. The host102may then reinitiate the I/O that was rejected with long busy status.

If, on the other hand, the secondary volumes114are still in long busy state after the long busy state timer116has expired, the primary storage controller108may initiate its recovery process. The primary storage controller108may also suspend the secondary volumes114and report to the host102that the volumes (i.e., the primary and secondary volumes110,114) are suspended.

When the host102has been notified that the volumes110,114are suspended, the host102may invoke its recovery procedure. For example, in a count-key-data (CKD) host environment, a recovery procedure called HyperSwap may be invoked. This procedure sends a freeze command to the primary storage controller108and the primary storage controller108in turn freezes all I/O to the volume pairs in the logical subsystem associated with the suspended volume. HyperSwap will then cause the host102to swap to the secondary storage controller112. In essence, this causes the secondary storage controller112to become the primary storage controller108.

The duration of the long busy state timer116may be controlled by a timer value118. Unlike the hard-coded value described previously, the timer value118may be modified using a command130(e.g., PPRC Long Busy State timer) in accordance with the invention. This command130may provide a way for the host system102to manage and control the duration of the long busy state timer116.

Using this command130, a host102may adjust the duration of the long busy state timer116in real time. In selected embodiment, the command130may enable a host102to adjust the duration of the long busy state timer116for different applications120,122. For example, the duration of the long busy state timer116may be reduced when backing up a critical database. Likewise, the duration of the long busy state timer116may be increased when backing up a non-critical database.

In other embodiments, the command130may allow the host system102to adjust the duration of the long busy state timer116to correspond to one or more timers124of the host system102. For example, an IBM S/390host may set the duration of the timer116to correspond to a Missing Interrupt Handler (MIH) timeout value or to a Geographically Dispersed Parallel Sysplex (GDPS) timer.

In selected embodiments, the timer value118may be limited to a range of values. For example, if a command130attempts to set the timer duration above a maximum value126or below a minimum value126, the microcode of the primary storage controller108may set the timer value118to a maximum or minimum value126closest to the desired value. Alternatively, the microcode may set the timer value118to a default value128between the maximum and minimum values126.

In selected embodiments, the command130may be designed to provide selection granularity. For example, a first timer value118may be designated for Metro Mirror applications, whereas a different timer value118may be designated for Global Copy applications. Similarly, in other embodiments, the command130may be designed so that the host system102may designate a timer value118for a single volume pair, multiple volume pairs, or all volumes in a logical subsystem.

Referring toFIG. 2, in a first scenario, a host system102may begin by initializing200a PPRC application and initializing202the value of the long busy state timer116, such as with the default value128. The host102may then analyze204an application to start on the host system102and send206a command to set the long busy state timer value118to a value that is desired for the application. If the timer value is between the maximum and minimum values126, the primary storage controller may set208the timer value118to that indicated by the host102. If the timer value is not between the maximum and minimum values126, the primary storage controller may set208the timer value118to a value between the maximum and minimum values126, such as to the default value128.

The host system102may then attempt to write210data to the primary storage device104. The primary storage device104may receive212and store212the data and send214a copy of the data to the secondary storage device106to mirror the data to the secondary volumes114. If the secondary storage device106is not in long busy state, the secondary storage device106may store216the data in the secondary volumes114and send218an acknowledge signal to the primary storage device104. The primary storage device104may then send220an acknowledge signal to the host system102indicating that the write operation has successfully completed.

Referring toFIG. 3, in another scenario, the host system102may perform the same basic steps200,202,204,206,208described in association withFIG. 2. The host system102may then attempt to write210data to the primary storage device104. The primary storage device104may receive212and store212the data and then send214a copy of the data to the secondary storage device106to mirror the data to the secondary volumes114.

In this scenario, the secondary storage device106rejects the write and responds300with a long busy status. The primary storage device104receives302this status information and notifies the host system102that the write has been rejected304due to long busy status. The primary storage device104may also initiate306the long busy state timer116at this time. If the secondary storage device106does not notify the primary storage device104that it is no longer in long busy state before the timer116expires, the primary storage device104may query308the secondary storage device106to determine its status.

If the secondary storage device106once again responds310with a long busy status, the primary storage device104may then notify312the host102that the primary and secondary volumes110,114are in a suspended state. At this point, the host102may invoke its recovery procedure. In selected embodiments, this recovery procedure may include freezing314all I/O to the volume pairs in the logical subsystem that are in the suspended state. In certain embodiments, the recovery procedure may also include swapping316to the secondary storage device106, effectively making the secondary storage device106the primary storage device104.