다음을 통해 공유

Introducing Zone Redundant Storage

  • 아티클

We are pleased to introduce Zone Redundant Storage (ZRS) as an additional redundancy option for Azure Storage. Customers can already choose from three options today: Locally Redundant Storage (LRS), Geo Redundant Storage (GRS) and Read-Access Geo Redundant storage (RA-GRS). ZRS provides customers another choice of redundancy, durability and price-point.

The following summarizes our existing offers:

Locally Redundant Storage (LRS): LRS keeps 3 replicas of your data within a single facility within a single region for durability.

Geo Redundant Storage (GRS): This is the default option for redundancy when a storage account is created. With GRS your data is replicated across two regions, and 3 replicas of your data are kept in each of the two regions.

Read Access - Geo Redundant Storage (RA-GRS): This is the recommended option for production services relying on Azure Storage. For a GRS storage account, you have the ability to leverage higher availability by reading the storage account’s data in the secondary region.

Introducing Zone Redundant Storage (ZRS)

As you can see, these options provide a continuum of durability and availability options. ZRS fits between LRS and GRS in terms of durability and price. ZRS stores 3 replicas of your data across 2 to 3 facilities. It is designed to keep all 3 replicas within in a single region, but may span across two regions. ZRS currently only supports block blobs. ZRS allows customers to store blob at a higher durability than a single facility can provide with LRS. ZRS accounts do not have metrics or logging capability enabled at this time.

 

Creating a ZRS Account

To create a ZRS account, you will need to log in to the azure management portal. From there, you can create a new storage account, selecting ZRS as the pricing tier. Since ZRS accounts only support Block Blobs, you will not see the table, queue or file endpoints listed on the portal for the new account. Also the monitoring section will be missing since ZRS accounts do not support metrics and logging at this time.

You can also use the Service Management API to create a new ZRS storage account. You will need to use Service Management API version 2014-06-01 or above. As with the portal, the Service Management API also returns just the blob endpoint for the newly created account, since tables, queues and files are not supported for ZRS accounts. Also, if you use Service Management API versions prior to 2014-06-01 to enumerate storage accounts, then any ZRS accounts will not be included in the enumeration. Similarly, attempting to retrieve properties of a storage account using API before 2014-06-01 will result in the request to fail.

You will need to be careful in your selection of redundancy level, since a ZRS account cannot be converted later to LRS or GRS. Similarly, an existing LRS or GRS account cannot be converted to a ZRS account. If you have existing blobs in blob storage and you want to use ZRS, then you have to create a ZRS account, and copy the blobs to the new account using AzCopy or the REST API.

Using a ZRS account

ZRS accounts can be accessed using the Azure Storage REST API, or our numerous client SDKs in various languages and platforms. Storage REST API version 2014-02-14 is the minimum REST version supported by ZRS accounts. Our client SDKs have been updated to support ZRS. The .net client supports ZRS as of version 4.0.0 and above, and the java client supports ZRS as of version 1.0.0. If you are using an older version of the SDK, you will need to upgrade to use a ZRS account.

Since ZRS accounts do not support page blob, file, table or queue, any attempt to create or manipulate those objects on a ZRS storage account will fail.

For accessing block blobs, there are no changes required to your code – just use the block blob APIs as you are used to today.

Pricing

The most up-to-date pricing for ZRS can be found on our pricing page.

As always, we are looking forward to your feedback.

Microsoft Azure Storage Team

Comments

  • Anonymous
    February 17, 2016
    What is the rationale for not supporting Tables and Queues for ZRS? Would like to ensure data residency, but still get extra layer of durability.

  • Anonymous
    February 17, 2016
    Barry can you explain your residency requirements a little further please?