Microsoft Unveils Georedundant Storage Option for Windows Azure
Microsoft this week rolled out a preview of a new georedundant option as part of its Windows Azure Storage service.
The new "read access-geographically redundant storage" option is currently available for testing in a "limited preview" trial worldwide, except in China. Organizations wanting to try it have to sign up for the trial first. It then becomes available for set up through the Windows Azure Management Portal, according to Microsoft's announcement.
It's not clear if it's free trial, but Microsoft plans to start charging for the preview sometime in February of 2014.
Three Storage Options
Microsoft currently has three types of Windows Azure Storage: locally redundant storage (LRS), geographically redundant storage (GRS) and the new read access-geographically redundant storage (RA-GRS). GRS is the default option when a Windows Azure Storage account gets created. It sets up a secondary storage site, located hundreds of miles away from the primary storage site. The GRS service replicates data asynchronously from the primary site to the secondary one.
A cheaper option is LRS, which replicates data synchronously, but only within a primary storage site. Consequently, with LRS, if a whole primary region goes down, data access becomes unavailable. The GRS service, in contrast, at least retains a copy of the data in another service region. LRS is 23 percent to 34 percent less expensive than GRS, according to Microsoft, in a very detailed blog post describing how the Windows Azure Storage services work.
The new RA-GRS service costs more than the GRS service but Microsoft promises higher availability with its RA-GRS service.
"The benefit of using RA-GRS is that it provides a higher read availability (99.99+%) for a storage account over GRS (99.9+%)," according to Microsoft's blog post.
A full list of Microsoft's storage cost options for Windows Azure can be found at this page.
Organizations with Windows Azure Storage accounts typically chose a primary site to store their data. However, Microsoft controls the secondary site location, and customers can't alter that secondary location. Primary and secondary sites have typical pairings though, as described by Microsoft's blog post. For instance, if the North Central U.S. region is chosen as a primary site, then it typically gets paired with the South Central U.S. region as the secondary site.
While Microsoft's talk of primary and secondary sites may sound reassuring, the Windows Azure Storage service has some limitations. For instance, failover from a primary to a secondary site currently happens "at stamp level," per Microsoft's lingo. A "stamp" is a regional unit with multiple storage node stacks. Microsoft can only failover multiple accounts to a stamp. It can't presently failover individual accounts. Since secondary sites are updated asynchronously, it's possible that the latest info won't be updated at the secondary site after a disaster occurs at a primary site.
That limitation came into the glare of the spotlight in a big way a year ago when Microsoft spent two days to restore data from a site failure rather than tap its GRS-created replicas. That Windows Azure service outage may have affected thousands of Microsoft's customers at the time. Microsoft explained that if it had tried to restore the data using its GRS service, it could have lost about 8 GB of recent data for all of its Windows Azure customers. And that's because there's a delay in the storage that occurs with the asynchronous GRS service. Microsoft's policy is to first try to recover the data at a site before performing a failover.
In a future Windows Azure Storage release, Microsoft plans to set up an API that its customers can use "to trigger a failover at an account level," according to Microsoft's blog post. Another addition in the works is log transactions for the RA-GRS service. Logs for transactions on the secondary site aren't currently available in the preview version of the RA-GRS service.
Kurt Mackie is senior news producer for the 1105 Enterprise Computing Group.