この章では、Dispatcher コンポーネントのインストールと構成を行う前に、ネットワーク計画担当者が考慮しなければならない事項について説明します。
この章には、以下のセクションが含まれています。
また、Dispatcher はプロトコル固有の情報を交換しない advisor (DB2® サーバーの状態を 報告する DB2 advisor やサーバーが PING に応答するかどうかを報告する Ping advisor など) も 提供します。 advisor の完全なリストについては、advisor のリストを参照してください。
また、オプションでユーザー自身の advisor を作成することもできます (カスタム (カスタマイズ可能) advisor の作成を参照してください)。
advisor の使用はオプションですが、使用することをお勧めします。
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 転送方式 (デフォルトの転送方式) を使用して、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) 機能を使用すると、ロード・バランシングされたサーバーがローカル接続ネットワーク上に置かれるという制限がなくなります。サーバーをリモート・ロケーションに置きたいときには、GRE/WAN カプセル化技法ではなく、NAT 転送方式技法を使用してください。また、NAPT 機能を使用して、各ロード・バランシングされたサーバー・マシン (各デーモンが固有のポートを listen しています) 上に常駐している複数のサーバー・デーモンにアクセスできます。
複数のデーモンを使用して 1 つのサーバーを構成する方法には、次の 2 つがあります。
このアプリケーションは、上位レベルのアプリケーション・プロトコル (例えば HTTP、SSL、IMAP、POP3、 NNTP、SMTP、Telnet など) と適切に連動します。
制限:
Dispatcher マシンには、3 つの IP アドレス (NFA アドレス、クラスター・アドレス、リターン・アドレス) が必要です。NAT/NAPT を実装するには、次のようにしてください (Dispatcher の NAT または CBR 転送方式を構成するためのサンプル・ステップも参照)。
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
これはクライアント要求の宛先ポート番号 (Dispatcher 用) を、Dispatcher がクライアント要求の ロード・バランシングを行うために使用するサーバーのポート番号にマップします。 Mapport により、Load Balancer は 1 つのポート上でクライアント要求を受信し、その要求をサーバー・マシン上の別のポートに送信できます。mapport を使用して、複数のサーバー・デーモンを実行している可能性があるサーバー・マシンに対する クライアント要求をロード・バランシングできます。 mapport のデフォルトは、クライアント要求の宛先ポート番号です。
リターン・アドレスは Dispatcher マシン上で構成される固有のアドレスまたはホスト名です。 サーバーに対するクライアント要求のロード・バランシングを行うときに、Dispatcher はリターン・アドレスをその送信元アドレスとして使用します。これによって、サーバーはパケットを直接クライアントに送信せずに、Dispatcher マシンに戻すようになります。(次に Dispatcher は IP パケットをクライアントに転送します。) サーバーの追加時には、リターン・アドレス値を指定する必要があります。リターン・アドレスは、サーバーを除去してもう一度追加しない限り変更できません。リターン・アドレスは、クラスター、サーバー、または NFA アドレスと同じにはできません。
NAT または CBR 転送方式を使用する場合は、Load Balancer とバックエンド・サーバー間の通信用のリターン・アドレスを定義する必要があります。 Load Balancer がバックエンド・サーバーとの間でアクティブにしておくことができる接続の数は、定義されているリターン・アドレスの数によって制限されます。 Load Balancer では、リターン・アドレスとサーバーの組み合わせではなく、リターン・アドレスのみに基づいてポートを使用します。 使用可能なポートがすべて使用中である場合、以降の接続は失敗します。ビジー状態の環境においては、 複数のリターン・アドレスを使用して、使用可能なポートが不足しないようにします。
リモート・サーバーへのルーターのアドレス。これがローカル接続サーバーである場合は、 サーバー・アドレスを入力します。ただし、そのサーバーが Load Balancer と同一マシン上にある場合を除きます。 その場合は、ルーターの実アドレスを引き続き使用してください。
この 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 はルール内の一連のサーバーからサーバーを選択 しません。
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 転送方式を構成するためのサンプル・ステップも参照)。
dscontrol server add cluster:port:server mapport value returnaddress rtrnaddress router rtraddress
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern pattern
ここで、pattern はコンテンツ・タイプ・ルールに使用するパターンを指定します。コンテンツ・ルール・タイプの詳細については、要求コンテンツに基づくルールの使用を参照してください。pattern の有効な式に関する詳細については、付録B. コンテンツ・ルール (パターン) 構文を参照してください。
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" コマンドに使用されたアドレスです。
サーバーの区分化で、特定の URL とその固有のアプリケーションをさらに区別できます。 例えば、1 つの Web サーバーは JSP ページ、HTML ページ、GIF ファイル、データベース要求などを提供できます。現在では、Load Balancer は、1 つのクラスターおよびポート固有のサーバーをいくつかの論理サーバーに区分化する機能を提供しています。 これにより、マシン上の特定サービスについて、サーブレット・エンジンまたはデータベース要求が高速で実行中か、あるいはまったく実行中でないかを検出することをアドバイスできます。
サーバーの区分化によって、Load Balancer は、例えば、HTML サービスがページを高速で提供中であるが、 データベース接続はダウンしていることなどを検出できます。 これにより、サーバー全体の重み単独ではなく、よりきめ細かなサービス固有の作業負荷を基にして負荷を分散できます。
サーバー区分化は、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 つの論理サーバーに区分されています。
高可用性機能では、2 番目の Dispatcher マシンが使用されます。最初の Dispatcher マシンは、単一 Dispatcher 構成の場合と同様に、すべてのクライアント・トラフィックに対して ロード・バランシングを実行します。 2 番目の Dispatcher マシンは、最初のマシンの「正常性」をモニターし、最初の Dispatcher マシンの障害を 検出した場合に、ロード・バランシングのタスクを引き継ぎます。
この 2 つのマシンには、それぞれ特定のロール、すなわち、プライマリー または バックアップ のいずれかが割り当てられます。プライマリー・マシンは、処理の進行とともに接続データをバックアップ・マシンに送信します。プライマリー・マシンが 活動状態 (ロード・バランシングを行っている) の間は、バックアップは 待機状態 になり、必要な場合には継続的に更新されていつでも引き継ぎできる状態になっています。
この 2 つのマシンの間の通信セッションは、heartbeat と呼ばれます。heartbeat により、それぞれのマシンが相手の「状態」をモニターできます。
バックアップ・マシンが活動マシンの失敗を検出すると、後を引き継いでロード・バランシングを開始します。この時点で 2 つのマシンの 状況 が反転します。すなわち、バックアップ・マシンが 活動状態 になり、プライマリー・マシンが 待機状態 になります。
高可用性の構成では、プライマリー・マシンとバックアップ・マシンの両方が同一の構成で同じサブネット上になければなりません。
高可用性の構成については、高可用性を参照してください。
相互高可用性機能では、2 つの Dispatcher マシンが使用されます。両方のマシンがクライアント・トラフィックのロード・バランシングを能動的に実行し、互いにバックアップを行います。単純な高可用性の構成では、1 つのマシンだけがロード・バランシングを実行します。相互高可用性の構成では、両方のマシンがクライアント・トラフィックの部分のロード・バランシングを行います。
相互高可用性の場合には、クライアント・トラフィックは、クラスター・アドレス・ベースで各 Dispatcher マシンに割り当てられます。各クラスターは、そのプライマリー Dispatcher の NFA (非転送先アドレス) を使用して構成されます。プライマリー Dispatcher マシンは通常、そのクラスターのロード・バランシングを実行します。障害が発生した場合に、他方のマシンが自己のクラスターおよび障害が発生した Dispatcher のクラスターの両方に対してロード・バランシングを実行します。
共有『クラスター・セット A』および共有『クラスター・セット B』の相互高可用性の図示については、図 14 を参照してください。各 Dispatcher は、そのプライマリー・クラスターのパケットをアクティブに経路指定できます。いずれかの Dispatcher に障害が起きてそのプライマリー・クラスターのパケットをアクティブに経路指定できなくなると、他の Dispatcher がそのバックアップ・クラスターのパケットの経路指定を受け継ぎます。
高可用性および相互高可用性の構成の詳細については、高可用性を参照してください。