Documentation

• 1: Installation Guide
• 1.1: Installation Overview
• 1.2: Introduction to Eucalyptus
• 1.2.1: Eucalyptus Overview
• 1.2.2: Eucalyptus Components
• 1.2.3: System Requirements
• 1.3: Automated Eucalyptus Installation
• 1.4: Manual Eucalyptus Installation
• 1.4.1: Plan Your Installation
• 1.4.1.1: Eucalyptus Architecture Overview
• 1.4.1.2: Plan Your Hardware
• 1.4.1.3: Plan Services Placement
• 1.4.1.4: Plan Disk Space
• 1.4.1.5: Plan Eucalyptus Features
• 1.4.1.5.1: Availability Zone Support
• 1.4.1.5.2: Object Storage
• 1.4.1.6: Plan Networking Modes
• 1.4.1.6.1: About Eucanetd
• 1.4.1.6.2: Understanding Eucalyptus EDGE Mode
• 1.4.1.6.3: Understanding VPCMIDO and MidoNet
• 1.4.1.7: Prepare the Network
• 1.4.1.7.1: Reserve Ports
• 1.4.1.7.2: Verify Connectivity
• 1.4.2: Configure Dependencies
• 1.4.2.1: Configure Bridges
• 1.4.2.2: Disable FirewallD on RHEL 7
• 1.4.2.3: Configure NTP
• 1.4.2.4: Configure Java
• 1.4.2.5: Configure an MTA
• 1.4.2.6: Install MidoNet
• 1.4.2.6.1: Prerequisites
• 1.4.2.6.2: MidoNet Component Topology
• 1.4.2.6.3: Install MidoNet for Eucalyptus
• 1.4.3: Install Repositories
• 1.4.3.1: Software Signing
• 1.4.3.2: Install Eucalyptus Release Packages
• 1.4.4: Configure Eucalyptus
• 1.4.4.1: Configure SELinux
• 1.4.4.2: Configure Network Modes
• 1.4.4.2.1: Configure EDGE Network Mode
• 1.4.4.2.2: Configure VPCMIDO Network Mode
• 1.4.4.2.2.1: VPCMIDO Gateway Configuration Parameters
• 1.4.4.3: Create Scheduling Policy
• 1.4.5: Start Eucalyptus
• 1.4.5.1: Start the CLC
• 1.4.5.2: Start the UFS
• 1.4.5.3: Start Walrus
• 1.4.5.4: Start the CC
• 1.4.5.5: Start the SC
• 1.4.5.6: Start the NC
• 1.4.5.7: Start the Management Console
• 1.4.5.8: Verify the Startup
• 1.4.6: Register Eucalyptus Services
• 1.4.6.1: Register User-Facing Services
• 1.4.6.2: Register the Walrus Backend
• 1.4.6.3: Register the Cluster Controller
• 1.4.6.4: Register the Storage Controller
• 1.4.6.5: Register the Node Controllers
• 1.4.7: Configure the Runtime Environment
• 1.4.7.1: Configure Eucalyptus DNS
• 1.4.7.2: Create the Eucalyptus Cloud Administrator User
• 1.4.7.3: Upload the Network Configuration
• 1.4.7.4: Configure Eucalyptus Storage
• 1.4.7.4.1: Configure Block Storage
• 1.4.7.4.1.1: Use Ceph-RBD
• 1.4.7.4.1.1.1: Configure Hypervisor Support for Ceph-RBD
• 1.4.7.4.1.2: About the BROKEN State
• 1.4.7.4.1.3: Use Direct Attached Storage (JBOD)
• 1.4.7.4.1.4: Use the Overlay Local Filesystem
• 1.4.7.4.2: Configure Object Storage
• 1.4.7.4.2.1: Use Ceph-RGW
• 1.4.7.4.2.2: Use MinIO Backend
• 1.4.7.4.2.3: Use Walrus Backend
• 1.4.7.5: Install and Configure the Imaging Service
• 1.4.7.6: Configure the Load Balancer
• 1.4.7.7: Configure Node Controller
• 1.5: Client Installation
• 1.5.1: AWS CLI Installation
• 1.5.2: Euca2ools Standalone Installation
• 1.6: Find More Information
• 2: Administration Guide
• 2.1: Management Overview
• 2.1.1: Overview of Eucalyptus
• 2.1.2: Command Line Interface
• 2.2: Manage Your Cloud
• 2.2.1: Cloud Overview
• 2.2.2: Cloud Best Practices
• 2.2.2.1: Synchronize Clocks
• 2.2.2.2: Configure SSL
• 2.2.2.3: Storage Volumes
• 2.2.3: Cloud Tasks
• 2.2.3.1: Inspect System Health
• 2.2.3.2: View User Resources
• 2.2.3.3: Change Network Configuration
• 2.2.3.3.1: Networking Configuration Options
• 2.2.3.4: Add a Node Controller
• 2.2.3.5: Migrate Instances Between Node Controllers
• 2.2.3.6: Remove a Node Controller
• 2.2.3.7: Restart Eucalyptus
• 2.2.3.7.1: Shut Down All Instances
• 2.2.3.7.2: Restart the CLC
• 2.2.3.7.3: Restart Walrus
• 2.2.3.7.4: Restart the CC
• 2.2.3.7.5: Restart the SC
• 2.2.3.7.6: Restart an NC
• 2.2.3.8: Shut Down Eucalyptus
• 2.2.3.8.1: Shut Down All Instances
• 2.2.3.8.2: Shut Down the NCs
• 2.2.3.8.3: Shut Down the CCs
• 2.2.3.8.4: Shut Down the SCs
• 2.2.3.8.5: Shut Down Walrus
• 2.2.3.8.6: Shut Down the CLC
• 2.2.3.9: Disable CloudWatch
• 2.3: Operations
• 2.3.1: Operations Overview
• 2.3.2: Planning Your Deployment
• 2.3.3: Testing Your Deployment
• 2.3.4: Customizing Your Deployment
• 2.3.5: Managing Policies
• 2.3.6: Networking
• 2.3.7: Monitoring
• 2.3.8: Backup and Recovery
• 2.3.8.1: Back Up Eucalyptus Cloud Data
• 2.3.8.1.1: Back Up the Database
• 2.3.8.2: Recover Eucalyptus Cloud Data
• 2.3.8.2.1: Restore the Database
• 2.3.9: Troubleshooting
• 2.3.9.1: Eucalyptus Log Files
• 2.3.9.2: Network Information
• 2.3.9.3: Common Problems
• 2.3.9.3.1: Problem: can't communicate with instance
• 2.3.9.3.2: Problem: install-time checks
• 2.3.9.3.3: Problem: instance runs but fails
• 2.3.9.3.4: Problem: snapshot creation failed
• 2.3.9.3.5: Problem: volume creation failed
• 2.3.9.4: Component Workarounds
• 2.3.9.4.1: Access and Identities
• 2.3.9.4.2: Elastic Load Balancing
• 2.3.9.4.3: Imaging Worker
• 2.3.9.4.4: Instances
• 2.3.9.4.5: Walrus and Storage
• 2.4: Manage Resources
• 2.4.1: Manage Auto Scaling Resources
• 2.4.2: Manage CloudWatch Resources
• 2.4.3: Manage Compute Resources
• 2.4.4: Manage ELB Resources
• 2.4.5: Manage IAM Resources
• 2.4.6: Manage Walrus Resources
• 2.5: Manage Regions
• 2.5.1: Regions Overview
• 2.5.2: Region Configuration File Format
• 2.5.3: Examples
• 2.5.4: Federation Differences Between AWS and Eucalyptus
• 2.5.5: Troubleshooting
• 2.6: Manage Security
• 2.6.1: Security Overview
• 2.6.2: Best Practices
• 2.6.2.1: Authentication and Access Control Best Practices
• 2.6.2.2: Hosts
• 2.6.2.3: Images and Instances
• 2.6.2.4: Management Console
• 2.6.2.5: Message Security
• 2.6.2.6: Networking Modes
• 2.6.3: Security Tasks
• 2.6.3.1: Configure SSL
• 2.6.3.1.1: Configure and Enable SSL for the Management Console
• 2.6.3.1.2: Configure and Enable SSL for the UFS
• 2.6.3.2: Change Multicast Address
• 2.6.3.3: Configure Replay Protection
• 2.6.3.4: Configure Session Timeouts
• 2.6.3.5: Configure STS Actions
• 2.6.3.6: Configure the Firewall
• 2.6.3.7: Reserve Ports
• 2.6.3.8: Synchronize Components
• 2.7: Eucalyptus Commands
• 2.7.1: Eucalyptus Administration Commands
• 2.7.1.1: euctl
• 2.7.1.2: euserv-deregister-service
• 2.7.1.3: euserv-describe-events
• 2.7.1.4: euserv-describe-node-controllers
• 2.7.1.5: euserv-describe-service-types
• 2.7.1.6: euserv-describe-services
• 2.7.1.7: euserv-migrate-instances
• 2.7.1.8: euserv-modify-service
• 2.7.1.9: euserv-register-service
• 2.7.2: Eucalyptus Configuration Variables
• 2.8: Advanced Storage Configuration
• 2.8.1: OSG Advanced Configuration
• 3: User Guide
• 3.1: Eucalyptus Overview
• 3.2: Getting Started
• 3.2.1: Getting Started with the Eucalyptus Management Console
• 3.2.1.1: Console Login
• 3.2.1.2: Launch and Connect to an Instance with the Management Console
• 3.2.1.3: Set Up A Web Server on an Instance
• 3.2.1.4: Reboot an Instance with the Management Console
• 3.2.1.5: Terminate an Instance with the Management Console
• 3.2.2: Getting Started with the AWS CLI
• 3.2.3: Getting Started with Euca2ools
• 3.3: Using Instances
• 3.3.1: Instance Overview
• 3.3.1.1: Instance Concepts
• 3.3.1.2: Instance Basics
• 3.3.1.2.1: Virtual Machine Types
• 3.3.1.2.2: Ephemeral Linux Instances
• 3.3.1.2.3: EBS-Backed Instances
• 3.3.1.2.3.1: Comparing Instance Types
• 3.3.1.2.3.2: Using EBS-Backed Instances
• 3.3.1.2.3.3: Suspending and Resuming EBS-Backed Instances
• 3.3.1.2.3.4: EBS EMI Creation Overview
• 3.3.1.2.3.4.1: Create an EBS EMI
• 3.3.2: Instance Tasks
• 3.3.2.1: Authorize Security Groups
• 3.3.2.2: Create Key Pairs
• 3.3.2.3: Find an Image
• 3.3.2.4: Launch an Instance
• 3.3.2.5: Log in to an Instance
• 3.3.2.6: Reboot an Instance
• 3.3.2.7: Terminate an Instance
• 3.4: Using EBS
• 3.4.1: EBS Overview
• 3.4.2: EBS Tasks
• 3.4.2.1: Create and Attach an EBS Volume
• 3.4.2.2: List Available EBS Volumes
• 3.4.2.3: Detach an EBS Volume
• 3.4.2.4: Create a Snapshot
• 3.4.2.5: List Available Snapshots
• 3.4.2.6: Delete a Snapshot
• 3.5: Using Tags and Filters
• 3.5.1: Tagging and Filtering Overview
• 3.5.1.1: Tagging Resources
• 3.5.1.2: Filtering Resources
• 3.5.2: Tagging and Filtering Tasks
• 3.5.2.1: Add a Tag
• 3.5.2.2: List Tags
• 3.5.2.3: Change a Tag's Value
• 3.5.2.4: Delete a Tag
• 3.5.2.5: Filter by Tag
• 3.6: Managing Access
• 3.6.1: Groups
• 3.6.1.1: Create a Group
• 3.6.1.2: Add a Group Policy
• 3.6.1.3: Modify a Group
• 3.6.1.4: Add a User to a Group
• 3.6.1.5: Remove a User from a Group
• 3.6.1.6: List Groups
• 3.6.1.7: Delete a Group
• 3.6.2: Users
• 3.6.2.1: Add a User
• 3.6.2.2: Create a Login Profile
• 3.6.2.3: Modify a User
• 3.6.2.4: Change User Path
• 3.6.2.5: Change User Password
• 3.6.2.6: List Users
• 3.6.2.7: Delete a User
• 3.6.3: Credentials
• 3.6.3.1: Create Credentials
• 3.6.3.2: Upload a Certificate
• 3.7: Using VM Networking and Security
• 3.7.1: Associate an IP Address with an Instance
• 3.7.2: Release an IP Address
• 3.7.3: Create a Security Group
• 3.7.4: Delete a Security Group
• 3.7.5: Authorize Security Group Rules
• 3.7.6: Revoke Security Group Rules
• 3.8: Using Auto Scaling
• 3.8.1: How Auto Scaling Works
• 3.8.2: Auto Scaling Concepts
• 3.8.2.1: Understanding Launch Configurations
• 3.8.2.2: Understanding Auto Scaling Groups
• 3.8.2.3: Understanding Auto Scaling Policies
• 3.8.2.4: Understanding Health Checks
• 3.8.2.5: Understanding Instance Termination Policies
• 3.8.3: Auto Scaling Usage Examples
• 3.8.3.1: Creating a Basic Auto Scaling Configuration
• 3.8.3.2: Configuring a Demand-Based Scaling Policy
• 3.8.3.3: Configuring Health Checks
• 3.8.3.4: Configuring an Instance Termination Policy
• 3.8.3.5: Configuring Auto Scaling with Elastic Load Balancing
• 3.9: Using Elastic Load Balancing
• 3.9.1: Elastic Load Balancing Overview
• 3.9.1.1: Elastic Load Balancing Concepts
• 3.9.2: Eucalyptus Load Balancing Usage Examples
• 3.9.2.1: Eucalyptus ELB Listener Configurations
• 3.9.2.2: Creating a Basic Elastic Load Balancing Configuration
• 3.9.2.3: Configuring the Health Check
• 3.9.2.4: Modifying an Elastic Load Balancing Configuration
• 3.9.2.5: Creating Elastic Load Balancing Sticky Sessions
• 3.9.2.6: Uploading SSL Certificates for Elastic Load Balancing
• 3.9.2.7: Adding SSL Support
• 3.9.2.8: Updating the SSL Negotiation Configuration
• 3.9.2.9: Adding and Editing Predefined Security Policies
• 3.9.2.10: Configuring Back-end Server Authentication
• 3.9.2.11: Enabling Cross-Zone Load Balancing
• 3.9.2.12: Accessing Load Balancer Logs
• 3.10: Using CloudWatch
• 3.10.1: CloudWatch Overview
• 3.10.1.1: CloudWatch Concepts
• 3.10.1.2: Namespaces, Metrics, and Dimensions
• 3.10.1.2.1: Namespaces
• 3.10.1.2.2: Instance Metrics and Dimensions
• 3.10.1.2.3: EBS Metrics and Dimensions
• 3.10.1.2.4: Auto Scaling Metrics and Dimensions
• 3.10.1.2.5: ELB Metrics and Dimensions
• 3.10.2: CloudWatch Tasks
• 3.10.2.1: Configuring Monitoring
• 3.10.2.1.1: Enable Monitoring
• 3.10.2.1.2: Disable Monitoring
• 3.10.2.2: Viewing and Publishing Metrics
• 3.10.2.2.1: List Available Metrics
• 3.10.2.2.2: Get Statistics for a Metric
• 3.10.2.2.3: Publish Custom Metrics
• 3.10.2.2.4: Modify Metric Polling Timing
• 3.10.2.3: Configuring Alarms
• 3.10.2.3.1: Create an Alarm
• 3.10.2.3.2: Test an Alarm
• 3.10.2.3.3: Delete an Alarm
• 3.11: Using Object Storage
• 3.11.1: Access Object Storage
• 3.12: Using Route53
• 3.12.1: Route53 Concepts
• 3.12.2: Route53 Usage
• 3.12.3: Route53 Delegated Subdomain
• 3.13: Using Simple Queue Service
• 3.13.1: Simple Queue Service Concepts
• 3.13.2: Simple Queue Service Overview
• 3.14: Using CloudFormation
• 3.14.1: CloudFormation Use Case
• 3.14.2: CloudFormation Templates
• 3.14.3: Troubleshooting CloudFormation
• 3.15: Using Virtual Private Cloud
• 3.15.1: How VPC Works
• 3.15.1.1: Default VPCs
• 3.15.1.2: Subnets and IP Addressing
• 3.15.2: Understanding VPC Networking Concepts
• 3.15.2.1: Domain Name System (DNS)
• 3.15.2.2: Elastic Network Interfaces (ENIs)
• 3.15.2.3: Route Tables
• 3.15.2.4: Internet Gateways
• 3.15.2.5: Network Address Translation (NAT) Gateways
• 3.15.3: VPC Security Concepts
• 3.15.3.1: Security Groups
• 4: Identity and Access Management (IAM) Guide
• 4.1: IAM Overview
• 4.2: Work with IAM
• 4.3: Manage Identities Overview
• 4.4: Authentication and Access Control Best Practices
• 4.5: Manage Users and Groups
• 4.5.1: Access Overview
• 4.5.1.1: Access Concepts
• 4.5.1.1.1: User Identities
• 4.5.1.1.2: Special Identities
• 4.5.1.1.3: Credentials
• 4.5.1.1.4: Account Creation
• 4.5.1.1.5: Special User Attributes
• 4.5.1.1.6: Roles
• 4.5.1.2: Policy Overview
• 4.5.1.2.1: Default Permissions
• 4.5.1.2.2: Quotas
• 4.5.1.2.3: Algorithms
• 4.5.1.2.4: Sample Policies
• 4.5.2: Access Tasks
• 4.5.2.1: Use Case: Create an Administrator
• 4.5.2.2: Use Case: Create a User
• 4.5.2.3: Accounts
• 4.5.2.3.1: Add an Account
• 4.5.2.3.2: Rename an Account
• 4.5.2.3.3: List Accounts
• 4.5.2.3.4: Delete an Account
• 4.5.2.4: Groups
• 4.5.2.4.1: Create a Group
• 4.5.2.4.2: Add a Group Policy
• 4.5.2.4.3: Modify a Group
• 4.5.2.4.4: Remove a User from a Group
• 4.5.2.4.5: List Groups
• 4.5.2.4.6: List Policies for a Group
• 4.5.2.4.7: Delete a Group
• 4.5.2.5: Users
• 4.5.2.5.1: Add a User
• 4.5.2.5.2: Add a User to a Group
• 4.5.2.5.3: Create a Login Profile
• 4.5.2.5.4: Generating User Credentials
• 4.5.2.5.5: Uploading a Certificate
• 4.5.2.5.6: Modify a User
• 4.5.2.5.7: List Users
• 4.5.2.5.8: Delete a User
• 4.5.2.6: Roles
• 4.5.2.6.1: Launch an Instance with a Role
• 4.5.2.6.2: Use a Role with an Instance Application
• 4.5.2.6.3: Assume a Role
• 4.5.2.6.4: Delegate Access Across Your Accounts Using Roles
• 5: Image Management Guide
• 5.1: Image Management Overview
• 5.2: Image Overview
• 5.3: Image Tasks
• 5.3.1: Browse and Download from Eucalyptus
• 5.3.2: Install an HVM Image
• 5.3.3: Create an HVM Image
• 5.3.3.1: Create an HVM Image from a Linux Distribution ISO (KVM)
• 5.3.4: Migrate an Image
• 5.3.4.1: Create an Image from an Existing EBS-Backed Instance
• 5.3.4.2: Create an Image from an Existing Instance-Store Instance
• 5.3.4.3: Prepare a Linux System for Eucalyptus
• 5.3.4.4: Migrate a Linux Image from AWS to Eucalyptus
• 5.3.4.5: Migrate a Linux Image from Eucalyptus to AWS
• 5.3.5: Install a paravirtual image
• 5.3.5.1: Add a Kernel
• 5.3.5.2: Add a Ramdisk
• 5.3.5.3: Add a Root Filesystem
• 5.3.6: Remove an Image

1 - Installation Guide

Installation Guide

This section describes concepts and tasks you need to successfully install Eucalyptus.

1.1 - Installation Overview

This topic helps you understand, plan for, and install Eucalyptus. If you follow the recommendations and instructions in this guide, you will have a working version of Eucalyptus customized for your specific needs and requirements. This guide walks you through installations for a few different use cases.

You can choose from one of the installation types listed in the following table.

We recommend that you read the section you choose in the order presented. To customize your installation, you have to understand what Eucalyptus is, what the installation requirements are, what your network configuration and restrictions are, and what Eucalyptus components and features are available based on your needs and requirements.

1.2 - 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.2.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.

1.2.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.

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.

1.2.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.

1.3 - Automated Eucalyptus Installation

Automated Eucalytpus installation uses an Ansible playbook.

To install Eucalyptus you will need to have Ansible and the Eucalyptus playbooks available and to create an inventory file that describes your deployment.

Install Packages

The host performing the installation must have the EPEL YUM repository available (for Ansible):

yum install epel-release

and a Eucalyptus YUM repository, either the release repository:

yum install https://downloads.eucalyptus.cloud/software/eucalyptus/5/rhel/7/x86_64/eucalyptus-release-5-1.11.as.el7.noarch.rpm

or the master repository for the latest nightly build:

yum install https://downloads.eucalyptus.cloud/software/eucalyptus/master/rhel/7/x86_64/eucalyptus-release-5-1.15.as.el7.noarch.rpm

Create Inventory

The Ansible inventory file describes both the hosts that will run your Eucalyptus cloud and the options for your installation.

---
all:
  hosts:
    cloud.example.com:
    node[01:10].example.com:

  vars:
    vpcmido_public_ip_range: "1.X.Y.128-1.X.Y.254"
    vpcmido_public_ip_cidr: "1.X.Y.128/25"

  children:
    cloud:
      hosts:
        cloud.example.com:
    zone:
      hosts:
        cloud.example.com:
    node:
      hosts:
        node[01:10].example.com:

There are three main sections to an inventory file:

1. hosts : the hosts to deploy
2. vars : variables providing options for the deployment
3. children : host groupings that describe where to install Eucalyptus components

Minimal Install

The minimum inventory for a deployment must specify one host and have a children/cloud section that includes that host.

For VPCMIDO the vars for vpcmido_public_ip_range and vpcmido_public_ip_cidr must also be provided.

When the zone and node children are not specified they are assumed to be the same host as the cloud.

Customization

Settings that are often used in an inventory are described in this section.

The DNS domain to be used should be set in the vars section:

    cloud_system_dns_dnsdomain: "mycloud.example.com"

The NTP server to use with services in your deployment can also be specifed:

    cloud_properties:
      services.imaging.worker.ntp_server: "time.cloudflare.com"
      services.loadbalancing.worker.ntp_server: "time.cloudflare.com"

To specify region and zone names for your deployment add the vars:

    cloud_region_name: "us-euca-1"
    cloud_zone_1_name: "us-euca-1a"
    cloud_zone_2_name: "us-euca-1b"
    cloud_zone_3_name: "us-euca-1c"

You can follow AWS naming conventions or can use your own naming scheme. To specify which hosts belong to which zone update the hosts section:

  hosts:
    node01.example.com:
      host_cluster_ipv4: "10.111.10.101"
      host_public_ipv4: "1.X.Y.101"
      host_zone_key: 1

The host_zone_key value of 1 specifes that node01 would be part of the us-euca-1a zone. This example also shows how to configure the public and cluster IP addresses for a host.

To specify the port for web sevices use:

    cloud_public_port: 443

If using port 443 for web services, the management console should be deployed as a service to avoid a port conflict.

To enable a firewall on the public/cluster interfaces use:

    cloud_firewalld_configure: yes
    cloud_firewalld_cluster_cidr: "10.111.0.0/16"
    cloud_firewalld_cluster_interface: "en2"
    cloud_firewalld_public_interface: "en1"

Interfaces must be named consistently on all hosts.

The default install uses overlay for block storage, to use das you must have an LVM volume group available on all storage (zone) hosts and set:

    cloud_storage_dasdevice: "storage_vg"

To deploy the management console as service running on an instance in your Eucalyptus cloud:

    eucalyptus_console_cloud_deploy: yes
    cloud_service_image_rpm: no

This will also create a DNS entry for the console such as console.mycloud.example.com. When deploying the console on an instance it is recommended to also set cloud_service_image_rpm to no so that the service image for loadbalancing and imaging is installed using the same approach rather than from the rpm.

MidoNet NSDB

For VPCMIDO deployments the MidoNet NSDB (Network State Database) should be deployed on multiple hosts:

    midonet-nsdb:
      hosts:
        midonet-nsdb[01:03].example.com:

These could be distinct hosts, or could be hosts running cloud and zone components (for example)

Using Ceph

To use Ceph for block and object storage configure the settings:

    ceph_release: "nautilus"
    ceph_osd_data_path: "storage_vg/storage_lv"
    ceph_public_network: "10.111.0.0/16"

the ceph_osd_data_path should reference either an existing LVM volume available on all hosts or a device.

The hosts for ceph must be in the ceph group under children:

    ceph:
      hosts:
        ceph[01:03].example.com:

There must be three or more hosts to have redundancy.

Using MinIO

To deploy MinIO as the objectstorage provider you specify minio under children:

    minio:
      hosts:
        minio.example.com:

This will deploy MinIO on those hosts and also configure MinIO as the objectstorage provider when Ceph is not being deployed. There must be three or more hosts to have redundancy.

Enabling Certbot Integration

To enable Let’s Encrypt for HTTPS via certbot set the following vars:

    eucaconsole_certbot_configure: yes
    eucalyptus_console_certbot_enable: yes
    eucalyptus_services_certbot_enable: yes

To use this functionality the cloud must be public so that it can be reached for DNS (services) or HTTP (console) challenges. See the Let’s Encrypt Challenge Types for details.

The eucaconsole_certbot_configure setting should be used when deploying the console on a physical host. The eucalyptus_console_certbot_enable setting applies when deploying the console on the cloud (i.e. when you specifed eucalyptus_console_cloud_deploy)

Test Connectivity

Before starting a deployment, test that the installation host can access all hosts in the inventory by running:

ansible --inventory inventory.yml -m ping all

If this fails, ensure that you have configured SSH access to all inventory hosts (e.g. configure passwordless SSH access) before proceeding to the installation.

Perform Installation

To start a VPCMIDO installation:

ansible-playbook --inventory inventory.yml /usr/share/eucalyptus-ansible/playbook_vpcmido.yml

To start an EDGE installation:

ansible-playbook --inventory inventory.yml /usr/share/eucalyptus-ansible/playbook_edge.yml

See the Find More Information page for next steps.

1.4 - Manual Eucalyptus Installation

Manual Eucalyptus Installation

This section details steps to install Eucalyptus manually. To install Eucalyptus, perform the following tasks in the order presented.

1.4.1 - Plan Your Installation

Plan Your Installation

Before you install Eucalyptus components on your machines, we recommend that you take the time to plan how you want to install it.

To successfully plan for your Eucalyptus installation, you must determine two things:

• Think about the application workload performance and resource utilization tuning. Think about how many machines you want on your system.
• Use your existing architecture and policies to determine the networking features you want to enable: EC2 Classic Networking or EC2 VPC Networking.

This section describes how to evaluate each tradeoff to determine the best choice to make, and how to verify that the resource environment can support the features that are enabled as a consequence of making a choice.

By the end of this section, you should be able to specify how you will deploy Eucalyptus in your environment, any tradeoffs between feature set and flexibility, and where your deployment will integrate with existing infrastructure systems.

1.4.1.1 - Eucalyptus Architecture Overview

This topics describes the relationship of the components in a Eucalyptus installation. The cloud components: Cloud Controller (CLC) and Walrus, as well as user components: User-Facing Services (UFS) and the Management Console, communicate with cluster components: the Cluster Controllers (CCs) and Storage Controllers (SCs). The CCs and SCs, in turn, communicate with the Node Controllers (NCs). The networks between machines hosting these components must be able to allow TCP connections between them.

Ceph provides an alternative to Walrus as an object storage provider, and can also be used as a block storage provider (EBS).

1.4.1.2 - Plan Your Hardware

This topic describes ways you can install Eucalyptus services on your physical servers.You can run Eucalyptus services in any combination on the various physical servers in a data center. For example, you can install the Cloud Controller (CLC), Walrus, CC, and SC on one host machine, and NCs on one or more host machines. Or you can install each service on an independent physical server. This gives each service its own local resources to work with.

Often in installation decisions, you must trade deployment simplicity for performance. For example, if you place all cloud (CLC) and zone (CC) services on a single machine, it makes for simple administration. This is because there is only one machine to monitor and control for the Eucalyptus control services. But, each service acts as an independent web service; so if they share a single machine, the reduced physical resources available to each service might become a performance bottleneck.

1.4.1.3 - Plan Services Placement

Cloud Services

The main decision for cloud services is whether to install the Cloud Controller (CLC) and Walrus on the same server. If they are on the same server, they operate as separate web services within a single Java environment, and they use a fast path for inter-service communication. If they are not on the same server, they use SOAP and REST to work together.

Sometimes the key factor for cloud services is not performance, but server cost and data center configuration. If you only have one server available for the cloud, then you have to install the services on the same server.

All services should be in the same data center. They use aggressive time-outs to maintain system responsiveness so separating them over a long-latency, lossy network link will not work.

User Services

The User Facing Services (UFS) handle all of the AWS APIs and provide an entry point for clients and users interacting with the Eucalyptus cloud. The UFS and the Management Console are often hosted on the same machine since both must be accessible from the public, client-facing network.

You may optionally choose to have redundant UFS and Management Console host machines behind a load balancer.

Zone Services

The Eucalyptus services deployed in the zone level of a Eucalyptus deployment are the Cluster Controller (CC) and Storage Controller (SC).

You can install all zone services on a single server, or you can distribute them on different servers. The choice of one or multiple servers is dictated by the demands of user workload in terms of number of instances (CC) and EBS volume access (SC).

Things to consider for CC placement:

• Place the CC on a server that has TCP/IP connectivity to the front-end servers and the NC servers in its zone.

• Each CC can manage a maximum of 4000 instances. Things to consider for SC placement:

• The SC host machine must always have TCP/IP connectivity to the CLC and be able use multicast to the CLC.

• The SC must have TCP/IP connectivity to the UFS/OSG hosts for uploading snapshots into the object store. (The SC does not require connectivity directly to users, it is an internal component and does not serve user EBS API requests; that job is done by the UFS.)

• The SC must be reachable via TCP/IP from all NCs in the zone within which the SC is registered. The SC and NC exchange tokens to authorize volume attachment, so they must be able to directly communicate. The SC provides the NCs with network access to the dynamic block volumes on the SC’s storage (if the SC is configured for overlay local filesystem or DAS-JBOD).

• IF using Ceph the SC must also have TCP/IP connectivity to the Ceph cluster.

• If you are going to use overlay local filesystem or DAS-JBOD configurations to export local SC storage for EBS, then SC storage should consist of a fast, reliable disk pool (either local file-system or block-attached storage) so that the SC can create and maintain volumes for the NCs. The capacity of the disk pool should be sufficient to provide the NCs with enough space to accommodate all dynamic block volumes requests from end users.

Node Services

The Node Controllers are the services that comprise the Eucalyptus backend. All NCs must have network connectivity to whatever machine(s) host their EBS volumes. Hosts are either a Ceph deployment or the SC.

1.4.1.4 - Plan Disk Space

We recommend that you choose a disk for the Walrus that is large enough to hold all objects and buckets you ever expect to have, including all images that will ever be registered to your system, plus any Amazon S3 application data. For heavy S3 usage, Riak CS is a better choice for object storage.

If necessary, create symbolic links or mount points to larger filesystems from the above locations. Make sure that the ’eucalyptus’ user owns the directories.

1.4.1.5 - Plan Eucalyptus Features

Plan Features

Before you install Eucalyptus , we recommend that you think about the features you plan to implement with Eucalyptus. These features are detailed in the following sections.

1.4.1.5.1 - Availability Zone Support

Eucalyptus offers the ability to create multiple local availability zones.An availability zone for AWS denotes a large subset of their cloud environment. Eucalyptus refines this definition to denote a subset of the cloud that shares a local area network. Each Eucalyptus zone has its own Cluster Controller and Storage Controller.

1.4.1.5.2 - Object Storage

Eucalyptus supports Walrus and Riak CS as its object storage backend. There is no extra planning if you use Walrus. If you use Riak CS, you can use a single Riak CS cluster for several Eucalyptus clouds. Basho (the vendor of RiakCS) recommends five nodes for each Riak CS cluster. This also means that you have to set up and configure a load balancer between the Riak CS nodes and the object storage gateway (OSG).

1.4.1.6 - Plan Networking Modes

Plan Networking Modes

These networking modes are designed to allow you to choose an appropriate level of security and flexibility for your cloud. The purpose is to direct Eucalyptus to use different network features to manage the virtual networks that connect VMs to each other and to clients external to Eucalyptus .

Eucalyptus networking modes are generally modeled after AWS networking capabilities. In legacy AWS accounts, you have the ability to choose EC2 Classic network mode or VPC network mode. New AWS accounts do not have this flexibility and are forced into using VPC. Eucalyptus VPCMIDO mode is similar to AWS VPC in that it allows users to fully manage their cloud network, including the definition of a Classless Inter-Domain Routing (CIDR) block, subnets, and security groups with rules for additional protocols beyond the default three (UDP, TCP, and ICMP) available in EC2 Classic networking.

Your choice of networking mode depends on the following considerations:

• Does your cloud need to mimic behavior in your AWS account? If you need EC2-Classic behavior, select EDGE mode. If you need EC2-VPC behavior, select VPCMIDO mode.
• Do you need to create security group rules with additional protocols (e.g., all protocols, RDP, XTP, etc.)? If so, choose VPCMIDO mode.
• If there is no specific requirement for either mode, then VPCMIDO mode is recommended given its flexibility and networking features.

Each networking mode is described in the following sections.

1.4.1.6.1 - About 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. Eucanetd manages network functionality. For example:

• Installs network artifacts (iptables, ipsets, ebtables, dhcpd)
• Performs state management for the installed network artifacts
• Updates network artifact configuration as needed
• In VPCMIDO mode:
  • Interacts with MidoNet via the MidoNet API
  • Defines network artifacts in MidoNet

Where to deploy eucanetd

Deploy eucanetd depending on the selected network mode:

When required for a mode eucanetd should be deployed on all hosts for that service.

1.4.1.6.2 - Understanding Eucalyptus EDGE Mode

In EDGE networking mode, the components responsible for implementing Eucalyptus VM networking artifacts are running at the edge of a Eucalyptus deployment: the Linux host machines acting as Node Controllers (NCs). On each NC host machine, a Eucalyptus stand-alone service, eucanetd, runs side-by-side with the NC service. The eucanetd service receives dynamically changing Eucalyptus networking views and is responsible for configuring the Linux networking subsystem to reflect the latest view.

EDGE networking mode integrates with your existing network infrastructure, allowing you to inform Eucalyptus , through configuration parameters for EDGE mode, about the existing network, which Eucalyptus then will consume when implementing the networking view.

EDGE networking mode integrates with two basic types of pre-existing network setups:

• One flat IP network used to service component systems, VM public IPs (elastic IPs), and VM private IPs.
• Two networks, one for components and VM public IPs, and the other for VM private IPs.

EDGE Mode Requirements

• Each NC host machine must have an interface configured with an IP on a VM public and a VM private network (which can be the same network).
• There must be IP connectivity from each NC host machine (where eucanetd runs) and the CLC host machine, so that network path from instances to the metadata server (running on the CLC host machine) can be established.
• There must be a functioning router in place for the private network. This router will be the default gateway for VM instances.
• The private and public networks can be the same network, but they can also be separate networks.
• The NC host machines need a bridge configured on the private network, with the bridge interface itself having been assigned an IP from the network.
• If you’re using a public network, the NC host machines need an interface on the public network as well (if the public and private networks are the same network, then the bridge needs an IP assigned on the network).
• If you run multiple zones, each zone can use the same network as its private network, or they can use separate networks as private networks. If you use separate networks, you need to have a router in place that is configured to route traffic between the networks.
• If you use private addressing only, the CLC host machine must have a route back to the VM private network.

EDGE Mode Limitations

• Global network updates (such as security group rule updates, security group VM membership updates, and elastic IP updates) are applied through an “eventually consistent” mechanism, as opposed to an “atomic” mechanism. That is, there may be a brief period of time where one NC has the new state implemented but another NC has the previous state implemented.
• Mappings between VM MAC addresses and private IPs are strictly enforced. This means that instances cannot communicate using addresses the cloud has not assigned to them.

1.4.1.6.3 - Understanding VPCMIDO and MidoNet

This topic describes MidoNet components and their Eucalyptus deployment options, which provide support for VPC on Eucalyptus. Eucalyptus VPCMIDO mode resembles the Amazon Virtual Private Cloud (VPC) product wherein the network is fully configurable by users. In Eucalyptus, it is implemented with a Software-Defined Networking (SDN) technology called MidoNet. MidoNet is a network virtualization platform for Infrastructure-as-a-Service (IaaS) clouds that implements and exposes virtual network components as software abstractions, enabling programmatic provisioning of virtual networks.

This network mode requires configuration of MidoNet in order to make cloud networking functional. It offers the most advanced networking capabilities and therefore it is recommended to be used on all new Eucalyptus installations.

MidoNet Components

A MidoNet deployment consists of four types of nodes (according to their logical functions or services offered), connected via four IP networks as depicted in Figure 1. MidoNet does not require any specific hardware, and can be deployed in commodity x86_64 servers. Interactions with MidoNet are accomplished through Application Programming Interface (API) calls, which are translated into (virtual) network topology changes. Network state information is stored in a logically centralized data store, called the Network State Database (NSDB), which is implemented on top of two open-source distributed coordination and data store technologies: ZooKeeper and Cassandra. Implementation of (virtual) network topology is realized via cooperation and coordination among MidoNet agents, which are deployed in nodes that participate in MidoNet.

Figure 1: Logical view of a MidoNet deployment. Four components are connected via four networks.

Node types:

• MidoNet Network State Database (NSDB): consists of a cluster of ZooKeeper and Cassandra. All MidoNet nodes must have IP connectivity with NSDB.
• MidoNet API: consists of MidoNet web app. Exposes MidoNet REST APIs.
• Hypervisor: MidoNet agent (Midolman) are required in all Hypervisors to enable VMs to be connected via MidoNet overlay networks/SDN.
• Gateway: Gateway nodes are connected to the public network, and enable the network flow from MidoNet overlays to the public network.

Physical Networks:

• NSDB: IP network that connects all nodes that participate in MidoNet. While NSDB and Tunnel Zone networks can be the same, it is recommended to have an isolated (physical or VLAN) segment.
• API: in deployments only eucanetd/CLC needs access to the API network. Only “special hosts/processes” should have access to this network. The use of “localhost” network on the node running CLC/eucanetd is sufficient and recommended in deployments.
• Tunnel Zone: IP network that transports the MidoNet overlay traffic ( VM traffic), which is not “visible” on the physical network.
• Public network: network with access to the Internet (or corporate/enterprise) network.

MidoNet Deployment Scale

Three reference architectures are presented in this document, ordered by complexity and size:

• Proof-of-Concept (PoC)
• Production: Small
• Production: Large

Production: Large reference architecture represents the most complete and recommended deployment model of MidoNet for Eucalyptus. Whenever possible (such as when resources are available), deployments should closely match with the Production: Large reference architecture (even on small scale clouds).

All MidoNet components are designed and implemented to horizontally scale. Therefore, it is possible to start small and add resources as they become available.

Eucalyptus with MidoNet

A Eucalyptus with MidoNet deployment consists of the following components:

Figure 2: Logical view of a Eucalyptus with MidoNet deployment. VM private network is created/virtualized by MidoNet, and ‘software-defined’ by eucanetd. Ideally, each component and network should have its own set of independent resources. In practice, components are grouped and consolidated into a set of servers, as detailed in different reference architectures.

MidoNet components, Eucalyptus components, and three extra networks are present.

Proof of Concept (PoC)

The PoC reference architecture is designed for very small and transient workloads, typical in development and testing environments. Quick deployment with minimal external network requirements are the key points of PoC reference architecture.

Requirements

Servers:

• Four (4) or more modern Intel cores or AMD modules - exclude logical cores that share CPU resources from the count (Hyperthreads and AMD cores within a module)
• 2GB of RAM reserved for MidoNet Agent (when applicable)
• 4GB of RAM reserved for MidoNet NSDB (when applicable)
• 4GB of RAM reserved for MidoNet API (when applicable)
• 30GB of free disk space for NSDB (when applicable)

Physical Network:

• One (1) 1Gbps IP Network
• A range or list of public IP addresses (Euca_public_IPs)
• Internet Gateway

Limits:

• Ten (10) MidoNet agents (i.e., 1 Gateway node, 1 CLC, and 8 NCs)
• One (1) MidoNet Gateway
• No fail over, fault tolerance, and/or network load balancing/sharing

Deployment Topology

• Single server with all MidoNet components (NSDB, API, and Midolman), and with CLC/eucanetd
• A server acting as MidoNet Gateway - when BGP terminated links are used, this node must not be co-located with CLC/eucanetd (in a proxy_arp setup described below, it is possible to consolidate CLC/eucanetd with MidoNet Gateway). This is due to incompatibilities in CentOS/RHEL7 netns (used by eucanetd), and bgpd (started by Midolman when BGP links are configured).
• Hypervisors with Midolman
• One IP network handling NSDB, Tunnel Zone, and Public Network traffic
• API communication via loopback/localhost network

Figure 3: PoC deployment topology. A single IP network carries NSDB, Tunnel Zone, and Public Network traffic. A single server handles MidoNet NSDB, API (and possibly Gateway) functionality.

MidoNet Gateway Bindings

Three ways to realize MidoNet Gateway bindings are discussed below, starting with the most recommended setup.

Public CIDR block(s) allocated for Eucalyptus (Euca_Public_IPs) needs to be routed to MidoNet Gateway by the customer network - this is an environment requirement, outside of control of both MidoNet and Eucalyptus systems. One way to accomplish this is to have a BGP terminated link available. MidoNet Gateway will establish a BGP session with the customer router to: (1) advertise Euca_Public_IPs to the customer router; and (2) get the default route from the customer router.

If a BGP terminated link is not available, but the routing of Euca_Public_IPs is delegated to MidoNet Gateway (configuration of customer routing infrastructure), similar setup can be used. In such scenario, static routes are configured on the customer router (to route Euca_Public_IPs to MidoNet Gateway), and on MidoNet (to use the customer router as the default route).

Figure 4: How servers are bound to MidoNet in a PoC deployment with BGP. A BGP terminated link is required: the gateway node eth device is bound to MidoNet virtual router (when BGP is involved, the MidoNet Gateway and Eucalyptus CLC cannot be co-located). Virtual machine tap devices are bound to MidoNet virtual bridges.

If routed Euca_Public_IPs are not available, static routes on all involved nodes (L2 connectivity is required among nodes) can be used as illustrated below.

Figure 5: How servers are bound to MidoNet in a PoC deployment without routed Euca_Public_IPs. Clients that need communication with Euca_Public_IPs configure static routes using MidoNet Gateway as the router. MidoNet Gateway configures a static default route to customer router.

In the case nodes outside the public network broadcast domain (L2) needs to access Euca_Public_IPs, a setup using proxy_arp, as illustrated below, can be used.

Figure 6: How servers are bound to MidoNet in a PoC deployment with proxy_arp. When routed Euca_Public_IPs are not available, the gateway node should proxy arp for public IP addresses allocated for Eucalyptus , and forward to a veth device that is bound to a MidoNet virtual router. Virtual machine tap devices are bound to MidoNet virtual bridges.

Production: Small

The Production: Small reference architecture is designed for small scale production quality deployments. It supports MidoNet NSDB fault tolerance (partial failures), and limited MidoNet Gateway failover and load balancing/sharing.

Border Gateway Protocol (BGP) terminated uplinks are recommended for production quality deployments.

Requirements

Servers:

• Four (4) or more modern Intel cores or AMD modules - exclude logical cores that share CPU resources from the count (Hyperthreads and AMD cores within a module) - for gateway nodes, 4 or more cores should be dedicated to MidoNet agent (Midolman)
• 4GB of RAM reserved for MidoNet Agent (when applicable), 8GB for Gateway nodes
• 4GB of free RAM reserved for MidoNet NSDB (when applicable)
• 4GB of free RAM reserved for MidoNet API (when applicable)
• 30GB of free disk space for NSDB (when applicable)
• Two (2) 10Gbps NICs per server
• Three (3) servers dedicated to MidoNet NSDB
• Two (2) servers as MidoNet Gateways

Physical Network:

• One (1) 10Gbps IP Network for public network (if upstream links are 1Gbps, this could be 1Gbps)
• One (1) 10Gbps IP Network for Tunnel Zone and NSDB
• Public Classless Inter-Domain Routing (CIDR) block (Euca_public_IPs)
• Two (2) BGP terminated uplinks

Limits:

• Thirty two (32) MidoNet agents (i.e., 2 Gateway nodes and 30 Hypervisors)
• Two (2) MidoNet Gateways
• Tolerate 1 NSDB server failure
• Tolerate 1 MidoNet Gateway/uplink failure
• Limited uplinks load sharing/balancing

Deployment Topology

• A 3-node cluster for NSDB (co-located ZooKeeper and Cassandra)
• eucanetd co-located with MidoNet API Server
• Two (2) MidoNet Gateway Nodes
• Hypervisors with Midolman
• One 10Gbps IP network handling NSDB and Tunnel Zone traffic
• One 10Gbps IP Network handling Public Network traffic
• API communication via loopback/localhost network

Figure 7: Production:Small deployment topology. A 10Gbps IP network carries NSDB and Tunnel Zone traffic. Another 10Gbps IP network carries Public Network traffic. A 3-node cluster for NSDB tolerates 1 server failure, and 2 gateways enable network failover and limited load balancing/sharing.

Figure 8: How servers are bound to MidoNet in a Production:Small deployment. Gateway Nodes have physical devices bound to a MidoNet virtual router. These devices should have L2 and L3 connectivity to the Customer’s Router, and with BGP terminated links. Virtual machine tap devices are bound to MidoNet virtual bridges.

NSDB Data Replication

• NSDB is deployed in a cluster of 3 nodes
• ZooKeeper and Cassandra both have built-in data replication
• One server failure is tolerated

MidoNet Gateway Failover

• Two paths are available to and from MidoNet, and failover is handled by BGP

MidoNet Gateway Load Balancing and Sharing

• Load Balancing from MidoNet is implemented by MidoNet agents (Midolman): ports in a stateful port group with default routes out are used in a round-robin fashion.
• Partial load sharing from the Customer’s router to MidoNet can be accomplished by:

Production: Large

The Production:Large reference architecture is designed for large scale (500 to 600 MidoNet agents) production quality deployments. It supports MidoNet NSDB fault tolerance (partial failures), and MidoNet Gateway failover and load balancing/sharing.

Border Gateway Protocol (BGP) terminated uplinks are required. Each uplink should come from an independent router.

Requirements:

• Eight (8) or more modern Intel cores or AMD modules - exclude logical cores that share CPU resources from the count (Hyperthreads and AMD cores within a module) - for gateway nodes, 8 or more cores should be dedicated to MidoNet agent (Midolman)
• 4GB of RAM reserved for MidoNet Agent (when applicable), 16GB for Gateway nodes
• 4GB of free RAM reserved for MidoNet NSDB (when applicable)
• 4GB of free RAM reserved for MidoNet API (when applicable)
• 30GB of free disk space for NSDB (when applicable)
• One 1Gbps and 2 10Gbps NICs per server
• Five (5) servers dedicated to MidoNet NSDB
• Three (3) servers as MidoNet Gateways

Physical Network:

• One 1Gbps IP Network for NSDB
• One 10Gbps IP Network for public network (if upstream links are 1Gbps, this could be 1Gbps)
• One 10Gbps IP Network for Tunnel Zone
• Public Classless Inter-Domain Routing (CIDR) block (Euca_public_IPs)
• Three (3) BGP terminated uplinks, each of which coming from an independent router
• ZooKeeper performance recommendations:

Limits:

• 500 to 600 MidoNet agents
• Three (3) MidoNet Gateways
• Tolerate 1 to 2 NSDB server failures
• Tolerate 1 to 2 MidoNet Gateway/uplink failures

Deployment Topology

• A 5-node cluster for NSDB (co-located ZooKeeper and Cassandra)
• eucanetd co-located with MidoNet API Server
• Three (3) MidoNet Gateway Nodes
• Hypervisors with Midolman
• One 1Gbps IP network handling NSDB traffic
• One 10Gbps IP network handling Tunnel Zone traffic
• One 10Gbps IP network handling Public Network traffic
• API communication via loopback/localhost network

Figure 9: Production:Large deployment topology. A 1Gbps IP network carries NSDB; a 10Gbps IP network carries Tunnel Zone traffic; and another 10Gbps IP network carries Public Network traffic. A 5-node cluster for NSDB tolerates 2 server failures, and 3 gateways enable network failover and load balancing/sharing. Servers are bound to MidoNet in a way similar to Production:Small.

NSDB Data Replication

• NSDB is deployed in a cluster of 5 nodes
• ZooKeeper and Cassandra both have built-in data replication
• Up to 2 server failures tolerated

MidoNet Gateway Failover

• Three paths are available to and from MidoNet, and failover is handled by BGP

MidoNet Gateway Load Balancing/Sharing

• Load Balancing from MidoNet is implemented by MidoNet agents (Midolman): ports in a stateful port group with default routes out are used in a round-robin fashion.
• The customer AS should handle multi path routing in order to support load sharing/balancing to MidoNet; for example, Equal Cost Multi Path (ECMP).

1.4.1.7 - Prepare the Network

Prepare the Network

1.4.1.7.1 - Reserve Ports

1.4.1.7.2 - Verify Connectivity

Verify connection from an end-user to the CLC on TCP port 8773 Verify connection from an end-user to Walrus on TCP port 8773 Verify connection from the CLC, SC, and NC to SC on TCP port 8773 Verify connection from the CLC, SC, and NC to Walrus on TCP port 8773 Verify connection from Walrus and SC to CLC on TCP port 8777 Verify connection from CLC to CC on TCP port 8774 Verify connection from CC to NC on TCP port 8775 Verify connection from NC to Walrus on TCP port 8773. Or, you can verify the connection from the CC to Walrus on port TCP 8773, and from an NC to the CC on TCP port 8776 Verify connection from public IP addresses of Eucalyptus instances (metadata) and CC to CLC on TCP port 8773 Verify TCP connectivity between CLC, Walrus, and SC on TCP port 8779 (or the first available port in range 8779-8849)  Verify connection between CLC, Walrus, and SC on UDP port 7500 Verify multicast connectivity for IP address 239.193.7.3 between CLC and UFS, OSG, Walrus, and SC on UDP port 8773 If DNS is enabled, verify connection from an end-user and instance IPs to DNS ports If you use tgt (iSCSI open source target) for EBS in DAS or Overlay modes, verify connection from NC to SC on TCP port 3260

1.4.2 - Configure Dependencies

Configure Dependencies

Before you install Eucalyptus , ensure you have the appropriate dependencies installed and configured.

1.4.2.1 - Configure Bridges

To configure a bridge on CentOS 7 or RHEL 7, you need to create a file with bridge configuration (for example, ifcfg-brX) and modify the file for the physical interface (for example, ifcfg-ethX). The following steps describe how to set up a bridge on both CentOS 7 and RHEL 7. We show examples for configuring bridge devices that either obtain IP addresses using DHCP or statically.

Install the bridge-utils package.

yum install bridge-utils

Go to the /etc/sysconfig/network-scripts directory:

cd /etc/sysconfig/network-scripts

Open the network script for the device you are adding to the bridge and add your bridge device to it. The edited file should look similar to the following:

DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no

Create a new network script in the /etc/sysconfig/network-scripts directory called ifcfg-br0 or something similar. The br0 is the name of the bridge, but this can be anything as long as the name of the file is the same as the DEVICE parameter, and the name is specified correctly in the previously created physical interface configuration (ifcfg-ethX).

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

If you are using a static IP address, the configuration will look similar to:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
IPADDR=static_IP_address
NETMASK=netmask
GATEWAY=gateway
ONBOOT=yes

Enter the following command:

systemctl restart network.service

1.4.2.2 - Disable FirewallD on RHEL 7

This topic describes how to stop and disable FirewallD on RHEL 7.Prerequisites

• You should have successfully installed RHEL 7 before this task. If you have existing firewall rules on your host machines, you must disable the firewall in order to install Eucalyptus . You should re-enable it after installation.

  Note

  The firewall on a RHEL 7 system is enabled by default. Before you restart the CLC, you must disable the firewalld service on all host machines.

For more information, see FirewallD on RHEL 7 or FirewallD on CentOS .

To stop and disable FirewallD Check the status of the firewalld service:

systemctl status firewalld.service

The status displays as active (running) or inactive (dead) . If the firewall is active / running, enter this command to stop it:

systemctl stop firewalld.service

To completely disable the firewalld service, so it does not reload when you restart the host machine:

systemctl disable firewalld.service

Verify the status of the firewalld service:

systemctl status firewalld.service

The status should display as disabled and inactive (dead) .

firewalld.service - firewalld - dynamic firewall daemon
  Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
  Active: inactive (dead)

Repeat these steps for all host machines. The firewalld service is stopped and disabled. You can now start the CLC and other host machines.

Postrequisites

• You should re-enable the firewall after installation is complete.

1.4.2.3 - Configure NTP

To use NTP:

Install NTP on the machines that will host Eucalyptus components.

yum install ntp

Open the /etc/ntp.conf file and add NTP servers, if necessary, as in the following example.

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

Save and close the file. Synchronize your server.

ntpdate -u YOUR_NTP_SERVER

Configure NTP to run at reboot.

systemctl enable ntpd.service

Start NTP.

systemctl start ntpd.service

Synchronize your system clock, so that when your system is rebooted, it does not get out of sync.

hwclock --systohc

Repeat on each host machine that will run a Eucalyptus service.

1.4.2.4 - Configure Java

For the supported version of the Java Virtual Machine (JVM), see the Compatibility Matrix in the Release Notes .

As of Eucalyptus 4.3, JVM 8 is required. Eucalyptus RPM packages require java-1.8.0-openjdk, which will be installed automatically.

To use Java with Eucalyptus cloud:

Open the /etc/eucalyptus/eucalyptus.conf file. Verify that the CLOUD_OPTS setting does not set –java-home , or that –java-home points to a supported JVM version.

1.4.2.5 - Configure an MTA

You can use Sendmail, Exim, postfix, or something simpler. The MTA server does not have to be able to receive incoming mail.

Many Linux distributions satisfy this requirement with their default MTA. For details about configuring your MTA, go to the documentation for your specific product.

To test your mail relay for localhost, send email to yourself from the terminal using mail .

1.4.2.6 - Install MidoNet

Install MidoNet

Eucalyptus requires MidoNet for VPC functionality. This section describes how to install MidoNet for use with Eucalyptus.

Before you begin:

• See the Planning your Network section of the guide to create a map of how MidoNet / will be deployed into your environment.
• See the MidoNet Installation Guide to become familiar with the general MidoNet installation procedure and concepts.

1.4.2.6.1 - Prerequisites

This topic discusses the prerequisites for installing MidoNet 5.2.

You need to configure software repositories and install Network State Database (NSDB) services: ZooKeeper and Cassandra.

Repository Access

In order to use MidoNet with Eucalyptus you need to configure the MidoNet repositories.

Create /etc/yum.repos.d/midonet.repo and /etc/yum.repos.d/midonet-misc.repo on all host machines that will run MidoNet components including ZooKeeper and Cassandra. For example:

[midonet]
name=MidoNet
baseurl=http://builds.midonet.org/midonet-5.2/stable/el7/
enabled=1
gpgcheck=1
gpgkey=https://builds.midonet.org/midorepo.key

and:

[midonet-misc]
name=MidoNet 3rd Party Tools and Libraries
baseurl=http://builds.midonet.org/misc/stable/el7/
enabled=1
gpgcheck=1
gpgkey=https://builds.midonet.org/midorepo.key

See MidoNet Repository Configuration.

ZooKeeper

MidoNet uses Apache ZooKeeper to store critical path data about the virtual and physical network topology.

For a simple single-server installation, install ZooKeeper on any server that is IP accessible from all Midolman agents (for example: on the CLC host machine itself). You can also cluster ZooKeeper for fault tolerance. See MidoNet NSDB ZooKeeper Installation.

Enable and start the ZooKeeper service before installing the other MidoNet services.

Cassandra

MidoNet uses Apache Cassandra to store flow state information.

For a simple single-server installation, install Cassandra on any server that is IP accessible from all Midolman agents (for example: on the CLC host machine itself). You can also cluster Cassandra for fault tolerance. See MidoNet NSDB Cassandra Installation.

Enable and start the Cassandra service before installing the other MidoNet services.

1.4.2.6.2 - MidoNet Component Topology

This topic lists topology recommendations for installing MidoNet.

• The midonet-api must run co-located with the Cloud Controller (CLC).
• Each Node Controller (NC) must run a Midolman agent.
• The Cloud Controller (CLC) must run a Midolman agent.
• It is recommended that your User Facing Services (UFS) host be used as the MidoNet Gateway (i.e., running a Midolman agent) when configuring .
• The network interface(s) specified as * (in the configuration file) should be dedicated for /MidoNet (for configuration/operation/use).
• /MidoNet expects exclusive use of the network interface specified in .
• If the main network interface of a server is specified in , most likely the connectivity to that server will be lost once is deployed.

Network YAML Example

The following Eucalyptus network YAML file shows a sample VPCMIDO mode configuration:

Mode: VPCMIDO

InstanceDnsServers:
- "10.10.10.1"

PublicIps:
- "1.A.B.1-1.A.B.255"

Mido:
  Gateways:
  - ExternalCidr: "172.19.0.0/30"
    ExternalDevice: "veth1"
    ExternalIp: "172.19.0.2"
    ExternalRouterIp: "172.19.0.1"
    Ip: "10.10.10.1"

Where 1.A.B.1-1.A.B.255 represents the public IP address range for your cloud.

1.4.2.6.3 - Install MidoNet for Eucalyptus

This topic shows how to install MidoNet for use in your Eucalyptus cloud.

Install the MidoNet Cluster on the Cloud Controller (CLC)

This topic describes how to install the MidoNet Cluster. MidoNet Cluster services provide a means to manage MidoNet functions that MidoNet agents (Midolman) are unable to perform on their own. MidoNet Cluster services include state synchronization of VxLAN gateways and the MidoNet REST API. A MidoNet v5 deployment requires at least one MidoNet cluster node, and it must be co-located on the CLC host machine in Eucalyptus deployments. For security reasons, the MidoNet REST API is accessed only on the CLC (localhost interface).

To install the MidoNet Cluster on the CLC

Add the MidoNet repo file as described in Prerequisites . Install MidoNet Cluster packages.

yum install midonet-cluster python-midonetclient

Edit the /etc/midonet/midonet.conf file to set the ZooKeeper host IP(s). Replace ZOOKEEPER_HOST_IP in the following example:

[zookeeper]
zookeeper_hosts = ZOOKEEPER_HOST_IP:2181 

Configure cloud-wide access to the NSDB services:

cat << EOF | mn-conf set -t default
zookeeper {
  zookeeper_hosts = “ZOOKEEPER_HOST:2181"
}

cassandra {
  servers = “CASSANDRA_HOST"
}
EOF

Enable and start the MidoNet Cluster:

systemctl enable midonet-cluster.service
systemctl start midonet-cluster.service

Set the midonet-api end point:

mn-conf set cluster.rest_api.http_port=8080
mn-conf set cluster.rest_api.http_host="127.0.0.1"

Restart the Midonet Cluster so the rest_api parameters take effect:

systemctl restart midonet-cluster.service

Install Midolman on components

This topic describes how to install the Midolman agent. Midolman is the MidoNet Agent, which is a daemon that runs on all hosts where traffic enters and leaves MidoNet. The Midolman agent is required on the Cloud Controller (CLC), Node Controllers (NCs), and any host that is a MidoNet Gateway node (e.g., UFS).

To install Midolman agent

Edit the /etc/midolman/midolman.conf file to set the ZooKeeper host IP(s). Replace ZOOKEEPER_HOST_IP in the following example:

[zookeeper]
zookeeper_hosts = ZOOKEEPER_HOST_IP:2181

Enable and start Midolman:

systemctl enable midolman.service
systemctl start midolman.service

Configure a Midolman resource usage template. For large Eucalyptus clouds, use the agent-compute-large template. For standard (small or medium) Eucalyptus clouds, use the default template. For gateway nodes, use the agent-gateway templates.

See the Midolman Installation documentation for more information.

Choose the Midolman resource usage template name, based on the size and type of installation:

agent-compute-large
agent-compute-medium
agent-gateway-large
agent-gateway-medium
default

Run this command, replacing TEMPLATE_NAME with your chosen template:

mn-conf template-set -h local -t TEMPLATE_NAME

Create a tunnel zone in MidoNet and add hosts

This topic describes how to create a MidoNet tunnel zone. In MidoNet, a tunnel zone is an isolation zone for hosts. Physical hosts that are members of a given tunnel zone communicate directly with one another and establish network tunnels as needed, and on demand. These network tunnels are used to transport overlay traffic (e.g., inter-VM communication) and isolate the underlay physical network communication (i.e., inter-physical hosts communication). On a Eucalyptus deployment, one MidoNet tunnel zone is expected with the IP address on the physical network designated to carry VM traffic being used when configuring its members. Eucalyptus accepts the following tunnel zone names:

• eucatz
• euca-tz
• midotz
• mido-tz

For more information, see What are Tunnel Zones?

To create a tunnel zone in MidoNet

Log into the MidoNet shell. For example:

midonet-cli -A --midonet-url=http://127.0.0.1:8080/midonet-api

Create a GRE tunnel zone:

[root@clcfrontend mido-docs]# midonet-cli -A --midonet-url=http://127.0.0.1:8080/midonet-api
midonet> tunnel-zone add name eucatz type gre
midonet> tunnel-zone list
tzone tzone0 name eucatz type gre
midonet> host list
host host0 name node1 alive true
host host1 name clcfrontend alive true
host host2 name node2 alive true

You should see a host listed for each of your Node Controllers and for your User Facing Service host; if not, check the /var/log/midolman/midolman.log log file on the missing hosts to ensure there are no error messages.

After verifying all your hosts are listed, add each host to your tunnel zone as follows. Replace HOST_N_IP with the IP of your Node Controller or User Facing Service host that you used to register the component with Eucalyptus :

midonet> tunnel-zone tzone0 add member host host0 address HOST_0_IP
midonet> tunnel-zone tzone0 add member host host1 address HOST_1_IP
midonet> tunnel-zone tzone0 add member host host2 address HOST_2_IP

You are now ready to install and configure Eucalyptus to use this MidoNet installation.

Additional ZooKeeper Configuration

Ongoing data directory cleanup is required for ZooKeeper. The following parameters should be added in /etc/zookeeper/zoo.cfg for automatic purging of the snapshots and corresponding transaction logs:

autopurge.snapRetainCount=3  # The number of snapshots to retain in dataDir
autopurge.purgeInterval=1  # Purge task interval in hours

For more information, see ZooKeeper Admin Guide, Ongoing Data Directory Cleanup.

1.4.3 - Install Repositories

Install Repositories

This section guides you through installing Eucalyptus from RPM package downloads.The first step to installing Eucalyptus is to download the RPM packages. When you’re ready, continue to Software Signing .

The following terminology might help you as you proceed through this section.

Eucalyptus open source software — Eucalyptus release packages and dependencies, which enable you to deploy a Eucalyptus cloud.

Euca2ools CLI — Euca2ools is the Eucalyptus command line interface for interacting with web services. It is compatible with many Amazon AWS services, so can be used with Eucalyptus as well as AWS.

RPM and YUM and software signing — Eucalyptus CentOS and RHEL download packages are in RPM (Red Hat Package Manager) format and use the YUM package management tool. We use GPG keys to sign our software packages and package repositories.

EPEL software — EPEL (Extra Packages for Enterprise Linux) are free, open source software, which is fully separated from licensed RHEL distribution. It requires its own package.

1.4.3.1 - Software Signing

This topic describes Eucalyptus software signing keys.We use a number of GPG keys to sign our software packages and package repositories. The necessary public keys are provided with the relevant products and can be used to automatically verify software updates. You can also verify the packages or package repositories manually using the keys on this page.

Use the rpm --checksig command on a download file to verify a RPM package for an Eucalyptus product. For example:

rpm --checksig -v myfilename.rpm

Follow the procedure detailed on Debian’s SecureApt web page to verify a deb package for an Eucalyptus product.

Please do not use package signing keys to encrypt email messages.

The following keys are used for signing Eucalyptus software:

c1240596: Eucalyptus Systems, Inc. (release key) security@eucalyptus.com

This key is used for signing Eucalyptus products released after July 2011 and their updates.

• Fingerprint:

0260cf4e: Eucalyptus Systems, Inc. (pre-release key) security@eucalyptus.com

This key is used for signing Eucalyptus pre-release products due for release after July 2011.

• Fingerprint:

9d7b073c: Eucalyptus Systems, Inc. (nightly release key) security@eucalyptus.com

This key is used for signing nightly builds of Eucalyptus products published after July 2011.

• Fingerprint:

1.4.3.2 - Install Eucalyptus Release Packages

To install Eucalyptus from release packages, perform the tasks listed in this topic.

Prerequisites

• The prerequisite hardware and software should be in place.

To install Eucalyptus from release packages

Configure the Eucalyptus package repository on each host machine that will run a Eucalyptus service:

yum install https://downloads.eucalyptus.cloud/software/eucalyptus/5/rhel/7/x86_64/eucalyptus-release-5-1.11.as.el7.noarch.rpm

Enter y when prompted to install this package.

Configure the Euca2ools package repository on each host machine that will run a Eucalyptus service or Euca2ools:

yum install https://downloads.eucalyptus.cloud/software/euca2ools/3.4/rhel/7/x86_64/euca2ools-release-3.4-2.2.as.el7.noarch.rpm

Enter y when prompted to install this package.

Configure the EPEL package repository on each host machine that will run a Eucalyptus service or Euca2ools:

yum install epel-release

Enter y when prompted to install this package.

If you are installing on RHEL 7, you must enable the Optional repository in Red Hat Network for each NC, as follows: Go to http://rhn.redhat.com and navigate to the system that will run the NC. Click Alter Channel Subscriptions . Make sure the RHEL Server Optional check-box is selected. Click Change Subscriptions .

On CentOS enable the QEMU Enterprise Virtualization repository for each NC:

yum install centos-release-qemu-ev

The following steps should be performed on each NC host machine. Install the Eucalyptus Node Controller software on each NC host:

yum install eucalyptus-node

Remove the default libvirt network. This step allows the eucanetd dhcpd server to start.

virsh net-destroy default
virsh net-autostart default --disable

Check that the KVM device node has proper permissions. Run the following command:

ls -l /dev/kvm

Verify the output shows that the device node is owned by user root and group kvm.

crw-rw-rw- 1 root kvm 10, 232 Nov 30 10:27 /dev/kvm

If your KVM device node does not have proper permissions, you need to reboot your NC host.

On each CLC host machine, install the Eucalyptus Cloud Controller software.

yum install eucalyptus-cloud

Install the backend service image package on the machine hosting the CLC:

yum install eucalyptus-service-image

This installs worker images for both the load balancer and imaging services. On the UFS host machine, install the Eucalyptus Cloud Controller software.

yum install eucalyptus-cloud

(Optional) On the UFS host machine, also install the Management Console.

yum install eucaconsole

The Management Console can run on any host machine, even one that does not have other Eucalyptus services . Install the software for the remaining Eucalyptus services. The following example shows services being installed on the same host machine.

yum install eucalyptus-cluster eucalyptus-sc eucalyptus-walrus

This installs the cloud controller (CC), storage controller (SC), and Walrus Backend (Optional) services.

Your package installation is complete. You are now ready to Configure Eucalyptus .

1.4.4 - Configure Eucalyptus

This section describes the parameters you need to set in order to launch Eucalyptus for the first time.

The first launch of Eucalyptus is different than a restart of a previously running Eucalyptus deployment in that it sets up the security mechanisms that will be used by the installation to ensure system integrity.

Eucalyptus configuration is stored in a text file, /etc/eucalyptus/eucalyptus.conf, that contains key-value pairs specifying various configuration parameters.

1.4.4.1 - Configure SELinux

We recommend enabling SELinux on host systems running Eucalyptus 4.4 services to improve their security on RHEL 7. Enabling SELinux, as described in this topic, can help contain break-ins. For more information, see RedHat SELinux documentation.

You need to set boolean values on Storage Controller (SC) and Management Console host machines. If your network mode is VPCMIDO, you also set a boolean value on the Cloud Controller (CLC) host machines. To configure SELinux on Eucalyptus 4.4 :

On each Storage Controller (SC) host machine, run the following command:

setsebool -P eucalyptus_storage_controller 1

This allows Eucalyptus to manage EBS volumes.

On each Management Console host machine, run the following command:

setsebool -P httpd_can_network_connect 1

This allows the Management Console’s HTTP proxy to access the back end.

If your cloud uses VPCMIDO networking mode, on the Cloud Controller (CLC), run the following command:

setsebool -P httpd_can_network_connect 1

This allows the CLC’s HTTP proxy to access the back end.

SELinux is now configured and ready to use with your Eucalyptus 4.4 cloud.

1.4.4.2 - Configure Network Modes

This section provides configuration instructions for Eucalyptus networking modes. Eucalyptus overlays a virtual network on top of your existing network. In order to do this, Eucalyptus supports these networking modes: EDGE (AWS EC2 Classic compatible) and VPCMIDO (AWS VPC compatible).

1.4.4.2.1 - Configure EDGE Network Mode

This topic provides configuration instructions for Eucalyptus EDGE network mode. Eucalyptus requires network connectivity between its clients (end-users) and the cloud components (e.g., CC, CLC, and Walrus).

To configure Eucalyptus for EDGE mode, most networking configuration is handled through settings in a global Cloud Controller (CLC) property file.

The /etc/eucalyptus/eucalyptus.conf file contains some network-related options in the “Networking Configuration” section. These options use the prefix VNET_. The most commonly used VNET options are described in the following table.

The most commonly used VNET options are described in the following table.

You must edit eucalyptus.conf on the Cluster Controller (CC) and Node Controller (NC) hosts. You must also create a network configuration file and upload it the Cloud Controller (CLC).

CC Configuration

Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf file. Go to the Network Configuration section, uncomment and set the following:

VNET_MODE="EDGE"

Save the file. Repeat on each CC in your cloud.

NC Configuration

Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf file. Go to the Network Configuration section, uncomment and set the following parameters:

VNET_MODE
VNET_PRIVINTERFACE
VNET_PUBINTERFACE
VNET_BRIDGE
VNET_DHCPDAEMON

For example:

VNET_MODE="EDGE"
VNET_PRIVINTERFACE="br0"
VNET_PUBINTERFACE="br0"
VNET_BRIDGE="br0"
VNET_DHCPDAEMON="/usr/sbin/dhcpd"

Save the file. Repeat on each NC.

Cloud Configuration

To configure the rest of the EDGE mode parameters, you must create a network.yaml configuration file. Later in the installation process you will Upload the Network Configuration to the CLC.

Create the network configuration file. Open a text editor. Create a file similar to the following structure.

# A list of servers that instances receive to resolve DNS names
InstanceDnsServers:
- ""

# List of public IP addresses or address ranges
PublicIps:
- ""

# A list of cluster objects that define each availability zone (AZ) in your cloud
Clusters:
-
  # Name of the cluster as it was registered
  Name: ""
  
  # Subnet definition that this cluster will use for private addressing
  Subnet:
    # Arbitrary name for the subnet
    Name: ""

    # The subnet that will be used for private addressing
    Subnet: ""

    # Netmask for the subnet defined above
    Netmask: ""

    # Gateway that will route packets for the private subnet
    Gateway: ""

  # List of Private IP addresses or address ranges for instances   
  PrivateIps:
  - ""

Save the network.json file. The following example is for a setup with one cluster (AZ), called PARTI00, with a flat network topology.

InstanceDnsServers:
- "10.1.1.254"

PublicIps:
- "10.111.101.84"
- "10.111.101.91-10.111.101.93"

Clusters:
- Name: PARTI00

  Subnet:
    Name: "10.111.0.0"
    Subnet: "10.111.0.0"
    Netmask: "255.255.0.0"
    Gateway: "10.111.0.1"

  PrivateIps:
  - "10.111.101.94"
  - "10.111.101.95"

For a multi-cluster deployment, add an additional cluster to your configuration for each cluster you have. The following example has an two clusters, PARTI00 and PARTI01.

InstanceDnsServers:
- "10.1.1.254"

PublicIps:
- "10.111.101.84"
- "10.111.101.91-10.111.101.93"

Clusters:
- Name: PARTI00

  Subnet:
    Name: "10.111.0.0"
    Subnet: "10.111.0.0"
    Netmask: "255.255.0.0"
    Gateway: "10.111.0.1"

  PrivateIps:
  - "10.111.101.94"
  - "10.111.101.95"

- Name: PARTI01

  Subnet:
    Name: "10.111.0.0"
    Subnet: "10.111.0.0"
    Netmask: "255.255.0.0"
    Gateway: "10.111.0.1"

  PrivateIps:
  - "10.111.101.96"
  - "10.111.101.97"

1.4.4.2.2 - Configure VPCMIDO Network Mode

This topic provides configuration instructions for Eucalyptus VPCMIDO network mode. Eucalyptus requires network connectivity between its clients (end-users) and the cloud components (e.g., CC, CLC, and storage).

To configure VPCMIDO mode parameters, you must create a network.yaml configuration file. Later in the installation process you will Upload the Network Configuration to the CLC.

Create the network configuration file. Open a text editor. Create a file similar to the following structure. This example demonstrates two gateways and two BGP peers (sections relevant to VPCMIDO are shown here).

Mode: VPCMIDO

PublicIps:
- "10.116.150.10-10.116.150.254"
- "10.117.150.10-10.117.150.254"

Mido:
  BgpAsn: "64512"
  Gateways:
  - Ip: "10.111.5.11"
    ExternalDevice: "em1.116"
    ExternalCidr: "10.116.128.0/17"
    ExternalIp: "10.116.133.11"
    BgpPeerIp: "10.116.133.173"
    BgpPeerAsn: "65000"
    BgpAdRoutes:
    - "10.116.150.0/24"
  - Ip: "10.111.5.22"
    ExternalDevice: "em1.117"
    ExternalCidr: "10.117.128.0/17"
    ExternalIp: "10.117.133.22"
    BgpPeerIp: "10.117.133.173"
    BgpPeerAsn: "65001"
    BgpAdRoutes:
    - "10.117.150.0/24"

Save the network.yaml file. The following example demonstrates a gateway with static routing configuration.

Mode: VPCMIDO

PublicIps:
- "10.116.150.10-10.116.150.254"

Mido:
  Gateways:
  - Ip: "10.111.5.11"
    ExternalDevice: "em1.116"
    ExternalCidr: "10.116.128.0/17"
    ExternalIp: "10.116.133.11"
    ExternalRouterIp: "10.116.133.173"

1.4.4.2.2.1 - VPCMIDO Gateway Configuration Parameters

This topic provides detailed configuration parameter information for Eucalyptus VPCMIDO network mode.

VPCMIDO Gateway Configuration

The following table provides a list of VPCMIDO parameters.

Gateways with BGP require BgpPeerAsn , BgpAdRoutes , and BgpAsn . If all gateways are static (no BGP), BgpAsn is optional. A gateway with BGP has BgpPeerAsn and BgpAdRoutes parameters; a static gateway does not.

1.4.4.3 - Create Scheduling Policy

This topic describes how to set up the Cluster Controller (CC) to choose which Node Controller (NC) to run each new instance.In the CC, open the /etc/eucalyptus/eucalyptus.conf file. In the SCHEDPOLICY= parameter, set the value to one of the following: GREEDY When the CC receives a new instance run request, it runs the instance on the first NC in an ordered list of NCs that has capacity to run the instance. At partial capacity with some amount of churn, this policy generally results in a steady state over time where some nodes are running many instances, and some nodes are running few or no instances. ROUNDROBIN (Default) When the CC receives a new instance run request, it runs the instance on the next NC in an ordered list of NCs that has capacity. The next NC is determined by the last NC to have received an instance. At partial capacity with some amount of churn, this policy generally results in a steady state over time where instances are more evenly distributed across the set of NCs. Save the file.

1.4.5 - Start Eucalyptus

Start

Start the Eucalyptus services in the order presented in this section. Make sure that each host machine you installed a Eucalyptus service on resolves to an IP address. Edit the /etc/hosts file if necessary.

1.4.5.1 - Start the CLC

Prerequisites You should have installed and configured Eucalyptus before starting the CLC.

To initialize and start the CLC

Log in to the Cloud Controller (CLC) host machine. Enter the following command to initialize the CLC:

clcadmin-initialize-cloud

This command might take a minute or more to finish. If it fails, check /var/log/eucalyptus/cloud-output.log . If you want the CLC service to start at each boot-time, run this command:

systemctl enable eucalyptus-cloud.service

Enter the following command to start the CLC:

systemctl start eucalyptus-cloud.service

If you are running in VPCMIDO networking mode: If you want the eucanetd service to start at each boot-time, run this command:

systemctl enable eucanetd.service

Start the eucanetd service:

systemctl start eucanetd.service

1.4.5.2 - Start the UFS

Prerequisites You should have installed and configured Eucalyptus before starting the UFS.

To start the UFS

Log in to the User-Facing Services (UFS) host machine. If you want the UFS service to start at each boot-time, run this command:

systemctl enable eucalyptus-cloud.service

Enter the following command to start the UFS:

systemctl start eucalyptus-cloud.service

Repeat for each UFS host machine.

1.4.5.3 - Start Walrus

Prerequisites

You should have installed and configured Eucalyptus before starting the Walrus Backend.

To start the Walrus

If you want the Walrus Backend service to start at each boot-time, run this command:

systemctl enable eucalyptus-cloud.service

Log in to the Walrus Backend host machine and enter the following command:

systemctl start eucalyptus-cloud.service

1.4.5.4 - Start the CC

Prerequisites

You should have installed and configured Eucalyptus before starting the CC.

To start the CC

Log in to the Cluster Controller (CC) host machine. If you want the CC service to start at each boot-time, run this command:

systemctl enable eucalyptus-cluster.service

Enter the following command to start the CC:

systemctl start eucalyptus-cluster.service

If you have a multi-zone setup, repeat this step on the CC in each zone.

1.4.5.5 - Start the SC

Prerequisites

You should have installed and configured Eucalyptus before starting the SC.

To start the SC

Log in to the Storage Controller (SC) host machine. If you want the SC service to start at each boot-time, run this command:

systemctl enable eucalyptus-cloud.service

If you want the tgtd service to start at each boot-time, run this command:

systemctl enable tgtd.service

Enter the following commands to start the SC:

systemctl start tgtd.service

systemctl start eucalyptus-cloud.service

If you have a multi-zone setup, repeat this step on the SC in each zone.

1.4.5.6 - Start the NC

Prerequisites You should have installed and configured Eucalyptus before starting the NC.

To start the NC

Log in to the Node Controller (NC) host machine. If you want the NC service to start at each boot-time, run this command:

systemctl enable eucalyptus-node.service

Enter the following command to start the NC:

systemctl start eucalyptus-node.service

If you are running in EDGE networking mode: If you want the eucanetd service to start at each boot-time, run this command:

systemctl enable eucanetd.service

Start the eucanetd service:

systemctl start eucanetd.service

Repeat for each NC host machine.

1.4.5.7 - Start the Management Console

Log in to the Management Console host machine. If you want the console service to start at each boot-time, run this command:

systemctl enable eucaconsole.service

Enter the following command to start the console:

systemctl start eucaconsole.service

Repeat for each Management Console host machine.

1.4.5.8 - Verify the Startup

At this point, all Eucalyptus services are enabled and starting up. Some of these services perform intensive initialization at start-up, particularly the first time they are started. You might have to wait a few minutes until they are fully operational.

One quick way to determine if the components are running is to run netstat on the various hosts and look to see when the service ports are allocated to a process. Specifically, the CLC, Walrus, and the SC allocate ports 8773. The CC listens to port 8774, and the NC uses port 8775.

Verify that everything has started without error. Expected outcomes include:

• The CLC is listening on port 8773
• Walrus is listening on port 8773
• The SC is listening on port 8773
• The CC is listening on port 8774
• The NCs are listening on port 8775
• Log files are being written to

1.4.6 - Register Eucalyptus Services

Register Services

This section describes how to register Eucalyptus services.

Eucalyptus implements a secure protocol for registering separate services so that the overall system cannot be tricked into including a service run by an unauthorized administrator or user.

You need only register services once. Most registration commands run on the CLC server.

Note that each registration command will attempt an SSH as root to the remote physical host where the registering service is assumed to be running. The registration command also contacts the service so it must be running at the time the command is issued. If a password is required to allow SSH access, the command will prompt the user for it.

Registration commands need the following information:

• The of service you are registering. Required. For example: .
• The of the service being registered. Required. The host must be specified by IP address to function correctly.
• The the service belongs to. This is roughly equivalent to the availability zone in AWS.
• The you assign to each instance of a service, up to 256 characters. Required. This is the name used to identify the service in a human-friendly way. This name is also used when reporting system state changes that require administrator attention.

1.4.6.1 - Register User-Facing Services

This topic describes how to register the User-Facing Services (UFS) with the Cloud Controller (CLC).

Prerequisites

• The Cloud Controller must be properly installed and started.
• The User-Facing Services must be properly installed and started.

To register the User-Facing Services with the Eucalyptus cloud

On the CLC host machine, obtain your temporary access keys for the Eucalyptus set up by running the following command:

eval `clcadmin-assume-system-credentials`

Also on the CLC host machine, run the following command:

euserv-register-service -t user-api -h IP SVCINSTANCE

where:

• SVCINSTANCE is the IP address of the UFS you are registering.
• must be a unique name for the User-Facing service.

For example:

euserv-register-service -t user-api -h 10.111.5.183 user-api-1

Repeat for each UFS host, replacing the UFS IP address and UFS name. Copy the security credentials from the CLC to each machine running User-Facing Services. Run this command on the CLC host machine:

clcadmin-copy-keys HOST [HOST ...]

For example:

clcadmin-copy-keys 10.111.5.183

Verify that the User-Facing service is registered with the following command for each instance of the UFS:

euserv-describe-services SVCINSTANCE

The registered UFS instances are now ready for your cloud.

1.4.6.2 - Register the Walrus Backend

This topic describes how to register the Walrus Backend service with the Cloud Controller (CLC).

Prerequisites

• You must be using the Walrus Backend service as your object storage provider.
• The Cloud Controller must be properly installed and started.

To register the Walrus Backend service with the Eucalyptus cloud

On the CLC host machine, run the following command:

euserv-register-service -t walrusbackend -h IP SVCINSTANCE

where:

• SVCINSTANCE is the IP of the Walrus Backend you are registering with this CLC.
• must be a unique name for the Walrus Backend service. We recommend that you use a short-hand name of the hostname or IP address of the machine.

For example:

euserv-register-service -t walrusbackend -h 10.111.5.182 walrus-10.111.5.182

Copy the security credentials from the CLC to each machine running a Walrus Backend service. Run this command on the CLC host machine:

clcadmin-copy-keys HOST [HOST ...]

For example:

clcadmin-copy-keys 10.111.5.182

Verify that the Walrus Backend service is registered with the following command:

euserv-describe-services SVCINSTANCE

The registered Walrus Backend service is now ready for your cloud.

1.4.6.3 - Register the Cluster Controller

This topic describes how to register a Cluster Controller (CC) with the Cloud Controller (CLC).

Prerequisites

• The Cloud Controller must be properly installed and started.
• The Cluster Controller service must be properly installed and started.

To register the Cluster Controller service with the Eucalyptus cloud

On the CLC host machine, run the following command:

euserv-register-service -t cluster -h IP -z ZONE SVCINSTANCE

where:

• SVCINSTANCE is the IP address of the CC you are registering with this CLC.
• name should be a descriptive name for the zone controlled by the CC. For example: .
• must be a unique name for the CC service. We recommend that you use the IP address of the machine

For example:

euserv-register-service -t cluster -h 10.111.5.182 -z zone-1 cc-10.111.5.182

Copy the security credentials from the CLC to each machine running Cluster Controller services. Run this command on the CLC host machine:

clcadmin-copy-keys -z ZONE HOST

For example:

clcadmin-copy-keys -z zone-1 10.111.5.182

Repeat the above steps for each Cluster Controller in each zone. Verify that the Cluster Controller service is registered with the following command:

euserv-describe-services SVCINSTANCE

The registered Cluster Controller service is now ready for your cloud.

1.4.6.4 - Register the Storage Controller

This topic describes how to register a Storage Controller (SC) with the Cloud Controller (CLC).

Prerequisites

• The Cloud Controller must be properly installed and started.
• The Storage Controller service must be properly installed and started.

To register the Storage Controller service with the Eucalyptus cloud

Copy the security credentials from the CLC to each machine running Storage Controller services. Run this command on the CLC host machine:

clcadmin-copy-keys -z ZONE HOST

For example:

clcadmin-copy-keys -z zone-1 10.111.5.182

On the CLC host machine, run the following command:

euserv-register-service -t storage -h IP -z ZONE SVCINSTANCE

where:

• SVCINSTANCE is the IP address of the SC you are registering with this CLC.
• name should be a descriptive name for the zone controlled by the CC. For example: . An SC must have the same name as the CC in the same zone.
• must be a unique name for the SC service. We recommend that you use a short-hand name of the IP address or hostname of the machine.

For example:

euserv-register-service -t storage -h 10.111.5.182 -z zone-1 sc-10.111.5.182

Repeat the above steps for each Storage Controller in each zone. Verify that the Storage Controller service is registered with the following command:

euserv-describe-services SVCINSTANCE

The registered Storage Controller service is now ready for your cloud.

1.4.6.5 - Register the Node Controllers

This topic describes how to register a Node Controller (NC) with a Cluster Controller (CC).

Prerequisites

• The Cluster Controller service must be properly installed and started.
• The Node Controller service must be properly installed and started.
• If you are upgrading, you should understand that:
  • If you’re upgrading an NC, just register that NC (on the CC that had it registered before).
  • If you’re upgrading the set of non-NC host machines, register all the NCs (on each CC that had NCs registered).

To register the Node Controller service with the Eucalyptus cloud

SSH to the Cluster Controller in the zone. On the CC, register all NCs using the following command with the IP address of each NC host machine:

clusteradmin-register-nodes node0_IP_address ... [nodeN_IP_address]

For example:

clusteradmin-register-nodes 10.111.5.160 10.111.5.161 10.111.5.162

Copy the CC’s security credentials using the following command:

clusteradmin-copy-keys node0_IP_address ... [nodeN_IP_address]

For example:

clusteradmin-copy-keys 10.111.5.160 10.111.5.161 10.111.5.162

Repeat the steps for each zone in your cloud. The registered Node Controller service is now ready for your cloud.

1.4.7 - Configure the Runtime Environment

Configure the Runtime Environment

After Eucalyptus is installed and registered, perform the tasks in this section to configure the runtime environment.Now that you have installed Eucalyptus , you’re ready to begin configuring and using it.

1.4.7.1 - Configure Eucalyptus DNS

Eucalyptus provides a DNS service that maps service names, bucket names, and more to IP addresses. This section details how to configure the Eucalyptus DNS service.

Configure the Domain and Subdomain

Before using the DNS service, configure the DNS subdomain name that you want Eucalyptus to handle using the steps that follow.

Log in to the CLC and enter the following:

euctl system.dns.dnsdomain=mycloud.example.com

You can configure the load balancer DNS subdomain. To do so, log in to the CLC and enter the following:

euctl services.loadbalancing.dns_subdomain=lb

Turn on IP Mapping

To enable mapping of instance IPs to DNS host names:

Enter the following command on the CLC:

euctl bootstrap.webservices.use_instance_dns=true

When this option is enabled, public and private DNS entries are created for each launched instance in Eucalyptus . This also enables virtual hosting for Walrus. Buckets created in Walrus can be accessed as hosts. For example, the bucket mybucket is accessible as mybucket.objectstorage.mycloud.example.com .

Instance IP addresses will be mapped as euca-A-B-C-D.eucalyptus.mycloud.example.com , where A-B-C-D is the IP address (or addresses) assigned to your instance.

If you want to modify the subdomain that is reported as part of the instance DNS name, enter the following command:

euctl cloud.vmstate.instance_subdomain=.custom-dns-subdomain

When this value is modified, the public and private DNS names reported for each instance will contain the specified custom DNS subdomain name, instead of the default value, which is eucalyptus . For example, if this value is set to foobar , the instance DNS names will appear as euca-A-B-C-D.foobar.mycloud.example.com .

Enable DNS Delegation

DNS delegation allows you to forward DNS traffic for the Eucalyptus subdomain to the Eucalyptus CLC host. This host acts as a name server. This allows interruption-free access to Eucalyptus cloud services in the event of a failure. The CLC host is capable of mapping cloud host names to IP addresses of the CLC and UFS / OSG host machines.

For example, if the IP address of the CLC is 192.0.2.5 , and the IP address of Walrus is 192.0.2.6 , the host compute.mycloud.example.com resolves to 192.0.2.5 and objectstorage.mycloud.example.com resolves to 192.0.2.6 .

To enable DNS delegation:

Enter the following command on the CLC:

euctl bootstrap.webservices.use_dns_delegation=true

Configure the Master DNS Server

Set up your master DNS server to delegate the Eucalyptus subdomain to the UFS host machines, which act as name servers.

The following example shows how the Linux name server bind is set up to delegate the Eucalyptus subdomain.

Open /etc/named.conf and set up the example.com zone. For example, your /etc/named.conf may look like the following:

zone "example.com" IN {
	      type master;
	      file "/etc/bind/db.example.com";
	      };

Create /etc/bind/db.example.com if it does not exist. If your master DNS is already set up for example.com , you will need to add a name server entry for UFS host machines. For example:

$ORIGIN example.com.
$TTL 604800

@ IN    SOA ns1 admin.example.com 1 604800 86400 2419200 604800
        NS  ns1
ns1     A   MASTER.DNS.SERVER_IP
ufs1    A   UFS1_IP
mycloud NS  ufs1

After this, you will be able to resolve your instances’ public DNS names such as euca-A-B-C-D.eucalyptus.mycloud.example.com .

Restart the bind nameserver service named restart . Verify your setup by pointing /etc/resolv.conf on your client to your primary DNS server and attempt to resolve compute.example.com using ping or nslookup. It should return the IP address of a UFS host machine.

Advanced DNS Options

Recursive lookups and split-horizon DNS are available in Eucalyptus .

To enable any of the DNS resolvers, set dns.enabled to true . To enable the recursive DNS resolver, set dns.recursive.enabled to true . To enable split-horizon DNS resolution for internal instance public DNS name queries, set dns.split_horizon.enabled to true .

Optional: Configure Eucalyptus DNS to Spoof AWS Endpoints

You can configure instances to use AWS region FQDNs for service endpoints by enabling DNS spoofing.

Set up a Eucalyptus cloud with Eucalyptus DNS and HTTPS endpoints. When creating CSR, make sure and add Subject Alternative Names for all the supported AWS services for the given region that’s being tested. For example:

$ openssl req -in wildcard.c-06.autoqa.qa1.eucalyptus-systems.com.csr 
						-noout -text | less X509v3 Subject Alternative Name:
     DNS:ec2.us-east-1.amazonaws.com, DNS:autoscaling.us-east-1.amazonaws.com, 
     DNS:cloudformation.us-east-1.amazonaws.com, DNS:monitoring.us-east-1.amazonaws.com, 
     DNS:elasticloadbalancing.us-east-1.amazonaws.com, DNS:s3.amazonaws.com, 
     DNS:sts.us-east-1.amazonaws.com

Set DNS spoofing:

[root@d-17 ~]#  euctl dns.spoof_regions --region euca-admin@future
dns.spoof_regions.enabled = true
dns.spoof_regions.region_name =
dns.spoof_regions.spoof_aws_default_regions = true
dns.spoof_regions.spoof_aws_regions = true

Launch an instance, and allow SSH access. SSH into the instance and install AWS CLI.

ubuntu@euca-172-31-12-59:~$ sudo apt-get install -y python-pip
ubuntu@euca-172-31-12-59:~$ sudo -H pip install --upgrade pip
ubuntu@euca-172-31-12-59:~$ sudo -H pip install --upgrade awscli

Run aws configure and set access and secret key information if not using instance profile. Confirm AWS CLI works with HTTPS Eucalyptus service endpoint:

ubuntu@euca-172-31-12-59:~$ aws --ca-bundle euca-ca-0.crt 
--endpoint-url https://ec2.c-06.autoqa.qa1.eucalyptus-systems.com/ ec2 describe-key-pairs
{
    "KeyPairs": [
        {
            "KeyName": "devops-admin",
            "KeyFingerprint": "ee:4f:93:a8:87:8d:80:8d:2c:d6:d5:60:20:a3:2d:b2"
        }
    ]
}

Test against AWS FQDN service endpoint that matches one of the SANs in the signed certificate:

ubuntu@euca-172-31-12-59:~$ aws --ca-bundle euca-ca-0.crt 
--endpoint-url https://ec2.us-east-1.amazonaws.com ec2 describe-key-pairs{
    "KeyPairs": [
        {
            "KeyName": "devops-admin",
            "KeyFingerprint": "ee:4f:93:a8:87:8d:80:8d:2c:d6:d5:60:20:a3:2d:b2"
        }
    ]
}				

1.4.7.2 - Create the Eucalyptus Cloud Administrator User

After your cloud is running and DNS is functional, create a user and access key for day-to-day cloud administration.

Prerequisites

• cloud services must be installed and registered.
• DNS must be configured.

Create a cloud admin user

Eucalyptus admin tools and Euca2ools commands need configuration from ~/.euca . If the directory does not yet exist, create it:

mkdir ~/.euca

Choose a name for the new user and create it along with an access key:

euare-usercreate -wld DOMAIN USER >~/.euca/FILE.ini

where:

• DOMAIN must match the DNS domain for the cloud.
• USER is the name of the new admin user.
• FILE can be anything; we recommend a descriptive name that includes the user’s name.

This creates a file with a region name that matches that of your cloud’s DNS domain; you can edit the file to change the region name if needed.

Switch to the new admin user:

# eval `clcadmin-release-credentials`
# export AWS_DEFAULT_REGION=REGION

where:

• REGION must match the region name from the previous step. By default, this is the same as the cloud’s DNS domain.

As long as this file exists in ~/.euca , you can use it by repeating the export command above. These euca2ools.ini configuration files are a flexible means of managing cloud regions and users.

Alternatively you can configure the default region in the global section of your Euca2ools configuration:

# cat ~/.euca/global.ini
[global]
default-region = REGION

setting the REGION to the one from the earlier step means you do not have to use export to select the region.

User impersonation

The eucalyptus account can act as other accounts for administrative purposes. To act as the admin user in the account-1 account run:

# eval `clcadmin-impersonate-user -a account-1 -u admin`

Impersonating an account allows you to view and modify resources for that account. For example, you can clean up resources in an account before deleting it.

To stop impersonating run:

clcadmin-release-credentials

Next steps

The remainder of this guide assumes you have completed the above steps.

Use these credentials after this point.

1.4.7.3 - Upload the Network Configuration

This topic describes how to upload the network configuration created earlier in the installation process. To upload your networking configuration:

Run the following command to upload the configuration file to the CLC (with valid Eucalyptus admin credentials):

euctl cloud.network.network_configuration=@/path/to/your/network_config_file

To review the existing network configuration run:

euctl  --dump --format=raw cloud.network.network_configuration

When you use the Ansible playbook for deployment a network configuration file is available at /etc/eucalyptus/network.yaml on the CLC.

1.4.7.4 - Configure Eucalyptus Storage

Configure Storage

These are the types of storage available for your Eucalyptus cloud. Object storage Eucalyptus provides an AWS S3 compatible object storage service that provides users with web-based general purpose storage, designed to be scalable, reliable and inexpensive. You choose the object storage backend provider: Walrus or Ceph RGW. The Object Storage Gateway (OSG) provides access to objects via the backend provider you choose.

Block storage Eucalyptus provides an AWS EBS compatible block storage service that provides block storage for EC2 instances. Volumes can be created as needed and dynamically attached and detached to instances as required. EBS provides persistent data storage for instances: the volume, and the data on it, can exist beyond the lifetime of an instance. You choose the block storage backend provider for a deployment.

1.4.7.4.1 - Configure Block Storage

Configure Block Storage

This topic describes how to configure block storage on the Storage Controller (SC) for the backend of your choice.

The Storage Controller (SC) provides functionality similar to the Amazon Elastic Block Store (Amazon EBS). The SC can interface with various storage systems. Eucalyptus block storage (EBS) exports storage volumes that can be attached to 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.

Eucalyptus provides the following open source (free) backend providers for the SC:

• Overlay, using the local file system
• DAS-JBOD (just a bunch of disks)
• Ceph

You must configure the SC to use one of the backend provider options.

1.4.7.4.1.1 - Use Ceph-RBD

Use Ceph-RBD

This topic describes how to configure Ceph-RBD as the block storage backend provider for the Storage Controller (SC).Prerequisites

• Successful completion of all the install sections prior to this section.

• The SC must be installed, registered, and running.

• You must execute the steps below as a administrator.

• You must have a functioning Ceph cluster.

• Ceph user credentials with the following privileges are available to SCs and NCs (different user credentials can be used for the SCs and NCs).

• Hypervisor support for Ceph-RBD on NCs. Node Controllers (NCs) are designed to communicate with the Ceph cluster via libvirt. This interaction requires a hypervisor that supports Ceph-RBD. See to satisfy this prerequisite. To configure Ceph-RBD block storage for the zone, run the following commands on the CLC Configure the SC to use Ceph-RBD for EBS.

  euctl ZONE.storage.blockstoragemanager=ceph-rbd

The output of the command should be similar to:

one.storage.blockstoragemanager=ceph-rbd

Verify that the property value is now ceph-rbd :

euctl ZONE.storage.blockstoragemanager

Check the SC to be sure that it has transitioned out of the BROKEN state and is in the NOTREADY , DISABLED or ENABLED state before configuring the rest of the properties for the SC. The ceph-rbd provider will assume defaults for the following properties for the SC:

euctl ZONE.storage.ceph
 
PROPERTY        one.storage.cephconfigfile  /etc/ceph/ceph.conf
DESCRIPTION     one.storage.cephconfigfile  Absolute path to Ceph configuration (ceph.conf) file. Default value is '/etc/ceph/ceph.conf'
 
PROPERTY        one.storage.cephkeyringfile /etc/ceph/ceph.client.eucalyptus.keyring
DESCRIPTION     one.storage.cephkeyringfile Absolute path to Ceph keyring (ceph.client.eucalyptus.keyring) file. Default value is '/etc/ceph/ceph.client.eucalyptus.keyring'
 
PROPERTY        one.storage.cephsnapshotpools       rbd
DESCRIPTION     one.storage.cephsnapshotpools       Ceph storage pool(s) made available to  for EBS snapshots. Use a comma separated list for configuring multiple pools. Default value is 'rbd'
 
PROPERTY        one.storage.cephuser        eucalyptus
DESCRIPTION     one.storage.cephuser        Ceph username employed by  operations. Default value is 'eucalyptus'
 
PROPERTY        one.storage.cephvolumepools rbd
DESCRIPTION     one.storage.cephvolumepools Ceph storage pool(s) made available to  for EBS volumes. Use a comma separated list for configuring multiple pools. Default value is 'rbd'

The following steps are optional if the default values do not work for your cloud: To set the Ceph username (the default value for Eucalyptus is ’eucalyptus’):

euctl ZONE.storage.cephuser=myuser

To set the absolute path to keyring file containing the key for the ’eucalyptus’ user (the default value is ‘/etc/ceph/ceph.client.eucalyptus.keyring’):

euctl ZONE.storage.cephkeyringfile='/etc/ceph/ceph.client.myuser.keyring'

euctl ZONE.storage.cephconfigfile=/path/to/ceph.conf

To change the comma-delimited list of Ceph pools assigned to Eucalyptus for managing EBS volumes (default value is ‘rbd’) :

euctl ZONE.storage.cephvolumepools=rbd,myvolumes

To change the comma-delimited list of Ceph pools assigned to Eucalyptus for managing EBS snapshots (default value is ‘rbd’) :

euctl ZONE.storage.cephsnapshotpools=mysnapshots

If you want to enable snapshot deltas for your Ceph backend:

euctl ZONE.storage.shouldtransfersnapshots=true

Set the maximum number of deltas to be created before creating a new full snapshot:

euctl ZONE.storage.maxsnapshotdeltas=NON_ZERO_INTEGER

CEPH_USER_NAME="eucalyptus"
CEPH_KEYRING_PATH="/etc/ceph/ceph.client.eucalyptus.keyring"
CEPH_CONFIG_PATH="/etc/ceph/ceph.conf"

To override the above defaults, add/edit the following properties in the /etc/eucalyptus/eucalyptus.conf on the specific NC file:

CEPH_USER_NAME="ceph-username-for-use-by-this-NC"
CEPH_KEYRING_PATH="path-to-keyring-file-for-ceph-username"
CEPH_CONFIG_PATH="path-to-ceph.conf-file"

Repeat this step for every NC in the specific Eucalyptus zone. Your Ceph backend is now ready to use with Eucalyptus .

1.4.7.4.1.1.1 - Configure Hypervisor Support for Ceph-RBD

This topic describes how to configure the hypervisor for Ceph-RBD support.The following instructions will walk you through steps for verifying and or installing the required hypervisor for Ceph-RBD support. Repeat this process for every NC in the Eucalyptus zone

Verify if qemu-kvm and qemu-img are already installed.

rpm -q qemu-kvm qemu-img

Proceed to the preparing the RHEV qemu packages step if they are not installed.

Verify qemu support for the ceph-rbd driver.

qemu-img --help
qemu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellard
...
Supported formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed vhdx parallels nbd blkdebug host_cdrom 
host_floppy host_device file gluster gluster gluster gluster rbd

systemctl stop eucalyptus-node.service

Prepare the RHEV qemu packages:

• If this NC is a RHEL system and the RHEV subscription to qemu packages is available, consult the RHEV package procedure to install the qemu-kvm-ev and qemu-img-ev packages. Blacklist the RHEV packages in the repository to ensure that packages from the RHEV repository are installed.

• If this NC is a RHEL system and RHEV subscription to qemu packages is unavailable, built and maintained qemu-rhev packages may be used. These packages are available in the same yum repository as other packages. Note that using built RHEV packages voids the original RHEL support for the qemu packages.

• If this NC is a non-RHEL (CentOS) system, -built and maintained qemu-rhev packages may be used. These packages are available in the same yum repository as other packages. If you are not using the RHEV package procedure to install the qemu-kvm-ev and qemu-img-ev packages, install Eucalyptus -built RHEV packages: qemu-kvm-ev and qemu-img-ev , which can be found in the same yum repository as other Eucalyptus packages.

  yum install qemu-kvm-ev qemu-img-ev

Start the libvirtd service.

systemctl start libvirtd.service

Verify qemu support for the ceph-rbd driver.

qemu-img --help
qemu-img version 0.12.1, Copyright (c) 2004-2008 Fabrice Bellard
...
Supported formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed vhdx parallels nbd blkdebug host_cdrom 
host_floppy host_device file gluster gluster gluster gluster rbd

Make sure the eucalyptus-node service is started.

systemctl start eucalyptus-node.service

Your hypervisor is ready for Eucalyptus Ceph-RBD support. You are now ready to configure Ceph-RBD for Eucalyptus .

1.4.7.4.1.2 - About the BROKEN State

This topic describes the initial state of the Storage Controller (SC) after you have registered it with the Cloud Controller (CLC).The SC automatically goes to the broken state after being registered with the CLC; it will remain in that state until you explicitly configure the SC by telling it which backend storage provider to use.

You can check the state of a storage controller by running euserv-describe-services --expert and note the state and status message of the SC(s). The output for an unconfigured SC looks something like this:

SERVICE	storage        	ZONE1        	SC71           	BROKEN    	37  	http://192.168.51.71:8773/services/Storage	arn:euca:eucalyptus:ZONE1:storage:SC71/
SERVICEEVENT	6c1f7a0a-21c9-496c-bb79-23ddd5749222	arn:euca:eucalyptus:ZONE1:storage:SC71/
SERVICEEVENT	6c1f7a0a-21c9-496c-bb79-23ddd5749222	ERROR
SERVICEEVENT	6c1f7a0a-21c9-496c-bb79-23ddd5749222	Sun Nov 18 22:11:13 PST 2012
SERVICEEVENT	6c1f7a0a-21c9-496c-bb79-23ddd5749222	SC blockstorageamanger not configured. Found empty or unset manager(unset). Legal values are: das,overlay,ceph

Note the error above: SC blockstoragemanager not configured. Found empty or unset manager(unset). Legal values are: das,overlay,ceph .

This indicates that the SC is not yet configured. It can be configured by setting the ZONE.storage.blockstoragemanager property to ‘das’, ‘overlay’, or ‘ceph’.

You can verify that the configured SC block storage manager using:

euctl ZONE.storage.blockstoragemanager

to show the current value.

1.4.7.4.1.3 - Use Direct Attached Storage (JBOD)

This topic describes how to configure the DAS-JBOD as the block storage backend provider for the Storage Controller (SC).Prerequisites

• Successful completion of all the install sections prior to this section.

• The SC must be installed, registered, and running.

• Direct Attached Storage requires that have enough space for locally cached snapshots.

• You must execute the steps below as a administrator. To configure DAS-JBOD block storage for the zone, run the following commands on the CLC Configure the SC to use the Direct Attached Storage for EBS.

  euctl ZONE.storage.blockstoragemanager=das

The output of the command should be similar to:

one.storage.blockstoragemanager=das

Verify that the property value is now: ‘das’

euctl ZONE.storage.blockstoragemanager

Set the DAS device name property. The device name can be either a raw device (/dev/sdX, for example), or the name of an existing Linux LVM volume group.

euctl ZONE.storage.dasdevice=DEVICE_NAME

For example:

euctl one.storage.dasdevice=/dev/sdb

Your DAS-JBOD backend is now ready to use with Eucalyptus .

1.4.7.4.1.4 - Use the Overlay Local Filesystem

This topic describes how to configure the local filesystem as the block storage backend provider for the Storage Controller (SC).Prerequisites

• Successful completion of all the install sections prior to this section.
• The SC must be installed, registered, and running.
• The local filesystem must have enough space to hold volumes and snapshots created in the cloud.
• You must execute the steps below as a administrator. In this configuration the SC itself hosts the volume and snapshots for EBS and stores them as files on the local filesystem. It uses standard Linux iSCSI tools to serve the volumes to instances running on NCs.

To configure overlay block storage for the zone, run the following commands on the CLC Configure the SC to use the local filesystem for EBS.

euctl ZONE.storage.blockstoragemanager=overlay 

The output of the command should be similar to:

one.storage.blockstoragemanager=overlay

Verify that the property value is now: ‘overlay’

euctl ZONE.storage.blockstoragemanager

Your local filesystem (overlay) backend is now ready to use with Eucalyptus .

1.4.7.4.2 - Configure Object Storage

This topic describes how to configure object storage on the Object Storage Gateway (OSG) for the backend of your choice. The OSG passes requests to object storage providers and talks to the persistence layer (DB) to authenticate requests. You can use Walrus, MinIO, or Ceph-RGW as the object storage provider.

• Walrus - the default backend provider. It is a single-host Eucalyptus -integrated provider which provides basic object storage functionality for the small scale. Walrus is intended for light S3 usage.

• MinIO - a high performing scalable object storage provider. MinIO implements the S3 API which is used by the OSG, not directly by end users. Distributed MinIO provides protection against multiple node/drive failures and bit rot using erasure code.

• Ceph-RGW - an object storage interface built on top of Librados to provide applications with a RESTful gateway to Ceph Storage Clusters. Ceph-RGW uses the Ceph Object Gateway daemon (radosgw), which is a FastCGI module for interacting with a Ceph Storage Cluster. Since it provides interfaces compatible with OpenStack Swift and Amazon S3, the Ceph Object Gateway has its own user management. Ceph Object Gateway can store data in the same Ceph Storage Cluster used to store data from Ceph Filesystem clients or Ceph Block Device clients. The S3 and Swift APIs share a common namespace, so you may write data with one API and retrieve it with the other.

You must configure the OSG to use one of the backend provider options.

Example showing unconfigured objectstorage:

# euserv-describe-services --show-headers --filter service-type=objectstorage
SERVICE  TYPE              	ZONE    	NAME                   	  STATE	
SERVICE  objectstorage      user-api-1  user-api-1.objectstorage  broken

1.4.7.4.2.1 - Use Ceph-RGW

This topic describes how to configure Ceph Rados Gateway (RGW) as the backend for the Object Storage Gateway (OSG).

Prerequisites

• Successful completion of all the install sections prior to this section.
• The UFS must be registered and enabled.
• A Ceph storage cluster is available.
• The ceph-radosgw service has been installed (on the UFS or any other host) and configured to use the Ceph storage cluster. recommends using civetweb with ceph-radosgw service. is a lightweight web server and is included in the ceph-radosgw installation. It is relatively easier to install and configure than the alternative option – a combination of Apache and Fastcgi modules.

For more information on Ceph-RGW, see the Ceph-RGW documentation.

Configure Ceph-RGW object storage

You must execute the steps below as a administrator.

Configure ceph-rgw as the storage provider using the euctl command:

euctl objectstorage.providerclient=ceph-rgw

Configure objectstorage.s3provider.s3endpoint to the ip:port of the host running the ceph-radosgw service:

euctl objectstorage.s3provider.s3endpoint=<radosgw-host-ip>:<radosgw-webserver-port>

Configure objectstorage.s3provider.s3accesskey and objectstorage.s3provider.s3secretkey with the radosgw user credentials:

euctl objectstorage.s3provider.s3accesskey=<radosgw-user-accesskey>
euctl objectstorage.s3provider.s3secretkey=<radosgw-user-secretkey>

The Ceph-RGW backend and OSG are now ready for production.

1.4.7.4.2.2 - Use MinIO Backend

This topic describes how to configure MinIO as the object storage backend provider for the Object Storage Gateway (OSG).

Prerequisites

• The UFS must be registered and enabled.
• Install and start MinIO

For more information on MinIO installation and configuration see the MinIO Server Documentation

To configure MinIO object storage

You must execute the steps below as a administrator.

Configure minio as the storage provider using the euctl command:

euctl objectstorage.providerclient=minio

Configure objectstorage.s3provider.s3endpoint to the ip:port of a host running the minio server:

euctl objectstorage.s3provider.s3endpoint=<minio-host-ip>:<minio-port>

Configure objectstorage.s3provider.s3accesskey and objectstorage.s3provider.s3secretkey with credentials for minio:

euctl objectstorage.s3provider.s3accesskey=<minio-accesskey>
euctl objectstorage.s3provider.s3secretkey=<minio-secretkey>

Configure the expected response code for minio:

euctl objectstorage.s3provider.s3endpointheadresponse=400

The MinIO backend and OSG are now ready for production.

1.4.7.4.2.3 - Use Walrus Backend

This topic describes how to configure Walrus as the object storage backend provider for the Object Storage Gateway (OSG).

Prerequisites

• Successful completion of all the install sections prior to this section.
• The UFS must be registered and enabled.

To configure Walrus object storage

You must execute the steps below as a administrator.

Configure walrus as the storage provider using the euctl command.

euctl objectstorage.providerclient=walrus

Check that the OSG is enabled.

euserv-describe-services

If the state appears as disabled or broken , check the cloud-*.log files in the /var/log/eucalyptus directory. A disabled state generally indicates that there is a problem with your network or credentials. See Log File Location and Content for more information.

The Walrus backend and OSG are now ready for production.

1.4.7.5 - Install and Configure the Imaging Service

The Eucalyptus Imaging Service, introduced in Eucalyptus 4.0, makes it easier to deploy EBS images in your Eucalyptus cloud and automates many of the labor-intensive processes required for uploading data into EBS images.

The Eucalyptus Imaging Service is implemented as a system-controlled “worker” virtual machine that is monitored and controlled via Auto Scaling. Once the Imaging Service is configured, the Imaging Service VM will be started automatically upon the first request that requires it: such as an EBS volume ingress. Specifically, in this release of Eucalyptus , these are the usage scenarios for the Eucalyptus Imaging Service:

• Importing a raw disk image as a volume: If you have a raw disk image (containing either a data partition or a full operating system with a boot record, e.g., an HVM image), you can use the Imaging Service to import this into your cloud as a volume. This is accomplished with the euca-import-volume command. If the volume was populated with a bootable disk, that volume can be snapshotted and registered as an image.
• Importing a raw disk image as an instance: If you have a raw disk image containing a bootable operating system, you can import this disk image into as an instance: the Imaging Service automatically creates a volume, registers the image, and launches an instance from the image. This is accomplished with the euca-import-instance command, which has options for specifying the instance type and the SSH key for the instance to use.

Install and Register the Imaging Worker Image

Eucalyptus provides a command-line tool for installing and registering the Imaging Worker image. Once you have run the tool, the Imaging Worker will be ready to use.Run the following commands on the machine where you installed the eucalyptus-service-image RPM package (it will set the imaging.imaging_worker_emi property to the newly created EMI of the imaging worker):

esi-install-image --region localhost --install-default

Consider setting the imaging.imaging_worker_keyname property to an SSH keyname (previously created with the euca-create-keypair command), so that you can perform troubleshooting inside the Imaging Worker instance, if necessary:

euctl services.imaging.worker.keyname=mykey

Managing the Imaging Worker Instance

Eucalyptus automatically starts Imaging Worker instances when there are tasks for workers to perform.The cloud administrator can list the running Imaging Worker instances, if any, by running the command:

euca-describe-instances --filter tag-value=euca-internal-imaging-workers

To delete / stop the imaging worker:

esi-manage-stack -a delete imaging

To create / start the imaging worker:

esi-manage-stack -a create imaging

Consider setting the imaging.imaging_worker_instance_type property to an Instance Type with enough ephemeral disk to convert any of your paravirtual images. The Imaging Worker root filesystem takes up about 2GB, so the maximum paravirtual image that the Imaging Worker will be able to convert is the disk allocation of the Instance Type minus 2GBs.

euctl services.imaging.worker.instance_type=m3.xlarge

Troubleshooting Imaging Worker

If the Imaging Worker is configured correctly, users will be able to import data into EBS volumes with euca-import-* commands, and paravirtual EMIs will run as instances. In some cases, though, paravirtual images may fail to convert (e.g., due to intermittent network failures or a network setup that doesn’t allow the Imaging Worker to communicate with the CLC), leaving the images in a special state. To troubleshoot:If the Imaging Worker Instance Type does not provide sufficient disk space for converting all paravirtual images, the administrator may have to change the Instance Type used by the Imaging Worker. After changing the instance type, the Imaging Worker instance should be restarted by terminating the old Imaging Worker instance:

euctl services.imaging.worker.instance_type=m2.2xlarge
euca-terminate-instances $(euca-describe-instances --filter tag-value=euca-internal-imaging-workers | grep INSTANCE | cut -f 2)

If the status of the conversion operation is ‘Image conversion failed’, but the image is marked as ‘available’ (in the output of euca-describe-images), the conversion can be retried by running the EMI again:

euca-run-instances ...

1.4.7.6 - Configure the Load Balancer

Install and Register the Load Balancer Image

Eucalyptus provides a tool for installing and registering the Load Balancer image. Once you have run the tool, your Load Balancer will be ready to use.

Run the following commands on the machine where you installed the eucalyptus-service-image RPM package (it will set the imaging.imaging_worker_emi property to the newly created EMI of the imaging worker):

esi-install-image --install-default

Verify Load Balancer Configuration

If you would like to verify that Load Balancer support is enabled you can list installed Load Balancers. The currently active Load Balancer will be listed as enabled. If no Load Balancers are listed, or none are marked as enabled, then your Load Balancer support has not been configured properly.Run the following command to list installed Load Balancer images:

esi-describe-images

This will produce output similar to the followin:

SERVICE     VERSION  ACTIVE     IMAGE      INSTANCES
    imaging       2.2      *     emi-573925e5      0
 loadbalancing    2.2      *     emi-573925e5      0
    database      2.2      *     emi-573925e5      0

You can also check the enabled Load Balancer EMI with:

euctl services.loadbalancing.worker.image

If you need to manually set the enabled Load Balancer EMI use:

euctl services.loadbalancing.worker.image=emi-12345678

1.4.7.7 - Configure Node Controller

On some Linux installations, a sufficiently large amount of local disk activity can slow down process scheduling. This can cause other operations (e.g., network communication and instance provisioning) appear to stall. Examples of disk-intensive operations include preparing disk images for launch and creating ephemeral storage.

1. Log in to an NC server and open the /etc/eucalyptus/eucalyptus.conf file.
2. Change the CONCURRENT_DISK_OPS parameter to the number of disk-intensive operations you want the NC to perform at once.
   1. Set CONCURRENT_DISK_OPS to 1 to serialize all disk-intensive operations. Or …
   2. Set it to a higher number to increase the amount of disk-intensive operations the NC will perform in parallel.

1.5 - Client Installation

The AWS CLI and Euca2ools are two command line interfaces that work well with Eucalyptus. See the relevant section for instructions to install each client.

1.5.1 - AWS CLI Installation

The AWS CLI is the official client for AWS. The CentOS and RHEL 7 official repositories provide a packaged AWS CLI version 1 that works well with Eucalyptus.

To allow easy use of the AWS CLI with Eucalyptus a plug-in is provided that understands how to access Eucalyptus services.

Install

To install the Eucalyptus plug-in a Eucalyptus YUM repository must first be enabled, either the release repository:

yum install https://downloads.eucalyptus.cloud/software/eucalyptus/5/rhel/7/x86_64/eucalyptus-release-5-1.11.as.el7.noarch.rpm

or the master repository for the latest nightly build:

yum install https://downloads.eucalyptus.cloud/software/eucalyptus/master/rhel/7/x86_64/eucalyptus-release-5-1.15.as.el7.noarch.rpm

Once a repository is configured, install the plugin and client:

yum install eucalyptus-awscli-plugin

Which will install the plug-in and version 1 of the AWS CLI.

Configuration

AWS provides general instructions on Configuring the AWS CLI which includes configuration for credentials. This section covers Eucalyptus plugin specific configuration.

An example configuration for the AWS CLI is:

# cat .aws/config 
[plugins]
eucalyptus = awscli_plugin_eucalyptus

[default]
ufshost = mycloud.example.com
ufsport = 8773
verify_ssl = yes
output = text
region = eucalyptus

The configuration enables the plugin and sets the ufshost and ufsport to enable Eucalyptus service endpoints to be derived.

If your cloud does not have a valid HTTPS certificate then you will need to change verify_ssl to no, but note that this is less secure.

1.5.2 - Euca2ools Standalone Installation

Euca2ools is the Eucalyptus command line interface for interacting with Eucalyptus. This topic discusses how to perform a standalone installation of Euca2ools. If you’re running recent versions of Fedora, Debian, or Ubuntu, you can install Euca2ools using yum or apt.

If you’re running RHEL/CentOS, you can use the following instructions to install Euca2ools.

To perform a standalone installation of Euca2ools on RHEL/CentOS:

Configure the EPEL package repository:

yum install epel-release

Configure the Euca2ools package repository:

yum install http://downloads.eucalyptus.cloud/software/euca2ools/3.4/rhel/7/x86_64/euca2ools-release-3.4-2.2.as.el7.noarch.rpm

Install Euca2ools:

yum install euca2ools

You’ve now performed a standalone installation of Euca2ools.

1.6 - Find More Information

This topic explains what to do once you have installed Eucalyptus, including further reading and other resources for understanding your cloud.

Read More

Eucalyptus has the following guides to help you with more information:

• The Administration Guide details ways to manage your Eucalyptus deployment. Refer to this guide to learn more about managing your Eucalyptus services, like the Cloud Controller; and resources, like instances and images.
• The Identity and Access Management (IAM) Guide provides information to help you securely control access to services and resources for your Eucalyptus cloud users. Refer to this guide to learn more about managing identities, authentication and access control best practices, and specifically managing your users and groups.
• The User Guide details ways to use Eucalyptus for your computing and storage needs. Refer to this guide to learn more about getting and using euca2ools, creating images, running instances, and using dynamic block storage devices.
• The Image Management Guide describes how to create and manage images for your cloud.

2 - Administration Guide

Administration Guide

This section contains concepts and tasks to help you manage your Eucalyptus cloud.

2.1 - Management Overview

Management Overview

The section shows you how to access Eucalyptus with a web-based console and with command line tools. This section also describes how to perform common management tasks. This document is intended to be a reference. You do not need to read it in order, unless you are following the directions for a particular task.

2.1.1 - Overview of Eucalyptus

Eucalyptus is a Linux-based software architecture that implements scalable, efficiency-enhancing private and hybrid clouds within an enterprise’s existing IT infrastructure. Because Eucalyptus provides Infrastructure as a Service (IaaS), you can provision your own resources (hardware, storage, and network) through Eucalyptus on an as-needed basis.

A Eucalyptus cloud is deployed across your enterprise’s on-premise data center. As a result, your organization has a full control of the cloud infrastructure. You can implement and enforce various level of security. Sensitive data managed by the cloud does not have to leave your enterprise boundaries, keeping data completely protected from external access by your enterprise firewall.

Eucalyptus was designed from the ground up to be easy to install and non-intrusive. The software framework is modular, with industry-standard, language-agnostic communication. Eucalyptus is also unique in that it provides a virtual network overlay that isolates network traffic of different users as well as allows two or more clusters to appear to belong to the same Local Area Network (LAN).

Eucalyptus also is compatible with Amazon’s EC2, S3, and IAM services. This offers you hybrid cloud capability.

2.1.2 - Command Line Interface

Eucalyptus supports two command line interfaces (CLIs): the administration CLI and the user CLI.The administration CLI is installed when you install Eucalyptus server-side components. The administration CLI is for maintaining and modifying Eucalyptus.

The other user CLI, called Euca2ools, can be downloaded and installed on clients. Euca2ools is a set of commands for end users and can be used with both Eucalyptus and Amazon Web Services (AWS).

2.2 - Manage Your Cloud

Manage Your Cloud

After you install and initially configure Eucalyptus, there are some common administration tasks you can perform. This section describes these tasks and associated concepts.

2.2.1 - Cloud Overview

This topic presents an overview of the components in Eucalyptus. Eucalyptus is comprised of several components: Cloud Controller, Walrus, Cluster Controller, Storage Controller, and Node Controller. Each component is a stand-alone web service. This architecture allows Eucalyptus both to expose each web service as a well-defined, language-agnostic API, and to support existing web service standards for secure communication between its components.

Cloud Controller

The Cloud Controller (CLC) is the entry-point into the cloud for administrators, developers, project managers, and end-users. The CLC queries other components for information about resources, makes high-level scheduling decisions, and makes requests to the Cluster Controllers (CCs). As the interface to the management platform, the CLC is responsible for exposing and managing the underlying virtualized resources (servers, network, and storage). You can access the CLC through command line tools that are compatible with Amazon’s Elastic Compute Cloud (EC2).

Walrus

Walrus allows users to store persistent data, organized as buckets and objects. You can use Walrus to create, delete, and list buckets, or to put, get, and delete objects, or to set access control policies. Walrus is interface compatible with Amazon’s Simple Storage Service (S3). It provides a mechanism for storing and accessing virtual machine images and user data. Walrus can be accessed by end-users, whether the user is running a client from outside the cloud or from a virtual machine instance running inside the cloud.

Cluster Controller

The Cluster Controller (CC) generally executes on a machine that has network connectivity to both the machines running the Node Controller (NC) and to the machine running the CLC. CCs gather information about a set of NCs and schedules virtual machine (VM) execution on specific NCs. The CC also manages the virtual machine networks. All NCs associated with a single CC must be in the same subnet.

Storage Controller

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

Node Controller

The Node Controller (NC) executes 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. The NC is also responsible for the management of the virtual network endpoint.

2.2.2 - Cloud Best Practices

Cloud Best Practices

This section details Eucalyptus best practices for your private cloud.

2.2.2.1 - Synchronize Clocks

Eucalyptus checks message timestamps across components in the cloud infrastructure. This assures command integrity and provides better security.Eucalyptus components receive and exchange messages using either Query or SOAP interfaces (or both). Messages received over these interfaces are required to have some form of a time stamp (as defined by AWS specification) to prevent message replay attacks. Because Eucalyptus enforces strict policies when checking timestamps in the received messages, for the correct functioning of the cloud infrastructure, it is crucial to have clocks constantly synchronized (for example, with ntpd) on all machines hosting Eucalyptus components. To prevent user command failures, it is also important to have clocks synchronized on the client machines.

Following the AWS specification, all Query interface requests containing the Timestamp element are rejected as expired after 15 minutes of the timestamp. Requests containing the Expires element expire at the time specified by the element. SOAP interface requests using WS-Security expire as specified by the WS-Security Timestamp element.

When checking the timestamps for expiration, Eucalyptus allows up to 20 seconds of clock drift between the machines. This is a default setting. You can change this value for the CLC at runtime by setting the bootstrap.webservices.clock_skew_sec property as follows:

euctl bootstrap.webservices.clock_skew_sec=<new_value_in_seconds>

For additional protection from the message replay attacks, the CLC implements a replay detection algorithm and rejects messages with the same signatures received within 15 minutes. Replay detection parameters can be tuned as described in Configure Replay Protection .

2.2.2.2 - Configure SSL

In order to connect to Eucalyptus using SSL/TLS, you must have a valid certificate for the Cloud Controller (CLC)

If you have more than one host (other than node controllers), note the following:

• The keystore must be updated on each host running the eucalyptus-cloud service
• The [key_alias] must be the same on each host
• Use a wildcard certificate (i.e. *.<system.dns.dnsdomain>), since UFS is responsible for all service API endpoints

Create a keystore

Eucalyptus uses a PKCS12-format keystore. If you are using a certificate signed by a trusted root CA, use the following command to convert your trusted certificate and key into an appropriate format:

openssl pkcs12 -export -in [YOURCERT.crt] -inkey [YOURKEY.key] \
  -out tmp.p12 -name [key_alias]

Save a backup of the Eucalyptus keystore, at /var/lib/eucalyptus/keys/euca.p12 , and then import your keystore into the Eucalyptus keystore as follows:

keytool -importkeystore \
  -srckeystore tmp.p12 -srcstoretype pkcs12 -srcstorepass [export_password] \
  -destkeystore /var/lib/eucalyptus/keys/euca.p12 -deststoretype pkcs12 \
  -deststorepass eucalyptus -alias [key_alias] \
  -srckeypass [export_password]

Enable the Cloud Controller to use this keystore

Run the following commands on the Cloud Controller (CLC):

euctl bootstrap.webservices.ssl.server_alias=[key_alias]

Optional: Redirect Requests to use Port 443

To allow user facing services requests on port 443 instead of the default 8773, run the following commands on the CLC:

euctl bootstrap.webservices.port=443

2.2.2.3 - Storage Volumes

Eucalyptus manages storage volumes for your private cloud. Volume management strategies are application specific, but this topic includes some general guidelines.When setting up your Storage Controller, consider whether performance (bandwidth and latency of read/write operations) or availability is more important for your application. For example, using several smaller volumes will allow snapshots to be taken on a rolling basis, decreasing each snapshot creation time and potentially making restore operations faster if the restore can be isolated to a single volume. However, a single larger volume allows for faster read/write operations from the VM to the storage volume.

An appropriate network configuration is an important part of optimizing the performance of your storage volumes. For best performance, each Node Controller should be connected to a distinct storage network that enables the NC to communicate with the SC or Ceph, without interfering with normal NC/VM-instance network traffic.

Eucalyptus includes configurable limits on the size of a single volume, as well as the aggregate size of all volumes on an SC. The SC can push snapshots from Ceph, where the volumes reside, to object storage, where the snapshots become available across multiple clusters. Smaller volumes will be much faster to snapshot and transfer, whereas large volumes will take longer. However, if many concurrent snapshot requests are sent to the SC, operations may take longer to complete.

EBS volumes are created from snapshots on the SC or Ceph, after the snapshot has been downloaded from object storage to the device. Creating an EBS volume from a snapshot on the same cluster as the source volume of the snapshot will reduce delays caused by having to transfer snapshots from object storage.

2.2.3 - Cloud Tasks

Cloud Tasks

This section contains a listing of your Eucalyptus cloud-related tasks.

2.2.3.1 - Inspect System Health

Eucalyptus provides access to the current view of service state and the ability to manipulate the state. You can inspect the service state to either ensure system health or to identify faulty services. You can modify a service state to maintain activities and apply external service placement policies.

View Service State

Use the euserv-describe-services command to view the service state. The output indicates:

• Component type of the service
• Partition in which the service is registered
• Unique name of the service
• Current view of service state
• Last reported epoch (this can be safely ignored)
• Service URI
• Fully qualified name of the service (This is needed for manipulating services that did not get unique names during registration. For example: internal services like DNS) The default output includes the services that are registered during configuration, as well as information about the DNS service, if present. You can obtain additional service state information, such as internal services, by providing the -a flag.

You can also make requests to retrieve service information that is filtered by either:

• current state (for example, )
• host where service is registered
• partition where service is registered
• type of service (for example, CC or Walrus) When you investigate service failures, you can specify -events to return a summary of the last fault. You can retrieve extended information (primarily useful for debugging) by specifying -events -events-verbose .

Heartbeat Service

http://CLCIPADDRESS:8773/services/Heartbeat provides a list of components and their respective statuses. This allows you to find out if a service is enabled without requiring cloud credentials.

Modify Service State

To modify a service:

Enter the following command on the CLC, Walrus, or SC machines:

systemctl stop eucalyptus-cloud.service

On the CC, use the following command:

systemctl stop eucalyptus-cluster.service

If you want to shut down the SC for maintenance. The SC is SC00 is ENABLED and needs to be DISABLED for maintenance.

To stop SC00 first verify that no volumes or snapshots are being created and that no volumes are being attached or detached, and then enter the following command on SC00:

systemctl stop eucalyptus-cloud.service

To check status of services, you would enter:

euserv-describe-services

When maintenance is complete, you can start the eucalyptus-cloud process on SC00 , which will enter the DISABLED state by default.

systemctl start eucalyptus-cloud.service

Monitor the state of services using euserv-describe-services until SC00 is ENABLED .

2.2.3.2 - View User Resources

To see resource use by your cloud users, Eucalyptus provides the following commands with the flag.

• : Returns information about security groups in your account, including output type identifier, security group ID, security group name, security group description, output type identifier, account ID of the group owner, name of group granting permission, type of rule, protocol to allow, start of port range, end of port range, source (for ingress rules) or destination (for egress rules), and any tags assigned to the security group.
• : Returns information about your instances, including output type identifier, reservation ID, name of each security group the instance is in, output type identifier, instance ID for each running instance, EMI ID of the image on which the instance is based, public DNS name associated with the instance (for instances in the running state), private DNS name associated with the instance (for instances in running state), instance state, key name, launch index, instance type, launch time, availability zone, kernel ID, ramdisk ID, monitoring state, public IP address, private IP address, type of root device (ebs or instance-store), placement group the cluster instance is in, virtualization type (paravirtual or hvm), any tags assigned to the instance, hypervisor type, block device identifier for each EBS volume the instance is using, along with the device name, the volume ID, and the timestamp.
• : Returns information about key pairs available to you, including keypair identifier, keypair name, and private key fingerprint.
• : Returns information about EBS snapshots available to you, including snapshot identifier, ID of the snapshot, ID of the volume, snapshot state (pending, completed, error), timestamp when snapshot initiated, percentage of completion, ID of the owner, volume sized, description, and any tags assigned to the snapshot.
• : Describes your EBS volumes, including volume identifier, volume ID, size of the volume in GiBs, snapshot from which the volume was created, availability zone, volume state (creating, available, in-use, deleting, deleted, error), timestamp of the volume creation, and any tags assigned to the volume.

2.2.3.3 - Change Network Configuration

Change Network Configuration

You might want to change the original network configuration of your cloud. To change your network configuration, perform the tasks listed in this topic.Log in to the CLC and open the /etc/eucalyptus/eucalyptus.conf file. Navigate to the Networking Configuration section and make your edits. Save the file. Restart the Cluster Controller.

systemctl restart eucalyptus-cluster.service

2.2.3.3.1 - Networking Configuration Options

All network-related options specified in /etc/eucalyptus/eucalyptus.conf use the prefix VNET_. The most commonly used VNET options are described in the following table.

2.2.3.4 - Add a Node Controller

If you want to increase your system’s capacity, you’ll want to add more Node Controllers (NCs).To add an NC, perform the following tasks:

Log in to the CLC and enter the following command:

clusteradmin-register-nodes node0_IP_address ... [nodeN_IP_address]

When prompted, enter the password to log into each node. Eucalyptus requires this password to propagate the cryptographic keys.

2.2.3.5 - Migrate Instances Between Node Controllers

In order to ensure optimal system performance, or to perform system maintenance, it is sometimes necessary to move running instances between Node Controllers (NCs). You can migrate instances individually, or migrate all instances from a given NC.

euserv-migrate-instances -i INSTANCE_ID

You can also optionally specify --include-dest HOST_NC_IP or --exclude-dest HOST_NC_IP , to ensure that the instance is migrated to one of the specified NCs, or to avoid migrating the instance to any of the specified NCs. These flags may be used more than once to specify multiple NCs.

To migrate all instances away from an NC, enter the following command:

euserv-migrate-instances --source HOST_NC_IP

You can also optionally specify euserv-modify-service -s stop HOST_NC_IP , to stop the specified NC and ensure that no new instances are started on that NC while the migration occurs. This allows you to safely remove the NC without interrupting running instances. The NC will remain in the DISABLED state until it is explicitly enabled using euserv-modify-service -s start HOST_NC_IP .

In some cases, timeouts may cause a migration to initially fail. Run the command again to complete the migration.

If the migration fails, check the nc.log file on the source and destination NCs. If you see an error similar to:

libvirt: Cannot get interface MTU on 'br0': No such device (code=38)

… then ensure the NCs have the same interface and bridge device names, as described in .

2.2.3.6 - Remove a Node Controller

Describes how to delete NCs in your system.If you want to decrease your system’s capacity, you’ll need to decrease NC servers. To delete an NC, perform the following tasks.

Log in to the CC and enter the following command:

clusteradmin-deregister-nodes node0_IP_address ... [nodeN_IP_address]

2.2.3.7 - Restart Eucalyptus

Restart Eucalyptus

Describes the recommended processes to restart Eucalyptus, including terminating instances and restarting Eucalyptus components.You must restart Eucalyptus whenever you make a physical change (e.g., switch out routers), or edit the eucalyptus.conf file. To restart Eucalyptus, perform the following tasks in the order presented.

2.2.3.7.1 - Shut Down All Instances

To terminate all instances on all NCs perform the steps listed in this topic. To terminate all instances on all NCs:

Enter the following command:

euca-terminate-instances <instance_id>

2.2.3.7.2 - Restart the CLC

Log in to the CLC and enter the following command:

systemctl restart eucalyptus-cloud.service

All Eucalyptus components on this server will restart.

2.2.3.7.3 - Restart Walrus

Log in to Walrus and enter the following command:

systemctl restart eucalyptus-cloud.service

2.2.3.7.4 - Restart the CC

Log in to the CC and enter the following command:

systemctl restart eucalyptus-cluster.service

2.2.3.7.5 - Restart the SC

Log in to the SC and enter the following command:

systemctl restart eucalyptus-cloud.service

2.2.3.7.6 - Restart an NC

To restart an NC perform the steps listed in this topic.Log in to the NC and enter the following command:

systemctl restart eucalyptus-node.service

Repeat for each NC. Verify that the following is even needed. If so, replicate for other NC-tasks. You can automate the restart command for all of your NCs. Store a list of your NCs in a file called nc-hosts that looks like:

nc-host-00
nc-host-01
...
nc-host-nn

To restart all of your NCs, run the following command:

cat nc-hosts | xargs -i ssh root@{} systemctl restart eucalyptus-node.service

2.2.3.8 - Shut Down Eucalyptus

Shut Down Eucalyptus

Describes the recommended processes to shut down Eucalyptus.There may be times when you need to shut down Eucalyptus. This might be because of a physical failure, topological change, backing up, or making an upgrade. We recommend that you shut down Eucalyptus components in the reverse order of how you started them. To stop the system, shut down the components in the order listed.

2.2.3.8.1 - Shut Down All Instances

To terminate all instances on all NCs perform the steps listed in this topic.To terminate all instances on all NCs:

Enter the following command:

euca-terminate-instances <instance_id>

2.2.3.8.2 - Shut Down the NCs

To shut down the NCs perform the steps listed in this topic.To shut down the NCs:

Log in as root to a machine hosting an NC. Enter the following command:

systemctl stop eucalyptus-node.service

Repeat for each machine hosting an NC.

2.2.3.8.3 - Shut Down the CCs

To shut down the CCs:

Log in as root to a machine hosting a CC. Enter the following command:

systemctl stop eucalyptus-cluster.service

Repeat for each machine hosting a CC.

2.2.3.8.4 - Shut Down the SCs

To shut down the SC:

Log in as root to the physical machine that hosts the SC. Enter the following command:

systemctl stop eucalyptus-cloud.service

Repeat for any other machine hosting an SC.

2.2.3.8.5 - Shut Down Walrus

To shut down Walrus:

Log in as root to the physical machine that hosts Walrus. Enter the following command:

systemctl stop eucalyptus-cloud.service

2.2.3.8.6 - Shut Down the CLC

To shut down the CLC:

Log in as root to the physical machine that hosts the CLC. Enter the following command:

systemctl stop eucalyptus-cloud.service

2.2.3.9 - Disable CloudWatch

To disable CloudWatch, run the following command.

euctl cloudwatch.enable_cloudwatch_service=true

2.3 - Operations

Operations

This section contains concepts and tasks associated with operating your Eucalyptus cloud.

2.3.1 - Operations Overview

This section is for architects and cloud administrators who plan to deploy Eucalyptus in a production environment. It is not intended for end users or proof-of-concept installations.To run Eucalyptus in a production environment, you must be aware of your hardware and network resources. This guide is to help you make decisions about deploying Eucalyptus. It is also meant to help you keep Eucalyptus running smoothly.

2.3.2 - Planning Your Deployment

To decide on your deployment’s scope, determine the use case for your cloud. For example, will this be a small dev-test environment, or a large and scalable web services environment?To help with scoping your deployment, see Plan Your Installation in the Installation Guide . There you will find solution examples and physical resource information.

2.3.3 - Testing Your Deployment

This topic details what you should test when you want to make sure your deployment is working. The following suggested test plan contains tasks that ensure DNS, imaging, and storage are working.

DNS

• Verify that instances can ping their:
• Verify that instances are pingable on their public DNS names from:

Imaging

• Verify that an EBS-backed image boots successfully
• Verify that you can create an image from a running EBS-backed instance
• Verify that you can install a new Ubuntu image
• Verify that you can deregister an image
• Verify that you can import an instance
• Verify that you can import a volume

Walrus

• Verify that you can make a basic s3cmd request
• Verify that you can successfully perform a multi-part upload (use a 1G+ file)

2.3.4 - Customizing Your Deployment

This section describes the most commonly applied post-install customizations and the issues they pose:

• Over-subscription
• Networking changes (EDGE mode)
• CloudWatch tweaks/customizations
• Capacity changes

Over-subscription

Over-subscription refers to the practice of expanding your computer beyond its limits. Over-subscription applies only to node controllers. You may modify disks and cores to allow enough usage buffer for your instance. Navigate to /etc/eucalyptus/ and locate the eucalyptus.conf file. Edit the following values to define the appropriate size buffers for your instances: NC_WORK_SIZE Defines the amount of disk space available for instances to be run. Defaults to 1/3 of the currently available disk space on the NC, and NC_CACHE_SIZE defaults to the other 2/3.

NC_CACHE_SIZE Defines how much disk space is needed for images to be cached. MAX_CORES Defines the maximum number of cores that can be provided to VMs on each NC. If it is 0 or not present, then the only limit on the number of instances is the number of cores available on the NC. If it is present, any value greater than 256 is treated as 256. In order for these changes to take effect, you must restart the NC.

Networking Changes (EDGE modes)

You can modify the default by adding network IPs to your cloud. Adding public IPs does not require shutting down the whole system.

To add network IPs:In EDGE mode, adding or changing the IP involves creating a JSON file and uploading it the Cloud Controller (CLC). See Configure for Edge Mode for more details. No restart needed, changes apply automatically.

Change CloudWatch Properties

You can change the following CloudWatch properties:

Change Capacity

Capacity changes refer to adding another zone or more nodes. To add another zone, install , start , and register . To add more nodes, see Add a Node Controller .

2.3.5 - Managing Policies

This topic details best practices for managing your cloud policies.

• Establish a workflow for account creation, including the initial request for a cloud account and the email containing credentials.
• Limit your use of individual policies. Focus your policies on groups and add individuals to the group.
• Use groups to assign permissions to individual users. Limit the use of policies for individual users. For more information about policy best practices, see IAM Best Practices .

2.3.6 - Networking

This topic addresses networking in the Eucalyptus cloud.

Networking Modes

Eucalyptus offers different modes to provide you with a cloud that will fit in your current network. For information what each networking mode has to offer, see Plan Networking Modes .

EC2-Classic Networking

Eucalyptus EDGE networking mode supports EC2-Classic networking. Your instances run in a single, flat network that you share with others. For more information about EC2-Classic networking, see EC2 Supported Platforms .

EC2-VPC Networking

Eucalyptus VPCMIDO networking mode resembles the Amazon Virtual Private Cloud (VPC) product wherein the network is fully configurable by users. For more information about EC2-VPC networking, see Differences Between Instances in EC2-Classic and EC2-VPC .

2.3.7 - Monitoring

This topic includes details about which resources you should monitor.

2.3.8 - Backup and Recovery

Backup and Recovery

This section provides details on important files to back up and recover.

2.3.8.1 - Back Up Eucalyptus Cloud Data

Back Up Cloud Data

This section explains what you need to back up and protect your cloud data.We recommend that you back up the following data:

• The cloud database: see
• Object storage. For objects in Walrus, the frequency depends on current load. Use your own discretion to determine the backup plan and strategy. You must have Walrus running.
• EBS volumes in each cluster (DAS and Overlay)
• The configuration file for the cloud is stored on the CLC: .
• Any configuration file for the cloud stored on any other host (UFS, CC, etc.): .
• The cloud security credentials on all hosts (you already backed up the CLC keys as part of the database backup). Use the tar command: .
• The CC and NC configuration files, stored on every CC and NC: .
• Any Euca2ools (.ini) configuration files, which reside on any Euca2ools host machine. Files can be found in:
• Management Console config files in should be backed up. Typical files:
• Ensure you have your instances’ so you can access the instances later.
• and LVM snapshots Users are responsible for volume backups using EBS snapshots on their defined schedules.

2.3.8.1.1 - Back Up the Database

To back up the cloud database follow the steps listed in this topic.Bucket and object metadata are stored in the Eucalyptus cloud database. To back up the database

Log in to the CLC. The cloud database is on the CLC. Extract the Eucalyptus PostgreSQL database cluster into a script file.

pg_dumpall --oids -c -h/var/lib/eucalyptus/db/data -p8777 -U root -f/root/eucalyptus_pg_dumpall-backup.sql

Back up the cloud security credentials in the keys directory.

tar -czvf ~/eucalyptus-keydir.tgz /var/lib/eucalyptus/keys

2.3.8.2 - Recover Eucalyptus Cloud Data

Recover Cloud Data

This topic explains what to include when you recover your cloud.Recovering Your Cloud Data

• The cloud database: see
• Object storage. For objects in Walrus, the frequency depends on current load. Use your own discretion to determine the restore plan and strategy.
• EBS volumes in each cluster (DAS and Overlay)
• The configuration file for the cloud is stored on the CLC: .
• Any configuration file for the cloud stored on any other host (UFS, CC, etc.): .
• The cloud security credentials on all hosts (you already restored the CLC keys as part of the database restore). Use the tar command: .
• The CC and NC configuration files, stored on every CC and NC: .
• Any Euca2ools (.ini) configuration files, which reside on any Euca2ools host machine. Files in these directories:
• Management Console config files you backed up from should be restored. Typical files:
• Ensure you have your instances’ so you can access the instances.
• and LVM snapshots Users are responsible for volume restore using EBS snapshots.

2.3.8.2.1 - Restore the Database

To restore the cloud database follow the steps listed in this topic.

Stop the CLC service.

systemctl stop eucalyptus-cloud.service

Remove traces of the old database.

rm -rf /var/lib/eucalyptus/db

Restore the cloud security credentials in the keys directory.

tar -xvf ~/eucalyptus-keydir.tgz -C /

Re-initialize the database structure.

clcadmin-initialize-cloud

Start the database manually.

su eucalyptus -s /bin/bash -c "/usr/bin/pg_ctl start -w \
-s -D/var/lib/eucalyptus/db/data -o '-h0.0.0.0/0 -p8777 -i'"

Restore the backup.

psql -U root -d postgres -p 8777 -h /var/lib/eucalyptus/db/data -f/root/eucalyptus_pg_dumpall-backup.sql

Stop the database manually.

su eucalyptus -s /bin/bash -c "/usr/bin/pg_ctl stop -D/var/lib/eucalyptus/db/data"

Start CLC service

systemctl start eucalyptus-cloud.service

2.3.9 - Troubleshooting

Troubleshooting

This topic details how to find information you need to troubleshoot most problems in your cloud. To troubleshoot Eucalyptus, you must have the following:

• a knowledge about which machines each Eucalyptus component is installed on
• root access to each machine hosting Eucalyptus components
• an understanding of the network mode (EDGE, VPCMIDO)
• an understanding of eucanetd and the configuration connecting the Eucalyptus components

For most problems, the procedure for tracing problems is the same: start at the bottom to verify the bottom-most component, and then work your way up. If you do this, you can be assured that the base is solid. This applies to virtually all Eucalyptus components and also works for proactive, targeted monitoring.

2.3.9.1 - Eucalyptus Log Files

Usually when an issue arises in Eucalyptus, you can find information that points to the nature of the problem either in the Eucalyptus log files or in the system log files. This topic details log file message meanings, location, configuration, and fault log information.

2.3.9.2 - Network Information

When you have to troubleshoot, it’s important to understand the elements of the network on your system.Here are some ideas for finding out information about your network:

• It is also important to understand the elements of the network on your system. For example, you might want to list bridges to see which devices are enslaved by the bridge. To do this, use the command.
• You might also want to list network devices and evaluate existing configurations. To do this, use these commands: , , and .
• You can use to check status, or to force eucanetd to run in the foreground, sending log messages to the terminal.
• You can get further information if you use the commands with the options. For example, returns all instances running by all users on the system. Other describe commands are:

2.3.9.3 - Common Problems

Common Problems

This section describes common problems and workarounds.

2.3.9.3.1 - Problem: can't communicate with instance

Use ping from a client (not the CLC). Can you ping it?

Yes: Check the open ports on security groups and retry connection using SSH or HTTP. Can you connect now? Yes. Okay, then. You’re work is done. No: Try the same procedure as if you can’t ping it up front. No: Is your cloud running in Edge networking mode?

• Yes: Run euca-describe-nodes . Is your instance there?

• No, it is not in Edge networking mode:

2.3.9.3.2 - Problem: install-time checks

Eucalyptus offers installation checks for any Eucalyptus component or service (CLC, Walrus, SC, NC, SC, services, and more). When Eucalyptus encounters an error, it presents the problem to the operator. These checks are used for install-time problems. They provide resolutions to some of the fault conditions.

Each problematic condition contains the following information:

For more information about all the faults we support, go to https://github.com/eucalyptus/eucalyptus/tree/master/util/faults/en_US .

2.3.9.3.3 - Problem: instance runs but fails

Run euca-describe-nodes to verify if instance is there. Is the instance there?

Yes: Go to the NC log for that NC and grep your instance ID. Did you find the instance?

• Yes: Is there an error message?

No: Go to the CC log and grep the instance ID. Is it there error message?

• Yes: The error message should give you some helpful information.

• No: grep the instance ID in cloud-output.log . Is there error message?

No: Log in as admin and run euca-describe-instance . Is the instance there?

• Yes:
• No: Start over and run a new instance, recreate failure, and start these steps over.

2.3.9.3.4 - Problem: snapshot creation failed

On the SC, depending on the backend used for storage:

• For Overlay, use the command to check the disk space in .
• For DAS, use the command to check the disk space in the DAS volumes.
• For any other backend, use its specific commands to check the free space for storage allocated for volumes. Is there enough space?

Yes: On the OSG host, depending on the backend used for object storage:

• For Walrus, use the command to check the disk space in .

• For RiakCS or Ceph-RGW, use its specific commands to check the free space for storage allocated for buckets and objects. Is there enough space? Yes.

• Use and note the IP addresses for the OSG and SC.

• SSH to SC and ping the OSG. Are there error messages?

No: Delete volumes or add disk space. No: Delete volumes or add disk space.

2.3.9.3.5 - Problem: volume creation failed

Symptom: Went from available to fail. This is typically caused by the CLC and the SC.On the SC, use df or lvdisplay to check the disk space. Is there enough space?

Yes: Check the SC log and grep the volume ID. Is there error message? Yes. This provides clues to helpful information. No: Check cloud-output.log for a volume ID error. No: Delete volumes or add disk space.

2.3.9.4 - Component Workarounds

Component Workarounds

This section contains troubleshooting information for Eucalyptus components and services.

2.3.9.4.1 - Access and Identities

This topic contains information about access-related problems and solutions. Need to verify an existing LIC file.

1. Enter the following command: The output from the example above shows the name of the LIC file and status of the synchronization (set to false).

2.3.9.4.2 - Elastic Load Balancing

This topic explains suggestions for problems you might have with Elastic Load Balancing (ELB). Can’t synchronize with time server Eucalyptus sets up NTP automatically for any instance that has an internet connection to a public network. If an instance doesn’t have such a connection, set the cloud property loadbalancing.loadbalancer_vm_ntp_server to a valid NTP server IP address. For example:

euctl loadbalancing.loadbalancer_vm_ntp_server=169.254.169.254
PROPERTY	loadbalancing.loadbalancer_vm_ntp_server	169.254.169.254 was {}

Need to debug an ELB instance To debug an ELB instance, set the loadbalancing.loadbalancer_vm_keyname cloud property to the keypair of the instance you want to debug. For example:

# euctl loadbalancing.loadbalancer_vm_keyname=sshlogin
PROPERTY	loadbalancing.loadbalancer_vm_keyname	sshlogin was {}

2.3.9.4.3 - Imaging Worker

This topic contains troubleshooting tips for the Imaging Worker.Some requests that require the Imaging Worker might remain in pending for a long time. For example: an import task or a paravirtual instance run. If request remains in pending, the Imaging Worker instance might not able to run because of a lack of resources (for example, instance slots or IP addresses).

You can check for this scenario by listing latest AutoScaling activities:

euscale-describe-scaling-activities -g asg-euca-internal-imaging-worker-01

Check for failures that indicate inadequate resources such as:

ACTIVITY        1950c4e5-0db9-4b80-ad3b-5c7c59d9c82e    2014-08-12T21:05:32.699Z        asg-euca-internal-imaging-worker-01    Failed   Not enough resources available: addresses; please stop or terminate unwanted instances or release unassociated elastic IPs and try again, or run with private addressing only

2.3.9.4.4 - Instances

This topic contains information to help you troubleshoot your instances. Inaccurate IP addresses display in the output of euca-describe-addresses. This can occur if you add IPs from the wrong subnet into your public IP pool, do a restart on the CC, swap out the wrong ones for the right ones, and do another restart on the CC. To resolve this issue, run the following commands.

systemctl stop eucalyptus-cloud.service
systemctl stop eucalyptus-cluster.service
iptables -F
systemctl restart eucalyptus-cluster.service
systemctl start eucalyptus-cloud.service

NC does not recalculate disk size correctly This can occur when trying to add extra disk space for instance ephemeral storage. To resolve this, you need to delete the instance cache and restart the NC.

For example:

rm -rf /var/lib/eucalyptus/instances/* 
systemctl restart eucalyptus-node.service               				

2.3.9.4.5 - Walrus and Storage

This topic contains information about Walrus-related problems and solutions. Walrus decryption failed. On Ubuntu 10.04 LTS, kernel version 2.6.32-31 includes a bug that prevents Walrus from decrypting images. This can be determined from the following line in cloud-output.log

javax.crypto.
BadPaddingException: pad block corrupted

If you are running this kernel:

1. Update to kernel version 2.6.32-33 or higher.
2. De-register the failed image ( ).
3. Re-register the bundle that you uploaded ( ).

Walrus physical disk is not large enough.

1. Stop the CLC.
2. Add a disk.
3. Migrate your data. Make sure you use LVM with your new disk drive(s).

2.4 - Manage Resources

Manage Resources

This section includes tasks to help you manage your users’ cloud resources.

2.4.1 - Manage Auto Scaling Resources

You can list, delete, update, and suspend your Eucalyptus cloud’s Autoscaling resources by passing the option with the keyword with the appropriate command.The followings are some examples you can use to act on your Auto Scaling resources.

To show all launch configurations in your cloud, run the following command:

euscale-describe-launch-configs --show-long verbose

To show all Auto Scaling instances in your cloud, run the following command:

euscale-describe-auto-scaling-groups --show-long verbose

To show all Auto Scaling instances in your cloud, run the following command:

euscale-describe-auto-scaling-groups --show-long verbose

To delete an Auto Scaling resource in your cloud, first get the ARN of the resource, as in this example:

$ euscale-describe-launch-configs --show-long verbose
LAUNCH-CONFIG  TestLaunchConfig  emi-06663A57  m1.medium  2013-10-30T22:52:39.392Z  true
arn:aws:autoscaling::961915002812:launchConfiguration:5ac29caf-9aad-4bdb-b228-5f
ce841dc062:launchConfigurationName/TestLaunchConfig

Then run the following command with the ARN:

euscale-delete-launch-config
arn:aws:autoscaling::961915002812:launchConfiguration:5ac29caf-9aad-4bdb-b228-5f
ce841dc062:launchConfigurationName/TestLaunchConfig

2.4.2 - Manage CloudWatch Resources

To manage CloudWatch resources on a Eucalyptus cloud, use the option in any command that lists, deletes, modifies, or sets a CloudWatch resource.The following are examples of what you can do with your CloudWatch resources.

To list all alarms for the cloud, run the following command:

euwatch-describe-alarms verbose

2.4.3 - Manage Compute Resources

To manage compute resources on a Eucalyptus cloud, use the option in any command.The following are some examples you can use to view various compute resources.

To see all instances running on your cloud, enter the following command:

euca-describe-instances verbose

To see all volumes in your cloud, enter the following command:

euca-describe-volumes verbose

To see all keypairs in your cloud, enter the following command:

euca-describe-keypairs verbose

2.4.4 - Manage ELB Resources

To list and delete ELB resources on a Eucalyptus cloud, use the option with any command.The following are some examples.

To list all detailed configuration information for the load balancers in your cloud, run the following command:

eulb-describe-lbs verbose

To list the details of policies for all load balancers in your cloud, run the following command:

eulb-describe-lb-policies verbose

To list meta information for all load balancer policies in your cloud, run the following command:

eulb-describe-lb-policy-types verbose

To delete any load balancer or any load balancer resource on the cloud, instead of using the ELB name, use the DNS name. For example:

$ eulb-describe-lbs verbose
LOAD_BALANCER	MyLoadBalancer	MyLoadBalancer-961915002812.lb.foobar.eucalyptus-systems.com	2013-10-30T03:02:53.39Z

$ eulb-delete-lb MyLoadBalancer-961915002812.lb.foobar.eucalyptus-systems.com 
$ eulb-describe-lbs verbose 

2.4.5 - Manage IAM Resources

To manage Euare (IAM) resources on your Eucalyptus cloud, use the option with any command that describes, adds, deletes, or modifies resources. This option allows you to assume the role of the admin user for a given account. You can also use a policy to control and limit instances to specific availability zones. The following are some examples.

To list all groups in an account, enter the following command:

euare-grouplistbypath --as-account <account-name>

To list all users in an account, enter the following command:

euare-userslistbypath --as-account <account-name>

To delete the login profile of a user in an account, enter the following command:

euare-userdelloginprofile --as-account <account-name> -u <user_name>

To modify the login profile of a user in an account, enter the following command:

euare-usermod --as-account <account-name> -u <user_name> -n
<new_user_name>

To restrict an image to a specific availability zone, edit and attach this sample policy to a user:

{
    "Statement":[
      {
        "Effect":"Allow",
        "Action":"ec2:*",
         "Resource":"*"
      },
      {
        "Effect": "Deny",
        "Action": [ "ec2:*" ],
        "Resource": "arn:aws:ec2:::availabilityzone/PARTI00",
        "Condition": {
          "ArnLike": {
            "ec2:TargetImage": "arn:aws:ec2:*:*:image/emi-239D37F2"
          }
        }
      }
    ]
  }

To restrict a user to actions only within a specific availability zone, edit and attach this sample policy to a user:

{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": [ "ec2:TerminateInstances" ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:AvailabilityZone": "PARTI00"
        }
      }
    }]
  }

To deny actions at the account level, edit and attach this example policy to an account:

{
    "Statement": [ {
      "Effect": "Deny",
      "Action": [ "ec2:RunInstances" ],
      "Resource": "arn:aws:ec2:::availabilityzone/PARTI00",
      "Condition": {
          "ArnLike": {
              "ec2:TargetImage": "arn:aws:ec2:*:*:image/emi-239D37F2"
          }
      }
    } ]
  }

2.4.6 - Manage Walrus Resources

This topic explains Walrus resources.

• Access Control Lists (ACLs) allow an account to explicitly grant access to a bucket or object to another account. ACLs only work between accounts, not IAM users. You specify accounts with the CanonicalID or the email address associated with the account (for Eucalyptus this is the email of the account admin).
• These are set by the admin of an account to control the access of users within that specific account. This is how an admin controls what users in that specific account are allowed to do. Policies can specify allow/deny on specific S3 operations (e.g. s3:GetObject, or s3:PutObject). IAM policies are set by sending the policy to the IAM (Euare) endpoint, not S3 (Walrus).
• These are IAM-like policies set by the bucket owner are not supported in Eucalyptus. For more information about bucket ACLs, go to Access Control List (ACL) Overview and Managing ACLs Using the REST API .

For more information about IAM policies, go to Using IAM Policies .

2.5 - Manage Regions

Manage Regions

This section provides information about regions and identity federation.

2.5.1 - Regions Overview

Eucalytpus provides support for the notion of federation of identity.Federation of identity information means that a Cloud Administrator can create a federation of (otherwise independent) Eucalyptus “clouds” where a Cloud User, using the same credentials as always, can use any of these federated Eucalyptus cloud regions. For the parts of Identify Access Management (IAM) and Security Token Service (STS) that Eucalyptus implements, the experience exposed to the Cloud User is the same as that seen by an AWS user working across AWS regions.

A user can interact with any region using the same credentials, subjected to the same policies, and having uniformly accessible and structured principals (Accounts, Users, Groups, Roles, etc.). The globality also includes the STS service functionality, the temporary credentials produced by the STS service also work globally.

Notably, this feature is restricted to IAM/STS and does not include other services which have pseudo-global characteristics, such as global bucket name space for S3. The following are general principles associated with regions:

• A region needs to be Registered as a federated region
• Registered regions should be discoverable via the EC2 DescribeRegions response
• A cloud user’s credentials should be accepted by any federated cloud
• There is a global IAM service (identities and policies are global for all registered regions)

2.5.2 - Region Configuration File Format

This section describes the necessary configuration properties that need to be addressed.For federation to be successfully configured, each cloud (i.e. region) that will be part of the federated cloud needs to have the following properties set (at a minimum):

2.5.3 - Examples

In this example, there will be two clouds used (10.111.5.32 and 10.111.1.1). Before setting up federation, the clouds must meet the following requirements:

• Eucalyptus installed
• Eucalyptus DNS enabled

2.5.4 - Federation Differences Between AWS and Eucalyptus

This section outlines the differences between AWS and Eucalyptus with respect to federation in the following platforms:

• Euca2ools vs. AWS EC2 API Tools
• Eucalyptus OSG vs. AWS S3
• Eucalyptus Resource-Level vs. AWS Resource-Level Permissions
• Global Cloud Administration (Local vs. Federated)

2.5.5 - Troubleshooting

This section is presented in a Q&A format to provide a quick reference to the most frequently asked questions.

1. Can Cloud Administrators federate existing clouds (i.e. clouds that already have non-system Eucalyptus accounts)? A. No, this is currently not supported. If a cloud administrator wants to federate an Eucalyptus clouds, this must be done prior to any non-system Eucalyptus account/user/group creation.

2. Is Eucalyptus DNS required for federating Eucalyptus clouds? A. No, however its highly recommended to enable it.

3. Are supported for more granular IAM access policies per region? A. As of 4.2, no. IAM policies apply globally (for all regions). In order to get more granular IAM access, use availability zone restrictions under each region. For more information, see Restrict Image to Availability Zone .

4. What services/resources span globally? Which span regionally? A. Currently, only Eucalyptus IAM and STS are global services/resources. All other services/resources are region-based (i.e. Eucalyptus cloud-specific). The only resource that can be either global or regional are keypairs. This is because users can import the same keypair to each region, therefore, the keypair is globally accessible. For additional information, please refer to the AWS EC2 Documentation regarding Resource Locations .

5. Are Eucalyptus system accounts global in a federated setup? A. No. Any Eucalyptus system account is limited to that region. Examples of Eucalyptus system accounts are as follows:

• eucalyptus
• (eucalyptus)blockstorage
• (eucalyptus)aws-exec-read
• (eucalyptus)cloudformation

1. Is and supported? A. No. There have been no improvements associated with Object Storage Gateway (OSG) regarding cross-regional behavior similar to AWS.

2. If a user uploads an object to an Object Storage Gateway in one region, will copies show up in other regions (similar to the behavior on AWS)? A. No, this is currently unsupported.

3. Do federated Eucalyptus clouds follow the same globally? A. No, Eucalyptus IAM limitations are regionally scoped.

2.6 - Manage Security

Manage Security

This section details concepts and tasks required to secure your cloud.

2.6.1 - Security Overview

This topic is intended for people who are currently using Eucalyptus and who want to harden the cloud and underlying configuration.

This topic covers available controls and best practices for securing your Eucalyptus cloud. Cloud security depends on security across many layers of infrastructure and technology:

• Security of the physical infrastructure and hosts
• Security of the virtual infrastructure
• Security of instances
• Security of storage and data
• Security of users and accounts

2.6.2 - Best Practices

Best Practices

This topic contains recommendations for hardening your Eucalyptus cloud.

2.6.2.1 - Authentication and Access Control Best Practices

This topic describes best practices for Identity and Access Management and the account.

Identity and Access Management

Eucalyptus manages access control through an authentication, authorization, and accounting system. This system manages user identities, enforces access controls over resources, and provides reporting on resource usage as a basis for auditing and managing cloud activities. The user identity organizational model and the scheme of authorizations used to access resources are based on and compatible with the AWS Identity and Access Management (IAM) system, with some Eucalyptus extensions provided that support ease-of-use in a private cloud environment.

For a general introduction to IAM in Eucalyptus, see Access Concepts in the IAM Guide. For information about using IAM quotas to enforce limits on resource usage by users and accounts in Eucalyptus, see the Quotas section in the IAM Guide.

The Amazon Web Services IAM Best Practices are also generally applicable to Eucalyptus.

Credential Management

Protection and careful management of user credentials (passwords, access keys, X.509 certificates, and key pairs) is critical to cloud security. When dealing with credentials, we recommend:

• Limit the number of active credentials and do not create more credentials than needed.
• Only create users and credentials for the interfaces that you will actually use. For example, if a user is only going to use the Management Console, do not create credentials access keys for that user.
• Use and or to get a specific set of credentials if needed.
• Regularly check for active credentials using commands and remove unused credentials. Ideally, only one pair of active credentials should be available at any time.
• Rotate credentials regularly and delete old credentials as soon as possible. Credentials can be created and deleted using commands, such as and .
• When rotating credentials, there is an option to deactivate, instead of removing, existing access/secret keys and X.509 certificates. Requests made using deactivated credentials will not be accepted, but the credentials remain in the Eucalyptus database and can be restored if needed. You can deactivate credentials using and .

Privileged Roles

The eucalyptus account is a super-privileged account in Eucalyptus. It has access to all cloud resources, cloud setup, and management. The users within this account do not obey IAM policies and compromised credentials can result in a complete cloud compromisation that is not easy to contain. We recommend limiting the use of this account and associated users’ credentials as much as possible.

For all unprivileged operations, use regular accounts. If you require super-privileged access (for example, management of resources across accounts and cloud setup administration), we recommend that you use one of the predefined privileged roles.

The Account, Infrastructure, and Resource Administrator roles provide a more secure way to gain super privileges in the cloud. Credentials returned by an assume-role operation are short-lived (unlike regular user credentials). Privileges available to each role are limited in scope and can be revoked easily by modifying the trust or access policy for the role.

2.6.2.2 - Hosts

This topic describes best practices for machines that host a Eucalyptus component.Eucalyptus recommends restricting physical and network access to all hosts comprising the Eucalyptus cloud, and disabling unused applications and ports on all machines used in your cloud.

After installation, no local access to Eucalyptus component hosts is required for normal cloud operations and all normal cloud operations can be done over remote web service APIs.

The user-facing services (UFS) and object storage gateway (OSG) are the only two components that generally expect remote connections from end users. Each Eucalyptus component can be put behind a firewall following the list of open ports and connectivity requirements described in the Configure the Firewall section.

For more information on securing Red Hat hosts, see the Red Hat Enterprise Linux Security Guide .

2.6.2.3 - Images and Instances

Because all instances are based on images, creating a secure image helps to create secure instances. This topic lists best practices that will add additional security during image creation. As a general rule, harden your images similar to how you would harden your physical servers.

• Turn off password-based authentication by specifying the following option in :
• Encourage non-root access by providing an unprivileged user account. If necessary, use sudo to allow access to privileged commands
• Always delete the shell history and any other potentially sensitive information before bundling. If you attempt more than one bundle upload in the same image, the shell history contains your secret access key.
• Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (e.g. when using , pass the folder location where the certificates are stored as part of the values for the option). AWS provides more in-depth information on .
• Consider installing in the image to help control root and non-root access. If cloud-init isn’t available, a custom script can be used.
• Consider using a tool such as zerofree to zero-out any unused space on the image.
• Consider editing to clear out the swap every time the instance is booted. This can be done using the following command:
• Consider enabling or for your images
• Disable all unused services and ports on the image.
• By default, all images registered have private launch permissions. Consider using to limit the accounts that can access the image. After locking down the image using the steps above, additional steps can be done to further secure instances started from that image. For example, restrict access to the instance by allowing only trusted hosts or networks to access ports on your instances. You can control access to instances using euca-authorize and euca-revoke .

Consider creating one security group that allows external logins and keep the remainder of your instances in a group that does not allow external logins. Review the rules in your security groups regularly, and ensure that you apply the principle of least privilege: only open up permissions as they are required. Use different security groups to deal with instances that have different security requirements.

2.6.2.4 - Management Console

This topic describes things you can do to secure the Eucalyptus Management Console.

• Enable HTTPS for communications with the console and configure the console to use a CA-signed certificate.
• We do not recommend the “Remember my keys” option for “Login to AWS” because it stores AWS credentials in your browser’s local storage and increases the security risk of AWS credentials being compromised.
• Change the default session timeouts if needed. For more information, see .
• If you don’t use the Management Console, we recommend that you disable (using ). For more information, see .
• Turn off password autocomplete for the console by setting the configuration option to false in the console’s configuration file.
• If memcached is configured to be used by the console, make sure it’s not exposed publicly because there is no authentication mechanism enabled out of the box. If the default Eucalyptus-provided configuration is used, it accepts connections only from localhost.

2.6.2.5 - Message Security

This topic describes which networking mode is the most secure, and describes how to enforce message security.

Replay Detection

Eucalyptus components receive and exchange messages using either Query or SOAP interfaces (or both). Messages received over these interfaces are required to have a time stamp (as defined by AWS specification) to prevent message replay attacks. Because Eucalyptus enforces strict policies when checking timestamps in the received messages, for the correct functioning of the cloud infrastructure, it is crucial to have clocks constantly synchronized (for example, with ntpd) on all machines hosting Eucalyptus components. To prevent user commands failures, it is also important to have clocks synchronized on the client machines.

Following the AWS specification, all Query interface requests containing the Timestamp element are rejected as expired after 15 minutes of the timestamp. Requests containing the Expires element expire at the time specified by the element. SOAP interface requests using WS-Security expire as specified by the WS-Security Timestamp element.

Replay detection parameters can be tuned as described in Configure Replay Protection .

Endpoints

Eucalyptus requires that all user requests (SOAP with WS-Security and Query) are signed, and that their content is properly hashed, to ensure integrity and non-repudiation of messages. For stronger security, and to ensure message confidentiality and server authenticity, client tools and applications should always use SSL/TLS protocols with server certification verification enabled for communications with Eucalyptus components.

By default, Eucalyptus components are installed with self-signed certificates. For public Eucalyptus endpoints, certificates signed by a trusted CA provider should be installed.

2.6.2.6 - Networking Modes

This topic describes the recommendations for networking modes.A Eucalyptus deployment can be configured in EDGE (AWS EC2 Classic compatible) or VPCMIDO (AWS VPC compatible) networking modes. In both modes, by default, instances are not allowed to send traffic with spoofed IP and/or MAC addresses and receive traffic that are not destined to their own IP and/or MAC addresses. Security groups should be used to control the ingress traffic to instances (EDGE and VPCMIDO modes) and to control the egress traffic from instances (VPCMIDO mode).

VPCMIDO mode offers many security features not present in EDGE mode. Instances of different accounts are deployed in user-defined isolated networks within a Eucalyptus cloud. A combination of security features including VPC, VPC subnets, security groups, source/destination check configuration, route tables, internet gateways, and NAT gateways can be used to selectively enable and configure network access to/from instances or group of instances.

For more information about choosing a networking modes, see Plan Networking Modes .

2.6.3 - Security Tasks

Tasks

This section details the tasks needed to make your cloud secure.

2.6.3.1 - Configure SSL

Configure SSL

In order to connect to Eucalyptus using SSL, you must have a valid certificate for the User-Facing Services (UFS).

2.6.3.1.1 - Configure and Enable SSL for the Management Console

You can use secure HTTP for your console.To run your console over Secure HTTP:

Install nginx on your console server with the following command: yum install nginx Overwrite the default nginx.conf file with the template provided in /usr/share/doc/eucaconsole-/nginx.conf. cp /usr/share/doc/eucaconsole-/nginx.conf /etc/nginx/nginx.conf Uncomment the ’listen’ directive and uncomment/modify the SSL certificate paths in /etc/nginx/nginx.conf (search for “SSL configuration”). For example:

# SSL configuration
listen 443 ssl;
# ssl_certificate /path/to/ssl/pem_file;
# EXAMPLE:
ssl_certificate /etc/eucaconsole/console.crt;
# ssl_certificate_key /path/to/ssl/certificate_key;
# EXAMPLE: 
ssl_certificate_key /etc/eucaconsole/console.key;
# end of SSL configuration

session.secure = true
sslcert=/etc/eucaconsole/eucalyptus.com.chained.crt
sslkey=/etc/eucaconsole/eucalyptus.com.key

2.6.3.1.2 - Configure and Enable SSL for the UFS

This topic details tasks to configure SSL/TLS for the User-Facing Services (UFS)

If you have more than one host (other than node controllers), note the following:

• The keystore must be updated on each host running the eucalyptus-cloud service
• The [key_alias] must be the same on each host
• Use a wildcard certificate (i.e. *.<system.dns.dnsdomain>), since UFS is responsible for all service API endpoints

Create a Keystore

Eucalyptus uses a PKCS12-format keystore. If you are using a certificate signed by a trusted root CA, perform the following steps.

Enter the following command to convert your trusted certificate and key into an appropriate format:

openssl pkcs12 -export -in [YOURCERT.crt] -inkey [YOURKEY.key] \
  -out tmp.p12 -name [key_alias]

Save a backup of the Eucalyptus keystore, at /var/lib/eucalyptus/keys/euca.p12 . Import your keystore into the Eucalyptus keystore on the UFS:

keytool -importkeystore -srckeystore tmp.p12 -srcstoretype pkcs12 \
  -srcstorepass [export_password] -destkeystore /var/lib/eucalyptus/keys/euca.p12 \
  -deststoretype pkcs12 -deststorepass eucalyptus -alias [key_alias] -destkeypass eucalyptus

Enable the UFS to Use the Keystore

To enable the UFS to use the keystore, perform the following steps in the CLC because the UFS gets all its configuration information from the CLC. Run the following commands on the CLC:

euctl bootstrap.webservices.ssl.server_alias=[key_alias]

Optional: Redirect Requests to use Port 443

To allow user facing services requests on port 443 instead of the default 8773, run the following commands on the CLC:

euctl bootstrap.webservices.port=443

2.6.3.2 - Change Multicast Address

This topic describes how to change your multicast address for group membership.By default, Eucalyptus uses the multicast address 239.193.7.3 for group membership. Most data centers limit multicast address communication for security measures. We recommend that you use addresses in the administratively-scoped multicast address range.

To change the multicast address for group membership Stop all services, starting from the CC, SC, Walrus, then CLC. For example:

systemctl stop eucalyptus-cluster.service
systemctl stop eucalyptus-cloud.service

Change the eucalyptus.conf on the CC, modifying the CLOUD_OPTS parameter to the new IP address:

CLOUD_OPTS="--mcast-addr=228.7.7.3"

systemctl start eucalyptus-cloud.service
systemctl start eucalyptus-cluster.service

Verify that the configured multicast address is being used via netstat:

netstat -nulp

Postrequisites

• Check the firewall after changing the multicast address. See for more information.

2.6.3.3 - Configure Replay Protection

You can configure replay detection in Java components (which includes the CLC, UFS, OSG, Walrus, and SC) to allow replays of the same message for a set time period.

euctl bootstrap.webservices.replay_skew_window_sec=[new_value_in_seconds]

If you set this property to 0 , Eucalyptus will not allow any message replays. This setting provides the best protection against message replay attacks.

If you set this property to any value greater than 15 minutes plus the values of ws.clock_skew_sec (that is, to a value >= 920 sec in the default installation), Eucalyptus disables replay detection completely.

When checking message timestamps for expiration, Eucalyptus allows up to 20 seconds of clock drift between the machines. This is a default setting. You can change this value for the Java components at runtime by setting the bootstrap.webservices.clock_skew_sec property as follows:

euctl bootstrap.webservices.clock_skew_sec=[new_value_in_seconds]

2.6.3.4 - Configure Session Timeouts

To set the session timeouts in the Management Console:

Modify the session.timeout and session.cookie_expires entries in the [app:main] section of the configuration file. The session.timeout value defines the number of seconds before an idle session is timed out. The session.cookie_expires is the maximum length that any session can be active before being timed out. All values are in seconds:

session.timeout=1800



session.cookie_expires=43200

2.6.3.5 - Configure STS Actions

The Security Token Service (STS) allows you to enable or disable specific token actions.By default, the enabled actions list is empty. However, this means that all actions are enabled. To disable actions, list each action in the disabledactions property. To enable specific actions, list them in the enabledactions property.

# euctl tokens
PROPERTY	tokens.disabledactions	{}
PROPERTY	tokens.enabledactions	{}

The values for each property are case-insensitive, space or comma-separated lists of token service actions. If an action is in the disable list it will not be permitted. Eucalyptus returns an HTTP status 503 and the code ServiceUnavailable .

If the enable list is not empty, Eucalyptus only permits the actions specifically listed.

For more information about STS, go to STS section of the AWS CLI Reference .

2.6.3.6 - Configure the Firewall

Restricting Network Access

This section provides basic guidance on setting up a firewall around your Eucalyptus components. It is not intended to be exhaustive.

On the Cloud Controller (CLC), Walrus, and Storage Controller (SC), allow for the following jGroups traffic:

• TCP connections between CLC, user-facing services (UFS), object storage gateway (OSG), Walrus, and SC on port 8779 (or the first available port in range 8779-8849)

• UDP connections between CLC, UFS, OSG, Walrus, and SC on port 7500

• Multicast connections between CLC and UFS, OSG, Walrus, and SC to IP 239.193.7.3 on UDP port 8773 On the UFS, allow the following connections:

• TCP connections from end-users and instances on ports 8773

• End-user and instance connections to DNS ports On the CLC, allow the following connections:

• TCP connections from UFS, CC and Eucalyptus instances (public IPs) on port 8773 (for metadata service)

• TCP connections from UFS, OSG, Walrus, and SC on port 8777 On the CC, make sure that all firewall rules are compatible with the dynamic changes performed by Eucalyptus, described in the section below. Also allow the following connections:

• TCP connections from CLC on port 8774 On OSG, allow the following connections:

• TCP connections from end-users and instances on port 8773

• TCP connections from SC and NC on port 8773 On Walrus, allow the following connections:

• TCP connections from OSG on port 8773 On the SC, allow the following connections:

• TCP connections from CLC and NC on TCP port 8773

• TCP connections from NC on TCP port 3260, if tgt (iSCSI open source target) is used for EBS in DAS or Overlay modes On the NC, allow the following connections:

• TCP connections from CC on port 8775

• TCP connections from other NCs on port 16514

• DHCP traffic forwarding to VMs

• Traffic forwarding to and from instances’ private IP addresses

2.6.3.7 - Reserve Ports

2.6.3.8 - Synchronize Components

To synchronize your Eucalyptus component machines with an NTP server, perform the following tasks.

Enter the following command on a machine hosting a Eucalyptus component:

# ntpdate pool.ntp.org
# systemctl start ntpd.service
# systemctl enable ntpd.service
# ps ax | grep ntp
# hwclock --systohc  

Repeat for each machine hosting a Eucalyptus component.

2.7 - Eucalyptus Commands

Eucalyptus Commands

This section contains reference information for Eucalyptus administration commands.

2.7.1 - Eucalyptus Administration Commands

Eucalyptus Administration Commands

Eucalyptus offers commands for common administration tasks and inquiries. This section provides a reference for these commands.

2.7.1.1 - euctl

Syntax

euctl [-Anr] [-d | -s] NAME ...
euctl [-nq] NAME=VALUE ...
euctl [-nq] NAME=@FILE ...
euctl --dump [--format {raw,json,yaml}] NAME
euctl --edit [--format {raw,json,yaml}] NAME

Positional Arguments

Options

Examples

When retrieving a variable, a subset of the MIB name may be specified to retrieve a list of variables in that subset. For example, to list all the dns variables:

euctl dns

This replaces euca-describe-properties .

When setting a variable, the MIB name should be followed by an equal sign and the new value:

euctl dns.enabled=true

This replaces euca-modify-property -p .

To write variables using the contents of the files as their new values rather than typing them into the command line, follow them with =@ and those file names:

euctl cloud.network.network_configuration=@/etc/eucalyptus/network.yaml

This replaces euca-modify-property -f .

Specify a filename to read the values from a file:

myproperty=@myvaluefile

It is possible to read or write more than one variable in a single invocation of euctl . Just separate them with spaces:

euctl one=1 two=2 three four=@4.txt five

In all of these cases, euctl will generally output each variable named on its command line, along with its current (and potentially just-changed) value. For example, the output of the command above could be:

one = 1 
two = 2
three = 3
four = 4
five = 5

To reset a variable to its default value, specify the -r option:

euctl -r dns.enabled

The information available from euctl consists of integers, strings, and structures. The structured information can only be retrieved by specialized programs and, in some cases, this program’s --edit and --dump options.

2.7.1.2 - euserv-deregister-service

Syntax

euserv-deregister-service [-U URL] [--region USER@REGION] [-I KEY_ID]

       [-S KEY] [--security-token TOKEN] [--debug]
              [--debugger] [--version] [-h] SVCINSTANCE

Positional Arguments

Output

Eucalyptus returns a message stating that service instance was successfully de-registered.

Example

To de-register the dns service named “API_10.111.1.44.dns”:

euserv-deregister-service API_10.111.1.44.dns

2.7.1.3 - euserv-describe-events

Syntax

euserv-describe-events [-s] [-f FORMAT]

Description

Events come in the form of a list, where each event contains one or more of the following tags:

Environment

Options

Output

There are several built-in formats, and you can define additional formats using a format: string , as described below. Here are the details of the built-in formats:

yaml This outputs block-style YAML designed to be easily readable. Tags that are empty or not defined do not appear in this output at all.

events:
            - timestamp: {timestamp}
            severity: {severity}
            id: {id}
            subject-type: {subject-type}
            subject-name: {subject-name}
            subject-host: {subject-host}
            subject-arn: {subject-arn}
            message: |-
            {message}
            stack-trace: |-
            {stack-trace}

oneline This output is designed to be as compact as possible.

{timestamp} {severity} {subject-type} {subject-name} {message}

format:string The format: string format allows you to specify which information you want to show using placeholders enclosed in curly braces to indicate where to show the tags for each event. For example:

euserv-describe-events -f "format:{timestamp} {subject-name} {message}"

Example

To output a list of service-affecting events in the oneline format:

euserv-describe-events --format oneline
2016-06-20 16:16:08 INFO node 10.111.1.15 the node is operating normally\nFound service status for 10.111.1.15: ENABLED
2016-06-27 17:37:57 ERROR node 10.111.5.50 Error occurred in transport
2016-06-28 07:00:17 ERROR node 10.111.5.50

2.7.1.4 - euserv-describe-node-controllers

Syntax

euserv-describe-node-controllers [--ec2-url URL] [--show-headers]

   [--show-empty-fields] [-U URL]
          [--region USER@REGION] [-I KEY_ID]  [-S  KEY]  [--security-token
          TOKEN] [--debug] [--debugger] [--version] [-h]

Options

Output

Eucalyptus returns information about the node controller and its instances, for example:

NODE  one  10.111.1.53  enabled    
INSTANCE  i-162a8f09      
INSTANCE  i-2b6cdd10      
NODE  one  10.111.5.132  enabled    
INSTANCE  i-ba9307d7

Example

euserv-describe-node-controllers --region localhost

2.7.1.5 - euserv-describe-service-types

Syntax

euserv-describe-service-types [-a] [--show-headers]

[--show-empty-fields] [-U URL]
   [--region  USER@REGION]  [-I  KEY_ID]  [-S  KEY] [--security-token TOKEN]
   [--debug] [--debugger] [--version] [-h]

Options

Output

Eucalyptus returns a list of service types.

Example

euserv-describe-service-types 
SVCTYPE  arbitrator                The Arbitrator service                                      
SVCTYPE  autoscaling     user-api  Auto Scaling API service                                    
SVCTYPE  cloudformation  user-api  Cloudformation API service                                  
SVCTYPE  cloudwatch      user-api  CloudWatch API service                                      
SVCTYPE  cluster                   The Cluster Controller service                              
SVCTYPE  compute         user-api  the Eucalyptus EC2 API service                              
SVCTYPE  dns             user-api  Eucalyptus DNS server                                       
SVCTYPE  euare           user-api  IAM API service                                             
SVCTYPE  eucalyptus                eucalyptus service implementation                           
SVCTYPE  identity        user-api  Eucalyptus identity service                                 
SVCTYPE  imaging         user-api  Eucalyptus imaging service                                  
SVCTYPE  loadbalancing   user-api  ELB API service                                             
SVCTYPE  objectstorage   user-api  S3 API service                                              
SVCTYPE  simpleworkflow  user-api  Simple Workflow API service                                 
SVCTYPE  storage                   The Storage Controller service                              
SVCTYPE  tokens          user-api  STS API service                                             
SVCTYPE  user-api                  The service group of all user-facing API endpoint services  
SVCTYPE  walrusbackend             The legacy Walrus Backend service

2.7.1.6 - euserv-describe-services

Syntax

euserv-describe-services [-a]

       [--group-by-type | --group-by-zone | --group-by-host | --expert]
         [--show-headers]   [--show-empty-fields]   [-U   URL]  [--region
         USER@REGION]  [-I  KEY_ID]  [-S  KEY]  [--security-token  TOKEN]
         [--filter  NAME=VALUE]  [--debug]  [--debugger] [--version] [-h]
         [SVCINSTANCE [SVCINSTANCE ...]]

Positional Arguments

Options

Output

Eucalyptus returns information about the services you specified.

Example

Verify that you are looking at the cloud controllers view of the service state by explicitly running against that host:

euserv-describe-services --filter service-type=storage -U http://localhost:8773/services/Empyrean
SERVICE  storage  one  one-sc-1  enabled

2.7.1.7 - euserv-migrate-instances

Syntax

euserv-migrate-instances (-s HOST | -i INSTANCE)

  [--include-dest HOST | --exclude-dest HOST]
  [-U URL] [--region USER@REGION] [-I KEY_ID]  [-S  KEY]  [--security-token
  TOKEN] [--debug] [--debugger] [--version] [-h]

Options

Output

Unless requested, no output is given. You can run the euserv-describe-* command to verify that the migration activity completed successfully, as shown in the example following.

Example

To migrate an instance from its current host:

euserv-migrate-instances -i i-8eacd211 
euserv-describe-node-controllers 
NODE  zone-555  10.104.1.200  enabled    

NODE  zone-555  10.104.1.201  enabled    
INSTANCE  i-8eacd211      

2.7.1.8 - euserv-modify-service

Syntax

euserv-modify-service -s STATE [-U URL] [--region USER@REGION]

   [-I KEY_ID] [-S KEY] [--security-token TOKEN]
   [--debug] [--debugger] [--version] [-h] SVCINSTANCE

Positional Arguments

Options

Output

No output is given. You can run the euserv-describe-services command to verify that the modification completed successfully, as shown in the example following.

Example

To modify the state of a storage controller service named “two-sc-1” to stopped:

euserv-modify-service -s stopped two-sc-1
euserv-describe-services two-sc-1
SERVICE  storage  two  two-sc-1  stopped  

2.7.1.9 - euserv-register-service

Syntax

euserv-register-service -t TYPE -h IP [--port PORT] [-z ZONE] [-U URL]

       [--region USER@REGION] [-I KEY_ID] [-S KEY]
           [--security-token   TOKEN]  [--debug]  [--debugger]  [--version]
           [--help] SVCINSTANCE

Positional Arguments

Options

Output

No output is given when it succeeds.

Example

To register the ufs service named “user-api-5”:

euserv-register-service -t user-api -h 10.0.0.15 user-api-5

2.7.2 - Eucalyptus Configuration Variables

Eucalyptus exposes a number of variables that can be configured using the command. This topic explains what types of variables Eucalyptus uses, and lists the most common configurable variables.

Eucalyptus Variable Types

Eucalyptus uses two types of variables: ones that can be changed (as configuration options), and ones that cannot be changed (they are displayed as variables, but configured by modifying the eucalyptus.conf file on the CC).

Eucalyptus Variables

The following table contains a list of common Eucalyptus cloud variables.

2.8 - Advanced Storage Configuration

Advanced Storage Configuration

This section covers advanced storage provider configuration options.

2.8.1 - OSG Advanced Configuration

The following properties are for tuning the behavior of the Object Storage service and Gateways; the defaults are reasonable and changing is not necessary, but they are available for unexpected situations.

3 - User Guide

User Guide

This User Guide instructs you how to use a Eucalyptus private cloud. As a cloud user, you will set up your account, work with images, launch instances, and so on. To install or administer and operate a Eucalyptus cloud, refer to the Eucalyptus Installation Guide and the Administration Guide, respectively.Enjoy using your Eucalyptus private cloud!

3.1 - Eucalyptus Overview

Eucalyptus is open source software for building AWS-compatible private and hybrid clouds. As an Infrastructure as a Service product, Eucalyptus allows you to flexibly provision your own collections of resources (both compute and storage), on an as-needed basis.

Who Should Read this Guide?

This guide is for Eucalyptus users who wish to run application workloads on a Eucalyptus cloud.

What’s in this Guide?

This guide contains instructions for users of the Eucalyptus cloud platform. While these instructions apply generally to all tools capable of interacting with Eucalyptus, such as the Eucalyptus Management Console or the AWS S3 toolset, but the primary focus is on the use of Euca2ools (Eucalyptus command line tools). The following is an overview of the contents of this guide.

Eucalyptus Features

Eucalyptus offers ways to implement, manage, and maintain your own collection of virtual resources (machines, network, and storage). The following is an overview of these features.

AWS API compatibility

Eucalyptus provides API compatibility with Amazon Web Services, to allow you to use familiar tools and commands to provision your cloud.

Block- and bucket-based storage abstractions

Eucalyptus provides storage options compatible with Amazon’s EBS (block-based) and S3 (bucket-based) storage products.

Self-service capabilities

Eucalyptus offers a Management Console, allowing your users to request the resources they need, and automatically provisioning those resources where available.

Web-based Interface

The Eucalyptus Management Console is accessible from any device via a browser. The Console initial page provides a Dashboard view of components available to you to manage, configure, provision, and generate various reports.

Resource Management

Eucalyptus offers tools to seamlessly manage a variety of virtual resources. The following is an overview of the types of resources your cloud platform.

SSH Key Management

Eucalyptus employs public and private keypairs to validate your identity when you log into VMs using SSH. You can add, describe, and delete keypairs.

Image Management

Before running instances, someone must prepare VM images for use in the cloud. This can be an administrator or a user. Eucalyptus allows you to bundle, upload, register, describe, download, unbundle, and deregister VM images.

Linux Guest OS Support

Eucalyptus lets you run your own VMs in the cloud. You can run, describe, terminate, and reboot a wide variety of Linux-based VMs that were prepared using image management commands.

IP Address Management

Eucalyptus can allocate, associate, disassociate, describe, and release IP addresses. Depending on the networking mode, you might have access to public IP addresses that are not statically associated with a VM ( Elastic IPs ). Eucalyptus provides tools to allow users to reserve and dynamically associate these elastic IPs with virtual machines.

Security Group Management

Security groups are sets of firewall rules applied to VMs associated with the group. Eucalyptus lets you create, describe, delete, authorize, and revoke security groups. How much of these things can a typical user actually do?

Volume and Snapshot Management

Eucalyptus allows you to create dynamic block volumes. A dynamic block volume is similar to a raw block storage device that can be used with virtual machines. You can create, attach, detach, describe, bundle, and delete volumes. You can also create and delete snapshots of volumes and create new volumes from snapshots.

3.2 - Getting Started

Getting Started

This section helps you get started using your Eucalyptus cloud, and covers setting up your user credentials, installing and configuring command line tools, and working with images and instances. As a cloud user, you can access the Eucalyptus cloud using a command line interface such as the AWS CLI, or by using a web-based interface such as the Eucalyptus Management Console.

To access Eucalyptus via the command line, you can use the AWS CLI or Euca2ools with access key credentials. To access Eucalyptus with the Management Console, you’ll need a password. Talk to your cloud administrator to get your keys and passwords.

3.2.1 - Getting Started with the Eucalyptus Management Console

Getting Started with the Eucalyptus Management Console

This section helps you get started using your Eucalyptus cloud with the Eucalyptus Management Console.To access Eucalyptus with the Management Console, you’ll need a password for the Management Console. Talk to your cloud administrator to get your keys and passwords.

3.2.1.1 - Console Login

This screen allows you to log in to the Eucalyptus Management Console with either your Eucalyptus or your Amazon Web Services account. If you’ve forgotten your password, don’t have login credentials, or do not know the URL for the Eucalyptus Management Console for your Eucalyptus account, please contact your system administrator.Navigate to the Eucalyptus Management Console by typing the URL of the Management Console into your browser’s navigation bar. The URL of the Eucalyptus Management Console depends on how the console was installed in your cloud; see your system administrator for the specific URL for your installation. Follow the appropriate instructions below for logging into either your Eucalyptus or your Amazon Web Services cloud.

Log in to your Eucalyptus cloud

This area of the login dialog allows you to log in to your Eucalyptus cloud.Click the Log in to Eucalyptus tab. Type your account name into the Account name text box. Type your user name into the User name text box. Type your password into the Password text box. Click the Log in to Eucalyptus button.

Log in to your Amazon Web Services cloud

This area of the login dialog allows you to log in to your Amazon Web Services cloud.Click the Log in to AWS tab.

3.2.1.2 - Launch and Connect to an Instance with the Management Console

To launch an instance:

Click on the Launch Instance button on the main console page: Select an image from the list (for this example, we’ll select a CentOS image), then click the Next button: Select an instance type and availability zone from the Details tab. For this example, select the defaults, and then click the Next button: On the Security tab, we’ll create a key pair and a security group to use with our new instance. A key pair will allow you to access your instance, and a security group allows you to define what kinds of incoming traffic your instance will allow. First, we will create a key pair. Click the Create key pair link to bring up the Create key pair dialog: Type the name of your new key pair into the Name text box, and then click the Create and Download button: The key pair automatically downloads to a location on your computer, typically in the Downloads folder. The Create key pair dialog will close, and the Key name text box will be populated with the name of the key pair you just created: Next, we will create a security group. Click the Create security group link to bring up the Create security group dialog: On the Create security group dialog, type the name of your security group into the Name text box. Type a brief description of your security group into the Description text box. We’ll need to SSH into our instance later, so in the Rules section of the dialog, select the SSH protocol from the Protocol drop-down list box.

ssh -i my-test-keypair.private root@10.111.57.109 

3.2.1.3 - Set Up A Web Server on an Instance

Once you’ve launched an instance and connected to it, you can test it by setting up a web server.

ssh into your instance.

ssh 192.168.1.1 -l root

Install Apache:

yum install -y httpd

You should see output similar to the following:

Loaded plugins: fastestmirror, security, versionlock
Loading mirror speeds from cached hostfile
 * extras: centos.sonn.com
centos-7-x86_64-os                                       | 3.7 kB     00:00
centos-7-x86_64-updates                                  | 3.4 kB     00:00
centos-7-x86_64-updates/primary_db                       | 5.4 MB     00:00
epel-7-x86_64                                            | 4.4 kB     00:00
epel-7-x86_64/primary_db                                 | 6.3 MB     00:00
extras                                                   | 3.3 kB     00:00
Setting up Install Process
Package httpd-2.2.15-31.el7.centos.x86_64 already installed and latest version
Nothing to do

Start the web server:

systemctl start httpd.service

You should see output similar to the following:

Starting httpd:                                            [  OK  ]

Test connectivity to your instance by using a web browser and connecting to the web service on your instance. For example:

3.2.1.4 - Reboot an Instance with the Management Console

Rebooting preserves the root filesystem of an instance across restarts. To reboot an instance:

On the Instances page, select Reboot from the Actions menu next to the instance you want to reboot. Click the Yes, Reboot button.

3.2.1.5 - Terminate an Instance with the Management Console

On the Instances page, Select Terminate from the Actions menu next to the instance you want to terminate. Click the Yes, Terminate button. The Status field of the instance will first change to Shutting-down : …and then change to Terminated :

3.2.2 - Getting Started with the AWS CLI

This section helps you get started using your Eucalyptus cloud, and covers setting up your user credentials, installing and configuring the AWS CLI, and working with images and instances. As a cloud user, you can access the Eucalyptus cloud using a command line interface such as the AWS CLI, or using a web-based interface such as the Eucalyptus Management Console.

The install guide covers “AWS CLI Installation”

Find Image

Enter the following command:

# aws ec2 describe-images
IMAGES	x86_64	2020-10-17T05:29:09.161Z	emi-0ba907069cb1845bc	ubuntu-focal/focal-server-cloudimg-amd64.raw.manifest.xml	machine	ubuntu-focal	000575948401		True	/dev/sda	instance-store	available	hvm
IMAGES	x86_64	2020-10-17T05:24:08.857Z	emi-371ada125a928669e	centos-7/CentOS-7-x86_64-GenericCloud-2003.raw.manifest.xml	machine	centos-7	000575948401		True	/dev/sda	instance-store	available	hvm

Look for the image ID and write it down. The image ID starts with emi- . Once you find a suitable image to use, make sure you have a keypair to use.

Create KeyPairs

Enter the following command:

aws ec2 create-key-pair --key-name <keypair_name> > <keypair_name>.private

where <keypair_name> is a unique name for your keypair. For example:

aws ec2 create-key-pair --key-name "alice-keypair" > "alice-keypair.private"

The private key is saved to a file in your local directory. Query the system to view the public key:

# aws ec2 describe-key-pairs
KEYPAIRS	92:40:28:cb:08:54:80:95:8d:69:d9:ab:9a:ff:28:30:40:12:6a:66	alice-keypair

Authorize Security Groups

Before you can log in to an instance, you must authorize access to that instance. This done by configuring a security group for that instance.

A security group is a set of networking rules applied to instances associated with that group. When you first create an instance, it is assigned to a default security group that denies incoming network traffic from all sources. To allow login and usage of a new instance, you must authorize network access to the default security group with the authorize-security-group-ingress command.

To authorize a security group, use authorize-security-group-ingress with the name of the security group, and the options of the network rule permissions you want to apply.

aws ec2 authorize-security-group-ingress [--group-id <value>] [--group-name <value>] [--ip-permissions <value>]

Use the following command to grant unlimited network access using SSH (TCP, port 22) and VNC (TCP, ports 5900 to 5910) to the security group default :

# aws ec2 authorize-security-group-ingress --ip-permissions "IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges={CidrIp=0.0.0.0/0}" --group-name default 
# aws ec2 authorize-security-group-ingress --ip-permissions "IpProtocol=tcp,FromPort=5900,ToPort=5910,IpRanges={CidrIp=0.0.0.0/0}" --group-name default 

Launch an Instance

Use the run-instances command and provide an image ID. For example:

aws ec2 run-instances --image-id emi-371ada125a928669e

For additional details and options that can be used with the run-instances command. Enter the following command to get the launch status of the instance:

aws ec2 describe-instances --instance-ids <instance_id>

Log in to an Instance

When you create an instance, Eucalyptus assigns the instance two IP addresses: a public IP address and a private IP address. The public IP address provides access to the instance from external network sources; the private IP address provides access to the instance from within the Eucalyptus cloud environment. For more information on Eucalyptus networking modes, see the Eucalyptus Administrator’s Guide.

To use an instance you must log into it via ssh using one of the IP addresses assigned to it. You can obtain the instance’s IP addresses using the describe-instances query as shown in the following example.

To log into a VM instance:

Enter the following command to view the IP addresses of your instance:

# aws ec2 describe-instances
RESERVATIONS	000332850814	r-825a2c9c04e97ee62
GROUPS	sg-84741faf0bd87ea73	default
INSTANCES	0	x86_64	emi-371ada125a928669e	i-131e5853a71c87f16	t2.micro	2020-10-19T16:35:36.120Z	euca-172-31-15-2.eucalyptus.internal	172.31.15.2	euca-192-168-134-74.eucalyptus.mycloud.example.com	192.168.134.74	/dev/sda1	instance-store	True	NORMAL:  -- []	subnet-1343e38b5566c8e90	hvm	vpc-bded94e5dd0a07bc3
MONITORING	disabled
NETWORKINTERFACES	Primary network interface	d0:0d:c1:ba:7d:64	eni-c1ba7d641cb70a7ee	000332850814	euca-172-31-15-2.eucalyptus.internal	172.31.15.2	True	in-usesubnet-1343e38b5566c8e90	vpc-bded94e5dd0a07bc3
ASSOCIATION	euca-192-168-134-74.eucalyptus.mycloud.example.com	192.168.134.74
ATTACHMENT	2020-10-19T16:35:36.125Z	eni-attach-d597b44874e84bbb2	True	0	attached
GROUPS	sg-84741faf0bd87ea73	default
PRIVATEIPADDRESSES	True	euca-172-31-15-2.eucalyptus.internal	172.31.15.2
ASSOCIATION	euca-192-168-134-74.eucalyptus.mycloud.example.com	192.168.134.74
PLACEMENT	cloud-1a
SECURITYGROUPS	sg-84741faf0bd87ea73	default
STATE	16	running

Note that the public IP address is on the INSTANCES line after “mycloud.example.com”, the private address is after “eucalyptus.internal”.

Look for the instance ID on the INSTANCE line and write it down. Use this ID to manipulate and terminate this instance.

Use SSH to log into the instance, using your private key and the public IP address. For example:

ssh -i alice-keypair.private root@192.168.134.74 

You are now logged in to your Linux instance.

Terminate an Instance

The terminate-instances command lets you cancel running VM instances. When you terminate instances, you must specify the ID string of the instance(s) you wish to terminate. You can obtain the ID strings of your instances using the describe-instances or describe-instance-status commands.

To terminate VM instances:

Enter describe-instance-status to obtain the ID of the instances you wish to terminate. Note that an instance ID strings begin with the prefix i- followed by an 8-character string:

# aws ec2 describe-instance-status 
INSTANCESTATUSES	cloud-1a	i-131e5853a71c87f16
INSTANCESTATE	16	running
INSTANCESTATUS	ok
DETAILS	reachability	passed
SYSTEMSTATUS	ok
DETAILS	reachability	passed

Enter terminate-instances and the ID string(s) of the instance(s) you wish to terminate:

# aws ec2 terminate-instances --instance-ids i-131e5853a71c87f16
TERMINATINGINSTANCES	i-131e5853a71c87f16
CURRENTSTATE	32	shutting-down
PREVIOUSSTATE	16	running

3.2.3 - Getting Started with Euca2ools

This section helps you get started using your Eucalyptus cloud, and covers setting up your user credentials, installing and configuring the command line tools, and working with images and instances.As a cloud user, you can access the Eucalyptus cloud using a command line interface such as Euca2ools, or using a web-based interface such as the Eucalyptus Management Console.

To access Eucalyptus via the command line tools, you need keys for Euca2ools. To access Eucalyptus with the Management Console, you’ll need a password for the Management Console. Talk to your cloud administrator to get your keys and passwords.

Find Image

Enter the following command:

# euca-describe-images -a
IMAGE	emi-0ba907069cb1845bc	ubuntu-focal/focal-server-cloudimg-amd64.raw.manifest.xml	000575948401	available	public	x86_64	machine				instance-storehvm	
IMAGE	emi-371ada125a928669e	centos-7/CentOS-7-x86_64-GenericCloud-2003.raw.manifest.xml	000575948401	available	public	x86_64	machine				instance-storehvm	

Look for the image ID in the second column and write it down. The image ID starts with emi- . Once you find a suitable image to use, make sure you have a keypair to use.

Create KeyPairs

Enter the following command:

euca-create-keypair -f <keypair_name>.private <keypair_name>

where <keypair_name> is a unique name for your keypair. For example:

euca-create-keypair -f "alice-keypair.private" "alice-keypair"

The private key is saved to a file in your local directory. Query the system to view the public key:

# euca-describe-keypairs
KEYPAIR	alice-keypair	92:40:28:cb:08:54:80:95:8d:69:d9:ab:9a:ff:28:30:40:12:6a:66

Authorize Security Groups

Before you can log in to an instance, you must authorize access to that instance. This done by configuring a security group for that instance.

A security group is a set of networking rules applied to instances associated with that group. When you first create an instance, it is assigned to a default security group that denies incoming network traffic from all sources. To allow login and usage of a new instance, you must authorize network access to the default security group with the euca-authorize command.

To authorize a security group, use euca-authorize with the name of the security group, and the options of the network rules you want to apply.

euca-authorize <security_group>

Use the following command to grant unlimited network access using SSH (TCP, port 22) and VNC (TCP, ports 5900 to 5910) to the security group default :

# euca-authorize -P tcp -p 22 -s 0.0.0.0/0 default
# euca-authorize -P tcp -p 5900-5910 -s 0.0.0.0/0 default

Launch an Instance

Use the euca-run-instances command and provide an image ID and the user data file, in the format euca-run-instances <image_id> . For example:

euca-run-instances emi-371ada125a928669e

For additional details and options that can be used with the euca-run-instances command. Enter the following command to get the launch status of the instance:

euca-describe-instances <instance_id>

Log in to an Instance

When you create an instance, Eucalyptus assigns the instance two IP addresses: a public IP address and a private IP address. The public IP address provides access to the instance from external network sources; the private IP address provides access to the instance from within the Eucalyptus cloud environment. For more information on Eucalyptus networking modes, see the Eucalyptus Administrator’s Guide.

To use an instance you must log into it via ssh using one of the IP addresses assigned to it. You can obtain the instance’s IP addresses using the euca-describe-instances query as shown in the following example.

To log into a VM instance:

Enter the following command to view the IP addresses of your instance:

# euca-describe-instances
RESERVATION	r-825a2c9c04e97ee62	000332850814	default
INSTANCE	i-131e5853a71c87f16	emi-371ada125a928669e	euca-192-168-134-74.eucalyptus.mycloud.example.com	euca-172-31-15-2.eucalyptus.internal	running		0		t2.micro	2020-10-19T16:35:36.120Z	cloud-1a				monitoring-disabled	192.168.134.74	172.31.15.2	vpc-bded94e5dd0a07bc3	subnet-1343e38b5566c8e90	instance-store					hvm			sg-84741faf0bd87ea73				x86_64
NETWORKINTERFACE	eni-c1ba7d641cb70a7ee	subnet-1343e38b5566c8e90	vpc-bded94e5dd0a07bc3	000332850814	in-use	172.31.15.2	euca-172-31-15-2.eucalyptus.internal	true
ATTACHMENT		eni-attach-d597b44874e84bbb2	0	attached	2020-10-19T16:35:36.125Z	true
ASSOCIATION	192.168.134.74		172.31.15.2
GROUP	sg-84741faf0bd87ea73	default
PRIVATEIPADDRESS	172.31.15.2	euca-172-31-15-2.eucalyptus.internal	primary

Note that the public IP address appears after the monitoring-disabled text, with the private address immediately following.

Look for the instance ID in the second field of the INSTANCE line and write it down. Use this ID to manipulate and terminate this instance.

Use SSH to log into the instance, using your private key and the public IP address. For example:

ssh -i alice-keypair.private root@192.168.134.74 

You are now logged in to your Linux instance.

Terminate an Instance

The euca-terminate-instances command lets you cancel running VM instances. When you terminate instances, you must specify the ID string of the instance(s) you wish to terminate. You can obtain the ID strings of your instances using the euca-describe-instances or euca-describe-instance-status commands.

To terminate VM instances:

Enter euca-describe-instance-status to obtain the ID of the instances you wish to terminate. Note that an instance ID strings begin with the prefix i-:

# euca-describe-instance-status
INSTANCE	i-131e5853a71c87f16	cloud-1a	running	16	ok	ok	active	
SYSTEMSTATUS	reachability	passed	
INSTANCESTATUS	reachability	passed

Enter euca-terminate-instances and the ID string(s) of the instance(s) you wish to terminate:

# euca-terminate-instances i-131e5853a71c87f16
INSTANCE	i-131e5853a71c87f16	running	shutting-down

3.3 - Using Instances

Using Instances

Any application that runs on a cloud, whether public or private or hybrid, runs inside at least one . To start using the cloud, you must launch one or more instances. Every instance is created from stored . An image contains the basic operating system and often other software that will be needed when the instance is running. When you launch an instance, you tell the cloud what image to base the instance on. Your cloud administrator should have set up a catalog of standard or customized images for you to use.To find out more about what instances are, see Instance Overview .

To find out how to use CloudWatch, see Instance Tasks .

3.3.1 - Instance Overview

Instance Overview

An instance is a virtual machine (VM). Eucalyptus allows you to run instances from registered images.

The following sections describe instances in more detail.

3.3.1.1 - Instance Concepts

This section describes conceptual information to help you understand instances.

Eucalyptus Machine Image (EMI)

A Eucalyptus machine image (EMI) is a copy of a virtual machine bootable file system stored in the Walrus storage. An EMI is a template from you can use to deploy multiple identical instances—or copies of the virtual machine.

EMIs are analogous to Amazon Machine Images (AMIs) in AWS. In fact, you can download and deploy any of the 10,000+ AMIs as EMIs in a Eucalyptus cloud without significant modification. While it is possible to build your own EMI, it is might be just as simple to find a thoroughly vetted, freely available image in AWS, download it to your Eucalyptus cloud, and use that instead.

When registered in a Eucalyptus cloud, each distinct EMI is given a unique ID for identification. The ID is in the format emi-.

Instance

A instance is a virtual machine deployed from an EMI. An instance then, is simply a running copy of an EMI, which means it always starts from a known baseline. There are two types of instances; instance store-backed and EBS-backed. This section describes store-backed instances. For information about EBS-backed instances, see Using EBS .

Every instance receives a unique ID in the format i-.

You can deploy multiple instances using a single command. In this case all the instances will have unique instance IDs but will share a common reservation ID. This reservation ID can be seen, for example, from the euca2ools euca-describe-instances command that lists running instances. Reservations IDs appear in the format r-.

Persistence

Applications running in ephemeral instances that generate data that must be saved should write that data to some place other than the instance itself. There are two Eucalyptus options available. First, the data can be written to a volume that is attached to the instance. Volumes provided by the Storage Controller and attached to instances are persistent. Second, the data could be written to the Walrus using HTTP put/get operations. Walrus storage is also persistent.

If the application cannot be rewritten to send data to a volume or the Walrus, then the application should be deployed inside an EBS-backed instance. EBS-backed instances are persistent and operate in a manner more similar to a physical machine.

3.3.1.2 - Instance Basics

Instance Basics

This section describes information to help you decide which type of instance you need.

3.3.1.2.1 - Virtual Machine Types

A virtual machine type, known as a VM type, defines the number of CPUs, the size of memory, and the size of storage that is given to an instance when it boots. There are five pre-defined VM types in Eucalyptus. You can change the quantity of resources associated with each of the five VM types, but you cannot change the name of the VM types or the number of VM types available. If you customize the sizes they must be well-ordered. That means that the CPU, memory, and storage sizes of the next VM type must be equal to, or larger than, the size of the preceding VM type. 

The VM type used to instantiate an EMI must have a defined disk size larger than the EMI file. If a 6GB EMI is loaded into an instance with a VM type defined with a 5GB disk, it will fail to boot. The status of the instance will show as pending .  The pending status is the result of the fact that the Walrus cannot finish downloading the image to the Node Controller because the Node Controller has not allotted sufficient disk space for the download. Starting with Eucalyptus 3.2, if the user attempts to launch an instance with a VM type that is too small, they will receive an on-screen warning and the operation will terminate.

Available VM Types

Eucalyptus, like AWS, offers families of VM types. These families are composed of varying combinations of CPU, disk size, and memory. Eucalyptus offers enough VM types to give you the flexibility to choose the appropriate mix of resources for your applications. For the best experience, we recommend that you launch instance types that are appropriate for your applications.

• This family includes the M1 and M3 VM types. These types provide a balance of CPU, memory, and network resources, which makes them a good choice for many applications. The VM types in this family range in size from one virtual CPU with two GB of RAM to eight virtual CPUs with 30 GB of RAM. The balance of resources makes them ideal for running small and mid-size databases, more memory-hungry data processing tasks, caching fleets, and backend servers. M1 types offer smaller instance sizes with moderate CPU performance. M3 types offer larger number of virtual CPUs that provide higher performance. We recommend you use M3 instances if you need general-purpose instances with demanding CPU requirements.

• This family includes the C1 and CC2 instance types, and is geared towards applications that benefit from high compute power. Compute-optimized VM types have a higher ratio of virtual CPUs to memory than other families but share the NCs with non optimized ones. We recommend this type if you are running any CPU-bound scale-out applications. CC2 instances provide high core count (32 virtual CPUs) and support for cluster networking. C1 instances are available in smaller sizes and are ideal for scaled-out applications at massive scale.

• This family includes the CR1 and M2 VM types and is designed for memory-intensive applications. We recommend these VM types for performance-sensitive database, where your application is memory-bound. CR1 VM types provide more memory and faster CPU than do M2 types. CR1 instances also support cluster networking for bandwidth intensive applications. M2 types are available in smaller sizes, and are an excellent option for many memory-bound applications.

• This Micro family contains the T1 VM type. The t1.micro provides a small amount of consistent CPU resources and allows you to increase CPU capacity in short bursts when additional cycles are available. We recommend this type for lower throughput applications like a proxy server or administrative applications, or for low-traffic websites that occasionally require additional compute cycles. We do not recommend this VM type for applications that require sustained CPU performance. The following tables list each VM type Eucalyptus offers. Each type is listed in its associate VM family.