A blog to share security, networking and cloud related technology information as @vCloudernBeer picked up on his search for his destiny in the cloud. (LinkedIn: https://www.linkedin.com/in/chowanthony)

Thursday, November 6, 2014

OpenStack Series: Part 7 – Swift – Object Storage Service

Last time when I blog about OpenStack Cinder I have mentioned that there are 3 main categories of storage:

Introduction to Object Storage OpenStack Documentation defines Object Storage as a robust, highly scalable and
fault tolerant storage platform for unstructured data
such as objects. Objects are stored bits, accessed
through a RESTful, HTTP-based interface. You cannot access
data at the block or file level. Object Storage is commonly
used to archive and back up data, with use cases in
virtual machine image, photo, video and music storage.

If you want to know more about object storage take a look a this TechTarget SearchCloudStorage article.

OpenStack Swift Architecture

Swift is the Object Storage service in OpenStack. I think one of the best feature for object storage is build-in redundancy and high availability objects are stored on multiple nodes. We can also think of Swift as a replication system.

Object storage fits right into the current huge demand for storing web based content. Everything stored in Swift is an object and each object can be referenced by a URI which makes access to the stored content easily retrievable.

By far the best article on OpenStack Swift is this one by SwiftStack which has tons of useful information about Swift.

SwiftStack offers a commercial version of Swift and is a major contributor and promoter to the OpenStack Swift project. On Oct 30 SwiftStack received $16M series B funding.

The above diagram show the relationship between the Proxy server and the Account, Object and Container server via the Ring. For a more detailed description of the various servers in Swift visit this blog post.

All objects in Swift can be accessed via the RESTful API. SwiftStack blog has this description for the API format:

/account

The account storage location is a uniquely named storage area that
contains the metadata (descriptive information) about the account itself
as well as the list of containers in the account.

Note that in Swift, an account is not a user identity. When you hear account, think storage area.

/account/container

The container storage location is the user-defined storage area
within an account where metadata about the container itself and the list
of objects in the container will be stored.

/account/container/object

The object storage location is where the data object and its metadata will be stored.

Each object is represented by an URI: https://abc.com/v1/account/container/object_name

Swift is deployed as a cluster. Each cluster is made up of nodes. A node is the Linux machine where the Swift processes runs on. Each cluster can logically be divided into regions in which there are zones.

Swift Storage Policy
New in the Juno release is the Storage Policy. This makes OpenStack more "enterprise" ready by allowing users and application developers to decide how they want to store,
replicate and access data across different backends and geographical
regions. The Juno Release stated for Swift Storage Policy:

Storage policies give users more control over cost and performance in
terms of how they want to replicate and access data across different
backends and geographical regions.

The Ring is the key in making the Storage Policy works without much change to the existing API.