Recap of OpenStack services

Recap of OpenStack services

A recap of OpenStack services; what is what again?

The various OpenStack community projects and the services they implement are modular in nature and generally capable of being used independently. They are intended to knit together into a net capability greater than the sum of the individual parts.

A major advantage of the modular setup of OpenStack is that this allows you to only use the components you need. Because of this we see many different setups from feature heavy setups with bare metal, virtual machine, container, and off-premises deployments to smaller Edge Cloud setups with only the bare minimum setup of features. Let’s have a quick recap of the most important services that are connected to OpenStack. So here we have listed a summary for you to go through what is what again.

In the title you can find an overview of an OpenStack landscape. You can see where the services fit and how they can work together. Off course the overview is just an example of such infrastructure.

Nova is used to implement services and associated libraries in order to provide, on demand, self-service access to compute resources, such as bare metal, virtual machines, and containers. In other words, it supports creating virtual machines, bare metal servers (using ironic) and includes support for system containers. Nova runs as a set of daemons on top of existing Linux servers. Nova requires the following OpenStack services: Keystone, Glance, Neutron and Placement. These services are also described below.

Keystone is an OpenStack service that provides API client authentication, service discovery, and distributed multi-tenant authorization by implementing OpenStack’s Identity API. It supports LDAP, OAuth, OpenID Connect, SAML and SQL.

Keystone defines functions related to Flask-RESTful in keystone.server.flask.common. Keystone creates API resources which inherit from class keystone.server.flask.common.ResourceBase and exposes methods for each supported HTTP methods GET, PUT , POST, PATCH and DELETE. For example, the User resource will look like:

class userresource(ks_flask.resourcebase:
collection_key = ‘users’
member_key = ‘users’
get_member_from_driver = providers.deferred_provider_lookup(api=’identity_api’, method=’get_user’)
def get(self, user_id=none):
“””get a user resource of list user.
get/head /v3/users
get/head/v3/users/{user_id}
“””

def post(self):
“””create a user.
post /v3/users
“””

class userchangepasswordresource(ks_flask.resourcebase):
@ks_flask.unenforce_api
def post(self, user_id):

Glance has a RESTful API that allows querying of VM image metadata as well as retrieval of the actual image. Glance, as with all OpenStack projects, is written with the following design guidelines in mind:
– Component based architecture: Quickly add new behaviors
– Highly available: Scale to very serious workloads
– Fault tolerant: Isolated processes avoid cascading failures
– Recoverable: Failures should be easy to diagnose, debug, and rectify
– Open standards: Be a reference implementation for a community-driven api

OpenStack Neutron is a SDN networking project focused on delivering networking-as-a-service (NaaS) in virtual compute environments. It enables scovering, registering, and retrieving virtual machine (VM) images. Thus, Neutron is an OpenStack project to provide ‘network connectivity as a service’ between interface devices managed by other OpenStack services.

An example architecture requires at least two nodes (hosts) to launch a basic virtual machine (VM) or instance. Optional services such as Block Storage and Object Storage require additional nodes. This example architecture differs from a minimal production architecture as follows:
– Networking agents reside on the controller node instead of one or more dedicated network nodes.
– Overlay (tunnel) traffic for self-service networks traverses the management network instead of a dedicated network.

Ironic provisions bare metal (as opposed to virtual) machines. It may be used independently or as part of an OpenStack Cloud, and integrates with the OpenStack Identity (keystone), Compute (nova), Network (neutron), Image (glance), and Object (swift) services. In Ubuntu setups you can also use MAAS for bare metal provisioning.

OpenStack Object Storage Swift is used for redundant, scalable data storage using clusters of standardized servers to store petabytes of accessible data. It is a long-term storage system for large amounts of static data which can be retrieved and updated. We see that storage solutions like Cinder and Ceph are also very popular solution used in OpenStack. I wrote two introductions on Ceph earlier on LinkedIn, these articles can be found here: https://www.linkedin.com/pulse/object-block-file-system-storage-single-cluster-michiel-manten/ and https://www.linkedin.com/pulse/follow-up-ceph-michiel-manten/

Heat orchestrates the infrastructure resources for a cloud application based on templates in the form of text files that can be treated like code. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API. Heat also provides an autoscaling service that integrates with the OpenStack Telemetry services, so you can include a scaling group as a resource in a template.

Magnum makes 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 within a cluster configuration.
When Magnum deploys a Kubernetes cluster, it uses parameters defined in the ClusterTemplate and specified on the cluster-create command, for example:

OpenStack coe cluster templae create k8s-cluster-template
– image fedora-coreos-latest
– keypair testkey
– external-network public
– dns-nameserver 8.8.8.8
– flavor m1.small
– docker-volume-size 5
– network-driver flannel
– coe Kubernetes

openstack coe cluster create k8s-cluster
– cluster-template k8s-cluster-template
– master-count 3
– node-count 8

Masakari provides Instances High Availability Service for OpenStack clouds by automatically recovering failed Instances. Currently, Masakari can recover KVM-based Virtual Machine (VM)s from failure events such as VM process down, provisioning process down, and nova-compute host failure. Masakari also provides an API service to manage and control the automated rescue mechanism.
And last but certainly not least: Horizon. This is the implementation of OpenStack’s dashboard, which is extensible and provides a web-based user interface to the OpenStack services.

These are some important OpenStack services. We hope this quick recap helps you! Have we missed an important service that you are using within OpenStack? Let us know in the comments.