前のトピック: スイッチ

次のトピック: L3LB - TCP/UDP Load Balancer


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

HALB に与えられるメモリ量によって、スループットや応答時間が増加することはありません。 HALB は、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 文字列は、応答元の端子に固有になるように(Cookie 値へ 4 文字の端子 ID を追加することによって)変更されます。 「端子 ID」 はリクエストがいずれかの outX 端子上のサーバへ転送される前に取り除かれます。 端子 ID の挿入を除くと、Cookie 値と出力端子の間のマッピングは passive と同じです。つまり、Cookie 値全体が比較されます。
insert - クライアントに送信される応答にロード バランサ自身が 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

整数

passive 操作モードのときに、セッションをバックエンド サーバとマッチさせるために Cookie 値から固有キーとして使用されるバイト数を定義します。 デフォルト値の 10 は、通常すべての一般的な PHP および Java アプリケーションに十分です。 この値は、Cookie 値の長さ以下である必要があります。
デフォルト: 10

max_connections

integer

ロード バランサが処理する、同時にアクティブな接続の最大数。 この数に到達すると、新しい接続は引き続き受け入れられますが、別の接続が閉じられるまでその処理は遅延されます。 起動時、HALB は使用可能メモリ量に基づいて最大接続数を自動的に算定し、それをこのプロパティの値と比較して最も小さい値を使用します。 このプロパティが 0 と等しい場合、計算された値が使用されます。 使用可能なメモリおよびこのプロパティの明示的な設定のいずれも、バランサのスループットや最大リクエスト率に直接影響しないことに注意してください。低い数値(または少ないメモリ)を設定すると、バックエンド サーバが各リクエストに長時間の操作(たとえばデータベース検索)を実行している場合のみ、応答に影響が出ます。この場合、多くの応答が同時に開いたままになります。
デフォルト: 0

backup_outputs

文字列

バックアップとみなされる、スペースまたはカンマで区切られた出力リスト(out1~out8)。 トラフィックは、バックエンド サーバがすべて使用できない場合のみ、バックアップ サーバに転送されます。 これらのバックアップ サーバの目的は、使用できないバックエンドからエラーを投げたり、タイムアウトにしたりすることではなく、問題のクライアントへの通知またはクライアントのリダイレクトを行うことです。
デフォルト: (空)

タイムアウト プロパティ

名前

タイプ

説明

timeout

integer

アクティブでないセッションを期限切れにする、秒単位のタイムアウト。 ゼロに設定すると、アクティブでないセッションは期限切れになりません。 ゼロ以外の値に設定すると、タイムアウト秒後に再開されたアクティブでないセッションは古いものとみなされます。「忘れられた」Cookie を持つリクエストは、Cookie を持たないものとして処理され、通常のラウンド ロビン メソッドで任意のサーバに転送されます。 このプロパティは passive モードでのみ有効で、他のすべてのモードでは無視されます。
デフォルト: 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/log/appliance/log」ログ ファイルを参照してください。

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 つの形式があります。

リクエスト: /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 つの形式があります。

リクエスト: /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 を使用すれば高負荷条件下でも応答を速くできるかを示しています。

HALB をどのように使用して、同じコンテンツに対応する複数の CPU を適用できるか

サーバ キープ セッションの設定 - 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: ヘッダを挿入します。

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

バックエンド 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

該当なし