Overview of OpenStack Swift: Architecture, Consistency Model, and Components

Background and Overview

Swift was originally developed by Rackspace as a highly available distributed object storage service and contributed to the OpenStack community in 2010 as a core project supporting Nova's virtual machine image storage. Built on inexpensive commodity hardware without RAID, it uses consistent hashing and data redundancy at the software layer, sacrificing some consistency for high availability and scalability, supporting multi‑tenant, container, and object operations, making it suitable for unstructured data storage in Internet‑scale applications.

The project is implemented in Python and released under the Apache 2.0 license, allowing commercial use.

Consistent Hashing

To distribute massive numbers of objects across thousands of servers and disks, Swift employs consistent hashing. Objects are uniformly mapped to virtual nodes in a virtual address space; when nodes are added or removed, only a small fraction of data needs to be moved. The virtual space size is typically a power of two, enabling efficient bit‑shifts. A ring data structure then maps virtual nodes to physical storage devices, completing the addressing process.

As shown in Figure 1, a 32‑bit hash space is divided into virtual nodes by right‑shifting the hash value. The number of virtual nodes (2^(32‑m)) is chosen to balance storage capacity and workload.

Consistency Model

Following Eric Brewer’s CAP theorem, Swift cannot simultaneously guarantee strict consistency, availability, and partition tolerance. It adopts eventual consistency to achieve high availability and horizontal scalability, using a quorum protocol where N is the total replica count, W the number of replicas that must acknowledge a write, and R the number of replicas that must respond to a read.

(1) Definitions: N – total replicas; W – write quorum; R – read quorum.

(2) Strong consistency: R + W > N ensures read and write sets intersect, allowing the latest version to be read. For example, W = N, R = 1 provides strong consistency for read‑heavy workloads; R = N, W = 1 suits write‑heavy workloads.

(3) Weak consistency: R + W ≤ N may result in stale reads, suitable for scenarios with low consistency requirements.

Swift targets workloads with frequent reads and writes, using a compromise: W > N/2 and R + W > N. The default configuration is N = 3, W = 2, R = 1 or 2, meaning each object has three replicas distributed across different zones. A read with R = 1 may return a stale version, while R = 2 (with the x-newest=true header) forces comparison of timestamps to obtain the newest copy.

Ring Data Structure

The ring maps virtual partitions to a set of physical storage devices, providing redundancy. It stores:

Device list (id, zone, weight, IP, port, device name, metadata).

Partition‑to‑device mapping array (replica2part2dev_id).

Partition shift value (part_shift) used for bit‑shifts.

To locate an object, Swift hashes the account/container/object key with MD5, takes the first four bytes, right‑shifts by part_shift to obtain a partition index, then looks up the corresponding devices in the mapping table. Devices are preferably spread across at least five zones for maximum redundancy; weight values influence how many partitions a device receives.

Data Model

Swift uses a hierarchical model with three logical layers: Account → Container → Object. Accounts act as tenants, containers group objects like directories, and objects consist of metadata and content. This model can scale without limits at any layer.

System Architecture

Swift follows a fully symmetric, resource‑oriented distributed architecture where every component is horizontally scalable, eliminating single points of failure. Communication uses non‑blocking I/O to maximize throughput and responsiveness.

Key components include:

Proxy Server : Exposes RESTful object APIs, routes requests based on ring information, and is stateless for easy scaling.

Authentication Server : Issues and validates token‑based access credentials.

Cache Server : Caches tokens, account, and container metadata (not object data) using a Memcached cluster with consistent hashing.

Account Server : Stores account metadata and container listings in a SQLite database.

Container Server : Stores container metadata and object listings, also in SQLite.

Object Server : Stores object content as files and metadata as extended attributes, preferably on XFS.

Replicator : Periodically reconciles local and remote partitions, using rsync for push‑based replication and cleaning up deleted objects.

Updater : Queues delayed updates when the system is overloaded, processing them asynchronously later.

Auditor : Verifies integrity of objects, containers, and accounts, isolating corrupted bits and repairing from replicas.

Account Reaper : Removes accounts marked for deletion along with all associated containers and objects.

API

Swift provides an HTTP‑based REST API via the Proxy Server. Clients first obtain an authentication token, then include it in the X-Auth-Token header for subsequent requests. Below is an example request that lists containers in an account and the corresponding response:

GET /v1/<account> HTTP/1.1
Host: storage.swift.com
X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb

HTTP/1.1 200 OK
Date: Thu, 07 Jan 2013 18:57:07 GMT
Server: Apache
Content-Type: text/plain; charset=UTF-8
Content-Length: 32

images
movies
documents
backups

All supported operations are summarized in Table 1 (image omitted). Detailed API specifications are available in the developer guide, and bindings exist for Python, Java, .NET, Ruby, PHP, and other languages.

Conclusion

OpenStack Swift is a stable, highly available open‑source object storage solution adopted by many enterprises, such as Sina App Engine and Korea Telecom's Ucloud Storage. Its openness, large user base, and active community suggest Swift could become a de‑facto open standard for cloud storage, challenging proprietary services like Amazon S3 and promoting a more interoperable cloud ecosystem.