We have our Azure key vault provisioned in East US and our hot-stand by region is West US.
Does it support Geo-Replication?
How do I configure the Azure Key vault to support the disaster recovery with automatic failover? Would it impact the connection string?
As per the documentation, its provided by default
"If individual components within the key vault service fail, alternate
components within the region step in to serve your request to make
sure that there is no degradation of functionality. You don't need to
take any action to start this process, it happens automatically and
will be transparent to you.
In the rare event that an entire Azure region is unavailable, the
requests that you make of Azure Key Vault in that region are
automatically routed (failed over) to a secondary region except in the
case of the Brazil South region. When the primary region is available
again, requests are routed back (failed back) to the primary region.
Again, you don't need to take any action because this happens
automatically."
You can read the whole documentation here. https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance
Related
Our application uses RA-GZRS for storage which enables to read data from the secondary when the primary is down, but can't write to it.
Is there a solution which enables application to do both read from and write to storage in the event of an Azure region going down?
In Azure Storage, there can be only one region (primary) where you can write. The other region (secondary) will always be read only.
One possible solution would be to do a manual failover so that the secondary region of your account becomes the primary and then you should be able to write to it. However, please be aware that the manual failover comes with a lots of caveats and make sure you understand those.
You can read more about those things here: https://learn.microsoft.com/en-us/azure/storage/common/storage-initiate-account-failover?tabs=azure-portal#important-implications-of-account-failover.
Please go through this. To quote from the article:
If the primary region becomes unavailable, you can choose to fail over
to the secondary region. After the failover has completed, the
secondary region becomes the primary region, and you can again read
and write data. For more information on disaster recovery and to learn
how to fail over to the secondary region, see Disaster recovery and
storage account failover.
The tutorial here tells you how to build a highly available application that automatically switches between endpoints on a failure. It uses a circuit breaker pattern.
I have a VM in Azure in location Central US . I have some restore points (fullbackups).
Can i restore the VM to a different resourcegroup in West US and reconnect to it with RDP ?
this is for disaster recovery if there is an issue with the Azure location or VM .
Also how can we guarantee that any location wont have issues ?
Interesting question.
You want to restore a VM hosted on the Central US to the West US.
Let's look into the Public Docs.
You could use the Cross Region (secondary region) restore to
restore Azure VMs in the secondary region, which is an Azure
paired region.
You can restore all the Azure VMs for the selected recovery point if
the backup is done in the secondary region.
During the backup, snapshots aren't replicated to the secondary
region. Only the data stored in the vault is replicated. So secondary
region restores are only vault tier restores. The restore time for the
secondary region will be almost the same as the vault tier restore
time for the primary region.
This feature is available for the options below:
Create a VM
Restore Disks
Unfortunately, I don't see the Central US region pairs with the West US region. So for your question if you can select your specific regional pair, answer is no.
Some Azure services rely upon regional pairs, such as Azure's
redundant storage. These services don't allow you to create new
regional pairings. Similarly, because Azure controls planned
maintenance and recovery prioritization for regional pairs, you can't
define your own regional pairs to take advantage of these services.
However, you can create your own disaster recovery solution by
building services in any number of regions and leveraging Azure
services to pair them.
I hope above helped to answer your questions.
I am working on Disaster Recovery for my application deployed on Azure. I am using following architecture.
Left side of Azure front door is primary region and right side is secondary region. Suppose disaster happened in primary region then Azure front door will send data to secondary region Azure function. Now failback happened that means primary region is up now. I want to flush all keys from Redis for Primary region since it has stale data before Azure front door sending data to primary region azure function.
Azure front door is configured to send data to primary region if it is healthy otherwise secondry region Azure function.
How can I do that?
Thanks
Does Azure Key Vault supports Geo-Replication between the regions? I don't see any options?
https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance
"The contents of your key vault are replicated within the region and
to a secondary region at least 150 miles away but within the same
geography to maintain high durability of your keys and secrets. See
the Azure paired regions document for details on specific region
pairs."
From #Karthikeyan Vijayakumar comment above:
However I have the application deployed on both West US (primary) and East US(secondary) and I want to sync between the regions.
You don't need to replicate your Key Vault instance to make it available to your applications in both regions.
Simply call the URL (https://<vault-instance-name>.vault.azure.net), Azure DNS will dynamically resolve to the active region. By default, the active region is the region where you created the instance. In the event this region is unavailable, the DNS will resolve to the geo-replica, hosted in the corresponding paired region.
The problem with this approach is that you still on the mercy of Microsoft, as the service will be reestablished only if they decide to failover the region.
Short story long: There is no user managed geo replication of Azure Key vault like Azure SQL for example. In your case, you need to build a workflow that replicates the values between your primary and secondary key vaults.
Backup and Restore : https://learn.microsoft.com/en-us/azure/key-vault/general/backup?tabs=azure-cli
You can use these capabilities to build your workflow.
You can use the changelog to track changes to your key vault, and trigger a backup/Restore or you can schedule it like once a day.
A change tracking is better as you can only replicate changes and not the entire key vault.
Regards
I've created a Hosted Service that talks to a Storage Account in Azure. Both have their regions set to Anywhere US but looking at the bills for the last couple of months I've found that I'm being charged for communication between the two as one is in North-Central US and the other South-Central US.
Am I correct in thinking there would be no charge if they were both hosted in the same sub-region?
If so, is it possible to move one of them and how do I go about doing it? I can't see anywhere in the Management Portal that allows me to do this.
Thanks in advance.
Adding to what astaykov said: My advice is to always select a specific region, even if you don't use affinity groups. You'll now be assured that your storage and services are in the same data center and you won't incur outbound bandwidth charges.
There isn't a way to move a storage account; you'll need to either transfer your data (and incur bandwidth costs), or re-deploy your hosted service to the region currently hosting your data (no bandwidth costs). To minimize downtime if your site is live, you can push your new hosted service up (to a new .cloudapp.net name), then change your DNS information to point to the new hosted service.
EDIT 5/23/2012 - If you re-visit the portal and create a new storage account or hosted service, you'll notice that the Anywhere options are no longer available. This doesn't impact existing accounts (although they'll now be shown at their current subregion).
In order to avoid such charges the best guideline is to use Affinity Groups. You define affinity group once, and then choose it when creating new storage account or hosted service. You can still have the Affinity Group in "Anywhere US", but as long as both the storage account and the hosted service are in the same affinity group, they will be placed in one DataCenter.
As for moving account from one region to another - I don't think it is possible. You might have to create a new account and migrate the data if required. You can use some 3rd party tool as Cerebrata's Cloud Storage Studio to first export your data and then import it into the new account.
Don't forget - use affinity groups! This is the way to make 100% sure there will no be traffic charges between Compute, Storage, SQL Azure.