HALB - HA プロキシに基づいたセッション認識 HTTP ロードバランサ

システムカタログ › スイッチ › HALB - HA プロキシに基づいたセッション認識 HTTP ロードバランサ

HALB - HA プロキシに基づいたセッション認識 HTTP ロードバランサ

最新バージョン： 2.0.2-1

HALB - セッション認識 HTTP ロードバランサ


早見表
カタログ	システム
カテゴリ	スイッチ
ユーザボリューム	なし
最小メモリ	96M
OS	Linux
制約	なし

機能の概要

HALB は、同一または異なるタイプの複数の Web サーバに作業負荷を配信するためのスイッチです。 HALB は HAProxy TCP/HTTP 負荷分散ソフトウェアパッケージに基づいています。消費するリソースがわずかなため、超高速化が実現されています。

HALB は、複数のアルゴリズムを使用して負荷分散機能を実行します。また、簡易ラウンドロビン負荷分散を実行し、バックエンドサーバへの負荷を均等にします。さらに、永続的セッションをサポートしており、セッション Cookie によって、またはリクエストソース IP アドレスをキーとして使用することにより、クライアントを特定のバックエンド Web サーバにバインドします。セッション Cookie の使用中、セッション Cookie を持たない新しいセッションは、ラウンドロビンアルゴリズムを使用して配信されます。 HALB は、複数の Cookie があるセッションをサポートし、必要なもののみ変更または追跡し、他のものはそのままの状態を保ちます。どのような特定のセッションやクライアントも、Cookie による関連付けを使用して、特定のバックエンド Web サーバまたはアプリケーションに結び付けることができます。既存の Cookie は、複数の Cookie を持つリクエストをサポートしていないクライアント用の HALB によって、透過的に変更される場合があります。

HALB は、すべてのバックエンド Web サーバの健全性状態を継続的にモニタします。 HALB が行う健全性状態チェックには、簡易 TCP 接続チェックまたはより複雑な HTTP リクエスト（HALB の境界上で指定）が含まれる場合があります。パラメータ化されたヘルスチェックメソッドを使用して HALB がサーバの故障を検出した場合、HALB はトラフィックを代替サーバに切り替えます。故障したサーバが結果的に回復した場合、HALB は再度切り替えを行って回復したサーバにトラフィックを戻すことができます。

HALB は、ctl 端子上で Web サービスインターフェースを公開します。このインターフェースでは、ユーザが出力端子 out1～out8 の有効/無効を実際に切り替えたり、すべての端子の状態を取得することが可能です。これは、何らかのバックエンド障害（すなわち、データベースまたはストレージアプライアンス内などで）が発生していて、アプリケーション自身が特定のサーバセットに対してトラフィックを自動的に無効にできる場合に役立ちます。この場合、HALB 自体はこのタイプの障害を検出できません。したがって、障害を検出し、対応するバックエンドサーバのセットを無効にするのはアプリケーションしだいです。

HALB は、バックエンド状態、1 サーバ当たりで処理されたリクエスト数、発生したエラー数などを含む詳細な統計を管理します。統計は mon 端子を介してレポートされます。また、個別のカウンタもブラウザでアクセス可能な GUI として、ui 端子を介して公開されます。

HALB は使用するリソースが非常に少ないため、きわめて高速な設計になっています。標準条件下では、HALB は 1 セッション当たり約 25KB のメモリを消費します。これは 40000 の同時セッションで 1GB に相当し、最大で毎秒 6000 件のリクエストを処理します。

境界

リソース

リソース	最小	最大	デフォルト
CPU	0.1	16	0.4
メモリ	96 MB	32 GB	96 MB
帯域幅	1 Mbps	2 Gbps	250 Mbps

L3LB に与えられるメモリ量によって、スループットや応答時間が増加することはありません。 L3LB は、CPU/帯域幅にバインドされたアプライアンスです。

端子

名前	方向	プロトコル	説明
in	in	HTTP	共通入力。受信した TCP リクエストは、ラウンドロビンの選択内容またはソースベースのセッション情報のいずれかを使用して、出力の 1 つへ転送されます。
ui	in	HTTP	Web クライアントから送られる HTTP リクエストを処理します。 HTTP/1.1 および 1.0 プロトコルを処理します。
ctl	in	HTTP	出力を有効/無効にし、出力端子の状態を取得するために使用する制御端子。
out1～out8	out	任意	分散出力。これらの出力の一部やすべてを接続しないでおくことができます。トラフィックは、接続済みの有効な出力のみに配信されます。デフォルトでは、端子はすべて有効です。
mon	out	CCE	パフォーマンスとリソースの使用状況統計を送信するために使用されます。

プロパティ

一般プロパティ

名前	タイプ	説明
mode	文字列	操作モードと、セッション識別用の名前付きセッション Cookie を使用する方法を指定します。有効な値は以下のとおりです。 passive - Cookie は変更されません。指定された Cookie 値が常に一意で、同じ値が別のサーバによって使用されないことが想定されます。 sync - サーバからの HTTP 応答に含まれる Cookie 文字列を変更して、応答元の端子に対して一意にします（4 文字の端子 ID を Cookie 値に入力します）。リクエストが outX 端子の 1 つにあるサーバへ転送される前に、「端子 ID」がストリップされます。端子 ID を挿入することを除けば、Cookie 値と出力端子間のマッピングは passive の場合と同じです。つまり、Cookie 値全体が比較されます。 insert - ロードバランサはそれ自身で in 端子上のクライアントに戻される応答に Cookie を挿入します。したがって、クライアントがその Cookie とともに後続のリクエストを送信すると、それらのリクエストは、そのクライアントからの最初のリクエストと同じサーバに方向付けられます。 HALB によって挿入された Cookie には有効期限日がありません。クライアントソフトウェアによって永続的に保存されません。 source - リクエストのソース IP アドレスは、セッションを特定のバックエンド Web サーバにバインドするために使用されます。 cookie プロパティが無視されます。デフォルト： passive
cookie_name	文字列	セッションを識別するために使用される Cookie の名前。 passive モード（passive および sync。以下の mode プロパティを参照）の場合、これはクライアントセッションを識別するために、out1～out8 に接続されたバックエンドサーバによって使用される Cookie の名前です。 insert モードの場合、これは、単一のサーバに各クライアントを「固定」するために、HALB が HTTP 応答に挿入する Cookie の名前です。このプロパティが空の値に設定されている場合、セッショントラッキングは行われておらず、リクエストはすべて単純なラウンドロビン方式で配布されます。 source モードでは無視されます。デフォルト：（空）
cookie_check_length	整数	セッションをバックエンド Web サーバに一致させるために、passive 操作モードで、一意キーとして Cookie の値から使用するバイト数を定義します。デフォルト値の10 は、共通するすべての PHP および Java アプリケーションにとって、通常は十分です。この値は常に Cookie 値の長さ以下にする必要があります。デフォルト： 10
max_connections	整数	ロードバランサが処理する、同時にアクティブな接続の最大数。この数に達しても新しい接続は受け付けられます。ただし、別の接続が閉じられるまで、それらの処理は遅れます。起動時、HALB は使用可能メモリ量に基づいて最大接続数を自動的に算定し、それをこのプロパティの値と比較して最も小さい値を使用します。このプロパティが 0 と等しい場合、計算値が使用されます。使用可能なメモリ量とこのプロパティの明示的な設定のいずれも、バランサのスループットまたはその最大リクエストレートに直接影響を与えるわけではありません。小さい数を設定する（すなわちメモリがほとんどない）と、バックエンドサーバが各リクエスト（たとえばデータベース検索）の長い操作を実行している場合、多くのリクエストが同時に開いたままとなります。デフォルト： 0
backup_outputs	文字列	バックアップとみなされる、スペースまたはカンマで区切られた出力リスト（out1～out8）。バックエンドサーバがすべて使用不可能な場合のみ、トラフィックはバックアップサーバに転送されます。これらのバックアップサーバの目的は、何らかの異常が発生した場合に、使用不能なバックエンドからエラーを投げたり、タイムアウトするのではなく、クライアントに通知するか、それらをリダイレクトすることです。デフォルト：（空）

タイムアウトプロパティ

名前	タイプ	説明
timeout	整数	非アクティブセッションが期限切れになるまでのタイムアウト秒数。ゼロに設定した場合、非アクティブセッションは期限切れになりません。ゼロ以外の値に設定されている場合は、タイムアウト秒後に再開された非アクティブセッションは古いと見なされます。「忘れられた」Cookie があるリクエストは、まったく Cookie がないかのように扱われ、通常のラウンドロビンメソッドを使用して、ランダムサーバに転送されます。このプロパティはパッシブモードのみに有効で、他のすべてのモードで無視されます。デフォルト： 0
client_timeout	整数	接続確立後にクライアントからのリクエストを待機するタイムアウト秒数。デフォルト： 150
server_timeout	整数	接続確立後にバックエンド Web サーバからの応答を待機するタイムアウト秒数。デフォルト： 150
conn_timeout	整数	任意の tcp 接続を確立するためのタイムアウト秒数。これにはヘルスチェックが含まれます。この設定には、特に注意が必要です。高負荷のもとでは、値を不当に小さくするとヘルスチェックがタイムアウトしてしまい、HALB が出力を無効し始めるからです。タイムアウトを 20 秒未満に設定することはお勧めしません。デフォルト： 20

ヘルスチェックプロパティ

名前	タイプ	説明
healthcheck_url	文字列	http_get と http_head のヘルスチェックメソッドで、バックエンド Web サーバのヘルスチェックの実行に使用する URL。完全 URL （http://host.name/file/to/check/for.php）または相対パス（/file/to/check/for.php）として指定することができます。 URL として指定された場合、HALB は HTTP/1.1 プロトコルを使用する一方で、Host: ヘッダ内の UR から抽出されたホスト名を使用して、ヘルスチェックを実行します。これは、仮想ホストの使用を許可します。相対パスとして指定した場合、HALB は HTTP/1.0 プロトコルを使用し、このプロパティによって指定されたドキュメントをチェックします。このプロパティが空の場合、HALB は HTTP/1.0 プロトコルを使用して、デフォルトルート「/」をチェックします。デフォルト：（空）
healthcheck_agent	文字列	http_get および http_head のヘルスチェックメソッド用のエージェント識別子として使用される文字列。空の場合、HALB-health-check が使用されます。デフォルト：（空）
healthcheck_method	文字列	バックエンド Web サーバのヘルスチェックに使用される方法。 tcp_connect - HALB は Web サーバのポート 80 に接続します。接続が正常に確立される場合、HALB は Web サーバが機能しているとみなします。これは最速の方法で、必要なリソースも最小限です。 http_head - HALB は、HEAD メソッドを使用して healthcheck_url プロパティによって指定されたドキュメントをリクエストします。これは tcp_connect より遅く、HALB と Web サーバの両方でより多くのリソースを必要としますが、信頼性は向上します。 Web サーバから受信するステータスコード 2xx または 3xx は、サーバが機能していることを確認します。 http_get - HALB は、GET メソッドを使用して healthcheck_url プロパティによって指定されたドキュメントをリクエストします。これはほとんどのリソースを必要とする最も遅いメソッドですが、信頼性は最も高くなります。Web サーバから受信するステータスコード 2xx または 3xx は、サーバが機能していることを確認します。 healthcheck_regexp プロパティが定義されている場合、HALB はすべての HTTP ヘッダおよびサーバステータスコードを含めてドキュメントをダウンロードし、healthcheck_regexp 値に対する一致をチェックします。一致が見つかった場合、バックエンドサーバは機能しているとみなされ、一致が見つからない場合は無効であるとみなされます。デフォルト： tcp_connect
healthcheck_regexp	文字列	http_get ヘルスチェックモードで使用されるテスト文字列。短いか、一般的な値（たとえば「OK」）は間違った正の一致の原因になる場合があります。この文字列は perl の正規表現です。perl の正規表現に関する詳細は、こちらを参照してください。デフォルト：（空）
healthcheck_interval	整数	バックエンド Web サーバのヘルスチェックの間隔（秒で指定）。デフォルト： 20 秒

UI/Web サービスインターフェースプロパティ

名前	タイプ	説明
username	文字列	ui 端子を介して HALB GUI にアクセスするためのユーザ名。空の場合、認証はありません。デフォルト：（空）
password	文字列	ui 端子を介して HALB GUI にアクセスするためのパスワード。ユーザ名が空の場合、パスワードは無視されます。デフォルト：（空）
ctl_port	整数	ctl 端子を介して Web サービスコントロールインターフェースにアクセスするために使用するポート。デフォルト： 80
ui_port	整数	ui 端子を介して HALB ランタイム統計 GUI にアクセスするために使用するポート。デフォルト： 80

カスタムカウンタ

HALB アプライアンスは、mon 端子を介して以下のカスタムカウンタをレポートします。

以下のカウンタは HALB カウンタグループに属します。 X は 1 から 8 の値を持つことができます。

カウンタ名	説明
outX_status	出力端子 outX の状態： 0 - 有効かつ動作中、1 - 有効かつ停止中、100 - 切断。
outX_queue	端子 outX のキューのリクエスト数。
outX_queue_max	端子 outX の同時キューリクエストの過去の最大数。
outX_sessions_active	端子 outX のアクティブセッション数。
outX_sessions_max	端子 outX の同時アクティブセッションの最大数。
outX_sessions_total	端子 outX の完了セッション数。
outX_errors	端子 outX の失敗したヘルスチェック数。
queue	現在のキューの長さ（out1～out8 で累積）。
queue_max	同時キューリクエストの過去の最大数（out1～out8 で累積）。
sessions_active	アクティブセッション数（out1～out8 で累積）。
sessions_max	アクティブセッションの過去の最大数（out1～out8 で累積）。
sessions_total	完了セッション数（out1～out8 で累積）。
errors	ヘルスチェック失敗の合計数（out1～out8 で累積）。

パフォーマンス

リクエストレート

ドキュメントサイズや利用可能なネットワーク帯域幅にもよりますが、HALB は毎秒（ 6000 以上のトランザクション（リクエスト/応答ペア）をルーティングします。

データスループット

HALB は 15MB/秒以上でルーティングします。

同時接続

HALB は 2000 以上の同時保留リクエストをサポートします（「保留リクエスト」はクライアントからのオープン TCP 接続であり、1 つ以上の未完了 HTTP リクエストが進行中です）。同時接続の数は、使用可能な空きメモリに依存しますが、最大で 40000 です。テストでは、HALB は 15000 を超えるアクティブな同時転送をサポートしました。

エラーメッセージ

アプライアンスの起動に失敗した場合、以下の内容のエラーがシステムログにログ記録される場合があります。

エラーメッセージ	説明
エラー：アプライアンスメモリ設定を決定できませんでした。CA Technologies のサポートにお問い合わせください。	HALB は使用可能なメモリ量の検出に失敗しました。CA のサポートにお問い合わせください。
エラー： HAProxy 環境設定ファイルを作成できませんでした。CA Technologies のサポートにお問い合わせください。	HALB が HAProxy 環境設定ファイルの作成に失敗しました。CA のサポートにお問い合わせください（原因としてディスク容量不足が考えられます）。
エラー：使用可能な CPU の数を特定できませんでした。CA Technologies のサポートにお問い合わせください。	HALB は使用可能な CPU 量の検出に失敗しました。CA のサポートにお問い合わせください。
エラー： healthcheck_url は、URL として指定するとき、http:// から始め、ドキュメントへのフルパスを含める必要があります（例： http://host.name.domain/file/to/check/for.html）。	healthcheck_url プロパティ値が正しくありません。「http://」から始めてフルパスを含める必要があります（例： http://host.name.domain/file/to/check/for.html）。
エラー：不明なヘルスチェックメソッド healthcheck_method が指定されています	healthcheck_method プロパティ値が正しくありません。これは tcp_connect、http_head または http_get のうちの 1 つにする必要があります。
エラー：無効な動作モードが指定されています	無効なモードが指定されています。これは passive、sync、insert、source のうちの 1 つにする必要があります。
エラー： ui_port 値は 1 ～ 65535 の値を指定する必要があります	ui_port 値は、1 より大きく 65535 より小さい必要があります。
エラー： ctl_port 値は 1 ～ 65535 の値を指定する必要があります	ctl_port 値は、1 より大きく 65535 より小さい必要があります。
エラー： HALB を起動できませんでした。詳細は「/var/ログ/アプライアンス/ログ」ログファイルを参照してください。	HALB の起動中にシステムエラーが発生しました。CA のサポートにお問い合わせください。
エラー：コントロール Web サービスインターフェースを初期化できませんでした。CA Technologies のサポートにお問い合わせください。	ctl 端子上で公開されているコントロール Web サービスインターフェースの初期化中にシステムエラーが発生しました。CA のサポートにお問い合わせください。
エラー：統計レポートを初期化できませんでした。CA Technologies のサポートにお問い合わせください。	統計レポートの初期化中にシステムエラーが発生しました。CA のサポートにお問い合わせください。
エラー：ユーザインターフェース端子を初期化できませんでした。CA Technologies のサポートにお問い合わせください。	ui 端子上で公開されているグラフィカルユーザインターフェースの初期化中にシステムエラーが発生しました。CA のサポートにお問い合わせください。
エラー：外部ヘルスチェッカーを初期化できませんでした。CA Technologies のサポートにお問い合わせください。	正義表現をサポートする外部ヘルスチェッカの起動中にエラーが発生しました。CA のテクニカルサポートにお問い合わせください。

出力端子のプログラムによる制御

概要

コントロール Web サービスインターフェースは、出力端子（out1～out8）を有効または無効にしたり、現在の端子状態を取得することを考慮に入れ、ctl 端子（設定済みポート上）上で公開されます。

プロトコル

このプロトコルは、読み取り機能のみを提供するので、GET HTTP メソッドのみが使用されます。したがって、サポートされているすべてのタイプのプロトコルで、リクエストはその URI および出力構造によって定義できます。文字は URI では「特殊」と認識されるため、標準的な % エンコーディングを介してエスケープする必要があります。

サポートされているすべての URI の説明を以下に示します。

コントロールコール

出力端子の無効化

出力端子がどのように識別されるかに基づき、disable コントロールコールには次の 2 つの形式があります。

名前によって出力端子を指定します（out1～out8）。
バックエンド Web サーバの対応する IP アドレスを指定します。

リクエスト： /api/disable?channel=out3 （出力端子 out3 を無効にします）

リクエスト： /api/disable?10.11.12.13 （IP アドレス 10.11.12.13 で Web サーバに接続される出力端子を無効にします）

応答：

HALB は、ステータスコードおよびオプションのステータスメッセージを持つ以下の構造を返します。

{
   "status" :
   {
   "code": code_value,
   "message": "status_message"
   }
}

可能なステータスコード値のリストを以下に示します。

コード値	説明
0	操作が成功し、端子は無効になりました。
10	操作が成功せず、HALB の設定は変更されませんでした。最も考えられる原因は、端子がすでに無効になっていたか、指定された IP アドレスが無効であるということです。
100	リクエストの処理中にエラーが発生しました。詳細はステータスメッセージを参照してください。

出力端子の有効化

出力端子がどのように識別されるかに基づき、enable コントロールコールには次の 2 つの形式があります。

名前によって出力端子を指定します（out1～out8）。
バックエンド Web サーバの対応する IP アドレスを指定します。

リクエスト： /api/enable?channel=out3 （出力端子 out3 を有効にします）

リクエスト： /api/enable?10.11.12.13 （IP アドレス 10.11.12.13 で Web サーバに接続される出力端子を有効にします）

応答：

HALB は、ステータスコードおよびオプションのステータスメッセージを持つ以下の構造を返します。

{
   "status" :
   {
   "code": code_value,
   "message": "status_message"
   }
}

可能なステータスコード値のリストを以下に示します。

コード値	説明
0	操作が成功し、端子は有効になりました。
10	操作が成功せず、HALB の設定は変更されませんでした。最も考えられる原因は、端子がすでに有効になっていたか、指定された IP アドレスが無効であるということです。
100	リクエストの処理中にエラーが発生しました。詳細はステータスメッセージを参照してください。

出力端子状態の取得

リクエスト： /api/status （すべての出力端子の状態を返します）

応答：

HALB は、ステータスコードおよびオプションのステータスメッセージを持つ以下の構造を返します。

{
   "status" :
   {
   "code": code_value,
   "message": "status_message",
   "terminal_id": "terminal_state",
   "terminal_id": "terminal_state",
   ...
   }
}

状態は、すべての接続済み端子の場合にのみ返されます。無効な端子や切断された端子の状態はレポートされません。

可能なステータスコード値のリストを以下に示します。

コード値	説明
0	操作は成功しました。
100	リクエストの処理中にエラーが発生しました。詳細はステータスメッセージを参照してください。

可能な端子の値は out1～out8 です。

可能な状態値は以下のとおりです。

状態値	説明
up	端子は接続されアクティブです。
down	端子は非アクティブです。この端子に接続される Web サーバは、down か HALB ヘルスチェックに失敗しています。

状態出力の例

{
   "status" :
   {
   "code": 0,
   "message": "",
   "out1": "up",
   "out2": "up",
   "out3": "down",
   "out4": "up"   
   }

}

Web GUI

HALB は ui 端子を介して統計 GUI を表示します。この GUI によってさまざまランタイム情報を使用できます：

パラメータ	説明
nbcproc	HALB に使用できる CPU の数。
uptime	HALB アップタイム。
system limits	オペレーティングシステムによって HALB に課されるリソース制限。
memmax	HALB に使用できる最大メモリ容量。
ulimit-n	同時オープンファイルの最大数。ネットワークソケットはファイルと見なされます。
maxsock	同時オープンソケットの最大数。
maxconn	同時接続の最大数。この数に到達すると、新しいすべての接続が待機キューに配置されます。
current conns	アクティブ接続の現在の数。
Server Status	バックエンドサーバの状態。 UP - server は機能していることを表し、DOWN - server は機能していないことを表します。
Queue Curr.	バックエンドサーバの現在のリクエストキューの長さ。
Queue Max.	HALB 起動後のバックエンドサーバのキュー最長到達。
Sessions Curr.	現在アクティブになっているセッションの数。
Sessions Max.	同時にアクティブになっているセッションの最大到達数。
Sessions Cumul.	完了したセッションの総数。
Errors Conn.	バックエンドサーバに接続中に発生したエラーの数。
Errors Resp.	バックエンドサーバによってレポートされた 5xx エラーの数。
Errors Check	バックエンドサーバの失敗ヘルスチェックの数。
Errors Down	バックエンドサーバが UP 状態から DOWN 状態に移行した回数。

典型的な使用状況

低速な動的コンテンツアプリケーションの負荷分散

アプリケーションが各ページを作成するのに多くの計算が必要な場合は、当然ながら同時にサービスできるクライアントの数が限られてきます。ただし、データソースが十分に速いか、レプリケートして複数のサーバからサービスを行える場合は、HALB を使用して同時に処理できる接続数を増やすことができます。代表的な例が、地図作成データベースから地図を提供する場合です。データベースは高速で読み取れますが、1 ページごとの読み込みでは、地図をイメージファイルとしてレンダリングする必要があります。

以下の図は、複数の CPU を使用して同一コンテンツを提供する際に、どのように HALB を使用すれば高負荷条件下でも応答を速くできるかを示しています。

サーバキープセッションの設定 - Bugzilla

設定例の一覧は、デフォルト以外の値に設定されたプロパティのみを表示しています。

プロパティ	値	注
cookie_name	Bugzilla_logincookie	Bugzilla がログイン Cookie 用に使用する名前です。
mode	passive	Bugzilla は、各ユーザ名/IP アドレスの組み合わせに対して一意の Cookie を発行します。したがって、同じデータベースに接続される 2 つの bugzilla インスタンスは、同じ Cookie を絶対に返しません。そのため、最も単純な passive モードを使用しても安全です。他のサーバタイプについては、sync 設定の方が適している場合があります。

Cookie を使用したセッションレスサーバ用の継続的負荷分散

セッションがなく、キャッシュされたデータをある程度保持していて、同じサーバに一貫して転送されるクライアントから利益が得られる可能性があるサーバの場合、パッシブ Cookie モニタリングはモニタ対象の Cookie がないので意味がありません。以下の表に示すように、このケースでは insert モードが使用されています。

プロパティ	値	注
cookie_name	session_id	任意の名前。ただし、サーバが他の何かに対して使用している名前と一致していないかを確認してください。
mode	insert	HALB は Set-cookie: ヘッダを挿入します。

セッション永続性を備えた Cookie を使用しないセッションレスサーバ用の継続的負荷分散

クライアントによっては、Cookie をサポートしないか、Cookie を無効にします。この場合、前に示した例ではクライアントが Cookie のセットを無視するので、最適なソリューションでありません。これをはるかに上回るソリューションが source モードの HALB 操作です。これはリクエストソース IP アドレスに基づき、Web サーバにトラフィックを転送します。また、クライアントがインターネットアクセスで複数のゲートウェイを同時に使用する場合、リクエストが同じ Web サーバへ転送されないようにすることも可能です。

プロパティ	値	注
mode	source	HALB は、リクエストソース IP アドレスをキーとして使用し、Web サーバへのリクエストをリダイレクトします。

インフラストラクチャヘルスチェックを備えた負荷分散

バックエンド Web サーバのヘルスチェックが成功しても、返されるデータが有効であることや、そのサーバの依存するデータベースが依然として機能していることを保証するわけではありません。 HALB の明確な特長の 1 つは、従来のヘルスチェック（単に Web サーバのポート 80 に接続する）方法だけでなく、http_head や http_get などの、より高度な方法も使用できることです。この機能を適切に活用すれば、バックエンド Web サーバの可用性だけでなく、それらの依存性、データベース、アプリケーションおよびストレージサーバを確認するのにも役立ちます。この例では、HALB の 2 つのヘルスチェック機能が使用されています。まず、特別なファイル health_check.php を作成し、その完全 URL を healthcheck_url プロパティで指定します。このファイルにアクセスすると、データベース、アプリケーションまたは NAS サーバの可用性が評価され、テキスト ALL_SERVICES_ARE_OK を含むステータスドキュメントが返されます。この値は healthcheck_regexp プロパティで指定されます。

HALB はすべての出力（out1～out8）を HTTP/1.1 GET リクエストとともに、Host: HTTP ヘッダ内の、ドキュメント URL が /health_check.php であるサイトを使用して確認します。これらの値は、healthcheck_url プロパティ（http://site/health_check.php）から抽出されます。各バックエンドサーバから取得したドキュメントでは、HALB は healthcheck_regexp （ALL_SERVICES_ARE_OK）の値を検索します。この行が見つかった場合、サーバは機能/動作しているとみなされ、見つからない場合、出力端子は無効になります。出力が無効になり、後で HALB ヘルスチェックに成功した場合、出力は再度有効になります。

仮想ホストを使用していないか、バックエンドサーバが HTTP/1.1 プロトコルをサポートしていないとき、healthcheck_url は単純形式（/health_check.php）で指定してもかまいません。この場合、HALB は HTTP/1.0 プロトコルを使用し、Host: HTTP ヘッダを指定しません。

プロパティ	値	注
healthcheck_mode	http_get	HALB は、http_get モードのヘルスチェックを使用します。
healthcheck_url	http://site/health_check.php	HALB が確認する URL。
healthcheck_regexp	ALL_SERVICES_ARE_OK

バックアップサーバの使用

バックエンドサーバがすべて使用不能のとき、バックアップサーバが使用されます。このときエラーやタイムアウトの代わりに、認識を促すメッセージやリダイレクトページをクライアントに配信する必要があります。以下の例では、サーババックアップは最後の手段的役割のサーバとして設定されており、クライアントに対し、技術メンテナンスを現在実行中であることを伝える静的ページのみを提供します。 srv1～srv4 の 4 つのサーバがすべて停止した場合は、サーババックアップからコンテンツが提供されます。

バックアップサーバの使用

プロパティ	値	注
backup_outputs	out8

コントロール Web サービスインターフェースの使用

コントロール Web サービスインターフェースは、動的かつプログラム的に HALB の出力端子を有効/無効にする方法を提供します。また、出力端子すべての現在の状態を取得するときにも使用できます。このインターフェースは、HALB の ctl 端子を介して公開されます。

以下の図は、複数の Web サーバおよびデータベースサーバからなるクラスタ環境を示しています。それぞれの Web サーバおよびデータベースサーバには、HALB の ctl 端子へのフィードバック接続があります。 Web サーバがデータベース/接続性/パフォーマンスに関する問題を検出した場合、対応する出力端子を無効にすることによって、Web サーバへのトラフィック転送を停止するよう HALB に命令することができます。同様に、どのデータベースサーバも、HALB の出力端子を無効にすることにより、受信トラフィックをすべて無効にできます。問題の解決後、出力端子は再度有効にすることができます。

複数の Web およびデータベースサーバが存在するクラスタ化環境

注

アプライアンス内で使用されるオープンソース/サードパーティソフトウェア

HALB では、そのベースクラス LUX5 によって使用されるサードパーティのオープンソースパッケージに加えて、以下のサードパーティオープンソースパッケージを使用します。

ソフトウェア	バージョン	変更	ライセンス	注
haproxy	1.4.9	なし	GPLv2	ホームページ
php-thttpd	2.25b	なし	BSD	該当なし

このトピックについて CA Technologies に電子メールを送信する