Eucalyptus is an open source cloud computing platform that enables businesses to build applications and move workloads between existing data centers and Amazon Web Services. It plays a great role if you are looking to enrich your cloud experience.
With this AWS-compatible architecture, enterprises using Eucalyptus can quickly move workloads between private and public clouds without modifying applications. Meanwhile, IT departments can use their preferred management tools and skills in both environments.
Eucalyptus is an open-source software infrastructure for implementing cloud computing on clusters, providing compute, storage, and network resources on demand as application workloads change. Support for Amazon Web Services allows applications developed there to run seamlessly in on-premise data centers using an industry-standard web service API.
Eucalyptus can be deployed as either private clouds, public clouds, or hybrid implementations. It consists of major components, including a Cloud Controller (CLC), Cluster Controller (CC), Storage Controller (SC), Node Controller (NC), and optionally, a VMware Broker for effective deployments of cloud infrastructures on clusters.
Cloud Controller CLC
The Cloud Controller (CLC) is at the core of every Eucalyptus cloud. It implements EC2-compliant SOAP and Query interfaces for user API requests and performs high-level resource scheduling and system accounting functions. By default, CLC runs on the same machine as Walrus and Storage Controller, making it the main element of each cloud. To keep things simple, only one CLC may exist per cloud. It allows it to be the single point of contact and consistency. By keeping track of resources, you have an index page of a book for your cloud with the CLC.
Like EBS in Amazon Web Services, Storage Controller (SC) provides block storage services to instances. In addition, the SC manages computer storage hardware and interacts with various storage systems like NFS, iSCSI, and SAN devices. Furthermore, SC serves an integral function within the Cloud Controller and Node Controller as it holds both machine images for an instance and application data for processing by these controllers.
The VMware Broker service allows CLCs to communicate and control a virtualized environment powered by VMware. It enables ESXi hosts or VCenter servers to act as hosts or servers while connecting to existing VMware-based infrastructure in hybrid deployment scenarios.
Cluster Controller CC
The Cluster Controller (CC) is a critical component in Eucalyptus cloud architecture too, and it functions as the orchestrator for managing all the virtual resources within a particular cluster. It sits between the Cloud Controller (CLC) and the Node Controllers (NCs), serving as a bridge for communication and control. The CC is responsible for resource allocation, instance management, and network configuration within its cluster.
Here is an outline of the CC duties and management:
Role in Instance Execution and Management
When a user or system request comes in to start a new virtual machine instance, the Cloud Controller forwards this request to the appropriate Cluster Controller. The CC takes this request and manages the starting of the VM on one of the available Node Controllers it can access. It interacts with NCs using functional APIs such as `runInstance`, `terminateInstance`, `describeResources`, and `describeInstance`. These APIs are crucial for the Node Controllers to interact with the overall cloud infrastructure, and they enable various actions like launching, terminating, and querying the status of instances. More on those commands in a moment.
Virtual Network Overlay Management
One of the CC’s essential roles is controlling the virtual network overlay for instances within its cluster. It ensures that the virtual machines are appropriately networked, following the specified rules and policies for isolation or communication between instances. This involves the creation, management, and teardown of any virtual LANs (VLANs), subnets, and routes to ensure instances can communicate with each other and the outside world as required. This gives you total control of all the elements of the cloud, and meaning you can run IAAS and PAAS options to your clients.
Instance Status Monitoring
The Cluster Controller continuously collects status reports from Node Controllers, which include metrics like CPU utilization, memory usage, and network activity for each running instance. This information is essential for real-time resource management and for making informed scheduling decisions.
API Functions
As mentioned, the CC provides functional APIs enabling Node Controllers to interact seamlessly with the Eucalyptus system. These include:
`runInstance`: Initiates a new VM instance on a node.
`terminateInstance`: Shuts down an existing VM instance.
`describeResources`: Provides an overview of available resources within the cluster.
`describeInstance`: Offers details about specific VM instances, such as current status and resource allocation.
Storage Controller SC
The Storage Controller SC (SC) service enables a cluster to store and stream persistent data similar to Amazon Web Services Elastic Block Store (Amazon EBS) and supports iSCSI, SAS or SAN devices.The Eucalyptus Storage Controller can run in managed mode (MM), system mode or static mode, with managed method being preferred as it offers networking virtualization for all instances within a data center while also providing elastic IP addresses to each instance in turn.
The Storage Controller (SC) provides persistent block-level storage for instances, storing images, snapshots, and data similar to Amazon’s Elastic Block Store (EBS). Additionally, it offers REST and SOAP APIs to developers. Finally, the Node Controller (NC) acts as a lifecycle manager for instances running on each host node; it communicates with operating systems and hypervisors to control how VM instances function before responding to queries from the Control Center and providing system APIs for instance execution, termination, and reporting.
Node Controller NC
Each node controller (NC) runs on a server designated to host virtual machines (VMs) and run the UEC virtualization system (called the “UEC”). Each NC processes node operations before communicating them to a central machine running a UEC CC which stores and delivers operational state changes from it; the latter could either reside on the same cluster front-end machine as an NC, or another with network access that has network access to all nodes running NCs and the CLC running machine.
The NC analyzes each node’s operating system to discover its physical resources – memory, processor and disk storage capacity. It communicates with its hypervisor in order to gain information regarding current and past virtual machine instances on that node and convey this state change information back upstream to its CC.
Eucalyptus offers support for an assortment of open source and commercial data storage systems that comply with the S3 standard, such as Walrus as its default implementation – an easy filesystem-based storage solution – or RiakCS which uses distributed log management that can be managed with the command-line tool for S3, s3cmd. The Node Controller (NC) primarily focuses on instance lifecycle management and does not typically interact directly with S3-compatible storage solutions like Walrus or RiakCS.
Virtual Machines VMs
In the context of Eucalyptus architecture, Virtual Machines (VMs) serve as the computational units that execute user applications and services. They act as isolated environments running on top of the physical hardware yet abstracted away through virtualization layers. These VMs are analogous to Amazon EC2 instances regarding functionality and purpose.
Lifecycle Management
The lifecycle of a VM within an Eucalyptus cloud starts with a user request to instantiate a particular machine image. This request is processed by the Cloud Controller (CLC), which then communicates with the appropriate Cluster Controller (CC) to allocate resources. The CC, in turn, communicates with the Node Controller (NC) on one of the physical servers (nodes) to start the VM.
Resource Allocation
Resource allocation for VMs – such as CPU cores, memory, and network bandwidth – is managed according to policies and availability. The Cluster Controller generally orchestrates this, but the Node Controller is responsible for the implementation on the individual node. VMs can be allocated dedicated or shared resources, depending on the requirements specified during the instantiation process.
Networking and Storage
VMs in a Eucalyptus cloud can be configured with various networking options, including but not limited to private IPs, public IPs, or VLANs. Storage can also be dynamically attached to VMs through the Storage Controller, similar to how Amazon’s Elastic Block Store (EBS) works.
Compatibility
One of the critical strengths of Eucalyptus is its API compatibility with Amazon Web Services (AWS), including the ability to manage VM instances. This allows users to employ the same tooling and scripting they would use on AWS, easing the transition between public and private clouds or enabling hybrid cloud scenarios.
Monitoring and Telemetry
VMs are continuously monitored for performance metrics and health status. This data is useful for administrators and users for troubleshooting, resource scaling, and load balancing purposes. Monitoring is integrated into the architecture and accessed via the Cloud Controller’s dashboard or API.
Termination and Scaling
VMs can be terminated manually by the user or automatically based on policies. Eucalyptus also provides capabilities for auto-scaling, allowing the number of VM instances to be dynamically adjusted based on load or other factors.