None.
1. Field of The Invention
The present invention relates generally to power management in systems that include a number of electronic devices.
2. Description of Related Art
Power budgets in complex computer systems are receiving more scrutiny lately. Distributed data storage systems, for example, use a number of electronic devices that are capable of operation at different power levels corresponding to different operational modes. For purposes of this description the electronic devices can include storage devices such as disk drives and solid state drives, and they can be read/write devices, such as a tape drive. The storage devices experience a significantly higher utilization at some times in comparison to other times. Some storage activities can be time shifted to off-peak times to extend the benefits of reduced power level operation. It is to these improvements that the embodiments of the present technology are directed.
Some embodiments of this technology contemplate an apparatus having a first electronic device and a second electronic device. The first electronic device is configured to execute input/output (I/O) commands via a network. The second electronic device is also configured to execute I/O commands via the network. Additionally, the second electronic device has a power manager application configured to control an amount of power supplied to the second electronic device based on an amount of power being supplied to the first electronic device.
Some embodiments of this technology contemplate a computer apparatus having a plurality of electronic devices, each electronic device including a controller configured to communicate input/output (I/O) commands and power control circuitry configured to selectively increase an amount of power supplied to one of the electronic devices based on an amount of power being supplied to at least one of the other electronic devices.
Some embodiments of this technology contemplate a method that includes: obtaining an apparatus including a plurality of electronic devices operably executing input/output (I/O) commands via a network; and individually controlling amounts of power supplied by each of the electronic devices, based on one of the electronic devices determining the amount of power supplied by at least one other of the electronic devices.
Initially, this disclosure is by way of example only, not by limitation. The power management concepts herein are not limited to use or application with any specific system or method. That is, the embodiments for storing digital data are illustrative and not limiting of the contemplated embodiments of this technology. Thus, although the instrumentalities described herein are for the convenience of explanation, shown and described with respect to exemplary embodiments, the skilled artisan understands that the principles herein may be applied equally in other types of systems and associated methods.
To illustrate an exemplary environment in which embodiments of the present technology can be practiced,
Access commands are flushed (moved) from the cache 126 into a command queue 128.
In other words, the command queue 128 is populated to, in effect, grant permissions to issue cached access commands. A power manager application 130 allocates power resources to enable electronic devices that are necessary for executing the flushed access commands. For purposes of this description, in illustrative embodiments each power manager application 130 controls the amount of power provided to its respective data store 108.
The capacity of the data store 108 is organized into logical addresses that are referenced when transferring access commands with the storage devices. System configuration information defines the storage relationships between user data and any associated parity and/or minor data. The system configuration information furthermore identifies the storage relationships between physical block addresses and the associated logical block addresses.
The controller 112 architecture advantageously provides scalable, highly functional data management and control of the data store 108. The system configuration information can further include data structures that are aligned to stripe boundaries on the storage devices. The data structures can reference data buffers in the cache 126 that are dedicated to storing the data associated with a storage stripe.
During operation, executing the access commands generally involves input-output (I/O) data transfers between the hosts 102 and the respective data store 108. Readback data retrieved from the storage devices, including non-requested speculative data, can be retained for a time in the respective cache 126 in an expectation of a “cache hit” in response to a subsequent access command. Speculative data is data that is retrieved in addition to the requested data, based on a predicted value of its access in the future. The throughput capacity of the computer system 100 is advantageously increased when a subsequent access command can be satisfied directly from the cache 126 instead of scheduling an I/O transfer with one or more of the storage devices.
Each power manager 130 includes a power control block 134 coupled to a switching device 136. The power control block 134 provides control outputs to the switching device 136 in response to operational inputs from the respective controller 112 (
The same structure can be repeated for each of the other storage devices, although not depicted. For example, there can be ten data storage devices 132 in the data store 108, each storage device 132 capable of operating at any of the three power inputs depicted (V1, V2, and Vn). In that example, it will be understood that the power control block 134 can include a total of thirty such conduction paths to the data storage devices 1321, 1322, . . . 13210.
Write commands received via the fabric I/F 120 are writeback cached in the cache 126 and held there until they are flushed from the cache 126. Flushing is controlled by a policy engine 146 that determines particular sets of write commands that can be simultaneously stored to the different storage devices 132. A policy engine is a processor-based module that includes an application executing an operating system. For example, without limitation, the sets of write commands can be defined by RAID (“redundant array of independent devices”) container services (RCS) 147. The RCS 147 perform data transfers in accordance with RAID algorithms that aim to transfer parity stripes of data across a plurality of the storage devices 132. The functional blocks depicted in
The controller 112 continuously manages the writeback data processes to optimize throughput performance at each of a number of different operational modes, depending on system-wide conditions and requirements. For example, one operational mode generally involves periodically flushing constant-size blocks of data of a predetermined size. For example, flushing a stripe of RAID data when the entire RAID stripe is cached. Another operational mode generally involves flushing smaller and perhaps varying-size blocks of data. For example, indexing the cached data by age (e.g., time the data has spent in the cache waiting flushing) and flushing an access command when its age exceeds a predetermined age limit.
In accordance with this technology, the aggressiveness with which the cache 126 is flushed can be tied to the I/O load. That is, not flushing aggressively enough during a relatively high I/O load can cause the cache 126 to reach saturation. Conversely, flushing too aggressively during a relatively low I/O load can leave the cache deficient for satisfying potential cache hits. Both scenarios adversely affect data throughput performance.
The policy engine 146 can continuously collect qualitative data about access commands received via the fabric I/F 120 on an I/O-by-I/O basis via path 148. The policy engine 146 can dynamically characterize the I/O load and consequently issue rules via path 150 that govern the cache 126 which, in turn, populates the command queue 128 to define a command profile. The policy engine 146 also stays continuously apprised of the cache 126 state via path 152.
The policy engine 146 can also collect quantitative data about the I/O load in real time, such as the current rate of access commands coming from one or more network requesting devices. That enables the policy engine 146 to dynamically characterize the I/O load and continuously adjust the command profile to the storage devices 132 in relation to the characterization. For example, the policy engine 146 can continuously collect real time data characterizing the I/O load in terms of the ratio of rate sensitive commands (illustrated below) to latency sensitive commands (illustrated below). Writeback cache commands are considered to be rate sensitive commands because it does not matter so much which requests are flushed to the storage devices 132 at any point in time. In fact, rate sensitive commands may even be overwritten while pending in cache 126 as dirty data. What matters is that rate sensitive commands get flushed at a rate that prevents the cache 126 from reaching saturation or starvation.
On the other hand, an access command to read data that is stored in one or more of the storage devices 132 will likely cause the host application to block further processing until the access command is satisfied. The time it takes to satisfy the access command for read data, the latency period, is critical to the performance of the application. Such access commands are thereby referred to as latency sensitive commands. Further, in certain circumstances the host can opt to not authorize writeback caching. In that case an access command for writing data, called a writethrough command, is likewise categorized as a latency sensitive command.
The policy engine 146 can also collect quantitative data characterizing the I/O load in other terms such as the size of the associated data file (bandwidth), the particular host 102 and/or network device initiating the access command, storage device 132 information such as access history, timestamp data, RAID class, and the LUN class to which the access command is directed.
In collecting quantitative data the policy engine 146 preferably tallies counts during each of a predetermined sample interval, such as each one-second interval. A free running counter can be set with a pointer moving the index on one-second boundaries to continuously track the ratio. The counter holds a desired number of previously observed ratios, such as the previous eight one-second sample ratios, with a ninth slot for tallying the current one-second ratio. On the one-second boundaries the index cycles, subtracts the indexed historical value and adds the latest sample value, then divides by eight to calculate the most recent running average of the ratio.
The policy engine 146 can be responsive to performance parameters 154 in formulating rules for flushing the cache 126. The parameters 154 can be quantitative or qualitative. The parameters 154 can include goals, such as but not limited to enforcing a desired command profile that is some factor of the network I/O load in terms of the ratio of latency sensitive commands to rate sensitive commands (ratio of read to write commands for writeback caching), enforcing assigned priorities to different LUN classes, enforcing a desired read command latency, and the like. The policy engine 146 thus can correlate the I/O load characterization with the predefined performance parameters 154 to define the rules for flushing the cache 126. Additionally, the parameters 154 can include system condition information. For example, a power supply indicator may inform the policy manager 146 that the computer system 100 has switched to a backup battery power source. In this condition the policy manager 146 can respond by implementing contingencies to aggressively flush the cache 126 because of the limited power availability. The parameters 154 can also include the state of pending background I/Os, meaning I/Os that are not directly involved with executing access commands.
For purposes of this example,
In block 162 the particular policy manager 146 considers the next I/O command received from the network. In block 164 the policy manager 146 defines which storage devices (D1-D6) are necessary (the “set”) to execute this I/O command, and at what voltage levels the set is necessary to execute the I/O command. Instead of operating on its individual storage devices 132, the power manager 146 advantageously increases the amount of power to the entire set of storage devices D1-D6 only if a predetermined condition is met. For example, the power manager 146 increases power levels to each storage device D1-D6 in the set if a sum of the increased amount of power to the set and the amount of power already being supplied to another server 104 is less than T.
Assume for the example of
In block 166 the particular policy manager 146 determines whether Ptot is less than the predetermined T. If the determination of block 166 is “no,” then the I/O command (sometimes referred to as “access command”) considered in block 162 remains cached in block 168. However, if the determination of block 166 is “yes,” then in block 170 the power manager 146 switches the power to enable the set derived in block 164. The I/O command considered in block 162 is flushed to the command queue 128 in block 172. The command queue 128 is continuously executed in blocks 174, 176 until empty.
The particular policy manager 146 can continuously flush the cache 126 in view of the current power settings, as depicted by input 178 and flushing stream 180. Otherwise, aged access commands in the cache 126 can be re-evaluated via control branch 182. The Ptot and T are periodically evaluated in block 184, in view of any changing parameters. Ptot can be decreased, for example, if the current parameters allow and/or a particular storage device D has been unused at its present power setting for longer than a predetermined time. In any event, control then passes back to consideration of the next I/O command in block 162, whether it be from the network or the cache 126.
Although not depicted in
Embodiments of the present invention can be commercially practiced in a Spectra Logic T-950 tape cartridge library manufactured by Spectra Logic of Boulder Colorado.
It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with the details of the structure and function of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, multiple write commands can be simultaneously interleaved by the path controller 112 in performing the I/O command throughput for example, while still maintaining substantially the same functionality without departing from the scope and spirit of the claimed invention. Another example can include using these techniques across multiple libraries, while still maintaining substantially the same functionality without departing from the scope and spirit of the claimed invention. Further, though communication is described herein as between a host and the tape library, communication can be received directly by a tape drive, via the fabric interface for example, without departing from the scope and spirit of the claimed invention. Further, for purposes of illustration, a tape drive and tape cartridges are used herein to simplify the description for a plurality of drives and tape cartridges. Finally, although the preferred embodiments described herein are directed to tape drive systems, and related technology, it will be appreciated by those skilled in the art that the claimed invention can be applied to other systems, without departing from the spirit and scope of the present invention.
It will be clear that the claimed invention is well adapted to attain the ends and advantages mentioned as well as those inherent therein. While presently preferred embodiments have been described for purposes of this disclosure, numerous changes may be made which readily suggest themselves to those skilled in the art and which are encompassed in the spirit of the claimed invention disclosed and as defined in the appended claims.
It is to be understood that even though numerous characteristics and advantages of various aspects have been set forth in the foregoing description, together with details of the structure and function, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.