Load Balancing-as-a-Service を提供する octavia の使用

Red Hat OpenStack Platform 16.2

データプレーン上のネットワークトラフィックの負荷を分散させつ方法についての情報

概要

RHOSP Load-balancing サービス (octavia) のインストール、設定、操作、トラブルシューティング、およびアップグレードに関するガイドです。

前書き

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 Load-balancing サービスについて

Load-balancing サービス (octavia) は、Red Hat OpenStack Platform (RHOSP) のデプロイメントに対して、Load Balancing-as-a-Service (LBaaS) API バージョン 2 の実装を提供します。

本項では、Load-balancing サービスを紹介し、負荷分散が RHOSP の残りの部分とどのように統合するか、およびさまざまな負荷分散コンポーネントについて説明します。

1.1. Load-balancing サービスとは

Load-balancing サービス (octavia) は、Red Hat OpenStack Platform (RHOSP) のデプロイメントに対して、Load Balancing-as-a-Service (LBaaS) API バージョン 2 の実装を提供します。Load-balancing サービスは、amphora として知られる仮想マシン、コンテナー、またはベアメタルサーバーの集合を管理し、これらをオンデマンドで起動します。オンデマンドの水平スケーリングを提供する機能により、Load-balancing サービスはフル機能のロードバランサーで、大規模な RHOSP のエンタープライズデプロイメントに適しています。

注記

Red Hat では、Neutron-LBaaS から octavia への移行パスをサポートしていません。ただし、サポート対象外のオープンソースツールを利用することが可能です。以下の「関連資料」を参照してください。

1.2. Load-balancing サービスのコンポーネント

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) は、コンピュートノード上で実行される amphora と呼ばれる仮想マシンインスタンスのセットを使用します。Load-balancing サービスコントローラーは、負荷分散管理ネットワーク (lb-mgmt-net) を使用して amphora と通信します。

Octavia の概念図

Load-balancing サービスのさまざまなコンポーネントは、Networking API サーバーと同じノード上でホストされます。デフォルトでは、コントローラーノード上にあります。Load-balancing サービスは以下で構成されます。

octavia API (octavia_api コンテナー)
ユーザーが octavia と対話するための REST API を提供します。
コントローラーワーカー (octavia_worker コンテナー)
負荷分散管理ネットワークを通じて、設定および設定の更新を amphora に送信します。
ヘルスマネージャー (octavia_health_manager コンテナー)
個々の amphora の正常性を監視し、amphora で障害が発生した場合にはフェイルオーバーイベントを処理します。
ハウスキーピングマネージャー (octavia_housekeeping コンテナー)
古い (削除済みの) データベースレコードをクリーンアップし、amphora の証明書のローテーションを管理します。
ドライバーエージェント (octavia_driver_agentコンテナー)
OVN などの他のプロバイダードライバーをサポートします。
amphora
負荷分散を行う仮想マシンインスタンス。amphora は、通常コンピュートノード上で実行されるインスタンスで、リスナー、プール、ヘルスモニター、L7 ポリシー、メンバーの設定に応じた負荷分散パラメーターにより設定されます。amphora はヘルスマネージャーに定期的なハートビートを送信します。

1.3. Load-balancing サービスのオブジェクトモデル

The Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) は、従来の負荷分散オブジェクトモデルを使用します。

Octavia オブジェクトモデルの図
ロードバランサー
負荷分散エンティティーを表す最上位の API オブジェクト。仮想 IP アドレスは、ロードバランサーの作成時に確保されます。amphora プロバイダーを使用してロードバランサーを作成すると、1 つまたは複数の amphora インスタンスが 1 つまたは複数のコンピュートノードで起動します。
リスナー
ロードバランサーがリッスンするポート (例: HTTP の場合は TCP ポート 80)
ヘルスモニター
各バックエンドメンバーサーバーで定期的なヘルスチェックを実行するプロセスで、障害が発生したサーバーを事前検出し、それらをプールから一時的に除外します。
プール
ロードバランサー (amphora) からのクライアント要求を処理するメンバーのグループ。プールは、API を使用して複数のリスナーに割り当てることができます。プールは、L7 ポリシーと共有することもできます。
メンバー
バックエンドインスタンスまたはサービスに接続する方法を説明します。この説明は、バックエンドメンバーが利用できる IP アドレスとネットワークポートで構成されます。
L7 ルール
レイヤー 7 (L7) ポリシーを接続に適用するかどうかを判断するために使用される L7 条件を定義します。
L7 ポリシー
リスナーと関連付けられた L7 ルールの集合。また、バックエンドプールとも関連付けられる場合があります。ポリシーは、ポリシー内のすべてのルールが満たされた場合にロードバランサーが実行するアクションを記述します。

1.4. Load-balancing と Red Hat OpenStack Platform の連携

負荷分散は、クラウドデプロイメントにおけるシンプルまたは自動配信のスケーリングおよび可用性を可能にする上で不可欠です。Load balancing サービス (octavia) は、さまざまな機能に関して他の Red Hat OpenStack Platform (RHOSP) のサービスに依存します。

  • Compute サービス (nova): Load-balancing サービスの仮想マシンインスタンス (amphora) のライフサイクルを管理し、オンデマンドでコンピュートリソースを起動します。
  • Networking サービス (neutron): Load-balancing サービスのインスタンス (amphora)、テナント環境、および外部ネットワーク間のネットワーク接続用
  • Key Manager サービス (barbican): TLS セッションの終了がリスナーに設定されている場合に、TLS 証明書および認証情報を管理します。
  • Identity サービス (keystone): octavia API への認証リクエスト、および octavia を他の RHOSP サービスに対して認証する場合
  • Image サービス (glance): amphora 仮想マシンイメージを保存します。
  • Common Libraries (oslo): octavia コントローラーコンポーネント間の通信用。これにより、octavia が標準の OpenStack フレームワーク内で機能し、システムおよびプロジェクトコード構造を確認します。
  • Taskflow: 技術的には oslo の一部ですが、バックエンドサービスの設定および管理をオーケストレーションする際に、octavia はこのジョブフローシステムをさまざまに活用します。

Load-balancing サービスはドライバーインターフェースを介して他の RHOSP サービスと対話し、外部コンポーネントを機能的に同等なサービスに置き換えなければならない場合に、octavia の大規模な再構築を防ぎます。

第2章 Load-balancing サービスのプランニング

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) のデプロイを計画する場合、さまざまなタスクを実行する必要があります。

  • Load-balancing サービスで使用するプロバイダーを選択する、複数のプロバイダーを同時に有効にするかどうかを選択する
  • Load-balancing サービスが必要とするソフトウェアを理解する
  • RHOSP アンダークラウドが必要な前提条件を満たしていることを確認する
  • Load-balancing サービスを高可用性にするかどうかを決定する

2.1. Load-balancing サービスプロバイダードライバー

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) では、octavia v2 API を使用して複数のプロバイダードライバーを有効にすることができます。1 つのプロバイダードライバーを使用するか、複数のプロバイダードライバーを同時に使用するかを選択することができます。

RHOSP では、amphora と Open Virtual Network (OVN) という 2 つの負荷分散プロバイダーを利用することができます。

デフォルトの amphora は可用性に優れたロードバランサーで、実際のコンピュート環境に対応する豊富な機能セットが用意されています。このため、amphora は大規模なデプロイメントに適しています。

OVN 負荷分散プロバイダーは、基本的な機能セットを持つ軽量ロードバランサーです。通常、East-West レイヤー 4 ネットワークトラフィックに使用され、OVN は素早くプロビジョニングし、amphora 等のフル機能の負荷分散プロバイダーほどリソースを消費しません。

neutron Modular Layer 2 プラグインと OVN メカニズムドライバーの組み合わせ (ML2/OVN) を使用する RHOSP デプロイメントでは、RHOSP director は Load-balancing サービス (octavia) で OVN プロバイダードライバーを自動的に有効にします。追加のインストールや設定のステップは必要ありません。すべての RHOSP デプロイメントと同様に、デフォルトの負荷分散プロバイダードライバーである amphora は引き続き有効で、完全にサポートされます。

重要

本項の手順は、特に明記しない限り、amphora 負荷分散プロバイダーにのみ適用 されます。

2.2. Load-balancing サービス (octavia) 機能のサポートマトリックス

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) では、amphora と Open Virtual Network (OVN) という 2 つの負荷分散プロバイダーを利用することができます。

amphora は、豊富な機能セットを持つフル機能の負荷分散プロバイダーですが、個別の haproxy 仮想マシンと追加のレイテンシーホップが必要です。

OVN はすべてのノードで実行され、別の仮想マシンや追加のホップは必要ありません。ただし、OVN には、amphora よりもはるかに少ない負荷分散機能しかありません。

以下の表は、Red Hat OpenStack Platform (RHOSP) 16.1 がサポートする octavia の機能と、機能のサポートが開始されたメンテナンスリリースを一覧にして示しています。

注記

機能が一覧にない場合、RHOSP 16.1 はその機能をサポートしません。

表2.1 Load-balancing サービス (octavia) 機能のサポートマトリックス

機能

RHOSP 16.1 でのサポートレベル

amphora プロバイダー

OVN プロバイダー

ML2/OVS L3 HA

フルサポート

サポートなし

ML2/OVS DVR

フルサポート

サポートなし

ML2/OVS L3 HA とコンポーザブルネットワークノードの組み合わせ [1]

フルサポート

サポートなし

ML2/OVS DVR とコンポーザブルネットワークノードの組み合わせ [1]

フルサポート

サポートなし

ML2/OVN L3 HA

フルサポート

フルサポート

ML2/OVN DVR

フルサポート

フルサポート

ヘルスモニター

フルサポート

サポートなし

amphora アクティブ/スタンバイ

フルサポート: 16.1 以降

サポートなし

HTTPS 終端ロードバランサー (barbican を使用)

フルサポート: 16.0.1 以降

サポートなし

amphora 予備プール

テクノロジープレビューとしてのみ提供

サポートなし

UDP

フルサポート: 16.1 以降

フルサポート

バックアップメンバー

テクノロジープレビューとしてのみ提供

サポートなし

プロバイダーフレームワーク

テクノロジープレビューとしてのみ提供

サポートなし

TLS クライアント認証

テクノロジープレビューとしてのみ提供

サポートなし

TLS バックエンド暗号化

テクノロジープレビューとしてのみ提供

サポートなし

Octavia フレーバー

フルサポート

サポートなし

オブジェクトタグ: API のみ

フルサポート: 16.1 以降

サポートなし

リスナー API タイムアウト

フルサポート

サポートなし

ログのオフロード

フルサポート: 16.1.2 以降

サポートなし

仮想 IP アクセス制御リスト

フルサポート

サポートなし

ボリュームベースの amphora

サポートなし

サポートなし

[1] ネットワークノードと OVS、メタデータ、DHCP、L3、および octavia (ワーカー、ヘルスモニター、およびハウスキーピング) の組み合わせ

2.3. Load-balancing サービスのソフトウェア要件

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) には、以下の OpenStack コアコンポーネントの設定が必要です。

  • Compute (nova)
  • OpenStack Networking (neutron)
  • Image (glance)
  • Identity (keystone)
  • RabbitMQ
  • MySQL

2.4. アンダークラウドでの Load-balancing サービスの前提条件

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) には、RHOSP アンダークラウドに対する以下の要件があります。

  • アンダークラウドがインストール済みで、Load-balancing サービス (octavia) を有効にしてオーバークラウドをデプロイする準備が整っている。
  • コンテナーベースのデプロイメントのみがサポートされる。
  • Load-balancing サービスがコントローラーノード上で実行される。
重要

既存のオーバークラウドデプロイメントで Load-balancing サービスを有効にする場合には、アンダークラウドを準備する必要があります。準備を行わないと、Load-balancing サービスが動作していない状態でオーバークラウドのインストールは成功と報告されます。アンダークラウドを準備するには、『コンテナー化されたサービスへの移行』を参照してください (以下の「関連資料」のリンクを参照してください)。

2.5. Load-balancing サービスインスタンスのアクティブ/スタンバイトポロジーの基本

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) をデプロイする場合には、ユーザーがロードバランサーを作成する際に、デフォルトで高可用性であるかどうかを決定することができます。ユーザーに選択肢を与えたい場合は、RHOSP のデプロイメント後に、高可用性ロードバランサーを作成するための Load-balancing サービスフレーバー、およびスタンドアロンロードバランサーを作成するためのフレーバーを作成します。

デフォルトでは、amphora プロバイダードライバーは単一の Load-balancing サービス (amphora) インスタンストポロジーに対して設定され、高可用性 (HA) のサポートは限定的です。ただし、アクティブ/スタンバイのトポロジーを実装すると、Load-balancing サービスインスタンスを高可用性の構成にすることが可能です。

このトポロジーでは、Load-balancing サービスは各ロードバランサーに対してアクティブおよびスタンバイ状態のインスタンスを起動し、ロードバランサー間でセッションの永続性を維持します。アクティブなインスタンスが正常でなくなると、インスタンスは自動的にスタンバイ状態のインスタンスにフェイルオーバーし、アクティブにします。Load-balancing サービスのヘルスマネージャーは、異常の発生しているインスタンスを自動的に再構築します。

2.6. Load-balancing サービスデプロイメント後の操作

Red Hat OpenStack Platform (RHOSP) は、Load-balancing サービス (octavia) のデプロイ後のステップを簡素化するためのワークフロータスクを提供しています。このワークフローは、Ansible Playbook のセットを実行して、オーバークラウドのデプロイの最終段階として、以下のデプロイ後のステップを提供します。

  • 証明書と鍵を設定する。
  • amphora、octavia コントローラーワーカー、およびヘルスマネージャーの間の負荷分散管理ネットワークを設定する。
注記

RHOSP heat テンプレートは直接編集しないでください。カスタムの環境ファイル (例: octavia-environment.yaml) を作成して、デフォルトのパラメーター値をオーバーライドしてください。

Amphora イメージ

事前にプロビジョニングされたサーバーでは、Load-balancing サービスをデプロイする前に、アンダークラウドに amphora イメージをインストールする必要があります。

$ sudo dnf install octavia-amphora-image-x86_64.noarch

事前にプロビジョニングされていないサーバーでは、RHOSP director はデフォルトの amphora イメージを自動的にダウンロードして、オーバークラウドの Image サービス (glance) にアップロードし、Load-balancing サービスがその amphora イメージを使用するように設定します。スタックの更新またはアップグレード中に、director はこのイメージを最新の amphora イメージに更新します。

注記

カスタムの amphora イメージはサポートされていません。

第3章 Load-balancing サービスのセキュリティー保護

Red Hat OpenStack Load-balancing サービス (octavia) のさまざまなコンポーネント間の通信のセキュリティーを保護することは、TLS 暗号化プロトコルと公開鍵暗号化に依存します。

本項では、TLS ハンドシェイクの概要を説明し、証明書のライフサイクルおよび中間証明書チェーンについて簡単に説明し、Red Hat OpenStack Platform が提供する自動生成された証明書ではなく、独自の証明書を使用するサイトでの手順を提供します。

3.1. Load-balancing サービスにおける双方向 TLS 認証

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) コントローラーのプロセスは、Web サイトへの HTTPS 接続によく似た TLS 接続を介して Load-balancing サービスインスタンス (amphora) と通信します。ただし、Load-balancing サービスは、双方向 TLS 認証を実行して、両方の側が信頼できることを検証します。

注記

これは、TLS ハンドシェイクの完全なプロセスを単純化します。完全なハンドシェイクについては、TLS 1.3 RFC 8446 を参照してください。

双方向 TLS 認証には、2 つのフェーズがあります。フェーズ 1 では、Load-balancing サービスのワーカープロセスなどのコントローラープロセスが Load-balancing サービスインスタンスに接続し、インスタンスがそのサーバー証明書をコントローラーに提示します。次に、コントローラーはコントローラーに保存されているサーバー認証局 (CA) 証明書に対して検証します。提示された証明書がサーバー CA 証明書に対して検証される場合、接続は 2 番目のフェーズに進みます。

フェーズ 2 では、コントローラーがクライアント証明書を Load-balancing サービスのインスタンスに提示します。次に、インスタンスはインスタンス内に保存されているクライアント CA 証明書に対して証明書を検証します。この証明書が正常に検証されると、残りの TLS ハンドシェイクは、コントローラーと Load-balancing サービスインスタンス間でセキュアな通信チャネルを確立し続けます。

3.2. Load-balancing サービスの証明書ライフサイクル

サーバー認証局証明書および鍵を使用して、Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) コントローラーは、各 Load-balancing サービスインスタンス (amphora) の証明書を一意に生成します。Load-balancing サービスハウスキーピングコントローラープロセスは、これらのサーバー証明書の有効期限が近づくと証明書を自動的にローテーションします。

Load-balancing サービスコントローラープロセスは、クライアント証明書を使用します。これらの TLS 証明書を管理する人の運用者は、証明書がクラウドコントロールプレーンで使用されるため、通常、長い有効期限を付与します。

3.3. Load-balancing サービスの証明書および鍵の設定

Red Hat OpenStack Platform (RHOSP) director が証明書と鍵を生成することを許可することも、独自に提供することもできます。director が必要なプライベート認証局を自動的に作成し、必要な証明書を発行するのを許可することを推奨します。これらの証明書は Load-balancing サービス (octavia) の内部通信専用で、ユーザーに公開されません。

重要

RHOSP director を使用して証明書および鍵を生成する利点の 1 つは、director が有効期限が切れる前に証明書を自動的に更新することです。独自の証明書を使用する場合には、director が自動的に更新できない点を念頭においてください。

注記

手動で生成された証明書から自動生成された証明書への切り替えは、RHOSP director ではサポートされません。ただし、コントローラーノード上の既存の証明書 (/var/lib/config-data/puppet-generated/octavia/etc/octavia/certs ディレクトリー内) を削除して、オーバークラウドを更新することで、証明書を強制的に再作成することができます。

独自の証明書および鍵を使用する必要がある場合は、以下の手順を実行します。

前提条件

  • 「Load-balancing サービスのデフォルト設定の変更」を読んで理解している (後半の「関連資料」のリンクを参照してください)。

Procedure

  1. openstack overcloud deploy コマンドを実行するマシンで、カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

  2. YAML 環境ファイルに以下のパラメーターを追加し、ご自分のサイトに適した値を設定します。

    • OctaviaCaCert:

      Octavia が証明書を生成するのに使用する CA の証明書

    • OctaviaCaKey:

      生成された証明書の署名に使用するプライベート CA 鍵

    • OctaviaCaKeyPassphrase:

      上記のプライベート CA 鍵で使用するパスフレーズ

    • OctaviaClientCert:

      コントローラー用に Octavia CA が発行するクライアント証明書および暗号化されていない鍵

    • OctaviaGenerateCerts:

      証明書および鍵の自動生成の有効 (true) または無効 (false) を director に指示するブール値

      重要

      OctaviaGenerateCerts を false に設定する必要があります。

      parameter_defaults:
          OctaviaCaCert: |
            -----BEGIN CERTIFICATE-----
            MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
            [snip]
            sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp
            -----END CERTIFICATE-----
      
          OctaviaCaKey: |
            -----BEGIN RSA PRIVATE KEY-----
            Proc-Type: 4,ENCRYPTED
            [snip]
            -----END RSA PRIVATE KEY-----[
      
          OctaviaClientCert: |
            -----BEGIN CERTIFICATE-----
            MIIDmjCCAoKgAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEP
            [snip]
            270l5ILSnfejLxDH+vI=
            -----END CERTIFICATE-----
            -----BEGIN PRIVATE KEY-----
            MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDU771O8MTQV8RY
            [snip]
            KfrjE3UqTF+ZaaIQaz3yayXW
            -----END PRIVATE KEY-----
      
          OctaviaCaKeyPassphrase:
            b28c519a-5880-4e5e-89bf-c042fc75225d
      
          OctaviaGenerateCerts: false
          [rest of file snipped]

      ヒント

      YAML ファイルでは、ファイル内でパラメーターがどこに置かれるかが非常に重要です。必ず parameter_defaults: は 1 列目から書き始め (先頭にスペースを置かない)、パラメーター/値のペアは 5 列目から書き始めてください (各パラメーターの前にスペースを 4 つ置く)。

  3. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

第4章 Load-balancing サービスのデプロイ

本項では、Red Hat OpenStack Platform Load-balancing サービス (octavia) をデプロイする方法と、その設定を変更する方法について説明します。また、Load-balancing サービスインスタンス (amphora) を高可用性にする方法も説明しています。

4.1. Load-balancing サービスのデプロイ

Red Hat OpenStack Platform (RHOSP) director を使用して、Load-balancing サービス (octavia) をデプロイします。完全な OpenStack 環境をインストールおよび管理するためのツールセットである director は、環境のプランセットとなる Orchestration サービス (heat) テンプレートを使用します。アンダークラウドはこれらのプランをインポートし、それらの指示に従って Load-balancing サービスおよびすべての OpenStack 環境を作成します。

前提条件

Procedure

  • コア heat テンプレート、環境ファイル、および octavia.yaml heat テンプレートを指定して、RHOSP director コマンド openstack overcloud deploy を実行します。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml

    注記

    director は、スタックの更新またはアップグレード中に amphora イメージを最新の amphora イメージに更新します。

4.2. Load-balancing サービスインスタンスでのアクティブ/スタンバイトポロジーの有効化

Load-balancing サービスインスタンス (amphora) を高可用性の構成にすることができます。この場合は、特定の Red Hat OpenStack Platform (RHOSP) Orchestration サービス (heat) パラメーター OctaviaLoadBalancerTopology を使用してアクティブ/スタンバイのトポロジーを実装します。カスタム環境ファイルOctaviaLoadBalancerTopology の値を設定します。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

重要

ベストプラクティスとしては、常にカスタム環境ファイルに対して Load-balancing サービスの設定変更を行い、openstack overcloud deploy コマンドを実行します。director を使用せず、Load-balancing サービス設定ファイルの値を手動で変更すると、設定変更が失われるリスクがあります。

前提条件

  • 『Advanced Overcloud Customization』を読んで理解している。
  • Compute サービスで、非アフィニティーが有効である (これがデフォルトです)。
  • 少なくとも 3 つのコンピュートノードホストが必要です。amphora を異なるホストに配置するために 2 つのコンピュートノードホストを使用し (Compute の非アフィニティー)、3 番目のホストをアクティブ/スタンバイロードバランサーの正常なフェイルオーバーに使用します。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインして、カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

  2. カスタム環境ファイルに、以下のパラメーターを追加します。

    parameter_defaults:
        OctaviaLoadBalancerTopology: "ACTIVE_STANDBY"
    ヒント

    YAML ファイルでは、ファイル内でパラメーターがどこに置かれるかが非常に重要です。必ず parameter_defaults: は 1 列目から書き始め (先頭にスペースを置かない)、パラメーター/値のペアは 5 列目から書き始めてください (各パラメーターの前にスペースを 4 つ置く)。YAML バリデーターを使用して YAML 構文が正しいことを確認することを検討してください。

  3. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

検証手順

  • デプロイメントが完了してロードバランサーを作成したら、以下のコマンドを実行します。

    $ source overcloudrc
    $ openstack loadbalancer amphora list

    Load-balancing サービスインスタンスの高可用性設定に成功すると、2 つのインスタンス (amphora) に関する出力が表示され、roleSINGLE は表示されなくなります。

4.3. Load-balancing サービスのデフォルト設定の変更

Red Hat OpenStack Platform (RHOSP) director を使用して、Load-balancing サービス (octavia) の設定変更を行います。完全な OpenStack 環境をインストールおよび管理するためのツールセットである director は、環境のプランセットとなる Orchestration サービス (heat) テンプレートを使用します。カスタム環境ファイル を使用して、オーバークラウドの要素をカスタマイズすることができます。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

重要

ベストプラクティスとしては、常にカスタム環境ファイルに対して Load-balancing サービスの設定変更を行い、openstack overcloud deploy コマンドを実行します。director を使用せず、Load-balancing サービス設定ファイルの値を手動で変更すると、設定変更が失われるリスクがあります。

前提条件

  • 『Advanced Overcloud Customization』を読んで理解している。
  • アンダークラウドで以下のファイルを参照して、director が Load-balancing サービスをデプロイするのにすでに使用している RHOSP Orchestration サービス (heat) パラメーターを決定します。
/usr/share/openstack-tripleo-heat-templates/deployment/octavia/octavia-deployment-config.j2.yaml
  • 変更するパラメーターを決定します。

    以下にいくつか例を示します。

    • OctaviaControlNetwork

      ロードバランサー管理ネットワークに使用される neutron ネットワークの名前

    • OctaviaControlSubnetCidr

      amphora 管理サブネット用のサブネット (CIDR 形式)

    • OctaviaMgmtPortDevName

      octavia ワーカー/ヘルスマネージャーと amphora マシン間の通信に使用される Octavia 管理ネットワークインターフェースの名前

Procedure

  1. openstack overcloud deploy コマンドを実行するマシンで、カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

  2. ご自分の環境ファイルには、parameter_defaults というキーワードを含める必要があります。parameter_defaults のキーワードの後に、ご自分のパラメーター/値ペアを定義します。

    parameter_defaults:
        OctaviaMgmtPortDevName: "o-hm0"
        OctaviaControlNetwork: 'lb-mgmt-net'
        OctaviaControlSubnet: 'lb-mgmt-subnet'
        OctaviaControlSecurityGroup: 'lb-mgmt-sec-group'
        OctaviaControlSubnetCidr: '172.24.0.0/16'
        OctaviaControlSubnetGateway: '172.24.0.1'
        OctaviaControlSubnetPoolStart: '172.24.0.2'
        OctaviaControlSubnetPoolEnd: '172.24.255.254'

    ヒント

    YAML ファイルでは、ファイル内でパラメーターがどこに置かれるかが非常に重要です。必ず parameter_defaults: は 1 列目から書き始め (先頭にスペースを置かない)、パラメーター/値のペアは 5 列目から書き始めてください (各パラメーターの前にスペースを 4 つ置く)。

  3. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

関連資料

第5章 Load-balancing サービスインスタンスのログの管理

Orchestration サービス (heat) パラメーターおよび openstack overcloud deploy コマンドを使用して、Load-balancing サービスインスタンス (amphora) のロギングを管理できます。

これらのパラメーターにより、テナントフローのロギングを有効にする、または amphora ローカルファイルシステムへのロギングの抑制するなどのオプションを制御することができます。また、Orchestration サービスで設定されるコンテナーセットの syslog レシーバーまたは選択したエンドポイントにある他の syslog レシーバーに、管理またはテナントフローログを転送することを決定することもできます。

さらに、syslog ファシリティー値を設定する、テナントフローログのフォーマットを変更する、カーネル等のソースや cron からのログを含めるように管理ログの範囲を拡張する、等のさまざまなロギング機能を制御できます。

5.1. Load-balancing サービスインスタンス (amphora) ログのオフロードの基本

デフォルトでは、Load-balancing サービスインスタンス (amphora) は、ローカルマシンの systemd ジャーナルにログを保存します。ただし、amphora がログを syslog レシーバーにオフロードするように指定して、管理とテナント両方のトラフィックフローのログを集約することができます。ログのオフロードにより、管理者はログを 1 カ所で管理し、amphora のローテーション後もログを維持することができます。

ほとんどの Red Hat OpenStack Platform (RHOSP) サービスと同様に、Orchestration サービス (heat) カスタム環境ファイルを使用して Load-balancing サービスインスタンスのロギングを設定します。対応する値と共に適切な heat パラメーターを追加したら、コア heat テンプレートおよびその他の環境ファイルと共にそのカスタム環境ファイルを呼び出して、openstack overcloud deploy コマンドを実行します。

5.2. Load-balancing サービスインスタンスの管理ログオフロードの有効化

デフォルトでは、Load-balancing サービスインスタンス (amphora) は、ローカルマシンの systemd ジャーナルにログを保存します。ただし、amphora がログを syslog レシーバーにオフロードするように指定して、管理ログを集約することができます。ログのオフロードにより、管理者はログを 1 カ所で管理し、amphora のローテーション後もログを維持することができます。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインして、カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

    ヒント

    Orchestration サービス (heat) は、テンプレート と呼ばれるプランのセットを使用して環境をインストールおよび設定します。カスタム環境ファイル を使用して、オーバークラウドの要素をカスタマイズすることができます。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

  2. YAML 環境ファイルの parameter_defaults セクションで、OctaviaLogOffloadtrue に設定します。

    重要

    コロン (:) と true の間に空白文字を追加するようにしてください。

    parameter_defaults:
        OctaviaLogOffload: true
        ...
    注記

    OctaviaAdminLogFacility パラメーターで別の値を指定しない限り、デフォルトでは、amphora は syslog ファシリティーの値に local1 を使用して管理ログをオフロードします。

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaAdminLogFacility: 2
        ...

  3. amphora は、ロードバランサー関連の管理ログ (haproxy 管理ログ、keepalived、および amphora エージェントログなど) のみを転送します。カーネル、システム、およびセキュリティーログ等の amphora からの すべての 管理ログを送信するように amphora を設定する場合には、OctaviaForwardAllLogstrue に設定します。

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaForwardAllLogs: true
        ...

  4. amphora は、ログメッセージをリッスンする syslog レシーバーが含まれる、RHOSP Orchestration サービス (heat) で定義されたデフォルトコンテナーのセットを使用します。異なるエンドポイントのセットを使用する場合は、OctaviaAdminLogTargets パラメーターでそれらを指定することができます。

    OctaviaAdminLogTargets: <ip-address>:<port>[, <ip-address>:<port>]

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaAdminLogTargets: 192.0.2.1:10514, 2001:db8:1::10:10514
        ...

  5. デフォルトでは、ログオフロードを有効にすると、テナントフローログもオフロードされます。

    テナントフローログのオフロードを無効にする場合は、OctaviaConnectionLoggingfalse に設定します。

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaConnectionLogging: false
        ...

  6. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

検証手順

  • OctaviaAdminLogTargets または OctaviaTenantLogTargets で特定のエンドポイントを指定しない限り、amphora は RHOSP コントローラー内の他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にログをオフロードします。
  • 適切な場所を確認して、以下のログファイルが存在することを確認します。

    • octavia-amphora.log: 管理ログのログファイル
    • (有効な場合) octavia-tenant-traffic.log: テナントトラフィックフローログのログファイル

5.3. Load-balancing サービスインスタンスのテナントフローログオフロードの有効化

デフォルトでは、Load-balancing サービスインスタンス (amphora) は、ローカルマシンの systemd ジャーナルにログを保存します。amphora がテナントフローログ用に十分なディスク領域が含まれるエンドポイント上の syslog レシーバーにログをオフロードすることを指定できます。テナントフローログは、テナント接続の数によってサイズが増大する場合があります。

管理ログのオフロードが有効な場合に、Load-balancing サービスインスタンス (amphora) のテナントフローログのオフロードは、自動的に有効になります。管理ログのオフロードが有効で、テナントフローログのオフロードが無効になるのは、OctaviaConnectionLogging パラメーターが false に設定されている場合だけです。

重要

テナントフローロギングは、ロードバランサーが受信する接続の数によって、多数の syslog メッセージを生成する場合があります。テナントフローロギングは、ロードバランサーへの接続ごとに 1 つのログエントリーを生成します。ログのボリュームをモニターし、ロードバランサーが管理すると予測される接続の数に基づいて syslog レシーバーを適切に設定することを推奨します。

Procedure

  1. openstack overcloud deploy コマンドを実行するマシンで、以下のいずれかのアクションを実行します。

    • 管理ログのオフロードがすでに有効で、テナントフローログがオフロード されていない 場合は、false から trueOctaviaConnectionLogging パラメーターを設定する必要があります。ステップ 2 に進みます。
    • いずれのログオフロードも有効ではない場合は、ステップ 4 に進みます。

      ヒント

      Orchestration サービス (heat) は、テンプレート と呼ばれるプランのセットを使用して環境をインストールおよび設定します。カスタム環境ファイル を使用して、オーバークラウドの要素をカスタマイズすることができます。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

  2. OctaviaConnectionLogging パラメーターが設定されている YAML カスタム環境ファイルを見つけ、falsetrue に変更します。

    $ grep -rl OctaviaConnectionLogging /home/stack/templates/

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaConnectionLogging: true
        ...
    重要

    コロン (:) と true の間に空白文字を追加するようにしてください。

    注記

    OctaviaTenantLogFacility パラメーターで別の値を指定しない限り、デフォルトでは、amphora は syslog ファシリティーの値に local0 を使用してテナントフローログをオフロードします。

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaTenantLogFacility: 1
        ...

  3. ステップ 6 に進みます。
  4. amphora のログオフロードがまだ有効に されていない 場合は、openstack overcloud deploy コマンドを実行するマシンで、YAML カスタム環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

  5. YAML 環境ファイルの parameter_defaults セクションで、OctaviaLogOffloadtrue に設定します。

    重要

    コロン (:) と true の間に空白文字を追加するようにしてください。

    parameter_defaults:
        OctaviaLogOffload: true
        ...
  6. (オプション) amphora は、ログメッセージをリッスンする syslog レシーバーが含まれる、RHOSP Orchestration サービス (heat) で定義されたデフォルトコンテナーのセットを使用します。異なるエンドポイントのセットを使用する場合には、管理ログ用には OctaviaAdminLogTargets パラメーターを使用して、テナントフローログ用には OctaviaTenantLogTargets を使用してそれぞれ指定できます。

    OctaviaAdminLogTargets: <ip-address>:<port>[, <ip-address>:<port>]
    
    OctaviaTenantLogTargets: <ip-address>:<port>[, <ip-address>:<port>]

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaAdminLogTargets: 192.0.2.1:10514, 2001:db8:1::10:10514
        OctaviaTenantLogTargets: 192.0.2.1:10514, 2001:db8:1::10:10514
        ...

  7. コア heat テンプレート、環境ファイル、および変更したカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

検証手順

  • OctaviaAdminLogTargets または OctaviaTenantLogTargets で特定のエンドポイントを指定しない限り、amphora は RHOSP コントローラー内の他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にログをオフロードします。
  • 適切な場所を確認して、以下のログファイルが存在することを確認します。

    • octavia-amphora.log: 管理ログのログファイル
    • octavia-tenant-traffic.log: テナントトラフィックフローログのログファイル

5.4. Load-balancing サービスインスタンスのテナントフローのロギングの無効化

管理ログのオフロードが有効な場合に、Load-balancing サービスインスタンス (amphora) のテナントフローログのオフロードは、自動的に有効になります。

管理ログのオフロードを有効にしたまま、テナントフローのロギングを無効にするには、OctaviaConnectionLogging パラメーターを false に設定する必要があります。

OctaviaConnectionLogging パラメーターが false の場合、amphora は amphora 内のディスクにテナントフローログを書き込まず、またログを別の場所でリッスンする syslog レシーバーにオフロードしません。

Procedure

  1. アンダークラウドホストに stack ユーザーとしてログインして、amphora のロギングが設定されている YAML カスタム環境ファイルを見つけます。

    ヒント

    Orchestration サービス (heat) は、テンプレート と呼ばれるプランのセットを使用して環境をインストールおよび設定します。カスタム環境ファイル を使用して、オーバークラウドの要素をカスタマイズすることができます。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

    $ grep -rl OctaviaLogOffload /home/stack/templates/

  2. amphora ロギングが設定されたカスタム環境ファイルの parameter_defaults の下、OctaviaConnectionLoggingfalse に設定します。

    重要

    コロン (:) と false の間に空白文字を追加するようにしてください。

    parameter_defaults:
        OctaviaLogOffload: true
        OctaviaConnectionLogging: false
        ...

  3. openstack overcloud deploy コマンドを実行しコア heat テンプレート、環境ファイル、および OctaviaConnectionLoggingtrue に設定したカスタム環境ファイルを含めます。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

検証手順

  • OctaviaAdminLogTargets または OctaviaTenantLogTargets で特定のエンドポイントを指定しない限り、amphora は RHOSP コントローラー内の他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にログをオフロードします。
  • 適切な場所を確認して、octavia-tenant-traffic.log存在しない ことを確認します。

5.5. Load-balancing サービスインスタンスのローカルログストレージの無効化

管理およびテナントフローログをオフロードするように Load-balancing サービスインスタンス (amphora) が設定されている場合でも、amphora はこれらのログを amphora 内のディスクに書き込み続けます。ただし、ローカルのロギングを停止することができます。これにより、ロードバランサーのパフォーマンスが向上します。

重要

この機能により、カーネル、システム、およびセキュリティーロギングを含む、amphora のすべてのログストレージが無効になります。

注記

ローカルログストレージを無効にし、OctaviaLogOffloadfalse の場合、負荷分散のパフォーマンスを改善するために OctaviaConnectionLoggingfalse に設定することを推奨します。

Procedure

  1. openstack overcloud deploy コマンドを実行するマシンで、カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/my-octavia-environment.yaml

    ヒント

    Orchestration サービス (heat) は、テンプレート と呼ばれるプランのセットを使用して環境をインストールおよび設定します。カスタム環境ファイル を使用して、オーバークラウドの要素をカスタマイズすることができます。このファイルは、heat テンプレートをカスタマイズするための特別な種別のテンプレートです。

  2. YAML 環境ファイルの parameter_defaults セクションで、OctaviaDisableLocalLogStoragetrue に設定します。

    重要

    コロン (:) と true の間に空白文字を追加するようにしてください。

    parameter_defaults:
        OctaviaDisableLocalLogStorage: true
        ...
  3. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、openstack overcloud deploy コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

検証手順

  • amphora インスタンスで、ログファイルが書き込まれる場所を確認し、新しいログファイルが書き込まれていないことを確認します。

5.6. Load-balancing サービスインスタンスのロギング用 heat パラメーター

Load-balancing サービスインスタンス (amphora) のロギングを設定する場合は、ロギングを制御する 1 つまたは複数の Orchestration サービス (heat) パラメーターに値を設定し、openstack overcloud deploy コマンドを実行します。

amphora ロギング用の heat パラメーターにより、ログオフロードの有効化、ログをオフロードするカスタムエンドポイントの定義、ログの syslog ファシリティー値の設定などの機能を制御できます。

表5.1 すべてのログの heat パラメーター

パラメーターデフォルト詳細

OctaviaLogOffload

false

true の場合、インスタンスはログをオフロードします。エンドポイントが指定されていない場合、デフォルトでは、インスタンスはそのログを他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にオフロードします。

OctaviaDisableLocalLogStorage

false

true の場合、インスタンスはインスタンスのホストのファイルシステムにログを格納しません。これには、すべてのカーネル、システム、およびセキュリティログが含まれます。

OctaviaForwardAllLogs

false

true の場合、インスタンスはすべてのログメッセージを管理ログのエンドポイントに転送します。これには、cron やカーネルログなどの負荷分散に関連しないログも含まれます。

インスタンスが OctaviaForwardAllLogs を認識するには、OctaviaLogOffload も有効にする必要があります。

表5.2 管理ロギング用の heat パラメーター

パラメーターデフォルト詳細

OctaviaAdminLogTargets

値なし。

管理ログメッセージを受信する syslog エンドポイントのコンマ区切りリスト (<host>:<port>)

これらのエンドポイントは、指定されたポートでログメッセージをリッスンするプロセスを実行しているコンテナー、仮想マシン、または物理ホストになります。

OctaviaAdminLogTargets が存在しない場合、インスタンスは RHOSP director で定義されたコンテナーセットの他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にログをオフロードします。

OctaviaAdminLogFacility

1

管理ログメッセージに使用する syslog "LOG_LOCAL" ファシリティーである 0 から 7 の間の数字

表5.3 テナントフローロギング用の heat パラメーター

パラメーターデフォルト詳細

OctaviaConnectionLogging

true

true の場合、テナント接続フローがログに記録されます。

OctaviaConnectionLogging が false の場合、amphora は OctaviaLogOffload 設定に関係なく、テナントの接続を停止します。OctaviaConnectionLogging はローカルのテナントフローログのストレージを無効にし、ログのオフロードが有効な場合、テナントフローログを転送しません。

OctaviaTenantLogTargets

値なし。

テナントトラフィックフローログメッセージを受信する syslog エンドポイントのコンマ区切りリスト (<host>:<port>)

これらのエンドポイントは、指定されたポートでログメッセージをリッスンするプロセスを実行しているコンテナー、仮想マシン、または物理ホストになります。

OctaviaTenantLogTargets が存在しない場合、インスタンスは RHOSP director で定義されたコンテナーセットの他の RHOSP ログと同じ場所 (/var/log/containers/octavia/) にログをオフロードします。

OctaviaTenantLogFacility

0

テナントトラフィックフローログメッセージに使用する syslog "LOG_LOCAL" ファシリティーである 0 から 7 の間の数字

OctaviaUserLogFormat

"{{ '{{' }} project_id {{ '}}' }} {{ '{{' }} lb_id {{ '}}' }} %f %ci %cp %t %{+Q}r %ST %B %U %[ssl_c_verify] %{+Q}[ssl_c_s_dn] %b %s %Tt %tsc"

テナントトラフィックフローログの形式

英数字は特定の octavia フィールドを表し、中括弧 ({}) は置換変数です。

5.7. Load-balancing サービスインスタンスのテナントフローログ形式

Load-balancing サービスインスタンス (amphora) のテナントフローログが使用するログ形式は、HAProxy のログ形式に従います。2 つの例外は、project_idlb_id 変数で、その値は amphora プロバイダードライバーによって提供されます。

sample

rsyslog を syslog レシーバーとして使用するログエントリーの例を以下に示します。

Jun 12 00:44:13 amphora-3e0239c3-5496-4215-b76c-6abbe18de573 haproxy[1644]: 5408b89aa45b48c69a53dca1aaec58db fd8f23df-960b-4b12-ba62-2b1dff661ee7 261ecfc2-9e8e-4bba-9ec2-3c903459a895 172.24.4.1 41152 12/Jun/2019:00:44:13.030 "GET / HTTP/1.1" 200 76 73 - "" e37e0e04-68a3-435b-876c-cffe4f2138a4 6f2720b3-27dc-4496-9039-1aafe2fee105 4 --

備考

  • ハイフン (-) は、不明または接続に該当しない任意のフィールドを示します。
  • 上記のサンプルログエントリーの接頭辞は rsyslog レシーバーに由来するもので、amphora からの syslog メッセージの一部ではありません。

    Jun 12 00:44:13 amphora-3e0239c3-5496-4215-b76c-6abbe18de573 haproxy[1644]:”

デフォルト

デフォルトの amphora テナントフローログの形式は以下のとおりです。

`"{{ '{{' }} project_id {{ '}}' }} {{ '{{' }} lb_id {{ '}}' }} %f %ci %cp %t %{+Q}r %ST %B %U %[ssl_c_verify] %{+Q}[ssl_c_s_dn] %b %s %Tt %tsc"`

形式の説明は、以下の表を参照してください。

表5.4 テナントフローログ形式の変数定義のデータ変数

変数フィールド名

{{project_id}}

UUID

プロジェクト ID (amphora プロバイダードライバーからの置換変数)

{{lb_id}}

UUID

ロードバランサー ID (amphora プロバイダードライバーからの置換変数)

%f

string

frontend_name

%ci

IP アドレス

client_ip

%cp

numeric

client_port

%t

date

date_time

%ST

numeric

status_code

%B

numeric

bytes_read

%U

numeric

bytes_uploaded

%ssl_c_verify

ブール値

client_certificate_verify (0 または 1)

%ssl_c_s_dn

string

client_certificate_distinguised_name

%b

string

pool_id

%s

string

member_id

%Tt

numeric

processing_time (ミリ秒)

%tsc

string

termination_state (cookie ステータスあり)

第6章 Load-balancing サービスフレーバーの設定

Load-balancing サービス (octavia) フレーバー は、定義するプロバイダー設定オプションの事前定義セットで、ユーザーがニーズに対応するロードバランサーの型を簡単に作成できるようにします。

本セクションでは、フレーバーの詳細情報と、そのフレーバーの作成に必要なステップを説明します。

6.1. Load-balancing サービスのフレーバーについて

Load-balancing サービス (octavia) フレーバー は、作成するプロバイダー設定オプションの事前定義セットです。ユーザーがロードバランサーを要求する場合、定義されたフレーバーのいずれかを使用してロードバランサーを構築するように指定できます。各負荷分散プロバイダードライバー用にフレーバーを定義して、該当するプロバイダーの一意の機能を公開します。

Load-balancing サービスのフレーバーを新たに作成するには、3 つのステップが必要です。

  1. フレーバーで設定する負荷分散プロバイダーの機能を決定する。
  2. 選択したフレーバー機能でフレーバープロファイルを作成する。
  3. フレーバーを作成する。

6.2. Load-balancing サービスプロバイダー機能の一覧

Load-balancing サービス (octavia) フレーバーを定義する最初のステップは、各プロバイダードライバーが公開する機能の一覧を確認することです。OpenStack クライアントを使用してプロバイダードライバー機能の一覧を取得することができます。

前提条件

  • OpenStack の管理者権限を持っている必要があります。

手順

  1. stack ユーザーとしてログインし、以下の OpenStack クライアントコマンドを実行します。

    $ openstack loadbalancer provider capability list <provider>

    $ openstack loadbalancer provider capability list amphora

    コマンド出力には、プロバイダーがサポートするすべての機能が一覧表示されます。

    出力サンプル

    +-----------------------+---------------------------------------------------+
    | name                  | description                                       |
    +-----------------------+---------------------------------------------------+
    | loadbalancer_topology | The load balancer topology. One of: SINGLE - One  |
    |                       | amphora per load balancer. ACTIVE_STANDBY - Two   |
    |                       | amphora per load balancer.                        |
    | ...                   | ...                                               |
    +-----------------------+---------------------------------------------------+

  2. 作成するフレーバーに必要な機能の名前を書き留めます。

6.3. フレーバープロファイルの定義

Load-balancing サービス (octavia) フレーバーを定義する 2 番目のステップは、フレーバーのプロファイルを定義することです。プロファイルには、プロバイダー名と機能一覧が含まれます。OpenStack クライアントを使用してフレーバープロファイルを作成します。

前提条件

  • OpenStack の管理者権限を持っている必要があります。
  • フレーバープロファイルに設定する負荷分散プロバイダーおよびその機能を把握している必要があります。

手順

  • stack ユーザーとしてログインし、以下の OpenStack クライアントコマンドを実行します。

    $ openstack loadbalancer flavorprofile create --name <profile-name> --provider <provider-name> --flavor-data '{"<capability>": "<value>"}'

    $ openstack loadbalancer flavorprofile create --name amphora-single-profile --provider amphora --flavor-data '{"loadbalancer_topology": "SINGLE"}'

    出力サンプル

    +---------------+--------------------------------------+
    | Field         | Value                                |
    +---------------+--------------------------------------+
    | id            | 72b53ac2-b191-48eb-8f73-ed012caca23a |
    | name          | amphora-single-profile               |
    | provider_name | amphora                              |
    | flavor_data   | {"loadbalancer_topology": "SINGLE"}  |
    +---------------+--------------------------------------+

    この例では、amphora プロバイダーのフレーバープロファイルが定義されています。このフレーバーが使用されると、単一の amphora ロードバランサーが作成されます。

検証手順

  • フレーバープロファイルを作成する際に、Load-balancing サービスはその値をプロバイダーで検証し、指定した機能をプロバイダーがサポートすることを確認します。

6.4. Load-balancing サービスフレーバーの作成

Load-balancing サービス (octavia) フレーバーを定義する最後のステップは、実際のユーザーに表示されるフレーバーを作成することです。フレーバーの名前は、ロードバランサーの作成時にユーザーが指定する値です。他のステップと同様に、OpenStack クライアントを使用してフレーバーを作成します。

前提条件

  • OpenStack の管理者権限を持っている必要があります。
  • フレーバープロファイルを作成している必要があります。

手順

  • stack ユーザーとしてログインし、以下の OpenStack クライアントコマンドを実行します。

    $ openstack loadbalancer flavor create --name <flavor-name> \
    --flavorprofile <flavor-profile> --description "<string>"
    ヒント

    提供しているフレーバーの機能をユーザーが明確に理解するように、詳細は説明を提供することを推奨します。

    $ openstack loadbalancer flavor create --name standalone-lb --flavorprofile amphora-single-profile --description "A non-high availability load balancer for testing."

    出力サンプル

    +-------------------+--------------------------------------+
    | Field             | Value                                |
    +-------------------+--------------------------------------+
    | id                | 25cda2d8-f735-4744-b936-d30405c05359 |
    | name              | standalone-lb                        |
    | flavor_profile_id | 72b53ac2-b191-48eb-8f73-ed012caca23a |
    | enabled           | True                                 |
    | description       | A non-high availability load         |
    |                   | balancer for testing.                |
    +-------------------+--------------------------------------+

    この例では、フレーバーが定義されている。ユーザーがこのフレーバーを指定すると、1 つの Load-balancing サービスインスタンス (amphora) を使用するロードバランサーが作成され、そのロードバランサーは高可用性 ではありません

注記

無効なフレーバーはユーザーに表示されますが、無効にされたフレーバーを使用してロードバランサーを作成することはできません。

第7章 Load-balancing サービスの監視

負荷分散の動作を維持するには、ロードバランサー管理ネットワークを使用し、負荷分散のヘルスモニターを作成、変更、および削除できます。

7.1. 負荷分散管理ネットワーク

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) は、ロードバランサー管理ネットワーク と呼ばれるプロジェクトネットワークを介してロードバランサーを監視します。Load-balancing サービスを実行するホストには、ロードバランサー管理ネットワークに接続するためのインターフェースが必要です。サポートされるインターフェース設定は、neutron Modular Layer 2 プラグインと Open Virtual Network メカニズムドライバーの組み合わせ (ML2/OVN) または Open vSwitch メカニズムドライバーの組み合わせ (ML2/OVS) で機能します。他のメカニズムドライバーを使用するインターフェースの使用はテストされていません。

デプロイメント時に作成されるデフォルトのインターフェースは、デフォルトの統合ブリッジ br-int 上の内部 Open vSwitch (OVS) ポートです。これらのインターフェースを、ロードバランサー管理ネットワークに割り当てられた実際の Networking サービスポートに関連付ける必要があります。

デフォルトでは、デフォルトインターフェースの名前は、o-hm0 です。これらは、Load-balancing サービスホストの標準のインターフェース設定ファイルで定義されます。RHOSP director は、デプロイメント時に Networking サービスポートおよび各 Load-balancing サービスホストのインターフェースを自動的に設定します。ポート情報とテンプレートは、以下を含むインターフェース設定ファイルの作成に使用されます。

  • IP およびネットマスクを含む IP ネットワークアドレス情報
  • MTU 設定
  • MAC アドレス
  • Networking サービスのポート ID

デフォルトの OVS の場合、Networking サービスのポート ID は追加データを OVS ポートに登録するのに使用されます。Networking サービスは、このインターフェースをポートに属するものとして認識し、ロードバランサー管理ネットワーク上で通信できるように OVS を設定します。

デフォルトでは、RHOSP は、Load-balancing サービスコントローラーが TCP ポート 9443 で仮想マシンインスタンス (amphora) と通信できるようにするセキュリティーグループおよびファイアウォールルールを設定し、amphora からのハートビートメッセージが UDP ポート 5555 のコントローラーに到達できるようにします。メカニズムドライバーによっては、負荷分散サービスとロードバランサー間の通信を可能にするために、追加または代替要件が必要になる場合があります。

7.2. Load-balancing サービスインスタンスの監視

Load-balancing サービス (octavia) は、負荷分散インスタンス (amphora) を監視し、amphora に異常が発生した場合にフェイルオーバーを開始して、置き換えます。フェイルオーバーが発生すると、Load-balancing サービスは /var/log/containers/octavia のコントローラー上の対応するヘルスマネージャーのログにフェイルオーバーを記録します。

ログ解析を使用して、フェイルオーバーの傾向を監視し、早い段階で問題に対処します。Networking サービス (neutron) の接続の問題、サービス拒否攻撃、および Compute サービス (nova) の異常などの問題により、ロードバランサーのフェイルオーバーの頻度が上がります。

7.3. Load-balancing サービスプールメンバーの監視

Load-balancing サービス (octavia) は、ベースとなる負荷分散サブシステムからの健全性情報を使用して、負荷分散プールのメンバーの健全性を判断します。健全性情報は Load-balancing サービスのデータベースにストリーミングされ、ステータスツリーまたは他の API メソッドにより利用できるようになります。重要なアプリケーションの場合、定期的な間隔で健全性情報をポーリングする必要があります。

7.4. ロードバランサーの監視

ロードバランサーのプロビジョニングステータスをモニターし、プロビジョニングのステータスが ERROR の場合にはアラートを送信する必要があります。アプリケーションがプールに対して定期的な変更を加えていて、頻繁に PENDING ステージに移行する場合は、アラートをトリガーしないでください。

ロードバランサーオブジェクトのプロビジョニングステータスは、コンタクトして作成、更新、および削除要求を正常にプロビジョニングできるコントロールプレーンのステータスを反映しています。ロードバランサーオブジェクトの操作ステータスは、ロードバランサーの現在の機能ステータスを報告します。

たとえば、ロードバランサーのプロビジョニングステータスが ERROR で、操作ステータスが ONLINE となる場合あります。これは、最後に要求されたロードバランサー設定への更新が正常に完了しないという、OpenStack Networking の障害により生じる可能性があります。この場合、ロードバランサーはロードバランサー経由でトラフィックの処理が継続しますが、最新の設定の更新が適用されていない可能性があります。

7.5. ロードバランサー機能の監視

openstack loadbalancer status show コマンドを使用して、ロードバランサーの稼働ステータスをモニターできます。ロードバランサーおよびその子オブジェクトの現在の稼働ステータスを報告します。

また、ロードバランサーリスナーに接続し、クラウド外から監視する外部モニタリングサービスを使用することもできます。このタイプのモニタリングでは、ルーターの失敗、ネットワーク接続の問題など、Load-balancing サービス (octavia) 外にロードバランサーの機能に影響を与える可能性のある障害が発生しているかどうかを示します。

7.6. Load-balancing サービスヘルスモニターの概要

Load-balancing サービス (octavia) のヘルスモニターは、各バックエンドメンバーサーバーで定期的なヘルスチェックを実行するプロセスで、障害が発生したサーバーを事前検出し、それらをプールから一時的に除外します。

ヘルスモニターが障害が発生したサーバーを検出すると、サーバーをプールから除外し、メンバーを ERROR とマークします。サーバーを修正して再度稼動状態にすると、ヘルスモニターはメンバーのステータスを ERROR から ONLINE に自動的に変更し、トラフィックをこれに渡すことを再開します。

実稼働環境のロードバランサーでは、ヘルスモニターを常に使用します。ヘルスモニターがない場合は、失敗したサーバーはプールから削除されません。これにより、Web クライアントのサービスの中断が発生する可能性があります。

以下に示すように、ヘルスモニターにはいくつかの種別があります。

  • HTTP: デフォルトでは、アプリケーションサーバーの / パスを調べます。
  • HTTPS: HTTP ヘルスモニターとまったく同じように動作しますが、TLS バックエンドサーバーが対象です。

    サーバーがクライアント証明書の検証を実行している場合、HAProxy には有効な証明書がありません。このような場合、TLS-HELLO ヘルスモニタリングが代替手段です。

  • TLS-HELLO: バックエンドサーバーが SSLv3-client hello メッセージに応答するようにします。

    TLS-HELLO ヘルスモニターは、ステータスコードやボディーの内容などの他のヘルスメトリックを確認しません。

  • PING: 定期的に ICMP ping リクエストをバックエンドサーバーに送信します。

    これらのヘルスチェックに合格するには、バックエンドサーバーは PING を許可するよう設定する必要があります。

    重要

    PING ヘルスモニターは、メンバーに到達可能で ICMP エコーリクエストに応答するかどうかを確認するだけです。PING ヘルスモニターは、インスタンスで実行されるアプリケーションが正常であるかどうかを確認しません。ICMP エコーリクエストが有効なヘルスチェックである場合にのみ、PING ヘルスモニターを使用します。

  • TCP: バックエンドサーバープロトコルポートへの TCP 接続を開きます。

    TCP アプリケーションは TCP 接続を開き、TCP ハンドシェイクの後にデータを送信せずに接続を閉じる必要があります。

  • UDP-CONNECT: 基本的な UDP ポート接続を実行します。

    Destination Unreachable (ICMP タイプ 3) がメンバーサーバーで有効化されていない場合、またはセキュリティールールによってブロックされている場合には、UDP-CONNECT ヘルスモニターが正しく動作しないことがあります。この場合、メンバーサーバーは、実際にダウンしている時に ONLINE の稼働ステータスとしてマークされる可能性があります。

7.7. Load-balancing サービスヘルスモニターの作成

Load-balancing サービス (octavia) のヘルスモニターは、それぞれのバックエンドサーバーで定期的なヘルスチェックを実行して失敗したサーバーを事前検出し、それらをプールから一時的に除外するので、ユーザーへのサービスの中断を回避するのに役立ちます。OpenStack クライアントを使用してヘルスモニターを作成することができます。

Procedure

  • ログインし、OpenStack クライアントコマンド openstack loadbalancer healthmonitor create を実行します。

    $ openstack loadbalancer healthmonitor create --name my-health-monitor --delay 10 --max-retries 4 --timeout 5 --type TCP lb-pool-1

検証手順

  • OpenStack クライアントコマンド openstack loadbalancer healthmonitor list を実行して、ヘルスモニターが実行中であることを確認します。

7.8. Load-balancing サービスヘルスモニターの変更

OpenStack クライアントコマンド openstack loadbalancer healthmonitor set を使用して、Load-balancing サービス (octavia) のヘルスモニターの設定を変更することができます。

Procedure

  • ログインし、OpenStack クライアントコマンド openstack loadbalancer healthmonitor set を実行します。

    $ openstack loadbalancer healthmonitor set my-health-monitor --delay 600

検証手順

  • OpenStack クライアントコマンド openstack loadbalancer healthmonitor show の実行により、ヘルスモニターの特定の情報を表示します。

7.9. Load-balancing サービスヘルスモニターの削除

Load-balancing サービス (octavia) のヘルスモニターを削除する必要がある場合には、OpenStack クライアントを使用することができます。

ヒント

ヘルスモニターを削除する代わりに、無効にすることもできます。以下の「関連資料」の loadbalancer healthmonitor set を参照してください。

Procedure

  • ログインし、OpenStack クライアントコマンド openstack loadbalancer healthmonitor delete を実行します。

    $ openstack loadbalancer healthmonitor delete my-health-monitor

検証手順

  • OpenStack クライアントコマンド openstack loadbalancer healthmonitor list を実行して、ヘルスモニターがもう存在しないことを確認します。

7.10. Load-balancing サービスヘルスモニターの設定引数

Load-balancing サービス (octavia) の すべて のヘルスモニター種別には、以下の設定可能な引数が必要です。

  • --delay: ヘルスチェックの間隔 (秒単位)。
  • --timeout: 指定したヘルスチェックが完了するまで待機する時間 (秒単位)。timeout は、常に delay よりも小さい値である必要があります。
  • --max-retries: バックエンドサーバーが停止しているとみなされるまでに失敗する必要のあるヘルスチェックの数。また、障害が発生したバックエンドサーバーが再度稼働中とみなされるために成功しなければならないヘルスチェックの数。

前述の引数に加えて、HTTP ヘルスモニター種別には、デフォルトで設定される以下の引数 必要になります。

  • --url-path: バックエンドサーバーから取得される URL のパスの部分。デフォルトでは、これは / です。
  • --http-method: url_path の取得に使用する HTTP メソッド。デフォルトでは、これは GET だけです。
  • --expected-codes: ヘルスチェックの成功を表す HTTP ステータスコードの一覧。デフォルトでは、これは 200 だけです。

7.11. Load-balancing サービス HTTP ヘルスモニターのベストプラクティス

Web アプリケーションでのヘルスチェックを生成するコードを作成する場合は、以下のベストプラクティスを考慮してください。

  • ヘルスモニター url-path には、読み込む認証は必要ありません。
  • expected-codes を代わりに指定しない限り、デフォルトでは、ヘルスモニター url-path はサーバーが正常であることを示すために HTTP 200 OK ステータスコードを返す必要があります。
  • ヘルスチェックは、アプリケーションが完全に正常であることを確認するために、十分な内部チェックを実行する必要があります。アプリケーションについて、以下の条件を満たしていることを確認します。

    • 必要なデータベースまたは他の外部ストレージ接続が稼働している。
    • アプリケーションを実行するサーバーで読み込みが許可されている。
    • お使いのサイトがメンテナンスモードにない。
    • アプリケーションに固有のテストが機能する。
  • ヘルスチェックによって生成されるページのサイズは小さくする必要があります。

    • 1 秒以下の間隔で返す必要がある。
    • アプリケーションサーバーに大きな負荷は発生させない。
  • ヘルスチェックを実行しているコードがキャッシュされたデータを参照する可能性がありますが、ヘルスチェックによって生成されるページはキャッシュされるべきではありません。

    たとえば、cron を使用してさらに広範なヘルスチェックを実行し、結果をディスクに保存すると便利です。ヘルスモニター url-path でページを生成するコードは、実行するテストのこの cron ジョブの結果を取り込みます。

  • Load-balancing サービスは、返された HTTP ステータスコードのみを処理し、ヘルスチェックが頻繁に実行されるため、HEAD または OPTIONS HTTP メソッドを使用してページ全体の処理を省略できます。

第8章 セキュアではない HTTP 用ロードバランサーの作成

本セクションでは、セキュアでない HTTP ネットワークトラフィック用のさまざまな種類のロードバランサーを作成する方法を説明します。

8.1. ヘルスモニターを使用した HTTP ロードバランサーの作成

OpenStack クライアントを使用してロードバランサーを作成し、セキュアでない HTTP アプリケーションのネットワークトラフィックを管理することができます。これは、IPv6 ネットワークなど、OpenStack Networking の Floating IP との互換性がないネットワークの基本ソリューションです。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット

Procedure

  1. パブリックサブネット (public-subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. ポート (80) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1

  4. リスナーの状態を確認します。

    $ openstack loadbalancer listener show listener1

    ACTIVE のステータスが表示されていれば、リスナーが作成されていることを意味しているので、次のステップに進むことができます。

  5. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP

  6. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  7. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:13                  |
    | vip_address         | 198.51.100.12                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:16:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:20:45                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

8.2. Floating IP を使用した HTTP ロードバランサーの作成

セキュアでない HTTP アプリケーションのネットワークトラフィックを管理するには、OpenStack クライアントを使用して、Floating IP に依存する仮想 IP (VIP) によるロードバランサーを作成することができます。Floating IP を使用する利点は、割り当てられた IP の制御を維持することです。このことは、ロードバランサーを移動、破棄、または再作成する場合に必要です。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

注記

Floating IP は IPv6 ネットワークでは機能しません。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • ロードバランサー VIP で使用できる Floating IP。
  • Floating IP に使用される、インターネットから到達可能な OpenStack Networking の共有外部 (パブリック) サブネット

Procedure

  1. プライベートサブネット (private_subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id private_subnet

  2. 後のステップで指定する必要があるため、load_balancer_vip_port_id の値を書き留めておきます。
  3. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  4. ポート (80) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1

  5. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP

  6. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  7. プライベートサブネットのロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

  8. 共有外部サブネット (public) に Floating IP アドレスを作成します。

    $ openstack floating ip create public

  9. 次のステップで指定する必要があるため、floating_ip_address の値を書き留めておきます。
  10. このフローティングIP (203.0.113.0) をロードバランサー vip_port_id (69a85edd-5b1c-458f-96f2-b4552b15b8e6) に関連付けます。

    $ openstack floating ip set --port 69a85edd-5b1c-458f-96f2-b4552b15b8e6 203.0.113.0

検証手順

  1. HTTP トラフィックが Floating IP (203.0.113.0) を使用してロードバランサー全体に流れることを確認します。

    $ curl -v http://203.0.113.0 --insecure

    以下のような出力が表示されるはずです。

    * About to connect() to 203.0.113.0 port 80 (#0)
    *   Trying 203.0.113.0...
    * Connected to 203.0.113.0 (203.0.113.0) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: 203.0.113.0
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Content-Length: 30
    <
    * Connection #0 to host 203.0.113.0 left intact
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.02.10                          |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:28:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

8.3. セッション永続性による HTTP ロードバランサーの作成

セキュアでない HTTP アプリケーションのネットワークトラフィックを管理するには、OpenStack クライアントを使用して、セッション永続性を追跡するロードバランサーを作成することができます。これにより、リクエスト受け取ると、ロードバランサーは、同じクライアントからの後続のリクエストを同じバックエンドサーバーに転送します。セッション永続性は、時間とメモリーを節約して負荷分散を最適化し、優れたユーザーエクスペリエンスが得られます。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • ネットワークトラフィックの負荷分散を行うセキュアではない Web アプリケーションで、クッキーが有効になっている。

Procedure

  1. パブリックサブネット (public-subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. ポート (80) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1

  4. クッキーのセッション永続性 (PHPSESSIONID) を定義するリスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --session-persistence type=APP_COOKIE,cookie_name=PHPSESSIONID

  5. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  6. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:58                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:28:42                  |
    | vip_address         | 198.51.100.22                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.02.10                          |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:28:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

第9章 セキュアな HTTP 用ロードバランサーの作成

セキュアな HTTP (HTTPS) ネットワークトラフィックを管理するために、さまざまな種別のロードバランサーを作成することができます。

9.1. HTTPS 非終端ロードバランサーの概要

HTTPS 非終端ロードバランサーは、一般的な TCP ロードバランサーのように効果的に機能します。ロードバランサーは、Web クライアントからの未加工の TCP トラフィックを、HTTPS 接続が Web クライアントで終端するバックエンドサーバーに転送します。HTTPS 非終端ロードバランサーの欠点の 1 つは、レイヤー 7 機能などの高度なロードバランサー機能に対応していないことです。

9.2. HTTPS 非終端ロードバランサーの作成

アプリケーションがバックエンドメンバーサーバーで終端する HTTPS トラフィックを必要とする場合に (一般的に HTTPS パススルー と呼ばれます)、ロードバランサーリスナーに HTTPS プロトコルを使用できます。

前提条件

  • TCP ポート 443 で TLS 暗号化 Web アプリケーションが設定された HTTPS アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット

Procedure

  1. パブリックサブネット (public-subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  2. ロードバランサーの状態を監視します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. ポート (443) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol HTTPS --protocol-port 443 lb1

  4. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTPS

  5. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TLS-HELLO --url-path / pool1

  6. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 443 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 443 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 443                                  |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

9.3. TLS 終端 HTTPS ロードバランサーについて

TLS 終端 HTTPS ロードバランサーが実装されると、Web クライアントは Transport Layer Security (TLS) プロトコルを介してロードバランサーと通信します。ロードバランサーは TLS セッションを終端し、復号化されたリクエストをバックエンドサーバーに転送します。ロードバランサーで TLS セッションを終端することで、CPU 負荷の高い暗号化操作をロードバランサーにオフロードし、これによりロードバランサーはレイヤー 7 インスペクション等の高度な機能を使用することができます。

9.4. TLS 終端 HTTPS ロードバランサーの作成

TLS 終端 HTTPS ロードバランサーを使用することで、CPU 負荷の高い暗号化操作をロードバランサーにオフロードし、これによりロードバランサーはレイヤー 7 インスペクション等の高度な機能を使用することができます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • TLS 公開鍵の暗号化が以下のように設定されている。

    • ロードバランサーの仮想 IP アドレス (例: www.example.com) に割り当てられた DNS 名用に、TLS 証明書、鍵、および中間証明書チェーンが外部認証局 (CA) から取得される。
    • 証明書、鍵、および中間証明書チェーンが、現在のディレクトリー内の個別ファイルに保存される。
    • 鍵および証明書は PEM 形式でエンコードされる。
    • 鍵はパスフレーズで暗号化されない。
    • 中間証明書チェーンには PEM 形式でエンコードされた複数の証明書が含まれ、チェーンを形成する。
  • Key Manager サービス (barbican) を使用するように Load-balancing サービス (octavia) が設定されている (本トピックの後半の「関連資料」で、『Manage Secrets with OpenStack Key Manager』のリンクを参照してください)。

Procedure

  1. 鍵 (server.key)、証明書 (server.crt)、および中間証明書チェーン (ca-chain.crt) を 1 つの PKCS12 ファイル (server.p12) に組み合わせます。

    注記

    丸かっこ内の値は例として示しています。これらの例を実際のサイトに適した値に置き換えてください。

    $ openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12

  2. Key Manager サービスを使用して、PKCS12 ファイルのシークレットリソース (tls_secret1) を作成します。

    $ openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"

  3. パブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  4. ロードバランサーの状態を監視します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  5. TERMINATED_HTTPS リスナー (listener1) を作成し、リスナーのデフォルト TLS コンテナーとしてシークレットリソースを参照します。

    $ openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') lb1

  6. プール (pool1) を作成し、リスナーのデフォルトプールに設定します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP

  7. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  8. プライベートサブネット (private_subnet) 上のセキュアではない HTTP バックエンドサーバー (192.0.2.10 および 192.0.2.11) をプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

9.5. SNI を使用した TLS 終端 HTTPS ロードバランサーの作成

Server Name Indication (SNI) テクノロジーを使用する TLS 終端 HTTPS ロードバランサーでは、単一のリスナーに複数の TLS 証明書を含めることができ、ロードバランサーは、共有 IP の使用時に提示する証明書を認識することができます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • TLS 公開鍵の暗号化が以下のように設定されている。

    • ロードバランサーの仮想 IP アドレス (例: www.example.com および www2.example.com) に割り当てられた DNS 名用に、複数の TLS 証明書、鍵、および中間証明書チェーンが外部認証局 (CA) から取得される。
    • 鍵および証明書は PEM 形式でエンコードされる。
    • 鍵はパスフレーズで暗号化されない。
  • Key Manager サービス (barbican) を使用するように Load-balancing サービス (octavia) が設定されている (本トピックの後半の「関連資料」で、『Manage Secrets with OpenStack Key Manager』のリンクを参照してください)。

Procedure

  1. SNI 一覧の TLS 証明書ごとに、鍵 (server.key)、証明書 (server.crt)、および中間証明書チェーン (ca-chain.crt) を 1 つの PKCS12 ファイル (server.p12) に組み合わせます。

    以下の例では、それぞれの証明書 (www.example.com および www2.example.com) 用に、2 つの PKCS12 ファイル (server.p12 および server2.p12) を作成します。

    注記

    丸かっこ内の値は例として示しています。これらの例を実際のサイトに適した値に置き換えてください。

    $ openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
    
    $ openssl pkcs12 -export -inkey server2.key -in server2.crt -certfile ca-chain2.crt -passout pass: -out server2.p12
  2. Key Manager サービスを使用して、PKCS12 ファイルのシークレットリソース (tls_secret1 および tls_secret2) を作成します。

    $ openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
    $ openstack secret store --name='tls_secret2' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server2.p12)"
  3. パブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet
  4. ロードバランサーの状態を監視します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  5. TERMINATED_HTTPS リスナー (listener1) を作成し、SNI を使用して両方のシークレットリソースを参照します。

    リスナーのデフォルト TLS コンテナーとして tls_secret1 を参照します。)

    $ openstack loadbalancer listener create --protocol-port 443 \
    --protocol TERMINATED_HTTPS --name listener1 \
    --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') \
    --sni-container-refs $(openstack secret list | awk '/ tls_secret1 / {print $2}') \
    $(openstack secret list | awk '/ tls_secret2 / {print $2}') -- lb1
  6. プール (pool1) を作成し、リスナーのデフォルトプールに設定します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
  7. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  8. プライベートサブネット (private_subnet) 上のセキュアではない HTTP バックエンドサーバー (192.0.2.10 および 192.0.2.11) をプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

9.6. 同じ IP およびバックエンドでの HTTP および TLS 終端 HTTPS 負荷分散の作成

クライアントがセキュアなプロトコルまたはセキュアではない HTTP プロトコルで接続されているかどうかにかかわらず、まったく同じコンテンツで Web クライアントに応答する場合に、同じロードバランサー (および同じ IP アドレス) にセキュアではないリスナーと TLS 終端 HTTPS リスナーを設定できます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 でセキュアではない HTTP アプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • TLS 公開鍵の暗号化が以下のように設定されている。

    • ロードバランサーの仮想 IP アドレス (例: www.example.com) に割り当てられた DNS 名用に、TLS 証明書、鍵、およびオプションの中間証明書チェーンが外部認証局 (CA) から取得される。
    • 証明書、鍵、および中間証明書チェーンが、現在のディレクトリー内の個別ファイルに保存される。
    • 鍵および証明書は PEM 形式でエンコードされる。
    • 鍵はパスフレーズで暗号化されない。
    • 中間証明書チェーンには PEM 形式でエンコードされた複数の証明書が含まれ、チェーンを形成する。
  • Key Manager サービス (barbican) を使用するように Load-balancing サービス (octavia) が設定されている (本トピックの後半の「関連資料」で、『Manage Secrets with OpenStack Key Manager』のリンクを参照してください)。
  • セキュアではない HTTP リスナーが、HTTPS TLS 終端ロードバランサーと同じプールで設定されている。

手順

  1. 鍵 (server.key)、証明書 (server.crt)、および中間証明書チェーン (ca-chain.crt) を 1 つの PKCS12 ファイル (server.p12) に組み合わせます。

    注記

    丸かっこ内の値は例として示しています。これらの例を実際のサイトに適した値に置き換えてください。

    $ openssl pkcs12 -export -inkey server.key -in server.crt -certfile ca-chain.crt -passout pass: -out server.p12
  2. Key Manager サービスを使用して、PKCS12 ファイルのシークレットリソース (tls_secret1) を作成します。

    $ openstack secret store --name='tls_secret1' -t 'application/octet-stream' -e 'base64' --payload="$(base64 < server.p12)"
  3. パブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet
  4. ロードバランサーの状態を監視します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  5. TERMINATED_HTTPS リスナー (listener1) を作成し、リスナーのデフォルト TLS コンテナーとしてシークレットリソースを参照します。

    $ openstack loadbalancer listener create --protocol-port 443 --protocol TERMINATED_HTTPS --name listener1 --default-tls-container=$(openstack secret list | awk '/ tls_secret1 / {print $2}') lb1
  6. プール (pool1) を作成し、リスナーのデフォルトプールに設定します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
  7. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  8. プライベートサブネット (private_subnet) 上のセキュアではない HTTP バックエンドサーバー (192.0.2.10 および 192.0.2.11) をプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1
  9. セキュアではない HTTP リスナー (listener2) を作成し、そのデフォルトのプールをセキュアなリスナーと同じプールに設定します。

    $ openstack loadbalancer listener create --protocol-port 80 --protocol HTTP --name listener2 --default-pool pool1 lb1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

第10章 他の種別のロードバランサーの作成

Load-balancing サービス (octavia) を使用して、管理する HTTP 以外のネットワークトラフィックの種別に一致するロードバランサーの種別を作成します。

10.1. TCP ロードバランサーの作成

HTTP 以外、TCP ベースのサービス、およびアプリケーションのネットワークトラフィックを管理する必要がある場合に、OpenStack クライアントを使用してロードバランサーを作成することができます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • 特定の TCP ポートでカスタムアプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット

Procedure

  1. パブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. カスタムアプリケーションが設定された指定のポート (23456) で TCP リスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 23456 lb1

  4. プール (pool1) を作成し、リスナーのデフォルトプールに設定します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol TCP

  5. バックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成し、TCP サービスポートを確認します。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type TCP pool1

  6. プライベートサブネット (private_subnet) 上のバックエンドサーバー (192.0.2.10 および 192.0.2.11) をプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                         |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。以下のコマンドを使用してメンバー ID を取得します。

    $ openstack loadbalancer member list pool1

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

10.2. ヘルスモニターを使用した UDP ロードバランサーの作成

UDP ポート上のネットワークトラフィックを管理する必要がある場合、OpenStack クライアントを使用してロードバランサーを作成することができます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • UDP ポートを使用するように設定された 1 つまたは複数のアプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • これらのバックエンドサーバーに、UDP ヘルスチェックが設定されている。
  • ICMP Destination Unreachable のメッセージ (ICMP タイプ 3) がセキュリティールールによってブロックされないようにします。

Procedure

  1. プライベートサブネット (private_subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id private_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. ポート (1234) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol UDP --protocol-port 1234 lb1

  4. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol UDP

  5. UDP (UDP-CONNECT) を使用するバックエンドサーバーに接続するプール (pool1) にヘルスモニターを作成します。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 2 --timeout 3 --type UDP-CONNECT pool1

  6. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 1234 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 1234 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                         |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. ヘルスモニターが存在し正常に機能する場合は、各メンバーのステータスを確認することができます。以下のコマンドを使用してメンバー ID を取得します。

    $ openstack loadbalancer member list pool1

    動作中のメンバー (b85c807e-4d7c-4cbd-b725-5e8afddf80d2) の operating_status の値は ONLINE でなければなりません。

    $ openstack loadbalancer member show pool1 b85c807e-4d7c-4cbd-b725-5e8afddf80d2

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                |                                      |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 1234                                 |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2021-01-15T11:12:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

10.3. QoS ルールが適用されるロードバランサーの作成

ロードバランサーが使用する仮想 IP アドレス (VIP) に OpenStack Networking Quality of Service (QoS) ポリシーを適用することができます。これにより、QoS ポリシーを使用して、ロードバランサーが管理することのできる送受信ネットワークトラフィックを制限することができます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 で HTTP アプリケーションが設定されたバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット
  • OpenStack Networking 用に作成された帯域幅を制限するルールが含まれる QoS ポリシー

Procedure

  1. OpenStack クライアントを使用して、最大 1024 kbps および最大バーストレートが 1024 kb のネットワーク帯域幅 QoS ポリシー (qos_policy_bandwidth) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack network qos policy create qos_policy_bandwidth
    $ openstack network qos rule create --type bandwidth-limit --max-kbps 1024 --max-burst-kbits 1024 qos-policy-bandwidth

  2. QoS ポリシー (qos-policy-bandwidth) を使用してパブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet --vip-qos-policy-id qos-policy-bandwidth

  3. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  4. ポート (80) にリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1

  5. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP

  6. バックエンドサーバーに接続するプールにヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  7. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  • リスナー (listener1) 設定を確認するには、openstack loadbalancer list コマンドを実行します。

    $ openstack loadbalancer list

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                         |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | cdfc3398-997b-46eb-9db1-ebbd88f7de05 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+

    この例では、パラメーター vip_qos_policy_id にポリシー ID が含まれます。

10.4. アクセス制御リストを使用したロードバランサーの作成

OpenStack クライアントを使用してアクセス制御リスト (ACL) を作成し、リスナーへの受信トラフィックを、許可されたソース IP アドレスのセットに制限することができます。それ意外の受信トラフィックは、すべて拒否されます。バックエンドメンバーを利用できる状態に保つためのヘルスモニターも作成するのがベストプラクティスです。

前提条件

  • TCP ポート 80 でカスタムアプリケーションが設定されたバックエンドサーバーが含まれるプライベートサブネット
  • これらのバックエンドサーバーは、URL パス / でヘルスチェックが設定されている。
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット

Procedure

  1. パブリックサブネット (public_subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --vip-subnet-id public_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. 許可される CIDR (192.0.2.0/24 および 198.51.100.0/24) でリスナー (listener1) を作成します。

    $ openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 80 --allowed-cidr 192.0.2.0/24 --allowed-cidr 198.51.100.0/24 lb1

  4. リスナーのデフォルトプール (pool1) を作成します。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol TCP

  5. バックエンドサーバーに接続するプールにヘルスモニターを作成し、パス (/) をテストします。

    $ openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1

  6. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をデフォルトのプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. リスナー (listener1) 設定を確認するには、openstack loadbalancer listener show コマンドを実行します。

    $ openstack loadbalancer listener show listener1

    以下のような出力が表示されるはずです。

    +-----------------------------+--------------------------------------+
    | Field                       | Value                                |
    +-----------------------------+--------------------------------------+
    | admin_state_up              | True                                 |
    | connection_limit            | -1                                   |
    | created_at                  | 2021-01-15T11:11:09                  |
    | default_pool_id             | None                                 |
    | default_tls_container_ref   | None                                 |
    | description                 |                                      |
    | id                          | d26ba156-03c3-4051-86e8-f8997a202d8e |
    | insert_headers              | None                                 |
    | l7policies                  |                                      |
    | loadbalancers               | 2281487a-54b9-4c2a-8d95-37262ec679d6 |
    | name                        | listener1                            |
    | operating_status            | ONLINE                               |
    | project_id                  | 308ca9f600064f2a8b3be2d57227ef8f     |
    | protocol                    | TCP                                  |
    | protocol_port               | 80                                   |
    | provisioning_status         | ACTIVE                               |
    | sni_container_refs          | []                                   |
    | timeout_client_data         | 50000                                |
    | timeout_member_connect      | 5000                                 |
    | timeout_member_data         | 50000                                |
    | timeout_tcp_inspect         | 0                                    |
    | updated_at                  | 2021-01-15T11:12:42                  |
    | client_ca_tls_container_ref | None                                 |
    | client_authentication       | NONE                                 |
    | client_crl_container_ref    | None                                 |
    | allowed_cidrs               | 192.0.2.0/24                         |
    |                             | 198.51.100.0/24                      |
    +-----------------------------+--------------------------------------+

    この例では、パラメーター allowed_cidrs は、192.0.2.0/24 および 198.51.100.0/24 からのトラフィックだけを許可するように設定します。

  2. ロードバランサーが保護されていることを確認するには、allowed_cidrs の一覧に記載されていない CIDR のクライアントからリスナーにリクエストの実施を試みます。リクエストは成功しないはずです。

    以下のような出力が表示されるはずです。

    curl: (7) Failed to connect to 203.0.113.226 port 80: Connection timed out
    curl: (7) Failed to connect to 203.0.113.226 port 80: Connection timed out
    curl: (7) Failed to connect to 203.0.113.226 port 80: Connection timed out
    curl: (7) Failed to connect to 203.0.113.226 port 80: Connection timed out

10.5. OVN ロードバランサーの作成

Red Hat OpenStack Platform (RHOSP) クライアントを使用して、RHOSP デプロイメントのネットワークトラフィックを管理するロードバランサーを作成できます。RHOSP Load-Balancing サービスは、neutron Modular Layer 2 プラグインと Open Virtual Network メカニズムドライバーの組み合わせ (ML2/OVN) をサポートします。

前提条件

  • ML2/OVN プロバイダードライバーがデプロイされている必要があります。

    重要

    OVN プロバイダーは、レイヤー 4 TCP および UDP ネットワークトラフィック、ならびに SOURCE_IP_PORT ロードバランサーアルゴリズムだけをサポートします。OVN プロバイダーはヘルスモニタリングをサポートしません。

  • 特定の TCP ポートでカスタムアプリケーションをホストするバックエンドサーバーが含まれるプライベートサブネット
  • インターネットからアクセス可能な共有外部 (パブリック) サブネット

Procedure

  1. --provider ovn 引数を使用して、プライベートサブネット (private_subnet) にロードバランサー (lb1) を作成します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer create --name lb1 --provider ovn --vip-subnet-id private_subnet

  2. ロードバランサーの状態を確認します。

    $ openstack loadbalancer show lb1

    ACTIVE のステータスが表示されていれば、ロードバランサーが作成され稼働していることを意味しているので、次のステップに進むことができます。

  3. カスタムアプリケーションが設定された指定のポート (80) でプロトコル (tcp) を使用するリスナー (listener1) を作成します。

    注記

    OVN プロバイダーは、レイヤー 4 TCP および UDP ネットワークトラフィックだけをサポートします。

    $ openstack loadbalancer listener create --name listener1 --protocol tcp --protocol-port 80 lb1

  4. リスナーのデフォルトプール (pool1) を作成します。

    注記

    OVN 用にサポートされる唯一の負荷分散アルゴリズムは SOURCE_IP_PORT です。

    $ openstack loadbalancer pool create --name pool1 --lb-algorithm SOURCE_IP_PORT --listener listener1 --protocol tcp

    重要

    OVN は負荷分散のヘルスモニター機能をサポートしません。

  5. プライベートサブネット (private_subnet) 上のバックエンドサーバー (192.0.2.10 および 192.0.2.11) をプールに追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 pool1
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 pool1

検証手順

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer show コマンドを実行します。

    $ openstack loadbalancer show lb1

    以下のような出力が表示されるはずです。

    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2021-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | ovn                                  |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2021-01-15T11:12:42                  |
    | vip_address         | 198.51.100.11                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. リスナーの情報を表示するには、openstack loadbalancer listener show コマンドを実行します。

    $ openstack loadbalancer listener show listener1

    以下のような出力が表示されるはずです。

    +-----------------------------+--------------------------------------+
    | Field                       | Value                                |
    +-----------------------------+--------------------------------------+
    | admin_state_up              | True                                 |
    | connection_limit            | -1                                   |
    | created_at                  | 2021-01-15T11:13:52                  |
    | default_pool_id             | a5034e7a-7ddf-416f-9c42-866863def1f2 |
    | default_tls_container_ref   | None                                 |
    | description                 |                                      |
    | id                          | a101caba-5573-4153-ade9-4ea63153b164 |
    | insert_headers              | None                                 |
    | l7policies                  |                                      |
    | loadbalancers               | 653b8d79-e8a4-4ddc-81b4-e3e6b42a2fe3 |
    | name                        | listener1                            |
    | operating_status            | ONLINE                               |
    | project_id                  | 7982a874623944d2a1b54fac9fe46f0b     |
    | protocol                    | TCP                                  |
    | protocol_port               | 64015                                |
    | provisioning_status         | ACTIVE                               |
    | sni_container_refs          | []                                   |
    | timeout_client_data         | 50000                                |
    | timeout_member_connect      | 5000                                 |
    | timeout_member_data         | 50000                                |
    | timeout_tcp_inspect         | 0                                    |
    | updated_at                  | 2021-01-15T11:15:17                  |
    | client_ca_tls_container_ref | None                                 |
    | client_authentication       | NONE                                 |
    | client_crl_container_ref    | None                                 |
    | allowed_cidrs               | None                                 |
    +-----------------------------+--------------------------------------+
  3. プール (pool1) とロードバランサーのメンバーを表示するには、openstack loadbalancer pool show コマンドを実行します。

    $ openstack loadbalancer pool show pool1

    以下のような出力が表示されるはずです。

    +----------------------+--------------------------------------+
    | Field                | Value                                |
    +----------------------+--------------------------------------+
    | admin_state_up       | True                                 |
    | created_at           | 2021-01-15T11:17:34                  |
    | description          |                                      |
    | healthmonitor_id     |                                      |
    | id                   | a5034e7a-7ddf-416f-9c42-866863def1f2 |
    | lb_algorithm         | SOURCE_IP_PORT                       |
    | listeners            | a101caba-5573-4153-ade9-4ea63153b164 |
    | loadbalancers        | 653b8d79-e8a4-4ddc-81b4-e3e6b42a2fe3 |
    | members              | 90d69170-2f73-4bfd-ad31-896191088f59 |
    | name                 | pool1                                |
    | operating_status     | ONLINE                               |
    | project_id           | 7982a874623944d2a1b54fac9fe46f0b     |
    | protocol             | TCP                                  |
    | provisioning_status  | ACTIVE                               |
    | session_persistence  | None                                 |
    | updated_at           | 2021-01-15T11:18:59                  |
    | tls_container_ref    | None                                 |
    | ca_tls_container_ref | None                                 |
    | crl_container_ref    | None                                 |
    | tls_enabled          | False                                |
    +----------------------+--------------------------------------+

第11章 レイヤー 7 負荷分散の実装

レイヤー 7 ポリシーと共に Red Hat OpenStack Platform Load-balancing サービス (octavia) を使用して、ビジネスニーズに応じた複数の条件により、HTTP リクエストを特定のアプリケーションサーバープールにリダイレクトすることができます。

11.1. レイヤー 7 の負荷分散とは

レイヤー 7 (L7) の負荷分散は、Open Systems Interconnection (OSI) モデルからその名前を取ります。ロードバランサーは、レイヤー 7 (アプリケーション) データに基づいてリクエストをバックエンドアプリケーションサーバープールに分散します。リクエストスイッチングアプリケーションロードバランシング、および コンテンツベースのルーティングスイッチング、または バランシング は、すべて L7 負荷分散を意味する用語です。Red Hat OpenStack Platform Load-balancing サービス (octavia) は、L7 負荷分散の堅牢なサポートを提供します。

注記

UDP ロードバランサーで L7 ポリシーおよびルールを作成することはできません。

L7 ロードバランサーは、数多くのバックエンドプールの代わりにリクエストを受け入れ、アプリケーションデータを使用してそれぞれのリクエストを処理するべきプールを決定するポリシーに基づいてこれらのリクエストを分散するリスナーで構成されます。これにより、アプリケーションインフラストラクチャーを、特定の種別のコンテンツに対応できるように具体的に調整および最適化することができます。たとえば、バックエンドサーバーの 1 つのグループ (プール) をイメージのみに対応するように調整し、別のグループを PHP や ASP などのサーバー側のスクリプト言語の実行用に、さらに別のグループを HTML、CSS、JavaScript などの静的コンテンツ用に調整することができます。

下位レベルの負荷分散と異なり、L7 負荷分散機能では、負荷分散サービスの背後にあるすべてのプールが同じコンテンツを持つ必要はありません。実際、L7 ロードバランサーは、異なるプールからのバックエンドサーバーに異なるコンテンツがあることを想定するのが通常です。L7 ロードバランサーは、アプリケーションメッセージの URI、ホスト、HTTP ヘッダー、およびその他のデータに基づいてリクエストを転送できます。

11.2. Load-balancing サービスでのレイヤー 7 負荷分散

レイヤー 7 (L7) の負荷分散は、適切に定義された任意の L7 アプリケーションインターフェースに対して実装できますが、Red Hat OpenStack Platform Load-balancing サービス (octavia) の L7 機能は、HTTP および TERMINATED_HTTPS プロトコルとその意味のみを参照します。

Neutron LBaaS および octavia は、L7 ルールおよびポリシーを使用して L7 の負荷分散のロジックを実現します。L7 ルールは、1 つの単純な論理テストで、true または false に評価します。L7 ポリシーは L7 ルールと、ポリシーに関連付けられたすべてのルールがマッチする場合に実行する必要のある定義されたアクションの集合です。

11.3. レイヤー 7 負荷分散ルール

Red Hat OpenStack Platform Load-balancing サービス (octavia) の場合、レイヤー 7 (L7) 負荷分散ルールは、true または false を返す単一の単純な論理テストです。これは、ルールの種別、比較の種別、値、およびルール種別に応じて使用されるオプションのキーで構成されます。L7 ルールは、常に L7 ポリシーに関連付ける必要があります。

注記

UDP ロードバランサーで L7 ポリシーおよびルールを作成することはできません。

11.4. レイヤー 7 負荷分散ルールの種別

Red Hat OpenStack Platform Load-balancing サービス (octavia) には、以下の種別のレイヤー 7 負荷分散ルールがあります。

  • HOST_NAME: ルールは、リクエストの HTTP/1.1 ホスト名を、ルールの値パラメーターと比較します。
  • PATH: ルールは、HTTP URI のパス部分を、ルールの値パラメーターと比較します。
  • FILE_TYPE: ルールは、URI の最後の部分を、ルールの値パラメーターと比較します (例: txtjpg など)。
  • HEADER: ルールはキーパラメーターで定義されるヘッダーを検索し、それをルールの値パラメーターと比較します。
  • COOKIE: ルールはキーパラメーターで命名されるクッキーを検索し、それをルールの値パラメーターと比較します。
  • SSL_CONN_HAS_CERT: クライアントが TLS クライアント認証用の証明書を提示した場合、ルールは一致します。これは、証明書が有効であることを意味するものではありません。
  • SSL_VERIFY_RESULT: このルールは、TLS クライアント認証証明書の検証結果を照合します。ゼロ (0) の値は、証明書が正常に検証されたことを意味します。ゼロより大きい値は、証明書が検証に失敗したことを意味します。この値は、openssl-verify 結果コードに従います。
  • SSL_DN_FIELD: ルールはキーパラメーターで定義される Distinguished Name を検索し、それをルールの値パラメーターと比較します。

11.5. レイヤー 7 負荷分散ルール比較の種別

Red Hat OpenStack Platform Load-balancing サービス (octavia) の場合、指定された種別のレイヤー 7 負荷分散ルールは常に比較を行います。octavia がサポートする比較の種別は以下のとおりです。すべてのルール種別がすべての比較種別に対応しているわけではないことに注意してください。

  • REGEX: perl 種別の正規表現の照合
  • STARTS_WITH: 文字列で始まる
  • ENDS_WITH: 文字列で終わる
  • CONTAINS: 文字列が含まれる
  • EQUAL_TO: 文字列が等しい

11.6. レイヤー 7 負荷分散ルールの結果の反転

Red Hat OpenStack Platform Load-balancing サービス (octavia) が使用するポリシーで必要なロジックをより完全に表現するために、レイヤー 7 負荷分散ルールではその結果を反転させることができます。指定されたルールの invert パラメーターが true の場合、その比較の結果は反転されます。

たとえば、equal to ルールを反転すると、実質的には not equal to ルールになります。regex ルールを反転すると、指定された正規表現が一致しない場合にだけ true が返されます。

11.7. レイヤー 7 負荷分散ポリシー

Red Hat OpenStack Platform Load-balancing サービス (octavia) の場合、レイヤー 7 (L7) 負荷分散ポリシーは、リスナーと関連付けられた L7 ルールの集合です。また、バックエンドプールとも関連付けられる場合があります。ポリシーは、ポリシー内のすべてのルールが満たされた場合にロードバランサーが実行するアクションを記述します。

注記

UDP ロードバランサーで L7 ポリシーおよびルールを作成することはできません。

11.8. レイヤー 7 負荷分散ポリシーのロジック

Red Hat OpenStack Platform Load-balancing サービス (octavia) の場合、レイヤー 7 負荷分散ポリシーのロジックは非常にシンプルです。指定されたポリシーに関連付けられたすべてのルールは、論理的に AND で結合されます。ポリシーとマッチするためには、リクエストはすべてのポリシールールとマッチする必要があります。

ルール間の論理 OR 演算を表す必要がある場合は、同じアクションのポリシーを複数作成して (または、より複雑な正規表現を作成して) これを行います。

11.9. レイヤー 7 負荷分散ポリシーのアクション

レイヤー 7 負荷分散ポリシーが指定のリクエストとマッチする場合は、そのポリシーのアクションが実行されます。以下は、L7 ポリシーに設定することのできるアクションです。

  • REJECT: リクエストは適切な応答コードと共に拒否され、いずれのバックエンドプールにも転送されません。
  • REDIRECT_TO_URL: リクエストは、redirect_url パラメーターに定義された URL に HTTP リダイレクトが送信されます。
  • REDIRECT_PREFIX: このポリシーにマッチするリクエストは、このプレフィックス URL にリダイレクトされます。
  • REDIRECT_TO_POOL: リクエストは、L7 ポリシーに関連付けられたバックエンドプールに転送されます。

11.10. レイヤー 7 負荷分散ポリシーの位置

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) の場合には、複数のレイヤー 7 (L7) 負荷分散ポリシーがリスナーに関連付けられると、ポリシーの位置パラメーターの値が重要になります。位置パラメーターは、L7 ポリシーが評価される順序を決定する際に使用されます。以下は、ポリシーの位置がリスナーの動作に影響を与える方法に関するいくつかの注意事項です。

  • octavia (haproxy amphora) の参照実装では、HAProxy はポリシーのアクションに関する以下の順序を強制します。

    • REJECT ポリシーは、他のすべてのポリシーよりも優先されます。
    • REDIRECT_TO_URL ポリシーは、REDIRECT_TO_POOL ポリシーよりも優先されます。
    • REDIRECT_TO_POOL ポリシーは、上記のすべての後にのみ、ポリシーの位置によって指定される順序で評価されます。
  • L7 ポリシーは (位置属性で定義されるように) 特定の順序で評価されます。指定のリクエストとマッチする最初のポリシーのアクションが実行されます。
  • いずれのポリシーも指定のリクエストにマッチしない場合、リクエストはリスナーのデフォルトプール (存在する場合) にルーティングされます。リスナーにデフォルトのプールがない場合は、エラー 503 を返します。
  • ポリシーの位置の番号は、1 から始まります。
  • 既存ポリシーの位置に一致する位置で新しいポリシーが作成されると、新しいポリシーが指定の位置に挿入されます。
  • 位置を指定せずに新しいポリシーが作成されるか、または一覧にすでにあるポリシーの番号よりも大きい位置を指定すると、新しいポリシーはただ一覧に追加されます。
  • ポリシーが一覧に挿入、削除、または追加されると、ポリシーの位置の値は数字を飛ばさずに 1 から並べ替えられます。たとえば、ポリシー A、B、および C の位置の値がそれぞれ 12、および 3 の場合、一覧からポリシー B を削除すると、ポリシー C の位置は 2 になります。

11.11. セキュアではない HTTP リクエストのセキュアな HTTP へのリダイレクト

レイヤー 7 (L7) ポリシーと共に Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) を使用して、セキュアではない TCP ポート上で受信した HTTP リクエストをセキュアな TCP ポートにリダイレクトすることができます。

この例では、セキュアではない TCP ポート 80 に到達するすべての HTTP リクエストは、セキュアな TCP ポート 443 にリダイレクトされます。

前提条件

  • リスナー (listener1) およびプール (pool1) を持つ TLS 終端 HTTPS ロードバランサー (lb1)。これらの前提条件については、後半の「関連資料」で TLS 終端のトピックを参照してください。

Procedure

  1. ロードバランサー (lb1) のポート (80) に HTTP リスナー (http_listener) を作成します。

    $ openstack loadbalancer listener create --name http_listener --protocol HTTP --protocol-port 80 lb1

  2. リスナー (http_listener) に L7 ポリシー (policy1) を作成します。ポリシーには、アクション (REDIRECT_TO_URL) が含まれ、URL (https://www.example.com/) を示す必要があります。

    $ openstack loadbalancer l7policy create --action REDIRECT_PREFIX --redirect-prefix https://www.example.com/ --name policy1 http_listener

  3. すべてのリクエストにマッチする L7 ルールを、ポリシー (policy1) に追加します。

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value / policy1

検証手順

  1. openstack loadbalancer l7policy list コマンドを実行し、ポリシー policy1 が存在することを確認します。
  2. openstack loadbalancer l7rule list <l7policy> コマンドを実行し、compare_typeSTARTS_WITH のルールが存在することを確認します。

    $ openstack loadbalancer l7rule list policy1

11.12. 開始パスに基づくリクエストのプールへのリダイレクト

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) を使用して、HTTP リクエストをサーバーの別のプールにリダイレクトすることができます。リクエストの URL で 1 つまたは複数の開始パスを照合するようにレイヤー 7 (L7) ポリシーを定義できます。

以下の例では、/js または /images で始まる URL が含まれるリクエストは、すべて静的コンテンツサーバーの別のプールにリダイレクトされます。

前提条件

  • リスナー (listener1) およびプール (pool1) を持つ HTTPS ロードバランサー (lb1)。この前提条件については、後半の「関連資料」で HTTP ロードバランサーのトピックを参照してください。

Procedure

  1. ロードバランサー (lb1) に 2 番目のプール (static_pool) を作成します。

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name static_pool --protocol HTTP

  2. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をプール (static_pool) に追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 static_pool
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 static_pool

  3. リスナー (listener1) に L7 ポリシー (policy1) を作成します。ポリシーには、アクション (REDIRECT_TO_POOL) を追加し、プール (static_pool) を示す必要があります。

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool static_pool --name policy1 listener1

  4. リクエストパスの先頭に /js を探す L7 ルールを、ポリシーに追加します。

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /js policy1

  5. アクション (REDIRECT_TO_POOL) で L7 ポリシー (policy2) を作成し、プールに示したリスナー (listener1) を追加します。

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool static_pool --name policy2 listener1

  6. リクエストパスの先頭に /images を探す L7 ルールを、ポリシーに追加します。

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /images policy2

検証手順

  1. openstack loadbalancer l7policy list コマンドを実行し、ポリシー policy1 および policy2 が存在することを確認します。
  2. openstack loadbalancer l7rule list <l7policy> コマンドを実行し、それぞれのポリシーごとに compare_typeSTARTS_WITH のルールが存在することを確認します。

    $ openstack loadbalancer l7rule list policy1
    $ openstack loadbalancer l7rule list policy2

11.13. 特定プールへのサブドメインリクエストの送信

レイヤー 7 (L7) ポリシーと共に Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) を使用して、特定の HTTP/1.1 ホスト名が含まれるリクエストをアプリケーションサーバーの異なるプールにリダイレクトすることができます。

以下の例では、HTTP/1.1 ホスト名 www2.example.com が含まれるリクエストは、すべてアプリケーションサーバーの別のプール pool2 にリダイレクトされます。

前提条件

  • リスナー (listener1) およびプール (pool1) を持つ HTTPS ロードバランサー (lb1)。この前提条件については、後半の「関連資料」で HTTP ロードバランサーのトピックを参照してください。

Procedure

  1. ロードバランサー (lb1) に 2 つ目のプール (pool2) を作成します。

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name pool2 --protocol HTTP

  2. リスナー (listener1) に L7 ポリシー (policy1) を作成します。ポリシーには、アクション (REDIRECT_TO_POOL) を追加し、プール (pool2) を示す必要があります。

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool pool2 --name policy1 listener1

  3. HTTP/1.1 ホスト名 www2.example.com を使用するすべてのリクエストを 2 番目のプール (pool2) に送信するポリシーに、L7 ルールを追加します。

    $ openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value www2.example.com policy1

検証手順

  1. openstack loadbalancer l7policy list コマンドを実行し、ポリシー policy1 が存在することを確認します。
  2. openstack loadbalancer l7rule list <l7policy> コマンドを実行し、ポリシーに compare_typeEQUAL_TO のルールが存在することを確認します。

    $ openstack loadbalancer l7rule list policy1

11.14. ホスト名末尾に基づくリクエストの特定プールへの送信

レイヤー 7 (L7) ポリシーと共に Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) を使用して、特定の文字列で終わる HTTP/1.1 ホスト名が含まれるリクエストをアプリケーションサーバーの異なるプールにリダイレクトすることができます。

以下の例では、.example.com で終わる HTTP/1.1 ホスト名が含まれるリクエストは、すべてアプリケーションサーバーの別のプール pool2 にリダイレクトされます。

前提条件

  • リスナー (listener1) およびプール (pool1) を持つ HTTPS ロードバランサー (lb1)。この前提条件については、後半の「関連資料」で HTTP ロードバランサーのトピックを参照してください。

Procedure

  1. ロードバランサー (lb1) に 2 つ目のプール (pool2) を作成します。

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name pool2 --protocol HTTP

  2. リスナー (listener1) に L7 ポリシー (policy1) を作成します。ポリシーには、アクション (REDIRECT_TO_POOL) を追加し、プール (pool2) を示す必要があります。

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool pool2 --name policy1 listener1

  3. HTTP/1.1 ホスト名 (www2.example.com) を使用するすべてのリクエストを 2 番目のプール (pool2) に送信するポリシーに、L7 ルールを追加します。

    $ openstack loadbalancer l7rule create --compare-type ENDS_WITH --type HOST_NAME --value .example.com policy1

検証手順

  1. openstack loadbalancer l7policy list コマンドを実行し、ポリシー policy1 が存在することを確認します。
  2. openstack loadbalancer l7rule list <l7policy> コマンドを実行し、ポリシーに compare_typeEQUAL_TO のルールが存在することを確認します。

    $ openstack loadbalancer l7rule list policy1

11.17. 名前がホスト名およびパスと一致するリクエストのプールへの送信

Red Hat OpenStack Platform (RHOSP) Load-balancing サービス (octavia) を使用して、特定の条件に一致する Web クライアントリクエストをアプリケーションサーバーの別のプールにリダイレクトすることができます。ビジネスロジックの条件は、事前定義されたホスト名およびリクエストパスを照合しようとするレイヤー 7 (L7) ポリシーで実行されます。

以下の例では、ホスト名 api.example.com に一致するか、リクエストパスの先頭が /api であるすべての Web クライアントリクエストは、別のプール api_pool にリダイレクトされます。

前提条件

  • リスナー (listener1) およびプール (pool1) を持つ HTTPS ロードバランサー (lb1)。この前提条件については、後半の「関連資料」で HTTP ロードバランサーのトピックを参照してください。

Procedure

  1. ロードバランサー (lb1) に 2 番目のプール (api_pool) を作成します。

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name api_pool --protocol HTTP

  2. プライベートサブネット (private_subnet) のロードバランサーメンバー (192.0.2.10 および 192.0.2.11) をプール (static_pool) に追加します。

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 static_pool
    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 static_pool

  3. リスナー (listener1) に L7 ポリシー (policy1) を作成します。ポリシーには、アクション (REDIRECT_TO_POOL) を追加し、プール (api_pool) を示す必要があります。

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool api_pool --name policy1 listener1

  4. ホスト名 api.example.com にマッチする L7 ルールを、ポリシーに追加します。

    $ openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value api.example.com policy1

  5. リクエスパスの最初の /api にマッチする 2 番目の L7 ルールを、ポリシーに追加します。

    このルールは、最初のルールと論理的に AND で結合されます。

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /api policy1

検証手順

  1. openstack loadbalancer l7policy list コマンドを実行し、ポリシー policy1 が存在することを確認します。
  2. openstack loadbalancer l7rule list <l7policy> コマンドを実行し、policy1compare_typeSTARTS_WITH および STARTS_WITH であるルールが共に存在することを確認します。

    $ openstack loadbalancer l7rule list policy1
    $ openstack loadbalancer l7rule list policy2

第12章 Load-balancing サービスの更新およびアップグレード

定期的に更新およびアップグレードを実施すると、最新の Red Hat OpenStack Platform Load-balancing サービス機能を利用できます。また、更新およびアップグレードを頻繁に行わないことによって生じる長期に及ぶ問題の発生を防ぐことができます。

12.1. Load-balancing サービスの更新およびアップグレード

Load-balancing サービス (octavia) は、Red Hat OpenStack Platform (RHOSP) の更新またはアップグレードの一部です。更新およびアップグレードにより RHOSP を最新化することで、より新しい負荷分散機能を活用することができます。

前提条件

  • アップグレード中 octavia コントロールプレーンが完全には機能しなくなるので、アップグレードを実行するためのメンテナンス期間がスケジュールされていること。

手順

  1. 『Red Hat OpenStack Platform の最新状態の維持』に記載の手順に従って、RHOSP の更新を実行します (本ガイドへのリンクは、以下の「関連資料」を参照してください)。
  2. メンテナンスリリースを適用した後に新機能を使用する必要がある場合は、実行中の amphora をローテーションして最新の amphora イメージに更新します (詳細は、以下の「関連資料」で「実行中の Load-balancing サービスインスタンスの更新」へのリンクを参照してください)。

12.2. 実行中の Load-balancing サービスインスタンスの更新

定期的に、実行中の Load-balancing サービスインスタンス (amphora) をより新しいイメージで更新することができます。たとえば、以下のイベント時に amphora インスタンスを更新する必要があります。

  • Red Hat OpenStack Platform (RHOSP) の更新またはアップグレード
  • システムへのセキュリティーアップデート
  • ベースとなる仮想マシンのフレーバー変更

Red Hat OpenStack Platform (RHOSP) の更新またはアップグレード時に、director は自動的にデフォルトの amphora イメージをダウンロードし、それをオーバークラウドの Image サービス (glance) にアップロードし、octavia が新しいイメージを使用するように設定します。ロードバランサーをフェイルオーバーすると、新しい amphora イメージを使用してインスタンス (amphora) を起動するように Load-balancing サービス (octavia) に強制します。

前提条件

  • amphora の新しいイメージ。これらは RHOSP の更新またはアップグレード時に利用可能です。

手順

  1. 更新するすべてのロードバランサーの ID を一覧表示します。

    $ openstack loadbalancer list -c id -f value
  2. それぞれのロードバランサーをフェイルオーバーします。

    $ openstack loadbalancer failover <loadbalancer_id>
    注記

    ロードバランサーのフェイルオーバーを開始したら、システムの使用状況を監視し、必要に応じてフェイルオーバーを実行する速度を調整します。ロードバランサーのフェイルオーバーにより、新規仮想マシンおよびポートが作成されます。これにより、一時的に OpenStack Networking の負荷が高まる場合があります。

  3. ロードバランサーのフェイルオーバーの状態を監視します。

    $ openstack loadbalancer show <loadbalancer_id>

    ロードバランサーのステータスが ACTIVE になれば、更新は完了です。

関連資料

第13章 Load-balancing サービスのトラブルシューティングおよびメンテナンス

Load-balancing サービス (octavia) の基本的なトラブルシューティングとメンテナンスは、ステータスを表示しインスタンスを移行するための OpenStack クライアントコマンドを熟知し、ログへのアクセス方法を理解することから始まります。より詳細なトラブルシューティングを行う必要がある場合は、1 つまたは複数の Load-balancing サービスインスタンス (amphora) に SSH 接続することができます。

13.1. ロードバランサーの検証

Load-balancing サービス (octavia) およびその各種コンポーネントのトラブルシューティングを行う基本的なステップの 1 つは、OpenStack クライアントのロードバランサーに関するさまざまな show および list コマンドを実行することです。

Procedure

  1. ロードバランサー (lb1) の設定を確認するには、openstack loadbalancer status show コマンドを実行します。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack loadbalancer status show lb1

  2. ロードバランサー (lb1) に関連付けられた amphora の UUID を確認するには、loadbalancer amphora list コマンドを実行します。

    $ openstack loadbalancer amphora list | grep 53a497b3-267d-4abc-968f-94237829f78f

  3. amphora の情報を表示するには、amphora の UUID と共に loadbalancer amphora show コマンドを実行します。

    $ openstack loadbalancer amphora show 62e41d30-1484-4e50-851c-7ab6e16b88d0

  4. リスナー (listener1) の情報を表示するには、openstack loadbalancer listener show コマンドを実行します。

    $ openstack loadbalancer listener show listener1

  5. プールとロードバランサーのメンバーを表示するには、openstack loadbalancer pool show コマンドを実行します。

    $ openstack loadbalancer pool show pool1

  6. Floating IP アドレスを確認するには、openstack floating ip list コマンドを実行します。

    $ openstack floating ip list

  7. リスナーが HTTPS または TERMINATED_HTTPS プロトコルに設定されているロードバランサー全体に、HTTPS トラフィックが流れることを確認します。

    $ curl -v https://198.51.100.213 --insecure
    * About to connect() to 198.51.100.213 port 443 (#0)
    *   Trying 198.51.100.213...
    * Connected to 198.51.100.213 (198.51.100.213) port 443 (#0)
    * Initializing NSS with certpath: sql:/etc/pki/nssdb
    * skipping SSL peer certificate verification
    * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    * Server certificate:
    * 	subject: CN=www.example.com,O=Dis,L=Springfield,ST=Denial,C=US
    * 	start date: Jan 15 09:21:45 2021 GMT
    * 	expire date: Jan 15 09:21:45 2021 GMT
    * 	common name: www.example.com
    * 	issuer: CN=www.example.com,O=Dis,L=Springfield,ST=Denial,C=US
    > GET / HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: 198.51.100.213
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Content-Length: 30
    <
    * Connection #0 to host 198.51.100.213 left intact

13.2. Load-balancing サービスインスタンスの管理ログ

Load-balancing サービスインスタンス (amphora) の管理ログオフロード機能は、テナントフローログを除く amphora 内のすべてのシステムロギングを対象とします。テナントフローログは、管理ログによって使用されるものと同じ syslog レシーバーに送信して処理できますが、独立して設定されます。

amphora は、メッセージを送信するアプリケーションのネイティブログ形式を使用して、すべての管理ログメッセージを送信します。amphora は、他の Red Hat OpenStack Platform (RHOSP) ログと同じ場所の RHOSP Controller にログを記録します (/var/log/containers/octavia/)。

13.3. 特定の Load-balancing サービスインスタンスの移行

メンテナンスのためにホストをシャットダウンしているので、Load-balancing サービスインスタンス (amphora) を移行する必要がある場合があります。

手順

  1. 移行する amphora の ID を特定します。後のステップで ID を指定する必要があります。

    $ openstack loadbalancer amphora list
  2. Compute スケジューラーサービスが退避しているコンピュートノードに新しい amphora をスケジュールしないようにするには、コンピュートノード (compute-host-1) を無効にします。

    注記

    丸かっこ内の値は、この手順のコマンド例で使用されるサンプルの値です。これらのサンプル値を、実際のサイトに適した値に置き換えてください。

    $ openstack compute service set compute-host-1 nova-compute --disable

  3. 前のステップで取得した amphora ID (ea17210a-1076-48ff-8a1f-ced49ccb5e53) を使用して amphora をフェイルオーバーします。

    $ openstack loadbalancer amphora failover ea17210a-1076-48ff-8a1f-ced49ccb5e53

13.4. SSH を使用した負荷分散インスタンスへの接続

サービスの問題のトラブルシューティングを行う際に、Secure Shell (SSH) を使用して実行中の Load-balancing サービスインスタンス (amphora) にログインすると便利な場合があります。

前提条件

  • octavia SSH 秘密鍵が必要です。
  • ロードバランサーを作成する前に、Load-balancing サービスの設定で SSH を有効にする必要があります。

手順

  1. (アンダークラウド上の) director ノードで ssh-agent を起動し、ユーザー ID キーをエージェントに追加します。

    $ eval `ssh-agent -s`
    $ ssh-add
  2. 接続する amphora の負荷分散管理ネットワーク (lb_network_ip) 上の IP アドレスを把握します。

    $ openstack loadbalancer amphora list
  3. SSH を使用して amphora に接続します。

    $ ssh -A -t heat-admin@<controller_node_IP_address> ssh cloud-user@<lb_network_ip>
  4. 操作を終え amphora への接続を切断したら、SSH エージェントを停止します。

    $ exit

付録A Load-balancing サービスのコマンドラインインターフェース

Load-balancing サービス (octavia) には、ネイティブのコマンドラインインターフェース (CLI) として利用可能な OpenStack クライアントプラグインがあります。

A.1. Load-balancing サービスのコマンドラインインターフェース

『Command Line Interface Reference』loadbalancer コマンドを参照してください。