Cisco CSS Controller と Nortel Alteon Controller の拡張機能

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

注:
この章で、xxxcontrol という記述は、Cisco CSS Controller では ccocontrol を、また Nortel Alteon Controller では nalcontrol を意味します。

連結

Cisco CSS Controller または Nortel Alteon Controller は、要求のロード・バランシングを行っているサーバーと同じマシン上に常駐できます。これは一般に、サーバーの 連結 と呼ばれています。追加の構成ステップは必要ありません。

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

高可用性

高可用性機能は、Cisco CSS Controller および Nortel Alteon Controller で使用可能になりました。

コントローラー耐障害性を向上させるため、高可用性機能には以下のフィーチャーが含まれています。

構成

xxxcontrol highavailability の完全な構文については、ccocontrol highavailability - 高可用性の制御および nalcontrol highavailability - 高可用性の制御 を参照してください。

コントローラーの高可用性を構成するには、次のようにします。

  1. 両方のコントローラー・マシンでコントローラー・サーバーを開始します。
  2. 各コントローラーを同一の構成で構成します。
  3. ローカル高可用性のロール、アドレス、およびパートナー・アドレスを以下のように構成します。
    xxxcontrol highavailability add address 10.10.10.10 
    partneraddress 10.10.10.20 port 143 role primary
  4. パートナー高可用性のロール、アドレス、およびパートナー・アドレスを以下のように構成します。
    xxxcontrol highavailability add address 10.10.10.20 
    partneraddress 10.10.10.10 port 143 role secondary
    address パラメーターと partneraddress パラメーターは、プライマリーおよびセカンダリー・マシンで逆になります。
  5. オプションで、ローカルおよびパートナー・コントローラーで高可用性パラメーターを構成します。 例:
    xxxcontrol highavailability set beatinterval 1000
  6. オプションとして、ローカルおよびパートナー・コントローラーで リーチ・ターゲットを次のように構成します。
    xxxcontrol highavailability usereach 10.20.20.20
    ローカルおよびパートナー・コントローラーで、同数のリーチ・ターゲットを構成しなければなりません。
  7. 高可用性コンポーネントを開始して、ローカルおよびパートナー・コントローラーでリカバリー・ストラテジーを次のように定義します。
    xxxcontrol highavailability start auto
  8. オプションで、ローカルおよびパートナー・コントローラーで高可用性情報を次のように表示します。
    xxxcontrol highavailability report
  9. オプションとして、アクティブ・コントローラーから引き継ぐために、待機コントローラーの引き継ぎを次のように指定します。
    xxxcontrol highavailability takeover
    これは保守用にのみ必要です。
注:
  1. 単一のコントローラーを高可用性なしで構成するため、高可用性コマンドを実行しないでください。
  2. 高可用性構成の 2 つのコントローラーを単一のコントローラーに変換するには、最初に待機コントローラーの高可用性を停止します。 さらに、オプションで活動状態コントローラーの高可用性を停止してください。
  3. 高可用性構成で 2 つのコントローラーを実行する場合、スイッチ間でコントローラー・プロパティーのいずれか (例えば switchconsultantid やスイッチ・アドレスなど) が異なるときには、予期しない結果が発生する可能性があります。 また、コントローラー高可用性プロパティー (例えばポート、ロール、リーチ・ターゲット、beatinterval、takeoverinterval、およびリカバリー・ストラテジー) が一致しない場合も、予期しない結果を得ることがあります。

障害検出

heartbeat メッセージによって検出される、アクティブ・コントローラーと待機コントローラー間での接続性の 喪失以外に、到達可能性というもう 1 つの障害検出機構があります。

コントローラー高可用性を構成する場合は、正しく機能するようにするために、コントローラーのそれぞれが到達しなければならないホストのリストを提供できます。 コントローラー・マシンが使用するサブネットごとに、少なくとも 1 つのホストがなければなりません。 これらのホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。

ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合、またはアクティブ・コントローラーが到達可能性基準に一致しなくなり、待機コントローラーが到達可能である場合は、切り替えが起こります。すべての使用可能な情報をもとにこの判断を行うため、アクティブ・コントローラーは、その到達可能性の機能を定期的に待機コントローラーに送信します。その反対の場合も同じです。次にコントローラーは到達可能性情報をそのパートナーの情報と比較し、どちらを活動状態にすべきかを決定します。

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

2 つのコントローラー・マシンのロールは、プライマリーおよびセカンダリーとして構成されています。 始動時に、これらのコントローラー・マシンは、各マシンが同期化するまで、情報を交換します。 この時点で、プライマリー・コントローラーは活動状態となり、重みの計算とスイッチの更新を開始しますが、セカンダリー・マシンは待機状態に移り、プライマリー・マシンの可用性をモニターします。

待機マシンはいつでも、活動状態のマシンの障害を検出すると、活動状態のマシン (障害を起こした) の ロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンが再び作動可能になると、この 2 つのマシンは、リカバリー・ストラテジーの構成内容に従って、どちらのコントローラーが活動状態になるかを決定します。

リカバリー・ストラテジーには、以下の 2 種類があります。

自動リカバリー

プライマリー・コントローラーは活動状態になり、重みを計算および更新し、再び作動可能になります。 セカンダリー・マシンは、プライマリーが活動状態になった後、待機状態に移ります。

手作業リカバリー

活動状態のセカンダリー・コントローラーは、プライマリー・コントローラーが作動可能になった後でも、アクティブ状態のままです。

プライマリー・コントローラーは待機状態に移ります。 活動状態に移るには、手動による介入が必要です。

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

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

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

Load Balancer で提供されるロード・バランシングの最適化

Load Balancer のコントローラー機能は、以下の設定を基にしてロード・バランシングを実行します。

これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。

メトリック情報の重要性

コントローラーは、その重みの判断で、以下のメトリック・コレクターの一部またはすべてを使用できます。

デフォルトのメトリックは activeconn と connrate です。

メトリック値の相対的な重要性の割合を変更できます。 この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトでは、活動中の接続および新規接続メトリックが使用され、その割合は 50 対 50 です。 ユーザーの環境では、最良のパフォーマンスが得られる組み合わせを判別するため、別のメトリック割合の組み合わせを試す必要がある場合があります。

割合値を設定するには、以下のように入力します。

Cisco CSS Controller の場合
ccocontrol ownercontent metrics metricName1 proportion1 metricName2 proportion2
Nortel Alteon Controller の場合
nalcontrol service metrics metricName1 proportion1 metricName2 proportion2

重み

重みは、アプリケーション応答時間と可用性、advisor からのフィードバック、および Metric Server のようなシステム・モニター・プログラムからのフィードバックに基づいて設定されます。 重みを手作業で設定する場合は、サーバーに fixedweight オプションを指定してください。 fixedweight オプションの説明については、コントローラー固定重みを参照してください。

重みは、サービスを提供するすべてのポートに適用されます。特定のサービスについて、要求は、互いに相対的な重みに基づいてサーバー間で分散されます。 例えば、一方のサーバーが重み 10 に設定され、他方が 5 に設定されると、10 に設定されたサーバーは 5 に設定されたサーバーの 2 倍の要求を得るはずです。

advisor は、サーバーが停止したことを検出した場合には、サーバーの重みは -1 に設定されます。 Cisco CSS Controller および Nortel Alteon Controller の場合、サーバーが使用不可であることがスイッチに伝えられ、スイッチはサーバーに接続を割り当てることを停止します。

コントローラー固定重み

コントローラーがなければ、advisor は実行されず、サーバーがダウンしているかどうかを検出することができません。 advisor を実行することを選択するが、特定のサーバー用に設定した重みをコントローラーに更新させたくない場合には、Cisco CSS Controller では ccocontrol service コマンドで、または Nortel Alteon Controller では nalcontrol server コマンドで fixedweight オプションを使用します。

重みに所要の値を設定するには、fixedweight コマンドを使用します。 固定重みが no に設定された別のコマンドが発行されるまで、コントローラーが実行されている間は、サーバー重みの値は固定されたままです。

重み計算スリープ時間

全体的パフォーマンスを最適化するには、メトリック収集の回数を制限することができます。

コンサルタント・スリープ時間は、コンサルタントがサーバーの重みを更新する回数を指定します。 コンサルタント・スリープ時間が短すぎると、コンサルタントが絶えずスイッチに割り込むことになり、パフォーマンスの低下が生じることになります。 コンサルタント・スリープ時間が長過ぎる場合は、スイッチのロード・バランシングが正確な最新情報に基づいていないことを意味します。

例えば、コンサルタント・スリープ時間を 1 秒に設定するには、以下のコマンドを入力します。

xxxcontrol consultant set consultantID sleeptime interval

重要度しきい値

他の方法を使用して、サーバーのロード・バランシングを最適化することができます。 最高速で働くために、サーバーの重みが大幅に変わった場合にだけそれが更新されます。サーバー状況にほとんど変更がないのに、絶えず重みを更新すると、無用なオーバーヘッドを生むことになります。 サービスを提供するすべてのサーバーの重みの合計に対するパーセントの重みの変更が重要度しきい値より大きい場合には、Load Balancer が使用する重みは更新されて接続が分散されます。 例えば、重みの合計が 100 から 105 に変化したとします。変化は 5% です。デフォルトの重要度しきい値の 5 では、変化率がしきい値を超えないので、Load Balancer が使用する重みは更新されません。 ただし、重みの合計が 100 から 106 に変化すると、重みは更新されます。 コンサルタントの重要度しきい値をデフォルト以外の値に設定するには、以下のコマンドを入力します。

    xxxcontrol consultant set consultantID sensitivity percentageChange

ほとんどの場合に、この値を変更する必要はありません。

Advisor

advisor は Load Balancer 内のエージェントです。advisor は、サーバー・マシンの状態および負荷の状態を評価することを目的とします。 これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。

注:
advisor の詳細リストについては、advisor のリストを参照してください。

advisor の機能

advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP "HEAD" 要求をサーバーに送信します。

advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この負荷値を 計算するため、advisor のほとんどは、サーバーが応答するまでの時間を測定して、負荷としてこの値 (ミリ秒単位) を使用します。

次に advisor は、負荷値をコンサルタント機能に報告します。この値はコンサルタント報告書に出力されます。 コンサルタントは、その割合に応じて全送信元からの重み値を集計して、これらの重み値をスイッチに送信します。 スイッチは、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。

サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値をコンサルタントに報告します。 サーバーが活動状態でないと advisor が判断した場合は、サーバーがダウンしていることをスイッチに伝えるために特別な負荷値である -1 を戻します。 その後、スイッチは、サーバーが再びアップするまで、それ以上そのサーバーに接続を転送しなくなります。

advisor スリープ時間

注:
advisor のデフォルトは、ほとんどの場合に効率的です。 デフォルト以外の値を入力する場合は注意が必要です。

advisor スリープ時間は、advisor がモニターして、その結果をコンサルタントに報告するポートのサーバーから状況を求める頻度を設定します。 advisor スリープ時間が短すぎると、advisor が絶えずサーバーに割り込むことになるため、パフォーマンスの低下が生じることになります。 advisor スリープ時間が長過ぎる場合は、コンサルタントの重みに関する決定が正確な最新情報に基づいていないことを意味します。

例えば、HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。

xxxcontrol metriccollector set consultantID:HTTP sleeptime 3

サーバーの advisor 接続タイムアウトおよび受信タイムアウト

サーバーまたはサービス上の特定のポートに障害が起きたことを検出するために費やす時間の値を設定することができます。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待機する時間が決定されます。

障害が発生したサーバーを最短時間で検出するには、advisor 接続タイムアウトおよび受信タイムアウトを最小値 (1 秒) に設定し、advisor およびコンサルタント・スリープ時間も最小値 (1 秒) に設定します。

注:
ユーザーの環境で、サーバーの応答時間が増加するような中ボリュームから高ボリュームのトラフィックが発生する場合には、timeoutconnect および timeoutreceive の値を小さく設定しすぎないように注意してください。 値が小さすぎると、advisor がビジーのサーバーを障害発生としてマークするのが早すぎる事態になる場合があります。

HTTP advisor の場合に、timeoutconnect を 9 秒に設定するには、以下のコマンドを入力します。

xxxcontrol metriccollector set consultantID:HTTP timeoutconnect 9

接続タイムアウトと受信タイムアウトのデフォルトは、advisor スリープ時間に指定されている値の 3 倍です。

advisor 再試行

advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 だけサーバー照会が失敗するまでは、サーバーをダウンとしてマーク付けしません。設定されなければ、デフォルトで retry 値はゼロになります。

Cisco CSS Controller の場合、ccocontrol ownercontent set コマンドを使用して retry 値を設定します。 詳細については、ccocontrol ownercontent - 所有者名およびコンテンツ・ルールの制御を参照してください。

Nortel Alteon Controller の場合、nalcontrol service set コマンドを使用して retry 値を設定します。 詳細については、nalcontrol サービス - サービスの構成を参照してください。

カスタム (カスタマイズ可能) advisor の作成

注:
このセクションで、サーバーは、Cisco CSS Controller の場合にはサービス、または Nortel Alteon Controller の場合にはサーバーを表す総称用語として使用されています。

カスタム (カスタマイズ可能) advisor は、基本コードによって呼び出される 小規模な Java™ コードで、ユーザーによりクラス・ファイルとして提供されます。 基本コードは、以下に示すようなすべての管理サービスを提供します。

また、結果をコンサルタントに報告します。基本コードは advisor サイクルを定期的に実行し、各サイクルで構成内のサーバーをすべて評価します。 これは、サーバー・マシンとの接続を オープンすることによって開始されます。ソケットがオープンすると、基本コードは、カスタム advisor の getLoad メソッド (関数) を呼び出します。 その後、カスタム advisor は、サーバーの状態を評価するために必要なステップをすべて実行します。 一般的には、ユーザー定義のメッセージをサーバーに送信してから応答を待機します。 (オープンしたソケットへのアクセスがカスタム advisor に提供されます。) その後、基本コードは、サーバーとのソケットをクローズして、コンサルタントに負荷情報を報告します。

基本コードおよびカスタム advisor は、通常モードおよび置換モードのいずれでも機能します。動作モードの選択は、カスタム advisor ファイルでコンストラクター・メソッドのパラメーターとして指定します。

通常モードでは、カスタム advisor がサーバーとデータを交換し、基本 advisor コードが交換の時間を測定して負荷値を計算します。基本コードは、この負荷値をコンサルタントに報告します。 カスタム advisor は、0 (正常) または負の値 (エラー) を戻す必要があるのみです。通常モードを指定するには、コンストラクターの代替フラグを false に設定します。

置換モードでは、基本コードはいかなる時間測定も行いません。カスタム advisor コードは、固有の要件に必要な操作をすべて実行して、実際の負荷値を戻します。基本コードは、その数値を受け入れて、コンサルタントに報告します。 最善の結果を得るためには、負荷値を 10 から 1000 までの間に正規化し、10 で高速なサーバーを表し、1000 で低速なサーバーを表してください。 置換モードを指定するには、コンストラクターの代替フラグを true に設定します。

この機能によって、ユーザー自身の advisor を作成し、必要とするサーバーに関する正確な情報を得ることができます。 サンプルのカスタム advisor、 ADV_ctlrsample.java はコントローラーに添付されています。 Load Balancer をインストールすると、次のディレクトリーにサンプル・コードが入ります。

注:
カスタム advisor を Cisco CSS Controller または Nortel Alteon Controller に追加する場合、新しいカスタム advisor クラス・ファイルを読み取る Java プロセスを使用可能にするため、ccoserver または nalserver を停止してから、再始動 (Windows システムでは、「サービス」を使用) しなければなりません。カスタム advisor クラス・ファイルは、始動時にのみロードされます。

命名規則

カスタム advisor のファイル名は ADV_myadvisor.java の形式でなければなりません。 つまり、大文字の接頭部 ADV_ で始まらなければなりません。 それ以後の文字は、すべて小文字でなければなりません。

Java の規則に従い、ファイルで定義されたクラスの名前は、ファイルの名前と一致していなければなりません。サンプル・コードをコピーする場合は、ファイル内の ADV_ctrlsample のインスタンスをすべて新しいクラス名に変更してください。

コンパイル

カスタム advisor は、Java 言語で作成します。Load Balancer と同時にインストールされた Java コンパイラーを 使用してください。コンパイル時には、以下のファイルが参照されます。

クラスパスは、コンパイル時にカスタム advisor ファイルと基本クラス・ファイルの両方を指していなければなりません。

Windows プラットフォームの場合、コンパイル・コマンドは以下のようになります。

install_dir/java/bin/javac -classpath
    <install_root>ibm¥edge¥lb¥servers¥lib¥ibmlb.jar ADV_pam.java

ここで、

コンパイルの出力は以下のようなクラス・ファイルです。 例えば、以下のようになります。

ADV_pam.class

advisor を開始する前に、クラス・ファイルを次のディレクトリーにコピーしてください。

注:
必要であれば、カスタム advisor をあるオペレーティング・システムでコンパイルし、別のオペレーティング・システムで実行することができます。 例えば、Windows システムで advisor をコンパイルし、(バイナリーの) クラス・ファイルを AIX® マシンにコピーして、そこでカスタム advisor を実行することができます。

AIX、HP-UX、 Linux、 および Solaris システムでの構文は似ています。

実行

カスタム advisor を実行するには、次のように、最初にクラス・ファイルを正しいインストール・ディレクトリーに コピーしなければなりません。

コンサルタントを開始し、続いて、次のコマンドを実行してカスタム advisor を開始します。

Cisco CSS Controller の場合
ccocontrol ownercontent metrics consultantID:ownerContentID pam 100
Nortel Alteon Controller の場合
nalcontrol service metrics consultantID:serviceID pam 100

ここで、

必須ルーチン

すべての advisor と同様に、カスタム advisor は、ADV_Base という advisor ベースの機能を拡張します。これは、コンサルタントの 重みのアルゴリズムで使用するためにコンサルタントに負荷を報告するなどの advisor の機能のほとんどを実際に実行する advisor ベースです。 また、advisor ベースは、ソケット接続とクローズ操作も実行し、advisor が使用するための send および receive メソッドを提供します。advisor 自体は、アドバイスされるサーバーのポートとの間で データを送受信するためにのみ使用されます。advisor ベースの TCP メソッドは時間が測定され、負荷が計算されます。必要な場合は、ADV_base のコンストラクターにあるフラグによって、advisor から戻された新しい負荷で既存の負荷が上書きされます。

注:
コンストラクターで設定された値に基づいて、advisor ベースは、指定された時間間隔で重みのアルゴリズムに負荷を提供します。実際の advisor が完了していないために有効な負荷を戻すことができない場合は、advisor ベースは直前の負荷を使用します。

基本クラスのメソッドを以下に示します。

検索順序

コントローラーは、最初に、提供されているネイティブ advisor のリストを参照します。 指定された advisor がそこに見つからないと、コントローラーはカスタム advisor のリストを参照します。

命名およびパス

サンプル advisor

コントローラーのサンプル advisor のプログラム・リストは、サンプル advisorに 入っています。インストール後、このサンプル advisor は次のディレクトリーに入っています。

Metric Server

Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer コンサルタントは、サーバーのそれぞれに常駐している Metric Serverに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も、Cisco CSS Controller ではサービス報告書に、または Nortel Alteon Controller ではサーバー報告書に入ります。

前提条件

Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。

Metric Server の使用法

以下は、コントローラーの Metric Server を構成するためのステップです。

Metric Server がローカル・ホスト以外のアドレスで実行されるようにするには、ロード・バランスされるサーバー・マシン上の metricserver ファイルを 編集します。metricserver ファイル中の java の後に、以下を挿入します。

-Djava.rmi.server.hostname=OTHER_ADDRESS

さらに、metricserver ファイル中の "if" ステートメントの前に、次の行を追加します。 hostname OTHER_ADDRESS

Windows システムの場合は、Microsoft スタック上の OTHER_ADDRESS に別名を割り当てます。Microsoft スタック上のアドレスに別名を付ける方法については、Metric Server 用の Microsoft スタック上のアドレスに対する別名の設定のセクションを参照してください。

作業負荷管理機能 advisor

WLM は、MVS™ メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。

OS/390® システムで MVS 作業負荷管理が構成されている場合は、コントローラーは、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。WLM advisor を使用して、コントローラーは、コンサルタント・ホスト・テーブルにある各サーバーの WLM ポートを介して接続を定期的にオープンし、戻された容量を表す整数を受け取ります。これらの整数はその時点で使用可能な容量を表しますが、コンサルタントは各マシンの負荷を表す値を要求しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (例えば、容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを表します)。WLM advisor と他のコントローラー advisor の間には、重要な違いがいくつかあります。

  1. 他の advisor は、通常のクライアント・トラフィックを流すポートと同じポートを使用して サーバーへの接続をオープンします。WLM advisor は、通常のトラフィックとは異なるポートを使用して サーバーへの接続をオープンします。各サーバー・マシンの WLM エージェントは、コントローラー WLM advisor が開始するポートと同じポートで listen するように 構成されていなければなりません。デフォルトの WLM ポートは 10007 です。
  2. プロトコル固有の両方の advisor を WLM advisor とともに 使用することができます。プロトコル固有の advisor は通常のトラフィック・ポートでサーバーをポーリングし、WLM advisor は WLM ポートを使用してシステム負荷をポーリングします。

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

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

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

情報をバイナリー・ログに記録するために、コンサルタントが実行されていなければなりません。

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

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

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

set interval オプションは、情報がログに 書き込まれる頻度を制御します。コンサルタントは、サーバー情報をコンサルタント間隔ごとに ログ・サーバーへ送信します。情報は、最後にログにレコードが書き込まれてから、指定した秒数の経過後にログに書き込まれます。 デフォルトでは、ログ記録間隔は 60 秒に設定されています。

コンサルタント間隔とログ記録間隔の設定の間には、相関関係があります。ログ・サーバーはコンサルタント間隔秒数以下の速度で情報を提供するので、コンサルタント間隔より短いログ記録間隔を設定しようとしても、実際にはコンサルタント間隔と同じ値に 設定されます。

このログ記録方法によって、サーバー情報を取り込む頻度を任意に細分化することができます。サーバーの重みを計算するために、コンサルタントによって確認されるサーバー情報に対する変更を すべて取り込むことができます。ただし、おそらく、この程度の情報量は、サーバーの使用および傾向の分析に必要ではありません。60 秒ごとにサーバー情報をログ記録すると、時間の経過とともにサーバー情報のスナップショットがとられます。ログ記録間隔を非常に低く設定すると、膨大な量のデータが生成される場合があります。

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

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

このサンプルは、ログ・ファイルからすべての情報を検索して画面に出力する方法を示します。カスタマイズすると、データについて必要な種類の分析を行うことができます。

提供されているスクリプトおよびプログラムの使用例を以下に示します。

xxxlogreport 2002/05/01 8:00 2002/05/01 17:00

これによって、2002 年 5 月 1 日の午前 8:00 から午後 5:00 までのコントローラーのサーバー情報の 報告書が得られます。

アラートまたはレコード・サーバー障害を生成するスクリプトの使用

Load Balancer は、カスタマイズできるスクリプトを起動するユーザー出口を提供します。 自動化された (サーバーがダウンとマークされると管理者にアラートを通知するか、単に障害のイベントを記録するなどの) アクションを 実行するスクリプトを作成できます。カスタマイズ可能なサンプル・スクリプトが次のディレクトリーに入っています。

これらのファイルを実行するには、ファイルを次のディレクトリーにコピーしてから、スクリプトに含まれている指示に従って各ファイルの名前を変更します。

以下のサンプル・スクリプトが提供されます。ここで、xxx は、Cisco CSS Controller では cco、および Nortel Alteon Controller では nal です。