OpenStack Architecture: A Practical Guide for Global Teams

If you are looking up “openstack architecture,” this guide gives you the full picture in one place: the layers, core services, node roles, real-world flows, high availability and security, plus when OpenStack private cloud actually makes sense. I will walk you through it step by step so that by the end, you can confidently evaluate or design an OpenStack architecture for your own environment.

If you are evaluating OpenStack, you are not just asking, “What is it?” You are really asking, “How does its architecture actually work, and could it be the foundation of our private or hybrid cloud?”

OpenStack is a modular cloud operating system that controls compute, storage, and networking resources in your data center. Architected well, it becomes the backbone of a private or hybrid cloud that can rival hyperscalers in flexibility while giving you more control over costs, data residency, and compliance.

OpenStack is also increasingly relevant in regions like Southeast Asia, where Singapore has become a preferred hub for regional cloud infrastructure and government led digital transformation. If you have followed how initiatives such as Singapore’s government digital transformation and wider ASEAN digital transformation efforts are reshaping the region, you have already seen why robust, sovereign cloud architectures matter.

In this guide, we will walk through OpenStack architecture from the ground up: layers, services, node roles, real world flows, high availability (HA), microservices, and security, and then talk about when OpenStack private cloud makes sense and how to approach it in practice.

OpenStack Architecture in 5 Minutes: The TL;DR

At a high level, an OpenStack deployment looks like this:

• Data center and hardware layer: servers, racks, power, cooling, connectivity, and upstream network
  
• Virtualization layer: typically KVM (or another hypervisor) running on your physical hosts
  
• OpenStack control plane: a collection of services (APIs, schedulers, databases, message queues) that decide what should happen in the cloud
  
• Data plane: where your workloads actually run, virtual machines and sometimes containers or bare metal
  
• User interfaces: REST APIs, CLI tools, and the Horizon web dashboard through which users and automation interact with your cloud
  

If you are still building your foundational understanding of cloud, pairing this guide with a refresher on the fundamentals of cloud computing can be very helpful.

Think of OpenStack as the brain and nervous system of your private cloud. It does not replace your data center; it orchestrates it.

A Layered View of OpenStack Architecture

Rather than starting with a long list of service names, it is more useful to visualise OpenStack architecture in layers.

Physical and Data Center Layer

At the bottom, you have traditional data center concerns:

• Racks, servers, storage arrays
  
• Power, cooling, and physical security
  
• Network connectivity, cross connects, and upstream carriers
  

For organisations hosting in or near Singapore, decisions such as whether to use Tier 2, 3, or 4 facilities matter a lot for resilience and SLAs. If you are evaluating locations, resources on Tier 2 data centers in Southeast Asia and when US companies should choose Singapore or the differences between Tier 3 and Tier 4 data centers provide useful context.

Many organisations do not want to manage all of this themselves. That is where infrastructure outsourcing models, including infrastructure IT outsource services in Singapore, come into play.

Virtualization Layer

On each physical server, you typically run a hypervisor such as KVM (commonly used with OpenStack). This layer:

• Offers compute resources (vCPUs, RAM) to virtual machines
  
• Exposes virtualisation primitives that OpenStack’s compute service (Nova) will orchestrate
  

OpenStack Control Plane

The control plane is where most of the OpenStack “magic” happens:

• API services for each component (Nova, Neutron, Cinder, and others)
  
• Scheduler services that decide where workloads should run
  
• Keystone for identity and authentication
  
• Databases (for example MariaDB or Galera) holding the state of the cloud
  
• Message queues (for example RabbitMQ) over which services communicate
  

This layer is usually hosted on dedicated controller nodes.

Data Plane and User Entry Points

Finally, you have:

• Compute nodes where your VMs run
  
• Network nodes handling routing, NAT, and load balancing
  
• Storage nodes providing block and or object storage
  
• User interfaces: Horizon dashboard, CLI, SDKs, and automation tools calling OpenStack APIs
  

Once you see the architecture in layers, the individual services will make a lot more sense.

Core OpenStack Services and How They Fit Together

OpenStack is composed of many services, but for architecture discussions we usually focus on a core group.

Identity and Security – Keystone

Keystone is the identity service. Every other service trusts Keystone to:

• Authenticate users and services
  
• Issue tokens
  
• Enforce basic project and tenant access rules
  

Architecturally, Keystone is central because every API call from users or services is authenticated through it.

Compute – Nova

Nova is the compute service. It orchestrates VMs across your hypervisors and typically includes:

• nova api, which receives user and API requests
  
• nova scheduler, which decides which compute node should host a VM
  
• nova compute, which runs on each compute node to interact with the hypervisor
  

Nova integrates with Neutron (networking), Cinder (block storage), and Glance (images) to create full virtual machine instances.

Networking – Neutron

Neutron is responsible for virtual networking:

• Creating tenant networks, routers, and subnets
  
• Connecting instances to networks
  
• Integrating with SDN plugins or physical network gear
  

In most architectures, Neutron components run on dedicated network nodes and on the compute nodes as agents.

Storage – Cinder, Swift, Manila

• Cinder provides block storage, similar to virtual disks attached to VMs
  
• Swift provides object storage, with an S3 like API
  
• Manila provides shared file storage, such as NFS as a service
  

These services can use underlying storage backends ranging from local disks to enterprise SAN or distributed storage systems.

Images, UI and Orchestration

• Glance is the image service; it stores and serves VM images
  
• Horizon is the web UI and dashboard for admins and users
  
• Heat is the orchestration service using templates, similar to infrastructure as code
  

When people talk about building an OpenStack private cloud, these are the building blocks they are assembling. For a higher level discussion of OpenStack as an IaaS platform, you may find it useful to compare this with the advantages of Infrastructure as a Service or an overview of IaaS vendors.

Node Roles and Reference Deployment Topologies

It is common to group services into node roles so the architecture is easier to design and scale.

Controller Nodes

Controller nodes typically run:

• API services for Nova, Neutron, Cinder, and other components
  
• Keystone
  
• Horizon
  
• Message queue such as RabbitMQ
  
• Databases such as MariaDB or Galera
  
• Scheduler services
  

In production, you will almost always run multiple controllers for high availability.

Network Nodes

Network nodes usually host:

• L3 agents for routing
  
• DHCP agents
  
• Load balancing or VPN services if enabled
  

In some architectures, these functions are split across multiple nodes for resilience and throughput.

Compute Nodes

Compute nodes host:

• The hypervisor (for example KVM)
  
• nova compute service
  
• Neutron agents such as OVS or Linux bridge
  

This is where your tenants’ VMs actually live.

Storage Nodes

Where you place storage depends on your backend, but many deployments use dedicated nodes for:

• Cinder backends for block storage
  
• Swift clusters for object storage
  

Example Topologies: Lab vs Production vs Telco

• Lab and proof of concept: single all in one node or a very small cluster, often with reduced HA, for testing
  
• Mid size production: three or more controller nodes, at least two network nodes, multiple compute nodes, external storage
  
• Telco or large enterprise: multiple regions, availability zones, and sometimes cells for Nova to scale to tens of thousands of instances
  

In regulated sectors like banking, these topologies need to incorporate strict controls and resilience patterns similar to those used in cloud banking solutions across Singapore and Southeast Asia, often combined with the best practices from an infrastructure security multicloud playbook.

How OpenStack Architecture Works in Practice: Three Key Flows

Knowing the components is useful; understanding how they interact during real operations is where architecture really clicks.

What Happens When You Launch a VM

At a simplified level:

1. A user or automation sends a request via Horizon or the Nova API.
   
2. Keystone authenticates the request and issues a token.
   
3. Nova API validates the request and consults the scheduler.
   
4. Nova Scheduler selects a compute node based on filters such as capacity and aggregates.
   
5. Nova on the compute node talks to:
   
   • Neutron to plug the VM into the appropriate virtual network
     
   • Cinder to attach volumes if requested
     
   • Glance to fetch the VM image
     
6. The hypervisor boots the instance and Nova updates its state in the database.
   

This interaction pattern, API to Keystone to scheduler to other services to compute, is a classic control plane flow.

What Happens When You Create a Tenant Network

1. The user calls the Neutron API, directly or via Horizon.
   
2. Keystone authenticates the request.
   
3. Neutron’s server process writes network definitions to its database.
   
4. Network agents on compute and network nodes receive instructions via the message queue.
   
5. Those agents configure virtual switches, routers, and DHCP as required.
   

What Happens When You Store an Image or Volume

For images:

1. The user uploads an image via Glance.
   
2. Glance stores the image in its backend, which might be Swift, a file store, or another option.
   
3. Nova retrieves the image during VM boot.
   

For volumes:

1. The user creates a volume via Cinder.
   
2. Cinder provisions the volume on the chosen backend.
   
3. When attached to a VM, Cinder coordinates with Nova to map the volume to the instance.
   

These flows connect directly to real workloads. If you are designing applications that depend on these patterns, it is worth cross referencing with examples of cloud computing business applications and real time cloud computing use cases.

High Availability, Scaling and Failure Domains in OpenStack Architecture

OpenStack can be deployed simply, but serious environments care deeply about HA and failure domains.

Multi controller and Database or Message Queue HA

For the control plane, HA typically involves:

• Three or more controller nodes
  
• Databases such as MariaDB or Galera in a cluster
  
• Message queue such as RabbitMQ in a mirrored or clustered configuration
  
• Load balancers in front of APIs
  

Architecturally, this means you design for no single point of failure in the control plane.

Scaling Compute and Nova Cells

As environments grow, you may:

• Add more compute nodes and group them into availability zones or host aggregates
  
• Use Nova Cells v2 to scale the compute layer horizontally, reducing the impact of failures and improving performance at scale
  

Designing for Failure Domains

Good architecture design treats these as separate failure domains:

• Rack level failures
  
• Cluster or zone level failures
  
• Region level failures
  

Backup, DR and Multi site

For many businesses, HA is not enough. They require disaster recovery and cross site resilience, which is where good OpenStack architectures intersect with robust backup and DR strategies similar to those used by cloud computing service providers in Singapore for backup and disaster recovery, or services like IT DR as a service and managed backup.

OpenStack as a Microservice Architecture (and Why It Matters)

Architecturally, OpenStack is often described as a microservice style system:

• Each service exposes its own API and has its own database tables
  
• Services communicate via message queues, not direct function calls
  
• Many components are stateless, making them easy to scale horizontally behind load balancers
  

This design has consequences:

• You can scale API services independently, for example adding more Nova API nodes, without changing Neutron or Keystone
  
• You need strong operational practices around message queues and databases, because they underpin everything
  
• Containerising OpenStack, for example using Kolla, makes it easier to roll out updates and run blue or green or canary deployments
  

If you are already working with infrastructure as code, it is worth understanding the difference between the deployment model and the service model, as explored in discussions on Infrastructure as Code vs Infrastructure as a Service and in guides on building cloud infrastructure without wrecking your budget or security.

Security, Compliance and Governance in OpenStack Architectures

OpenStack’s architecture gives you several security and governance levers.

Identity, Policy and Network Isolation

• Keystone manages identities, roles, and projects or tenants
  
• Role based access control determines what users can do
  
• Neutron provides logical isolation via tenant networks, security groups, and in some cases micro segmentation with SDN plugins
  

Compliance in Regulated Industries

In regulated sectors such as banking or government, architecture decisions must align with:

• Data residency requirements
  
• Encryption in transit and at rest
  
• Audit logging and long term retention
  

These considerations mirror the design constraints seen in cloud security consulting engagements across Southeast Asia, Singapore government cloud environments, and broader digital transformation in banking.

Observability and Audit Trails

Modern OpenStack architectures also integrate:

• Centralised logging, for example ELK or EFK
  
• Metrics and tracing for services
  
• API audit logs for compliance and security investigations
  

All of these components should be considered first class parts of your architecture, not afterthoughts.

When OpenStack Private Cloud Makes Sense (and When It Does Not)

OpenStack private cloud is not a universal answer, but it is the right answer in some very specific scenarios.

When It Is a Strong Fit

• You need fine grained control over performance, topology, and network design
  
• There are strict data residency or compliance requirements, especially common for organisations serving Southeast Asia from Singapore
  
• Cloud costs at hyperscalers are becoming unwieldy for predictable baseline workloads, and you want to shift part of that to a more predictable capex plus controlled opex model
  
• You want a long lived, highly customised environment that public cloud might not handle elegantly
  

These are the same drivers pushing businesses toward private cloud hosting services and hybrid models.

When It Is Not the Best First Step

• You have a small team with no appetite for deep infrastructure operations
  
• You primarily need managed SaaS or PaaS, not infrastructure level control
  
• Your workloads are highly bursty and unpredictable, with little baseline utilisation
  

In such cases, a hybrid approach is more sensible. You can leverage hyperscalers where they shine and use OpenStack private cloud for predictable or sensitive workloads. Many global teams look to hybrid cloud providers in Singapore to design that balance.

From VMware to OpenStack: Architectural Considerations for Migration

For many global enterprises, “OpenStack architecture” is tightly connected to “Can we get out of VMware lock in?”

Architecturally, you should pay attention to:

• How VMware concepts such as clusters, datastores, and port groups map to OpenStack constructs such as availability zones, Cinder backends, and Neutron networks
  
• Whether you need to maintain co existence for a time, hybrid vSphere plus OpenStack, or execute a hard cutover
  
• Network models, storage performance expectations, and identity integration, for example with Active Directory
  

If you are actively evaluating options, it is worth comparing notes with guides on VMware alternatives, practical migration advice such as escaping VMware lock in using Accrets OpenStack migration services, and broader strategy playbooks like VMware digital transformation for global IT leaders.

How Accrets Helps You Design and Operate OpenStack Architectures

Designing a robust OpenStack architecture is not just about reading service names off a diagram. It is about making the right trade offs for your business, your region, and your risk profile.

As a Singapore based managed cloud and infrastructure provider, Accrets works with global teams to:

• Design right sized OpenStack architectures, from compact private clouds to multi site, multi region deployments
  
• Implement high availability, backup, and disaster recovery patterns aligned to your SLAs
  
• Integrate OpenStack into broader ecosystems, including enterprise connectivity, security, and managed services
  
• Operate the environment as a managed service, so your internal teams can focus on applications and business value
  

If you would like to review your current plans or validate an OpenStack architecture for your organisation, you can fill out the form to get a free consultation with an Accrets cloud expert on OpenStack architecture via theAccrets contact page.

For teams that prefer a service led approach, it can also be useful to look at Accrets’ broader portfolio as amanaged cloud service provider, including offerings such ason premise private cloud,cloud infrastructure as a service, andenterprise cloud computing solutions.

Dandy Pradana

Dandy Pradana is an Digital Marketer and tech enthusiast focused on driving digital growth through smart infrastructure and automation. Aligned with Accrets’ mission, he bridges marketing strategy and cloud technology to help businesses scale securely and efficiently.