This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Introduction to Eucalyptus

Introduction to Eucalyptus

Eucalyptus is open source software for building AWS-compatible private and hybrid clouds.

As an Infrastructure as a Service (IaaS) product, Eucalyptus allows your users to provision your compute and storage resources on-demand.

You can install Eucalyptus on the following Linux distributions:

  • CentOS 7.9
  • Red Hat Enterprise Linux (RHEL) 7.9

1 - Eucalyptus Overview

Eucalyptus was designed to be easy to install and as non-intrusive as possible. The software framework is modular, with industry-standard, language-agnostic communication.

Eucalyptus provides a virtual network overlay that both isolates network traffic of different users and allows two or more clusters to appear to belong to the same Local Area Network (LAN). Also, Eucalyptus offers API compatibility with Amazon’s EC2, S3, IAM, ELB, Auto Scaling, CloudFormation, and CloudWatch services. This offers you the capability of a hybrid cloud.

2 - Eucalyptus Components

This topic describes the various components that comprise a Eucalyptus cloud.The following image shows a high-level architecture of Eucalyptus with its main components.

image A detailed description of each Eucalyptus component follows.

Cloud Controller

In many deployments, the Cloud Controller (CLC) service and the User-Facing Services (UFS) are on the same host machine. This server is the entry-point into the cloud for administrators, developers, project managers, and end-users. The CLC handles persistence and is the backend for the UFS. A Eucalyptus cloud must have exactly one CLC.

User-Facing Services

The User-Facing Services (UFS) serve as endpoints for the AWS-compatible services offered by Eucalyptus : EC2 (compute), AS (AutoScaling), CW (CloudWatch), ELB (LoadBalancing), IAM (Euare), and STS (tokens). A Eucalyptus cloud can have several UFS host machines.

Object Storage Gateway

The Object Storage Gateway (OSG) is part of the UFS. The OSG passes requests to object storage providers and talks to the persistence layer (DB) to authenticate requests. You can use Walrus, Riak CS, or Ceph-RGW as the object storage provider.

Object Storage Provider

The Object Storage Provider (OSP) can be either the Eucalyptus Walrus backend, Riak CS, or Ceph-RGW. Walrus is intended for light S3 usage and is a single service. Riak is an open source scalable general purpose data platform; it is intended for deployments with heavy S3 usage. Ceph-RGW is an object storage interface built on top of Librados.

Management Console

The Eucalyptus Management Console is an easy-to-use web-based interface that allows you to manage your Eucalyptus cloud. The Management Console is often deployed on the same host machine as the UFS. A Eucalyptus cloud can have multiple Management Console host machines.

Cluster Controller

The Cluster Controller (CC) service must run on a host machine that has network connectivity to the host machines running the Node Controllers (NCs) and to the host machine for the CLC. CCs gather information about a set of NCs and schedules virtual machine (VM) execution on specific NCs. All NCs associated with a single CC must be in the same subnet.

Storage Controller

The Storage Controller (SC) service provides functionality similar to Amazon Elastic Block Store (Amazon EBS). The SC can interface with various storage systems. Elastic block storage exports storage volumes that can be attached by a VM and mounted or accessed as a raw block device. EBS volumes can persist past VM termination and are commonly used to store persistent data. An EBS volume cannot be shared between multiple VMs at once and can be accessed only within the same availability zone in which the VM is running. Users can create snapshots from EBS volumes. Snapshots are stored by the OSG and made available across availability zones.

Node Controller

The Node Controller (NC) service runs on any machine that hosts VM instances. The NC controls VM activities, including the execution, inspection, and termination of VM instances. It also fetches and maintains a local cache of instance images, and it queries and controls the system software (host OS and the hypervisor) in response to queries and control requests from the CC.

Eucanetd

The eucanetd service implements artifacts to manage and define Eucalyptus cloud networking. Eucanetd runs alongside the CLC or NC services, depending on the configured networking mode.

3 - System Requirements

To install Eucalyptus, your system must meet the baseline requirements described in this topic.

Compute Requirements

  • Physical Machines: All services must be installed on physical servers, not virtual machines.
  • Central Processing Units (CPUs): We recommend that each host machine in your cloud contain either an Intel or AMD processor with a minimum of 4 2GHz cores.
  • Operating Systems: supports the following Linux distributions: CentOS 7.9 and RHEL 7.9. supports only 64-bit architecture.
  • Machine Clocks: Each host machine and any client machine clocks must be synchronized (for example, using NTP). These clocks must be synchronized all the time, not only during the installation process.

Storage and Memory Requirements

  • Each machine needs a minimum of 100GB of storage.
  • We recommend at least 500GB for Walrus and SC hosts.
  • We recommend 200GB per NC host running Linux VMs. Note that larger available disk space enables a greater number of VMs.
  • Each machine needs a minimum of 16GB RAM. However, we recommend more RAM for improved caching and on NCs to support more instances.

Network Requirements

  • For VPCMIDO, Eucalyptus needs MidoNet to be installed.
  • The network connecting machines that host components (except the CC and NC) must support UDP multicast for IP address 239.193.7.3. Note that UDP multicast is not used over the network that connects the CC to the NCs.

Once you are satisfied that your systems requirements are met, you are ready to plan your Eucalyptus installation.