HOST-SPECIFIC EVENT NOTIFICATION REGISTRATION

A computer-implemented method for effectively delivering notifications in data storage environments includes, receiving, by a storage controller from a host system, a request to register the host system with the storage controller to receive notifications. These notifications may be associated with a selected type of event detected by the storage controller. In certain embodiments, the selected type of event is a space-related condition associated with a particular storage resource controlled by the storage controller. The computer-implemented method registers the host system with the storage controller. In response to detecting an event of the selected type on the storage controller, the computer-implemented method transmits a notification from the storage controller to the host system to provide notice of the event. A corresponding system and computer program product are also disclosed.

BACKGROUND

Field of the Invention

This invention relates to systems and methods for more effectively delivering notifications in data storage environments.

Background of the Invention

When resource consumption thresholds are reached, the DS8000™ enterprise storage system and other storage systems may issue warning notifications to host systems for presentation to users. For most production devices, these notifications are sufficient to inform users of issues that are occurring on the storage systems and provide users the opportunity to address the issues in a timely manner. However, there are many cases in which notifications related to various types of recovery devices, which provide redundancy and resilience in a replication and/or data recovery environment, are not sufficiently surfaced to users. This is primarily due to the fact that recovery devices are frequently kept offline to most or all host systems for addressability and/or security reasons. Unfortunately, this may leave users unaware that their storage environment is no longer in a state that can support full recovery from future error events.

SUMMARY

The 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, systems and methods have been developed for more effectively delivering notifications in data storage environments. The features and advantages of the invention will become more fully apparent from the following description and appended claims, or may be learned by practice of the invention as set forth hereinafter.

Consistent with the foregoing, a computer-implemented method for effectively delivering notifications in data storage environments includes, receiving, by a storage controller from a host system, a request to register the host system with the storage controller to receive notifications. These notifications may be associated with a selected type of event detected by the storage controller. In certain embodiments, the selected type of event is a space-related condition associated with a particular storage resource controlled by the storage controller. The computer-implemented method registers the host system with the storage controller. In response to detecting an event of the selected type on the storage controller, the computer-implemented method transmits a notification from the storage controller to the host system to provide notice of the event.

A corresponding system and computer program product are also disclosed and claimed herein.

DETAILED DESCRIPTION

Referring toFIG.2, one example of a network environment200is illustrated. The network environment200is presented to show one example of an environment where systems and methods in accordance with the invention may be implemented. The network environment200is presented by way of example and not limitation. Indeed, the systems and methods disclosed herein may be applicable to a wide variety of different network environments in addition to the network environment200shown.

As shown, the network environment200includes one or more computers202,206interconnected by a network204. The network204may include, for example, a local-area-network (LAN)204, a wide-area-network (WAN)204, the Internet204, an intranet204, or the like. In certain embodiments, the computers202,206may include both client computers202and server computers206(also referred to herein as “hosts”206or “host systems”206). In general, the client computers202initiate communication sessions, whereas the server computers206wait for and respond to requests from the client computers202. In certain embodiments, the computers202and/or servers206may connect to one or more internal or external direct-attached storage systems209(e.g., arrays of hard-storage drives, solid-state drives, tape drives, etc.). These computers202,206and direct-attached storage systems209may communicate using protocols such as ATA, SATA, SCSI, SAS, Fibre Channel, or the like.

The network environment200may, in certain embodiments, include a storage network208behind the servers206, such as a storage-area-network (SAN)208or a LAN208(e.g., when using network-attached storage). This network208may connect the servers206to one or more storage systems, such as arrays210of hard-disk drives or solid-state drives, tape libraries212, individual hard-disk drives214or solid-state drives214, tape drives216, CD-ROM libraries, or the like. To access a storage system210,212,214,216, a host system206may communicate over physical connections from one or more ports on the host206to one or more ports on the storage system210,212,214,216. A connection may be through a switch, fabric, direct connection, or the like. In certain embodiments, the servers206and storage systems210,212,214,216may communicate using a networking standard or protocol such as Fibre Channel (FC) or iSCSI.

Referring toFIG.3, one example of a storage system210containing an array of hard-disk drives304and/or solid-state drives304is illustrated. In certain embodiments, all or part of a system and method in accordance with the invention may be implemented within such a storage system210. As shown, the storage system210includes a storage controller300, one or more switches302, and one or more storage drives304, such as hard-disk drives304and/or solid-state drives304(e.g., flash-memory-based drives304). The storage controller300may enable one or more host systems206(e.g., open system and/or mainframe servers206running operating systems such z/OS, zVM, or the like) to access data in the one or more storage drives304.

In selected embodiments, the storage controller300includes one or more servers306a,306b. The storage controller300may also include host adapters308and device adapters310to connect the storage controller300to host devices206and storage drives304, respectively. Multiple servers306a,306bmay provide redundancy to ensure that data is always available to connected host systems206. Thus, when one server306afails, the other server306bmay pick up the I/O load of the failed server306ato ensure that I/O is able to continue between the host systems206and the storage drives304. This process may be referred to as a “failover.”

In selected embodiments, each server306may include one or more processors312and memory314. The memory314may include volatile memory (e.g., RAM) as well as non-volatile memory (e.g., ROM, EPROM, EEPROM, hard disks, flash memory, etc.). The volatile and non-volatile memory may, in certain embodiments, store software modules that run on the processor(s)312and are used to access data in the storage drives304. These software modules may manage all read and write requests to logical volumes322in the storage drives304.

One example of a storage system210having an architecture similar to that illustrated inFIG.2is the IBM DS8000™ enterprise storage system. The DS8000™ is a high-performance, high-capacity storage controller providing disk and solid-state storage that is designed to support continuous operations. Nevertheless, the techniques disclosed herein are not limited to the IBM DS8000™ enterprise storage system210, but may be implemented in any comparable or analogous storage system210, regardless of the manufacturer, product name, or components or component names associated with the system210. Any storage system that could benefit from one or more embodiments of the invention is deemed to fall within the scope of the invention. Thus, the IBM DS8000™ is presented only by way of example and not limitation.

Referring toFIG.4, in certain embodiments, apparatus and methods in accordance with the invention may be implemented in a data replication system such as IBM's Metro or Global Mirror. In such systems, production data may be mirrored from primary volumes402aon a primary storage system210ato secondary volumes402bon a secondary storage system210bto maintain two consistent copies of the production data. The primary and secondary storage systems210a,210bmay be located at different sites400a,400b, perhaps hundreds or even thousands of miles away from one another. One or more primary host systems206amay perform I/O on the primary storage system114aand one or more secondary host systems206bmay perform I/O on the secondary storage system210b. In the event the primary storage system210afails, I/O may be redirected to the secondary storage system210b(a process referred to as a failover), thereby enabling continuous operations. In certain embodiments, the primary storage system210aand/or secondary storage system210bis a storage system such as that illustrated and described in association withFIG.3.

FIG.5shows an alternative toFIG.4wherein snapshots500(i.e., point-in-time copies500) are periodically taken of data in the secondary volumes402b. These snapshots500may be stored in tertiary volumes502either at the secondary site400bor at a third site that is remote from the secondary site400b. In certain embodiments, the tertiary volumes502are stored on and controlled by the secondary storage system210b.

Referring toFIG.6, as previously mentioned, when resource consumption thresholds (e.g., space-related thresholds or conditions) are reached, the DS8000™ enterprise storage system and other storage systems may issue warning notifications to host systems206for presentation to users. For most production devices, these notifications are sufficient to inform the users of issues that are occurring on the storage systems210and provide users the opportunity to address the issues in a timely manner. However, there are many cases in which notifications related to various types of recovery devices such as the secondary storage system210b, which provide redundancy and resilience in a replication and/or data recovery environment, are not sufficiently surfaced to users. This is primarily due to the fact that recovery devices are frequently kept offline to most or all host systems206for addressability and/or security reasons. Unfortunately, this may leave users unaware that their environment is no longer in a state that can support full recovery from future error events.

Currently, when events such as out-of-space conditions or other space-related conditions occur for particular storage resources (e.g., storage drives304, logical volumes402, storage arrays210, logical subsystems (LSSs) etc.), notifications are typically sent to host systems206that are grouped (i.e., online) to the storage resources. However, host systems206that are not grouped or online with respect to the storage resources may not receive the notifications, even though a communication path or connection may exist between the host systems206and storage resources. This can be particularly problematic where a host system206is a managing host system206that is tasked with managing a disaster recovery environment (such as by setting up pairing relationships, managing point-in-time copies, setting up volumes, etc.) since the managing host system206may not be aware of potential issues (e.g., out-of-space conditions, etc.) that need to be addressed to keep the disaster recovery environment functioning as intended. In a worst-case scenario, the disaster recovery environment may be unable to recover from a disaster as intended because these issues were not surfaced to a managing host system206in a timely manner for resolution.

In certain embodiments in accordance with the invention, in order to ensure that notifications are adequately surfaced to host systems206even when storage resources are offline to the host systems206(i.e., not able to be read from and/or written to by the host systems206), an event notification registration module150may be provided in a storage system210, such as the secondary storage system210b. This event notification registration module150may be configured to register particular host systems206(e.g., logical hosts, logical partitions (LPARs), operating system (OS) images, etc.) to receive notifications for events occurring on the storage system210or storage resources controlled by the storage sy stem210.

In certain embodiments, when a host system206wishes to register itself with a storage system210in order to receive notifications, the host system206(and more specifically an application600such as a management system like GDPS executing on the host system206) may transmit a request602to the storage system210. The storage system210may receive this request602and, in response, register the host system206with the storage system210to receive notifications for particular events occurring on the storage system210. Alternatively, host systems206may be automatically registered for notifications when resources are brought online and an owning application600ensures that it brings at least one device online for each set of resources it manages.

In certain embodiments, a registration request602may include various parameters that define the scope of the notifications that it wishes to receive. For example, the parameters may designate specific storage resources for which a host system206wishes to receive notifications, the types of events for which the host system206wishes to receive notifications, the identity (e.g., location, address, name, etc.) of the host system206that wishes to receive the notifications, and the like.

In one example, a host system206may wish to receive notifications for particular storage resources of a storage system210for space-related conditions, such as out-of-space conditions. Such space-related conditions may include, for example, physical space for a space-efficient extent pool or virtual capacity for a Safeguarded Copy Backup volume (i.e., point-in-time-copy) having reached a warning watermark; physical space for a space-efficient extent pool or virtual capacity for a Safeguarded Copy Backup volume having become completely exhausted; and one of the previously listed space-related conditions having been addressed or relieved.

Receiving notifications may enable a host system206to take actions such as freeing up storage space, allocating more storage space, redirecting I/O, modifying I/O, etc. to storage resources that are affected by an out-of-space or other space-related condition. The ability to surface notifications to a host system206, particularly to a managing host system206that may not otherwise have access to a storage resource due to the storage resource being offline with respect to the host system206, may enable more automated management of selected events in the disaster recovery environment as well to mitigate a variety of potentially impactful events.

In certain embodiments, a registration request602may be embodied as a DSO (i.e., define subsystem operation) command that will enable a host system206to register for all out-of-space or other related events that occur for a given control unit cluster (e.g., control unit server306, central electronics complex (CEC), node, etc.). It may be up to managing software (GDPS, CSM, etc.) in a host system206to ensure that it registers with each cluster (e.g., server306) for which it wants to receive notifications. When an out-of-space condition occurs in the server306, the server306may send a notification to any and all host systems206that have registered with the server306. This may be in addition to any notifications that the server306would normally send to host systems206that are grouped or online with respect to the server306.

Referring toFIG.8, a high-level block diagram showing an event notification registration module150and associated sub-modules is illustrated. The event notification registration module150and associated sub-modules may be implemented in hardware, software, firmware, or combinations thereof. The event notification registration module150and associated sub-modules are presented by way of example and not limitation. More or fewer sub-modules may be provided in different embodiments. For example, the functionality of some sub-modules may be combined into a single or smaller number of sub-modules, or the functionality of a single sub-module may be distributed across several sub-modules.

As shown, the event notification registration module150may include one or more of a registration module700, detection module710, determination module712, and notification module714. In response to receiving a registration request602, the registration module700may be configured to register a particular host system206with the storage system210that hosts the event notification registration module150. In certain embodiments, when registering a particular host system206, the registration module700may identify702the host system206that is to receive the notifications, identify704the types of events for which the host system206will be notified, and identify706the storage resources for which the host system206will be notified of events. In certain embodiments, these parameters are set forth in a registration request602that is transmitted from the host system206to the storage system210. In other embodiments, the parameters are set by a user or automatically by default.

The detection module710may be configured to detect when an event800such as an out-of-space condition occurs on the storage system210, as shown inFIG.8. When an event is detected, the determination module712may determine the event type and the storage resource for which the event occurred. Based on this information, the determination module712may determine whether a host system206that has been registered with the storage system210should receive a notification. If so, the notification module714may send a notification802to the host system206to provide notice of the event, as also shown inFIG.8.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other implementations may not require all of the disclosed steps to achieve the desired functionality. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.