Watch the Eucalyptus Component Overview video above [18:45 minutes].
Eucalyptus is Modular, Distributed, and Highly Scalable
Eucalyptus architecture is highly scalable because of its distributed nature. The Cloud level is comprised of only two components and while used by many users, the transactions at each component are typically small. The Node level may have many components, but each component only supports a few users, even though the transactions are larger.
Eucalyptus is made up of six distinct components that can be deployed in various architectures:
- Cloud Controller (CLC)
- Walrus Storage
- Cluster Controller (CC)
- Storage Controller (SC)
- VMware Broker (Optional)
- Node Controller (NC)
The six components are grouped into three separate levels:
- Cloud level: Cloud Controller and Walrus
- Cluster level (i.e., Availability Zone): Cluster Controller, Storage Controller, and optional VMware Broker
- Node level: Node Controller
The Cloud Controller (CLC) is a Java program that offers EC2-compatible 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.
The CLC handles high-level:
- Quota 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 (SC) and Node Controller (NC). The CC 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 Elastic Block Store (EBS). The SC communicates with the Cluster Controller (CC) and Node Controller (NC) 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 SC interfaces with storage systems, including local, NFS, iSCSI, and SAN.
The VMware Broker is an optional component that provides an AWS-compatible interface for VMware environments and physically runs on the Cluster Controller (CC). 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 CC 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. The NC downloads and caches images from Walrus as well as creates and caches instances. While there is no theoretical limit to the number of NCs per cluster, performance limits do exist.