Eucalyptus is an open source software for building Amazon Web Services (AWS)-compatible private and hybrid clouds and

it allows organizations to build self-service, elastic clouds inside the datacenter using existing IT infrastructure. Eucalyptus enables AWS-compatible private and hybrid clouds by pooling together compute, storage, and network resources that can be dynamically scaled up or down as application workloads change.

Software architecture
Eucalyptus is compatible with AWS APIs so that users can leverage Eucalyptus commands to manage either Amazon or Eucalyptus instances. Cloud users can also move instances between a Eucalyptus private cloud and the Amazon public cloud to create a hybrid cloud. Eucalyptus leverages operating system virtualization to achieve isolation between applications and stacks. Operating system virtualization dedicates CPU, RAM, disk, and network resources to systems and applications so that they don't interfere with each other.[3] The following is an explanation of terminology and concepts used by Eucalyptus:[4] Images - An image is a fixed collection of software modules, system software, application software, and configuration information that is started from a known baseline (immutable/fixed). An example of an image is a Linux virtual machine configured with Apache, MySQL, Perl, and PHP. When bundled and uploaded to the Eucalyptus cloud, this becomes a Eucalyptus machine image (EMI). Instances - When an image is put to use, it is called an instance. The configuration is dynamically executed at runtime, and the Cloud Controller decides where the image will run, and storage and networking is attached to meet resource needs. IP addressing - Eucalyptus instances can have public and private IPs. An IP address is assigned to an instance when the instance is created from an image. For instances that require a persistent IP address, such as a web-server, Eucalyptus supplies elastic IP addresses. These are pre-allocated by the Eucalyptus cloud to an instance. An elastic IP persists whether the instance is running or not. In other words, if you stop an instance and restart it hours, days, or weeks later, the instance still binds to the same elastic IP address it was assigned to. This is essential for consistent DNS resolution. Security - TCP/IP stack layer 3 security is achieved using security groups, which share a common set of firewall rules. This is a

mechanism to firewall off an instance using IP address and port block/allow functionality. At TCP/IP layer 2 instances are isolated. If this were not present, a root user could manipulate the networking of instances and gain access to neighboring instances violating the basic cloud tenet of instance isolation and separation. Networking - There are three networking modes. In Managed Mode Eucalyptus manages a local network of instances, including security groups and elastic IPs. Eucalyptus maintains a DHCP server and provides private non-routable IPs to instances. An instance is created in a security group and gets an IP from the range in that group. There is also a pool of public (elastic) IPs that users can bind to an instance at boot-time or dynamically at runtime. VLANs are used to network instances in different security groups. If there is no VLAN present, isolation can be achieved using security groups in different subnets. In System Mode, essentially the physical LAN that is attached to Eucalyptus manages the network of the Eucalyptus cloud. Eucalyptus assigns a MAC address and attaches the instance's network interface to the physical Ethernet LAN through the Node Controller's bridge. System Mode requires a DHCP server on the physical LAN that is reachable by instances. System Mode does not offer elastic IPs, security groups, or VM isolation. In Static Mode, Eucalyptus maintains a DHCP server and assigns IP addresses to instances. Static Mode does not offer elastic IPs, security groups, or VM isolation. Access Control - A user of Eucalyptus is assigned an identity, and identities can be grouped together for access control. [edit]

Components
Eucalyptus has a modular, distributed, and highly scalable architecture offering six distinct components[5][6]: The Cloud Controller (CLC) is a Java program that offers EC2compatible SOAP and Query interfaces, as well as a web interface to the outside world. In addition to handling incoming requests, the CLC acts as the administrative interface for cloud management and performs high-level resource scheduling and system accounting. The CLC accepts user API requests from command-line interfaces like euca2ools or GUI-based tools like the Eucalyptus User Console and manages the underlying compute, storage, and network resources. Only one CLC can exist per cloud and it handles authentication, accounting, reporting, and quote management. Walrus, also written in Java, is the Eucalyptus equivalent to AWS

Simple Storage Service (S3). Walrus offers persistent storage to all of the virtual machines in the Eucalyptus cloud and can be used as a simple HTTP put/get storage as a service solution. There are no data type restrictions for Walrus, and it can contain images (i.e., the building blocks used to launch virtual machines), volume snapshots (i.e., point-in-time copies), and application data. Again, only one Walrus can exist per cloud. The Cluster Controller (CC) is written in C and acts as the front end for a cluster within a Eucalyptus cloud and communicates with the Storage Controller and Node Controller. It manages instance (i.e., virtual machines) execution and Service Level Agreements (SLAs) per cluster. The Storage Controller (SC) is written in Java and is the Eucalyptus equivalent to AWS EBS. It communicates with the Cluster Controller and Node Controller and manages Eucalyptus block volumes and snapshots to the instances within its specific cluster. If an instance requires writing persistent data to memory outside of the cluster, it would need to write to Walrus, which is available to any instance in any cluster. The Storage Controller interfaces with storage systems, including local, NFS, iSCSI, and SAN. The VMware Broker is an optional component that provides an AWScompatible interface for VMware environments and physically runs on the Cluster Controller. The VMware Broker overlays existing ESX/ESXi hosts and transforms Eucalyptus Machine Images (EMIs) to VMware virtual disks. The VMware Broker mediates interactions between the Cluster Controller and VMware and can connect directly to either ESX/ESXi hosts or to vCenter Server. The Node Controller (NC) is written in C and hosts the virtual machine instances and manages the virtual network endpoints. It downloads and caches images from Walrus as well as creates and caches instances. While there is no theoretical limit to the number of Node Controllers per cluster, performance limits do exist. [edit]