I know that by default geo-replicate is turned on for the azure service. However it only does so between two places within the same region. E.g. if I have chosen North Europe, the geo-replicate will be located in West Europe. Is it possible to so that I have the replication in US instead?
I want to make service such that my database can be located in two or more regions, such that the response time when accessing the database will be minimal. That is for a user in US he will access the database replica in US, while or a European user he will access the replica in Europe.
First, you should know that geo replication is turned on for Azure STORAGE service, not for any other Azure services yet. Then, you shall also be aware that this geo-replication is for disaster recovery mainly (and only as of today).
If you have to replicate a DB (Windows Azure SQL Database, a.k.a. WASD) you can use the SQL Data Sync - the only known way as of today to sync Azure Databases (either between different geo regions, or between Azure and on-premises).
There is not support for Windows Azure Cloud Service geo-replication. If you need to geographically distribute your application, you have to manage cloud service deployment across different data centers on your own.
If this is the case, for Azure storage, I would suggest using a single Storage service for WRITE operations, but Azure CDN for READ operations. Otherwise it might get too complicated. Of course the chosen architectural approach will depend on the requirements of the app (and expected load).
Then, you have to combine the different deployments with Azure Traffic Manager with a "Performance" algorithm setup.
EDIT (NOV 2014)
As of Q3 2014, Azure SQL Database also support Geo Replication. And Azure Data Sync is depricated and removed service. Azure Storage replication continue to be offered with 3 different flavours: Zone redundant, Geo redundant, Geo redundant with Read Access.
And still no option to replicate between Geographic Regions (i.e. from EU to US). Replication is still only an option between Geo Zone pairs (same geography).
I believe this is not possible today out of the box. You would need to do that on your own using data sync (for SQL Azure) and similar technologies (for Windows Azure Storage).
Related
Does Azure Synapse Analytics support Geo-Redundancy like Storage Account & Key vault? If not, why do I implement High availability for Azure Synapse Analytics? I have the following components as a part of the Azure Synapse Analytics Solution
SQL Dedicated Pool
SQL Serverless Pool
Spark Pool
Storage Account(ADLS)
Azure DevOps Git Repo
First, designing and documenting a Disaster Recovery plan is a project unto itself. I’ve been working on one for a client of mine using Synapse for several months part-time.
The first task is to define your Recovery Time Objective (RTO, meaning how long before your solution is back up in the event of a disaster) and your Recovery Point Objective (RPO, meaning how many minutes or hours of data you can afford to lose… and with analytics solutions you can usually reload from the source to catch up). If your RTO and RPO are low for an analytics solution (like 2 hours) then you probably need to spin up parallel environments in another region and load data to both environments in parallel. If your RTO and RPO are typical for an analytics solution (24-48 hours) then you can probably survive with ensuring backups are geo-redundant and restoring in the event of an outage. I would recommend you preconfigured your Synapse workspace and other infrastructure before the outage unless you have a trust an infrastructure as code solution. If your RPO and RTO are long (like 7 days) it’s extremely unlikely an Azure service or region is going to be down for that long.
ADLS supports RA-GRS redundancy so you could read all the files from the secondary endpoint in its pair region and copy files to another ADLS in the secondary region. Unfortunately ADLS accounts don’t yet support user-initiated failover.
Dedicated SQL Pools support built-in geo redundant backups once a day but you can’t control when they are taken. If this isn’t acceptable then you need to proactively create a user-defined restore point and proactively restore it cross region and pause the SQL pool.
Synapse Serverless SQL pools have no storage so ensure you have a backup of the schema (views, permissions, external data sources, external tables, etc) in source control or somewhere. The data will failover with ADLS.
For Spark Pools ensure you have your notebook artifacts in source control and you can always run them in a different Synapse workspace in another region when needed. Document your cluster configs.
Write out a disaster recovery playbook and do a DR drill periodically (once a quarter or once a year).
Here is another author’s description of the DR plan for Synapse.
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.
I have site deployed on Azure. I am using Cloud Services, Storage, SQL Database.
I want to have High Availability and Disaster Recovery for our Azure Website.
My question is that how can we provide this feature on Azure? Is it already managed by Azure or we need to use any services from Azure for the same.
Thanks in Advance
Well, I don't think DR is needed, since everything you use is PaaS Service, so if you trust Azure - it will handle everything for you, if you don't. Well, if you don't it won't help you ;)
So, in my opinion best way to achieve what you are looking for is using build-in HA for Cloud Services (increase instance count), while Storage and Azure SQL are HA by design.
If you really-really want DR, you can implement Traffic Manager with extra copy of your Cloud Service in another Azure region and implement Storage Replication and Azure SQL Replication.
I won't be giving link to documentation, as all of those are found in under 5 minutes in and search engine.
I want to confirm our understanding of how our Azure SQL databases are being backed up to enable point in time restore. We have not currently configured geo-replication to have the database available in another region. We may in the future as some data analysis is done. But my understanding is that the database is still being backed up to a geo redundant location so I could do a geo-restore if there was an issue with the data center that houses my sql database. Is that correct or do I need to enable geo-replication and pay for a second database in order to have a disaster recover option if the datacenter had an issue.
To clarify further: I think this article states what I'm saying in the Geo-Restore section.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/
Thanks
Yes, all databases have a geo-replicated copy for disaster recovery purposes. For more details, please see the following: https://azure.microsoft.com/en-us/blog/azure-sql-database-geo-restore/
Geo-restore uses the same technology as point in time restore with one
important difference. It restores the database from a copy of the most
recent daily backup in geo-replicated blob storage (RA-GRS). For each
active database, the service maintains a backup chain that includes a
weekly full backup, multiple daily differential backups, and
transaction logs saved every 5 minutes. These blobs are geo-replicated
this guarantees that daily backups are available even after a massive
failure in the primary region.
Yes, Azure SQL Databases are automatically backed up to a different Azure data center using Geo-Replication. This is an automatic features of Azure SQL that is baked into the service offering.
Here's a blog post with further information about Azure SQL Data Replication:
https://azure.microsoft.com/en-us/blog/azure-sql-database-standard-geo-replication/
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/