eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The OpenStack Swift storage project’s new release defines a new era of cloud storage policies. Swift 2.0’s storage policies enable cloud administrators to be more flexible with their storage back end.
Swift administrators can now choose on which hardware data is stored. That choice can be geography-based, with storage located in the United States or in Asia, or it could be technology-based on either spinning disk or solid-state drives (SSDs).
Swift, one of the core projects in the open-source OpenStack cloud platform, was recently updated with its Icehouse release in April; however, the new Swift 2.0 release was not part of the Icehouse release, due to a number of timing- and testing-related issues that OpenStack Swift project leader John Dickinson detailed back in March.
OpenStack has two major integrated releases each year that include multiple projects within OpenStack. Dickinson explained to eWEEK that the features in the Swift 2.0 release will be further tested with other OpenStack projects for the OpenStack Juno platform release set for October.
Swift 2.0’s Storage Policies
With storage policies, cloud administrators now gain new automation capabilities for storage. An end user can now see what policies are available using Swift’s discoverable capabilities feature, Dickinson said. Those capabilities can be determined by storage policies set up by the cloud administrator.
Swift isn’t doing automatic storage tiering, but because the policies are set via API calls, it’s possible and expected that tools will be written to migrate data between policies, Dickinson explained.
“For example, this could be written as a management process that runs every night to move data from a hot to cold tier based on age of the data,” Dickinson said. “The great part is that it can be done with no interaction from the end user.”
Smooth Migration
Existing Swift users can move to the new version of Swift without taking their storage cluster down. The Swift developer community always aimed to make sure that deployers can upgrade to a new version without any end-user downtime or breaking any existing clients, Dickinson said.
“When deployers upgrade to 2.0, their existing storage will perfectly integrate into storage policies, without having to do any data migration,” Dickinson said. “If the deployer chooses to start using storage policies, then those will seamlessly integrate beside the existing storage.”
In terms of applications that rely on Swift, Dickinson said that all existing applications will continue to work.
“We have not broken anything in the Swift API that would prevent existing clients from continuing to work,” Dickinson said. “In fact, we’ve kept this API compatibility promise for the past five years.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.