openstack-swift

OpenStack Swift -- Object Storage Service

Swift provides distributed object storage with an HTTP-accessible API. Unlike block storage (Cinder), which provides attached devices, Swift stores objects (files) in containers (buckets) accessible via REST API calls. Swift is S3-compatible when the s3api middleware is enabled, making it a drop-in replacement for AWS S3 in many applications.

Architecture

Swift uses a ring architecture to determine where objects are stored. Even in a single-node deployment, understanding rings is important because they control data placement and replication.

• Rings: Swift maintains three rings -- account, container, and object. Each ring maps a partition to a set of devices (disks). The ring builder calculates this mapping based on the number of replicas, partition power, and device weights.
• Partition power: Determines how many partitions exist (2^power). Higher partition power = more granular distribution but more memory usage. Single-node typically uses partition power 10 (1024 partitions).
• Replicas: The number of copies of each object. Production uses 3 replicas across failure zones. Single-node uses 1 replica (no redundancy benefit with one node).
• Eventual consistency: Swift is designed around eventual consistency. After a write, reads from different nodes may temporarily return different results. Replicator and auditor processes converge state over time.

Service components:

• swift-proxy: The API frontend. Receives HTTP requests, authenticates via Keystone, routes requests to the appropriate storage nodes using the rings.
• swift-account: Manages account-level metadata and container listings.
• swift-container: Manages container-level metadata and object listings.
• swift-object: Stores and retrieves actual object data on disk.
• Auxiliary services: object-replicator, object-auditor, container-updater, account-reaper (background consistency processes).

Deploy

Kolla-Ansible Configuration

Key settings in globals.yml:

# Enable Swift
enable_swift: "yes"

# Disk configuration for Swift storage
# Kolla-Ansible expects dedicated disks or partitions
# Format: label:device pairs
swift_devices_name: "KOLLA_SWIFT_DATA"

# Number of replicas (1 for single-node)
swift_default_replication_count: 1

Disk Setup for Swift

Swift requires dedicated storage devices. For Kolla-Ansible:

# Format and label a disk for Swift
parted /dev/sdc mklabel gpt
parted /dev/sdc mkpart primary xfs 0% 100%
mkfs.xfs -f /dev/sdc1
# Label must match swift_devices_name
xfs_admin -L KOLLA_SWIFT_DATA /dev/sdc1

# Alternatively, use a loop device for testing
dd if=/dev/zero of=/srv/swift-disk bs=1M count=10240
mkfs.xfs -f /srv/swift-disk
# Mount and label for Kolla-Ansible discovery

Ring Building (Single-Node)

Kolla-Ansible builds rings during deployment. For single-node with 1 replica:

# Kolla-Ansible handles ring building, but for manual ring management:
# Account ring
swift-ring-builder account.builder create 10 1 1
swift-ring-builder account.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6202 --device sdc1 --weight 100
swift-ring-builder account.builder rebalance

# Container ring (same pattern)
swift-ring-builder container.builder create 10 1 1
swift-ring-builder container.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6201 --device sdc1 --weight 100
swift-ring-builder container.builder rebalance

# Object ring (same pattern)
swift-ring-builder object.builder create 10 1 1
swift-ring-builder object.builder add --region 1 --zone 1 \
  --ip 10.0.0.1 --port 6200 --device sdc1 --weight 100
swift-ring-builder object.builder rebalance

Container and Service Verification

# List Swift containers
docker ps --format '{{.Names}}' | grep swift

# Expected containers:
# swift_proxy_server, swift_account_server, swift_container_server,
# swift_object_server, swift_account_reaper, swift_object_expirer,
# swift_rsyncd

# Verify Swift is operational
openstack object store account show
# Should return account info with container count and bytes used

# Check S3 API availability (if s3api middleware is enabled)
# Use AWS CLI or s3cmd with OpenStack credentials

Configure

Storage Policies

Storage policies define different tiers of storage with different replication counts, erasure coding parameters, or device assignments.

# In swift.conf (through Kolla-Ansible config override)
[storage-policy:0]
name = standard
default = yes

# Additional policies for different tiers:
# [storage-policy:1]
# name = high-durability
# (requires separate ring and additional devices)

S3 API Middleware

Swift's s3api middleware provides S3-compatible API access:

# In proxy-server.conf pipeline (Kolla-Ansible configures this when enabled)
# pipeline = ... s3api s3token keystoneauth ... proxy-server

Using the S3 API:

# Create EC2 credentials for S3 access
openstack ec2 credentials create

# Use with AWS CLI
aws configure
# AWS Access Key ID: <ec2-access>
# AWS Secret Access Key: <ec2-secret>
# Default region: RegionOne

# Use with endpoint URL
aws --endpoint-url http://<swift-proxy>:8080 s3 ls
aws --endpoint-url http://<swift-proxy>:8080 s3 mb s3://my-bucket
aws --endpoint-url http://<swift-proxy>:8080 s3 cp file.txt s3://my-bucket/

Container ACLs

Swift provides container-level and account-level access control:

# Make a container publicly readable
swift post my-container --read-acl ".r:*,.rlistings"

# Grant read access to a specific project
swift post my-container --read-acl "<project-id>:*"

# Grant write access to a specific user
swift post my-container --write-acl "<project-id>:<user-id>"

# Remove ACLs
swift post my-container --read-acl "" --write-acl ""

TempURL Configuration

TempURL allows generating time-limited URLs for unauthenticated access:

# Set the tempurl key on the account
swift post -m "Temp-URL-Key: mysecretkey"

# Generate a tempurl (valid for 3600 seconds)
swift tempurl GET 3600 /v1/AUTH_<account>/my-container/my-object mysecretkey

Large Object Support

Swift has a 5GB limit per single object. For larger files, use segmented uploads:

• SLO (Static Large Object): Upload segments, then create a manifest listing all segments. Immutable after creation.
• DLO (Dynamic Large Object): Upload segments with a common prefix. The manifest points to the prefix. Segments can be modified independently.

# SLO upload using swift CLI
swift upload my-container --segment-size 1073741824 large-file.iso
# Creates segments in my-container_segments/ and a manifest in my-container/

# DLO: manually upload segments with shared prefix
swift upload my-container_segments segment-001 segment-002 segment-003
swift upload my-container large-file --header "X-Object-Manifest: my-container_segments/segment-"

Object Versioning

# Enable versioning on a container
swift post my-container -H "X-Versions-Location: my-container-versions"
# Create the versions container
swift post my-container-versions

# Now every overwrite of an object in my-container stores the
# previous version in my-container-versions

Object Expiry

# Set an object to expire after 86400 seconds (24 hours)
swift post my-container my-object -H "X-Delete-After: 86400"

# Set an object to expire at a specific Unix timestamp
swift post my-container my-object -H "X-Delete-At: 1771900000"

Rate Limiting

# In proxy-server.conf (through config override)
[filter:ratelimit]
account_ratelimit = 100    # requests per second per account
container_ratelimit_0 = 50  # requests per second for containers with 0+ objects

Operate

Container and Object CRUD

# Create a container
openstack container create my-container

# Upload an object
openstack object create my-container local-file.txt

# List containers and objects
openstack cont