Charmed OpenStack Explained: Architecture & Backup

Charmed OpenStack is Canonical’s model-driven way of standing up an OpenStack cloud — MAAS for the metal, Juju for the orchestration, and charms for everything in between. It removes a great deal of the manual labor. It does not remove your responsibility for the data that ends up running on top of it.

OpenStack has a deserved reputation. It is one of the most capable open-source platforms for running a private cloud, and one of the most components-heavy projects in existence — several dozen services that all have to agree with each other before a single instance boots. Canonical’s answer to that complexity is Charmed OpenStack: don’t configure the cloud by hand, model it.

This article covers what Charmed OpenStack actually is, the three tools that make it work, where it differs from Canonical’s newer Sunbeam approach, and — because someone eventually has to ask the uncomfortable question — how you back the whole thing up without putting agents inside your instances or reaching into the hypervisor.

What Charmed OpenStack actually is

Charmed OpenStack is an implementation of OpenStack built on Canonical’s tooling: MAAS, Juju, and charms. Instead of installing Keystone, Nova, Neutron, Glance and the rest one package at a time, you describe the cloud as a set of services and the relations between them. Juju then deploys those services, wires them together, and manages their lifecycle.

The three layers each do one job:

MAAS – Metal as a Service — provisions and PXE-boots bare-metal nodes, installs the OS, tags hardware by role.

Juju – Models the cloud, deploys services, defines relations, and manages scaling and upgrades.

Charms – Encapsulated operators — one charm per service (e.g. nova-compute), carrying its deploy and config logic.

Bundle – openstack-base — a curated set of charms and relations that stands up a reference cloud.

The architecture below shows how those layers stack — from the metal at the bottom to the OpenStack control plane and the Ceph storage tier on top.

The three pillars, in one sentence each

MAAS turns a rack of anonymous servers into a pool of addressable, role-tagged nodes Juju can deploy onto. Juju is the part that does the thinking — you declare what you want and how the pieces relate, and it builds the graph. Charms are where the operational knowledge lives: each one knows how to install, configure, relate, scale, and upgrade its service, so the cloud administrator does not have to hold all of that in their head at 2 a.m.

Upgrades are part of the model too. Canonical ships the Charmed OpenStack Upgrader (COU), which detects the running cloud version and proposes a path to the next release — a meaningful detail, because in-place OpenStack upgrades are precisely the operation most teams put off until something forces their hand.

Charmed OpenStack vs. Sunbeam — don’t conflate them

One distinction worth getting right, because it changes how you plan everything downstream: “Canonical OpenStack” today refers to two different deployment models.

Two roads, same destination. Charmed OpenStack uses machine charms on Juju and MAAS — the mature, widely deployed model described in this article. Sunbeam is the newer, Kubernetes-native approach (K8s operators) positioned as the next-generation Canonical OpenStack. They are not interchangeable, and your operational tooling, storage assumptions, and data-protection design differ between them. When someone says “Canonical OpenStack,” ask which one.

The good news for either choice: the backup approach below supports both — Charmed OpenStack 2024.1 and Sunbeam 2024.1 LTS — so the deployment model you pick does not dictate how you protect the cloud.

Why backing up Charmed OpenStack is its own problem

Here is the part vendors tend to skip past. Charmed OpenStack automates deployment beautifully. It does not, on its own, protect the workloads running inside the instances — and an OpenStack cloud is a multi-component, multi-tenant, Ceph-backed environment where “just snapshot the VM” is rarely the whole answer.

A backup approach for this platform has to satisfy three constraints at once: it must not put agents inside the guest instances or reach into the hypervisor OS — both are overhead and privileged access you would rather not grant; it must drive the backup through OpenStack’s own APIs — Cinder for snapshots, Nova and Glance for metadata; and it must handle incremental backups across whatever storage backend the cloud happens to use, Ceph RBD included.

This is the architecture Storware Backup and Recovery uses. The data flow looks like this:

The mechanics, for the engineers in the room: Storware takes a crash-consistent snapshot through the Cinder API and collects instance metadata from the Nova, Glance and Cinder APIs. Volumes created from that snapshot are attached, one at a time, to a Storware Proxy VM running in the Availability Zone, and the data is read there — no agent inside the guest, and no access to the hypervisor OS. Application consistency is available through optional pre/post-snapshot command execution. For incrementals you have two options: where Ceph RBD is the storage backend, Storware fetches the changed-block list directly from the Ceph monitors (CBT-like); the preferred, backend-independent option computes block-level checksums, so incrementals work on any storage at the cost of a little more compute. Restore recreates the volumes on the Proxy VM, rebuilds the instance, and reuses the Glance image when it already exists in the target environment.

Two backup strategies, picked to fit your storage

Charmed OpenStack environments don’t all store disks the same way, so a single approach would be a poor fit. Storware exposes two production strategies — both built on Cinder disk-attachment — and which one you choose comes down to your storage backend and how much you care about backend-independent incrementals.

What you get on top of the data path

The transport layer is only half the value. Around it sits the part that matters when something goes wrong: an agentless architecture so neither the guest instances nor the hypervisor OS carry backup software, IsoLayer air-gap and WORM immutability with retention lock to keep copies beyond reach of ransomware, a Horizon UI plugin so tenants and administrators manage backups inside the dashboard they already use, a RESTful API for policy-driven automation, and multi-tenant RBAC for service-provider and enterprise separation.

Licensing is deliberately boring, which is the highest compliment you can pay an enterprise license model: per VM, per host, or per TB, with a single license covering every supported hypervisor — so a heterogeneous estate doesn’t turn into a procurement project every time you add a platform. And if part of that estate is still on VMware, the same platform handles VMware-to-OpenStack V2V migration, which makes Charmed OpenStack a realistic consolidation target rather than a science project.

The honest summary. Charmed OpenStack solves deployment and lifecycle. It does not solve data protection — that remains your problem, and a multi-component, Ceph-backed, multi-tenant cloud is not a place to improvise. An agentless, policy-driven backup layer that drives everything through Cinder, Nova and Glance — and handles incrementals on any storage backend — is the proven way to close that gap.

Frequently asked questions

Protect your Charmed OpenStack cloud — agentless, proven, policy-driven

See how Storware Backup and Recovery protects your Canonical OpenStack estate through Cinder disk-attachment, with backend-independent incrementals and immutable, air-gapped destinations. Book a technical walkthrough →