Datacenter Location Aware Elasticity

Introduction

 

The main characteristics of Cloud Computing are: a pay-­as-­you-­go model, provision of raw capacity, and elasticity. However, the possibility to allocate resources in multiple clouds opens up avenues to a new type of elasticity based on where the new capacity is allocated, that is, the location­-aware elasticity.

This is a generic use case that represents a class of applications that are able to allocate functional components close to the client requests to improve performance, or because of security or jurisdictional constraints. In general, these components should be able to communicate through public networks, and so being able to tolerate long latencies. As a paradigmatic example, we will consider a content distribution system able to allocate access servers on specific geographic locations in order to address increasing amount of client requests in that area (e.g. country specific marketing campaigns or release of new media).

The elements of the BEACON framework used to implement this use case are OpenNebula (with modifications made in the context of the BEACON project, especially in OneFlow), the Federation Agent and the BEACON network manager.

Deployment

Initially the system is deployed in a private cloud, where the original content is developed and stored. At a given time the load of the application is expected to increase in a specific geographical area. This process fires the allocation of a new component in a public cloud located closer to the clients, so effectively reducing the latency of the application and improving the user experience. This is achieved using the elastic features of OneFlow coupled with the federated network managed by the BEACON Network Manager.

 

Use Case Architecture

The contents of the application are basically static and distributed through standard web mechanisms; so new web servers can be allocated in any location provided they have access to the content. Typically, to improve performance access to the content database a distributed memory object caching system should be considered. Note that the redirection to the best server can be implemented through custom DNS A-name records or with the GeoDNS extension.

Web servers, DB caches and DB servers need to communicate through a secure virtual LAN. This LAN has to dynamically grow to multiple locations and additionally control and monitor traffic for the application components.

 

Use Case Deployment

The needed LAN is created using an L2 overlay across different network segments in different datacenters (using the OpenNebula 2 OpenNebula drivers) or clouds (using the Amazon EC2 hybrid connector from OpenNebula). The BEACON network manager is the component that creates and manage the lifecycle of the federated network in the BEACON framework.

Using OneFlow elasticity features, coupled with federated networks (both part of the BEACON framework) it is now easier than ever to construct this very interesting type of services, that can grow on demand in those geographic areas that have peak demands.

Conclusion

The features introduced by BEACON in the OneFlow component of OpenNebula, as well as the federated network capabilities provided by the BEACON framework, enables this interesting use case which greatly reduces the latency of services deployed in the cloud, allowing them to grow in a localized manner close to the end customer.

The source code for the BEACON framework can be found on Github