SEPARATING SEQUENTIAL I/O WORKLOADS ACCESSING A VOLUME IN AN I/O STREAM OF MULTIPLE SUPERIMPOSED SEQUENTIAL I/O WORKLOADS

In one general embodiment, a computer-implemented method includes detecting individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume. The detecting is based on a time dependency corresponding to accesses of blocks of the volume. In another general embodiment, a computer-implemented method includes detecting a plurality of sequential input/output (I/O) workloads in an I/O stream of superimposed workloads accessing a same volume, the detecting being based on a time dependency corresponding to accesses of blocks of the volume. A sequentiality factor is calculated for each of the sequential I/O workloads.

BACKGROUND

The present invention relates to managing input/output (I/O) workloads, and more specifically, this invention relates to separating sequential I/O workloads accessing a volume in an I/O stream of multiple superimposed sequential I/O workloads.

Storage systems, such as storage subsystems of larger computing and/or storage systems, improve read I/O latencies using read-caches which are located in high speed memory such as DRAM. The latency of a cache hit in DRAM, for example, is about an order of magnitude lower than cache miss, when the I/O target is not present in the cache and must be passed to the storage backend.

One strategy for enhancing the amount of cache hits is to determine when sequential I/O is happening and to pre-fetch data from the storage backend and put the pre-fetched data into the cache before the next I/O operation requests the data. The storage systems normally keep track of sequential I/Os in the boundaries of individual volumes. Using the SCSI and NVMe protocol, for example, these volumes have individual I/O queues (SCSI: 1 queue, NVMe: 64 k queues).

It is good practice to operate with volumes separated at host level if the workload of the application is known. For example, a relational database system requires database files and redo logs, and placing these logs on individual volumes with disjunct I/O queues greatly increases the performance of the application.

With the explosion of capacity, the consolidation of workloads and the tendency to virtualize Virtual Machines (VMs) and containers, it is now common to have multiple workloads being backed by only one single large volume of the storage system. In such environments, a mixture of all the I/Os of the different applications is consolidated on the I/O queue(s) of the volume. If multiple sequential I/Os of different applications are happening at the same time, the I/O stream on the volume will be pseudo-random if the host is not separating each sequential stream of I/Os into individual I/O queues by itself. A storage system is then not able to detect sequentially in the IO stream without additional processing.

In virtualized and container environments the workloads of multiple virtual machines and/or containers are overlapping at the host bus adapter level, and sequential I/O cannot be detected in the resulting I/O queue by the attached storage systems.

SUMMARY

A computer-implemented method, in accordance with one embodiment, includes detecting individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume. The detecting is based on a time dependency corresponding to accesses of blocks of the volume.

A computer-implemented method, in accordance with another embodiment, includes detecting a plurality of sequential input/output (I/O) workloads in an I/O stream of superimposed workloads accessing a same volume, the detecting being based on a time dependency corresponding to accesses of blocks of the volume. A sequentiality factor is calculated for each of the sequential I/O workloads.

A computer program product, in accordance with one embodiment, includes a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to detect, by the processor, individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume. The detecting is based on a time dependency corresponding to accesses of blocks of the volume.

DETAILED DESCRIPTION

The following description discloses several preferred embodiments of systems, methods and computer program products for separating sequential I/O workloads accessing a volume in an I/O stream of multiple superimposed sequential I/O workloads. In one embodiment, the methodology provided herein delivers a separation of multiple sequential I/O workloads running against the same I/O queue of a storage volume at the storage system controller, and in preferred approaches, without knowledge of the setup in the servers, VMs and/or containers.

In one general embodiment, a computer-implemented method includes detecting individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume. The detecting is based on a time dependency corresponding to accesses of blocks of the volume.

In another general embodiment, a computer-implemented method includes detecting a plurality of sequential input/output (I/O) workloads in an I/O stream of superimposed workloads accessing a same volume, the detecting being based on a time dependency corresponding to accesses of blocks of the volume. A sequentiality factor is calculated for each of the sequential I/O workloads.

In yet another general embodiment, a computer program product includes a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to detect, by the processor, individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume. The detecting is based on a time dependency corresponding to accesses of blocks of the volume.

According to some approaches, methods and systems described herein may be implemented with and/or on virtual systems and/or systems which emulate one or more other systems, such as a UNIX® system which emulates an IBM® z/OS® environment (IBM and all IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation and/or its affiliates), a UNIX® system which virtually hosts a known operating system environment, an operating system which emulates an IBM® z/OS® environment, etc. This virtualization and/or emulation may be enhanced through the use of VMware® software, in some embodiments.

Now referring toFIG.3, a storage system300is shown according to one embodiment. Note that some of the elements shown inFIG.3may be implemented as hardware and/or software, according to various embodiments. The storage system300may include a storage system manager312for communicating with a plurality of media and/or drives on at least one higher storage tier302and at least one lower storage tier306. The higher storage tier(s)302preferably may include one or more random access and/or direct access media304, such as hard disks in hard disk drives (HDDs), nonvolatile memory (NVM), solid state memory in solid state drives (SSDs), flash memory, SSD arrays, flash memory arrays, etc., and/or others noted herein or known in the art. The lower storage tier(s)306may preferably include one or more lower performing storage media308, including sequential access media such as magnetic tape in tape drives and/or optical media, slower accessing HDDs, slower accessing SSDs, etc., and/or others noted herein or known in the art. One or more additional storage tiers316may include any combination of storage memory media as desired by a designer of the system300. Also, any of the higher storage tiers302and/or the lower storage tiers306may include some combination of storage devices and/or storage media.

The storage system manager312may communicate with the drives and/or storage media304,308on the higher storage tier(s)302and lower storage tier(s)306through a network310, such as a storage area network (SAN), as shown inFIG.3, or some other suitable network type. The storage system manager312may also communicate with one or more host systems (not shown) through a host interface314, which may or may not be a part of the storage system manager312. The storage system manager312and/or any other component of the storage system300may be implemented in hardware and/or software, and may make use of a processor (not shown) for executing commands of a type known in the art, such as a central processing unit (CPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc. Of course, any arrangement of a storage system may be used, as will be apparent to those of skill in the art upon reading the present description.

According to some embodiments, the storage system (such as300) may include logic configured to receive a request to open a data set, logic configured to determine if the requested data set is stored to a lower storage tier306of a tiered data storage system300in multiple associated portions, logic configured to move each associated portion of the requested data set to a higher storage tier302of the tiered data storage system300, and logic configured to assemble the requested data set on the higher storage tier302of the tiered data storage system300from the associated portions.

Overview of Separating Sequential I/O Workloads In an I/O Stream of Multiple Superimposed Sequential I/O Workloads

The methodology presented hereinbelow enables separation of multiple sequential I/O workloads running against the same I/O queue of a storage volume. The various determinations and computations can be performed at the storage system controller in some approaches, and in some aspects, without knowledge of the setup in the servers, VMs and/or containers. By detecting sequential I/O patterns, various processes described herein are able to optimize (reduce) latency of overlapping workloads.

By introducing a time dependency, the individual sequential I/O patterns in storage environments where many I/Os from different workloads overlap are recognized. The time dependency can be in real time, based on I/O count (e.g., by counting every I/O) in a table or map of accessed blocks, etc.

In further approaches, a sequentiality factor is calculated for some or all of the sequential I/O streams. Based on the sequentiality factor, an optimal cache strategy can be determined. Moreover, further improvements are achievable by considering parameters of the storage system, such as available memory, load on the storage backend, etc. Based on factors such as the achieved performance benefit for the host workload, a user input, etc., the parameters of the optimization can be adjusted on a per volume basis.

In one approach, the knowledge regarding separate sequential I/O workloads and the sequentiality factors are used to optimize the read ahead provided by the storage system and deliver better (lower) latencies for the I/O access. This in turn results in better overall performance to the applications which are driving the individual workloads.

Any of the aforementioned functionality may be activated on a per volume basis. By using these features on a volume basis, additional storage resources such as CPU, memory, and backend I/Os can be allocated to the more critical applications and their storage volumes. Also, the sequentiality factor can be analyzed per volume to get a better understanding of the workload.

Moreover, aspects of the aforementioned functionality may be selectively activated based on predefined parameters, such as the availability of system resources, current and/or historical system performance, etc.

Now referring toFIG.4, a flowchart of a method400for separating sequential input/output (I/O) workloads accessing a volume in an I/O stream of multiple superimposed sequential I/O workloads is shown according to one embodiment. The method400may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-3, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.4may be included in method400, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG.4, method400includes operation402, in which individual sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume are detected. The detecting is based on a time dependency corresponding to accesses of data blocks of the volume, as will be elaborated on in detail below. Note that there may be many superimposed I/O workloads, some or all of which are detected as being sequential I/O workloads.

Now referring toFIG.5, a flowchart of a method500for separating sequential input/output (I/O) workloads accessing a volume in an I/O stream of multiple superimposed sequential I/O workloads is shown according to one embodiment. The method500may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-4, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.5may be included in method500, as would be understood by one of skill in the art upon reading the present descriptions.

As shown inFIG.5, method500includes operation502, in which sequential input/output (I/O) workloads in a stream of superimposed I/O workloads accessing a same physical volume are detected. The detecting is based on a time dependency corresponding to accesses of data blocks of the volume, as will be elaborated on in detail below.

In operation504, a sequentiality factor is calculated for each of the sequential I/O workloads. The sequentiality factor is useful for such things as enabling preferred read ahead of sequential I/O streams which are reading more sequential blocks during a timeframe than other streams. The calculation and use of the sequentiality factor is elaborated upon in detail below.

Detection of Sequential I/O Workload Streams

Various aspects of the present invention operate in environments where multiple I/O workloads run independently of one another, but where I/Os are introduced to the same storage volume in a storage system. Examples of such environments include one or more of:Multiple workloads running within a single server (e.g., bare metal or virtualized),Multiple workloads running in respective VMs, each VM having its virtual volume placed on the same physical volume as the other VMs, andContainers, where sequential I/O workloads are each running in a unique container having a persistent volume claim on the same filesystem located on one physical volume.

Referring toFIG.6, which is a diagram of a system600having a storage subsystem604being accessed by a host side602. The host side602may have any number of workloads, referred to as WLx where {x=1, 2, . . . n}. The workloads may originate from an application, a VM, a container, etc. Moreover, the application, VM, container, etc. may send requests to a virtual disk Virt Diskx where {x=1, 2, . . . n}, which may be part of a File System of known type. The host side602may also include any type of interface606to the storage subsystem604, in this example Bare Metal and/or a Hypervisor, as well as a host bus adapter HBA.

For purposes of this illustration, there are depicted three independent workloads WL1, WL2, WL3which are accessing the same physical volume PV1. The individual I/O stream608of the workloads are described as WLx,y, where {x=1,2,3} is related to the workload and {y=1, 2, . . . ,m} represents the number of I/O after a start point, e.g., time=t0. The resulting I/O queue on the HBA will then have a mix of I/Os coming from all three workloads.

For sequential workloads, which retrieve sequential data blocks from the physical volume PV1, the I/O stream610presented to the storage subsystem604loses its sequential property and the storage system will see a pseudo random I/O stream610. Thus, the storage subsystem604is not able to discern which streams are sequential, making prefetch of data impractical.

Various aspects of the present invention overcome this drawback by identifying the individual sequential I/O workload streams, thereby allowing such streams to essentially be treated as individual queues within the storage subsystem. Referring toFIG.7, there is shown the system600ofFIG.6, with the new and novel sequential I/O workload detection feature700described herein and labeled as Queue Separation inFIG.7.

“Sequential” I/Os are those that access sequential blocks in a volume. Typically, a physical volume has many blocks of a fixed size, and the blocks are numbered sequentially, e.g., consecutively from1to n, where n is the number of blocks in the volume. Normal read ahead algorithms check whether a predefined number of consecutive I/Os access sequential blocks. If this is detected, the read-ahead algorithm causes reading of additional blocks into the cache to be prepared for new incoming I/Os which could request these additional blocks.

Using a table, such as a bitmap, in which the last I/Os are stored, a sequential I/O can be readily identified.FIG.8depicts a bitmap of a portion of a volume, where each field (square) in the bitmap corresponds to a data block in the volume and a “1” in the field represents a consecutive I/O of at least two adjacent data blocks. If the workload is sequential and there are, for example, six I/Os (t1, . . . ,t6) requesting data blocks in a sequential way, the read-ahead algorithm easily can find the sequential I/O by looking at the bitmap. However, in conventional read-ahead algorithms, the bitmap is cleared as soon as one I/O is not addressing a block which would be predicted by the read-ahead algorithm.

Moreover, as soon as there are two sequential workloads superimposed addressing the same volume (e.g., as inFIG.6), the temporal sequence of the I/O stream is hidden, rendering conventional read-ahead algorithms unable to accurately predict read ahead. The bitmap shown inFIG.9depicts an example for the time t10, after ten I/O cycles. Only the bits in the bitmap for the last two I/Os would be recognized as sequential I/O. The blocks accessed at t4 and t6 would not be recognized by conventional read-ahead algorithms as corresponding to sequential I/O because I/O was performed at a different location in the volume at t2, t3 and t5.

The methodology, according to one embodiment, is not to simply refer to the last entry in the table (e.g., bitmap) to detect sequential workloads, but to define a relationship where a temporal dependency is defined to detect the sequential access. The time dependency can be in real time, based on I/O count (e.g., by counting every I/O) in a table or map of accessed blocks, etc. The methodology to separate the individual workloads and their corresponding I/O streams, according to one embodiment, not only leverages the location of each of the reads within the volume, but also the temporal characteristics of the reads.

FIG.10depicts a table (bitmap) in which a time dependency of the I/O is also included, thereby allowing a time dependency to be derived from a table of accessed blocks. Instead of simply registering an I/O in the bitmap, the individual time such as a timestamp corresponding to the I/O (or equivalently the number of I/O to this individual volume) is reflected (e.g., stored) in the bitmap. The inventive algorithm to detect sequential I/O is then able to take into account when the block prior to the now-accessed block has been accessed. In this way, the sequentially can be determined by using a decay function which is time and/or I/O dependent.

In the example shown inFIG.10, consider the first area of accessed blocks, which are accessed at times t1, t4, t6, t9 and t10. The inventive algorithm allows a predefined quantity of I/Os (for example, two, three, four, or more) going into other areas of the volume between I/Os to the area of interest in the volume, the I/Os to that area of interest are still considered a sequential stream, and thus, the access is defined as sequential.

Using the knowledge, an inference is made that a sequential I/O stream is requesting blocks from the target area of the volume, and additional blocks in the target area can be read into cache. This read ahead can be performed for each of the sequential I/O workloads, thereby greatly improving performance in terms of speed of serving data from the storage system. For example, looking atFIG.10, one or more blocks following the blocks read at t10 and t8 can be loaded into the read ahead cache, so that they are ready to be served to Workload1and Workload2, respectively, from cache if requested. Moreover may allow the storage system to utilize otherwise unused CPU cycles.

Thus, in preferred embodiments, the individual sequential I/O workloads are detected by analyzing accesses to sequential blocks in the volume during a period of time and/or across a number of accesses to the volume. The period of time and/or number of accesses may be predefined, selected based on historical data, based on a sliding window, based on a current workflow, etc. The individual sequential I/O workloads can thus be detected even when temporally consecutive accesses to the volume access nonsequential blocks, e.g., as shown inFIG.10. In some cases, individual sequential I/O workloads are detected even though no two consecutive I/Os access sequential blocks.

Sequentiality Factor

Because the individual sequential I/O workloads are identifiable, a sequentiality factor can be calculated for each of the sequential I/O workloads. The sequentiality factor can be any number, ratio, data, function, etc. that reflects a temporal-based indication of sequential accesses for a given sequential I/O workload.

The sequentiality factor is useful for many purposes. For example, the sequentiality factors for several sequential I/O workloads may be compared and used to give read ahead preference for blocks expected to be requested by one or more of the sequential I/O workloads.

The sequentiality factors can be calculated using any technique that would become apparent to one skilled in the art upon being apprised of the present disclosure.

In one embodiment, the sequentiality factor for each sequential I/O workload is calculated based on a formula having as variables the number of I/Os in a sequential stream of the sequential I/O workload and a total number of I/Os against the volume by all streams during performance of said number of I/Os. For example, the formula may include the number of I/Os in the sequential stream of the sequential I/O workload divided by the aforementioned total number of I/Os.

In an exemplary approach, a sequentiality factor, Sstreamx, is calculated for each stream x, where:

Sstreamx=Number of I/Os in a sequential streamx/Number of I/Os against the volume.

Looking to the example ofFIG.10, Streams 1 and 2 have the following sequentiality factor:

By comparing the sequentiality factors for Streams 1 and 2, the storage system may favor the read ahead of Stream 2 over the read ahead of Stream 1, thereby optimizing management and use of the limited read ahead cache. Thus, for example, a preferred order of read ahead of blocks of the volume for one or more of the sequential I/O workloads may be determined based on the sequentiality factors, and such read ahead of blocks for one or more of the sequential I/O workloads according to the preferred order may be performed. Any technique for determining a preferred order of read ahead may be used. For example, read ahead for the workload having the highest ranked sequentiality factor may be performed first, then read ahead performed for the workload having the second highest ranked sequentiality factor, and so on. Other techniques that would become apparent to one skilled in the art upon reading the present disclosure may be used. Using such a read-ahead algorithm, a storage system can improve the latency for I/O requests, and may also leverage unused CPU cycles.

Moreover, the sequentiality factor can be analyzed to gain a better understanding of the workloads, which in turn can be used to adjust allocations of storage resources such as CPU and memory.

General Computer Environment