この章には、以下のセクションが含まれています。
Cisco CSS Controller または Nortel Alteon Controller は、要求のロード・バランシングを行っているサーバーと同じマシン上に常駐できます。これは一般に、サーバーの 連結 と呼ばれています。追加の構成ステップは必要ありません。
ハイ・アベイラビリティー機能は、Cisco CSS Controller および Nortel Alteon Controller で使用可能になりました。
コントローラー耐障害性を向上させるため、ハイ・アベイラビリティー機能には以下のフィーチャーが含まれています。
xxxcontrol highavailability の完全な構文については、ccocontrol highavailability - ハイ・アベイラビリティーの制御および nalcontrol highavailability - ハイ・アベイラビリティーの制御 を参照してください。
コントローラーのハイ・アベイラビリティーを構成するには、次のようにします。
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondaryaddress パラメーターと partneraddress パラメーターは、プライマリーおよびセカンダリー・マシンで逆になります。
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20ローカルおよびパートナー・コントローラーで、同数のリーチ・ターゲットを構成しなければなりません。
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeoverこれは保守用にのみ必要です。
heartbeat メッセージによって検出される、アクティブ・コントローラーと待機コントローラー間での接続性の 喪失以外に、到達可能性というもう 1 つの障害検出機構があります。
コントローラー・ハイ・アベイラビリティーを構成する場合は、正しく機能するようにするために、コントローラーのそれぞれが到達しなければならないホストのリストを提供できます。 コントローラー・マシンが使用するサブネットごとに、少なくとも 1 つのホストがなければなりません。 これらのホストは、ルーター、IP サーバー、または他のタイプのホストでも可能です。
ホストの到達可能性は、ホストを ping する reach advisor によって取得されます。heartbeat メッセージが検出できない場合、またはアクティブ・コントローラーが到達可能性基準に一致しなくなり、待機コントローラーが到達可能である場合は、切り替えが起こります。すべての使用可能な情報をもとにこの判断を行うため、アクティブ・コントローラーは、その到達可能性の機能を定期的に待機コントローラーに送信します。その反対の場合も同じです。次にコントローラーは到達可能性情報をそのパートナーの情報と比較し、どちらを活動状態にすべきかを決定します。
2 つのコントローラー・マシンの役割は、プライマリーおよびセカンダリーとして構成されています。 始動時に、これらのコントローラー・マシンは、各マシンが同期化するまで、情報を交換します。 この時点で、プライマリー・コントローラーは活動状態となり、重みの計算とスイッチの更新を開始しますが、セカンダリー・マシンは待機状態に移り、プライマリー・マシンの可用性をモニターします。
待機マシンはいつでも、活動状態のマシンの障害を検出すると、活動状態のマシン (障害を起こした) の ロード・バランシング機能を引き継ぎ、活動状態のマシンになります。 プライマリー・マシンが再び作動可能になると、この 2 つのマシンは、リカバリー・ストラテジーの構成内容に従って、どちらのコントローラーが活動状態になるかを決定します。
リカバリー・ストラテジーには、以下の 2 種類があります。
プライマリー・コントローラーは活動状態になり、重みを計算および更新し、再び作動可能になります。 セカンダリー・マシンは、プライマリーが活動状態になった後、待機状態に移ります。
活動状態のセカンダリー・コントローラーは、プライマリー・コントローラーが作動可能になった後でも、アクティブ状態のままです。
プライマリー・コントローラーは待機状態に移ります。 活動状態に移るには、手動による介入が必要です。
ストラテジー・パラメーターの設定は、両マシンとも同じでなければなりません。
Cisco CSS Controller ハイ・アベイラビリティー構成の例については、例を参照してください。
Nortel Alteon Controller ハイ・アベイラビリティー構成の例については、例を参照してください。
Load Balancer のコントローラー機能は、以下の設定を基にしてロード・バランシングを実行します。
これらの設定を変更して、ネットワークのロード・バランシングを最適化することができます。
コントローラーは、その重みの判断で、以下のメトリック・コレクターの一部またはすべてを使用できます。
デフォルトのメトリックは activeconn と connrate です。
メトリック値の相対的な重要性の割合を変更できます。 この割合をパーセントで考えると、相対的な割合の合計は 100% でなければなりません。 デフォルトでは、活動中の接続および新規接続メトリックが使用され、その割合は 50 対 50 です。 ユーザーの環境では、最良のパフォーマンスが得られる組み合わせを判別するため、別のメトリック割合の組み合わせを試す必要がある場合があります。
割合値を設定するには、以下のように入力します。
重みは、アプリケーション応答時間と可用性、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 は Load Balancer 内のエージェントです。advisor は、サーバー・マシンの状態および負荷の状態を評価することを目的とします。 これは、サーバーとの事前の対策を講じたクライアント式交換で行われます。advisor は、アプリケーション・サーバーの lightweight クライアントと見なすことができます。
advisor は、定期的に各サーバーとの TCP 接続をオープンして、サーバーに要求メッセージを送信します。メッセージの内容は、サーバーで実行されるプロトコルに固有のものです。例えば、HTTP advisor は HTTP "HEAD" 要求をサーバーに送信します。
advisor は、サーバーからの応答を listen します。advisor は、応答を受け取るとサーバーの評価を行います。この負荷値を 計算するため、advisor のほとんどは、サーバーが応答するまでの時間を測定して、負荷としてこの値 (ミリ秒単位) を使用します。
次に advisor は、負荷値をコンサルタント機能に報告します。この値はコンサルタント報告書に出力されます。 コンサルタントは、その割合に応じて全送信元からの重み値を集計して、これらの重み値をスイッチに送信します。 スイッチは、これらの重みを使用して、新規の着信クライアント接続のロード・バランシングを行います。
サーバーが正常に機能していると advisor が判断した場合は、正で非ゼロの負荷値をコンサルタントに報告します。 サーバーが活動状態でないと advisor が判断した場合は、サーバーがダウンしていることをスイッチに伝えるために特別な負荷値である -1 を戻します。 その後、スイッチは、サーバーが再びアップするまで、それ以上そのサーバーに接続を転送しなくなります。
advisor スリープ時間は、advisor がモニターして、その結果をコンサルタントに報告するポートのサーバーから状況を求める頻度を設定します。 advisor スリープ時間が短すぎると、advisor が絶えずサーバーに割り込むことになるため、パフォーマンスの低下が生じることになります。 advisor スリープ時間が長過ぎる場合は、コンサルタントの重みに関する決定が正確な最新情報に基づいていないことを意味します。
例えば、HTTP advisor の場合に、間隔を 3 秒に設定するには、以下のコマンドを入力します。
xxxcontrol metriccollector set consultantID:HTTP sleeptime 3
サーバーまたはサービス上の特定のポートに障害が起きたことを検出するために費やす時間の値を設定することができます。 失敗したサーバー・タイムアウト値 (connecttimeout および receivetimeout) によって、advisor が接続または受信のいずれかの失敗を報告する前に待機する時間が決定されます。
最速に失敗したサーバーの検出を得るために、advisor 接続タイムアウトおよび 受信タイムアウトを最小値 (1 秒) に設定し、advisor およびコンサルタント・スリープ時間を最小値 (1 秒) に設定します。
HTTP advisor の場合に、timeoutconnect を 9 秒に設定するには、以下のコマンドを入力します。
xxxcontrol metriccollector set consultantID:HTTP timeoutconnect 9
接続タイムアウトと受信タイムアウトのデフォルトは、advisor スリープ時間に指定されている値の 3 倍です。
advisor は、サーバーをダウンとしてマーク付けする前に、接続を再試行する機能を持っています。 advisor は、再試行回数 + 1 だけサーバー照会が失敗するまでは、サーバーをダウンとしてマーク付けしません。設定されなければ、デフォルトで retry 値はゼロになります。
Cisco CSS Controller の場合、ccocontrol ownercontent set コマンドを使用して retry 値を設定します。 詳細については、ccocontrol ownercontent - 所有者名およびコンテンツ・ルールの制御を参照してください。
Nortel Alteon Controller の場合、nalcontrol service set コマンドを使用して retry 値を設定します。 詳細については、nalcontrol サービス - サービスの構成を参照してください。
カスタム (カスタマイズ可能) 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 のファイル名は 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 を開始する前に、クラス・ファイルを次のディレクトリーにコピーしてください。
AIX、HP-UX、 Linux、 および Solaris システムでの構文は似ています。
カスタム advisor を実行するには、次のように、最初にクラス・ファイルを正しいインストール・ディレクトリーに コピーしなければなりません。
コンサルタントを開始し、続いて、次のコマンドを実行してカスタム advisor を開始します。
ここで、
すべての advisor と同様に、カスタム advisor は、ADV_Base という advisor ベースの機能を拡張します。これは、コンサルタントの 重みのアルゴリズムで使用するためにコンサルタントに負荷を報告するなどの advisor の機能のほとんどを実際に実行する advisor ベースです。 また、advisor ベースは、ソケット接続とクローズ操作も実行し、advisor が使用するための send および receive メソッドを提供します。advisor 自体は、アドバイスされるサーバーのポートとの間で データを送受信するためにのみ使用されます。advisor ベースの TCP メソッドは時間が測定され、負荷が計算されます。必要な場合は、ADV_base のコンストラクターにあるフラグによって、advisor から戻された新しい負荷で既存の負荷が上書きされます。
基本クラスのメソッドを以下に示します。
コントローラーは、最初に、提供されているネイティブ advisor のリストを参照します。 指定された advisor がそこに見つからないと、コントローラーはカスタム advisor のリストを参照します。
コントローラーのサンプル advisor のプログラム・リストは、サンプル advisorに 入っています。インストール後、このサンプル advisor は次のディレクトリーに入っています。
Metric Server はシステム固有のメトリックの形式でサーバーの負荷情報を Load Balancer に提供し、サーバーの状態について報告します。 Load Balancer コンサルタントは、サーバーのそれぞれに常駐している Metric Serverに照会し、エージェントから収集したメトリックを使用してロード・バランシング処理に重みを割り当てます。 その結果も、Cisco CSS Controller ではサービス報告書に、または Nortel Alteon Controller ではサーバー報告書に入ります。
Metric Server エージェントは、ロード・バランシングされているサーバーすべてにインストールされていて、そのサーバーで実行中でなければなりません。
以下は、コントローラーの Metric Server を構成するためのステップです。
Nortel Alteon Controller の場合、スイッチ・コンサルタントを追加し、続いて、サービスを追加します。
ここで、metricName は、Metric Server スクリプトの名前。
システム・メトリック・スクリプトは、バックエンド・サーバーにあって、指定された ownercontent または service の下の構成でサーバーそれぞれで実行します。 2 つのスクリプト (cpuload および memload) が提供されるか、またはカスタム・システム・メトリック・スクリプトを作成できます。 スクリプトには、数値を返すコマンドが入っています。 この数値はロード測定値を表しますが、これは使用可能な値ではありません。
制限: Windows システムの場合は、システム・メトリック・スクリプトの名前の拡張子が .exe 以外になっているときには、ファイルのフルネーム (例えば、mySystemScript.bat) を指定しなければなりません。これは Java コードの制限です。
オプションで、Metric Server がサーバー・マシンで出すコマンドを定義する、独自のカスタマイズ済みメトリック・スクリプト・ファイルを作成できます。 カスタム・スクリプトが実行可能であり、かつ次のディレクトリーに入っていることを確認してください。
カスタム・スクリプトは、範囲が 0 から 100 の数字の負荷の値を戻さなければなりません。
Metric Server がローカル・ホスト以外のアドレスで実行されるようにするには、ロード・バランスされるサーバー・マシン上の metricserver ファイルを 編集します。metricserver ファイル中の java の後に、以下を挿入します。
-Djava.rmi.server.hostname=OTHER_ADDRESS
さらに、metricserver ファイル中の "if" ステートメントの前に、次の行を追加します。 hostname OTHER_ADDRESS。
Windows システムの場合は、Microsoft スタック上の OTHER_ADDRESS に別名を割り当てます。Microsoft スタック上のアドレスに別名を付ける方法については、Metric Server 用の Microsoft スタック上のアドレスに対する別名の設定のセクションを参照してください。
WLM は、MVS™ メインフレームで実行されるコードです。これは、MVS マシンの負荷を確認するために照会できます。
OS/390® システムで MVS 作業負荷管理が構成されている場合は、コントローラーは、WLM からの容量情報を受け取り、ロード・バランシング処理で使用します。WLM advisor を使用して、コントローラーは、コンサルタント・ホスト・テーブルにある各サーバーの WLM ポートを介して接続を定期的にオープンし、戻された容量を表す整数を受け取ります。これらの整数はその時点で使用可能な容量を表しますが、コンサルタントは各マシンの負荷を表す値を要求しているので、容量を表す整数は advisor によって反転され、負荷値に正規化されます (例えば、容量を表す整数が大きくて負荷値が小さいことは、サーバーの状態が良いことを表します)。WLM advisor と他のコントローラー advisor の間には、重要な違いがいくつかあります。
バイナリー・ログ機能を使用すれば、サーバー情報をバイナリー・ファイルに保管することができます。 これらのファイルを処理して、ある時間にわたって収集されたサーバー情報を分析することができます。
以下の情報が、構成で定義されたサーバーごとのバイナリー・ログに保管されます。
情報をバイナリー・ログに記録するために、コンサルタントが実行されていなければなりません。
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 です。