Anchor: A Stable Matching Framework for Managing Cloud Resources
Modern data centers heavily rely on virtualization to flexibly multiplex different applications onto physical servers, in order to efficiently utilize their resources. With virtualization, applications are packaged and run in the form of virtual machines (VM) that share the server infrastructure. Due to the multi-tenant nature of such virtualized data centers, resource management becomes a major challenge for cloud operators to achieve economies of scale. VMs impose extremely diverse resource requirements that need to be accommodated, as they run completely different applications owned by different clients. As such, they are entitled to distinct resource management policies depending on specific needs of their owners.
On the other hand, the infrastructure is managed as a whole by the cloud operator, who relies on a common resource management substrate, and has a wide variety of its own objectives to achieve, such as workload consolidation, cost minimization, and load balancing. Therefore, the resource management substrate must accommodate and orchestrate the needs and interests of both cloud operators and clients. However, current solutions provided by virtualization vendors are far from satisfactory: they are proprietary, hard-coded, and not easily customizable. There exists no interface for cloud clients to express resource management needs in their applications.
In this work, we present Anchor, a new architecture that decouples policies from mechanisms when it comes to managing resources in the cloud. Stakeholders in the cloud, including both cloud operators and their clients, are able to express and configure their high-level resource management policies, based on performance, cost, and network load, as they deem fit. These policies serve as input to guide mechanisms that manage cloud resources, so that conflicts of interest among stakeholders can be resolved. The output is a mapping between VMs and physical servers: Anchor allocates VMs to servers before they are run, and, if necessary, migrates running VMs away from their original hosts using live VM migration. Anchor is designed to be scalable to support hundreds of thousands of VMs and servers, to be expressive so that clients and operators can specify a wide variety of their policies and preferences with ease.
Our design of the Anchor architecture is based on a stable matching framework from economics theory, which elegantly and efficiently addresses common and conflicting interests of agents in a resource market. In our framework, the concept of preferences is used to express various high-level policies that stakeholders specify, and, rather than optimality, stability is used as the central solution concept of the matching mechanism. Merits of the stable matching framework lie in its com- petitiveness of outcomes, generality of preferences, efficiency and simplicity of its algorithmic implementations, and most importantly, its overall practicality.
The Anchor architecture consists of three main components: a resource monitor, a policy manager, as well as a matching engine, as shown below. The cloud operator configures resource management policies as input to the policy engine. When requests for allocating a new VM or migrating an existing VM arrive, Anchor assumes that detailed information about VM configurations and its own policy goals is available at the time. The policy manager then queries information required by both operator and client policies from the resource monitor, which maintains resource usage information through the management API, and translates these high-level objectives into preferences for the VM. It also configures server preferences in a similar manner. These preferences are fed into the matching engine that runs our stable matching mechanism. The highlight of our matching engine is a new multi-stage deferred-acceptance algorithm that matches multiple VMs of heterogeneous resource demands to a single physical server, corresponding to a many-to-one stable matching problem with size heterogeneity. The result determines the final matching between VMs and servers, and is executed through the management API.
The Anchor paper is currently under submission. A preprint of the paper will be made available upon request.
