第15章 Neutron LBaaSv2 API を使用した Load Balancing-as-a-Service の設定

Load Balancing-as-a-Service (LBaaS) は、OpenStack Networking が指定のインスタンス間で受信要求を均等に分散できるようにします。このステップバイステップのガイドでは、OpenStack Networking が Open vSwitch (OVS) プラグインで LBaas を使用するように設定します。

Red Hat OpenStack Platform 5 で導入された Load Balancing-as-a-Service (LBaaS) は、OpenStack Networking が指定のインスタンス間で受信要求を均等に分散できるようにします。これにより、インスタンス間でのワークロードが予測可能な方法で共有されるようになり、システムリソースのより効率的な使用が可能となります。受信要求は、以下の負荷分散メソッドの 1 つを使用して分散されます。

  • ラウンドロビン: 複数のインスタンス間で要求を均等にローテーションします。
  • 送信元 IP アドレス: 同じ送信元 IP アドレスからの要求は常に一定のインスタンスへ送信されます。
  • 最小コネクション: アクティブな接続が最も少ないインスタンスに要求が割り当てられます。

表15.1 LBaaS の機能

機能説明

監視機能

LBaaS は、PING、TCP、HTTP、HTTPS GET メソッドを使用した可用性モニタリング機能を提供します。モニターは、要求の処理にプールメンバーが利用可能かどうかを判断するために実装されます。

管理

LBaaS は、さまざまなツールセットを使用して管理されます。REST API は、プログラムベースの管理およびスクリプト作成に使用できます。ユーザーは、CLI (neutron) または OpenStack Dashboard のいずれかを使用して、ロードバランサーの管理タスクを行います。

接続制限

接続制限を使用して、受信トラフィックのシェーピングを行うことができます。この機能は、ワークロードを制御することも可能で、DoS (Denial of Service) 攻撃の緩和にも有効です。

セッションの永続化

LBaaS は、複数のインスタンスで構成されるプール内で同じインスタンスに受信要求がルーティングされるようにすることで、セッションの永続化をサポートします。LBaaS は、クッキーや送信元 IP アドレスに基づいたルーティングの決定をサポートします。

注記

LBaaS は現在 IPv4 アドレスのみサポートします。

注記

LBaaSv1 は Red Hat OpenStack Platform 11 (Ocata) で削除され、LBaaSv2 に置き換えられました。

15.1. OpenStack Networking および LBaaS トポロジー

OpenStack Networking (neutron) サービスは、大きく 2 つのカテゴリーに分類することができます。

1. Neutron API server: このサービスは、エンドユーザーとサービスが OpenStack Networking と対話できるように、主に API を提供する OpenStack Networking API サーバーを実行します。またこのサービスは、基盤のデータベースと対話して、テナントネットワーク、ルーター、ロードバランサーの詳細などを保存する役割も果たします。

2. Neutron エージェント: OpenStack Networking のさまざまな機能を提供するサービスです。

  • neutron-dhcp-agent: テナントプライベートネットワークの DHCP IP アドレスを管理します。
  • neutron-l3-agent: テナントプライベートネットワーク、外部ネットワークなどの間のレイヤー 3 ルーティングを容易化します。
  • neutron-lbaasv2-agent: テナントにより作成された LBaaS ルーターをプロビジョニングします。
注記

neutron-lbassv2-agent (HAProxy を使用) は非推奨となりました。Octavia を使用したロードバランシングの推奨されるリファレンス実装については、「16章Octavia を使用した Load Balancing-as-a-Service (LBaaS)」を参照してください。

以下の図には、HTTPS トラフィックからプールメンバーへのフローを示しています。

lbaas

15.1.1. LBaaS のサポートステータス

  • LBaaS v1 API は、バージョン 10 で削除されました。
  • LBaaS v2 API は Red Hat OpenStack Platform 7 で導入されました。これは、バージョン 10 で提供されている唯一の LBaaS API です。
  • LBaaS デプロイメントは現在 Red Hat OpenStack Platform director ではサポートされていません。
注記

neutron-lbassv2-agent (HAProxy を使用) は非推奨となり、サポートされなくなりました。Octavia を使用したロードバランシングの推奨されるリファレンス実装については、「16章Octavia を使用した Load Balancing-as-a-Service (LBaaS)」を参照してください。neutron-lbaas RPM は、サードパーティーのプラグインに対応するための API をサポートするために、現在も提供されています。

15.1.2. サービスの配置

OpenStack Networking Service は、同じ物理サーバーまたは別の専用サーバーで実行することができます。

注記

Red Hat OpenStack Platform 11 では、コンポーザブルロールのサポートが追加され、ネットワークサービスをカスタムロール別に分類することができます。ただし、本ガイドでは、内容をわかりやすくするために、デプロイメントにはデフォルトのコントローラーノードを使用することを前提とします。

API サーバーを実行するサーバーは通常、コントローラーノード と呼ばれ、OpenStack Networking エージェントを実行するサーバーは Network node と呼ばれます。理想的な実稼動環境では、パフォーマンスやスケーラビリティーの理由により、コンポーネントを専用のノードに分類しますが、テストまたは PoC デプロイメントではすべてのコンポーネントを 1 つの同じノードで実行します。本章では、どちらのシナリオにも対応しますが、コントローラーノードの設定のセクションは API サーバーで、ネットワークノードのセクションは LBaaS エージェントを実行するサーバーで行う必要があります。

注記

コントローラーおよびネットワークロールの両方が同じ物理ノードに存在する場合には、この物理ノード (サーバー) で手順を実行する必要があります。