Abstract: Execution of I/O operations for an application is managed to improve consistency of performance for an I/O performance metric for the application. Such control may be achieved by defining a value for a performance resilience objective (PRO) parameter, and applying the PRO value to I/O requests of the application. The PRO value may define a value indicative of an extent to which I/O performance can deviate from a performance objective (e.g., as defined by a service level) over time; i.e., a tolerance for such deviation. Components of a computer network may be configured to apply PRO values to I/O requests for one or more applications. The PRO values of applications may be distributed to one or more components of a data storage system and one or more components of a host system, and these components may be configured to apply the PRO values to I/O requests of the subject applications.

Abstract: Described are techniques for processing I/O operations that may include: issuing, by a process of an application on a host, an I/O operation; tagging the I/O operation with a tag value in accordance with a process name associated with the process that issued the I/O operation; sending the I/O operation from the host to a data storage system; and determining, on the data storage system, an service level objective (SLO) for the I/O operation in accordance with the tag value of the I/O operation. The process name may include a first portion and a second customizable or configurable portion used to distinguish between different instance of the same application process. It may be determined which of multiple time-dependent SLOs for the process name is active and used with the I/O operation based on a receipt or processing time associated with the I/O operation.

Abstract: An apparatus in one embodiment comprises a host device configured to communicate over a network with a storage system comprising a plurality of storage devices. The host device includes a set of input-output queues and a multi-path input-output driver configured to select input-output operations from the set of input-output queues for delivery to particular ports of the storage system over the network in accordance with a load balancing algorithm. The multi-path input-output driver is further configured to receive notification from one or more of the ports indicating that at least a given one of the ports has exceeded a designated threshold level of port load, and to adjust the load balancing algorithm based at least in part on the received notification.

Abstract: A system, computer program product, and computer-executable method, including creating a production Logical Unit (LU) and one or more snapshots of the production LU on a data storage system, wherein the data storage system provides an interface to the production LU and each of the one or more snapshots, receiving an I/O request at the interface to the production LU, analyzing the received I/O request to determine whether a code is embedded in the received I/O request, and processing the received I/O request based on the code, wherein the received I/O request is enabled to be sent to the production LU or a first snapshot of the one or more snapshots based on the code.

Abstract: A system, computer program product, and computer-executable method of balancing Input/Output (I/O) loads for cloud data storage systems including a plurality of hosts and a plurality of data storage arrays, the system, computer program product, and computer-executable method including monitoring, via a first host of the plurality of hosts, a status of a first data storage array of the plurality of data storage arrays, upon detecting a performance issue with the first data storage array, notifying a cloud manager of the first data storage array, wherein the cloud manager is in communication with each of the plurality of hosts and each of the plurality of data storage arrays, monitoring, via the cloud manager, the performance issue, and determining, via the cloud manager, whether to move at least one LUN from the first data storage array.

Abstract: Example embodiments of the present disclosure relate to a method, computer program product, and system for an upgrade of an array specific module in a multipath application comprising suspending all input/output operations associated with the array specific module; and upgrading the array specific module without disrupting any input/output operations associated with the array specific module.

Abstract: A technique for storing data operates a replication splitter in a host computing device. The host computing device runs an application and monitors write performance from the application to both a data storage array and a replication site. If the monitored performance indicates that writes to the replication site would not significantly slow down the application, the replication splitter operates in synchronous mode, in which the splitter waits to acknowledge writes from the application until it receives confirmation of write completion from both the data storage array and the replication site. However, if the monitored performance indicates that writes to the replication site would significantly slow down the application, the replication splitter operates in asynchronous mode, in which the splitter acknowledges writes from the application as soon as it receives confirmation that the data storage array has completed those writes and without waiting for acknowledgements from the replication site.

Abstract: Example embodiments of the present disclosure relate to a method, computer program product, and system for an upgrade of an array specific module in a multipath application comprising suspending all input/output operations associated with the array specific module; and upgrading the array specific module without disrupting any input/output operations associated with the array specific module.

Abstract: A host computer accesses a federated storage volume at first and second frames (physical storage assemblies). The host identifies a preferred frame by (1) obtaining representative values of a performance metric for sets of paths to the volume, each set associated with a different frame, and (2) selecting the frame associated with the path set having the best representative value. In one example a response latency is used to detect different distances to the host and identify the closer frame, which will be preferred. Operating modes of the paths for non-preferred frames are set to “standby”. During subsequent operation using path selection to send storage operations to the volume, the host selects among paths in an “active” operating mode so as to access the volume at the preferred frame under normal operating condition. Standby paths are reserved for less normal operating conditions, such as when no active path is available.

Abstract: A technique oversees a path between a multipathing driver of a host computer and a volume of a data storage array. The technique involves, while the multipathing driver of the host computer sends input/output requests (IOs) to the volume of the data storage array on the path, generating an IOs-Over-Period metric based on outcomes of the IOs, the IOs-Over-Period metric providing a measure of IOs per failure over a period of path operation. The technique further involves performing a comparison operation which compares the IOs-Over-Period metric to a predefined flaky path range having a predefined lower limit and a predefined upper limit. The technique further involves, after performing the comparison operation, outputting a detection signal indicating that the path is (i) flaky when the IOs-Over-Period metric falls within the predefined flaky path range and (ii) non-flaky when the IOs-Over-Period metric falls outside of the predefined flaky path range.

Abstract: An improved technique for processing IO requests has been described that distinguishes bogus IOs from genuine IO request failures by accessing a hardware configuration record that associates available paths with hardware components at different hardware layers traversed by the paths. When an IO request fails down a first path, a second path is selected for retrying the IO request by accessing the hardware configuration record and identifying a path that the record indicates traverses hardware components that are different from those traversed by the first path at multiple hardware layers. The chance that an IO request will fail due to faulty hardware over both the first path and the second path is thus low, such that IO failures down both the first path and the second path provide a clear indication that the IO request is bogus.