Azure Load Balancer 分散モード
Azure Load Balancer は、バックエンド プール内のインスタンスに接続をルーティングするために、次の分散モードをサポートしています。
| 分散モード | ハッシュベース | セッション永続化: クライアント IP | セッション永続化: クライアント IP とプロトコル |
|---|---|---|---|
| 概要 | 同じクライアント IP からのトラフィックは、バックエンド プール内の正常なインスタンスにルーティングされます | 同じクライアント IP からのトラフィックは、同じバックエンド インスタンスにルーティングされます | 同じクライアント IP とプロトコルからのトラフィックは、同じバックエンド インスタンスにルーティングされます |
| タプル | 5 タプル | 2 タプル | 3 タプル |
| Azure portal の構成 | セッション永続化: なし | セッション永続化: クライアント IP | セッション永続化: クライアント IP とプロトコル |
| REST API | "loadDistribution":"Default" |
"loadDistribution":SourceIP |
"loadDistribution":SourceIPProtocol |
Load Balancer で 1 つのディストリビューション モードから別のディストリビューション モードに切り替える際にダウンタイムはありません。
ハッシュベース
Azure Load Balancer では、既定で 5 タプル ハッシュ ベースの分散モードが使用されます。
5 タプルの構成は次のとおりです。
- 発信元 IP
- ソース ポート
- 宛先 IP
- 宛先ポート
- プロトコルの種類
ハッシュは、バックエンド プール内の正常なバックエンド インスタンスにトラフィックをルーティングするために使用されます。 アルゴリズムでは、トランスポート セッション内でのみ持続性が提供されます。 クライアントが同じソース IP から新しいセッションを開始すると、接続元ポートが変更され、そのトラフィックは別のバックエンド インスタンスに送信されます。 ハッシュ ベースの分散を構成するには、Azure portal でセッション永続化に [なし] を選択する必要があります。 これは、同じクライアントからの連続した要求が、任意の仮想マシンによって処理できることを指定します。
図: 既定の 5 タプル ハッシュ ベースの分散
セッション永続化
セッション永続化は、セッション アフィニティ、ソース IP アフィニティ、またはクライアント IP アフィニティとも呼ばれます。 この分散モードは 2 タプル (ソース IP と接続先 IP) または 3 タプル (ソース IP、接続先 IP、プロトコルの種類) のハッシュを使用して、バックエンド インスタンスにルーティングします。 セッション永続化を使用する場合、同じクライアントからの接続は、バックエンド プール内の同じバックエンド インスタンスに送信されます。
セッションの永続化モードには、次の 2 種類の構成があります。
- クライアント IP (2 タプル) - 同じクライアント IP アドレスからの連続する要求が、同じバックエンド インスタンスによって処理されることを指定します。
- クライアント IP とプロトコル (3 タプル) - 同じクライアント IP アドレスとプロトコルの組み合わせからの連続する要求が、同じバックエンド インスタンスによって処理されることを指定します。
次の図は 2 タプルの構成を示しています。 2 タプルの場合に、どのように接続がロード バランサーを通過して仮想マシン 1 (VM1) に向かうかに注目してください。 VM1 は VM2 と VM3 でバックアップされます。
ユース ケース
クライアント IP とプロトコルによるソース IP アフィニティ (ソース IP アフィニティ 3 タプル) は、Azure Load Balancer とリモート デスクトップ ゲートウェイ (RD ゲートウェイ) 間の非互換性を解決します。
もう 1 つの使用シナリオは、メディア アップロードです。 データのアップロードを UDP 経由で行い、コントロール プレーンは TCP 経由で実現します。
- クライアントで、負荷分散されたパブリック アドレスに対する TCP セッションが開始され、特定の DIP に送られます。 チャネルは、接続の正常性を監視するためにアクティブのままになります。
- 同じクライアント コンピューターからの新しい UDP セッションが、負荷分散された同じパブリック エンドポイントに対して開始されます。 接続先は前回の TCP 接続と同じ DIP エンドポイントになります。 コントロール チャネルは TCP 経由で維持しつつ、メディア アップロードを高スループットで実行できます。
Note
仮想マシンの削除または追加によって Load Balancer のバックエンド プールのメンバーが変更された場合、クライアント要求の分散が再計算されます。 最終的に同じサーバーに接続する既存のクライアントからの新しい接続に依存することはできません。 また、ソース IP アフィニティ分散モードを使用すると、トラフィックが均等に分散されない可能性があります。 プロキシの背後で実行しているクライアントは、1 つの固有のクライアント アプリケーションと見なすことができます。
次のステップ
Azure Load Balancer の分散モードを構成する方法の詳細については、「Azure Load Balancer の分散モードを構成する」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示