Dispatcher、CBR、および Site Selector の拡張機能

本章では、ロード・バランシング・パラメーターの構成方法と、拡張機能に関する Load Balancer のセットアップ方法について説明します。

注:
本章を読むとき、Dispatcher コンポーネントを使用中では ない 場合は、"dscontrol" を以下によって置換してください。
表 11. Load Balancer の拡張構成タスク
タスク 説明 関連情報
ロード・バランシングを行っているマシン上の Load Balancer を連結する 連結された Load Balancer マシンをセットアップします。 連結サーバーの使用
ハイ・アベイラビリティーまたは相互ハイ・アベイラビリティーを構成する 2 番目の Dispatcher マシンをセットアップしてバックアップを提供します。 ハイ・アベイラビリティー
ルール・ベースのロード・バランシングを構成する サーバーのサブセットが使用される条件を定義します。 ルール・ベースのロード・バランシングの構成
ポート類縁性のオーバーライドを使用して、サーバーがポート・スティッキー機能をオーバーライドするメカニズムを提供する サーバーは、そのポートのスティッキー時間の設定をオーバーライドできます。 ポート類縁性のオーバーライド
スティッキー (類縁性機能) を使用して、クラスターのポートをスティッキーになるように構成する クライアント要求を同じサーバーに送信できます。 Load Balancer の類縁性機能の動作
ポート間類縁性を使用して、スティッキー (類縁性) 機能をポート全体に拡張する 異なるポートから受け取ったクライアント要求を、同じサーバーに送信できます。 ポート間類縁性
類縁性アドレス・マスクを使用して、共通の IP サブネット・アドレスを指定する 同じサブネットから受け取ったクライアント要求を、同じサーバーに送信できます。 類縁性アドレス・マスク (stickymask)
活動中の cookie の類縁性を使用して、CBR のサーバーのロード・バランシングを行う セッションにおいて特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 活動 Cookie 類縁性
受動 Cookie の類縁性を使用して、Dispatcher の Content Based Routing (CBR) および CBR コンポーネントについてサーバーのロード・バランシングを行う セッションにおいて Cookie 名/Cookie 値を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 受動 cookie 類縁性
URI の類縁性を使用して、個々の各サーバーのキャッシュに入れる固有のコンテンツがある Caching Proxy サーバーにわたってロード・バランシングを行う セッションにおいて URI を基にして特定サーバーの類縁性を保守できるルール・オプションの 1 つ。 URI 類縁性
広域 Dispatcher サポートを構成する リモート Dispatcher をセットアップして、広域ネットワークにわたるロード・バランシングを行います。あるいは、GRE をサポートするサーバー・プラットフォームを使用して (リモート Dispatcher を使用しない) 広域ネットワークにわたるロード・バランシングを行います。 広域 Dispatcher サポートの構成
明示リンクを使用する リンクで Dispatcher をバイパスしないようにします。 明示リンクの使用
プライベート・ネットワークを使用する Dispatcher を構成して、プライベート・ネットワークにあるサーバーのロード・バランシングを行います。 プライベート・ネットワーク構成の使用
ワイルドカード・クラスターを使用して、共通のサーバー構成を結合する 明示的に構成されていないアドレスでは、トラフィックのロード・バランシングを行うための方法としてワイルドカード・クラスターが使用されます。 ワイルドカード・クラスターを使用したサーバー構成の結合
ワイルドカード・クラスターを使用して、ファイアウォールのロード・バランシングを行う ファイアウォールに対して、すべてのトラフィックのロード・バランシングが行われます。 ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング
透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用する 透過プロキシーを使用可能にするために Dispatcher を使用できるようにします。 透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用
ワイルドカード・ポートを使用して、構成されていないポートのトラフィックを送信する 特定のポートに対して構成されていないトラフィックを処理します。 ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信
「サービス妨害攻撃 (Denial of Service Attack)」を使用して、潜在的なアタックを管理者に (アラートによって) 通知する Dispatcher は、サーバーでハーフ・オープン TCP 接続の著しい量の受信要求を分析します。 サービス妨害攻撃の検出
バイナリー・ログを使用して、サーバーの統計を分析する サーバー情報をバイナリー・ファイルに保管して検索できるようにします。 バイナリー・ログを使用したサーバー統計の分析
連結クライアント構成を使用する Load Balancer をクライアントと同一マシン上に 常駐できるようにします。 連結クライアントの使用

連結サーバーの使用

Load Balancer は要求のロード・バランシングを行っているサーバーと同じマシン上に常駐できます。 これは一般に、サーバーの 連結 と呼ばれています。連結は、Dispatcher および Site Selector コンポーネントに適用されます。 また、CBR の場合は、バインド特定 Web サーバーおよびバインド特定 Caching Proxy を使用するときに限り、連結がサポートされています。

注:
トラフィック量が多い場合、連結サーバーは、リソースを求めて Load Balancer と競合します。しかし、過負荷のマシンがない場合は、連結サーバーを使用することによって、負荷の平衡化されたサイトのセットアップに必要なマシンの合計数を削減することができます。

Dispatcher コンポーネントの場合

Linux: MAC 転送方式を使用して Dispatcher コンポーネントを実行している時に、連結とハイ・アベイラビリティーを両方とも同時に構成するためには、Linux における Load Balancer の MAC 転送の使用時のループバック別名割り当ての代替手段を参照してください。

Solaris: エントリー・ポイント Dispatcher が連結されているときに WAN advisor を構成できないという制限があります。Dispatcher の広域サポートとリモート advisor の使用を参照してください。

Windows: 連結は現在使用されていません。

以前のリリースでは、連結サーバーのアドレスは構成内の非転送先アドレス (NFA) と同じになるように指定する必要がありました。この制限は、取り除かれました。

サーバーが連結されるように構成するために、dscontrol server コマンドには、yes または no に設定できる、collocated というオプションが提供されます。 デフォルトは no です。サーバーのアドレスは、マシン上のネットワーク・インターフェース・カードの有効な IP アドレスでなければなりません。 Dispatcher の NAT または CBR 転送方式で連結したサーバーには、 collocated パラメーターを設定しないでください。

連結サーバーは、次の方法のいずれかで構成できます。

Dispatcher の NAT または CBR 転送については、 NFA 上で未使用のアダプター・アドレスを構成する (別名を割り当てる) 必要があります。 サーバーは、このアドレスに対して listen するように構成します。 次のコマンド構文を使用してサーバーを構成してください。

dscontrol server add cluster:port:new_alias address new_alias router router_ip 
returnaddress return_address

この構成をしないと、システム・エラーが出されるか、 サーバーからの応答が得られないか、その両方につながります。

Dispatcher の nat 転送によるサーバー連結の構成

Dispatcher の nat 転送メソッドを使用して連結サーバーを 構成する場合、dscontrol server add コマンドで指定するルーターは、 サーバーの IP アドレスではなく、ルーターの実アドレスでなければなりません。

現在、次のオペレーティング・システムでは、Dispatcher マシンで以下のステップを実行すれば、Dispatcher の NAT 転送方式の構成時における連結をサポートすることができます。

CBR コンポーネントの場合

CBR は AIX、HP-UX、Linux、および Solaris プラットフォームで連結をサポートし、追加構成を必要としません。しかし、使用される Web サーバーおよび Caching Proxy はバインド固有でなければなりません。

Site Selector コンポーネントの場合

Site Selector は AIX、HP-UX、Linux、および Solaris プラットフォームで連結をサポートし、追加構成を必要としません。

ハイ・アベイラビリティー

ハイ・アベイラビリティー機能 (dscontrol highavailability コマンドで構成可能) は、Dispatcher コンポーネントに使用可能 (CBR または Site Selector コンポーネントでは使用不可) です。

Dispatcher の可用性を向上させるために、Dispatcher の高可用性機能は以下のメカニズムを使用します。

注:
2 つのクラスター・セットを共有している 2 つの Dispatcher マシンが相互にバックアップを提供し合う「相互ハイ・アベイラビリティー」構成の図と説明については、相互ハイ・アベイラビリティーを参照してください。 相互ハイ・アベイラビリティーはハイ・アベイラビリティーに類似していますが、全体として Dispatcher マシンではなくクラスター・アドレスを特に基にしています。どちらのマシンも、同じ共有クラスター・セットを構成していなければなりません。

ハイ・アベイラビリティーを構成する

dscontrol highavailability の完全な構文は、dscontrol highavailability — 高可用性の制御 を参照してください。

下記のタスクの多くについて詳しくは、Dispatcher マシンのセットアップ を参照してください。

  1. 2 つの Dispatcher マシンのそれぞれに、別名スクリプト・ファイルを作成します。スクリプトの使用 を参照してください。
  2. サーバーを両 Dispatcher サーバー・マシンで開始します。
  3. executor を両方のマシンで開始します。
  4. 各 Dispatcher マシンの非転送先アドレス (NFA) が構成されており、Dispatcher マシンのサブネットに対する有効な IP アドレスになっていることを確認します。
  5. 両方のマシンで heartbeat 情報を追加します。
    dscontrol highavailability heartbeat add sourceaddress destinationaddress
    注:
    Sourceaddress および destinationaddress は、Dispatcher マシンの IP アドレス (DNSnames または IP アドレスのいずれか) です。値は、各マシンごとに反転します。 例えば、以下のようになります。
    Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8
    Backup  - highavailability heartbeat add 9.67.186.8 9.67.111.3
    少なくとも 1 つの heartbeat ペアには、送信元アドレスおよび宛先アドレスとしてそのペア の NFA が必要です。

    可能な場合には、heartbeat ペアの少なくとも 1 つを、 通常のクラスター・トラフィックではなく別個のサブネットにまたがるようにしてください。 heartbeat トラフィックを別個に保持すると、非常に重いネットワーク負荷の最中に起こる偽の引き継ぎを防ぎ、 フェイルオーバー後の完全なリカバリーの時間を短縮させます。

    実行プログラムが高可用性 heartbeat のタイムアウトに使用する秒数を設定してください。以下に例を示します。

    dscontrol executor set hatimeout 3

    デフォルトは 2 秒です。

  6. 両方のマシンで、reach add コマンドを使用して、Dispatcher が全サービスを保証するために到達できなければならない、IP アドレスのリストを構成します。 例えば、以下のようになります。
    dscontrol highavailability reach add 9.67.125.18
    リーチ・ターゲットをお勧めしますが、必須ではありません。 詳しくは、heartbeat およびリーチ・ターゲットを使用した障害検出機能を参照してください。
  7. バックアップ情報を各マシンに追加します。
    注:
    port としてマシン上の未使用のポートを選択します。入力したポート番号は、 パケットを受信しているのが正当なホストであることを確認するためのキーとして使用されます。
  8. 各マシンの HA 状況をチェックします。
    dscontrol highavailability status
    マシンには、それぞれ正しいロール (バックアップとプライマリー、または両方)、状態、および副状態があるはずです。プライマリーは、活動状態であり、かつ同期化されていなければなりません。バックアップは待機モードであって、間もなく同期化されなければなりません。ストラテジーは同じでなければなりません。
  9. 両マシンのクラスター、ポート、およびサーバー情報をセットアップします。
    注:
    例えば、相互ハイ・アベイラビリティー構成 (図 14) の場合は、以下のようにして、2 つの Dispatcher 間で共有したクラスター・セットを構成します。
    • Dispatcher 1 発行の場合は、以下のようになります。
      dscontrol cluster set clusterA primaryhost NFAdispatcher1
      dscontrol cluster set clusterB primaryhost NFAdispatcher2
    • Dispatcher 2 発行の場合は、以下のようになります。
      dscontrol cluster set clusterB primaryhost NFAdispatcher2
      dscontrol cluster set clusterA primaryhost NFAdispatcher1
  10. 両マシンの manager および advisor を開始します。
注:
  1. 単一の Dispatcher マシンを構成して、バックアップなしでパケットを経路指定するには、始動時にハイ・ アベイラビリティーコマンドを出してはなりません。
  2. ハイ・ アベイラビリティー用に構成された 2 つの Dispatcher マシンを、単独で実行する 1 つのマシンに変換するには、いずれか一方のマシンの executor を停止してから、他方のマシンでハイ・ アベイラビリティー機能 (heartbeat、範囲、およびバックアップ) を削除します。
  3. 上記 2 つの例の両方で、必要に応じて、ネットワーク・インターフェース・カードをクラスター・アドレスで 別名割り当てしなければなりません。
  4. 2 つの Dispatcher マシンが HA 構成で稼働していて、同期しているときは、最初は待機マシンに、次は活動中のマシンに、すべての dscontrol コマンドを (この構成を更新するために) 入力します。
  5. 高可用性構成で 2 つの Dispatcher マシンを実行する際に、executor、クラスター、ポート、またはサーバーのパラメーター (port stickytime など) を 2 つのマシン上で異なる値に設定すると、予期しない結果が生じる場合があります。
  6. 相互高可用性では、Dispatcher の 1 つがバックアップ・クラスターに経路指定しているパケットを引き継ぐだけでなく、パケットをそのプライマリー・クラスターに能動的に経路指定していなければならない場合を考慮に入れてください。 このマシンのスループットの容量を超えていないことを確認してください。
  7. Linux システムでは、 ハイ・アベイラビリティーと連結を Dispatcher コンポーネントの MAC ポート転送方式を使用して同時に構成するときには、Linux における Load Balancer の MAC 転送の使用時のループバック別名割り当ての代替手段を参照してください。
  8. ハイ・アベイラビリティーの構成問題から生じる次のような問題を 改善するのに役立つヒントについては、 問題: 高可用性の構成に関するヒント を参照してください。

heartbeat およびリーチ・ターゲットを使用した障害検出機能

障害検出の基本的な基準 (heartbeat メッセージによって検出される、活動状態と待機 Dispatcher 間での接続性の喪失) 以外には、到達可能性基準 というもう 1 つの障害検出機構があります。Dispatcher を構成する場合は、正しく機能するようにするために、Dispatcher のそれぞれが到達できるホストのリストを提供できます。2 つの HA パートナーは、heartbeat を通じて互いに継続的に連絡を取り、2 つのうちいずれかが ping できるリーチ・ターゲット数を相互に更新します。待機 Dispatcher が活動状態の Dispatcher より多くのリーチ・ターゲットを ping する場合、フェイルオーバーが発生します。

heartbeat は、活動状態の Dispatcher によって送信され、スタンバイ Dispatcher によって 1/2 秒ごとに受信されることが予想されます。スタンバイ Dispatcher が 2 秒以内に heartbeat を受信できない場合、フェイルオーバーが始まります。heartbeat は、スタンバイ Dispatcher からの引き継ぎを発生させるためにすべて中断しなければなりません。 すなわち、2 組みの heartbeat を構成するときは、両方の heartbeat を中断する必要があるということになります。ハイ・アベイラビリティー環境を 安定させてフェイルオーバーを回避するためには、複数の heartbeat ペアを追加します。

リーチ・ターゲットの場合、Dispatcher マシンが使用するサブネットごとに、少なくとも 1 つのホストを選択しなければなりません。ホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合か、プライマリー Dispatcher が到達可能性基準に一致しなくなり、待機 Dispatcher が到達可能である場合は、フェイルオーバーが起こります。あらゆる使用可能な情報をもとに判断するため、活動状態の Dispatcher は、その到達可能性の機能を定期的に待機 Dispatcher に送信します。待機 Dispatcher は、この機能とそれ自身の機能と比較して、切り替えを行うかどうかを決定します。

注:
リーチ・ターゲットを構成する場合は、reach advisor も開始しなければなりません。reach advisor は、manager 機能を開始すると自動的に開始されます。reach advisor の詳細については、*** のページを参照してください。

リカバリー・ストラテジー

プライマリー・マシンおよび バックアップ と いう第 2 マシンの 2 つの Dispatcher マシンが構成されます。始動時に、プライマリー・マシンは、マシンが同期化するまで、すべての接続データをバックアップ・マシンに送信します。プライマリー・マシンは 活動状態 になります、すなわち、プライマリー・マシンはロード・バランシングが開始します。その間、バックアップ・マシンは、プライマリー・マシンの状況をモニターしていて、待機 状態にあるといわれます。

バックアップ・マシンは、いつでも、プライマリー・マシンが失敗したことを検出すると、プライマリー・マシンのロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンは、再度操作可能になると、ユーザーによるリカバリー・ ストラテジー の構成方法に応じて応答します。 ストラテジーには、以下の 2 種類があります。

自動
プライマリー・マシンは、再度操作可能になると直ちに すぐにパケットの経路指定を再開します。
手動
プライマリー・マシンが操作可能になっても、バックアップ・マシンはパケットの経路指定を継続します。プライマリー・マシンを活動状態に戻し、バックアップ・マシンを待機にリセットするには、手動による介入が必要です。

ストラテジー・パラメーターの設定は、両マシンとも同じでなければなりません。

手動リカバリー・ストラテジーでは、引き継ぎコマンドを使用して、パケットの経路指定を強制的に特定のマシンに向けることができます。手動リカバリーは、他のマシンで保守が行われているときは便利です。自動リカバリー・ストラテジーは、通常の不在操作用に設計されています。

相互ハイ・アベイラビリティー構成の場合は、クラスターごとの障害はありません。 一方のマシンでなんらかの問題が発生する場合、たとえその問題が 1 方だけのクラスターに影響を及ぼしても、他方のマシンは両方のクラスターを引き継ぎます。

注:
状態の引き継ぎ時に、一部の接続更新が破損する場合があります。 これは、引き継ぎ時にアクセス中の既存の長時間実行中の接続 (Telnet など) が終了する原因になる場合があります。

スクリプトの使用

Dispatcher がパケットを経路指定するには、それぞれのクラスター・アドレスがネットワーク・インターフェース・デバイスに対して 別名割り当てされなければなりません。

ネットワーク・インターフェース・カードに対する別名割り当てについては、ステップ 5. ネットワーク・インターフェース・カードの別名割り当て を参照してください。

Dispatcher マシンは障害を検出すると状態を変更するので、上記のコマンドは自動的に出されなければなりません。Dispatcher は、ユーザー作成のスクリプトを実行して、これを行います。次のディレクトリーにサンプル・スクリプトがあります。

これらのスクリプトを実行するためには、次のディレクトリーに移動する必要があります

スクリプトは、dsserver の稼働中のみ自動的に実行されます。

注:
  1. 相互ハイ・アベイラビリティー構成の場合、 それぞれの "go" スクリプトは、 プライマリー Dispatcher アドレスを識別するパラメーターが指定されてい る Dispatcher によって 呼び出されます。 スクリプトはこのパラメーターを照会し、 そのプライマリー Dispatcher に関連付けられたクラスター・アドレスに 対して executor configure コマンドを実行しなければなりません。
  2. Dispatcher の nat 転送方式のためにハイ・アベイラビリティーを構成するには、スクリプト・ファイルにリターン・アドレスを追加しなければなりません。

以下のサンプル・スクリプトを使用できます。

goActive
goActive スクリプトは、Dispatcher が活動状態になり、パケットの経路指定を開始すると実行されます。
goStandby
goStandby スクリプトは、Dispatcher が活動状態のマシンの状態はモニターするが、パケットの経路指定は行わない待機状態になると実行されます。
goInOp
goInOp スクリプトは Dispatcher executor が停止する時点で実行されます。
goIdle
goIdle スクリプトは、Dispatcher がアイドル状態になり、パケットの経路指定を開始すると実行されます。これは、スタンドアロン構成の場合のように、高可用性機能が追加させていないと起こります。また、ハイ・アベイラビリティー機能が追加される前または 削除された後のハイ・アベイラビリティー構成でも起こります。
highavailChange
highavailChange スクリプトは、高可用性状態が Dispatcher 内で変化すると ("go" スクリプトの 1 つが呼び出されるなど) 常に実行されます。 このスクリプトに渡される単一のパラメーターは、Dispatcher によってまさに実行される "go" スクリプトの名前です。このスクリプトは、例えば、管理者にアラートを通知するか、あるいは単にイベントを記録する目的などで、状態変更情報を使用するために作成できます。

Windows システムの場合: 構成セットアップにおいて、Site Selector がハイ・アベイラビリティー環境で運用中の 2 つの Dispatcher マシンのロード・バランシングを行うようにする場合は、Metric Server 用の Microsoft スタック上の別名を追加することになります。 この別名が goActive スクリプトに追加されます。 例えば、以下のようになります。

call netsh interface ip add address "Local Area Connection"
   addr=9.37.51.28 mask=255.255.240.0

goStandby および goInOp の場合は、この別名を除去することが必要になります。 例えば、以下のようになります。

call netsh interface ip delete address "Local Area Connection"
  addr=9.37.51.28

マシン上に複数の NIC がある場合は、最初に、コマンド・プロンプトで次のコマンドを出すことによってどのインターフェースを使用するかを調べてください: netsh interface ip show address。 このコマンドは正しく構成されたインターフェースのリストを戻し、「ローカル・エリア接続」に番号を付ける (例えば、「ローカル・エリア接続 2」など) ので、どれを使用するかが判別できます。

Linux for S/390® の場合: Dispatcher は、 IP アドレスをある Dispatcher から別の Dispatcher に移動するための無償 ARP を 発行します。したがってこのメカニズムは、基礎ネットワーク・タイプと関連しています。 Linux for S/390 を 稼働しているとき、Dispatcher は、無償 ARP を発行してローカルのインターフェースでアドレスを 構成できるインターフェースでのみ、ネイティブにハイ・アベイラビリティーの引き継ぎ (IP アドレスの移動を含む 完全なもの) を行うことができます。この仕組みは、IUCV や CTC などの point-to-point インターフェースでは正常に動作せず、また qeth/QDIO の一部の構成でも正常に動作しません。

Dispatcher のネイティブな IP 引き継ぎ機能が正常に動作しないこれらのインターフェースや構成の場合には、go スクリプトに適切なコマンドを置き、手動でアドレスを移動することができます。これで、ネットワークの接続形態も確実にハイ・アベイラビリティーの利益を受けられるようになります。

ルール・ベースのロード・バランシングの構成

ルール・ベースのロード・バランシングを使用して、パケットが送信されるサーバー、時刻、および理由を微調整することができます。Load Balancer は最初の優先度から最後の優先度に追加したルールをすべてレビューし、真である最初のルールで停止し、ルールに関連するサーバー間のコンテンツのロード・バランシングを行います。ルールを使用しなくても 宛先およびポートに基づいてロード・バランシングが行われますが、ルールを使用すると接続を分散する機能を拡張することができます。

ルールを構成するときはほとんどの場合、その他の優先度が より高いルールによって渡される要求をキャッチするために、 デフォルトの常に真ルールを構成する必要があります。このデフォルトは、 他のすべてのサーバーがクライアント要求に失敗すると、「残念ながら、このサイトは現在ダウンしています。 後でやり直してください。」応答になる場合があります。

なんらかの理由でサーバーのサブセットを使用する場合は、ルールに基づいたロード・バランシングを Dispatcher および Site Selector とともに使用する必要があります。常に、CBR コンポーネントにはルールを使用し なければなりません

以下のタイプのルールを選択することができます。

ルールを構成に追加し始める前に、ルールがどのような 論理に従うかの計画を立ててください。

ルールの評価方法

すべてのルールには名前、タイプ、優先順位があり、サーバーのセットと一緒に、範囲の開始値および範囲の終了値がある場合があります。 さらに、CBR コンポーネントのコンテンツ・タイプ・ルールには、それと関連付けられている一致している正規表現パターンもあります。 (コンテンツ・ルールの使用法の例とシナリオおよびコンテンツ・ルールに有効なパターン構文については、付録B. コンテンツ・ルール (パターン) 構文を参照してください。)

ルールは優先度の順序で評価されます。すなわち、優先度が 1 (小さい方の数) のルールは、優先度が 2 (大きい方の数) のルールより前に評価されます。条件を満たした最初のルールが適用されます。ルールが満たされると、それ以上のルールの評価は行われなくなります。

ルールが条件を満たすように、以下の 2 つの条件を満たさなければなりません。

  1. ルールの述部は true でなければなりません。すなわち、評価する値が開始値および範囲の終了値の間になければなりません。あるいは、コンテンツが、コンテンツ・ルールの pattern に指定された正規表現と一致していなければなりません。タイプ “true” のルールの場合は、述部は範囲の開始値および範囲の終了値とは無関係に常に満たされます。
  2. ルールと関連するサーバーがある場合、パケットを転送す るには、少なくとも 1 つのサーバーの重みが 0 より大きくなく てはなりません。

ルールにサーバーが関連していない場合は、ルールは、条件 1 のみを満たしている必要があります。この場合は、Dispatcher は接続要求をドロップし、Site Selector はネーム・サーバー要求をエラーで戻し、 CBR は Caching Proxy がエラー・ページを戻すようにします。

ルールが満たされない場合は、Dispatcher はポートで使用可能なサーバーの全セットからサーバーを選択し、Site Selector はサイト名で使用可能なサーバーの全セットからサーバーを選択し、CBR は Caching Proxy がエラー・ページを戻すようにします。

クライアント IP アドレスに基づくルールの使用

このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。

顧客を選別して顧客のアクセス元に基づいてリソースを割り振る場合は、クライアント IP アドレスに基づいたルールを使用することも考えられます。

例えば、IP アドレスの特定のセットからアクセスしているクライアントから、未払いの (したがって望ましくない) トラフィックが ネットワークに多く到着するとします。dscontrol rule コマンドを使用してルールを作成します。例えば、以下のようにします。

dscontrol rule add 9.67.131.153:80:ni type ip 
  beginrange 9.0.0.0 endrange 9.255.255.255

この "ni" ルールは、望ましくないクライアントからの接続を 排除します。その後、アクセスできるようにしたいサーバーをルールに追加します。サーバーをルールに追加しないと、9.x.x.x アドレスからの要求に対してサーバーが まったくサービスを提供しなくなります。

クライアント・ポートに基づくルールの使用

このルール・タイプは Dispatcher コンポーネントでしか使用できません。

要求時に TCP/IP から特定のポートを要求する種類の ソフトウェアをクライアントが使用している場合に、クライアント・ポートに基づくルールを使用したい場合があります。

例えば、クライアント・ポートが 10002 のクライアント要求が、特に大切な顧客からのアクセスであることが分かっているため、このポートを持つすべての要求が特別に高速のサーバーのセットを使用するように 指示するルールを作成することができます。

時刻に基づくルールの使用

このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。

容量の計画のため、時刻に基づくルールを使用することも考えられます。例えば、Web サイトが毎日同じ時間帯に アクセスされる場合は、5 つの追加サーバーをピークの時間帯に専用にすることも考えられます。

時刻に基づくルールを使用する理由として、毎晩深夜に一部のサーバーを停止して保守するときに、保守に必要な時間だけそれらのサーバーを除外するルールを設定することなどがあげられます。

Type of Service (TOS) を基にしたルールの使用法

このルール・タイプは Dispatcher コンポーネントでしか使用できません。

IP ヘッダーの “type of service” (TOS) の内容に基づくルールを使用することも考えられます。 例えば、クライアント要求が、通常のサービスを示す TOS 値付きで着信した場合には、その要求を 1 つのサーバーのセットに経路指定することができます。別のクライアント要求が、優先順位が高いサービスを示す別の TOS 値付きで着信した場合には、その要求を別のサーバーのセットに経路指定することができます。

TOS ルールを使用すると、dscontrol rule コマンドを使用して、各ビットを TOS バイトで完全に構成することができます。 TOS バイトで一致させたい有効なビットには、0 または 1 を使用します。それ以外は、x を使用します。以下は、TOS ルールを追加する例です。

dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x

1 秒当たりの接続数に基づくルールの使用

このルール・タイプは、Dispatcher および CBR コンポーネントで使用可能です。

注:
manager は、以下が機能するように実行しなければなりません。

サーバーのいくつかを他のアプリケーションで共有する必要がある場合に、1 秒当たりの接続数に基づくルールを使用したい場合があります。例えば、以下の 2 つのルールを設定できます。

  1. ポート 80 の 1 秒当たりの接続数が 0 から 2000 の間であれば、2 つのサーバーを使用する
  2. ポート 80 の 1 秒当たりの接続数が 2000 を超える場合は、10 台のサーバーを使用する

Telnet を使用している場合に、1 秒当たりの接続数が特定のレベル以上に増加するときを除いて、Telnet 用の 5 つのサーバーのうち 2 つを予約したい場合もあります。このようにすると、Dispatcher によって、ピーク時に 5 つのサーバーの すべてにわたってロード・バランシングが行われます。

"connection" タイプ・ルールとともにルール評価オプション "upserversonrule" を設定する: 接続タイプ・ルールの使用時、および upserversonrule オプションの設定時に、サーバー・セット内のサーバーの一部が停止した場合、残りのサーバーが過負荷にならないことを確認できます。 詳細については、ルールのサーバー評価オプションを参照してください。

活動状態の総接続数に基づくルールの使用

このルール・タイプは、Dispatcher または CBR コンポーネントで使用可能です。

注:
manager は、以下が機能するように実行しなければなりません。

サーバーが過負荷になり、パケットを破棄する場合に、ポートの活動状態の接続の総数に基づくルールを使用したい場合があります。特定の Web サーバーは、要求に応答するスレッドが十分にない場合でも接続を受け入れ続けます。この結果として、クライアント要求はタイムアウトになり、Web サイトにアクセスしている顧客にサービスが提供されなくなります。活動状態の接続数に基づくルールを使用して、サーバーのプールで容量のバランスを取ることができます。

例えば、サーバーが 250 の接続を受け入れた後、サービスの提供を停止することが経験的に分かっているとします。 dscontrol rule コマンドまたは cbrcontrol rule コマンドを使用してルールを作成することができます。例えば、

dscontrol rule add 130.40.52.153:80:pool2 type active 
  beginrange 250 endrange 500

  または

cbrcontrol rule add 130.40.52.153:80:pool2 type active
  beginrange 250 endrange 500

このルールに、現行のサーバーと、他の処理に使用する追加サーバーを追加します。

予約済み帯域幅および共有帯域幅に基づくルールの使用

予約済み帯域幅および共有帯域幅ルールは、Dispatcher コンポーネントでのみ使用可能です。

帯域幅ルールでは、Dispatcher は、データが特定のサーバー・セットによってクライアントに送達される速度として帯域幅を計算します。 Dispatcher は、サーバー、ルール、ポート、クラスター、および executor のレベルで容量を追跡します。 これらのレベルごとに、バイト・カウンター・フィールド (秒当たりの転送 K バイト数) があります。 Dispatcher はこれらの速度を 60 秒の間隔を基準に計算します。 これらの速度は GUI から、あるいはコマンド行報告の出力から表示できます。

予約済み帯域幅ルール

予約済み帯域幅ルールによって、1 セットのサーバーによって送達された秒当たりの K バイト数を制御できます。 構成中のサーバーのセットごとにしきい値を設定する (指定された帯域幅の範囲を割り振る) ことによって、クラスターとポートの組み合わせごとに使用される帯域幅の量を制御および保証できます。

以下は、reservedbandwidth ルールを追加する例です。

dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth 
  beginrange 0 endrange 300

範囲の開始値と範囲の終了値は秒当たりの K バイト数で指定します。

共有帯域幅ルール

共有帯域幅ルールを構成する前に、sharedbandwidth オプションを指定した dscontrol executor または dscontrol cluster コマンドを使用して、executor レベルまたはクラスター・レベルで共有できる帯域幅の最大容量 (K バイト/秒) を指定しなければなりません。 sharebandwidth 値は、使用可能な合計帯域幅 (合計サーバー容量) を超えることはできません。 dscontrol コマンドを使用して共有帯域幅を設定すると、ルールの上限だけが決まります。

以下は、コマンド構文の例です。

dscontrol executor set sharedbandwidth size
dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth size

sharedbandwidth の size は整数値 (秒当たりの K バイト数) です。デフォルトは 0 です。この値がゼロの場合は、帯域幅を共有できません。

帯域幅をクラスター・レベルで共有すると、クラスターは指定された最大帯域幅を使用できます。 クラスターによって使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が指定された容量より大きい場合、このルールは偽と評価されます。

executor レベルで帯域幅を共有することにより、Dispatcher 構成全体が最大容量の帯域幅を共有することができます。 executor レベルで使用される帯域幅が指定された容量より小さいかぎり、このルールは真と評価されます。 使用される合計帯域幅が定義された容量より大きい場合、このルールは偽と評価されます。

以下は、sharedbandwidth ルールを追加または設定する例です。

dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel value
dscontrol rule set 9.20.34.11:80:shrule sharelevel value

sharelevel の value は executor またはクラスターのいずれかです。sharelevel は sharebandwidth ルールで必須パラメーターの 1 つです。

予約済みおよび共有帯域幅ルールの使用

Dispatcher によって、予約済み帯域幅 ルールを使用して、指定された帯域幅を構成内のサーバーのセットに割り振ることができます。 範囲の開始値と終了値を指定することにより、サーバーのセットによってクライアントに送達される K バイトの範囲を制御できます。 そのルールが真と評価されなくなる (範囲の終了値を超過する) と、次に低い優先度のルールが評価されます。 次に低い優先度のルールが「常に真」ルールの場合、サーバーがクライアントに「サイト・ビジー」応答を返すよう選択できます。

例: ポート 2222 に 3 つのサーバーによるグループがあると想定します。 予約済み帯域幅が 300 に設定されている場合、60 秒の期間に基づいて、1 秒当たりの最大 K バイトは 300 になります。 この速度を超えると、ルールは真と評価されません。 ルールがこれだけであれば、要求を処理するため、3 つのサーバーのうち 1 つが Dispatcher によって選択されます。 より低い優先度の「常に真」ルールがあれば、要求は別のサーバーにリダイレクトされ、「サイト・ビジー」を返される可能性があります。

共有帯域幅ルールは、クライアントへのサーバー・アクセスをさらに提供できます。 特に、予約済み帯域幅ルールに従う低い優先度のルールとして使用される場合、予約済み帯域幅を超過していても、クライアントはサーバーにアクセスできます。

例: 予約済み帯域幅ルールに従う共有帯域幅ルールを使用することによって、制限された方法でクライアントが 3 つのサーバーにアクセスするようにできます。 使用可能な共有帯域幅があるかぎり、ルールは真と評価され、アクセスが認可されます。 共有帯域幅がない場合、そのルールは真ではなく、次のルールが評価されます。 「常に真」ルールが後に続く場合、必要に応じて要求をリダイレクトできます。

前の例で説明した予約済みおよび共有帯域幅の両方を使用することによって、サーバーへのアクセスを認可 (または禁止) するとき、より豊かな柔軟性と制御が可能になります。 帯域幅の使用において特定のポートでのサーバーを限定すると同時に、他のサーバーが可能なかぎり多くの帯域幅を使用するようにできます。

注:
Dispatcher は、サーバーに流れるデータ "acks" のような、クライアントのトラフィックを測ることで帯域幅を追跡します。 何らかの理由で、このトラフィックが Dispatcher から見えない場合、帯域幅ルールを使用するときの結果は予期しないものになります。

メトリック全体ルール

このルール・タイプは Site Selector コンポーネントでしか使用できません。

メトリック全体ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みのサーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値は、実行するルールの範囲内になっていなければなりません。

注:
選択するシステム・メトリック・スクリプトは、ロード・バランシング後のサーバーのそれぞれに存在していなければなりません。

以下は、メトリック全体ルールを構成に追加する例です。

sscontrol rule add dnsload.com:allrule1 type metricall 
  metricname cpuload beginrange 0 endrange 100

メトリック平均ルール

このルール・タイプは Site Selector コンポーネントでしか使用できません。

メトリック平均ルールの場合は、システム・メトリック (cpuload、memload、ユーザー独自にカスタマイズしたシステム・メトリック・スクリプト) を選択し、Site Selector はシステム・メトリック値 (ロード・バランシング済みの各サーバーに常駐している Metric Server エージェントによって戻される) とルールに指定されている範囲の開始値および終了値と比較します。サーバー・セット内のすべてのサーバーの 現行システム・メトリック値の 平均 が、実行するルールの範囲内になっていなければなりません。

注:
選択するシステム・メトリック・スクリプトは、ロード・バランシング後のサーバーのそれぞれに存在していなければなりません。

以下は、メトリック平均ルールを構成に追加する例です。

sscontrol rule add dnsload.com:avgrule1 type metricavg 
  metricname cpuload beginrange 0 endrange 100

常に真であるルールの使用

このルール・タイプは、Dispatcher、CBR、または Site Selector コンポーネントで使用できます。

“常に真” のルールを作成することができます。このようなルールは、関連するサーバーがすべて停止しない限り、常に選択されます。このため、通常は、他のルールよりも 優先順位が低くなければなりません。

複数の “常に真” ルールを用意して、それぞれについて関連するサーバーのセットを持たせることができます。使用可能なサーバーを持つ最初の true のルールが選択されます。例えば、6 つのサーバーを持っているとします。このうちの 2 つに、両方とも停止してしまわない限り、あらゆる状況でトラフィックを処理させます。最初の 2 つのサーバーが停止した場合は、サーバーの 2 番目のセットにトラフィックを処理させます。これらのサーバーが 4 つとも停止した場合は、最後の 2 つのサーバーを使用してトラフィックを処理させます。この場合は、3 つの “常に真” ルールを設定することができます。サーバーの最初のセットは、少なくとも 1 つが稼働している限り常に選択されます。両方とも停止した場合は、2 番目のセットから 1 つ選択され、以下同様に行われます。

他の例として、“常に真” ルールによって、設定済みのどのルールとも着信クライアントが一致しない場合にサービスが提供されないようにしたい場合があります。以下のように dscontrol rule コマンドを使用してルールを作成します。

dscontrol rule add 130.40.52.153:80:jamais type true priority 100

サーバーをルールに追加しないと、クライアント・パケットが応答なしのままドロップしてしまいます。

注:
常に真ルールを作成する場合は、開始範囲や終了範囲を設定する必要はありません。

複数の “常に真” ルールを定義して、優先順位のレベルを変更することによって、実行するルールを調整することができます。

要求コンテンツに基づくルールの使用

このルール・タイプは、CBR コンポーネントまたは Dispatcher コンポーネント (Dispatcher の CBR 転送方式を使用している場合) で使用可能です。

コンテンツ・タイプ・ルールを使用して、ユーザー・サイトのトラフィックのなんらかのサブセットを処理するようにセットアップされたサーバー・セットに要求を送信します。例えば、あるサーバー・セットを使用してすべての cgi-bin 要求を処理し、別のサーバー・セットを使用してすべてのストリーミング・オーディオ要求を処理し、さらに別のサーバー・セットを使用してその他のすべての要求を処理することができます。 cgi-bin ディレクトリーへのパスと一致するパターンを持つルールを追加し、ストリーミング・オーディオ・ファイルのファイル・タイプと一致するパターンを持つルールを追加し、さらにその他のトラフィックを処理するための、常に真のルールを追加します。 次に、該当するサーバーをそれぞれのルールに追加します。

重要: コンテンツ・ルールおよびコンテンツ・ルールに有効なパターン構文の使用法の例とシナリオについては、付録B. コンテンツ・ルール (パターン) 構文を参照してください。

ポート類縁性のオーバーライド

ポート類縁性のオーバーライドを使用すると、特定サーバーに対するポートのスティッキー性をオーバーライドすることができます。 例えば、各アプリケーション・サーバーへの接続量を制限するルールを使用している とします。そして、オーバーフロー・サーバーは、そのアプリケーションに対して、“please try again later (後でもう一度お試しください)” というメッセージを常に出すように設定されているとします。 ポートの stickytime 値は 25 分です。したがって、クライアントがそのサーバーに対してスティッキーになることは望ましくありません。 ポート類縁性のオーバーライドを使用すると、オーバーフロー・サーバーを変更して、通常そのポートに関連した類縁性を変更することができます。 クライアントが次回にクラスターを要求するとき、オーバーフロー・サーバーではなく、最も使用可能なアプリケーション・サーバーでロード・バランシングが行われます。

サーバーの sticky オプションを使用したポート類縁性のオーバーライドのためのコマンド構文についての詳細は、dscontrol server — サーバーの構成を参照してください。

構成へのルールの追加

サンプル構成ファイルを編集することによって、あるいはグラフィカル・ユーザー・インターフェース (GUI) によって、dscontrol rule add コマンドを使用してルールを追加できます。定義したすべてのポートに 1 つ以上のルールを追加することができます。

これは、ルールを追加してから、ルールが真の場合にサービスを提供するサーバーを 定義するという 2 つのステップの処理です。例えば、システム管理者が サイトの各部門からのプロキシー・サーバーの使用の程度を追跡するとします。IP アドレスは部門ごとに与えられます。 クライアント IP アドレスに基づくルールの最初のセットを作成して、各部門の負荷を分割します。

dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255
dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255
dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255

次に、 異なるサーバーを各ルールに追加してから、各サーバーの負荷を測定し、 それらが使用したサービスに対して部門への請求が正しく行われるように します。例えば、以下のようになります。

dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45
dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63
dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47

ルールのサーバー評価オプション

サーバー評価オプションは Dispatcher コンポーネントでのみ使用可能です。

dscontrol rule コマンドには、ルールのサーバー評価オプションがあります。evaluate オプションはポートのすべてのサーバー間のルールの条件を評価すること、あるいはルール内のサーバーだけの間のルールの条件を評価することを選択するために使用します。(Load Balancer の初期バージョンでは、ポート上のすべてのサーバー間の各ルールの条件を測ることしかできませんでした。)

注:
  1. サーバー評価オプションが有効なのは、サーバーの特性を基にした判断を行うルール (合計接続数 (/ 秒) ルール、活動中の接続数ルール、および予約済み帯域幅ルール) の場合だけです。
  2. "connection" タイプ・ルールには、— upserversonrule を選択するための追加の評価オプションがあります。 詳細については、1 秒当たりの接続数に基づくルールの使用を参照してください。

以下は、予約済み帯域幅ルールに評価オプションを追加または設定する例です。

dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate level 
dscontrol rule set 9.22.21.3:80:rbweval evaluate level

evaluate level は、port、rule、または upserversonrule のいずれかに設定できます。デフォルトは port です。

ルール内のサーバーの評価

ルール内のサーバー間のルールの条件を測るためのオプションによって、以下の特性を使用して 2 つのルールを構成できます。

結果は、トラフィックが最初のルール内のサーバーのしきい値を超えると、 トラフィックは 2 番目のルール内の「サイト・ビジー」サーバーに 送信されます。トラフィックが最初のルール内のサーバーのしきい値を下回ると、新規トラフィックは最初のルール内のサーバーにもう一度続けられます。

ポート上のサーバーの評価

前の例で説明した 2 つのルールを使用して、evaluate オプションを最初のルール (ポート上のすべてのサーバー間でルールの条件を評価) の port に設定した場合は、トラフィックがそのルールのしきい値を超えると、トラフィックは 2 番目のルールと関連付けられている「サイト・ビジー」サーバーに送信されます。

最初のルールは、ポート上のすべてのサーバー・トラフィック (「サイト・ビジー」サーバーを含む) を測って、そのトラフィックがしきい値を超えているかどうかを判断します。最初のルールに関連したサーバーの輻輳が低下すると、ポートのトラフィックはまだ最初のルールのしきい値を超えているので、トラフィックは「サイト・ビジー」サーバーに送信され続けるという、不測の結果が起こる場合があります。

Load Balancer の類縁性機能の動作

Dispatcher および CBR コンポーネントの場合: クラスターのポートをスティッキーになるよう構成すると、類縁性機能が使用可能になります。 クラスターのポートをスティッキーになるように構成すると、以降のクライアント要求を同じサーバーに送信することができます。 これは、executor、クラスター、またはポート・レベルのスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不可になります。

ポート間類縁性を使用可能にしている場合は、共有ポートの stickytime 値は同じ (ゼロ以外) でなければなりません。 詳しくは、ポート間類縁性を参照してください。

Site Selector コンポーネントの場合: サイト名をスティッキーになるよう構成すると、類縁性機能が使用可能になります。 sitename をスティッキーとして構成することにより、複数のネーム・サービス要求に対してクライアントは同じサーバーを使用できます。 これは、サイト名のスティッキー時間を秒単位で設定することによって行います。 この機能は、スティッキー時間を 0 に設定すると使用不可になります。

サーバーのスティッキー時間値は、ある接続がクローズしてから 新しい接続がオープンするまでの時間間隔で、この間にクライアントは、 最初の接続で使用したサーバーと同じサーバーに送られます。スティッキー時間 の有効期限が切れると、クライアントは最初のサーバーとは異なるサーバ ーに送られる場合が あります。サーバーのスティッキー時間値は、dscontrol executor、 port、または cluster コマンドを使用して構成されます。

類縁性が使用不可な場合の振る舞い

類縁性機能が使用不可な場合に、新しい TCP 接続がクライアントから受信されると、Load Balancer は、その時点の適切なサーバーを時間内に選出してパケットを転送します。 次の接続が同じクライアントから到着すると、Load Balancer はその接続を関連のない新しい接続として処理し、その時点の適切なサーバーを時間内に再度選出します。

類縁性が使用可能な場合の振る舞い

類縁性機能を使用可能にすると、以降の要求を同じクライアントから受け取った場合に、その要求は同じサーバーに送信されます。

時間が経過すると、クライアントはトランザクションを終了し、類縁性レコードが廃棄されます。これがスティッキー "時間" の意味です。各類縁性レコードは、秒単位の "スティッキー時間" の間だけ存在し続けます。次の接続がスティッキー時間内に受信されると、類縁性レコードは有効のままになり、要求は同じサーバーに送信されます。次の接続がスティッキー時間外に受信されると、レコードは除去されます。その時間の後に受信される接続については、新しいサーバーがその接続に対して選択されます。

サーバーをオフラインにするには、サーバー・ダウン・コマンド (dscontrol server down) を使用します。サーバーが終了するのは、スティッキー時間値の有効期限が切れてからです。

ポート間類縁性

ポート間類縁性は Dispatcher コンポーネントの MAC および NAT/NATP 転送方式にしか適用されません。

ポート間類縁性は、複数のポートを取り扱うために拡張されたスティッキー機能です。 例えば、クライアント要求を最初に 1 つのポートで受け取り、次の要求を別のポートで受け取る場合、ポート間類縁性を使用すると、Dispatcher はそのクライアント要求を同じサーバーに送信することができます。 この機能を使用するには、ポートを以下のようにしなければなりません。

2 つ以上のポートが、同じ crossport にリンクできます。同じポートまたは共有ポートの同じクライアントから引き続き接続が着信すると、同じサーバーがアクセスされます。以下は、ポート間類縁性をもつ複数のポートをポート 10 に構成している例です。

dscontrol port set cluster:20 crossport 10
dscontrol port set cluster:30 crossport 10
dscontrol port set cluster:40 crossport 10

ポート間類縁性が確立されると、ポートの stickytime 値を柔軟に変更することができます。 ただし、すべての共有ポートの stickytime 値を同じ値に変更することをお勧めします。そうでないと、予想外の結果が発生する場合があります。

ポート間類縁性を除去するには、crossport 値を独自のポート番号に戻します。crossport オプションのコマンド構文に関する詳細については、dscontrol port — ポートの構成を参照してください。

類縁性アドレス・マスク (stickymask)

類縁性アドレス・マスクは Dispatcher コンポーネントにしか適用されません。

類縁性アドレス・マスクは、共通サブネット・アドレスを基に、クライアントをグループ化するためにスティッキー機能を拡張したものです。 dscontrol port コマンドに stickymask を指定することにより、32 ビット IP アドレスの共通高位ビットをマスクできます。 この機能が構成された場合、クライアント要求が最初にポートに接続すると、同じサブネット・アドレス (マスクされているアドレスのその部分で表される) をもつクライアントからの以降の要求すべてが、同じサーバーに送信されます。

注:
stickymask を使用可能にするには、stickytime が非ゼロ値でなければなりません。

例えば、同じネットワーク Class A アドレスをもつすべての着信クライアント要求を同じサーバーに送信したい場合は、そのポートの stickymask 値を 8 (ビット) に設定します。 同じネットワーク Class B アドレスをもつクライアント要求をグループ化するには、stickymask 値を 16 (ビット) に設定します。 同じネットワーク Class C アドレスをもつクライアント要求をグループ化するには、stickymask 値を 24 (ビット) に設定します。

最良の結果を得るためには、最初の Load Balancer を開始時に、stickymask 値を設定します。stickymask 値を動的に変更すると、予期しない結果が発生します。

ポート間類縁性との相互作用: ポート間類縁性を使用可能にしている場合は、共有ポートの stickymask 値は同じでなければなりません。 詳しくは、ポート間類縁性を参照してください。

類縁性アドレス・マスクを使用可能にするには、以下のような dscontrol port コマンドを発行します。

dscontrol port set cluster:port stickytime 10 stickymask 8

可能な stickymask 値は 8、16、24 および 32 です。 値 8 は、IP アドレス (ネットワーク Class A アドレス) の 最初の 8 の高位ビットをマスクすることを指定します。値 16 は、IP アドレス (ネットワーク Class B アドレス) の 最初の 16 の高位ビットをマスクすることを指定します。 値 24 は、IP アドレス (ネットワーク Class C アドレス) の 最初の 24 の高位ビットをマスクすることを指定します。 値 32 を指定すると、IP アドレス全体をマスクしていて、類縁性アドレス・マスク機能を効果的に使用不可にします。stickymask のデフォルト値は 32 です。

stickymask (類縁性アドレス・マスク機能) のコマンド構文に関する詳細については、dscontrol port — ポートの構成を参照してください。

サーバー接続処理の静止

処理の静止は、Dispatcher および CBR コンポーネントに適用されます。

何らかの理由 (更新、アップグレード、保守など) でサーバーを Load Balancer 構成から除去するために、dscontrol manager quiesce コマンドを使用できます。quiesce サブコマンドによって、既存の接続は、(切断しないで) 完了し、その接続がスティッキーと指定されていて、スティッキー時間が満了していると、その後のクライアントからの新規接続のみを静止サーバーに転送できます。quiesce サブコマンドはそのサーバーへのその他のいかなる新規接続も認可しません。

スティッキー接続の処理の静止

スティッキー時間が設定されていて、スティッキー時間が満了する前に新規接続を (静止したサーバーの代わりに) 別のサーバーに送信したい場合は、quiesce “now" を使用します。 以下は、サーバー 9.40.25.67 を静止する now オプションの使用例です。

dscontrol manager quiesce 9.40.25.67 now

now オプションは、スティッキー接続を次のように処理する方法を判別します。

クライアント要求の内容に基づくルールの類縁性オプション

dscontrol rule コマンドには、以下のタイプの類縁性を指定できます。

affinity オプションのデフォルトは "none" です。 活動 Cookie、受動 Cookie、または URI に対する rule コマンドで affinity オプションを設定するためには、port コマンドの stickytime オプションはゼロ (使用不可) になっていなければなりません。 類縁性がルールに対して設定されていると、そのポートで stickytime は使用可能にはできません。

活動 Cookie 類縁性

活動 Cookie 類縁性フィーチャーが適用されるのは、CBR コンポーネントに対してだけです。

これは、特定のサーバーにクライアント「スティッキー」を作成する方法を提供しています。この機能は、ルールのスティッキー時間を正数に設定し、類縁性を “activecookie” に設定することによって使用可能となります。これは、ルールを追加するか、あるいは rule set コマンドを使用すると実行できます。コマンド構文の詳細については、dscontrol rule - ルールの構成を参照してください。

活動 Cookie 類縁性に対してルールが使用可能になると、同じクライアントからの正常に実行された要求が最初に選択したサーバーに送信される間に、標準 CBR アルゴリズムを使用して新規クライアント要求のロード・バランスされます。選択したサーバーは、クライアントへの応答で Cookie として保管されます。クライアントの将来の要求に Cookie が入っていて、各要求がスティッキー時間間隔内に到達する限り、クライアントは初期サーバーとの類縁性を保守します。

活動 cookie 類縁性は、同じサーバーに対する任意の期間のロード・バランシングをクライアントが継続することを確認するために使用されます。 これは、クライアント・ブラウザーが保管する Cookie を送信することによって実行されます。 Cookie には、決定を行うために使用した cluster:port:rule、ロード・バランシングを行ったサーバー、および類縁性が有効でなくなったときのタイムアウト・タイム・スタンプが入っています。 Cookie はフォーマット: IBMCBR=cluster:port:rule+server-time! になっています。 cluster:port:rule および server 情報はエンコードされているため、CBR 構成に関する情報は公開されません。

活動状態の Cookie 類縁性の機能

オンにされた活動 Cookie 類縁性があるルールが起動されると常に、クライアントによって送信される Cookie が調べられます。

次にこの新規 Cookie はクライアントに戻るヘッダーに挿入され、クライアントのブラウザーが Cookie を受け入れるように構成されている場合は以降の要求を戻します。

Cookie の類縁性インスタンスはそれぞれ、長さ 65 バイトで、感嘆符で終了します。 この結果として、4096 バイトの Cookie は、ドメインごとに約 60 の活動状態 Cookie ルールを持つことができます。 Cookie が完全に一杯になると、すべての有効期限切れ類縁性インスタンスが除去されます。 すべてのインスタンスがまだ有効な場合、最も古いものがドロップされ、現在のルール用のインスタンスが追加されます。

注:
CBR は、古いフォーマットの IBMCBR Cookie のオカレンスがプロキシーに見つかったとき、それらを置き換えます。

ポート・スティッキー時間がゼロ (使用不可) である場合は、ルール・コマンドの活動 Cookie 類縁性オプションに設定できるのは activecookie だけです。 活動 Cookie 類縁性がルールに対して活動状態になっていると、そのポートで stickytime は使用可能にはできません。

活動 Cookie 類縁性を使用可能にする方法

特定のルールに対して、活動 cookie 類縁性を使用可能にするには、rule set コマンドを使用してください。

rule set cluster:port:rule stickytime 60
rule set cluster:port:rule affinity activecookie

活動 Cookie 類縁性を使用する理由

ルール・スティッキーの作成は、通常はサーバー上のクライアント状態を保管する CGI またはサーブレットに使用されます。この状態は、Cookie ID によって識別されます (これがサーバー Cookie です)。クライアント状態は選択したサーバー上にのみ存在するので、 クライアントは要求間で状態を保持するためにそのサーバーからの Cookie を必要とします。

活動状態の Cookie (クッキー) 類縁性の有効期限のオーバーライド

活動状態の Cookie 類縁性には、現在のサーバー時刻にスティッキー時間間隔を加算し、さらに 24 時間を加えたデフォルトの有効期限があります。 クライアント (CBR マシンに要求を送信している側) のシステムの時刻が不正確であると (例えば、サーバー時刻よりも 1 日進んでいると)、これらのクライアントのシステムでは、Cookie が既に期限切れになっていると思い、CBR からの Cookie を無視してしまいます。 さらに長い有効期限を設定するには、cbrserver スクリプトを変更します。 これを行うためには、スクリプト・ファイル内の javaw 行を編集して、LB_SERVER_KEYS の後に -DCOOKIEEXPIREINTERVAL=X というパラメーターを追加します (ただし、X は有効期限に加算する日数です)。

AIX®、Solaris、 および Linux システムでは、 cbrserver ファイルは /usr/bin ディレクトリーにあります。

Windows システムでは、 cbrserver ファイルは ¥winnt¥system32 ディレクトリーにあります。

受動 cookie 類縁性

受動 cookie 類縁性は、Dispatcher コンポーネントの Content Based Routing (CBR) 転送方式 および CBR コンポーネントに適用されます。Dispatcher の CBR 転送方式を構成する方法については、Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)を参照してください。

受動 cookie 類縁性は、クライアントを特定のサーバーに対してスティッキーにする手段を提供します。ルールの類縁性が "passivecookie" に設定されていると、受動 cookie 類縁性によって、サーバーによって生成された自己識別 cookies を基にして、同一サーバーに対する類縁性で Web トラフィックをロード・バランシングできます。受動 cookie 類縁性はルール・レベルで構成してください。

ルールが始動されると、受動 cookie 類縁性が使用可能になっている場合は、Load Balancer はクライアント要求の HTTP ヘッダー中の cookie 名に基づいてサーバーを選択します。Load Balancer によって、クライアントの HTTP ヘッダーの cookie 名と各サーバーに対して構成済みの cookie 値との比較が開始されます。

Load Balancer は、cookie 値にクライアントの cookie 名を 含む サーバーを最初に見つけたとき に、要求に対してそのサーバーを選択します。

注:
Load Balancer にはこの柔軟性があり、サーバーが可変部分を付加した静的部分を持つ cookie 値を生成する可能性のあるケースを処理します。例えば、サーバーの cookie 値がタイム・スタンプ (可変値) を付加したサーバー名 (静的値) である可能性がある場合などが該当します。

クライアント要求中の cookie 名が見つからないか、サーバーの cookie 値の内容のいずれとも一致しない場合は、サーバーは既存のサーバー選択か重み付きラウンドロビン技法を使用して選択されます。

受動 cookie 類縁性を構成するには、以下を行います。

ポート・スティッキー時間がゼロ (使用不可) の場合は、ルール・コマンドの受動 cookie 類縁性オプションに設定できるのは passivecookie だけです。受動 cookie 類縁性がルールに対して活動状態になっていると、ポートに対して stickytime は使用可能にはできません。

URI 類縁性

URI 類縁性は、Dispatcher の CBR 転送方式および CBR コンポーネントに適用されます。CBR 転送方式を構成する方法については、Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)を参照してください。

URI 類縁性によって、固有のコンテンツを個々の個々の各サーバーにキャッシュできる、Caching Proxy サーバーに対して Web トラフィックをロード・バランシングできます。 この結果として、サイトのキャッシュの容量は、複数のマシン上のコンテンツの冗長なキャッシュを除去することによって、効果的に増加することになります。 URI 類縁性はルール・レベルで構成します。ルールが始動されていると、URI 類縁性が使用可能になっていて、同一セットのサーバーがアップになっていて応答している場合は、Load Balancer は同じ URI を付けて新規着信クライアント要求を同じサーバーに転送します。

一般に、Load Balancer は、同一のコンテンツを提供する複数のサーバーに要求を分散できます。キャッシュ・サーバーのグループとともに Load Balancer を使用すると、頻繁にアクセスされるコンテンツは、結局、すべてのサーバーのキャッシュに入れられた状態になります。これは、複数のマシンのキャッシュに入れられた同一のコンテンツを複製することによって、非常に高いクライアントの負荷をサポートします。これが特に役立つのは、高いボリュームの Web サイトの場合です。

しかし、Web サイトが非常に多様なコンテンツに対してクライアント・トラフィックの適度のボリュームをサポートしていて、一段と大容量のキャッシュを複数のサーバー間に広げたい場合は、ユーザー・サイトは、各キャッシュ・サイトに固有のコンテンツが入っていて、Load Balancer がそのコンテンツが入っているキャッシュ・サーバーだけに要求を分散すると一層効果的に実行されることになります。

URI 類縁性を使用すると、Load Balancer によって、キャッシュに入れられたコンテンツを個々のサーバーに分散して、複数マシンでの冗長なキャッシュを除去できます。この機能強化によって、Caching Proxy サーバーを使用する多様なコンテンツ・サーバー・サイトのパフォーマンスは向上することになります。同一サーバーに送信されるのは同一の要求なので、コンテンツは単一サーバーでのみキャッシュに入れられます。さらに、キャッシュの有効サイズは、各新規サーバー・マシンがプールに追加されることによってさらに増大します。

URI 類縁性を構成するには、以下を行います。

広域 Dispatcher サポートの構成

この機能は Dispatcher コンポーネントにのみ使用可能です。

Dispatcher の広域サポートを使用中ではなく、Dispatcher の nat 転送方式を使用中ではない場合、Dispatcher 構成は、Dispatcher マシンおよびそのサーバーはすべてが同一の LAN セグメントに接続されていることが必要です (図 32 を参照してください)。 クライアントの要求は Dispatcher マシンに送られ、さらにサーバーに送信されます。 サーバーから、応答が直接クライアントに返されます。

図 32. 単一の LAN セグメントから構成される構成の例
単一の LAN セグメント

広域 Dispatcher 機能では、リモート・サーバー として知られる オフサイト・サーバーのサポートが追加されています (図 33 を参照してください)。 GRE がリモート・サイトでサポートされていなくて、Dispatcher の NAT 転送方式が使用中でない場合は、そのリモート・サイトは、リモート Dispatcher マシン (Dispatcher 2) およびそのローカル接続されたサーバー (サーバー G、サーバー H、およびサーバー I) から成っていなければなりません。 クライアントのパケットは、インターネットからイニシャル Dispatcher マシンへ移動します。そのイニシャル Dispatcher マシンから、 パケットは、地理的リモート Dispatcher マシンおよびそのローカル接続サーバーの 1 つに移動します。

Dispatcher マシンはすべて (ローカルおよびリモート)、広域構成を稼働するために、 同じタイプのオペレーティング・システムおよびプラットフォーム上になければなりません

図 33. ローカルおよびリモートのサーバーを使用する構成の例
ローカル・サーバーおよびリモート・サーバー

これによって、1 つのクラスター・アドレスで、世界中のクライアント要求をすべてサポートするとともに、世界中のサーバーに負荷を分散させることができます。

さらに、パケットを最初に受信する Dispatcher マシンは、引き続きローカル・サーバーに接続しておくことができ、ローカル・サーバーとリモート・サーバーの間で負荷を分散させることができます。

コマンド構文

広域サポートを構成するには、以下を行います。

  1. サーバーを追加する。サーバーを Dispatcher に追加する場合は、サーバーがローカルであるかリモートであるかを 定義しなければなりません (上記を参照してください)。サーバーを追加してローカルとして定義するには、ルーターを指定せずに dscontrol server add コマンドを出します。これはデフォルトです。サーバーをリモートとして定義するには、リモート・サーバーに到達するために Dispatcher が パケットを送信しなければならないルーターを指定しなければなりません。サーバーは別の Dispatcher でなければならず、サーバーのアドレスは Dispatcher の非転送先アドレスでなければなりません。例えば、図 34 において、LB 2LB 1 の下の リモート・サーバーとして追加する場合は、ルーター 1 をルーター・アドレスとして定義しなければなりません。一般的な構文を以下に示します。
    dscontrol server add cluster:port:server router address

    router キーワードの詳細については、dscontrol server — サーバーの構成を参照してください。

  2. 別名を構成する。インターネットからのクライアント要求を受信する最初の Dispatcher マシンでは、 executor configure コマンドを使用して クラスター・アドレスに別名を割り当てなければなりません。 (Linux または UNIX システムの場合は、executor configure また は ifconfig コマンドが使用できます。) ただし、リモート Dispatcher マシンでは、クラスター・アドレスには、ネットワーク・インターフェース・カードへの 別名が割り当てられません

Dispatcher の広域サポートとリモート advisor の使用

エントリー・ポイント Dispatcher の場合:

エントリー・ポイント Dispatcher は第 2 レベル Dispatcher をサーバーと見なします。また、エントリー・ポイント Dispatcher はサーバーとしての第 2 レベル Dispatcher の正常性をモニターし、結果をその Dispatcher の実 IP に結び付けます。

リモート Dispatcher の場合: それぞれのリモート・クラスター・アドレスごとに、以下の構成ステップを行います。 リモート Dispatcher ロケーションにあるハイ・アベイラビリティー構成の場合は、 両方のマシンでこれらのステップを実行しなければなりません。

AIX システム

HP-UX システム、Linux、Solaris、 および Windows システム

構成の例

図 34. リモート Load Balancer がある構成の広域の例
リモート Load Balancer がある広域構成

この例は、図 34 で説明する構成に適用します。

ここでは、Dispatcher マシンを構成して、ポート 80 のクラスター・アドレス xebec を サポートする方法について説明します。LB1 は 『エントリー・ポイント』 Load Balancer として定義されています。 イーサネット接続を想定します。LB1 には定義済みのサーバーが 5 つ、すなわち、3 つのローカル (ServerA、ServerB、ServerC) および 2 つのリモート (LB2 および LB3) があることに注意してください。 リモートの LB2 および LB3 には、それぞれ 3 つのローカル・サーバーが定義されています。

最初の Dispatcher (LB1) のコンソールで、以下を行います。

  1. executor を開始します。

    dscontrol executor start

  2. Dispatcher マシンの非転送先アドレスを設定します。

    dscontrol executor set nfa LB1

  3. クラスターを定義します。

    dscontrol cluster add xebec

  4. ポートを定義します。

    dscontrol port add xebec:80

  5. サーバーを定義します。
    1. dscontrol server add xebec:80:ServerA
    2. dscontrol server add xebec:80:ServerB
    3. dscontrol server add xebec:80:ServerC
    4. dscontrol server add xebec:80:LB2 router Router1
    5. dscontrol server add xebec:80:LB3 router Router1
  6. クラスター・アドレスを構成します。

    dscontrol executor configure xebec

2 番目の Dispatcher (LB2) のコンソールで、以下を行います。

  1. executor を開始します。

    dscontrol executor start

  2. Dispatcher マシンの非転送先アドレスを設定します。

    dscontrol executor set nfa LB2

  3. クラスターを定義します。

    dscontrol cluster add xebec

  4. ポートを定義します。

    dscontrol port add xebec:80

  5. サーバーを定義します。
    1. dscontrol server add xebec:80:ServerD
    2. dscontrol server add xebec:80:ServerE
    3. dscontrol server add xebec:80:ServerF

3 番目の Dispatcher (LB3) のコンソールで、以下を行います。

  1. executor を開始します。

    dscontrol executor start

  2. Dispatcher マシンの非転送先アドレスを設定します。

    dscontrol executor set nfa LB3

  3. クラスターを定義します。

    dscontrol cluster add xebec

  4. ポートを定義します。

    dscontrol port add xebec:80

  5. サーバーを定義します。
    1. dscontrol server add xebec:80:ServerG
    2. dscontrol server add xebec:80:ServerH
    3. dscontrol server add xebec:80:ServerI

Notes®

  1. すべてのサーバー (A-1) で、クラスター・アドレスの別名をループバックに割り当てます。
  2. クラスターおよびポートを、関連するすべての Dispatcher マシン (エントリー・ポイント Dispatcher およびすべてのリモート) で dscontrol を使用して追加します。
  3. 広域サポートとリモート advisor の使用に関する手引きについては、Dispatcher の広域サポートとリモート advisor の使用を参照してください。
  4. 広域サポートでは、経路指定の無限ループは禁止されています。(Dispatcher マシンが他の Dispatcher からのパケットを受信する場合は、第 3 の Dispatcher には転送しません。) 広域は、1 レベルのリモートしかサポートしていません。
  5. 広域は、UDP および TCP をサポートします。
  6. 広域は、ハイ・アベイラビリティーとともに機能します。各 Dispatcher は、(同じ LAN セグメントにある) 隣接する 待機マシンによってバックアップすることができます。
  7. manager および advisor は、広域とともに機能し、使用する場合は、関連する Dispatcher マシンすべてで開始しなければなりません。
  8. Load Balancer は同様のオペレーティング・システムでは WAN のみをサポートします。

GRE (総称経路指定カプセル化) サポート

総称経路指定カプセル化 (GRE) は RFC 1701 および RFC 1702 に指定されているインターネット・プロトコルの 1 つです。GRE を使用することで、Load Balancer はクライアント IP パケットを IP/GRE パケットの内部にカプセル化し、それを GRE をサポートしている OS/390® などのサーバー・プラットフォームに転送できます。 GRE サポートによって、Dispatcher コンポーネントは、1 つの MAC アドレスと関連付けられている複数のサーバー・アドレス当てのパケットをロード・バランシングできます。

Load Balancer は GRE を WAN フィーチャーの一部として実装します。 これにより、Load Balancer は、GRE パケットをアンラップできるすべてのサーバー・システムに対する広域ロード・バランシングを直接提供できます。リモート・サーバーがカプセル化された GRE パケットをサポートしている場合は、Load Balancer はリモート・サイトにインストールされている必要はありません。Load Balancer は、WAN パケットを 10 進数値 3735928559 に設定された GRE キー・フィールドとともにカプセル化します。

図 35. GRE をサポートするサーバー・プラットフォームがある広域の例の構成
GRE をサポートしているサーバーがある広域構成

この例 (図 35) の場合は、GRE をサポートするリモート ServerD を追加するために、WAN サーバーを cluster:port:server 階層内に定義中であるかのように、そのサーバーは Load Balancer 構成内に定義します。

dscontrol server add cluster:port:ServerD router Router1

WAN 用の GRE カプセル化解除の構成 (Linux システムの場合)

Linux システムには、GRE のカプセル化を解除する固有の機能があります。 これによって、Load Balancer は、多くのサーバー・イメージが MAC アドレスを 共有している Linux for S/390 サーバー・イメージに対してロード・バランシングを行うことができます。 これによってエントリー・ポイント Load Balancer は、 リモート・サイトの Load Balancer を経由することなく、 直接 Linux WAN サーバーへのロード・バランシングを行うことが可能になります。 これにより、エントリー・ポイント Load Balancer の advisor は、それぞれのリモート・サーバーで直接操作することもできます。

エントリー・ポイント Load Balancer で、WAN の場合に説明したように構成してください。

それぞれ の Linux バックエンド ・サーバーを構成するには、root として以下のコマンドを実行します。(これらのコマンドは、変更がリブート後も保持されるようにするために、システムの始動機能に追加することができます。)

# modprobe ip_gre
# ip tunnel add gre-nd mode gre ikey 3735928559 
# ip link set gre-nd up
# ip addr add cluster address dev gre-nd
注:
これらの命令を使用して 構成された Linux サーバーは、 エントリー・ポイント Load Balancer と同じ物理セグメント上にあってはなりません。 これは、Linux サーバーが クラスター・アドレスに対する "ARP who-has" 要求に応答するために、 そのクラスター・アドレスへのすべてのトラフィックが ARP の競合の勝者にのみ送られるという、 破綻を引き起こす可能性のある競合状態の原因となるためです。

一般に、Dispatcher のロード・バランシング機能は、当製品が使用されるサイトの内容とは関係なく働きます。ただし、サイトの内容が重要であり、かつ内容に関する判断が Dispatcher の効率に重大な影響を与える可能性がある領域が 1 つあります。これは、リンク・アドレスの領域です。

サイトの個別のサーバーを指すリンクをページで指定すると、強制的にクライアントが特定のマシンにアクセスするようになるので、すべてのロード・バランシング機能が迂回され、効果がなくなってしまいます。このため、 ページに含まれるすべてのリンクで、常に Dispatcher のアドレスを使用してください。 サイトで自動プログラミングを使用して HTML を動的に作成する場合は、使用するアドレスの種類が常に明らかであるとは限りません。ロード・バランシングを最大限に活用するには、明示アドレスに注意して、可能な場合には回避しなければなりません。

プライベート・ネットワーク構成の使用

プライベート・ネットワークを使用する Dispatcher および TCP サーバー・マシンを セットアップすることができます。この構成によって、パフォーマンスに影響を与える可能性がある公衆ネットワーク や外部ネットワークでの競合を削減することができます。

AIX システムの場合は、この構成によって、Dispatcher および TCP サーバー・マシンを SP フレームのノードで実行している場合に、高速な SP ハイパフォーマンス・スイッチを利用することもできます。

プライベート・ネットワークを作成するには、各マシンに少なくとも 2 つの LAN カードを用意し、一方のカードをプライベート・ネットワークに接続しなければなりません。異なるサブネットで 2 番目の LAN カードも 構成しなければなりません。Dispatcher マシンは、プライベート・ネットワークを介して TCP サーバー・マシンに クライアント要求を送信します。

Windows システム: executor configure コマンドを使用して、nonforwarding アドレスを構成してください。

dscontrol server add コマンドを使用して 追加されたサーバーは、プライベート・ネットワーク・アドレスを使用して追加しなければなりません。例えば、図 36 の Apple サーバーの例では、以下のようにコマンドをコーディングしなければなりません。

dscontrol server add cluster_address:80:10.0.0.1

以下のようであってはなりません。

dscontrol server add cluster_address:80:9.67.131.18

Site Selector を使用して負荷情報を Dispatcher に提供している場合は、プライベート・アドレスでの負荷を報告するように Site Selector を構成しなければなりません。

図 36. Dispatcher を使用するプライベート・ネットワークの例
プライベート・ネットワーク

プライベート・ネットワーク構成は Dispatcher コンポーネントでしか使用できません。

ワイルドカード・クラスターを使用したサーバー構成の結合

ワイルドカード・クラスターを使用してサーバー構成を結合する操作は、Dispatcher コンポーネントでしか行えません。

“ワイルドカード” は、複数の IP アドレスに一致するクラスターの機能を指します (すなわち、ワイルドカードとして機能します)。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。

クラスター・アドレスの多くについてロード・バランシングを行っており、ポート/サーバー構成が全クライアントについて同じである場合は、すべてのクラスターを 1 つのワイルドカード・クラスター構成に結合することができます。

この場合でも、Dispatcher ワークステーションのネットワーク・アダプターのいずれかで、各クラスター・アドレスを明示的に構成しなければなりません。ただし、dscontrol cluster add コマンドを使用して 全クラスター・アドレスを Dispatcher 構成に追加する必要はありません。

ワイルドカード・クラスター (アドレス 0.0.0.0) のみを追加して、ロード・バランシングに必要な ポートおよびサーバーを構成します。アドレスを構成したアダプターへのトラフィックについては、すべてワイルドカード・クラスター構成を使用して ロード・バランシングが行われます。

この方法の利点は、最適なサーバーを判別するときに、すべてのクラスター・アドレスへのトラフィックが考慮されることです。1 つのクラスターが受信するトラフィックが多く、サーバーのいずれかで多くの活動状態の接続を作成した場合は、この情報を使用して、他のクラスター・アドレスへのトラフィックについて ロード・バランシングが行われます。

固有のポート/サーバー構成を持つクラスター・アドレスがある場合は、ワイルドカード・クラスターを実際のクラスターと結合し、いくつかを共通構成と結合することができます。固有の構成は、それぞれ実際のクラスター・アドレスに割り当てなければなりません。共通構成は、すべてワイルドカード・クラスターに割り当てることができます。

ワイルドカード・クラスターを使用したファイアウォールのロード・バランシング

ワイルドカード・クラスターを使用しファイアウォールをロード・バランシングする操作は、Dispatcher コンポーネントでしか行えません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。

ワイルドカード・クラスターは、Dispatcher ワークステーションのネットワーク・アダプターで明示的に 構成されていないアドレスへのトラフィックについてロード・バランシングを 行うために使用することができます。これを行うためには、少なくとも、ロード・バランシングを行うトラフィックを Dispatcher が すべて確認することができなければなりません。Dispatcher ワークステーションは、トラフィックのセットに対するデフォルトの経路としてセットアップされていない限り、そのネットワーク・アダプターのいずれでも明示的に構成されていない アドレスへのトラフィックを確認しません。

一度 Dispatcher をデフォルトの経路として構成すると、Dispatcher マシンを介した TCP トラフィックまたは UDP トラフィックは、すべてワイルドカード・クラスター構成を使用してロード・バランシングが行われます。

このアプリケーションの 1 つは、ファイアウォールのロード・バランシングを行うためのものです。ファイアウォールは、すべての宛先アドレスおよび宛先ポートに対するパケットを処理するので、宛先アドレスおよびポートに関係なく、トラフィックのロード・バランシングを行える必要があります。

ファイアウォールは、保護されていないクライアントから保護されたサーバーまでのトラフィック、および保護されたサーバーからの応答をはじめ、保護された側のクライアントから保護されていない側のサーバーへのトラフィック および応答を処理するために使用されます。

2 つの Dispatcher マシンをセットアップし、一方のマシンでは保護されていないファイアウォール・アドレスに対して 保護されていないトラフィックのロード・バランシングを行い、もう一方のマシンでは 保護されたファイアウォール・アドレスに対して保護されたトラフィックのロード・バランシングを 行わなければなりません。これらの Dispatcher の両方が、サーバー・アドレスの異なるセットとともに ワイルドカード・クラスターおよびワイルドカード・ポートを使用しなければならないので、2 つの Dispatcher は 2 つの別個のワークステーションになければなりません。

透過プロキシーに Caching Proxy とワイルドカード・クラスターを使用

Dispatcher コンポーネントの場合、透過プロキシーについて、ワイルドカード・クラスターを Caching Proxy とともに使用することはできません。 クラスター・アドレス 0.0.0.0 を使用して、ワイルドカード・クラスターを指定します。

また、ワイルドカード・クラスター機能によって、Dispatcher を使用して Dispatcher と同じマシン上に ある Caching Proxy サーバーの透過プロキシー機能を使用可能にできます。 これは、Dispatcher コンポーネントからオペレーティング・システムの TCP コンポーネントへの通信が必要なので、AIX のみの機能です。

この機能を使用可能にするには、Caching Proxy によるポート 80 でのクライアント要求の listen を開始しなければなりません。 その後、ワイルドカード・クラスターを構成します (0.0.0.0)。ワイルドカード・クラスターで、ポート 80 を構成します。ポート 80 で、Dispatcher マシンの NFA を唯一のサーバーとして構成します。これで、ポート 80 の任意のアドレスに対するクライアント・トラフィックが、すべて Dispatcher ワークステーションで実行されている Caching Proxy サーバーに 送達されるようになります。 クライアント要求は、通常どおりに代行され、応答が Caching Proxy からクライアントに送信されます。このモードでは、Dispatcher コンポーネントはロード・バランシングを行いません。

ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信

ワイルドカード・ポートは、明示的に構成されたポートに 対するトラフィックではないトラフィックを処理するために使用することができます。例えば、ファイアウォールのロード・バランシングに使用することができます。また、構成されていないポートへのトラフィックが適切に処理されることを 確認するために使用することもできます。サーバーを指定せずにワイルドカード・ポートを定義することによって、構成されていないポートへの要求が確実に廃棄され、オペレーティング・システムには戻されないようにすることができます。 ポート番号 0 (ゼロ) は、ワイルドカード・ポートを指定するために使用します。例えば、以下のようになります。

dscontrol port add cluster:0

FTP トラフィック処理のためのワイルドカード・ポート

受動 FTP およびワイルドカード・ポート処理のためにクラスターを構成すると、受動 FTP はデータ接続のためにデフォルトで非特権 TCP ポート範囲全体を使用します。これは、クライアントが、ロード・バランシング・クラスターを通じた FTP 制御ポートへの既存接続で、Load Balancer によって FTP 制御接続と同じサーバーに自動的に経路指定された同じクラスターへの後続の制御接続および高位ポート接続 (ポート >1023) を持つことを意味します。

同じクラスター上のワイルドカード・ポートと FTP ポートのサーバー・セットが同じでない場合、高位ポート・アプリケーション (ポート >1023) は、クライアントに既存の FTP 制御接続がないと失敗する可能性があります。したがって、同一クラスター上の FTP とワイルドカード・ポートに異なるサーバー・セットを構成することはお勧めしません。このシナリオが望ましい場合は、FTP デーモン受動ポートの範囲は Load Balancer 構成内で構成しなければなりません。

サービス妨害攻撃の検出

この機能は Dispatcher コンポーネントにのみ使用可能です。

Dispatcher は、潜在的な「サービス妨害」攻撃を検出し、アラートによって管理者に通知する機能を提供します。Dispatcher は、 サーバーでハーフ・オープン TCP 接続の著しい量の受信要求 (単純なサービス妨害攻撃 (Denial of Service Attack) の特性) を 分析することによってこれを行います。 サービス妨害攻撃では、サイトは多数の送信元 IP アドレスおよび送信元ポート番号から大量の偽造された SYN パケットを受信しますが、このサイトはそれらの TCP 接続用のその後のパケットを 1 個も受信しません。これにより、サーバー上で多数の TCP 接続がハーフ・オープン状態になり、時を経るとサーバーは非常に低速化して、新規着信接続をまったく受け入れなくなる可能性があります。

注:
サービス妨害攻撃の終了を決定するためには、Dispatcher に対して攻撃されているクラスターとポートを通じた着信トラフィックがなければなりません。Dispatcher は、再びトラフィックが流れ始めるまで、攻撃停止を検出できません。

Load Balancer は、考えられるサービス妨害攻撃 (Denial of Service Attack) のアラートを管理者に通知する、カスタマイズできるスクリプトを起動するユーザー出口を提供します。 次のディレクトリーに、Dispatcher が提供するサンプル・スクリプト・ファイルが入っています。

以下のスクリプトを使用することができます。

これらのファイルを実行するためには、ファイルを次のディレクトリーに移動して、「.sample」ファイル拡張子を除去する必要があります。

DoS 攻撃検出を実装するには、maxhalfopen パラメーターを dscontrol port コマンドで次のように設定します。

dscontrol port set 127.40.56.1:80 maxhalfopen 1000

前述の例では、Dispatcher はハーフ・オープンの現在の合計接続数 (ポート 80 のクラスター 127.40.56.1 にあるすべてのサーバー) としきい値 1000 (maxhalfopen パラメーターによって指定) を比較します。現在のハーフ・オープン接続数がこのしきい値を超えると、アラート・スクリプト (halfOpenAlert) への呼び出しが行われます。ハーフ・オープン接続数がこのしきい値を下回っていると、攻撃は終了していることを示すために、別のアラート・スクリプト (halfOpenAlertDone) への呼び出しが行われます。

maxhalfopen 値を判別する方法を判別する場合: ユーザー・サイトが通常から大量トラフィックへの変化を経験しつつあるときに、定期的に (多分、10 分ごとに) ハーフ・オープン接続報告 (dscontrol port halfopenaddressreport cluster:port) を実行します。 ハーフ・オープン接続報告は、現在の「合計受信ハーフ・オープン接続数」を戻します。 maxhalfopen は、ユーザー・サイトで経験しているハーフ・オープン接続の最大数より 50 から 200% 大きな値に設定する必要があります。

報告される統計データの他に、halfopenaddressreport は、ハーフ・オープン接続になったサーバーにアクセスしたクライアント・アドレス (最大約 8000 個までのアドレスのベア) すべてのログ (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) 中に項目を生成します。

注:
halfOpenAlert および halfOpenAlertDone スクリプトと対応している SNMP トラップがあります。SNMP サブエージェントを構成して実行する場合は、対応するトラップが同じ条件下に送信されて、これがスクリプトを起動します。SNMP サブエージェントの詳細については、Dispatcher コンポーネントでの Simple Network Management Protocol の使用を参照してください。

バックエンド・サーバーのサービス妨害攻撃からの追加保護を提供するために、ワイルドカード・クラスターおよびポートを構成できます。特に各構成済みクラスターの下にサーバーを使用しないワイルドカード・ポートを追加してください。また、ワイルドカード・ポートがあってサーバーがないワイルドカード・クラスターも追加してください。これには、非ワイルドカード・クラスターおよびポートを扱わないすべてのパケットを廃棄する効果があります。ワイルドカード・クラスターおよびワイルドカード・ポートの詳細については、ワイルドカード・クラスターを使用したサーバー構成の結合 および ワイルドカード・ポートを使用した未構成ポート・トラフィックの送信 を参照してください。

バイナリー・ログを使用したサーバー統計の分析

注:
バイナリー・ロギング機能は、Dispatcher および CBR コンポーネントに適用されます。

バイナリー・ログ機能を使用すれば、サーバー情報をバイナリー・ファイルに保管することができます。 これらのファイルを処理して、ある時間にわたって収集されたサーバー情報を分析することができます。

以下の情報が、構成で定義されたサーバーごとのバイナリー・ログに保管されます。

この情報には、manager サイクルの一部として executor から取得されるものもあります。したがって、情報をバイナリー・ログに記録するために、manager が実行されていなければなりません。

dscontrol log コマンド・セットを使用して、バイナリー・ロギングを構成します。

start オプションは、ログ・ディレクトリーにあるバイナリー・ログへのサーバー情報の記録を開始します。ログは、毎時 0 分に その日時をファイル名として作成されます。

stop オプションは、バイナリー・ログへのサーバー情報の 記録を停止します。ログ・サービスは、デフォルトによって停止しています。

set interval オプションは、情報がログに 書き込まれる頻度を制御します。manager はサーバー情報を manager 間隔ごとにログ・サーバーへ送信します。情報は、最後にログにレコードが書き込まれてから、指定した秒数の経過後にログに書き込まれます。 デフォルトでは、ログ記録間隔は 60 秒に設定されています。manager 間隔と ログ記録間隔の設定の間には、相関関係があります。ログ・サーバーは manager 間隔秒数以下の速度で情報を提供するので、manager 間隔より短いログ記録間隔を設定しようとしても、実際には manager 間隔と同じ値に設定されます。このログ記録方法によって、サーバー情報を取り込む頻度を任意に細分化することができます。サーバーの重みを計算するために、manager によって確認されるサーバー情報に対する 変更をすべて取り込むことができます。ただし、おそらく、この情報は、サーバーの使用および傾向の分析に必要ではありません。60 秒ごとにサーバー情報をログ記録すると、時間の経過とともにサーバー情報のスナップショットがとられます。ログ記録間隔を非常に低く設定すると、膨大な量のデータが生成される場合があります。

set retention オプションは、ログ・ファイルが保持される期間を制御します。指定した保存時間よりも古いログ・ファイルは、ログ・サーバーによって削除されます。これは、ログ・サーバーが manager によって 呼び出されている場合にのみ行われるので、manager が停止していると古いログ・ファイルでも削除されません。

status オプションは、ログ・サービスの現行の設定を戻します。これらの設定は、サービスが開始されているかどうか、間隔、および保存時間です。

次のディレクトリーにサンプル Java プログラムおよびコマンド・ファイルが入っています。

このサンプルは、ログ・ファイルからすべての情報を検索して画面に出力する方法を示します。カスタマイズすると、データについて必要な種類の分析を行うことができます。Dispatcher に提供されているスクリプトおよびプログラムの使用例を以下に示します。

dslogreport 2001/05/01 8:00 2001/05/01 17:00

これによって、2001 年 5 月 1 日の午前 8:00 から午後 5:00 までの Dispatcher コンポーネント・サーバー情報の報告書が得られます。 (CBR の場合、cbrlogreport を使用してください。)

連結クライアントの使用

Load Balancer と同一マシンにクライアントを配置する構成を サポートしているのは、Linux システムのみです。

連結クライアント構成は、他のプラットフォームでは正しく機能しない場合があります。 これは、Load Balancer が別の手法を使用して、サポートする各種のオペレーティング・システムで 着信パケットを検査するためです。ほとんどの場合、 Linux 以外のシステムでは、Load Balancer はローカル・マシンからのパケットを 受信しません。ネットワークから入ってくるパケットだけを受信します。このため、 ローカル・マシンからクラスター・アドレスへの要求は、Load Balancer によって受信されず、 サービスの対象にもなりません。