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. 1 つの IP アドレスにのみサービスを公開する場合は、パブリックまたは内部ロード バランサーの構成に関する簡略化された手順が用意されています。If you only intend to expose services on one IP address, you can find simplified instructions for public or internal load balancer configurations. 複数フロントエンドの追加は、1 つのフロントエンド構成に対する増分です。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 バックエンド プールを参照する、Virtual Machine 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 portport
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

この表は、4 つの異なるフロントエンドを示します。The table shows four different frontends. フロントエンド #1、#2 および #3 は、複数の規則を持つ 1 つのフロントエンドです。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. 次の 2 つのタイプの規則があります。There are two types of rules:

  1. バックエンドのポートを再利用しない既定の規則The default rule with no backend port reuse
  2. バックエンドのポートが再利用される Floating 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 portport
緑のフロントエンド 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.

次の 2 つのルールを定義します。We define two rules:

ルールRule フロントエンドのマッピングMap frontend バックエンド プールへTo backend pool
11 緑のフロントエンド Frontend1:80Frontend1:80 バックエンド DIP1:80、DIP1:80, バックエンド DIP2:80DIP2:80
22 VIP Frontend2: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 portport 宛先Destination portport
緑の規則 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: Floating 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. さらに、一部のアプリケーション シナリオでは、バックエンド プール内の 1 つの 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.

複数の規則でバックエンド ポートを再利用するには、規則の定義で Floating IP を有効にする必要があります。If you want to reuse the backend port across multiple rules, you must enable Floating IP in the rule definition.

"Floating IP" は、Direct Server Return (DSR) と呼ばれるものの一部に対する Azure の用語です。"Floating IP" is Azure's terminology for a portion of what is known as Direct Server Return (DSR). DSR は、フロー トポロジーと IP アドレスのマッピング スキームの 2 つの部分で構成されます。DSR consists of two parts: a flow topology and an IP address mapping scheme. プラットフォーム レベルでは、Azure Load Balancer は Floating IP が有効かどうかに関係なく、常に DSR フロー トポロジで動作します。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. Floating 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 に次の 3 つのネットワーク インターフェイスがあります。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: フロントエンド 1 の IP アドレスで構成されているゲスト OS 内のループバック インターフェイスFrontend 1: a loopback interface within guest OS that is configured with IP address of Frontend 1
  • フロントエンド 2: フロントエンド 2 の IP アドレスで構成されているゲスト OS 内のループバック インターフェイス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 

VM NIC (Azure マネージド) には、次のコマンドを入力します。For the VM NIC (Azure managed), type this command:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(interfacename の部分をこのインターフェイスの名前に置き換えてください)(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 

(interfacename の部分をこのループバック インターフェイスの名前に置き換えてください)(replace interfacename with the name of this loopback interface)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

(interfacename の部分をこのループバック インターフェイスの名前に置き換えてください)(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. 正常性プローブの定義は、DSR フロントエンドを表すループバック インターフェイスではなく VM の DIP を使用します。Health probe definitions use the DIP of the VM rather than the loopback interface representing the DSR Frontend. したがって、お使いのサービスでは、DSR フロントエンドを表すループバック インターフェイスで提供されているサービスの状態を反映する、DIP ポートのプローブ応答を提供する必要があります。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 portport
緑のフロントエンド 11 65.52.0.165.52.0.1 TCPTCP 8080
紫のフロントエンド 22 65.52.0.265.52.0.2 TCPTCP 8080

次の 2 つのルールを定義します。We define two rules:

ルールRule フロントエンドFrontend バックエンド プールにマップMap to backend pool
11 ルール Frontend1:80Frontend1:80 バックエンド Frontend1:80 (VM1 と VM2)Frontend1:80 (in VM1 and VM2)
22 ルール Frontend2:80Frontend2:80 バックエンド Frontend2: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 portport 宛先Destination portport
緑の規則 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. これは Floating 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.

Floating IP 規則タイプは、いくつかのロード バランサーの構成パターンの基盤になります。The Floating IP rule type is the foundation of several load balancer configuration patterns. 現在利用できる例の 1 つは、 複数リスナーによる 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.
  • Floating 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 アドレスは課金に影響します。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.