Skip to content

Commit dd060f1

Browse files
committed
Updates and new Images
1 parent 1f944c6 commit dd060f1

File tree

3 files changed

+27
-29
lines changed

3 files changed

+27
-29
lines changed

articles/load-balancer/load-balancer-multivip-overview.md

Lines changed: 27 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -15,11 +15,11 @@ ms.author: mbender
1515

1616
# Multiple frontends for Azure Load Balancer
1717

18-
Azure Load Balancer allows you to load balance services on multiple ports, multiple IP addresses, or both. You can use a public or internal load balancer to load balance traffic across a set of services like virtual machine scale sets (VMSS) or virtual machines (VMs).
18+
Azure Load Balancer allows you to load balance services on multiple ports, multiple IP addresses, or both. You can use a public or internal load balancer to load balance traffic across a set of services like virtual machine scale sets or virtual machines (VMs).
1919

2020
This article describes the fundamentals of load balancing across multiple IP addresses using the same port and protocol. If you only intend to expose services on one IP address, you can find simplified instructions for [public](./quickstart-load-balancer-standard-public-portal.md) or [internal](./quickstart-load-balancer-standard-internal-portal.md) load balancer configurations. Adding multiple frontends is incremental to a single frontend configuration. Using the concepts in this article, you can expand a simplified configuration at any time.
2121

22-
When you define an Azure Load Balancer, a frontend and a backend pool configuration are connected with a load balancing rule. The health probe referenced by the load balancing rule is used to determine the health of a VM on a certain port and protocol. Based on the health probe results, new flows are sent to VMs in the backend pool. The frontend is defined by a 3-tuple comprised of an IP address (public or internal), a transport protocol (UDP or TCP), and a port number from the load balancing rule. The backend pool is a collection of Virtual Machine IP configurations (part of the NIC resource) which reference the Load Balancer backend pool.
22+
When you define an Azure Load Balancer, a frontend and a backend pool configuration are connected with a load balancing rule. The health probe referenced by the load balancing rule is used to determine the health of a VM on a certain port and protocol. Based on the health probe results, new flows are sent to VMs in the backend pool. The frontend is defined by a three-tuple comprised of an IP address (public or internal), a transport protocol (UDP or TCP), and a port number from the load balancing rule. The backend pool is a collection of Virtual Machine IP configurations (part of the NIC resource) which reference the Load Balancer backend pool.
2323

2424
The following table contains some example frontend configurations:
2525

@@ -30,16 +30,14 @@ The following table contains some example frontend configurations:
3030
| 3 |65.52.0.1 |*UDP* |80 |
3131
| 4 |*65.52.0.2* |TCP |80 |
3232

33-
The table shows four different frontends. Frontends #1, #2 and #3 are a single frontend with multiple rules. The same IP address is used but the port or protocol is different for each frontend. Frontends #1 and #4 are an example of multiple frontends, where the same frontend protocol and port are reused across multiple frontends.
33+
The table shows four different frontend configurations. Frontends #1, #2 and #3 use the same IP address but the port or protocol is different for each frontend. Frontends #1 and #4 are an example of multiple frontends, where the same frontend protocol and port are reused across multiple frontend IPs.
3434

35-
Azure Load Balancer provides flexibility in defining the load balancing rules. A rule declares how an address and port on the frontend is mapped to the destination address and port on the backend. Whether or not backend ports are reused across rules depends on the type of the rule. Each type of rule has specific requirements that can affect host configuration and probe design. There are two types of rules:
35+
Azure Load Balancer provides flexibility in defining the load balancing rules. A load balancing rule declares how an address and port on the frontend is mapped to the destination address and port on the backend. Whether or not backend ports are reused across rules depends on the type of the rule. Each type of rule has specific requirements that can affect host configuration and probe design. There are two types of rules:
3636

37-
1. The default rule with no backend port reuse
38-
2. The Floating IP rule where backend ports are reused
37+
1. The default rule with no backend port reuse.
38+
2. The Floating IP rule where backend ports are reused.
3939

40-
Azure Load Balancer allows you to mix both rule types on the same load balancer configuration. The load balancer can use them simultaneously for a given VM, or any combination, as long as you abide by the constraints of the rule. Which rule type you choose depends on the requirements of your application and the complexity of supporting that configuration. You should evaluate which rule types are best for your scenario.
41-
42-
We explore these scenarios further by starting with the default behavior.
40+
Azure Load Balancer allows you to mix both rule types on the same load balancer configuration. The load balancer can use them simultaneously for a given VM, or any combination, if you abide by the constraints of the rule. The rule type you choose depends on the requirements of your application and the complexity of supporting that configuration. You should evaluate which rule types are best for your scenario. We'll explore these scenarios further by starting with the default behavior. We explore these scenarios further by starting with the default behavior.
4341

4442
## Rule type #1: No backend port reuse
4543

@@ -52,43 +50,43 @@ In this scenario, the frontends are configured as follows:
5250
| ![green frontend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) 1 |65.52.0.1 |TCP |80 |
5351
| ![purple frontend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) 2 |*65.52.0.2* |TCP |80 |
5452

55-
The DIP is the destination of the inbound flow. In the backend pool, each VM exposes the desired service on a unique port on a DIP. This service is associated with the frontend through a rule definition.
53+
The backend instance IP (BIP) is the IP address of the backend service in the backend pool, each VM exposes the desired service on a unique port on the backend instance IP. This service is associated with the frontend through a rule definition.
5654

5755
We define two rules:
5856

5957
| Rule | Map frontend | To backend pool |
6058
| --- | --- | --- |
61-
| 1 |![green frontend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) Frontend1:80 |![green backend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) DIP1:80, ![green backend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) DIP2:80 |
62-
| 2 |![VIP](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) Frontend2:80 |![purple backend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) DIP1:81, ![purple backend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) DIP2:81 |
59+
| 1 |![green frontend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) Frontend1:80 |![green backend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) BIP1:80, ![green backend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) BIP2:80 |
60+
| 2 |![VIP](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) Frontend2:80 |![purple backend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) BIP1:81, ![purple backend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) BIP2:81 |
6361

6462
The complete mapping in Azure Load Balancer is now as follows:
6563

6664
| Rule | Frontend IP address | protocol | port | Destination | port |
6765
| --- | --- | --- | --- | --- | --- |
68-
| ![green rule](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) 1 |65.52.0.1 |TCP |80 |DIP IP Address |80 |
69-
| ![purple rule](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) 2 |65.52.0.2 |TCP |80 |DIP IP Address |81 |
66+
| ![green rule](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) 1 |65.52.0.1 |TCP |80 |BIP IP Address |80 |
67+
| ![purple rule](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) 2 |65.52.0.2 |TCP |80 |BIP IP Address |81 |
7068

71-
Each rule must produce a flow with a unique combination of destination IP address and destination port. By varying the destination port of the flow, multiple rules can deliver flows to the same DIP on different ports.
69+
Each rule must produce a flow with a unique combination of destination IP address and destination port. Multiple load balancing rules can deliver flows to the same backend instance IP on different ports by varying the destination port of the flow.
7270

73-
Health probes are always directed to the DIP of a VM. You must ensure that your probe reflects the health of the VM.
71+
Health probes are always directed to the backend instance IP of a VM. You must ensure that your probe reflects the health of the VM.
7472

7573
## Rule type #2: backend port reuse by using Floating IP
7674

77-
Azure Load Balancer provides the flexibility to reuse the frontend port across multiple frontends regardless of the rule type used. Additionally, some application scenarios prefer or require the same port to be used by multiple application instances on a single VM in the backend pool. Common examples of port reuse include clustering for high availability, network virtual appliances, and exposing multiple TLS endpoints without re-encryption.
75+
Azure Load Balancer provides the flexibility to reuse the frontend port across multiple frontends configurations. Additionally, some application scenarios prefer or require the same port to be used by multiple application instances on a single VM in the backend pool. Common examples of port reuse include clustering for high availability, network virtual appliances, and exposing multiple TLS endpoints without re-encryption.
7876

79-
If you want to reuse the backend port across multiple rules, you must enable Floating IP in the rule definition.
77+
If you want to reuse the backend port across multiple rules, you must enable Floating IP in the load balancing rule definition.
8078

81-
"Floating IP" is Azure's terminology for a portion of what is known as Direct Server Return (DSR). DSR consists of two parts: a flow topology and an IP address mapping scheme. At a platform level, Azure Load Balancer always operates in a DSR flow topology regardless of whether Floating IP is enabled or not. This means that the outbound part of a flow is always correctly rewritten to flow directly back to the origin.
79+
*Floating IP* is Azure's terminology for a portion of what is known as Direct Server Return (DSR). DSR consists of two parts: a flow topology and an IP address mapping scheme. At a platform level, Azure Load Balancer always operates in a DSR flow topology regardless of whether Floating IP is enabled or not. This means that the outbound part of a flow is always correctly rewritten to flow directly back to the origin.
8280

83-
With the default rule type, Azure exposes a traditional load balancing IP address mapping scheme for ease of use. Enabling Floating IP changes the IP address mapping scheme to allow for additional flexibility as explained below.
81+
With the default rule type, Azure exposes a traditional load balancing IP address mapping scheme for ease of use. Enabling Floating IP changes the IP address mapping scheme to allow for more flexibility as explained below.
8482

85-
The following diagram illustrates this configuration:
83+
The following diagram illustrates floating IP configuration:
8684

8785
![Multiple frontend illustration with green and purple frontend with DSR](./media/load-balancer-multivip-overview/load-balancer-multivip-dsr.png)
8886

8987
For this scenario, every VM in the backend pool has three network interfaces:
9088

91-
* DIP: a Virtual NIC associated with the VM (IP configuration of Azure's NIC resource)
89+
* Backend IP: a Virtual NIC associated with the VM (IP configuration of Azure's NIC resource)
9290
* Frontend 1: a loopback interface within guest OS that is configured with IP address of Frontend 1
9391
* Frontend 2: a loopback interface within guest OS that is configured with IP address of Frontend 2
9492

@@ -99,7 +97,7 @@ Let's assume the same frontend configuration as in the previous scenario:
9997
| ![green frontend](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) 1 |65.52.0.1 |TCP |80 |
10098
| ![purple frontend](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) 2 |*65.52.0.2* |TCP |80 |
10199

102-
We define two rules:
100+
We define two floating IP rules:
103101

104102
| Rule | Frontend | Map to backend pool |
105103
| --- | --- | --- |
@@ -113,23 +111,23 @@ The following table shows the complete mapping in the load balancer:
113111
| ![green rule](./media/load-balancer-multivip-overview/load-balancer-rule-green.png) 1 |65.52.0.1 |TCP |80 |same as frontend (65.52.0.1) |same as frontend (80) |
114112
| ![purple rule](./media/load-balancer-multivip-overview/load-balancer-rule-purple.png) 2 |65.52.0.2 |TCP |80 |same as frontend (65.52.0.2) |same as frontend (80) |
115113

116-
The destination of the inbound flow is the frontend IP address on the loopback interface in the VM. Each rule must produce a flow with a unique combination of destination IP address and destination port. By varying the destination IP address of the flow, port reuse is possible on the same VM. Your service is exposed to the load balancer by binding it to the frontend’s IP address and port of the respective loopback interface.
114+
The destination of the inbound flow is now the frontend IP address on the loopback interface in the VM. Each rule must produce a flow with a unique combination of destination IP address and destination port. Port reuse is possible on the same VM by varying the destination IP address to the frontend IP address of the flow. Your service is exposed to the load balancer by binding it to the frontend’s IP address and port of the respective loopback interface.
117115

118-
Notice that this example does not change the destination port. Even though this is a Floating IP scenario, Azure Load Balancer also supports defining a rule to rewrite the backend destination port and to make it different from the frontend destination port.
116+
You'll notice the destination port doesn't change in the example. In floating IP scenarios, Azure Load Balancer also supports defining a load balancing rule to change the backend destination port and to make it different from the frontend destination port.
119117

120-
The Floating IP rule type is the foundation of several load balancer configuration patterns. One example that is currently available is the [Configure one or more Always On availability group listeners](/azure/azure-sql/virtual-machines/windows/availability-group-listener-powershell-configure) configuration. Over time, we will document more of these scenarios.
118+
The Floating IP rule type is the foundation of several load balancer configuration patterns. One example that is currently available is the [Configure one or more Always On availability group listeners](/azure/azure-sql/virtual-machines/windows/availability-group-listener-powershell-configure) configuration. Over time, we'll document more of these scenarios.
121119

122120
> [!NOTE]
123121
> For more detailed information on the specific Guest OS configurations required to enable Floating IP, please refer to [Azure Load Balancer Floating IP configuration](load-balancer-floating-ip.md).
124122
125123
## Limitations
126124

127125
* Multiple frontend configurations are only supported with IaaS VMs and virtual machine scale sets.
128-
* With the Floating IP rule, your application must use the primary IP configuration for outbound SNAT flows. If your application binds to the frontend IP address configured on the loopback interface in the guest OS, Azure's outbound SNAT is not available to rewrite the outbound flow and the flow fails. Review [outbound scenarios](load-balancer-outbound-connections.md).
129-
* Floating IP is not currently supported on secondary IP configurations.
126+
* With the Floating IP rule, your application must use the primary IP configuration for outbound SNAT flows. If your application binds to the frontend IP address configured on the loopback interface in the guest OS, Azure's outbound SNAT won't rewrite the outbound flow, and the flow fails. Review [outbound scenarios](load-balancer-outbound-connections.md).
127+
* Floating IP isn't currently supported on secondary IP configurations.
130128
* Public IP addresses have an effect on billing. For more information, see [IP Address pricing](https://azure.microsoft.com/pricing/details/ip-addresses/)
131129
* Subscription limits apply. For more information, see [Service limits](../azure-resource-manager/management/azure-subscription-service-limits.md#networking-limits) for details.
132130

133131
## Next steps
134132

135-
- Review [Outbound connections](load-balancer-outbound-connections.md) to understand the impact of multiple frontends on outbound connection behavior.
133+
- Review [Outbound connections](load-balancer-outbound-connections.md) to understand the effect of multiple frontends on outbound connection behavior.
-11.6 KB
Loading
-11.1 KB
Loading

0 commit comments

Comments
 (0)