Fair, Fast and Frugal Large-Scale Matchmaking for VM Placement

Abstract

VM placement, be it in public or private clouds, has a decisive impact on the provider’s interest and the customer’s needs alike, both of which may vary over time and circumstances. However, current resource management practices are either statically bound to specific policies or unilaterally favor the needs of Cloud operators. In this paper we argue for a flexible and democratic mechanism to map virtual to physical resources, trying to balance satisfaction on both sides of the involved stakeholders. To that end, VM placement is expressed as an Equitable Stable Matching Problem (ESMP), where each party’s policy is translated to a preference list. A practical approximation for this NP-hard problem, modified accordingly to ensure efficiency and scalability, is applied to provide equitable matchings within a reasonable time frame. Our experimental evaluation shows that, requiring no more memory than what a high-end desktop PC provides and knowing no more than the top 20% of the agent’s preference lists, our solution can efficiently resolve more than 90% of large-scale ESMP instances within $N \sqrt{N}$ rounds of matchmaking.

Appendices

Appendix

A Implementation details

Our implementation is a rewrite of the one presented in [8], with a few changes and additions to suit our purpose. The source code can be found on GitHub: https://github.com/Renelvon/pesma-limit.

1.1 A.1 Languages and Frameworks

The original Java implementation was ported to C++11, as the later allows much greater precision in handling memory resources. We took care to make as much of the new code parallelizable and used the OpenMP framework to leverage any multicore power during instance generation, loading and solving.

1.2 A.2 Proposer selection

We propose a minor modification to the proposer-selection heuristic used in [8]: whenever all agents of one set are satisfied after some round, the other set is granted the proposer role in the next round. This ensures there will be some proposing action in all rounds save for the last one. It prevents idle rounds in large instances, and is especially impactful once only a few agents remain unsatisfied. Despite the tangible benefits, it is unclear whether this optimization may force the proposer-selection algorithm to fall in a periodic cycle, though none of our experiments indicate so.

1.3 A.3 Deterministic generation and subsetting

A problem instance generated by our framework can be reliably reproduced given the quintuple $(N, n, K, b, s, h)$, where $N$ is the number of agents per set, $n$ is the size of the reservoir used, $K$ is the length of the preference list, $b$ is a function mapping agents to positive weights (floating-point values), $s$ is an initial seed (64-bit integer) and $h$ is a hash function. We use the 64-bit Mersenne Twister (MT64) engine available in the Standard Library of C++11, a fast PRNG that guarantees long periods.

We generate a preference list as follows. First, we hash the global seed $s$ together with the agent id to create an agent-specific seed $s'$, with which we setup a MT64. We feed the engine and the function $b$ together with $N$ and $n$ to WRS and obtain a sample of suitors of length $n$, where $n \le N$. Each sampled suitor is paired with the weight which put them in the reservoir. As a last step, we extract the heaviest $K$ suitors (where $K \le n$) in the sample and place their ids in the preference list ordered according to their weight. Each agent’s list can be generated independently; our OpenMP implementation takes advantage of this.

Consider two instances occurring from the same $(N, n, b, s, h)$ but differring in the cut-off point: $K_1 < K_2 \le n$. The sampling phase is independent from $K$ and so will produce the same sample of length $n$ for any two agents with the same id. Since the suitors are placed in the preference list according to the order of their weights, the list of an agent in the $K_1$ instance will coincide with the first $K_1$ elements of the corresponding agent’s (longer) list in the $K_2$ instance. This effect enables us to generate instances that are proper subsets of other instances. We can thus study with great precision the effects of limiting the preference list at any desired fraction.

1.4 A.4 Compact representation of inverse map

The bulk of each agent’s dataset consists of two structures: the preference list, which contains the suitors in order of preference, and the inverse map, which maps a suitor’s id to their index in the agent’s preference list. When entire preference lists are used, the inverse map can be represented as a plain array. However, once the preference lists are trimmed, the array becomes sparse and it is wise to represent it as a static dictionary in order to save space. We explored several concrete implementations built around stl::unordered_map and boost::flat_map. The former one is very fast but the latter one achieves a much better balance between performance and memory consumption. For our experiments, we re-implemented boost::flat_map from scratch to reduce unnecessary overheads and augmented it with a summarizer cache that enables faster searches.