After 20+ years in software engineering, the transition to the Cloud Storage is creating some incredible opportunities. For example, the concept of “Path to Cloud” as apposed to “Path to Tape” is revolutionizing business. Traditionally, tape drives have been used for long-term backups.  Government laws, like the Sarbanes Oxley Act of 2002, require certain types of data to be saved for 7 years. Using disk drives to fulfill this requirement would require a large number of disk drives, and therefore are prohibitively expensive.

Last time I described how Openstack Swift stores data and started to explain Storage nodes, Consistent Hashing, and caching called an Account Ring. Let’s dig into the Rings a bit.

Openstack Swift Storage Account Rings

The Account Ring is used by the Proxy nodes to determine where each account is stored. There is one and only one Account Ring for a given Swift Cluster. Input to the Account Ring is the tuple: (account name). The account name is then hashed, and the hash is used as an index into the Account Ring. The result is the three Storage nodes that contain a copy of the account data. All three copies are identical; so it does not matter which copy (Storage node) is used by the Proxy node. In practice, a specific Proxy node, given repeated requests for a specific account, will round robin the Storage node requests to help balance the load.

In a previous blog, I presented the topology of Openstack Swift Object Storage.   That is, how Swift uses XFS  to store Accounts, Containers, and Objects.

A separate Account Database is created for each Account and an Account Database is a SQLite  instantiation in the file system. An Account Database consists of a Account Stat Table and a Container Table. The Account Stat Table contains meta-data for that specific account.   The Container Table contains an entry for each container in that account.