A recap of OpenStack services; what is what again?
Why combine the components?
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, ranging 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.
Below you can find an image with an overview of an OpenStack landscape. You can see where the services fit and how they can work together. Of course the overview is just an example of such infrastructure.
Let’s do a quick recap of the most important services that are connected to OpenStack. We have listed a summary below for you to go through what is what again.
Nova
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
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. An example of a 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):
…
NEW
Want to find out if your OpenStack infrastructure can run smoother? Claim your health check
- Improve system performance
- Improve reliability
- Prepare for scale
- Collaborate with a Fairbanks OpenStack expert
Glance
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: Scales to very serious workloads
– Fault tolerant: Isolated processes avoid cascading failures
– Recoverable: Failures should be easy to diagnose, debug, and rectify
– Open standards: A reference implementation for a community-driven api
Neutron
OpenStack Neutron is an SDN networking project focused on delivering networking-as-a-service (NaaS) in virtual compute environments. It enables covering, 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
Ironic provisions bare metal machines (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.
Swift
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 solutions 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
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
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 template creates 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 creates k8s-cluster
– cluster-template k8s-cluster-template
– master-count 3
– node-count 8
Masakari
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.
Horizon
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 use within OpenStack? Let us know.
Get a health check of your Kubernetes or Openstack infrastructure
Curious about whether your current Kubernetes or Openstack infrastructure is performing up to the market standard? Or are you looking for ways to improve your current situation? Request a free scan of your Openstack or Kubernetes infrastructure and receive interesting insights free of commitment.
