As you may know, OpenNebula’s approach to cloud bursting (that is, its hybrid cloud model) is quite unique. The reason behind this uniqueness is the transparency to both end users and cloud administrators to use and maintain the cloud bursting functionality.

The transparency to cloud administrators comes from the fact that a an AWS EC2 region is modelled as any other host (albeit of potentially a much bigger capacity), so the scheduler can place VMs in EC2 as it will do in any other local host. Of course, the scheduler algorithm can be tuned so the EC2 host (or hosts, more on this below) is picked last, so it will be only used only if there is a real need (ie, the local infrastructure cannot cope with the demand). On the other hand, the transparency to end users is offered through the hybrid template functionality: the same VM template in OpenNebula can describe the VM if it is deployed locally and also if it gets deployed in Amazon EC2. So users just have to instantiate the template, and OpenNebula will transparently chose if that is executed locally or remotely. Very convenient, isn’t it?

An example of an (simplified, yet valid) hybrid template:

CPU      = 0.5
MEMORY   = 128

# Xen or KVM template machine, this will be use when submitting this VM to local resources
DISK     = [ IMAGE_ID = 3 ]
NIC      = [ NETWORK_ID = 7 ]

# EC2 template machine, this will be use wen submitting this VM to EC2
EC2 = [ AMI="ami-00bafcb5",
        KEYPAIR="gsg-keypair",
        INSTANCETYPE=m1.small]

In the new OpenNebula 4.4 (beta 2 version has just been released), these drivers have been vastly improved. For starters, the underlying technology has been shifted from using Amazon API Tools, which basically spawned a Java process per operation, to the new AWS SDK for Ruby. This means a much better improvement and resource usage in the front-end. Moreover, it is possible now to define various EC2 hosts to allow OpenNebula the managing of different EC2 regions and also the use of different EC2 accounts for cloud bursting. In this new model, these different hosts can model the same region, but with different capacities.

Functionality is also richer in the EC2 drivers in OpenNebula 4.4. There is support to define EBS optimized VMs, to define VM tagging, etc. It is also important to highlight the improvement made in monitoring, with a whole new set of information retrieved from the Amazon EC2 VM instances (see Hybrid Cloud/Cloudbursting section in Compatibility guide). For instance, these improvements makes possible to support Amazon EC2 VMs in Virtual Private Cloud (VPC). There has been also huge improvements regarding monitoring performance, with information from all the VMs gathered in the same call.

There is still a chance to influence the final OpenNebula 4.4 release. If you have any comments on this, please let us know through the mailing list.

We want to thank the awesome feedback received from the community, as well as patches provided by users running OpenNebula in large scale deployments, using an active cloud bursting model.