An interposed 2-Level I/O scheduling framework for performance virtualization

Networked storage and large disk arrays are enabling consolidated storage systems. While such consolidation is attractive economically, sharing of the underlying storage infrastructure can lead to interference between the different applications/users and possible violation of performance-based service level objectives (SLO). The data centers aim to insulate the users from each other (i.e., referred to as performance virtualization), giving each user the impression that the storage utility is dedicated to them. Several approaches exist for performance virtualization. We categorize them as: (1) schemes that use a proportional bandwidth sharing paradigm, such as SFQ(D), FSFQ(D) [3], and CVC [2]; and (2) schemes that use feedback-based control, such as Triage [4], SLEDS [1], and Facade [5]. These schemes have various advantages, but suffer from one or more of the following drawbacks: (i) rely on a fairly detailed performance model of the underlying storage system to estimate the service time of an individual request [2, 3], (ii) couple rate and latency allocation in a single scheduler making them less flexible [2, 3], (iii) may not always exploit the full bandwidth offered by the storage system [1, 4], or (iv) may not provide good performance isolation in the overloaded situations [5]. Our scheme aim to provide both throughput and latency guarantees, because each of them is critical to many (if not all) applications. We propose an interposed 2-level scheduling framework that separates rate allocation from latency control rather than couple them together. In our system, incoming I/O requests are classified into different classes, with an SLO pre-determined for each class. Without loss of generality, we assume that each user belongs to a different class. The SLO is a tuple for each class. R represents the maximum arrival rate with a latency guarantee D for a given class. If the arrival rate for that class is higher than R, then its throughput should be at least R, but there is no latency guarantee. In our approach, we use a statistical latency guarantee, that is the SLO requiring x% (95% in our evaluation) of all requests to be bounded by a latency of D. This SLO is enforced in each time