Dispatcher の計画

この章では、Dispatcher コンポーネントのインストールと構成を行う前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。

この章には、以下のセクションが含まれています。

注:
前のバージョンでは、製品は Network Dispatcher として知られており、Dispatcher 制御コマンド名は ndcontrol でした。 Dispatcher 制御コマンド名は、現在 dscontrol です。

計画の考慮事項

Dispatcher は、以下の機能で構成されています。

Dispatcher の 3 つの主要な機能 (executor、manager、および advisor) は、 対話してサーバー間の受信要求を平衡化およびディスパッチします。ロード・バランシング要求とともに、executor は新規の接続、活動中の接続、および終了状態の接続の数をモニターします。また、executor は完了またはリセットした接続のガーベッジ・コレクションも実行し、この情報を manager に提供します。

manager は、executor、advisor、およびシステム・モニター・プログラム (Metric Server など) から 情報を収集します。manager は、受け取った情報に基づいて、各ポートでのサーバー・マシンの重み付けの方法を調整し、新規接続の平衡化で使用する新規の重み値を executor に指定します。

advisor は、割り当てられたポート上の各サーバーをモニターして、サーバーの応答時間とアベイラビリティー を判別した後、この情報を manager に提供します。advisor も、サーバーが起動しているかいないかをモニターします。manager および advisor がないと、executor は、現行サーバーの重み付けに基づいてラウンドロビン・スケジューリングを行います。

転送方式

Dispatcher を使用して、ポート・レベルで指定された MAC 転送、NAT/NAPT 転送、または CBR (Content Based Routing) 転送という 3 つの転送方式のいずれかを選択できます。

Dispatcher の MAC レベル経路指定 (mac 転送方式)

Dispatcher の MAC 転送方式 (デフォルトの転送方式) を使用して、Dispatcher は選択したサーバーへの受信要求のロード・バランシングを行い、 そのサーバーは Dispatcher の介入なしに 直接 クライアントに応答を戻します。この転送方式を使用すると、Dispatcher がモニターするのはクライアントからサーバーへのインバウンド・フローだけです。サーバーからクライアントへのアウトバウンド・フローをモニターする必要はありません。このためにアプリケーションに対する影響を大幅に軽減し、ネットワーク・パフォーマンスを向上させることができます。

転送方式は、dscontrol port add cluster:port method value コマンドを使用してポートを追加するときに選択できます。デフォルト転送方式値は mac です。メソッド・パラメーターを指定できるのは、ポートが追加されるときだけです。一度ポートを追加すると、転送方式の設定は変更できません。詳細については、dscontrol port — ポートの構成を参照してください。

Linux の 制約事項: Linux システムでは、 ARP を使用してハードウェア・アドレスを IP アドレスに公示する、ホスト・ベースのモデルを使用しています。 このモデルは、Load Balancer の MAC 転送方式における、バックエンド・サーバーまたは高可用性連結サーバーの要件に合致していません。 Linux における Load Balancer の MAC 転送の使用時のループバック別名割り当ての代替手段には、 Linux システムの動作を 変更し、Load Balancer の MAC 転送方式と互換性を持たせる方法がいくつか記述されているので、 参照してください。

zSeries または S/390 サーバーを使用する場合の Linux の 制限: オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する場合には、 いくつかの制限があります。考えられる次善策については、問題: Linux で、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の Dispatcher 構成の制限を参照してください。

Dispatcher の NAT/NAPT (nat 転送方式)

Dispatcher のネットワーク・アドレス変換 (NAT) またはネットワーク・アドレス・ポート変換 (NAPT) 機能を使用すると、ロード・バランシングされたサーバーがローカル接続ネットワーク上に置かれるという制限がなくなります。サーバーをリモート・ロケーションに置きたいときには、GRE/WAN カプセル化技法ではなく、NAT 転送方式技法を使用してください。また、NAPT 機能を使用して、各ロード・バランシングされたサーバー・マシン (各デーモンが固有のポートを listen しています) 上に常駐している複数のサーバー・デーモンにアクセスできます。

複数のデーモンを使用して 1 つのサーバーを構成する方法には、次の 2 つがあります。

このアプリケーションは、上位レベルのアプリケーション・プロトコル (例えば HTTP、SSL、IMAP、POP3、 NNTP、SMTP、Telnet など) と適切に連動します。

制限:

Dispatcher マシンには、3 つの IP アドレス (NFA アドレス、クラスター・アドレス、リターン・アドレス) が必要です。NAT/NAPT を実装するには、次のようにしてください (Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップも参照)。

Dispatcher のコンテンツ・ベースのルーティング (CBR 転送方式)

この Dispatcher コンポーネントにより、Caching Proxy を使用しなくても HTTP (「コンテンツ」タイプ・ルールを使用) および HTTPS (SSL セッション ID アフィニティーを使用) の コンテンツ・ベースのルーティング を実行できます。 HTTP および HTTPS トラフィックの場合は、Dispatcher コンポーネントの CBR 転送方式は、CBR コンポーネントよりも高速の コンテンツ・ベースのルーティング を提供できます。 これには Caching Proxy が必要です。

HTTP の場合: Dispatcher のコンテンツ・ベースのルーティング におけるサーバー選択は、URL または HTTP ヘッダーのコンテンツに基づきます。 これは「コンテンツ」タイプ・ルールを使用して構成されています。コンテンツ・ルールの構成時には、ルールに検索ストリング "pattern" と一連のサーバーを指定します。新規受信要求の処理時には、このルールは指定されたストリングをクライアントの URL またはクライアント要求で指定された HTTP ヘッダーと比較します。

Dispatcher がクライアント要求でそのストリングを検出すると、Dispatcher は要求をルール内のいずれかのサーバーに転送します。次に Dispatcher は応答データをサーバーからクライアントに中継します ("CBR" 転送方式)。

Dispatcher がクライアント要求でそのストリングを検出しない場合は、Dispatcher はルール内の一連のサーバーからサーバーを選択 しません

注:
コンテンツ・ルールは、CBR コンポーネントに構成されるのと同じ方法で、Dispatcher コンポーネントに構成されます。Dispatcher は、HTTP トラフィックのコンテンツ・ルールを使用できます。ただし、CBR コンポーネントは HTTP および HTTPS (SSL) 両方 のトラフィックのコンテンツ・ルールを使用できます。

HTTPS (SSL) の場合: Dispatcher の Content Based Routing は、クライアント要求の SSL ID セッション・フィールドを基にしてロード・バランシングされます。 SSL では、クライアント要求には前のセッションの SSL セッション ID が入っていて、サーバーは前の SSL 接続のキャッシュを保守します。Dispatcher の SSL ID セッション・アフィニティーにより、クライアントおよびサーバーはサーバーとの前の接続のセキュリティー・パラメーターを使用して新規接続を確立できます。 SSL セキュリティー・パラメーター (共有鍵や暗号化アルゴリズムなど) の再折衝をなくすことにより、サーバーの CPU サイクルが節約され、クライアントへの応答がより高速になります。 SSL セッション ID アフィニティーを使用可能にするには、ポートに指定されるプロトコル・タイプは SSL でなければならず、ポートの stickytime はゼロ以外の値に設定しなければなりません。stickytime が経過すると、クライアントは前のとは異なる別のサーバーに送信します。

Dispatcher マシンには、3 つの IP アドレス (NFA アドレス、クラスター・アドレス、リターン・アドレス) が必要です。Dispatcher のコンテンツ・ベースのルーティング を実装するには、次のようにしてください (Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップも参照)。

注:
高可用性の接続レコード複製機能 (バックアップ Dispatcher マシンがプライマリー・マシンを引き継ぐときに クライアントの接続が除去されなくなります) は、Dispatcher の Content Based Routing ではサポートされて いません

Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップ

図 12. Dispatcher の NAT または CBR 転送方式の使用例
Dispatcher の NAT または CBR 転送を使用するため構成

Dispatcher マシンには、少なくとも 3 つの IP アドレスが必要です。 図 12 で、Dispatcher の NAT または CBR 転送方式の最小構成を行うために 必要なステップは以下のとおりです。

1.Start the executor
  dscontrol executor start

2.Define the client gateway
  dscontrol executor set clientgateway 1.2.3.5
  NOTE: If your subnet does not have a local router, then you must
        configure a machine to do IP forwarding and use that as the
        clientgateway. Consult your operating system documentation 
        to determine how to enable IP forwarding.

3.Define the cluster address
  dscontrol cluster add 1.2.3.44

4.Configure the cluster address
  dscontrol executor configure 1.2.3.44

5.Define the port with a method of nat or cbr
  dscontrol port add 1.2.3.44:80 method nat
  or
  dscontrol port add 1.2.3.44:80 method cbr protocol http

6.Configure an alias return address on Load Balancer (using ethernet card 0)
  NOTE: On Linux systems, you do not need to alias the return address if using
  nat forwarding on a collocated machine.

  dscontrol executor configure 10.10.10.99

  or use the ifconfig command (for Linux or UNIX only):
  AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
  HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
  Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
  Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up

7.Define the backend servers
  dscontrol server add 1.2.3.4:80:192.10.10.10
    router 10.10.10.6 returnaddress 10.10.10.99 

クライアント・ゲートウェイ (1.2.3.5) は Load Balancer とクライアントとの間の ルーター 1 のアドレスです。 ルーター (10.10.10.6) は Load Balancer とバックエンド・サーバーとの間の ルーター 2 のアドレスです。 クライアント・ゲートウェイまたはルーター 2 のアドレスがはっきりとわからない場合は、クライアント (またはサーバー) アドレスを指定して traceroute プログラムを使用することで ルーター・アドレスを判別することができます。 このプログラムの正確な構文は、使用するオペレーティング・システムによって異なります。 このプログラムの詳細については、ご使用のオペレーティング・システムの文書を参照してください。

サーバーが Load Balancer と同じサブネットにある場合 (すなわち、traceroute を使用したときに、ルーターが戻されない場合)、ルーター・アドレスとしてサーバー・アドレスを入力してください。 ただし、サーバーが Load Balancer と同一マシン上にある場合は、 サーバー・アドレスの代わりに、ルーター・フィールドにルーター・アドレスを 入力する必要があります。 ルーター・アドレスは、ステップ 7 で Load Balancer マシン の "server add" コマンドに使用されたアドレスです。

サーバーの区分化: 1 つのサーバー (IP アドレス) に対して構成された論理サーバー

サーバーの区分化で、特定の URL とその固有のアプリケーションをさらに区別できます。 例えば、1 つの Web サーバーは JSP ページ、HTML ページ、GIF ファイル、データベース要求などを提供できます。現在では、Load Balancer は、1 つのクラスターおよびポート固有のサーバーをいくつかの論理サーバーに区分化する機能を提供しています。 これにより、マシン上の特定サービスについて、サーブレット・エンジンまたはデータベース要求が高速で実行中か、あるいはまったく実行中でないかを検出することをアドバイスできます。

サーバーの区分化によって、Load Balancer は、例えば、HTML サービスがページを高速で提供中であるが、 データベース接続はダウンしていることなどを検出できます。 これにより、サーバー全体の重み単独ではなく、よりきめ細かなサービス固有の作業負荷を基にして負荷を分散できます。

HTTP または HTTPS advisor を使用したサーバー区分化

サーバー区分化は、HTTP および HTTPS advisor とともに使用すると便利です。 例えば、HTML、GIF、および JSP ページを処理する HTML サーバーがあり、ポート 80 でそのサーバーを (追加することによって) 定義した場合、HTTP サーバー全体に対して負荷値を 1 つのみ受け取ります。 これは、GIF サービスがサーバーで機能していない可能性があるため、誤解を招く恐れがあります。 Dispatcher は、引き続き GIF ページをサーバーに転送しますが、クライアントではタイムアウトまたは障害が発生します。

このポートでサーバーを 3 回 (ServerHTML、ServerGIF、ServerJSP など) 定義し、論理サーバーごとに別のストリングを使用して サーバー advisorrequest パラメーターを定義した場合、サーバー上の特定のサービスの状態を照会することができます。 ServerHTML、ServerGIF、および ServerJSP は、1 つの物理サーバーから 区分化された 3 つの論理サーバーを表します。 ServerJSP では、advisorrequest ストリングを定義して、JSP ページを処理する マシン上のサービスを照会できます。 ServerGIF では、advisorrequest ストリングを定義して GIF サービスを照会できます。 また、ServerHTML では、advisorrequest を定義して HTML サービスを照会できます。 このため、GIF サービスを照会するための advisorrequest からクライアントが 応答を取得しなかった場合、Dispatcher はその論理サーバー (ServerGIF) を ダウンとしてマークしますが、他の 2 つの論理サーバーは正常である可能性があります。 Dispatcher は、GIF を物理サーバーに転送しなくなりますが、引き続き JSP および HTML 要求をサーバーに送ることは可能です。

advisorrequest パラメーターについて詳しくは、 要求および応答 (URL) オプションによる HTTP または HTTPS advisor の構成を参照してください。

論理サーバーへの物理サーバーの構成の例

Dispatcher 構成内では、物理サーバーまたは 論理サーバーは cluster:port:server 階層を使用して表現できます。 このサーバーは、シンボル名または IP アドレス形式のいずれかのマシン (物理サーバー) の固有 IP アドレスとすることができます。または、区分化されたサーバーを表すようにこのサーバーを定義する場合は、 dscontrol server add コマンドの address パラメーターで 物理サーバーの解決可能なサーバー・アドレスを指定する必要があります。 詳しくは、dscontrol server — サーバーの構成を参照してください。

以下は、さまざまなタイプの要求を処理するために、物理サーバーを論理サーバーに区分化している例です。

Cluster: 1.1.1.1
        Port:  80
             Server: A (IP address 1.1.1.2)
                       HTML server
             Server: B (IP address 1.1.1.2)
                       GIF server
             Server: C (IP address 1.1.1.3)
                       HTML server
             Server: D (IP address 1.1.1.3)
                       JSP server
             Server: E (IP address 1.1.1.4)
                       GIF server
             Server: F (IP address 1.1.1.4)
                       JSP server
        Rule1: /*.htm
             Server: A
             Server: C
        Rule2: /*.jsp
             Server: D
             Server: F
        Rule3: /*.gif
             Server: B
             Server: E                

この例では、サーバー 1.1.1.2 は、"A" (HTML 要求の処理) と "B" (GIF 要求の処理) という 2 つの論理サーバーに区分化されています。 サーバー 1.1.1.3 は "C" (HTML 要求の処理) と "D" (JSP 要求の処理) という 2 つの論理サーバーに区分化されています。 サーバー 1.1.1.4 は "E" (GIF 要求の処理) と "F" (JSP 要求の処理) という 2 つの論理サーバーに区分されています。

高可用性

単純な高可用性

図 13. 単純な 高可用性を使用した Dispatcher の例
単純な高可用性構成を使用した Dispatcher

高可用性機能では、2 番目の Dispatcher マシンが使用されます。最初の Dispatcher マシンは、単一 Dispatcher 構成の場合と同様に、すべてのクライアント・トラフィックに対して ロード・バランシングを実行します。 2 番目の Dispatcher マシンは、最初のマシンの「正常性」をモニターし、最初の Dispatcher マシンの障害を 検出した場合に、ロード・バランシングのタスクを引き継ぎます。

この 2 つのマシンには、それぞれ特定のロール、すなわち、プライマリー または バックアップ のいずれかが割り当てられます。プライマリー・マシンは、処理の進行とともに接続データをバックアップ・マシンに送信します。プライマリー・マシンが 活動状態 (ロード・バランシングを行っている) の間は、バックアップは 待機状態 になり、必要な場合には継続的に更新されていつでも引き継ぎできる状態になっています。

この 2 つのマシンの間の通信セッションは、heartbeat と呼ばれます。heartbeat により、それぞれのマシンが相手の「状態」をモニターできます。

バックアップ・マシンが活動マシンの失敗を検出すると、後を引き継いでロード・バランシングを開始します。この時点で 2 つのマシンの 状況 が反転します。すなわち、バックアップ・マシンが 活動状態 になり、プライマリー・マシンが 待機状態 になります。

高可用性の構成では、プライマリー・マシンとバックアップ・マシンの両方が同一の構成で同じサブネット上になければなりません。

高可用性の構成については、高可用性を参照してください。

相互高可用性

図 14. 相互高可用性を使用した Dispatcher の例
相互高可用性を使用した Dispatcher の構成

相互高可用性機能では、2 つの Dispatcher マシンが使用されます。両方のマシンがクライアント・トラフィックのロード・バランシングを能動的に実行し、互いにバックアップを行います。単純な高可用性の構成では、1 つのマシンだけがロード・バランシングを実行します。相互高可用性の構成では、両方のマシンがクライアント・トラフィックの部分のロード・バランシングを行います。

相互高可用性の場合には、クライアント・トラフィックは、クラスター・アドレス・ベースで各 Dispatcher マシンに割り当てられます。各クラスターは、そのプライマリー Dispatcher の NFA (非転送先アドレス) を使用して構成されます。プライマリー Dispatcher マシンは通常、そのクラスターのロード・バランシングを実行します。障害が発生した場合に、他方のマシンが自己のクラスターおよび障害が発生した Dispatcher のクラスターの両方に対してロード・バランシングを実行します。

共有『クラスター・セット A』および共有『クラスター・セット B』の相互高可用性の図示については、図 14 を参照してください。各 Dispatcher は、そのプライマリー・クラスターのパケットをアクティブに経路指定できます。いずれかの Dispatcher に障害が起きてそのプライマリー・クラスターのパケットをアクティブに経路指定できなくなると、他の Dispatcher がそのバックアップ・クラスターのパケットの経路指定を受け継ぎます。

注:
どちらのマシンも、同じ共有クラスター・セットを構成していなければなりません。すなわち、使用されるポートと各ポート下のサーバーは 2 つの構成内で同一である必要があります。

高可用性および相互高可用性の構成の詳細については、高可用性を参照してください。