Frequently Asked Questions (1.0)

Is Eucalyptus a precise implementation of Amazon's EC2? ¶

No. Eucalyptus supports Amazon's interface syntactically and it implements the same functionality (with a few exceptions), but internally it is almost certainly different. Eucalyptus is designed to be extensible and easy to install and maintain, particularly in a research environment, where system administrator time is the most expensive commodity. While we can't be certain, Amazon's main design goal almost has to be scalability. Put another way, if we were to design a commercial software venue for cloud services where scalability is paramount and we could mandate how all clusters within the cloud were initially configured (instead of an open-source software tool for community distribution) we would have designed Eucalyptus differently.

Why choose Amazon's EC2 interface for Eucalyptus? ¶

The intention is to be able to support multiple cloud computing interfaces using the same "back end" infrastructure. EC2 seemed to be the best documented of the available choices at the time we began development and also the most commercially successful so we chose to implement it first. The interface module, however, can be replaced without changing the rest of the system (we hope).

Is Eucalyptus the product of a company? ¶

No. Eucalyptus has been developed in the MAYHEM Lab within the Computer Science Department at the University of California, Santa Barbara primarily as a tool for cloud-computing research. It is distributed as open source with a FreeBSD-style license that does not restrict its usage much. We hope that it fosters further interest and development, both scientific and commercial, in cloud computing.

Do Eucalyptus users need a credit card to access the system? ¶

No. In a commercial cloud, clients pay for their use with a credit card. Eucalyptus is designed to work in an environment where machines are available to a user community that accesses them via logins. Because user accountability usually must be ensured by the system administrators in such an environment, we have developed a "cloud administrator" interface for Eucalyptus that is more analogous to common practice in a setting without fees.

Cloud users must register with the cloud administrator using a Web-based sign-up page. The cloud administrator receives an email message requesting approval whenever a potential user requests access. The message contains links for approving or denying the request. The decision of the administrator is communicated to the requester via email. In the case of approval, the user will be able to obtain from a password-protected Web page the cryptographic certificates necessary for using Eucalyptus.

What software environments are supported? ¶

Eucalyptus 1.0 targets Linux systems that use Xen (versions 3.*) for virtualization. It is packaged for Rocks V as a "roll" -- an ISO disk image with RPMs and some metadata that Rocks uses for cluster-wide installation. The RPM works as a stand-alone package as well, but installation outside Rocks is not supported in version 1.0. The client-side tools are those that are provided by Amazon for use with EC2.

What happens when all virtual machine "slots" are allocated? ¶

The SLAs (Service Level Agreements) implemented by the cloud controller are bare-bones simple. Our intention is for Eucalyptus sites and development teams to come up with their own (we have a few in mind we'd like to try) but in the release of version 1.0, the simple SLAs supplied enforce no restrictions on occupancy duration. This type of SLA is comparable to the Amazon SLA with the exception that Amazon's will "time out" when charges to the registered credit card are no longer postable.

We have implemented no such time out analogy at present, so if users or the cloud administrator do not terminate running instances, eventually Eucalyptus will run out of VM slots to allocate. In this case, user requests fail and the EC2 tools report no instances available when the command "ec2-describe-availability-zones" is invoked.

What is an "Availability Zone" in Eucalyptus? ¶

Amazon implements "availability zones" to allow users some degree of control over instance placement. Specifically, EC2 users can choose to host images in different availability zones if they wish to try and ensure independent failure probabilities. Amazon, presumably, takes steps to insulate instances in separate availability zones from correlated failure (e.g., a single power outage that takes out a data center).

Under Eucalyptus, the abstraction is slightly different. Each availability zone corresponds to a separate cluster within the Eucalyptus cloud. The advantage is that the networking within a single availability zone can be made much faster (i.e., it uses the cluster's private network in native mode). For allocations that span clusters, the technology Eucalyptus uses to implement a private network for each allocation imposes a substantial performance penalty.

Thus the two are similar in that cloud allocations to separate availability zones do reduce the chance of correlated failure. They are different, however, in that under Eucalyptus, each availability zone is restricted to a single "machine" (e.g., cluster) where at Amazon, the zones are much broader.

Does Eucalyptus require Rocks? ¶

For the moment, the answer is probably "yes." There is nothing about the software itself that depends on Rocks. However configuring it for a particular installation is tricky. For Eucalyptus 1.0, we have written a set of Rocks scripts (that are included in the roll) that essentially query the local installation and generate the necessary configuration files for Eucalyptus. In some cases, the configuration files and where Eucalyptus puts persistent state it needs must be synchronized. By invoking the various scripts, Rocks handles the configuration automatically.

However, it can be done by hand and we are planning a stand-alone installation system in the near future. If you would like to use Eucalyptus and Rocks is not an option for you, please contact us and we'll try to help.

When will the source code be available? ¶

We have not released the code of version 1.0 because building and deploying this distributed system from source is too error-prone in its current state. That is likely to frustrate our early adopters, which we would like to avoid. A binary-only Rocks-based install eliminates many of the potential pitfalls, which is why we felt comfortable releasing 1.0 in that form.

But we are committed to making the deployment process more robust, cleaning up the code a bit, and publishing it soon, hopefully by early July 2008. Whether or not we will support "build from source and deploy" installation method, the code will be open. Stay tuned for the announcement on the mailing list.