Azure-docs: Storage Class for Allways on

Created on 1 Jul 2019  Â·  14Comments  Â·  Source: MicrosoftDocs/azure-docs

@Cedric-Bravo commented on Mon Jul 01 2019

Hi,
I'm surprised to see RA-GRS blob storage for the cross AZ scenario.
Did you want to mention ZRS ?


Détails du document

⚠ Ne pas modifier cette section. C’est obligatoire pour docs.microsoft.com ➟ Liaison des problèmes GitHub.

Pri1 assigned-to-author doc-bug high-availabilitsubsvc sql-databassvc triaged

All 14 comments

Hi team,
I'm moving this here because the contributor's comment is refering the original documentation
kind regards

Thank you for bringing this to our attention. Depending on the service tier your Azure SQL Database is deployed, Basic, Standard, and General Purpose service tier leverage LRS (Locally Redundant Storage) as there is no Geo-Replication occurring (See Image). With Premium and Business Critical service tiers where geo-replication is part of the service, the underlying storage is RA-GRS (Read Access - Geo-Redundant Storage)(See Image).

The use of ZRS (Zone Redendant Storage) is not applicable as ZRS does not support Read Access in the case of an outage. Please see additional details fos the differant Azure Storage options (link).

Hi thanks a lot for the reply,
I still don't understand why you need "Read Access - Geo-Redundant Storage" for Allways on cluster since the cluster nodes need RW access to storage and the cluster operate into the same region (and RA-GRS is region replication).
Why did you configure Region replication ? There is no node to read the data since they are into the same region ? image here

In this scenario, we want to provide SQL availability in case of Datacenter outage, not region outage... RA-GRS is overkill ?

Ok, i think got it... the RA-GRS is for backup file not database and log !
In prenium and Business critical service tiers, database file are stored in local SSD.
Correct ?
(The article is a bit confusing, maybe need to place the database file on the schema)

Actually, the database files are mirrored between the local SSDs and the associated storage account (LRS or RA-GRS). The difference between the two is if the region your instance is deployed to was to go off-line, with LRS your entire solution will become unavailable. With RA-GRS, the mirror activity will allow you to access the data in one of the paired regions established during initial set-up.

With LSR, the local SSDs act more like a cache and the .ldf and .mdf files are hosted in the Azure Storage account, all in the same region. With RA-GRS, because you have secondaries in different regions, these secondaries have exact copies of the .ldf/.mdf that are hosted on each respective set of SSDs in those paired regions (via the Always ON AG), and the RA-GRS storage provides a paired host for the backup files to be written to. The result is that regardless of the disaster scenario, there will always be the availability of your data.
Please let me know if you have any additional questions.

Thanks mike,
So in this scenario, what happen to my running database in case of a complete region outage ?
Does the database is still running ? (not only a backup availability).?

@Cedric-Bravo With Basic, Standard, and General Purpose deployments and LRS storage, if the region was to experience a complete outage your entire instance becomes unavailable. With Premium and Business Critical deployments and RA-GRS storage your solution may experience a minor (less than 20 seconds) service interruption if the region your primary instance was to experience a complete outage, as one of the secondaries will become the primary and service continues as normal. Does this make sense?

Ye mike, i understand that Premium and Business Critical deployments protect me from a region black out (minus a failover delay). This is not what is explain in the article that mention only a HA across AZ into the same region, not HA across Region. Does the article is outdated ?

By default, the cluster of nodes for the premium availability model is created in the same datacenter. With the introduction of Azure Availability Zones, SQL Database can place different replicas in the cluster to different availability zones in the same region. To eliminate a single point of failure, the control ring is also duplicated across multiple zones as three gateway rings (GW). The routing to a specific gateway ring is controlled by Azure Traffic Manager (ATM). Because the zone redundant configuration in the Premium or Business Critical service tiers does not create additional database redundancy, you can enable it at no extra cost. By selecting a zone redundant configuration, you can make your Premium or Business Critical databases resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes to the application logic. You can also convert any existing Premium or Business Critical databases or pools to the zone redundant configuration.

Thanks for the additional feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@jovanpop-msft @CarlRabeler Customer has pointed out a detail that likely needs some clarification. Firstly, why is the default availability model deployed to the same data center?

@mike-Ubezzi-MSFT please assign to @MashaMSFT
@anosov1960 for awareness

This thread seems to be causing some confusion so let me clarify.
First, the choice between RA-GRS, LRS and ZRS only applies to backup storage. RA-GRS enables the ability to restore from the read-only blob endpoint (geo-restore) even if the region goes down and you don't have database geo-replication set up. With zone redundant configuration the likelihood of the entire region going down is very small but it is not zero. Think of an event like hurricane, earthquake etc. Plus, some customers require that data geo-redundancy is guaranteed as a matter of compliance. This is why it is the default is not changed for zone redundant databases. But you can certainly justify changing it to ZRS as a cost optimization decision, especially if compliance is not an issue. Pleas note, the self-service method to change the default is not yet released.

Hi @CeciAc and @Cedric-Bravo , please let us know if your questions have been answered? If so, we will proceed with closing out this Git issue. Otherwise, please let us know how we can help further?

Thanks!
Masha from the SQL Docs team

Hi @CeciAc and @Cedric-Bravo , it's been some time since we've heard from you so we'll assume your question was addressed and close out the Git Issue. Please let us know if there is anything more we can do for you.

Thanks and hope you both have a wonderful rest of your day!
Masha from the SQL Docs team

please-close

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AronT-TLV picture AronT-TLV  Â·  3Comments

paulmarshall picture paulmarshall  Â·  3Comments

Ponant picture Ponant  Â·  3Comments

mrdfuse picture mrdfuse  Â·  3Comments

bityob picture bityob  Â·  3Comments