Alok's Blog

Cloud with Eucalyptus

What is Eucalyptus

In the previous article, Learn about cloud computing we introduced the basics of cloud computing and we discussed how clouds are classified according to service offerings or “styles” (i.e., IaaS, PaaS, SaaS) and “types” (i.e., public, private and hybrid). In this article we introduce the Eucalyptus cloud computing platform.

Eucalyptus enables the creation of on-premise private clouds, with no requirements for retooling the organization’s existing IT infrastructure or need to introduce specialized hardware. Eucalyptus implements an IaaS (Infrastructure as a Service) private cloud that is accessible via an API compatible with Amazon EC2 and Amazon S3. For more information on our API see our Developer’s Corner. This compatibility allows any Eucalyptus cloud to be turned into a hybrid cloud, capable of drawing compute resources from public cloud. And Eucalyptus is compatible with a wealth of tools and applications that also adhere to the de facto EC2 and S3 standards.

Here are some of the characteristics that make Eucalyptus the most widely deployed cloud platform for the private (on-premise) cloud:

Open Source
Eucalyptus is open source: if you want to modify it, contribute to it, assess its security or just learn from it you can donwload it and have the source code at your fingertips. The Eucalyptus development process is in the open, as are bug reports, community contributions and security advisories.
Eucalyptus’ design is modular. The Eucalyptus components have well-defined interfaces (via WSDL, since they are web services) and thus can be easily swapped out for custom components.
Eucalyptus allows its components to be installed strategically close to the needed/used resources. For example Walrus can be installed close to the storage, while the Cluster Controller can be installed close to the cluster it will manage.
Designed to Perform
Eucalyptus was designed from the ground up to be scalable and to achieve optimal performance in diverse environments (designed to overlay an existing infrastructure).
Eucalyptus is flexible and can be installed on a very minimal setup. Yet it can be installed on thousands of cores and terabytes of storage. And it can do so as an overlay on top of an existing infrastructure.
Eucalyptus is compatible with the most popular and widely used Cloud API currently available: Amazon EC2 and S3. Eucalyptus’ design allows for any other API to be implemented, but to date no other real Cloud API contender is as complete and as requested as Amazon’s.
Hypervisor Agnostic
Eucalyptus is designed to easily support most available and future hypervisors. Currently Eucalyptus fully supports KVM and Xen. Additionally, the Enterprise Edition supports the proprietary VMware hypervisor.
Hybrid Cloud
All of the above characteristics makes Eucalyptus easy to deploy as an hybrid cloud. An hybrid cloud combines resources drawn from multiple clouds, typically one private and one public. Eucalyptus compatibility with Amazon’s EC2 API allows for a natural hybrid cloud with the biggest public cloud available.

History of Eucalyptus

Eucalyptus was born as a University project in the MAYHEM labs of the Computer Science Dept. at UC Santa Barbara. The MAYHEM team’s experience in Grid Computing, HPC, and massively scalable systems (Rich Wolski’s team of NWS and EveryWare fame) made it the natural place for the birth of Eucalyptus.

The name EUCALYPTUS is an acronym and stands for Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems. A brief description of this period can be read here. This is of course no coincidence as UCSB is a leading University in Cloud Computing research.

In 2009, the Eucalyptus team started a company (Eucalyptus Systems Inc.) to commercialize Eucalyptus. Currently there is Eucalyptus, the open source project, and Eucalyptus EE (Enterprise Edition), which is the commercial version of Eucalyptus.

Next Steps

Our talented development team has made installing Eucalyptus easy, but some planning is still required (e.g., Where is the storage for Walrus/S3? What about the storage and network for EBS? How many public IPs can Eucalyptus use? Is there a private network for the Node Controllers? How big will my cloud grow?). These questions are a normal part of the planning process that IT goes through in order to appropriately size the infrastructure for a deployment. Before embarking on a full-scale deployment we suggest familiarizing yourself with Eucalyptus by:

  • TestDrive our community cloud (ECC);
  • Reserve few machines, and follow our documentation in particular the administrator’s guide, to install Eucalyptus on your favorite distribution.

Our forum are always available if you need additional help. Or explore other ways to participate in our community.

Case Study: Installing the Eucalyptus Community Cloud (ECC)

This article describes the steps taken by the Eucalyptus team to setup the Eucalyptus Community Cloud (ECC). The ECC is a sandbox environment in which members of our community can testdrive and experiment with the Eucalyptus cloud computing platform. The ECC resides at the Coresite data center facility in Los Angeles, is hosted on HP servers, and has one uplink to the Internet provided by Inforelay.

Physical hardware layout

The ECC is a good example of a standard installation of a Eucalyptus cloud, intended for multiple users with very different needs. We begin with a look at the physical hardware layout supporting the ECC. The ECC shares this hardware with other Eucalyptus services, including the Eucalyptus Partner Cloud, and the Eucalyptus QA system, which tests cloud deployment and functionality. In Figure 1, we see how the two NICs of each blade server connect to separate switches, and these switches connect to a managed switch that controls access to the Inforelay uplink.

Figure 1. ECC Physical Hardware Layout (Each HP SL2x170z chassis contains 4 blades. Please note that our diagram is simplified for clarity to show connections from one blade per chassis).

The servers offer Lights Out Management (LOM), which lets us connect to the servers remotely under all circumstances. Each blade server contains two 500GB disks, the latest quad-core processors, and plenty of RAM to handle instances. As we shall see, having two disks in each blade server is very handy when installing the Eucalyptus Node Controller (NC) component. The network fabric is a twisted pair gigabit network, while the uplink is 100Mbit.

Network configuration

Next, we describe how we configured the network. In Figure 2, we see that only one blade server has been given direct Internet access, while all other blades connect to a common private network. In this case, the private network is configured to be 192.168.253.x. The LOM has its own private network, which is independent and guarantees access in case of network misconfiguration.

Figure 2. ECC Network Configuration

Installing Eucalyptus components

Now we examine the actual installation of Eucalyptus components. If you have read the Eucalyptus Installation Guide, you may already have an idea where we are going to install each component: The blade with Internet access hosts the Cloud Controller (CLC), Walrus, Storage Controller (SC), and Cluster controller (CC), while the other blades host NCs. We decided to install Eucalyptus from source instead of packages, since the ECC may at times be using some experimental code, and installing from source makes it easy to redeploy single components. (For more information on installing from source, see our Installing Eucalyptus from Source instructions). Figure 3 shows the location of installed Eucalyptus components in context of the ECC’s logical network configuration and underlying physical hardware layout.

Figure 3. Installed Eucalyptus Components

Eucalyptus abstracts away the hypervisor and underlying configuration, so the end user’s experience is entirely independent from the infrastructure configuration implemented by the cloud administrator. (Please see our User’s Guide for information on interacting with a Eucalyptus cloud). There are ways however for curious-minded users to determine which hypervisor is being used to run your virtual machine.

File system layout

We installed Eucalyptus on the blade server with Internet access, in /opt/eucalyptus-<version-number> so that new upgrades will have their own directory. And we used symbolic links to point /opt/eucalyptus to the current installation. We put the EBS volumes on one disk, and Walrus’s buckets directory on the other, to maximize disk space. To achieve that we used symbolic links for the volumes and buckets directories in /opt/eucalyptus to point to the real locations on the different disks. Once Eucalyptus was compiled and installed, since all the blades have the same architecture, we simply rsync’ed /opt/eucalyptus-<version-number> to all the NCs.

On the NCs we used the two disks to minimize instance start-up time: The Eucalyptus NC caches the emi (eucalyptus machine image) the first time it sees it, so that subsequent instances start faster. But we still need to create a copy of the pristine emi that the instance can modify at will. This disk-to-disk copy can be fairly expensive (multi GB transfers are never easy), so we put the cache on one disk, and the instances images on the other disk. Eucalyptus creates a ‘eucalyptus’ directory under $INSTANCE_PATH (the directory that holds instance images and cache) to hold the cached images; we simply use the symbolic link to point the directory to the second disk, thus ensuring that the images copy across disks.

Eucalyptus Network configuration

With the low level details out of the way, and Eucalyptus installed on all machines, we can finally finish the configuration: The blade server got its final public IP (which is currently or, while all the other blades (using the second NIC on the blade server) got configured on the private network (192.168.253.x in this case). We reserved as many public IPs as possible to be used with the ECC and with that we were ready to configure Eucalyptus network.

While the managed switch uses VLANs, the switches for our private network do not. Thus, being VLAN clean, we chose MANAGED mode as our Eucalyptus networking mode. We gave Eucalyptus the entire 10.x.x.x range to allow for a large number of security groups. (For an overview of MANAGED mode, and how to calculate available security groups, see our Eucalyptus Network Configuration guide).

Eucalyptus configuration

With the Network configuration complete, we were left with the NC configuration. On the NCs we checked that the hypervisor and libvirt were properly configured and we setup the $INSTANCE_PATH directory as mentioned above. Finally we started and registered the components as described in the Installation and Configuration sections of the Eucalyptus Administrator’s Guide.

Deploying virtual machines

Our final step is to test the ECC: We uploaded one of our pre-packaged images, uploaded the appropriate kernel and ramdisk for it, and ran a set of instances. We made sure to run enough to cover all nodes, to ensure that all the NCs were properly configured, which, as an added benefit, populated the cache with the image, thus speeding up the launching of future instances.

Learn more about the Eucalyptus Community Cloud (ECC)
Read the Eucalyptus Installation Guide
Read the Eucalyptus Administrator’s Guide



Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: