この章では、Load Balancer の操作および管理の方法について説明しています。この章には以下のセクションがあります。
Load Balancer では、Load Balancer があるマシンとは別のマシンで構成プログラムを 実行するための方法が 2 つあります。 構成プログラム (dscontrol、cbrcontrol、sscontrol、ccocontrol、nalcontrol) と サーバー (dsserver、cbrserver など) との通信は、以下の方法のいずれかを使用して行われます。
RMI を使用するリモート管理の利点は、パフォーマンスが Web ベース管理よりも高速だということです。
Web ベース管理を使用する利点は、Web ベース管理では、安全な認証リモート管理が 提供されるということと、ファイアウォールがある場合でも Load Balancer マシンとの 通信が可能だということです。 また、この管理方法では、Load Balancer マシンと通信するリモート・クライアント・マシンに 認証キー (lbkeys) をインストールしたり、このリモート・クライアント・マシンで 認証キーを使用する必要がありません。
RMI では、リモート管理のために Load Balancer マシンに接続するコマンドは、dscontrol host:remote_host です。
RMI 呼び出しがローカル・マシン以外のマシンから行われた場合は、公開鍵と秘密鍵の認証シーケンスを行わなければ、構成コマンドは受信されません。
コンポーネント・サーバーと同じマシンで実行する制御プログラムの間の通信は認証されません。
以下のコマンドを使用して、リモート認証に使用する公開鍵および秘密鍵を生成します。
lbkeys [create|delete]
このコマンドを実行できるのは、Load Balancer と同じマシン上だけです。
create オプションを使用すると、次のサーバー鍵ディレクトリーに秘密鍵が作成されます。
さらに、スクリプトにより、各 Load Balancer コンポーネントの公開鍵が次の管理鍵ディレクトリーに作成されます。
公開鍵のファイル名は component-ServerAddress-RMIport です。 これらの公開鍵は、リモート・クライアントに移送して、管理鍵ディレクトリーに入れなければなりません。
各コンポーネントにデフォルト RMI ポートを使用するホスト名 10.0.0.25 の Load Balancer マシンの場合には、lbkeys create コマンドが以下のファイルを生成します。
管理ファイル・セットは、別のマシンにインストールされています。 公開鍵ファイルは、リモート・クライアント・マシン上の次のディレクトリーに入っていなければなりません。
これでリモート・クライアントに対して 10.0.0.25 における Load Balancer の構成が許可されます。
10.0.0.25 にある Load Balancer の構成を許可するすべてのリモート・クライアントでは、これらの同じ鍵を使用しなければなりません。
lbkeys create コマンドを再度実行すると、公開鍵と秘密鍵の新しいセットが生成されます。すなわち、以前の鍵を使用して接続しようとしたすべてのリモート・クライアントが許可されなくなります。新しい鍵は、再度許可するこれらのクライアントの正しいディレクトリーに入れなければなりません。
lbkeys delete コマンドは、サーバー・マシンにある 秘密鍵および公開鍵を削除します。 これらの鍵が削除されると、リモート・クライアントはサーバーへの接続を許可されなくなります。
lbkeys create と lbkeys delete の両方の場合に、force オプションがあります。 force オプションは、既存の鍵を上書きするか、あるいは削除するかを尋ねるコマンド・プロンプトを抑止します。
RMI 接続を確立すると、コマンド・プロンプトから dscontrol、cbrcontrol、 sscontrol、ccocontrol、nalcontrol、dswizard、cbrwizard、および sswizard コマンドを使用して構成プログラム間の通信を行うことができます。 また、コマンド・プロンプトから lbadmin を入力して GUI から Load Balancer を 構成することもできます。
Web ベース管理を使用するには、リモート管理を行うクライアント・マシンに 以下がインストールされている必要があります。
リモート Web ベース管理を行うには、アクセスするホスト・マシンに 以下がインストールされている必要があります。
Windows システムの場合 —
Protect /lb-admin/lbwebaccess PROT-ADMIN
Exec /lb-admin/lbwebaccess C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥lbwebaccess.pl
Pass /lb-admin/help/* C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥help¥*
Pass /lb-admin/*.jar C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥lib¥*.jar
Pass /lb-admin/* C:¥PROGRA~1¥IBM¥edge¥lb¥admin¥*
Pass /documentation/lang/* C:¥PROGRA~1¥IBM¥edge¥lb¥documentation¥lang¥*
ここで、lang はご使用の言語のサブディレクトリー (例えば en_US) です。
AIX、HP-UX、Linux、および Solaris オペレーティング・システムの場合 —
Protect /lb-admin/lbwebaccess PROT-ADMIN
Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl
Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/*
Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar
Pass /lb-admin/* /opt/ibm/edge/lb/admin/*
Pass /documentation/lang/* /opt/ibm/edge/lb/documentation/lang/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Web ベース管理を実行するには、これを Load Balancer ホスト・マシンで開始する必要があります。 開始するには、ホスト・マシンのコマンド・プロンプトから lbwebaccess を実行します。
リモートでアクセスするホスト・マシンのユーザー ID およびパスワードも必要です。 ユーザー ID とパスワードは、Caching Proxy 管理ユーザー ID およびパスワードと同じです。
Load Balancer の Web ベース管理を行うには、リモート・ロケーションから Web ブラウザーで 次の URL にアクセスします。
http://host_name/lb-admin/lbadmin.html
host_nameは、Load Balancer との通信を行うためにアクセスするマシンの名前です。
Web ページがロードされると、リモート Web ベース管理を 行うための Load Balancer GUI がブラウザー・ウィンドウに表示されます。
Load Balancer GUI から、構成制御コマンドを実行することもできます。 GUI からコマンドを実行するには、以下を行います。
リモートでの構成のリフレッシュ
リモート Web ベース管理では、複数の管理者が別のロケーションから Load Balancer 構成を 更新する場合、別の管理者によって追加 (または削除) されたクラスター、ポート、またはサーバーを (例えば) 表示するには、構成をリフレッシュする必要があります。 リモート Web ベース管理 GUI には、「構成をリフレッシュ」 および「すべての構成をリフレッシュ」機能があります。
Web ベース GUI から構成をリフレッシュするには、次を行います。
Load Balancer は、サーバー・ログ、manager ログ、メトリック・モニター・ログ (Metric Server エージェントでのロギング通信)、および使用する各 advisor のログに項目を追加します。
ログ・レベルを設定して、ログに書き込まれるメッセージの増え方を定義することができます。レベル 0 では、エラーが記録されて、Load Balancer は一度だけ発生したイベント (例えば、manager ログに書き込まれ始めた advisor に関するメッセージ) のヘッダーとレコードも記録します。 レベル 1 には継続中の情報などが組み込まれ、レベル 5 には必要に応じて生成される問題のデバッグに役立つメッセージが組み込まれます。manager、advisor、サーバー、またはサブエージェントのログのデフォルトは 1 です。
以下のコマンドを使用して、ロギングを構成します。
デフォルトでは、Load Balancer によって生成されるログは、Load Balancer インストールのログ・ディレクトリーに保管されます。 このパスを変更するには、dsserver スクリプトで lb_logdir 変数を設定してください。
AIX®、HP-UX、Linux、 および Solaris システムの場合、 dsserver スクリプトは /usr/bin ディレクトリーにあります。 このスクリプトでは、変数 lb_logdir はデフォルトのディレクトリーに設定されています。この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
LB_LOGDIR=/path/to/my/logs/
Windows システム: dsserver ファイルは <install_root>ibm¥edge¥lb¥bin ディレクトリーにあります。 dsserver ファイルでは、変数 lb_logdir はデフォルト・ディレクトリーに設定されています。この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
set LB_LOGDIR=c:¥path¥to¥my¥logs¥
すべてのオペレーティング・システムにおいて、等号の両側にはスペースを置かず、パスが (必要に応じて) スラッシュ (/) または円記号 (¥) で終了していなければなりません。
Load Balancer のバイナリー・ロギング機能は、他のログ・ファイルと同じログ・ディレクトリーを使用します。 バイナリー・ロギングを使用したサーバー統計の分析 を参照してください。
ログ・レベルを設定して、ログに書き込まれるメッセージの増え方を定義することができます。レベル 0 では、エラーが記録され、Load Balancer は一度だけ発生したイベント (例えば、コンサルタント・ログに 書き込まれ始めた advisor に関するメッセージ) のヘッダーおよびレコードも記録します。 レベル 1 には継続中の情報などが組み込まれ、レベル 5 には必要に応じて生成される問題のデバッグに役立つメッセージが組み込まれます。ログの デフォルトは 1 です。
ログの最大サイズを設定することもできます。ログ・ファイルに最大サイズを設定すると、ファイルは循環します。すなわち、ファイルが指定サイズに達すると、次の入力がファイルの最上部に書き込まれ、前のログ入力を上書きします。ログ・サイズを現行サイズより小さい値に設定することができません。ログ項目にはタイム・スタンプが記されるため、書き込まれた順序が分かります。
ログ・レベルの設定が高いほど、ログ・サイズの選択には注意を要します。レベル 0 では、ログ・サイズをデフォルトの 1MB のままにおくと安全です。ただし、レベル 3 以上でログ記録するときには、小さ過ぎて役に立たなくならない程度にサイズを制限する必要があります。
Cisco CSS Controller および Nortel Alteon Controller には以下のログがあります。
次は、Metric Server エージェントとの通信を記録する メトリック・モニター・ログのログ・レベルおよび最大ログ・サイズの構成例です。
xxxcontrol metriccollector set consultantID:serviceID:metricName
loglevel x logsize y
デフォルトでは、コントローラーによって生成されるログは、コントローラー・インストールのログ・ディレクトリーに保管されます。 このパスを変更するには、xxxserver スクリプトに xxx_logdir 変数を 設定してください。
AIX、HP-UX、Linux、 および Solaris システムの場合、 xxxserver スクリプトは /usr/bin directory にあります。 このスクリプトでは、変数 xxx_logdir はデフォルトのディレクトリーに設定されています。 この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
xxx_LOGDIR=/path/to/my/logs/
Windows システム: xxxserver ファイルは <install_root>ibm¥edge¥lb¥bin ディレクトリーにあります。 xxxserver ファイルでは、変数 xxx_logdir はデフォルトのディレクトリーに設定されています。 この変数を変更して、ログ・ディレクトリーを指定することができます。例えば、以下のようになります。
set xxx_LOGDIR=c:¥path¥to¥my¥logs¥
すべてのオペレーティング・システムにおいて、等号の両側にはスペースを置かず、パスが (必要に応じて) スラッシュ (/) または円記号 (¥) で終了していなければなりません。
Load Balancer のバイナリー・ロギング機能は、他のログ・ファイルと同じログ・ディレクトリーを使用します。 バイナリー・ロギングを使用したサーバー統計の分析 を参照してください。
このセクションでは、Dispatcher コンポーネントの操作および管理方法について説明します。
Load Balancer では、ステイル・タイムアウトに指定された秒数の間にその接続でアクティビティーがなかった場合は、接続は期限切れと見なされます。アクティビティーなしでその秒数を過ぎると、Load Balancer はその接続レコードをテーブルから除去し、その接続での後続のトラフィックは廃棄されます。
例えばポート・レベルでは、dscontrol port set staletimeout コマンドでステイル・タイムアウト値を指定できます。
ステイル・タイムアウトは、executor、クラスター、およびポート・レベルで設定できます。executor レベルおよびクラスター・レベルでは、デフォルトは 300 秒であり、そのポートにフィルター掛けします。ポート・レベルでは、デフォルトはポートに依存します。ポートの定義によって、デフォルトのステイル・タイムアウト値は異なります。例えば、Telnet ポート 23 のデフォルトは、259,200 秒です。
また、サービスによっては、独自のステイル・タイムアウトとなることもあります。例えば LDAP (Lightweight Directory Access Protocol) には idletimeout と呼ばれる構成パラメーターがあります。idletimeout の秒数が過ぎると、アイドル中のクライアント接続は強制的にクローズされます。また、Idletimeout を 0 に設定すると、接続は強制的にクローズされることがなくなります。
接続問題は、Load Balancer のステイル・タイムアウト値がサービスのタイムアウト値より小さいときに起こることがあります。LDAP の場合には、Load Balancer ステイル・タイムアウト値のデフォルトは 300 秒です。接続において 300 秒間アクティビティーがないと、Load Balancer はテーブルから接続レコードを除去します。idletimeout 値が 300 秒より大きい (または 0 に設定されている) 場合には、クライアントはサーバーとの接続がまだ保たれていると考えます。クライアントがパケットを送信すると、そのパケットは Load Balancer によって廃棄されます。これが、サーバーに対して要求すると LDAP の停止を引き起こすことになります。この問題を避けるには、LDAP idletimeout を Load Balancer のステイル・タイムアウト値以下の非ゼロ値に設定してください。
クライアントは、そのパケットをすべて送信した後に FIN パケットを送信し、 サーバーがトランザクションの終了を認識するようにします。 Dispatcher は FIN パケットを受信すると、 そのトランザクションに活動状態から FIN 状態へのマークを付けます。 トランザクションに FIN のマークが付けられると、その接続に予約されたメモリーはクリア可能になります。
接続レコードの割り振りと再利用の効率を高めるには、 executor set fintimeout コマンドを使用し、 Dispatcher が FIN 状態の接続を Dispatcher テーブルでアクティブに保ち、トラフィックを受け続けさせる 期間を制御します。 FIN 状態の接続が fintimeout を超過すると、 Dispatcher のテーブルから削除され、再利用可能になります。 FIN タイムアウトは、dscontrol executor set fincount コマンドを使用して 変更することができます。
dscontrol executor set staletimeout コマンドを使用して、 Dispatcher テーブルでアクティブなトラフィックが見られないときに、 Dispatcher が接続を Established 状態に保ち、トラフィ ックを受け入れ続ける期間を制御します。 詳細については、ステイル・タイムアウト値の使用を参照してください。
各種の図表は、executor からの情報を基にして表示して、manager に中継できます。 (GUI モニター・メニュー・オプションでは、manager 機能が実行中であることが必要です):
ネットワーク管理システムは断続的に実行される プログラムであり、ネットワークのモニター、状況の反映、および制御に使用されます。Simple Network Management Protocol (SNMP) は ネットワーク内の装置と通信するための一般的なプロトコルであり、現在のネットワーク管理の標準となっています。ネットワーク装置は、通常は SNMP エージェント と、1 つ以上のサブエージェントを持ちます。SNMP エージェントは、ネットワーク管理ステーション と通信するか、コマンド行 SNMP 要求に応答します。SNMP サブエージェント は、データを取得および更新し、そのデータを SNMP エージェントに提供して 要求側に戻します。
Dispatcher は SNMP 管理情報ベース (ibmNetDispatcherMIB) および SNMP サブエージェントを提供します。これによって、Tivoli® NetView®、Tivoli Distributed Monitoring、または HP OpenView などの任意のネットワーク管理システムを使用して、Dispatcher の正常性、スループットおよび活動をモニターすることができます。MIB データは、管理している Dispatcher について記述するものであり、現在の Dispatcher の状況を反映しています。MIB は ..lb/admin/MIB サブディレクトリーにインストールされています。
ネットワーク管理システムは、SNMP GET コマンドを使用して他のマシンの MIB 値を調べます。指定されたしきい値を超えた場合は、ユーザーに通知します。その後、Dispatcher の構成データを変更することによって Dispatcher のパフォーマンスに影響を与え、Dispatcher の問題が Dispatcher や Web サーバーの障害に至る前に未然に調整または修正を行うことができます。
システムによって、通常、ネットワーク管理ステーションごとに 1 つの SNMP エージェントが提供されます。ユーザーは SNMP エージェントに GET コマンドを送信します。次に、この SNMP エージェントも GET コマンドを送信して、これらの MIB 変数を管理するサブエージェントから、指定の MIB 変数を取得します。
Dispatcher は、MIB データの更新および取得を行うサブエージェントを提供します。SNMP エージェントが GET コマンドを送信すると、サブエージェントは適切な MIB データで応答します。SNMP エージェントは、このデータをネットワーク管理ステーションに送信します。ネットワーク管理ステーションは、指定されたしきい値を超えた場合にはユーザーに通知することができます。
Dispatcher SNMP サポートには、分散プログラム・インターフェース (DPI) 機能を使用する SNMP サブエージェントが含まれます。 DPI は、SNMP エージェントとそのサブエージェントの間のインターフェースです。 Windows オペレーティング・システムは、SNMP エージェントとそのサブエージェントの間のインターフェースとして Windows 拡張エージェントを使用します。
AIX システムは、SNMP Multiplexer プロトコル (SMUX) を使用する SNMP エージェントと、DPI および SMUX 間の変換機能として機能する追加の実行可能プログラムである DPID2 を提供します。
HP-UX システムの場合は SMUX 対応の SNMP エージェントを得る必要があります。これは HP-UX では提供されません。 Load Balancer は、HP-UX システムに DPID2 を提供します。
Linux システムは、SMUX を使用する SNMP エージェントを提供します。 多くのバージョンの Linux (Red Hat など) に UCD SNMP パッケージが付属しています。 UCD SNMP バージョン 4.1 またはそれ以降には、SMUX 使用可能エージェントが備わっています。 Load Balancer は Linux システムに DPID2 を提供します。
Solaris システムの場合は SMUX 可能な SNMP エージェントを得る必要があります。これは Solaris では提供されないためです。Load Balancer によって、/opt/ibm/edge/lb/servers/samples/SNMP ディレクトリーに Solaris システム用の DPID2 が提供されています。
DPI エージェントは、root ユーザーとして実行しなければなりません。DPID2 デーモンを実行する前に、以下のように /etc/snmpd.peers ファイルおよび /etc/snmpd.conf ファイルを更新してください。
AIX および Solaris システムの場合:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
Linux システムの場合:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
また、snmpd.conf ファイル内の com2sec、group、view、または access で始まるすべての行を
コメント化する必要もあります。HP-UX SNMP サポートをインストールするには、以下を行います。
SuSE Linux システムで Load Balancer SNMP を使用するには、以下を行う必要があります。
snmpd をリフレッシュして (既に実行中の場合)、snmpd.conf ファイルを 再読み取りするようにします。
refresh -s snmpd
DPID SMUX 対等機能を開始します。
dpid2
このデーモンは、以下の順序で開始しなければなりません。
Solaris SNMP サポートをインストールするには、以下を行います。
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
http://sunfreeware.com/ Web サイトでは、これらの名前に .gz の拡張子が 付いているため、これらを gunzip/untar しないでください。 その代わりに、pkgadd packageName を使用します。
Windows SNMP サポートをインストールするには、以下を行います。
executor 実行では、dscontrol subagent start [communityname] コマンドを使用して、Windows OS 拡張エージェントと SNMP エージェントとの間で使用される コミュニティー名を定義します。
重要: Windows 2003 では、SNMP はデフォルトでは表示されたいずれのコミュニティー名にも応答しません。このような場合には、SNMP サブエージェントはいずれの SNMP 要求にも応答しません。SNMP サブエージェントがコミュニティー名に応答するようにするには、適切なコミュニティー名および宛先ホストで「SNMP サービス・プロパティー」を設定しなければなりません。 SNMP セキュリティー・プロパティーを以下のように構成します。
SNMP は、しきい値に達したなど、管理されている装置が例外条件または重要なイベントの発生を報告するために送信するメッセージとして トラップ を送受信することによって通信します。
サブエージェントは以下のトラップを使用します。
indHighAvailStatus トラップは、高可用性状況の状態変数 (hasState) の値が変化したことを通知します。 hasState の指定できる値は以下のとおりです。
indSrvrGoneDown トラップは、オブジェクト ID の csID (クラスター ID)、psNum (ポート番号)、および ssID (サーバー ID) の部分で指定されたサーバーの重みがゼロになったことを通知します。 トラップでは、最終的に既知であったサーバーの活動状態の接続の数が送信されます。このトラップは、Dispatcher が判別できる限り、指定のサーバーが終了していることを示します。
indDOSAttack トラップは、numhalfopen (SYN パケットだけから構成されるハーフ・オープン接続の数) が、オブジェクト ID の csID (クラスター ID) および psNum (ポート番号) の部分で指定されたポートに対するしきい値を超過したことを示します。 ポート上で構成されたサーバー数がトラップで送信されます。このトラップは、Load Balancer がサービス妨害攻撃を予期していることを示しています。
indDOSAttackDone トラップは、numhalfopen (SYN パケットだけから構成されるハーフ・オープン接続の数) が、オブジェクト ID の csID および psNum の部分で指定されたポートに対するしきい値を下回ったことを示します。 ポート上で構成されたサーバー数がトラップで送信されます。Load Balancer があり得るサービス妨害攻撃が終了したことを判別すると、indDOSAttack トラップが送信された後にこのトラップが送信されます。
AIX、HP-UX、Linux、および Solaris オペレーティング・システムの場合、SMUX API の制限により、ibmNetDispatcher サブエージェントからのトラップで報告されたエンタープライズ ID が、ibmNetDispatcher のエンタープライズ ID、1.3.6.1.4.1.2.6.144 ではなく、dpid2 のエンタープライズ ID である場合があります。 ただし、データに ibmNetDispatcher MIB 内からのオブジェクト ID が含まれるため、SNMP 管理ユーティリティーはトラップの送信元を判別することができます。
dscontrol subagent start コマンドは、SNMP サポートをオンにします。dscontrol subagent stop コマンドは、SNMP サポートをオフにします。
dscontrol コマンドの詳細については、dscontrol subagent - SNMP サブエージェントの構成を参照してください。
Linux カーネルには、 ipchains と呼ばれるファイアウォール機能が組み込まれています。 Load Balancer と ipchains を並行して実行すると、Load Balancer が最初にパケットを読み込み、 次に ipchains が処理されます。これにより、ipchains を使用すると、 Linux Load Balancer マシン を強化できます。これは例えば、ファイアウォールのロード・バランシングを行うために使用する Load Balancer マシン とすることができます。
ipchains または iptables が完全に制限される (インバウンドまたはアウトバウンド・トラフィックが許可されない) ように構成されている場合、Load Balancer のパケット転送部分は正常に機能し続けます。
ipchains および iptables は、ロード・バランシング前に着信トラフィックをフィルターに掛けるためには使用できない ことに注意してください。
すべての Load Balancer が適切に機能するためには、 一部の追加トラフィックが許可されている必要があります。 この通信のいくつかの例は、次のとおりです。
一般に Load Balancer マシンでの ipchains の適切な方針は、バックエンド・サーバー、パートナー高可用性 Load Balancer、任意のリーチ・ターゲット、または任意の構成ホストとの間のトラフィックを除くすべてのトラフィックを認可しないということです。
Linux カーネルのバージョン 2.4.10.x で Load Balancer が実行されている場合は、 iptables を活動状態にすることはお勧めできません。 この Linux カーネルのバージョンで活動化すると、時間の経過に従ってパフォーマンスが低下する可能性があります。
iptables を活動停止するには、モジュール (lsmod) をリストして、どのモジュールが ip_tables および ip_conntrack を調べてから、rmmod ip_tables および rmmod ip_conntrack を実行してそれらを除去します。 マシンをリブートすると、これらのモジュールが再び追加されるので、リブートするたびにこれらのステップを繰り返す必要があります。
詳細については、問題: Linux iptables がパケットの経路指定を干渉す る を参照してください。
このセクションでは、Load Balancer の CBR コンポーネントの操作および管理方法について説明します。
CBR および Caching Proxy は、Caching Proxy プラグイン API を介して、HTTP および HTTPS (SSL) の要求を共同で処理します。CBR に対してサーバーのロード・バランシングを開始するには、Caching Proxy は同じマシン上で実行している必要があります。CBR と Caching Proxy を CBR 構成の例の説明に従ってセットアップしてください。
CBR の開始後に、以下の方式のいずれかを使用して制御できます。
CBR が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用 を参照してください。
CBR の前のリリースでは、変更できるのは Caching Proxy 構成ファイル中のログ・ディレクトリー・パスでした。現在はログが cbrserver ファイルに保管されたディレクトリーを変更できます。ログ・ファイル・パスの変更を参照してください。
Site Selector の開始後に、以下の方式のいずれかを使用して制御できます。
Site Selector が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Cisco CSS Controller の開始後に、以下の方式のいずれかを使用して制御できます。
Cisco CSS Controller が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Nortel Alteon Controller の開始後に、以下の方式のいずれかを使用して制御できます。
Nortel Alteon Controller が使用するログは、Dispatcher で使用されるログに類似しています。詳細については、Load Balancer ログの使用を参照してください。
Metric Server は Load Balancer にサーバー・ロード情報を提供します。 Metric Server は、ロード・バランシングされている各サーバー上に常駐します。
Linux および UNIX システム:
Windows システム:
「スタート」>「コントロール パネル」>「管理ツール」>「サービス」をクリックします。「IBM Metric Server」を右クリックし、「開始」を選択します。 サービスを停止するには、同様のステップに従って、「停止」を選択します。
Metric Server 始動スクリプトのログ・レベルを変更します。Load Balancer ログでのログ・レベル範囲と同様に、 ログ・レベルの範囲を 0 から 5 に指定できます。これにより、 ...ms/logs ディレクトリーにエージェント・ログが生成されます。