Check out the new USENIX Web site. next up previous
Next: Local Constraint or Surplus Up: A Model-Based Allocator Previous: A Model-Based Allocator

Generating Initial Candidates

To avoid searching a complex space of resource combinations to achieve a given performance goal, Candidate follows a simple principle: build a balanced system. The allocator configures CPU and storage throughput ($\phi $) allotments around a predetermined average utilization level $\rho_{target}$. The $\rho_{target}$ may be set in a ``sweet spot'' range from 50-80% that balances efficient use of storage and CPU resources against queuing delays incurred at servers and storage units. The value for $\rho_{target}$ is a separate policy choice. Lower values for $\rho_{target}$ provide more ``headroom'' to absorb transient load bursts for the service, reducing the probability of violating SLA targets. The algorithm generalizes to independent $\rho_{target}$ values for each (service, resource)pair. ,

The Candidate algorithm consists of the following steps:


  
Figure: Using Candidate and LocalAdjust to determine memory and storage allotments for a service. As service load ($\lambda $) increases, Candidate increases the storage share $\phi $ to meet response time targets. After encountering a resource constraint at $\phi = 200$ IOPS, LocalAdjust transforms the candidate allotments to stay on target by adding memory instead.
\begin{figure}
\centerline{\epsfig{file=onesvc.eps, width=\figwidth}}
\end{figure}

Note that the candidate M is the minimum required to meet the response time target. Given reasonable targets, Candidate leaves memory undercommitted. To illustrate, Figure 5 shows candidate storage and memory allotments $[M, \phi ]$for an example service as offered Web load $\lambda $increases along the x-axis. Candidate responds to increasing load by increasing $\phi $rather than M. This is because increasing $\lambda $ does not require a higher hit ratio H to meet a fixed response time target. For a fixed M and corresponding H, $\lambda _S$ grows linearly with $\lambda $, and so the storage allotment $\phi $ also grows linearly following $\lambda_S/\phi = \rho_{target}$.

Figure 5 also shows how the provisioning scheme adjusts the vectors to conform to a resource constraint. This example constrains $\phi $ to 200 IOPS, ultimately forcing the system to meet its targets by increasing the candidate M. Candidate itself does not consider resource constraints; the next two primitives adapt allotment vectors on a local or group basis to conform to resource constraints, or to allocate surplus resources to improve performance according to system-wide metrics.


  
Figure: Memory allotments by GroupAdjust for four competing services with different caching profiles (left) and different request arrival rates (right).
\begin{figure*}
\parbox{\columnwidth}{\epsfig{file=mem_4_svcs.eps, width=\column...
...\columnwidth}{\epsfig{file=lambda_4_svcs.eps, width=\columnwidth}}
\end{figure*}


next up previous
Next: Local Constraint or Surplus Up: A Model-Based Allocator Previous: A Model-Based Allocator
Ronald Doyle
2003-01-20