Openstack Cheat Sheet

components of open stack

all components are more or less independent and have rest APIs. Each component potentially interacts with several other components. Die diagram show one virtual use case from a logical point but not from the perspective of real technical interaction

Nova

offers and manages virtual machines, compute nodes, it’s like AWS EC2

Cinder

not replicated block storage for attaching and detaching external hard drives to your operating system. The block storage can be used as normal disk storage (e.g. database), for your operating system files. Its like EBS (Elastic Block Store)

Swift

replicated, scalabale Object Storage. Storing multimedia content like videos, images, virtual machine images, backups, email storage, archives etc. Can be used for storing static large data like backups, archives etc. It can be accessed with its own API, and is replicated cross datacenter. HTTP based APIs. Swift can be compared to AWS S3

Neutron

Networking, provide IP address both private and public

Glance

This is used for maintaining a catalog for images and is kind of a repository for images, like AMI (Amazon Machine Images). Stores and retrieve virtual machine disk images.

Keystone

This component is responsible for managing authentication services for all components. Like credentials and authorization, and authentication for users

Ceilometer

OpenStack Telemetry Service, statistics regarding the usage, billings

Heat

This component manages multiple Cloud applications through an OpenStack-native REST API and a CloudFormation-compatible Query API.

Trove

Database as a Service. Trove is Database as a Service for OpenStack. It’s designed to run entirely on OpenStack, with the goal of allowing users to quickly and easily utilize the features of a relational database without the burden of handling complex administrative tasks. Cloud users and database administrators can provision and manage multiple database instances as needed. Initially, the service will focus on providing resource isolation at high performance while automating complex administrative tasks including deployment, configuration, patching, backups, restores, and monitoring.

Marconi

Messaging as a Service. Marconi is a cloud messaging and notification service for developers building applications on top of OpenStack. The service features a web-friendly HTTP API, which developers can use to send messages between the various components of their SaaS and mobile applications, using a variety of communication patterns. Underlying the API is an efficient messaging engine designed with scalability and security in mind.

Magnum

Magnum is an OpenStack API service developed by the OpenStack Containers Team making container orchestration engines such as Docker Swarm, Kubernetes, and Apache Mesos available as first class resources in OpenStack. Magnum uses Heat to orchestrate an OS image which contains Docker and Kubernetes and runs that image in either virtual machines or bare metal in a cluster configuration.

Horizon

web-based portal to interact with all the underlying OpenStack services, such as NOVA, Neutron, etc.

How it works together with all those modular parts?

Let’s assume we want to create a virtual machine by the Web-UI. So we will login into Horizon. Then we want to create a virtual machine, which means the nova module is called for that. But we do not want to create a blank machine, instead we want to have an OS on it. The images are stored in Glance. Maybe the disk size is not big enough, so we will add a disk by using Cinder. After the machine is created it should get an ip, there the neutron module comes in place. The UI is doing all of them in one dialog, so we do not need do request the modules ourselves. After the machine is created we will deploy a software. This software needs maybe a database or a broker. The modules Trove and Marconi can make your live easier (think about problems like vendor login here). Maybe your application stores data which should be available in another datacenter. Normally you have probably a database which runs shared on boot datacenters, but stuff like videos or archives should not be in a database. Here you can use Swift for scalable and reliable Object storeage by APIs.

Command Line Cheat Sheet

How to Install OpenStack using RDO Packstack

How to Install Redhat Openstack in Triple O method (Openstack on Openstack)

The Red Hat OpenStack Platform director is a toolset for installing and managing a complete OpenStack environment. It is based primarily on the OpenStack project TripleO, which is an abbreviation for “OpenStack-On-OpenStack”. This project takes advantage of OpenStack components to install a fully operational OpenStack environment. This includes new OpenStack components that provision and control bare metal systems to use as OpenStack nodes. This provides a simple method for installing a complete Red Hat OpenStack Platform environment that is both lean and robust.

The Red Hat OpenStack Platform director uses two main concepts: an undercloud and an overcloud. The undercloud installs and configures the overcloud. The next few sections outline the concept of each.

Basic Layout of undercloud and overcloud

1.1. Undercloud
The undercloud is the main director node. It is a single-system OpenStack installation that includes components for provisioning and managing the OpenStack nodes that form your OpenStack environment (the overcloud). The components that form the undercloud provide the multiple functions:

Environment Planning
The undercloud provides planning functions for users to create and assign certain node roles. The undercloud includes a default set of nodes such as Compute, Controller, and various storage roles, but also provides the ability to use custom roles. In addition, you can select which OpenStack Platform services to include on each node role, which provides a method to model new node types or isolate certain components on their own host.
Bare Metal System Control
The undercloud uses out-of-band management interface, usually Intelligent Platform Management Interface (IPMI), of each node for power management control and a PXE-based service to discover hardware attributes and install OpenStack to each node. This provides a method to provision bare metal systems as OpenStack nodes. See Appendix B, Power Management Drivers for a full list of power management drivers.
Orchestration
The undercloud provides a set of YAML templates that acts as a set of plans for your environment. The undercloud imports these plans and follows their instructions to create the resulting OpenStack environment. The plans also include hooks that allow you to incorporate your own customizations as certain points in the environment creation process.
Command Line Tools and a Web UI
The Red Hat OpenStack Platform director performs these undercloud functions through a terminal-based command line interface or a web-based user interface.
Undercloud Components
The undercloud uses OpenStack components as its base tool set. This includes the following components:

OpenStack Identity (keystone) – Provides authentication and authorization for the director’s components.
OpenStack Bare Metal (ironic) and OpenStack Compute (nova) – Manages bare metal nodes.
OpenStack Networking (neutron) and Open vSwitch – Controls networking for bare metal nodes.
OpenStack Image Service (glance) – Stores images that are written to bare metal machines.
OpenStack Orchestration (heat) and Puppet – Provides orchestration of nodes and configuration of nodes after the director writes the overcloud image to disk.
OpenStack Telemetry (ceilometer) – Performs monitoring and data collection. This also includes:

OpenStack Telemetry Metrics (gnocchi) – Provides a time series database for metrics.
OpenStack Telemetry Alarming (aodh) – Provides a an alarming component for monitoring.
OpenStack Workflow Service (mistral) – Provides a set of workflows for certain director-specific actions, such as importing and deploying plans.
OpenStack Messaging Service (zaqar) – Provides a messaging service for the OpenStack Workflow Service.
OpenStack Object Storage (swift) – Provides object storage for various OpenStack Platform components, including:

Image storage for OpenStack Image Service
Introspection data for OpenStack Bare Metal
Deployment plans for OpenStack Workflow Service
1.2. Overcloud
The overcloud is the resulting Red Hat OpenStack Platform environment created using the undercloud. This includes different nodes roles which you define based on the OpenStack Platform environment you aim to create. The undercloud includes a default set of overcloud node roles, which include:

Controller
Nodes that provide administration, networking, and high availability for the OpenStack environment. An ideal OpenStack environment recommends three of these nodes together in a high availability cluster.

A default Controller node contains the following components:

OpenStack Dashboard (horizon)
OpenStack Identity (keystone)
OpenStack Compute (nova) API
OpenStack Networking (neutron)
OpenStack Image Service (glance)
OpenStack Block Storage (cinder)
OpenStack Object Storage (swift)
OpenStack Orchestration (heat)
OpenStack Telemetry (ceilometer)
OpenStack Telemetry Metrics (gnocchi)
OpenStack Telemetry Alarming (aodh)
OpenStack Clustering (sahara)
OpenStack Shared File Systems (manila)
OpenStack Bare Metal (ironic)
MariaDB
Open vSwitch
Pacemaker and Galera for high availability services.
Compute
These nodes provide computing resources for the OpenStack environment. You can add more Compute nodes to scale out your environment over time. A default Compute node contains the following components:

OpenStack Compute (nova)
KVM/QEMU
OpenStack Telemetry (ceilometer) agent
Open vSwitch
Storage
Nodes that provide storage for the OpenStack environment. This includes nodes for:

Ceph Storage nodes – Used to form storage clusters. Each node contains a Ceph Object Storage Daemon (OSD). In addition, the director installs Ceph Monitor onto the Controller nodes in situations where it deploys Ceph Storage nodes.
Block storage (cinder) – Used as external block storage for HA Controller nodes. This node contains the following components:

OpenStack Block Storage (cinder) volume
OpenStack Telemetry (ceilometer) agent
Open vSwitch.
Object storage (swift) – These nodes provide a external storage layer for OpenStack Swift. The Controller nodes access these nodes through the Swift proxy. This node contains the following components:

OpenStack Object Storage (swift) storage
OpenStack Telemetry (ceilometer) agent
Open vSwitch.
1.3. High Availability
The Red Hat OpenStack Platform director uses a Controller node cluster to provide high availability services to your OpenStack Platform environment. The director installs a duplicate set of components on each Controller node and manages them together as a single service. This type of cluster configuration provides a fallback in the event of operational failures on a single Controller node; this provides OpenStack users with a certain degree of continuous operation.

The OpenStack Platform director uses some key pieces of software to manage components on the Controller node:

Pacemaker – Pacemaker is a cluster resource manager. Pacemaker manages and monitors the availability of OpenStack components across all nodes in the cluster.
HAProxy – Provides load balancing and proxy services to the cluster.
Galera – Replicates the Red Hat OpenStack Platform database across the cluster.
Memcached – Provides database caching.
NOTE
Red Hat OpenStack Platform director automatically configures the bulk of high availability on Controller nodes. However, the nodes require some manual configuration to enable fencing and power management controls. This guide includes these instructions.

1.4. Ceph Storage
It is common for large organizations using OpenStack to serve thousands of clients or more. Each OpenStack client is likely to have their own unique needs when consuming block storage resources. Deploying glance (images), cinder (volumes) and/or nova (Compute) on a single node can become impossible to manage in large deployments with thousands of clients. Scaling OpenStack externally resolves this challenge.

However, there is also a practical requirement to virtualize the storage layer with a solution like Red Hat Ceph Storage so that you can scale the Red Hat OpenStack Platform storage layer from tens of terabytes to petabytes (or even exabytes) of storage. Red Hat Ceph Storage provides this storage virtualization layer with high availability and high performance while running on commodity hardware. While virtualization might seem like it comes with a performance penalty, Ceph stripes block device images as objects across the cluster; this means large Ceph Block Device images have better performance than a standalone disk. Ceph Block devices also support caching, copy-on-write cloning, and copy-on-read cloning for enhanced performance.

See Red Hat Ceph Storage for additional information about Red Hat Ceph Storage.