Login

Development and Evaluation of an OpenStack Extension to Enforce Cloud-wide Multi-resource Fairness during VM Runtime

BA
State: completed by Stephan Mannhart
Published: 2015-10-14

The thesis goal is to develop and evaluate an OpenStack extension that gathers information about the resource utilization of VMs during runtime and aggregates this information to a "cost" for each user, which is then announced to the hosts, such that these can prioritize VMs of modest users.
Therefore, the extension shall provide an API to configure the applied cost metric. The extension has to collect the resource utilization information of each VM in the entire cloud at least every 10 seconds (intervals of 1 second 3
are preferable) to feed this information to the cost metric. If the cost metric allows, it shall be applied by individual hosts to the resource utilization information of their hosted VMs and only the result announced, as this increases decentralization. Also, the aggregation process shall operate decentralized, if the OpenStack architecture allows. If a centralized implementation is chosen, arguments have to back this choice. To reallocate resources, methods have to be chosen, that ensure that resources are not idle, if requested, i.e., reallocation has to happen by prioritization and soft limits instead of hard limits. Secondary goals are to keep the extension’s number of dependencies and performance overhead low and its number of supported hypervisors high (e.g., by deploying the libvirt API).
The extensions functionality has to be proven by experiments, which have to show that VMs of modest consumers receive higher priorities. To show that these priorities actually materialize in terms of performance changes of VMs, benchmarks have to be executed on the VMs, to show that VMs of modest consumers achieve higher benchmark scores, compared to when the extension is not implemented. By the same methodology, it has to be shown, that the extension does not impede performance, in uncontended clouds, i.e., that VMs achieve the same benchmark score, with and without the extension, when no resource is under contention. Other methods to prove the extensions functionality can be suggested.

70% Implementation, 20% Design, 10% Documentation

Supervisors: Patrick Poullie

back to the main page