Prasanta Kumar Behera
OpenStack Private Cloud›01 · OpenStack architecture
Learning Hub / Cloud — OpenStack, AWS & EKS / OpenStack Private Cloud

Lesson 01 of 9 · Modules

OpenStack architecture

See OpenStack as a system: the core services and what each owns, how control-plane and compute nodes divide the work, the message queue and database underneath, and the full path of an 'openstack server create' request.

Practitioner
Key wordsOpenStackcontrol planecompute nodesRabbitMQMariaDB/GaleraAPI servicesservice catalogrequest flow
Users & automation Horizon · openstack CLI · Terraform Keystone tokens + service catalog API services (controllers, behind HAProxy VIP) Nova compute Neutron networking Glance images Cinder volumes Placement capacity Heat orchestration Shared infrastructure RabbitMQ RPC between services MariaDB / Galera state of every service Compute nodes (many) nova-compute libvirt / KVM OVS / OVN agent tenant networks instances VMs Ceph images · volumes · vms (RBD pools)
Keystone in front, API services on controllers, RabbitMQ and MariaDB underneath, compute nodes and Ceph doing the work.

OpenStack in one sentence

OpenStack is a set of cooperating services that turn racks of servers, disks and switches into a self-service cloud, with APIs for compute, networking, storage and identity much like a public cloud's, but on hardware you own.

OpenStack is like a big hotel. Keystone is the front desk that checks guests in and gives them key cards. Nova finds a free room (a compute host) and makes it ready. Neutron wires up the room's phone line and Wi-Fi (networking). Glance is the catalogue of room layouts (images). Cinder provides extra wardrobes you can move between rooms (volumes). Behind the scenes, staff pass notes to each other through a pneumatic tube system (RabbitMQ) and keep the records in the hotel ledger (the database).

The core services

Service Project Owns
Identity Keystone Users, projects, roles, tokens, service catalog
Compute Nova (+ Placement) Instances, scheduling, flavors, hypervisors
Networking Neutron Networks, subnets, routers, ports, floating IPs, security groups
Images Glance VM images
Block storage Cinder Volumes, snapshots, backups
Orchestration Heat Stacks from templates
Load balancing Octavia Load balancers (amphora VMs or OVN-based)
Dashboard Horizon Web UI
Object storage Swift (or Ceph RGW) Objects over HTTP

Nodes and shared infrastructure

Node role Runs
Controllers (usually 3) API services, schedulers, conductors, Neutron server; MariaDB/Galera, RabbitMQ, memcached; HAProxy + keepalived VIP in front of the APIs
Compute nodes nova-compute, libvirt/KVM, the Neutron agent or OVN controller
Network nodes (OVS-based designs) L3 routers, DHCP, metadata agents (OVN distributes most of this)
Storage nodes Ceph OSDs, or Cinder volume backends

Each service is split into an API (HTTP, via the VIP) and workers that talk to each other over RabbitMQ and store state in MariaDB.

Follow one request: openstack server create

1. CLI → Keystone: authenticate, get a token + service catalog
2. CLI → Nova API: "create vm1: flavor m1.small, image ubuntu-24.04, network private"
3. Nova API: validate, record the instance (BUILD) in the DB, cast to nova-conductor via RabbitMQ
4. nova-scheduler + Placement: pick a compute host with enough resources, claim them
5. nova-conductor → nova-compute on that host (RabbitMQ)
6. nova-compute → Glance: fetch the image (or clone it, with Ceph)
   nova-compute → Neutron: create/bind a port; the Neutron agent/OVN wires the tap device
   (optional) → Cinder: attach volumes
7. nova-compute → libvirt: define and start the domain; cloud-init reads metadata
8. Instance ACTIVE; status reported back through RabbitMQ to the DB

When it fails, openstack server show vm1 -c fault usually names the step: No valid host was found (scheduler/placement), port binding failures (Neutron), image errors (Glance).

Try it: an all-in-one lab

Use a VM with 8+ GB RAM (and nested virtualisation enabled). DevStack (for learning) or Kolla-Ansible all-in-one (lesson 07) both work.

  1. Install, then load credentials and run openstack token issue and openstack catalog list.
  2. openstack compute service list and openstack network agent list: what runs where?
  3. Upload a small cloud image (e.g. CirrOS), create a keypair, a network and a flavor if needed, and boot an instance.
  4. Watch the instance go from BUILD to ACTIVE, and find the request ID (req-…) in the Nova API logs, then follow it into the conductor and compute logs.

Going deeper: architecture decisions

  • Three controllers for HA: Galera and RabbitMQ need quorum, and APIs sit behind a keepalived VIP.
  • RabbitMQ and MariaDB are the usual scaling and stability hotspots. Size and monitor them first (lesson 08).
  • Large clouds use Nova cells v2 to shard compute hosts, databases and queues.
  • Choose OVN or OVS with agents for Neutron early (lesson 04); migrating later is significant work.

Recap

  • Core services: Keystone, Nova (+Placement), Neutron, Glance, Cinder, plus Heat, Octavia, Horizon, Swift.
  • Controllers (APIs, schedulers, DB, queue, VIP) vs compute nodes (nova-compute + KVM + networking agent).
  • Components talk over RabbitMQ and keep state in MariaDB/Galera.
  • A server create flows Keystone → Nova → Placement/scheduler → compute → Glance/Neutron/Cinder → libvirt.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.