Introduction

CloudVAMP is currently being used in the OpenNebula-based on-premises Cloud deployments at the GRyCAP at the Universitat Politècnica de València. It is being used to introduce vertical elasticity, in the shape of automated memory management, for the elastic virtual clusters that support the job executions incoming from the es-NGI Grid infrastructure. The working nodes are automatically provisioned with a certain amount of memory and CloudVAMP dynamically manages the memory size allocated to the VMs, thus being able to deploy additional working nodes per physical node.

The CloudVAMP work is described in the following publication, which includes a further elaboration of the case studies described here:

Germán Moltó, Miguel Caballer and Carlos de Alfonso. Automatic Memory-based Vertical Elasticity and Oversubscription on Cloud Platforms. Future Generation Computer Systems. DOI: 10.1016/j.future.2015.10.002


Fully Elastic Virtual Clusters for Grid Infrastructures

In this case study, the effectivity of introducing vertical elasticity in the shape of dynamic memory management within the es-NGI infrastructure is assessed. CloudVAMP was introduced into an OpenNebula Cloud, and recorded data from a representative workload that arose from different real jobs in a period of 12 hours, distributed in three physical hosts with 16 GB of RAM (niebla02, niebla03 and niebla04) and one physical host with 64 GB of RAM (niebla13).

Figure 1 summarises the evolution of the memory reclaimed (stolen memory) in such hosts by CloudVAMP. CloudVAMP is able to free memory from the VMs by adjusting their allocated memory to the real memory requirements of the VM.

The Table 1 describes a comparison between the physical memory of the hosts and the average of the resulting stolen memory.

Fully Elastic Virtual Clusters for Grid Infrastructures

Fully Elastic Virtual Clusters for Grid Infrastructures

Preventing Memory Overload via Live Migration

We introduced CloudVAMP into a multi-tenant scenario based on Docker containers to automatically manage the allocated memory to the VM (or a set of VMs) according to the memory used by its active containers.

The Figure 2 summarises the experiment where the memory allocation of the VM hosting different Docker containers is described. The memory consumption profile varies due to a sequence of events (from A to H) which introduced memory overload in such scenario. In more detail, such profile indicates how CloudVAMP detects indistinctly both 1) free memory and decides to reduce allocated memory (e.g. from A to B); and 2) demands of additional memory and increases the allocated memory to the VM (e.g. from C to H). In particular, at instant 1:10:36 CloudVAMP cannot allocate additional memory to the VM because the host becomes overloaded, in terms of memory. For these cases, CloudVAMP live migrates the VM with the least amount of allocated memory to prevent as fast as possible the memory overload situation. In this way, in G,

a VM other than the one considered is migrated away from the physical host in few seconds. Thus, at instant 1:11:09 (H) the VM can now be allocated more memory to comply with the increasing memory requirements of the application.


Tel: (+34) 963 87 70 07 Ext. 88254
Camino de Vera Road, Building 8B, Door N, 1st Floor,
Valencia City, Valencia 46022



Copyright © 2015, GRyCAP-I3M-UPV, Universitat Politècnica de València - 46022, Valencia, Spain