OpenStack Architecture and Services

Openstack is consisted of several core projects, Nova for Compute, Glance for Images, Cinder for Block Storage, Keystone for Identity, Neutron for Networking, and additional optional services. Each project exposes all it’s capabilities over RESTful API. The services inner-communicate over RESTful API calls, so when a service requires resources from another services, it makes a RESTfull API call to query services’ capabilities, list its resources or call for a certain action.

Every Openstack Project consists of several components, each component fulfills a certain functionality or performs a certain task. The components for each project, are standard POSIX Linux services which use a message brocker server for inner service communication,RabbitMQ in most cases. The services also save persistent data and objects’ states to a database.

To better understand this let’s take a look at a common communication flow in Openstack – Instance Launch flow, and map which Nova components are used to launch an new instance.


  1. Nova-API service receives an API call via RESTful API, and validates it against Keystone identity service. Nova-API saves the new request to the database and pushes a message to the message for Nova-Scheduler.
  2. Nova-Scheduler picks up the request from the message queue, selects the host on which the instance should run, updates the database, and sends the selection over the message queue.
  3. Nova-Conductor queries the database for additional needed information to launch the instance, and send a command over the message queue to the appropriate nova-compute node to launch an instance .
  4. Nova-Compute picks up the launch request, sends a REST api call to Glance to fetch an image to launch and interacts with it’s back-end driver, usually libvirtd/KVM, to launch the instance.

In this flow we mentioned 4 components that are used within Nova to launch instances. All openstack services share this  modular design so each service is constructed of several components, which are posix Linux services. Most services have one service that is responsible to receive API calls and other services are responsible for performing actions,for example launching a virtual machine or creating a volumes, weighing filters and scheduling, or other tasks that are part of Project’s functionality.

This design  makes Openstack highly modular,  components of each project can be installed on  separate hosts while inner-communicating over the message broker. There’s no single permutation that fits all use cases Openstack is used for, but there are few commonly used  layouts, some are easier for management, some focus on scaling compute resources, other layouts focus on scaling object storage, each with it’s own benefits and drawbacks.

Core OpenStack Services 


Nova Compute Service implements the Compute service which is the main part of an IaaS system. it is responsible for launching and managing instance of virtual machines. The Compute service scales horizontally on standard hardware.

Nova Components


  • nova-api service: accepts and responds to end user compute API calls. Supports OpenStack Compute API, Amazon EC2 API, and a special Admin API for privileged users to perform administrative actions. Also, initiates most orchestration activities, such as running an instance, and enforces some policies.
  • nova-api-metadata service: accepts metadata requests from instances. The nova-api-metadata service is generally only used when you run in multi-host mode with nova-network installations.

Compute Core

  • nova-compute service: A worker daemon which scales horizontally, creates and terminates virtual machine instances through hypervisor APIs such as libvirt for KVM/QEMU, Xen, VMWareAPI, etc’.  The process accepts actions from the queue and perform a series of system commands, like launching a an instance, while updating state in the database .
  • nova-scheduler service: Conceptually the simplest piece of code in Compute. Takes a virtual machine instance request from the queue and determines on which compute server host it should run.
  • nova-conductor Service: mediates interactions between nova-compute and the database. Aims to eliminate direct accesses to the cloud database made by nova-compute.

Nova Netowrk

  • nova-network Service: Similar to nova-compute, it accepts networking tasks from the queue and performs tasks to manipulate the network, such as setting up bridging interfaces or changing iptables rules.
  • nova-dhcpbridge script: Tracks IP address leases and records them in the database by using the dnsmasq dhcp-script facility.

Console Interface

  • nova-consoleauth Service: authorizess tokens for users that console proxies provide.
  • nova-novncproxy Service: provides a proxy for accessing running instances through a VNC connection. Supports browser-based novnc clients.
  • nova-xvpnvncproxy Service: a proxy for accessing running instances through a VNC connection. Supports a Java client specifically designed for OpenStack.
  • nova-cert Service:  Manages x509 certificates.


Glance Image Service enables users to discover, register, and retrieve virtual machine images. The Image Service offers a REST API that enables you to query virtual machine image metadata and retrieve an actual image. You can store virtual machine images made available through the Image Service in a variety of locations from simple file systems to object-storage systems like OpenStack Object Storage.

Glance Components

  • glance-api Service: accepts Image API calls for image discovery, retrieval, and storage.
  • glance-registry Service: stores, processes, and retrieves metadata about images. Metadata includes items such as size and type. The Image Service supports a variety of repositories including normal file systems, Object Storage, Cehp RADOS block devices, HTTP, and Amazon S3. Some types of repositories support only read-only usage.


Keystone Identity Service is an OpenStack project that provides Identity for openstack services to authenticate against, Tokens which , Catalog and Policy services for use specifically by projects in the OpenStack family.

Keystone Component

  • keystone service implements both the API and the middleware communicating with backend identity service, which could be the native MariaDB server, supportive LDAP server or Microsoft Active Directory. Keystone service exposes Endpoints for all services. Endpoints are URL addresses thru which the services are accessible.


Neutron Networking Service takes care of the creation and management of virtual networks, including creation of layer 2 networks, layer 3 subnets, routers, services such as Firewalls, VPNs and DNS.

  • neutron-server service exposes the networking  API, and it is the main networking management  services controlling then underlying networking mechanisem
  • neutron-l3-agent services handles L3/NAT forwarding
  • neutron-openvswitch-agent service is responsible for local machine networking configuration
  • neutron-dhcp-agent service provides DHCP service to tenant networks




Horizon Dashboard service is the graphical web user interface for users and administrator to manage Openstack, and for users to consume Openstack services.

  • httpd is the Appache HTTP service that hosts and serves the web dashboard application
  • openstack-dashbaord is the package that provides the dashboard web application

Cinder Block Storage Service provides persistent block storage services, in form of virtual hard disk drives, for the instances. Cinder allows users to create, delete and attached virtual disks to instances, on which the the instance keep persistent data which is performance sensitive.

  • cinder-volume service interacts with storage devices via back-end drivers and serves them to instances managed by Nova service.
  • cinder-api handles requests and responds, and places them in message queue.
  • cinder-scheduler service gathers volume requests and determines which volume server should provision the requests volume.
  • cinder-backup service provides ability to backup volumes to external storage.


Heat Orchestration Service provides the ability to orchestrate Openstack requests, such as creation of instances, volumes and other Openstack services, using  templates based language call HOT(Heat Orchestration Template).

  • heat-api service serves HTTP RESTful API that process requests and responses.
  • heat-api-cfn is a CloudFormation compatible API service to heat.
  • heat-api-cloudwatch monitors metrics for the orchestration service.
  • heat-engine service  process templates and orchestrates their launch.


Ceilometer Telemetry Service collects  usage metrics by poling Openstack components which can be used for system monitoring, producing alerts, customer billing.

  • ceilometer-API recieves API calls
  • ceilometer-central Central ceilometer agent
  • ceilometer-collector the collector agent
  • ceilometer-compute compute agent
  • ceilometer-alarm-evaluator evaluates states and triggers alarms
  • ceilometer-alarm-notifier executes alarms actions

OpenStack is extremely fast moving project when new component  join every cycle.

Share If You Care

3 Comments on OpenStack Architecture and Services

  1. Hi thanks for your job!
    I want to translate your article to spanish, and I’m asking if you don’t have any problem Iwill quote you in my translation.
    Thanks again.


  2. It’s amazing to go to see this website and reading the views of all colleagues regarding this article, while I am also zealous of getting knowledge.

  3. Minute correction – Nova Netowrk – need to correct the spelling here – under Core OpenStack Services >> Nova Components. Rest the article is super cool!

4 Trackbacks & Pingbacks

  1. OpenStack Orchestration: Getting Started with HEAT | Berezin's Virtual Clouds
  2. Ceilometer Architecture - GREENSTACK
  3. Building Custom Dashboards in OpenStack Horizon - GREENSTACK
  4. Best Practices and Considerations Deploying OpenStack In Production - GREENSTACK

What do you think about this?