Docker containers wrap up a piece of software together with everything it needs for the execution and enable to easily run it on any machine. For their execution in the Cloud, we need to identify an elastic set of virtual machines that can accommodate those containers, while considering the diversity of their requirements. In this paper, we briefly describe our formulation of the Elastic provisioning of Virtual machines for Container Deployment (EVCD), which takes explicitly into account the heterogeneity of container requirements and virtual machine resources. Afterwards, we evaluate the EVCD formulation with the aim of demonstrating its flexibility in optimizing multiple QoS metrics.
Docker1 containers enable to package an application together with all of its
dependencies and then run it smoothly in other environments. They exploit the
operating system level virtualization, therefore multiple containers can co-exist
and run in isolation on the same machine, thus improving resource utilization.
Diferently from virtual machines, containers are lightweight [
In this paper, we investigate the problem of deploying containers in the
Cloud. Specifically, we evaluate EVCD [
This paper is organized as follows. We review related work in Sect. 2 ; in Sect. 3 we describe the system model and the problem under investigation, before formulating EVCD as an Integer Linear Programming problem in Sect. 4 . We evaluate the flexibility of EVCD in Sect. 5 and conclude in Sect. 6 . 2
In literature a limited number of works provides a formal definition of the
allocation problem for containers; however, due to NP-hardness of the problem,
many heuristics have been proposed. As regards the modeling, in [
The existing heuristics aim at optimizing a diversity of utility functions,
namely fairness, load balancing, network trafic, or energy consumption. The
fairness of resource allocation is considered in [
Docker Swarm5) usually bundle simple scheduling heuristics and also enable
the execution of custom policies. Among the most common heuristics, we can
ifnd the round-robin policy, which tries to evenly use resources, and well-known
heuristics that solve the bin packing problem, namely greedy best-fit and
firstift. Specifically, Docker Swarm, the oficial Docker component that allocates
containers on a centralized pool of resources, includes a bin packing policy and
a strategy that balances the number of containers among computing nodes.
In our previous work [
Devising an optimal container deployment strongly depends on the assumptions made about the domain it will be applied to. In this section, we provide a formal description of the domain entities: containers and virtual machines.
Software Container Model. A Docker container is an instance of an image, which represents a container snapshot and contains all the data needed for its execution. For eficiency reasons, an image is structured as a series of layers (e.g., libraries, custom files), where each one can be downloaded independently from the others. We define the set of containers as S. A container s ∈ S is characterized by the following QoS attributes: Cs, the number of required CPUs; Dssc, the startup time; Ms, the amount of required memory; and Is, the set of image layers needed for its instantiation. We assume Is ⊆ I, where I is the set of all the available containers images. Each image layer i ∈ I is characterized by the size of data li composing the layer.
Virtual Machine Model. A virtual machine (VM) hosts and executes containers with respect to its capabilities. Being a Cloud resource, a VM can be acquired and released as needed and paid for the amount of, albeit partially, consumed Billing Time Units (BTU). Finally, although in theory unlimited, we assume the number of leasable virtual machines to be limited in a certain time period. Let V be the set of all VMs, including the active (leased) ones and the leasable ones. A virtual machine v ∈ V has the following QoS attributes: Cv, the amount of available CPUs; Mv, the available memory capacity; DRv, the download data rate of v; Dvsv, the startup time; Pv, the cost per BTU; and Iv, with Iv ⊆ I, the set of image layers available in v without downloading them from an external repository.
Container Deployment Problem. To solve the deployment problem, we need to determine a mapping between the set of containers S and the set of virtual machines V in a such a way that all constraints are fulfilled. We investigate the initial deployment as well as its adaptation at runtime, therefore we solve EVCD periodically, every τ unit of time. We model the container deployment with binary variables xs,v, s ∈ S, v ∈ V : xs,v = 1 if s is deployed on v and xs,v = 0 otherwise. The variables zv denote whether v ∈ V is active and hosts
at least one container. Relying on the deployment configuration determined at time t − τ , we also define the following auxiliary binary variables: av, which indicates whether v ∈ V , turned of in t − τ , has to be activated in t; as,v, which indicates whether s is deployed on a newly activated virtual machine v (i.e., with av = 1); and δ s,v, which indicates whether, in t − τ , s ∈ S was not allocated or was allocated on u ̸= v, with u ∈ V . 4
In this section we present our formulation of EVCD (acronym of Elastic
provisioning of Virtual machines for Container Deployment) as an Integer Linear
Programming (ILP) model. Due to space limitations, we do not report the full
formulation of EVCD, which can be found in [
C(z) =
X Pvav + v∈ V
X v∈ V exp
Pvzv
D(x, z) − Dmin + wc C(z) − Cmin
F (x, z) = wd Dmax − Dmin Cmax − Cmin where wd, wc, with wd, wc ≥ 0, wd + wc = 1, are weights for the diferent QoS attributes, and Dmax (Dmin) and Cmax (Cmin) denote, respectively, the maximum (minimum) value for the overall expected deployment time and cost. Observe that these normalization factors can be computed by solving other optimization problems or can be approximated relying on previous experiments or on statistical analysis of the runtime execution. The overall deployment time D(x, z) accounts for the time needed to spawn new VMs, retrieve container images, and finally start the containers. It can be formally defined as:
D(x, z) = X X Dvsvas,v + s∈ S v∈ V
X i∈ Is\Iv
li DRv xs,v + Dsscδ s,v where Dvsv is the startup time of a new VM, considered only if a new one is needed, P li represents the time needed to download the images Is not yet on v, and Di ssDc Risv the startup time of s, if s was not already running on v. The cost C(x, z) includes the leasing of the new VMs and the renewing the expired ones which are still needed. Relying on the activation vector z and on the auxiliary variables av, we have that: (1 ) (2 ) (3 ) 2000 2500
Simulated Time (min) 500 1000 1500 3000 3500 4000 4500 (a) Number of active containers
Active Containers
EVCD_C EVCD_D EVCD_CD rse 40 n i tna 30 o foC 20 r be 10 m u N 0 s 10 M V 8 e v i tc 6 A fo 4 r bem 2 uN 0 0 0 where the first term on the right end side accounts for the cost of newly acquired VMs, and the second one accounts for renewing the expired leasings, if needed (i.e., if the related VM is still used). The set V exp ⊆ V includes the VMs whose leasing is going to expire between the current time t and the next execution of EVCD in t + τ .
The full optimization in [
To evaluate the EVCD model, we simulate its execution in a system that receives containers and allocates them on VMs. The aim of this experiment is to show the lfexibility of EVCD, which can elastically acquire and release VMs to host and execute software containers while optimizing the deployment time of containers, the cost of leased VMs, or a combination thereof.
We solve EVCD with CPLEX©6, the state-of-the-art solver for ILP problems, on a machine with 4 CPUs and 16 GB RAM. We simulate the execution of EVCD
every τ = 15 minutes. Each container requires unitary resources (i.e., CPU,
memory) and has a lifespan of L = 30 minutes. A container depends on a set
of image layers, whose cardinality is uniformly chosen between 2 and 4; this set
includes 70% of existing images (if any) and 30% of new images. Each image layer
has a size li uniformly defined in [200, 800] MB. The startup time Dssc of s ∈ S
ranges uniformly in [8.5, 11.5] s. Two type of VMs are available in V : type A with
4 CPUs, 16 GB of RAM, and Pv = 1; and type B with 8 CPUs, 32 GB of RAM,
and Pv = 1.7. Similarly to the most popular commercial solutions, the BTU is
60 minutes. The startup time Dvsv of v ∈ V ranges uniformly in [85, 115] s, in
accordance with [
We evaluate the efects on the containers deployment of three diferent configurations of EVCD, namely EVCD_C, EVCD_D, and EVCD_CD. EVCD_C deploys containers by minimizing, as QoS metric, the cost C(x, z), i.e., it solves EVCD with F parametrized with weights wc = 1 and wd = 0. EVCD_D minimizes the deployment time D(x, z), by solving EVCD with wd = 1 and wc = 0. Finally, EVCD_CD minimizes both the QoS metrics, by solving EVCD with wd = wc = 0.5, and normalization terms Dmin = 8.5 s, Dmax = 152.1 s, Cmin = 0, and Cmax = 10.1. These values result from preliminary experiments. Figure 1 b shows the number of active VMs during the experiment, whereas Table 1 reports the average values of the considered QoS metrics and the relative number of used VMs per type. From Fig. 1 b we can see that, although every configuration of EVCD acquires and releases VMs to satisfy the incoming load, each of them follows a diferent strategy. Diferently from the other configurations, EVCD_C tries to use as few VMs as possible and, if needed, prefers type B VMs (76.6% of the time, see Table 1 ), because of their economy of scale. However, this leads to the highest deployment time, which is higher then the optimal one of about 76% (see Table 1 ). EVCD_D neglects the diferences in terms of price between VMs of type A and type B, which are used almost equally. This strategy has the highest cost (29% higher than the optimal one), however it obtains the lowest
2000 2500 Simulated Time (min) 3000 3500 4000 4500 possible deployment time, because it allocates containers on VMs that already host some of the needed image layers, thus reducing the container startup time. EVCD_CD finds a trade-of between the previous strategies, as can be seen from Table 1 . It optimizes both the QoS metrics, achieving a deployment time and cost about 9% and 8% higher than the optimal values, respectively. Moreover, this strategy shows that, by selecting the weights of F according to the user preferences, EVCD can be aimed at optimizing diferent QoS metrics of interest. Observe that any other combination of weights wc, wd lead to configurations that lie in between EVCD_C and EVCD_D. Determining the best trade-of between deployment time and cost depends on the relative importance of these QoS metrics on the utilization scenario (e.g., diferent user preferences).
On EVCD Resolution Time. We now discuss about the resolution time of EVCD and its relationship with the optimization goals. We consider as resolution time the time needed to compute the exact solution of the ILP problem. During this experiment, the maximum number of managed virtual machines (both active and leasable) in V is 19, whereas the maximum number of active containers in S is 40. Figure 2 reports the resolution time of EVCD for the diferent configurations (i.e., EVCD_C, EVCD_D, and EVCD_CD) during the experiment. In general, we observe that the resolution time is influenced by the size of the problem as well as by the optimization function F resulting from the diferent set of weights. Optimizing a single QoS attribute, i.e., solving EVCD_C or EVCD_D, is less computationally demanding and has better performances; as can be seen from Fig. 2 , the resolution time of EVCD_C and EVCD_D is always below 1 s. Conversely, solving a multi-objective optimization problem is harder and produces higher resolution times with greater fluctuations with respect to the previous configurations. The complexity of CPLEX does not easily reveal the motivations behind the number and amplitude of these fluctuations. During the whole experiment, the 95th percentile of the resolution time for EVCD_C and EVCD_D is 189 ms and 33 ms, respectively, whereas EVCD_CD has a 95th percentile of about 24.6 s, i.e., two order of magnitude higher.
It can be demonstrated that the deployment problem is NP-hard (see [
In this paper we have described and evaluated EVCD, a formulation of the elastic provisioning of virtual machines for container deployment. EVCD is a general and flexible model that can be conveniently configured to optimize diferent QoS metrics. Aside computing the initial allocation, EVCD can adapt the containers deployment at runtime, if needed. The experimental evaluation has shown the lfexibility of the proposed model, which has optimized the deployment time of containers, the monetary cost for their execution, and a combination thereof. As future work, we plan to extend the formulation of EVCD to include other QoS attributes (e.g., network trafic, resource utilization) and the runtime replication of containers. Moreover, we plan to develop eficient heuristics to deal with large instances of the container deployment problem for the initial deployment and to support runtime reconfigurations.