Automated High Availability Across Datacentres  

Introduction

 

High Availability (HA) of a system is achieved by incorporating specific features to reduce service downtime, typically: failover, load balancing and replication. These techniques can be easily incorporated into services deployed on multi-data center clouds. To some extent, HA features are currently available on public cloud providers but seriously limited by networking constraints. This is a horizontal use case that accommodates any cluster, or multi-tier, application. For the sake of completeness we will consider a web application that combines all the techniques mentioned before. This particular example is considered general enough to cover a wide spectrum of applications, each one with its one architectural requirements.

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

Description

Using the BEACON framework, a HA service can be deployed in a breeze using the federated network mechanisms available in the BEACON Network Manager.

Once deployed, access to the HA service is performed typically through the Internet by means of a Domain Name System (DNS), via multiple A-name records for the service, to distribute the client calls across load balancers. When a load balancer fails web clients will retry using the next address returned by the DNS servers.

Load balancers redirect client requests to an application server to provide optimal performance, reacting to high load and failure conditions on the application servers. It is important to note that load balancers can make use of application servers from any datacenter. Finally, the application server process the request accessing the information stored in a database. The database component is usually deployed in a HA setup, implementing a replication mechanism.

All the previous components communicate through a private network that traverse all the datacenters used to deploy the application. The nature of the traffic is diverse, and depends on the techniques and technologies used to implement each functional block. For example, a master-slave replication at the database tier may require multicast UDP monitoring traffic to promote a slave in case of master failure, while the application servers usually use plain TCP connections to other components. Moreover, a common scenario is a component acquiring the IP address of failed component.

 

As mentioned before, this use case highlights an implementation pattern of a typical clustered service, however it is possible to further evolve this use case by adding more functional components like object caching servers (to speed-up DB access), HTTP caching servers (to speed-up application server access) or distributed file systems (to increase storage reliability).

Deployment with BEACON Components

Using either the OpenNebula hybrid federation with Amazon EC2, or the OpenNebula to OpenNebula drivers (developed within the BEACON project), two or more cloud infrastructures can be federated. An HA service can be defined using OneFlow, the OpenNebula component that allows the definition of services, that also count with BEACON developed extensions.

 

In order to count with a proper HA, data replication is a must. Hence, the other BEACON framework components used are the Federation Agent and the BEACON network manager. The former sustains a federated network joining two or more local network segments creating a L2 tunnel, while the latter offers the needed mechanisms to manage the lifecycle of a federated network, with permissions enforcement engine for security.

With these two main federation types (compute management and network), possible thanks to BEACON, deploying HA services is an easy and straightforward task.

Conclusion

Building HA services across datacenters is easier than ever with the BEACON framework. The Time to Market of this use case has been reduced by two orders of magnitude, thanks to the federated network capabilities that simplifies the service definition.

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