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/storage/common/storage-failover-private-endpoints.md
+16-16Lines changed: 16 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title: Failover Considerations for Storage Accounts with Private Endpoints
2
+
title: Failover considerations for storage accounts with private endpoints
3
3
titleSuffix: Azure Storage
4
4
description: Learn how to architect highly available storage accounts using Private Endpoints
5
5
services: storage
@@ -12,7 +12,7 @@ ms.author: brsteph
12
12
ms.subservice: common
13
13
14
14
---
15
-
# Failover Considerations for Storage Accounts with Private Endpoints
15
+
# Failover considerations for storage accounts with private endpoints
16
16
17
17
Storage accounts work differently than many other Azure services when it comes to high availability configurations. They don't often use a secondary instance deployed by the customer for resiliency. Instead, storage accounts configured to be [geo-redundant](./storage-account-overview.md#types-of-storage-accounts) replicate to another region, based on [regional pairs](/azure/reliability/cross-region-replication-azure). When necessary, the storage account can fail over to this replicated copy, and operate in the secondary region.
18
18
@@ -27,21 +27,21 @@ If you're using [private endpoints](../../private-link/private-endpoint-dns.md),
27
27
> [!NOTE]
28
28
> Not all storage account types support geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS). For example, data lakes deployed with premium block blob can only be locally redundant or zone redundant in a single region. Review [Azure Storage redundancy](./storage-redundancy.md) to make sure your scenario is supported.
29
29
30
-
## Example Architecture
30
+
## Example architecture
31
31
32
32
This architecture uses a primary and secondary region that can be used to handle active/active or failover scenarios. Each region has a hub network for shared network infrastructure. Each region also has a spoke where the storage account and other workload solutions are deployed.
33
33
34
34
The geo-redundant storage account is deployed in the primary region, but has private endpoints for its blob endpoint in both regions.
35
35
36
-
36
+
[](./media/storage-failover-private-endpoints/storage-failover-private-endpoints-topology.png#lightbox)
37
37
38
38
The two private endpoints can't use the same Private DNS Zone for the same endpoint. As a result, each region uses its own Private DNS Zone. Each regional zone is attached to the hub network for the region. This design uses the [DNS forwarder scenario](../../private-link/private-endpoint-dns.md#virtual-network-and-on-premises-workloads-using-a-dns-forwarder) to provide resolution.
39
39
40
40
As a result, regardless of the region of the VM trying to access the private endpoint, there's a local endpoint available that can access the storage blob, regardless of the region the storage account is currently operating in.
41
41
42
42
For connections from a data center, a VPN connection would be made to the hub network in the region. However, for DNS resolution, each data center would have its conditional forwarding set up to only one of the two DNS resolver server sets, to ensure that it resolves to the closest network location.
43
43
44
-
### Architecture Concepts
44
+
### Architecture concepts
45
45
46
46
This architecture uses functionality of private endpoints that may not be commonly encountered when doing single region deployments.
47
47
@@ -55,15 +55,15 @@ So long as there's an alternate Private DNS Zone for that region, resources in t
55
55
56
56
It's common to use private endpoints located in the same region to reduce costs. But when considering failover, this functionality can allow regional private networking to work despite failures in one region.
57
57
58
-
### Cross Region Traffic Costs
58
+
### Cross-region traffic costs
59
59
60
60
There are costs associated with having private endpoints in multiple regions. First, there's a cost per private endpoint. The above design would have two endpoints, and so would be charged twice. In addition, there's a cost for sending the traffic between regions. For more information about private endpoint costs, see [Azure Private Link pricing](https://azure.microsoft.com/pricing/details/private-link/).
61
61
62
62
Global virtual network peering is a service that connects virtual networks in multiple regions. It also has a data transfer cost between regions. This cost depends on the zone your networks are in. For more information about network costs, see [Virtual Network pricing](https://azure.microsoft.com/pricing/details/virtual-network).
63
63
64
64
Global peering can be used to enable services to communicate to each other during a service failure in a region. However, it supports fewer scenarios and may have more manual activities involved in activating a failover. An organization should review the costs of operating in a highly available or resilient architecture, and compare that to the risks of longer durations to restore service.
65
65
66
-
## Failover Scenarios
66
+
## Failover scenarios
67
67
68
68
This topology supports the following scenarios, and each scenario has its own considerations for DNS failover.
69
69
@@ -74,7 +74,7 @@ This topology supports the following scenarios, and each scenario has its own co
74
74
|[Scenario 3 - Whole Region Outage](#scenario-3---whole-region-outage)| A service interruption to multiple services in a region requires both the storage account and other services to be failed over. | Conditional forwarders from on-premises DNS need to be updated to the secondary region. |
75
75
|[Scenario 4 - Running in HA](#scenario-4---running-in-ha)| The services and storage accounts are working in Azure in an active/active configuration. | If a region's DNS or storage account is impacted, conditional forwarders on-premises need to be updated to operational regions. |
76
76
77
-
### Scenario 1 - Storage Account Failover
77
+
### Scenario 1 - storage account failover
78
78
79
79
In this scenario, an issue with the storage account requires it to be failed over to the secondary regions. With storage accounts that are zone redundant and geo-redundant, these outages are uncommon, but should still be planned for.
80
80
@@ -84,11 +84,11 @@ Connections from an on-premises data center connected by VPN would continue to o
84
84
85
85
After failover, the service will operate as illustrated:
86
86
87
-
87
+
[](./media/storage-failover-private-endpoints/storage-failover-private-endpoints-scenario-1.png#lightbox)
88
88
89
89
When the service is restored in the primary region, the storage account can be failed back.
90
90
91
-
### Scenario 2 - Other Services Failover
91
+
### Scenario 2 - other services failover
92
92
93
93
In this scenario, there's an issue with the services that connect to the storage account. In our environment, these are virtual machines, but they could be application services or other services.
94
94
@@ -100,14 +100,14 @@ Connections from an on-premises data center connected by VPN would continue to o
100
100
101
101
After failover, the service will operate as illustrated:
102
102
103
-
103
+
[](./media/storage-failover-private-endpoints/storage-failover-private-endpoints-scenario-2.png#lightbox)
104
104
105
105
When the service is restored in the primary region, the services can be failed back and on-premises DNS reset.
106
106
107
107
> [!NOTE]
108
108
> If you only need to connect to the storage account from on-premises for administrative tasks, a jump box in the secondary region could be used instead of updating DNS in the primary region. on-premises DNS only needs to be updated if you need direct connection to the storage account from systems on-premises.
109
109
110
-
### Scenario 3 - Whole Region Outage
110
+
### Scenario 3 - whole region outage
111
111
112
112
In this scenario, there's a regional outage of sufficient scope as both the storage account and other services need to be failed over.
113
113
@@ -117,11 +117,11 @@ Similar to Scenario 2, if the primary hub is unable to handle DNS responses to i
117
117
118
118
After failover, the service will operate as illustrated:
119
119
120
-
120
+
[](./media/storage-failover-private-endpoints/storage-failover-private-endpoints-scenario-3.png#lightbox)
121
121
122
122
When the services are restored, resources can be failed back, and on-premises DNS can be reset back to its normal configuration.
123
123
124
-
### Scenario 4 - Running in HA
124
+
### Scenario 4 - running in high availability
125
125
126
126
In this scenario, you have your workload running in an active/active mode. There are compute resources running in both the primary and secondary region, and clients are connecting to either region based off of load balancing rules.
127
127
@@ -133,9 +133,9 @@ For connectivity from on-premises data center locations, if the outage impacts a
133
133
134
134
While both regions are healthy, the service operates as illustrated:
135
135
136
-
136
+
[ (./media/storage-failover-private-endpoints/storage-failover-private-endpoints-scenario-4.png#lightbox)]
137
137
138
-
## Next Steps
138
+
## Next steps
139
139
140
140
As part of planning for your storage account resiliency, you can review the following articles for more information:
0 commit comments