Optimizing OpenStack Swift Object Storage on SSDs: Performance, Ops, and EC Insights

Preface

The speaker shares optimization of OpenStack object storage on SSDs, which occupies about half of the content, with the other half covering distributed object storage operations. Object storage is a relatively new paradigm, and the speaker discusses the key points to consider in its operation.

Object storage has attracted more attention recently. The speaker explains why it has become a hot topic in the past year.

Why is Object Storage Hot Now?

Data volume is exploding, especially unstructured data such as photos taken on mobile devices and videos. Images grow at a remarkable rate, and 4K video frames generate dozens of times more data than standard HD video. This leads to massive amounts of small files (photos) and large files (videos), creating new storage challenges.

Traditional shared directories require mounting, unmounting, and handling high concurrency, which is difficult for cloud VMs that are created and destroyed on demand. Object storage simplifies access by using HTTP requests without complex file system operations, making data sharing and access control easier.

In the US, object storage is already a large business, used for storing genomic data, which generates huge volumes due to advanced sequencing technologies.

OpenStack Swift Distributed Object Storage

OpenStack is a massive ecosystem; the speaker focuses on Swift, which supports multi‑region active‑active deployment, tiering, and can integrate with Hadoop.

Swift uses Proxy nodes to provide the HTTP interface and Storage nodes to store objects in containers (called Containers in Swift). User isolation is achieved by separating accounts and containers, providing security advantages over traditional storage.

When creating and deleting cloud disks, the system may keep logical references, leading to potential data recovery issues if not properly erased.

Swift locates data using a Ring data structure (based on consistent hashing) to improve reliability and availability.

Operational Concerns for Distributed Object Storage

Key operational goals are:

Data reliability – ensuring data persistence.

Scalability – expanding from a few nodes to hundreds.

Availability – keeping storage services and data accessible.

Traditional metrics like IOPS, throughput, and latency remain relevant, but the focus shifts to guaranteeing the above goals.

A real‑world case: expanding an HDFS cluster caused data migration delays and temporary unavailability, highlighting the importance of proper scaling practices.

Monitoring should include HTTP request rates, per‑request latency, and identification of heavy‑traffic IPs. Large object reads/writes often dominate latency, especially when objects exceed 500 MB.

Because Swift is eventually consistent, operators need visibility into which data has been replicated across regions. The speaker describes a method to mark data that has been fully synchronized, helping users decide when to rely on cross‑region copies.

SSD Usage in OpenStack Swift

Performance tests compare 8 SATA HDDs, SSD for Account/Container metadata, and all‑SSD configurations. Small object reads see modest gains, while small object writes benefit significantly from SSD metadata storage.

For large objects (100 MB+), pure SSD does not dramatically improve performance; a hybrid approach (SSD for metadata, HDD for bulk data) offers a good cost‑performance balance.

Deployments may dedicate nodes for Proxy services and separate nodes for Account/Container storage, often using 2U servers with SSDs for metadata and 4U servers with HDDs for object data.

In clusters exceeding hundreds of terabytes, using SSD for all data becomes cost‑prohibitive; focusing SSD on metadata yields the best trade‑off.

Swift stores Account and Container information in SQLite databases (small files). Placing these on SSD accelerates write performance because updating containers generates many small I/O operations.

Erasure Coding (EC)

EC overhead is lower than expected, especially for large files. Small files are not ideal for EC due to increased I/O fragmentation.

Swift’s EC implementation (e.g., 6+8 scheme) can raise storage efficiency from 33 % (triple replication) to about 75 %.

Q & A

Question: How does Swift compare to other object storage solutions?

The speaker prefers Swift for its focus on object storage, simplicity, and features such as multi‑region replication, erasure coding, and extensible plugins for encryption and custom authentication.

Question: How to optimize the Auditor process that checks data integrity?

Auditor runs periodically and can be tuned to reduce CPU usage, though less frequent checks increase risk.

Question: How to monitor Swift?

Swift provides a RECON API and supports custom middleware to collect metrics.

Conclusion

Swift delivers strong performance for object storage, with ongoing efforts to rewrite core components in Go for future improvements.