Skip to content

Commit 0314725

Browse files
Jak-MSJak-MS
authored
Merge pull request #105943 from anavinahar/patch-229
Update load-balancer-standard-availability-zones.md
2 parents 4dada0c + cf9801f commit 0314725

File tree

1 file changed

+4
-105
lines changed

1 file changed

+4
-105
lines changed

‎articles/load-balancer/load-balancer-standard-availability-zones.md

Lines changed: 4 additions & 105 deletions
Original file line numberDiff line numberDiff line change
@@ -19,71 +19,21 @@ ms.author: allensu
1919

2020
Azure Standard Load Balancer supports [availability zones](../availability-zones/az-overview.md) scenarios. You can use Standard Load Balancer to optimize availability in your end-to-end scenario by aligning resources with zones and distributing them across zones. Review [availability zones](../availability-zones/az-overview.md) for guidance on what availability zones are, which regions currently support availability zones, and other related concepts and products. Availability zones in combination with Standard Load Balancer is an expansive and flexible feature set that can create many different scenarios. Review this document to understand these [concepts](#concepts) and fundamental scenario [design guidance](#design).
2121

22-
>[!IMPORTANT]
23-
>Review [Availability Zones](../availability-zones/az-overview.md) for related topics, including any region specific information.
24-
2522
## <a name="concepts"></a> Availability Zones concepts applied to Load Balancer
2623

27-
There's no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance. Load Balancer resources are objects within which you can express how Azure should program its prebuilt multi-tenant infrastructure to achieve the scenario you wish to create. This is significant in the context of availability zones because a single Load Balancer resource can control programming of infrastructure in multiple availability zones while a zone-redundant service appears as one resource from a customer point of view.
28-
29-
A Load Balancer resource itself is regional and never zonal. And a VNet and subnet are always regional and never zonal. The granularity of what you can configure is constrained by each configuration of frontend, rule, and backend pool definition.
30-
24+
A Load Balancer resource itself is regional and never zonal. The granularity of what you can configure is constrained by each configuration of frontend, rule, and backend pool definition.
3125
In the context of availability zones, the behavior and properties of a Load Balancer rule are described as zone-redundant or zonal. Zone-redundant and zonal describe the zonality of a property. In the context of Load Balancer, zone-redundant always means *multiple zones* and zonal means isolating the service to a *single zone*.
32-
3326
Both public and internal Load Balancer support zone-redundant and zonal scenarios and both can direct traffic across zones as needed (*cross-zone load-balancing*).
3427

3528
### Frontend
3629

3730
A Load Balancer frontend is a frontend IP configuration referencing either a public IP address resource or a private IP address within the subnet of a virtual network resource. It forms the load balanced endpoint where your service is exposed.
38-
3931
A Load Balancer resource can contain rules with zonal and zone-redundant frontends simultaneously.
40-
4132
When a public IP resource or a private IP address has been guaranteed to a zone, the zonality (or lack thereof) isn't mutable. If you wish to change or omit the zonality of a public IP or private IP address frontend, you need to recreate the public IP in the appropriate zone. Availability zones do not change the constraints for multiple frontend, review [multiple frontends for Load Balancer](load-balancer-multivip-overview.md) for details for this ability.
4233

43-
#### Zone redundant by default
44-
45-
In a region with availability zones, a Standard Load Balancer frontend is zone-redundant by default. Zone-redundant means that all inbound or outbound flows are served by multiple availability zones in a region simultaneously using a single IP address. DNS redundancy schemes aren't required. A single frontend IP address can survive zone failure and can be used to reach all (non-impacted) backend pool members irrespective of the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy. The frontend's single IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones. This doesn't mean hitless data path, but any retries or reestablishment will succeed in other zones not impacted by the zone failure.
46-
47-
The following excerpt is an illustration for how to define a public IP a zone-redundant Public IP address to use with your public Standard Load Balancer. If you're using existing Resource Manager templates in your configuration, add the **sku** section to these templates.
48-
49-
```json
50-
"apiVersion": "2017-08-01",
51-
"type": "Microsoft.Network/publicIPAddresses",
52-
"name": "public_ip_standard",
53-
"location": "region",
54-
"sku":
55-
{
56-
"name": "Standard"
57-
},
58-
```
59-
60-
The following excerpt is an illustration for how to define a zone-redundant frontend IP address for your internal Standard Load Balancer. If you're using existing Resource Manager templates in your configuration, add the **sku** section to these templates.
61-
62-
```json
63-
"apiVersion": "2017-08-01",
64-
"type": "Microsoft.Network/loadBalancers",
65-
"name": "load_balancer_standard",
66-
"location": "region",
67-
"sku":
68-
{
69-
"name": "Standard"
70-
},
71-
"properties": {
72-
"frontendIPConfigurations": [
73-
{
74-
"name": "zone_redundant_frontend",
75-
"properties": {
76-
"subnet": {
77-
"Id": "[variables('subnetRef')]"
78-
},
79-
"privateIPAddress": "10.0.0.6",
80-
"privateIPAllocationMethod": "Static"
81-
}
82-
},
83-
],
84-
```
85-
86-
The preceding excerpts are not complete templates but intended to show how to express availability zones properties. You need to incorporate these statements into your templates.
34+
#### Zone redundant
35+
36+
In a region with availability zones, a Standard Load Balancer frontend can be zone-redundant. Zone-redundant means that all inbound or outbound flows are served by multiple availability zones in a region simultaneously using a single IP address. DNS redundancy schemes aren't required. A single frontend IP address can survive zone failure and can be used to reach all (non-impacted) backend pool members irrespective of the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy. The frontend's single IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones. This doesn't mean hitless data path, but any retries or reestablishment will succeed in other zones not impacted by the zone failure.
8737

8838
#### Optional zone isolation
8939

@@ -97,49 +47,6 @@ For a public Load Balancer frontend, you add a *zones* parameter to the public I
9747

9848
For an internal Load Balancer frontend, add a *zones* parameter to the internal Load Balancer frontend IP configuration. The zonal frontend causes the Load Balancer to guarantee an IP address in a subnet to a specific zone.
9949

100-
The following excerpt is an illustration for how to define a zonal Standard Public IP address in Availability Zone 1. If you're using existing Resource Manager templates in your configuration, add the **sku** section to these templates.
101-
102-
```json
103-
"apiVersion": "2017-08-01",
104-
"type": "Microsoft.Network/publicIPAddresses",
105-
"name": "public_ip_standard",
106-
"location": "region",
107-
"zones": [ "1" ],
108-
"sku":
109-
{
110-
"name": "Standard"
111-
},
112-
```
113-
114-
The following excerpt is an illustration for how to define an internal Standard Load Balancer front end in Availability Zone 1. If you're using existing Resource Manager templates in your configuration, add the **sku** section to these templates. Also, define the **zones** property in the frontend IP configuration for the child resource.
115-
116-
```json
117-
"apiVersion": "2017-08-01",
118-
"type": "Microsoft.Network/loadBalancers",
119-
"name": "load_balancer_standard",
120-
"location": "region",
121-
"sku":
122-
{
123-
"name": "Standard"
124-
},
125-
"properties": {
126-
"frontendIPConfigurations": [
127-
{
128-
"name": "zonal_frontend_in_az1",
129-
"zones": [ "1" ],
130-
"properties": {
131-
"subnet": {
132-
"Id": "[variables('subnetRef')]"
133-
},
134-
"privateIPAddress": "10.0.0.6",
135-
"privateIPAllocationMethod": "Static"
136-
}
137-
},
138-
],
139-
```
140-
141-
The preceding excerpts are not complete templates but intended to show how to express availability zones properties. You need to incorporate these statements into your templates.
142-
14350
### Cross-zone Load-Balancing
14451

14552
Cross-zone load-balancing is the ability of Load Balancer to reach a backend endpoint in any zone and is independent of frontend and its zonality. Any load balancing rule can target backend instance in any availability zone or regional instances.
@@ -197,14 +104,6 @@ Avoid introducing unintended cross-zone dependencies, which will nullify availab
197104

198105
Review [Azure cloud design patterns](https://docs.microsoft.com/azure/architecture/patterns/) to improve the resiliency of your application to failure scenarios.
199106

200-
### <a name="zonalityguidance"></a> Zone-redundant versus zonal
201-
202-
Zone-redundant can provide a simplicity with a zone-agnostic option and at the same time resilient option with a single IP address for the service. It can reduce complexity in turn. Zone-redundant also has mobility across zones, and can be safely used on resources in any zone. Also, it's future proof in regions without availability zones, which can limit changes required once a region does gain availability zones. The configuration syntax for a zone-redundant IP address or frontend succeeds in any region including those without availability zones: a zone is not specified within the zones: property of the resource.
203-
204-
Zonal can provide an explicit guarantee to a zone, explicitly sharing fate with the health of the zone. Creating a Load Balancer rule with a zonal IP address frontend or zonal internal Load Balancer frontend can be a desirable especially if your attached resource is a zonal virtual machine in the same zone. Or perhaps your application requires explicit knowledge about which zone a resource is located in ahead of time and you wish to reason about availability in separate zones explicitly. You can choose to expose multiple zonal frontends for an end-to-end service distributed across zones (that is, per zone zonal frontends for multiple zonal virtual machine scale sets). And if your zonal frontends are public IP addresses, you can use these multiple zonal frontends for exposing your service with [Traffic Manager](../traffic-manager/traffic-manager-overview.md). Or you can use multiple zonal frontends to gain per zone health and performance insights through third party monitoring solutions and expose the overall service with a zone-redundant frontend. You should only serve zonal resources with zonal frontends aligned to the same zone and avoid potentially harmful cross-zone scenarios for zonal resources. Zonal resources only exist in regions where availability zones exist.
205-
206-
There's no general guidance that one is a better choice than the other without knowing the service architecture. Review [Azure cloud design patterns](https://docs.microsoft.com/azure/architecture/patterns/) to improve the resiliency of your application to failure scenarios.
207-
208107
## Next steps
209108
- Learn more about [Availability Zones](../availability-zones/az-overview.md)
210109
- Learn more about [Standard Load Balancer](load-balancer-standard-overview.md)

0 commit comments

Comments
 (0)