Includes a configuration advisor and a run-time tiering mechanism. The advisor uses a storage workload trace to estimate the capacity required in each tier during each time period, assuming that the run-time mechanism is moving each extent to the lowest cost tier that can satisfy the extent's I/O requirements during each epoch. The advisor recommends provisioning according to the maximum demand at each tier over all epochs. Epochs are assumed to be minutes/hours in duration. At run-time, a dynamic tier manager adjusts the placement of extents after each epoch. It choose a tier for each extent that will minimize power consumption, amont tiers that can satisfy the performance extent's performance demands. Within a tier, it also assigns extents to specific devices, attempting to consolidate so that devices can be powered down. Necessary migrations are then scheduled to run gradually.

Describes a system that uses database query execution plans, storage layout and storage system configuration to attempt to pinpoint the cause of performance problems (e.g., slow queries) in a DBMS plus storage system stack.

Mechanism for proportional allocation of storage server bandwidth among multiple storage clients. Each client observes server response times to detect overload conditions, and then throttles it request stream by an amount determined by the share it expects to receive.

Considers how to apportion database and storage server buffer cache space and storage system bandwidth across multiple workloads.

Allocation of buffer space in the face of a multi-class workload with QoS (mean response time) requirements for each class. Dynamic algorithms.

Enforcement of SLOs for disk. SLOs are load/response time curves for reads and writes. Enforcement mechanism throttles requests from hosts to storage devices. Assumes offered loads are feasible for the underlying storage devices. Uses real-time scheduling (EDF) to put requests into device queues so that deadlines targets are met. Device queue lengths are managed with feedback control.

Given workload, configure block-level storage system. Workload is described as stores (logically contiguous set of blocks) and streams (details in [veke01]). Workload analysis tool can produce stream-based workload description from a request trace. A configuration consists of number of disks, grouping of disks into arrays, division of arrays into logical units, disk controller and cache settings, and a mapping of the stores in the workload onto the logical units. Includes a migration component to move the storage system between configurations. Details of configuration finder are in [anka01]. Iterative approach does not assume that workload remains constant as the system configuration changes.

Input includes a workload description in terms of, logical stores and streams of accesses to the stores, a description of the available physical devices, a set of constraint on how those devices may be configured, maximum utilizations, or total system cost, and finally a cost function that can be used to compare alternative configurations. The output includes a grouping of devices into RAID logical units (LUs) and settings for configuration parameters, such as stripe sizes. Search through the design space is heuristic. Cost functions are externally defined, so the system cannot exploit their structure to improve the search.

Provides an historical overview of an HP effort in automated storage system management. Provides examples of specification language used to describe workloads and system configurations.