Skip to content

Commit e4b4011

Browse files
anavinaharanavinahar
authored
Update load-balancer-standard-availability-zones.md
1 parent 202d1da commit e4b4011

File tree

1 file changed

+0
-94
lines changed

1 file changed

+0
-94
lines changed

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

Lines changed: 0 additions & 94 deletions
Original file line numberDiff line numberDiff line change
@@ -28,56 +28,13 @@ Both public and internal Load Balancer support zone-redundant and zonal scenario
2828
### Frontend
2929

3030
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.
31-
3231
A Load Balancer resource can contain rules with zonal and zone-redundant frontends simultaneously.
33-
3432
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.
3533

3634
#### Zone redundant by default
3735

3836
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.
3937

40-
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.
41-
42-
```json
43-
"apiVersion": "2017-08-01",
44-
"type": "Microsoft.Network/publicIPAddresses",
45-
"name": "public_ip_standard",
46-
"location": "region",
47-
"sku":
48-
{
49-
"name": "Standard"
50-
},
51-
```
52-
53-
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.
54-
55-
```json
56-
"apiVersion": "2017-08-01",
57-
"type": "Microsoft.Network/loadBalancers",
58-
"name": "load_balancer_standard",
59-
"location": "region",
60-
"sku":
61-
{
62-
"name": "Standard"
63-
},
64-
"properties": {
65-
"frontendIPConfigurations": [
66-
{
67-
"name": "zone_redundant_frontend",
68-
"properties": {
69-
"subnet": {
70-
"Id": "[variables('subnetRef')]"
71-
},
72-
"privateIPAddress": "10.0.0.6",
73-
"privateIPAllocationMethod": "Static"
74-
}
75-
},
76-
],
77-
```
78-
79-
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.
80-
8138
#### Optional zone isolation
8239

8340
You can choose to have a frontend guaranteed to a single zone, which is known as a *zonal frontend*. This means any inbound or outbound flow is served by a single zone in a region. Your frontend shares fate with the health of the zone. The data path is unaffected by failures in zones other than where it was guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.
@@ -90,49 +47,6 @@ For a public Load Balancer frontend, you add a *zones* parameter to the public I
9047

9148
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.
9249

93-
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.
94-
95-
```json
96-
"apiVersion": "2017-08-01",
97-
"type": "Microsoft.Network/publicIPAddresses",
98-
"name": "public_ip_standard",
99-
"location": "region",
100-
"zones": [ "1" ],
101-
"sku":
102-
{
103-
"name": "Standard"
104-
},
105-
```
106-
107-
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.
108-
109-
```json
110-
"apiVersion": "2017-08-01",
111-
"type": "Microsoft.Network/loadBalancers",
112-
"name": "load_balancer_standard",
113-
"location": "region",
114-
"sku":
115-
{
116-
"name": "Standard"
117-
},
118-
"properties": {
119-
"frontendIPConfigurations": [
120-
{
121-
"name": "zonal_frontend_in_az1",
122-
"zones": [ "1" ],
123-
"properties": {
124-
"subnet": {
125-
"Id": "[variables('subnetRef')]"
126-
},
127-
"privateIPAddress": "10.0.0.6",
128-
"privateIPAllocationMethod": "Static"
129-
}
130-
},
131-
],
132-
```
133-
134-
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.
135-
13650
### Cross-zone Load-Balancing
13751

13852
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.
@@ -190,14 +104,6 @@ Avoid introducing unintended cross-zone dependencies, which will nullify availab
190104

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

193-
### <a name="zonalityguidance"></a> Zone-redundant versus zonal
194-
195-
Zone-redundant ensure high availability by ensuring your Standard Load balancer public frontend is replicated across all zones.This means your deployment will not share fate with the health of a single zone. Zone-redundant also has mobility across zones and can be safely used on resources in any zone.
196-
197-
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.
198-
199-
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.
200-
201107
## Next steps
202108
- Learn more about [Availability Zones](../availability-zones/az-overview.md)
203109
- Learn more about [Standard Load Balancer](load-balancer-standard-overview.md)

0 commit comments

Comments
 (0)