OpenStack Swift object storage

The ring is the lookup table that tells every Swift proxy and storage node where an object belongs. When a request arrives, Swift hashes the account, container and object name to choose a partition, and the ring maps that partition to the devices that hold its copies. Every node reads the same ring files, so placement needs no central metadata service. Your main decisions are the ring builder settings: the partition power, the replica count for each storage policy, and the minimum time between partition moves. Confirm the exact parameter names, defaults and limits for your release in the Swift documentation before you build the first ring, because the partition power is difficult to change after data is stored.

Each device is assigned to a zone, and zones can be grouped into regions. The builder tries to place copies of a partition in different zones, so the loss of one rack, switch or site does not remove every copy. Erasure-coded storage policies apply the same placement logic to fragments instead of full copies. They lower raw capacity overhead but add CPU work and more network traffic during reads, writes and repairs. Before you choose a policy for each data type, count the zones and nodes you can supply. That number limits which replica counts and fragment layouts are viable, and it sets how much failure you can absorb without losing availability.

Swift is eventually consistent for object data. A write succeeds once a majority of the copies are stored, and the remaining copies are brought up to date later by replicators and object updaters that compare and repair differences in the background. During that window, a read can return an older version of an object, and container listings can lag behind recent writes. Applications that expect every read to reflect the latest write need to be designed for this. A common approach is to write each new version under a unique object name rather than overwrite an existing one. Ask your application owners which access patterns depend on immediate consistency, and confirm the guarantees for your Swift release before they design around them.

Changing the ring moves data. Adding, removing or reweighting devices changes which partitions belong on which devices. The builder reassigns a subset of partitions, you distribute the new ring to every node, and the replicators then copy or delete data over the network. This work uses disk I/O and bandwidth for as long as it runs and can slow client requests. Add capacity in controlled steps, review the builder's reported movement before you deploy, and schedule the work for periods of low traffic. Track replication lag and queue depth while it runs. Treat device removal as a planned data migration, and confirm that copies stay spread across zones throughout the process.

Choose Ceph RADOS Gateway (RGW) when your clients need both S3 and Swift APIs and you want one storage gateway serving both. RGW offers S3-compatible and Swift-compatible APIs on top of Ceph, so applications written for either protocol can share the same back end. Native Swift serves the Swift API directly, and S3 access depends on the s3api middleware. Before deciding, list every client that will connect, the protocol and API version each one uses, and the operations it calls. That inventory is the starting point for any comparison.

RGW's documented feature set covers multisite configuration, compression, Keystone and LDAP authentication, and multi-factor authentication. It also integrates with Open Policy Agent and exposes AWS STS, IAM and SNS APIs. Treat these as capabilities to verify, not defaults to assume. Confirm that the release line you plan to run includes each feature your clients or security policy depend on, and test the specific IAM and SNS actions your applications call. A supported API does not guarantee that every operation behaves the same way your client expects.

Ceph's source is licensed under LGPL-2.1 or LGPL-3, with some bundled components under other licenses, and the project itself offers no paid edition. Commercial support therefore comes from vendors or service partners, and that cost belongs in your comparison. The Ceph releases page lists Tentacle (20.2.x) and Squid (19.2.x) as actively maintained, with Squid's estimated end of life on October 31, 2026. Confirm the current dates on that page before committing, and plan any upgrade path with that estimate in mind.

The main trade-off is operating a separate storage platform. A Ceph cluster has its own monitors, OSDs, failure domains, network design, hardware sizing and upgrade cycle, and your team needs skills to run it. A native Swift cluster keeps object storage inside the OpenStack control plane, which means fewer moving parts if Swift is already in place. If your organization already runs Ceph for Glance, Cinder or Nova disks, adding RGW usually extends an existing skill set. If it does not, RGW adds a new platform, so request a quote that covers both the build and the ongoing operations.

Moving data into Swift is mostly an inventory and cutover problem, not a copy problem. Before anyone picks a tool, the team needs a complete list of the buckets, containers and file shares in scope, the applications that read and write each one, and the owner who can approve a switch. Ask each application owner which credentials, access lists and public URLs their system uses, and which objects they must keep or can discard. Most failed migrations trace back to a bucket nobody listed, a service account nobody rotated, or a nightly job that still writes to the old location after cutover.

Naming and metadata need a mapping decision before the first byte moves. Swift organizes data as accounts, containers and objects, and the S3 compatibility layer, when enabled through the s3api middleware, maps S3 buckets onto containers. Confirm which bucket names can become container names without conflict, how object keys with slashes or unusual characters will appear, and which custom metadata, content types and object tags your applications depend on. Where a source feature has no clean equivalent, such as versioning, lifecycle rules or object locking, record the gap as an explicit decision, because the application team will otherwise discover it in production.

Choose a copy tool that your own engineers can read, rerun and validate. Prefer tools that support S3 on both ends or that can work with the source's native API, can resume after interruption, can filter by prefix, and produce a manifest or log you can compare later. Test the tool on a representative subset first, including large objects, zero-byte objects, and keys with special characters. Ask the tool vendor or project for the exact options that control overwrite behavior, retries and concurrency, and confirm them in your environment. Do not rely on performance claims from a datasheet; measure against your own network path and the Swift cluster's capacity.

Plan a parallel period in which the source and Swift both hold current data and the application team confirms behavior against Swift. Use this period to change one non-critical consumer at a time, to test credential and endpoint changes, and to run incremental syncs for objects written after the first full copy. Cutover then means freezing writes on the source for the agreed window, running the final delta copy, switching client endpoints and credentials, and keeping the source read-only for a rollback period. The client team must provide application owners who approve each switch, a named contact for each consumer, the access lists and service accounts that need new credentials, and a cutover window that avoids batch jobs and reporting runs.

Verification decides whether the move is finished. Compare object counts and total bytes per container against the source inventory, then compare checksums for a defined sample, or for all objects if the data is regulated or business critical. Confirm that Swift stores the checksum or ETag your tool expects, and record any object whose checksum differs for investigation rather than overwriting it silently. Keep the manifests, tool logs and sign-off records as evidence for your change record and for any later compliance assessment. Ask DeployOpen or your internal team to define the acceptance criteria in writing before the first copy, so that the team agrees what success looks like.