Skip to content

Commit eefbd92

Browse files
Merge pull request #307640 from stevenmatthew/imaniAirport
Added section fo0r priority replication
2 parents d964d56 + 30dd8a1 commit eefbd92

1 file changed

Lines changed: 19 additions & 6 deletions

File tree

articles/storage/common/storage-redundancy.md

Lines changed: 19 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -49,11 +49,11 @@ Azure Storage offers two options for how your data is replicated in the primary
4949
5050
### Locally redundant storage
5151

52-
Locally redundant storage (LRS) replicates the data within your storage accounts to one or more Azure availability zones located in the primary region of your choice. Although there is no option to choose your preferred availability zone, Azure may move or expand LRS accounts across zones to improve load balancing. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year. Visit the [What are Azure availability zones](../../reliability/availability-zones-overview.md) article to learn more about availability zone reliability.
52+
Locally redundant storage (LRS) replicates the data within your storage accounts to one or more Azure availability zones located in the primary region of your choice. Choosing your preferred availability zone isn't supported, and Azure might move or expand LRS accounts across zones to improve load balancing. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year. Visit the [What are Azure availability zones](../../reliability/availability-zones-overview.md) article to learn more about availability zone reliability.
5353

54-
LRS is the lowest-cost redundancy option and offers the least durability compared to other options. LRS protects your data against drive, server, and rack failures. However, if a disaster such as fire or flooding occurs within the data center, all replicas of a storage account using LRS might be lost or unrecoverable, and in the case of a temporary event such as a thermal event occurs within the data center, all replicas may be temporarily unavailable until the event is resolved. To mitigate these risks, Microsoft recommends using [zone-redundant storage](#zone-redundant-storage) (ZRS), [geo-redundant storage](#geo-redundant-storage) (GRS), or [geo-zone-redundant storage](#geo-zone-redundant-storage) (GZRS).
54+
LRS is the lowest-cost redundancy option and offers the least durability compared to other options. LRS protects your data against drive, server, and rack failures. However, if a disaster such as fire or flooding occurs within the data center, all replicas of a storage account using LRS might be lost or unrecoverable. If a temporary event, such as a thermal event, occurs within the data center, all replicas might be temporarily unavailable until the event is resolved. To mitigate these risks, Microsoft recommends using [zone-redundant storage](#zone-redundant-storage) (ZRS), [geo-redundant storage](#geo-redundant-storage) (GRS), or [geo-zone-redundant storage](#geo-zone-redundant-storage) (GZRS).
5555

56-
A write request to a storage account that is using LRS happens synchronously. The write operation returns successfully only after the data is written to all three replicas.
56+
A write request to a storage account that's using LRS happens synchronously. The write operation returns successfully only after the data is written to all three replicas.
5757

5858
The following diagram shows how your data is replicated within a single data center with LRS:
5959

@@ -71,7 +71,7 @@ Zone-redundant storage (ZRS) replicates the data within your storage accounts to
7171

7272
When you utilize ZRS, your data remains accessible for both read and write operations even if a zone becomes unavailable. If a zone becomes unavailable, Azure undertakes networking updates such as Domain Name System (DNS) repointing. These updates could affect your application if you access data before the updates are complete. When designing applications for ZRS, follow practices for transient fault handling, including implementing retry policies with exponential back-off.
7373

74-
A write request to a storage account that is using ZRS happens synchronously. The write operation returns successfully only after the data is written to all replicas across the three availability zones. If an availability zone is temporarily unavailable, the operation returns successfully after the data is written to all available zones.
74+
A write request to a storage account that's using ZRS happens synchronously. The write operation returns successfully only after the data is written to all replicas across the three availability zones. If an availability zone is temporarily unavailable, the operation returns successfully after the data is written to all available zones.
7575

7676
Microsoft recommends using ZRS in the primary region for scenarios that require high availability. ZRS is also recommended for restricting replication of data to a particular region to meet data governance requirements.
7777

@@ -107,7 +107,7 @@ When you utilize GRS or GZRS, the data in the secondary region isn't available f
107107
If the primary region becomes unavailable, you can choose to fail over to the secondary region. After the failover operation completes, the secondary region becomes the primary region and you're able to 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](storage-disaster-recovery-guidance.md).
108108

109109
> [!IMPORTANT]
110-
> Because data is replicated to the secondary region asynchronously, a failure that affects the primary region may result in data loss if the primary region cannot be recovered. The interval between the most recent writes to the primary region and the last write to the secondary region is known as the recovery point objective (RPO). The RPO indicates the point in time to which data can be recovered. The Azure Storage platform typically has an RPO of less than 15 minutes, although there's currently no SLA on how long it takes to replicate data to the secondary region.
110+
> Because data is replicated to the secondary region asynchronously, a failure that affects the primary region might result in data loss if the primary region can't be recovered. The interval between the most recent writes to the primary region and the last write to the secondary region is known as the recovery point objective (RPO). The RPO indicates the point in time to which data can be recovered. The Azure Storage platform typically has an RPO of less than 15 minutes. New Service Level Agreement (SLA)-backed [priority replication features](#geo-and-object-replication-priority-replication) are available that guarantee a specific RPO for data replication to the secondary region.
111111
112112
### Geo-redundant storage
113113

@@ -119,6 +119,19 @@ The following diagram shows how your data is replicated with GRS or RA-GRS:
119119

120120
:::image type="content" source="media/storage-redundancy/geo-redundant-storage.png" alt-text="Diagram showing how data is replicated with GRS or RA-GRS":::
121121

122+
#### Geo and Object Replication Priority Replication
123+
124+
Priority Replication for geo-redundancy and object replication is a blob data-specific **preview** feature that allows you to prioritize the replication of data to a secondary region. These features can be useful for scenarios where certain critical data needs to be available in the secondary region as quickly as possible.
125+
126+
SLAs for both priority replication features ensure that your high-priority data is replicated to the secondary region with minimal delay. The addition of these SLAs enhances the overall resilience and availability of your applications.
127+
128+
By enabling these features, you incur a per-GB cost associated with the prioritized replication of your data. When you disable priority replication, you're billed for 30 days beyond the date on which the feature was disabled.
129+
130+
> [!IMPORTANT]
131+
> Priority replication for geo redundant storage accounts and object replication is currently in PREVIEW.
132+
>
133+
> When you disable priority replication, you're billed for 30 days beyond the date on which the feature was disabled.
134+
122135
### Geo-zone-redundant storage
123136

124137
Geo-zone-redundant storage (GZRS) combines the high availability provided by redundancy across availability zones with protection from regional outages provided by geo-replication. Data in a GZRS account is copied across three or more [Azure availability zones](../../reliability/availability-zones-overview.md) in the primary region. In addition, it also replicates to a secondary geographic region for protection from regional disasters. Microsoft recommends using GZRS for applications requiring maximum consistency, durability, and availability, excellent performance, and resilience for disaster recovery.
@@ -138,7 +151,7 @@ Geo-redundant storage (with GRS or GZRS) replicates your data to another physica
138151
If your applications require high availability, then you can configure your storage account for read access to the secondary region. When you enable read access to the secondary region, then your data is always available to be read from the secondary, including in a situation where the primary region becomes unavailable. Read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS) configurations permit read access to the secondary region.
139152

140153
> [!NOTE]
141-
> Azure Files does not support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).
154+
> Azure Files doesn't support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS).
142155
143156
### Design your applications for read access to the secondary
144157

0 commit comments

Comments
 (0)