Azure Storage Object Replication

failover-to-secondary

I’ve previosly written about Azure datacenters and especially about the norwegian datacenters (https://msandbu.org/not-all-azure-datacenters-are-equal-what-to-consider-with-regards-to-dr/), where we have two regions where only east is active and west is a passive datacenter which is only used to support the underlying services which require geo redudant services, such as Azure SQL, Storage and so on.

This poses an issue especially in DR scenario since data is then replicated as part of the GRS redudancy level to Norway West. Many customer choose to use Norway East as primary and West Europe as a DR site for services such as Azure Site Recovery. For Storage redudancy they have until now only been able to use LRS since GRS would replicate data between Geo-paired regions (Norway East and West).

As announced at Ignite, Microsoft has now introduced a new feature called Object Replication (Currently in Public Preview as of 13/07/2020), which allows you to replicate data between storage accounts between defined regions

Diagram showing how object replication works

Since this is currently in Preview, you need to sign up for the resource providers to use it. You can sign up by sending an email to [email protected] (This is to whitelist a subscription for the AllowObjectReplication feature)

# Register for the object replication preview

Register-AzProviderFeature -FeatureName AllowObjectReplication -ProviderNamespace Microsoft.Storage

# Register for change feed (preview)

Register-AzProviderFeature -FeatureName Changefeed -ProviderNamespace Microsoft.Storage

# Register for blob versioning (preview)

Register-AzProviderFeature -FeatureName Versioning -ProviderNamespace Microsoft.Storage

# Refresh the Azure Storage provider namespace

Register-AzResourceProvider -ProviderNamespace Microsoft.Storage

Secondly it is only available in three regions (France Central, Canada Central and Canada East) also you need to have the following features enabled for the storage accounts (Versioning and Change Feed enabled) also Only GPv2 and Blob storage accounts can enable Change feed. Premium BlockBlobStorage accounts, and hierarchical namespace enabled accounts are not currently supported

The object replication feature uses Versioning and Change Feed to track changes to objects in a blob container. Change feed is a feature that provides transactional log of successful mutations or changes to an storage account account such as blob creation, modification, and deletions and is used to replicate changes across from one storage account to another. Blob versioning allows track different versions of a file in a storage account.

Once both of these features are enabled you will get a new option called object replication available in the portal.

After configuring an object replication policy, the destination container becomes read-only. If you try to upload files to the destination container you will get 409 error. The only way to get the destination account to become writeable again is to remove the replication policy.

When defining a replication policy you can also define what object that should be copied over, if it should take everything or just new objects

A storage account can serve as the source account for up to two destination accounts. And a destination account may have no more than two source accounts. The source and destination accounts may all be in different regions and it should be noted that this feature uses asyncronous replication. Because block blob data is replicated asynchronously, the source account and destination account are not immediately in sync. There’s currently no SLA on how long it takes to replicate data to the destination account.

It should be noted however that using features like Azure Backup there is no support for move the storage account data source from one to another. This means that you cannot use Azure Backup to backup data to a LRS storage account in Norway East and then use object replication to move data to west europe to reseed the data there. But this will be extremely useful for scenarioes where you need to have pure object data replicated because of DR purposes.

 

 

 

You May Also Like

About the Author: Marius Sandbu

Leave a Reply

Your email address will not be published. Required fields are marked *