Azure Load Balancer 的多個前端Multiple frontends for Azure Load Balancer

Azure Load Balancer 可讓您平衡在多個連接埠、多個 IP 位址或兩者上的服務負載。Azure Load Balancer allows you to load balance services on multiple ports, multiple IP addresses, or both. 您可以使用公用和內部負載平衡器定義來負載平衡一組 VM 間的流量。You can use public and internal load balancer definitions to load balance flows across a set of VMs.

本文說明此功能的基本運用、重要概念和限制。This article describes the fundamentals of this ability, important concepts, and constraints. 如果您只想要公開一個 IP 位址上的服務,可以找到公用內部負載平衡器設定的簡易指示。If you only intend to expose services on one IP address, you can find simplified instructions for public or internal 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.

定義 Azure Load Balancer 時,前端和後端集區設定會與規則連線。When you define an Azure Load Balancer, a frontend and a backend pool configuration are connected with rules. 規則所參考的健全狀況探查是用來判斷新的流程如何傳送至後端集區中的節點。The health probe referenced by the rule is used to determine how new flows are sent to a node in the backend pool. 前端 (也稱為 VIP) 是由 IP 位址 (公用或內部)、傳輸通訊協定 (UDP 或 TCP),以及負載平衡規則中連接埠號碼組成的 3 項元素所定義。The frontend (aka VIP) 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. 後端集區是參考 Load Balancer 後端集區之虛擬機器 IP 設定的集合 (NIC 資源的一部分)。The backend pool is a collection of Virtual Machine IP configurations (part of the NIC resource) which reference the Load Balancer backend pool.

下表是一些範例前端設定:The following table contains some example frontend configurations:

前端Frontend IP 位址IP address protocolprotocol 連接埠port
11 65.52.0.165.52.0.1 TCPTCP 8080
22 65.52.0.165.52.0.1 TCPTCP 80808080
33 65.52.0.165.52.0.1 UDPUDP 8080
44 65.52.0.265.52.0.2 TCPTCP 8080

表中有四個不同的前端。The table shows four different frontends. #1、#2、#3 前端是具有多個規則的單一前端。Frontends #1, #2 and #3 are a single frontend with multiple rules. 使用相同的 IP 位址,但每個前端的連接埠或通訊協定不同。The same IP address is used but the port or protocol is different for each frontend. #1、#4 前端是多前端的範例,在多個前端上會重複使用相同的前端通訊協定和連接埠。Frontends #1 and #4 are an example of multiple frontends, where the same frontend protocol and port are reused across multiple frontends.

Azure Load Balancer 提供定義負載平衡規則的彈性。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:

  1. 預設規則,不會重複使用後端連接埠The default rule with no backend port reuse
  2. 浮動 IP 規則,會重複使用後端連接埠The Floating IP rule where backend ports are reused

Azure Load Balancer 允許您在同一負載平衡器設定上混用兩種規則類型。Azure Load Balancer allows you to mix both rule types on the same load balancer configuration. 負載平衡器可以對指定的 VM同時使用它們,或任何組合,只要您遵守規則的限制。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.

我們將從預設行為開始進一步探討這些案例。We explore these scenarios further by starting with the default behavior.

規則類型 #1︰不重複使用後端連接埠Rule type #1: No backend port reuse

具有綠色和紫色前端的多個前端圖解

在此案例中,前端的設定如下︰In this scenario, the frontends are configured as follows:

前端Frontend IP 位址IP address protocolprotocol 連接埠port
綠色前端 11 65.52.0.165.52.0.1 TCPTCP 8080
紫色前端 22 65.52.0.265.52.0.2 TCPTCP 8080

DIP 是輸入流量的目的地。The DIP is the destination of the inbound flow. 在後端集區中,每個 VM 會公開 DIP 上唯一連接埠上的所需服務。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.

我們定義兩個規則︰We define two rules:

規則Rule 對應前端Map frontend 至後端集區To backend pool
11 綠色前端 前端1:80Frontend1:80 綠色後端 DIP1:80,DIP1:80, 綠色後端 DIP2:80DIP2:80
22 VIP 前端2:80Frontend2:80 紫色後端 DIP1:81,DIP1:81, 紫色後端 DIP2:81DIP2:81

現在 Azure Load Balancer 的完整對應如下︰The complete mapping in Azure Load Balancer is now as follows:

規則Rule 前端 IP 位址Frontend IP address protocolprotocol 連接埠port DestinationDestination 連接埠port
綠色規則 11 65.52.0.165.52.0.1 TCPTCP 8080 DIP IP 位址DIP IP Address 8080
紫色規則 22 65.52.0.265.52.0.2 TCPTCP 8080 DIP IP 位址DIP IP Address 8181

每個規則都必須產生具有唯一組合 (目的地 IP 位址和目的地連接埠組合) 的流程。Each rule must produce a flow with a unique combination of destination IP address and destination port. 改變流量的目的地連接埠,多個規則就可以將流量傳送到不同連接埠上的相同 DIP。By varying the destination port of the flow, multiple rules can deliver flows to the same DIP on different ports.

健全狀況探查一律會被導向 VM 的 DIP。Health probes are always directed to the DIP of a VM. 您必須確定您的探查會反映 VM 的健全狀況。You must ensure you that your probe reflects the health of the VM.

規則類型 #2︰使用浮動 IP 來重複使用後端連接埠Rule type #2: backend port reuse by using Floating IP

Azure Load Balancer 提供在多個前端重複使用前端連接埠的彈性,不論使用何種規則類型。Azure Load Balancer provides the flexibility to reuse the frontend port across multiple frontends regardless of the rule type used. 此外,在某些應用程式案例中,後端集區中單一 VM 上的多個應用程式執行個體偏好或必須使用相同連接埠。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. 連接埠重複使用的常見範例包括提供高可用性的叢集、網路虛擬裝置、公開多個不會重新加密的 TLS 端點。Common examples of port reuse include clustering for high availability, network virtual appliances, and exposing multiple TLS endpoints without re-encryption.

如果您想要在多個規則重複使用後端連接埠,必須啟用規則定義中的浮動 IP。If you want to reuse the backend port across multiple rules, you must enable Floating IP in the rule definition.

「浮動 IP」是 Azure 術語,屬於伺服器直接回傳 (DSR) 的一部分。"Floating IP" is Azure's terminology for a portion of what is known as Direct Server Return (DSR). DSR 包含兩個部分︰流程拓樸和 IP 位址對應配置。DSR consists of two parts: a flow topology and an IP address mapping scheme. 在平台層級,Azure Load Balancer 一律在 DSR 流程拓撲中運作,無論是否已啟用浮動 IP。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.

使用預設規則類型時,Azure 會公開傳統負載平衡 IP 位址對應配置以利使用的方便性。With the default rule type, Azure exposes a traditional load balancing IP address mapping scheme for ease of use. 啟用浮動 IP 會變更 IP 位址對應配置,以提供更大的彈性,解釋如下。Enabling Floating IP changes the IP address mapping scheme to allow for additional flexibility as explained below.

下圖說明此設定:The following diagram illustrates this configuration:

具有綠色和紫色前端 (採用 DSR) 的多個前圖解

此案例中,後端集區中的每個 VM 有三個網路介面︰For this scenario, every VM in the backend pool has three network interfaces:

  • DIP:與 VM 相關聯的虛擬 NIC (Azure NIC 資源的 IP 組態)DIP: a Virtual NIC associated with the VM (IP configuration of Azure's NIC resource)
  • 前端 1︰客體 OS 內的回送介面 (此 OS 已設定了前端 1 的 IP 位址)Frontend 1: a loopback interface within guest OS that is configured with IP address of Frontend 1
  • 前端 2︰客體 OS 內的回送介面 (此 OS 已設定了前端 2 的 IP 位址)Frontend 2: a loopback interface within guest OS that is configured with IP address of Frontend 2

針對後端集區中的每個 VM,在 Windows 命令提示字元中執行下列命令。For each VM in the backend pool, run the following commands at a Windows Command Prompt.

若要取得您在 VM 上所擁有的介面名稱清單,請輸入下列命令:To get the list of interface names you have on your VM, type this command:

netsh interface show interface 

針對 (Azure 受控) 的 VM NIC,請輸入下列命令:For the VM NIC (Azure managed), type this command:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(將介面名稱取代為此介面的名稱) (replace interfacename with the name of this interface)

針對您新增的每個回送介面,重複下列命令:For each loopback interface you added, repeat these commands:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled 

(將介面名稱取代為此回送介面的名稱) (replace interfacename with the name of this loopback interface)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

(將介面名稱取代為此回送介面的名稱) (replace interfacename with the name of this loopback interface)

重要

回送介面的設定是在客體 OS 內進行。The configuration of the loopback interfaces is performed within the guest OS. 這項設定不是由 Azure 執行或管理。This configuration is not performed or managed by Azure. 沒有此設定,規則將無法運作。Without this configuration, the rules will not function. 健康狀態探查定義使用 VM 的 DIP,而不是代表 DSR 前端的回送介面。Health probe definitions use the DIP of the VM rather than the loopback interface representing the DSR Frontend. 因此,您的服務必須提供 DIP 連接埠的探查回應,以反映代表 DSR 前端之回送介面上所提供服務的狀態。Therefore, your service must provide probe responses on a DIP port that reflect the status of the service offered on the loopback interface representing the DSR Frontend.

讓我們假設前一個案例的相同前端組態︰Let's assume the same frontend configuration as in the previous scenario:

前端Frontend IP 位址IP address protocolprotocol 連接埠port
綠色前端 11 65.52.0.165.52.0.1 TCPTCP 8080
紫色前端 22 65.52.0.265.52.0.2 TCPTCP 8080

我們定義兩個規則︰We define two rules:

規則Rule 前端Frontend 對應至後端集區Map to backend pool
11 綠色規則 前端1:80Frontend1:80 綠色後端 前端1:80 (在 VM1 和 VM2 中)Frontend1:80 (in VM1 and VM2)
22 紫色規則 前端2:80Frontend2:80 紫色後端 前端2:80 (在 VM1 和 VM2 中)Frontend2:80 (in VM1 and VM2)

下表顯示負載平衡器的完整對應︰The following table shows the complete mapping in the load balancer:

規則Rule 前端 IP 位址Frontend IP address protocolprotocol 連接埠port DestinationDestination 連接埠port
綠色規則 11 65.52.0.165.52.0.1 TCPTCP 8080 與前端相同 (65.52.0.1)same as frontend (65.52.0.1) 與前端相同 (80)same as frontend (80)
紫色規則 22 65.52.0.265.52.0.2 TCPTCP 8080 與前端相同 (65.52.0.2)same as frontend (65.52.0.2) 與前端相同 (80)same as frontend (80)

輸入流量的目的地是在 VM 中回送介面上的前端 IP 位址。The destination of the inbound flow is the frontend IP address on the loopback interface in the VM. 每個規則都必須產生具有唯一組合 (目的地 IP 位址和目的地連接埠組合) 的流程。Each rule must produce a flow with a unique combination of destination IP address and destination port. 改變流量的目的地 IP 位址,就有可能在相同 VM 上重複使用連接埠。By varying the destination IP address of the flow, port reuse is possible on the same VM. 將您的服務繫結至前端的 IP 位址和個別回送介面的連接埠,即可會向負載平衡器公開服務。Your service is exposed to the load balancer by binding it to the frontend’s IP address and port of the respective loopback interface.

請注意,此範例沒有變更目的地連接埠。Notice that this example does not change the destination port. 雖然這是浮動 IP 案例,Azure Load Balancer 也支援定義規則來重寫後端的目的地連接埠,使其和前端的目的地連接埠不同。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.

浮動 IP 規則類型是數種負載平衡器設定模式的基礎。The Floating IP rule type is the foundation of several load balancer configuration patterns. 具有多個接聽程式的 SQL AlwaysOn 設定是目前可看到其運用的範例。One example that is currently available is the SQL AlwaysOn with Multiple Listeners configuration. 經過一段時間,我們會記載更多這類案例。Over time, we will document more of these scenarios.

限制Limitations

  • 只有 IaaS VM 支援多個前端組態。Multiple frontend configurations are only supported with IaaS VMs.
  • 使用浮動 IP 規則時,您的應用程式必須針對輸出 SNAT 流程使用主要 IP 設定。With the Floating IP rule, your application must use the primary IP configuration for outbound SNAT flows. 如果您的應用程式系結至在來賓 OS 的回送介面上設定的前端 IP 位址,則無法使用 Azure 的輸出 SNAT 來重寫輸出流程,而且流程會失敗。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.
  • 內部負載平衡案例的次要 IP 組態目前不支援浮動 IP。Floating IP is not currently supported on secondary IP configurations for Internal Load Balancing scenarios.
  • 公用 IP 位址需要費用。Public IP addresses have an effect on billing. 如需詳細資訊,請參閱 IP 位址定價For more information, see IP Address pricing
  • 訂用帳戶有其限制。Subscription limits apply. 如需詳細資訊,請參閱 服務限制 的說明。For more information, see Service limits for details.

下一步Next steps

  • 檢閱輸出連線,以了解多個前端對輸出連線行為的影響。Review Outbound connections to understand the impact of multiple frontends on outbound connection behavior.