Microsoft Azure RA-GRS Storage - After a Microsoft-managed failover to secondary region, is the data still geo-replicated?

3
votes

When using RA-GRS replication on an Azure Storage Account, if a regional outage occurs and there is a Microsoft-managed failover to the secondary region, is the data in that secondary region read-access geo-replicated again automatically?

Similarly, once the original primary region is back online, does the storage account automatically fail-back to this region or does it remain in the secondary region?

I can find plenty of information about the customer-managed failovers currently in preview but I'm struggling to find this information for Microsoft-managed failovers.

1
azureazure-storagereplication

1 Answers

1
votes

For your questions:

  1. Yes, the data in that secondary region will be read-access geo-replicated again automatically.
  2. After a failover, the storage account will stay in the secondary region as the new primary storage endpoint but all existing URIs will work the same before and after a geo-failover since the DNS entry of your storage account account..core.windows.net would be updated to point from the primary location to the secondary location. I think if the original primary region is back online, it will probably be the new secondary region for the data geo redundant. You can refer to the comments in the blog. It will depend on the issue. The options we have are to failover the primary, or to restore data on the primary from the secondary and our choice would depend on the issue at hand.

What is the Geo-Failover Process? Geo failover is the process of configuring a storage account’s secondary location as the new primary location. At present, failover is at stamp level and we do not have the ability to failover a single storage account. We plan to provide an API to allow customers to trigger a failover at an account level, but this is not available yet. Given that failover is at the stamp level, in the event of a major disaster that affects the primary location, we will first try to restore the data in the primary location. Restoring of primary is given precedence since failing over to secondary may result in recent delta changes being lost because of the nature of replication being asynchronous, and not all applications may prefer failing over if the availability to the primary can be restored.

If we needed to perform a failover, affected customers will be notified via their subscription contact information. As part of the failover, the customer’s “account..core.windows.net” DNS entry would be updated to point from the primary location to the secondary location. Once this DNS change is propagated, the existing Blob, Table, and Queue URIs will work. This means that you do not need to change your application’s URIs – all existing URIs will work the same before and after a geo-failover. For example, if the primary location for a storage account “myaccount” was North Central US, then the DNS entry for myaccount..core.windows.net would direct traffic to North Central US. If a geo-failover became necessary, the DNS entry for myaccount..core.windows.net would be updated so that it would then direct all traffic for the storage account to South Central US. After the failover occurs, the location that is accepting traffic is considered the new primary location for the storage account. Once the new primary is up and accepting traffic, we will bootstrap to a new secondary to get the data geo redundant again.

You could get more details from Microsoft Azure Storage Team Blog--- Windows Azure Storage Redundancy Options and Read Access Geo Redundant Storage