Using RA-GRS Azure Storage Account, is it possible to write to a blob path in both regions?
We have two regions running the same data flows active-active (configured via Traffic Manager), however one legacy application used for file transfer to our on premise estate will only be available in the primary region. In case of DR we will manually stand up the application in the secondary region. (This is due to a limitation in the application itself.)
So the storage needs to be written to in both regions, but only in the primary region we will read (and delete on success) the data. Does RA-GRS allow this? Some delay in the files being synced to primary region will not be a problem.
Azure Storage Account RA-GRS does not offer two-way synchronization, you would need to implement a solution yourself. azcopy offers some functionality for doing this.
Related
We have Terraform state file stored in the Azure Storage Account. In case storage account went down we will be screwed. What is the best way to store the file? where?
AFAIK, there are two methods to store a terraform state file i.e. Locally in your machine or in a Storage account in azure .
In case storage account went down we will be screwed. What is the best
way to store the file? where?
As confirmed , You are using Standard_LRS which is not preferred as per the Microsoft Document if you are looking for high availability.
Locally redundant storage (LRS) copies your data synchronously three
times within a single physical location in the primary region. LRS is
the least expensive replication option, but is not recommended for
applications requiring high availability or durability.
So, as a solution you can change the storage account type as per your requirement to Standard_GRS or Standard_ZRS so that your data is present in two locations i.e. replicated.
You can change it by going to your storage account>>Configuration>>replication as shown below:
If You want more details on Disaster recovery (if one location is down) or data protection from Accidental Deletes then please refer the below documents:
Disaster recovery and storage account failover - Azure Storage | Microsoft Docs
Soft delete for containers - Azure Storage | Microsoft Docs
Since our RA-GZRS enabled Azure storage can't write to the secondary region when primary is down, thought of having another standby Azure storage to do the writes continuously.
The question is once the main storage account comes back, how sync the updates back to the main from standby? Can we write runbook using AzCopy.exe? Any other better Azure service/solution to accomplish sync process using AzCopy.exe/other as a background service?
Assuming the outage isn't severe enough that Microsoft doesn't failover to the secondary region. You can initiate the failover yourself, and then you would be able to write to the secondary region. This is essentially a DNS change which makes the secondary endpoint become the primary endpoint. Once the primary region becomes available again, you can change the storage account to geo-redundant storage, and then if required, repeat the failover.
See Initiate storage account failover and Storage account failover for more details.
To improve our application's availability, we have opted RA-GZRS for Azure storage. This enables us to read from the secondary when the primary is down, but we can't write to it.
But for our application to keep its essential service up & running, not only read also write to storage in the event of a region going down is MUST.
As there is no built-in solution for the above mentioned scenario, is there any custom solution which enables us to both read from and write to secondary region Azure storage as well in the event of a primary region going down?
Also thought of having alternative storage account with different primary region but later once availability of the primary is restored how to sync back recent delta changes written to the alternative storage account during the primary account failure?
Azure Storage provides you with the capability to do a manual failover from primary to secondary in case the primary region becomes unavailable. You could possibly use this approach to accomplish high availability.
You can read more about the manual failover here: https://learn.microsoft.com/en-us/azure/storage/common/storage-initiate-account-failover?tabs=azure-portal.
I've searched the web and contacted technical support yet no one seems to be able to give me a straight answer on whether items in Azure Blob Storage are backed up or not.
What I mean is, do I need to create a twin storage account as a "backup" and program copies of all content from one storage to another, or are the contents of a client's Blob Storage automatically redundantly backed up by Microsoft?
I know with AWS, storage is redundantly backed up via onsite drives as well as across other nodes in the cluster.
do I need to create a twin storage account as a "backup" and program
copies of all content from one storage to another, or are the contents
of a client's Blob Storage automatically redundantly backed up by
Microsoft?
Yes, you will need to do backup manually. Azure Storage does not back up the contents of your storage account automatically.
Azure Storage does provide geo-redundant replication (provided you configure the redundancy level for your storage account as GRS or RA-GRS) but that is not back up. Once you delete content from your primary account (location, it will automatically be removed from secondary account (geo-redundant location).
Both AWS (EBS) and Azure(Blob Storage) options provides durability by replicating the data across different data centers. This is for the high availability and durability of the data to provide the guarantee by the cloud provider.
In order to ensure that your data is durable, Azure Storage has the
ability to keep (and manage) multiple copies of your data. This is
called replication, or sometimes redundancy. When you set up your
storage account, you select a replication type. In most cases, this
setting can be modified after the storage account is set up.
For more details refer the replication section in documentation.
If you need to capture changes to the storage and allow restore to previous versions (e.g In situations like data corruption or application feature requirements like restore points, backups), you need to take a SnapShot manually. This is common for both AWS and Azure.
For more details on creating a Snapshot of Blob in Azure refer the documentation.
I know Azure will geo-replication a copy of current storage account to another location,
my questions is: can I access another location in program, even just read only
I asked this, because this allow me to build another deploy in different geo-location for performance and disaster-proof like what Azure did. For current setup, if I use same source of storage in different geo-location, I have to pay extra bandwidth cost.
You can only access your storage account by its primary name. In the event of failover, that name will be mapped to the alternate datacenter. You cannot access the failover storage directly, nor can you choose when to trigger a failover. For a multi-site setup as you described, you'd need to duplicate your data (which would then add the cost of storage in datacenter #2). This does give you ultimate flexibility in your DR and performance planning, but at an added cost of storage and bandwidth (egress-only).
Last week the storage team announced read-only access to the failover storage: Windows Azure Storage Redundancy Options and Read Access Geo Redundant Storage.
This means you can now deploy your application in a different datacenter which can be used for "full" failover (meaning that the storage will also be available there). Even if it's only read-only, your application will still be online - but simply in "degraded" mode.
The steps on how you can implement this with traffic manager are described here: http://fabriccontroller.net/blog/posts/adding-failover-to-your-application-with-read-access-geo-redundant-storage-and-the-windows-azure-traffic-manager/