You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/reliability/includes/storage/reliability-storage-availability-zone-down-experience-include.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,9 @@
13
13
14
14
If a zone becomes unavailable, Azure undertakes networking updates such as Domain Name System (DNS) repointing.
15
15
16
-
-**Notification:** You can monitor zone failure events by using Azure Service Health and Resource Health. Set up alerts on these services to receive notifications of zone-level issues.
16
+
-**Notification**: Azure Storage doesn't notify you when a zone is down. However, you can use [Azure Resource Health](/azure/service-health/resource-health-overview) to monitor for the health of your storage account. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Storage service, including any zone failures.
17
+
18
+
Set up alerts on these services to receive notifications of zone-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
17
19
18
20
-**Active requests:** In-flight requests might be dropped during the recovery process and should be retried. Applications should [implement retry logic](#transient-faults) to handle these temporary interruptions.
title: Description of Azure Storage alternative multi-region deployment introductoin
3
+
description: Description of Azure Storage alternative multi-region deployment introductoin
4
+
author: anaharris-ms
5
+
ms.service: azure
6
+
ms.topic: include
7
+
ms.date: 07/02/2024
8
+
ms.author: anaharris
9
+
ms.custom: include file
10
+
---
11
+
12
+
This section provides a high-level overview of some approaches to consider, but a complete treatment of multi-region deployment topologies for Azure Storage is outside the scope of this article.
Copy file name to clipboardExpand all lines: articles/reliability/includes/storage/reliability-storage-multi-region-alternative-reasons-include.md
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,5 +18,3 @@ The cross-region failover capabilities of Azure Storage might be unsuitable beca
18
18
- You need to fail over to a region that isn't your primary region's pair.
19
19
20
20
- You need an active/active configuration across regions.
21
-
22
-
Instead, you can design a cross-region failover solution that meets your needs. A complete treatment of deployment topologies for Azure Storage is outside the scope of this article, but you can consider a multi-region deployment model.
Copy file name to clipboardExpand all lines: articles/reliability/includes/storage/reliability-storage-multi-region-configure-enable-disable-include.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@
9
9
ms.custom: include file
10
10
---
11
11
12
-
-**Enable geo-redundancy on an existing storage account.** To convert an existing storage account to geo-redundant storage (GRS), see [Change how a storage account is replicated](/azure/storage/common/redundancy-migration) for step-by-step conversion procedures.
12
+
-**Enable geo-redundancy on an existing storage account.** To convert an existing storage account to geo-redundant storage (GRS), see [Change how a storage account is replicated](/azure/storage/common/redundancy-migration).
13
13
14
14
> [!WARNING]
15
15
> After your account is reconfigured for geo-redundancy, it might take a significant amount of time before existing data in the new primary region is fully copied to the new secondary region.
Copy file name to clipboardExpand all lines: articles/reliability/includes/storage/reliability-storage-multi-region-down-experience-include.md
+15-9Lines changed: 15 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,31 +22,35 @@ This section describes what to expect when a storage account is configured for g
22
22
> [!WARNING]
23
23
> An unplanned failover [can result in data loss](/azure/storage/common/storage-disaster-recovery-guidance#anticipate-data-loss-and-inconsistencies). Before you initiate a customer-managed failover, decide whether the restoration of service justifies the risk of data loss.
24
24
25
-
-**Notification:** Region failure events can be monitored through Azure Service Health and Resource Health. Set up alerts on these services to receive notifications of region-level issues.
26
-
25
+
-**Notification**: Azure Storage doesn't notify you when a region is down. However, you can use [Azure Resource Health](/azure/service-health/resource-health-overview) to monitor for the health of your storage account. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Storage service, including any region failures.
26
+
27
+
Set up alerts on these services to receive notifications of region-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
28
+
27
29
-**Active requests:** During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes. Any active requests might be dropped, and client applications need to retry after the failover completes.
28
30
29
-
-**Expected data loss:** Data loss is common during an unplanned failover because of the asynchronous replication lag, which means that recent writes might not be replicated. You can check the [Last Sync Time property](/azure/storage/common/last-sync-time-get) to understand how much data might be lost during an unplanned failover. You can typically expect the data loss to be less than 15 minutes, but that time isn't guaranteed.
31
+
-**Expected data loss:** Data loss is common during an unplanned failover because of the asynchronous replication lag, which means that recent writes might not be replicated. You can check the [Last Sync Time property](/azure/storage/common/last-sync-time-get) to understand how much data might be lost during an unplanned failover. Expected data loss is often referred to as the recovery point objective (RPO). You can typically expect the data loss (RPO) to be less than 15 minutes, but that time isn't guaranteed.
30
32
31
-
-**Expected downtime:**Failover typically completes within 60 minutes, depending on the account size and complexity.
33
+
-**Expected downtime:**The amount of expected downtime is often referred to as the recovery time objective (RTO). Customer-managed failover typically completes within 60 minutes (in other words, the expected RTO is 60 minutes), depending on the account size and complexity.
32
34
33
35
-**Traffic rerouting:** As the failover completes, Azure automatically updates the storage account endpoints so that applications don't need to be reconfigured. If your application keeps Domain Name System (DNS) entries cached, it might be necessary to clear the cache to ensure that the application sends traffic to the new primary region.
34
36
35
37
-**Post-failover configuration:** After an unplanned failover completes, your storage account in the destination region uses the locally redundant storage (LRS) tier. If you need to geo-replicate it again, you need to re-enable geo-redundant storage (GRS) and wait for the data to be replicated to the new secondary region.
36
38
37
39
For more information about how to initiate customer-managed failover, see [How customer-managed (unplanned) failover works](/azure/storage/common/storage-failover-customer-managed-unplanned) and [Initiate a storage account failover](/azure/storage/common/storage-initiate-account-failover).
38
40
39
-
-**Customer-managed failover (planned):** Use a planned failover when storage remains operational in the primary region, but you need to fail over your whole solution to a secondary region for another reason.
41
+
-**Customer-managed failover (planned):** Use a planned failover when storage remains operational in the primary region, but you need to fail over your whole solution to a secondary region for another reason. For example, another Azure service might be experiencing a problem and you need to switch to using a secondary region for your whole solution, or you might use a planned failover to conduct a disaster recovery drill for compliance and audit purposes.
40
42
41
43
-**Detection and response:** You're responsible for deciding to fail over. You typically make this decision if you need to fail over between regions even though your storage account is healthy. For example, you might trigger a failover when there's a major outage of another application component that you can't recover from in the primary region.
42
44
43
-
-**Notification:** Region failure events can be monitored through Azure Service Health and Resource Health. Set up alerts on these services to receive notifications of region-level issues.
45
+
-**Notification**: Azure Storage doesn't notify you when a region is down. However, you can use [Azure Resource Health](/azure/service-health/resource-health-overview) to monitor for the health of your storage account. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Storage service, including any region failures.
46
+
47
+
Set up alerts on these services to receive notifications of region-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
44
48
45
49
-**Active requests:** During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes. Any active requests might be dropped, and client applications need to retry after the failover completes.
46
50
47
-
-**Expected data loss:** No data loss is expected because the failover process waits for all data to be synchronized.
51
+
-**Expected data loss:** No data loss is expected (in other words, the expected RPO is zero) because the failover process waits for all data to be synchronized.
48
52
49
-
-**Expected downtime:** Failover typically completes within 60 minutes, depending on the account size and complexity. During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes.
53
+
-**Expected downtime:** Failover typically completes within 60 minutes (in other words, the expected RTO is 60 minutes), depending on the account size and complexity. During the failover process, both the primary and secondary storage account endpoints become temporarily unavailable for both reads and writes.
50
54
51
55
-**Traffic rerouting:** As the failover completes, Azure automatically updates the storage account endpoints so that applications don't need to be reconfigured. If your application keeps DNS entries cached, it might be necessary to clear the cache to ensure that the application sends traffic to the new primary region.
52
56
@@ -56,7 +60,9 @@ This section describes what to expect when a storage account is configured for g
56
60
57
61
-**Microsoft-managed failover:** In the rare case of a major disaster, where Microsoft determines that the primary region is permanently unrecoverable, Microsoft might initiate automatic failover to the secondary region. This process is managed entirely by Microsoft and requires no customer action. The amount of time that elapses before failover occurs depends on the severity of the disaster and the time required to assess the situation.
58
62
59
-
-**Notification:** Region failure events can be monitored through Azure Service Health and Resource Health. Set up alerts on these services to receive notifications of region-level issues.
63
+
-**Notification:** Azure Storage doesn't notify you when a region is down. However, you can use [Azure Resource Health](/azure/service-health/resource-health-overview) to monitor for the health of your storage account. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure Storage service, including any region failures.
64
+
65
+
Set up alerts on these services to receive notifications of region-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
60
66
61
67
> [!IMPORTANT]
62
68
> Use customer-managed failover options to develop, test, and implement your disaster recovery plans. **Don't rely on Microsoft-managed failover**, which might only be used in extreme circumstances. A Microsoft-managed failover is likely initiated for an entire region. It can't be initiated for individual storage accounts, subscriptions, or customers. Failover might occur at different times for different Azure services. We recommend that you use customer-managed failover.
Copy file name to clipboardExpand all lines: articles/reliability/includes/storage/reliability-storage-multi-region-support-failover-types-include.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Azure Storage supports three types of failover for different scenarios.
15
15
16
16
-**Customer-managed unplanned failover:** You're responsible for initiating recovery if there's a region-wide storage failure in your primary region.
17
17
18
-
-**Customer-managed planned failover:** You're responsible for initiating recovery if another part of your solution has a failure in your primary region. You need to switch your whole solution over to a secondary region.
18
+
-**Customer-managed planned failover:** You are responsible for initiating recovery if another part of your solution has a failure in your primary region, and you need to switch your whole solution over to a secondary region. Use a planned failover when storage remains operational in the primary region, but you need to fail over your whole solution to a secondary region, such as for disaster recovery drills designed to ensure compliance and audit requirements.
19
19
20
20
-**Microsoft-managed failover:** In exceptional circumstances, Microsoft might initiate failover for all geo-redundant storage (GRS) accounts in a region. However, Microsoft-managed failover is a last resort and is expected to only be performed after an extended period of outage. You shouldn't rely on Microsoft-managed failover.
Copy file name to clipboardExpand all lines: articles/reliability/overview-reliability-guidance.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,7 +78,7 @@ This section provides links to reliability guidance for many Azure services. Eac
78
78
|Azure Event Grid|[Reliability in Event Grid](./reliability-event-grid.md)||
79
79
|Azure Event Hubs||[Best practices for insulating Azure Event Hubs applications against outages and disasters](/azure/event-hubs/event-hubs-business-continuity-outages-disasters)|
80
80
|Azure ExpressRoute||[Design for high availability with ExpressRoute](../expressroute/designing-for-high-availability-with-expressroute.md?toc=/azure/reliability/toc.json&bc=/azure/reliability/breadcrumb/toc.json) </p>[Design for disaster recovery with ExpressRoute private peering](../expressroute/designing-for-disaster-recovery-with-expressroute-privatepeering.md?toc=/azure/reliability/toc.json&bc=/azure/reliability/breadcrumb/toc.json)|
81
-
|Azure Files||[Choose the right redundancy option](/azure/storage/files/files-disaster-recovery?toc=/azure/reliability/toc.json&bc=/azure/reliability/breadcrumb/toc.json#choose-the-right-redundancy-option)</p>[Disaster recovery and failover for Azure Files](/azure/storage/files/files-disaster-recovery?toc=/azure/reliability/toc.json&bc=/azure/reliability/breadcrumb/toc.json)|
81
+
|Azure Files|[Reliability in Azure Files](reliability-storage-files.md)||
82
82
|Azure Firewall|[Reliability in Azure Firewall](./reliability-firewall.md)||
83
83
|Azure Functions|[Reliability in Azure Functions ](reliability-functions.md)||
0 commit comments