この章は、Load Balancer に関連する問題の検出と解決に役立ちます。
このセクションの情報を使用して IBM サービスが必要とするデータを収集します。 情報は以下の件名に分かれています。
Dispatcher コンポーネントにのみ、オペレーティング・システム固有のデータおよびコンポーネント固有の構成ファイルを自動的に収集する問題判別ツールがあります。 このツールを実行するには、適切なディレクトリーから lbpd と入力します。
この問題判別ツールは、以下のようにデータをファイルにパッケージします。
IBM サービスに電話をかける前に、以下の情報を使用できるようにしておいてください。
dscontrol file save primary.cfg
このコマンドは、構成ファイルを次のディレクトリーに入れます。
java -fullversion
netstat -ni
ipconfig /all
これについては、すべてのサーバーおよび Load Balancer からの情報が必要です。
netstat -nr
route print
これについては、すべてのサーバーおよび Load Balancer からの情報が必要です。
HA 環境での問題の場合、以下の必須情報を収集します。
スクリプト名は以下のとおりです。
さらに、構成ファイルも必要です。一般情報 (必須)を参照してください。
例えば、advIsor がサーバーに誤ってダウンのマークを付けるときなど、advisor の問題の場合は、以下の必須情報を収集します。
dscontrol advisor loglevel http 80 5
または
dscontrol advisor loglevel advisorName port loglevel
または
dscontrol advisor loglevel advisorName cluster:port loglevel
または
nalcontrol metriccollector set consultantID:serviceID:metricName loglevel value
これにより、ADV_advisorName.log という名前 (例えば ADV_http.log) の ログが作成されます。 このログは以下のロケーションに置かれます。
ここで、component は以下のとおりです。
ADVLOG 呼び出しは、レベルが advisor に関連したロギング・レベルより低いときに、advisor ログ・ファイルにステートメントをプリントします。ログ・レベルが 0 の場合、ステートメントが常に書き込まれます。コンストラクターから ADVLOG を使用することができません。ログ・ファイル名はコンストラクターに設定される情報によって決まるので、ログ・ファイルは、カスタムの advisor のコンストラクターが完成する直後まで作成されません。
この制限を回避し、カスタムの advisor をデバッグする別の方法があります。System.out.println(message) ステートメントを使用して、ウィンドウにメッセージを プリントすることができます。dsserver スクリプトを編集し、javaw から java に変更してプリント・ステートメントをウィンドウに表示します。dsserver の開始に使用したウィンドウは、プリントの表示のために開いておかなければなりません。Windows プラットフォームをご使用の場合は、Dispatcher のサービスとしての実行を停止し、 ウィンドウから手動で開始してメッセージを表示する必要があります。
ADVLOG の詳細については、「Edge Components プログラミング・ガイド」を参照してください。
Content Based Routing の問題の場合、以下の必須情報を収集します。
クラスターをヒットできない場合、両方の Load Balancer マシンでクラスターが別名割り当てされていないか、 または両方のマシンでクラスターが別名割り当てされている可能性があります。 どのマシンにクラスターがあるかを判別するには、以下を行います。
ping cluster arp -aDispatcher の NAT または CBR 転送方式を使用している場合は、戻りアドレスも ping します。
ping からの応答がなく、ULB を使用していない場合は、どちらのマシンに おいても、インターフェースにクラスター IP アドレス (例えば en0、tr0 など) が別名割り当てされていない可能性があります。
経路指定の問題を解決できず、その他のすべてが失敗した場合、以下のコマンドを実行してネットワーク・トラフィック上でトレースを実行します。
iptrace -a -s failingClientIPAddress -d clusterIPAddress -b iptrace.trcトレースを実行し、問題を再作成してから、プロセスを強制終了します。
tcpdump -i lan0 host cluster and host clientHP-UX GNU ソフトウェアのアーカイブ・サイトのいずれかから、tcpdump をダウンロードする必要がある場合があります。
tcpdump -i eth0 host cluster and host clientトレースを実行し、問題を再作成してから、プロセスを強制終了します。
snoop -v clientIPAddress destinationIPAddress > snooptrace.out
また、さまざまログ・レベル (manager ログ、advisor ログなど) を上げて、その出力を調べることもできます。
サービス・リリース・フィックスまたはパッチで既に修正されている問題を確認するには、 アップグレードを確認してください。 修正された Edge Components の問題のリストを得るには、 WebSphere® Application Server Web サイトのサポート・ページ (http://www.ibm.com/software/webservers/appserv/was/support/) を参照してください。 サポート・ページから、修正サービスのダウンロード・サイトへのリンクをたどってください。
Load Balancer インストールの一部として適切なバージョンの Java コードがインストールされます。
サポートおよびライブラリーの Web ページへのリンクについては、参照情報 を参照してください。Web サポート・ページには、テクニカル・ノート形式のセルフ・ヘルプへのリンクが含まれます。
以下を参照してください。
症状 | 考えられる原因 | 参照カ所 |
---|---|---|
Dispatcher が正常に実行されない | ポート番号が競合している | Dispatcher ポート番号のチェック |
連結されたサーバーを構成したが、ロード・バランシング要求に応答しない | アドレスが誤っているか競合している | 問題: Dispatcher およびサーバーが応答しない |
クライアント・マシンからの接続がサービスを受けていない、あるいは接続がタイムアウトである |
|
問題: Dispatcher 要求が平衡化されない |
クライアント・マシンにサービスが提供されていないか、タイムアウトになっている | ハイ・アベイラビリティーが機能しない | 問題: Dispatcher の高可用性機能が機能しない |
heartbeat を追加できない (Windows プラットフォーム) | アダプターに送信元アドレスが構成されていない | 問題: heartbeat を追加できない (Windows プラットフォーム) |
advisor が広域で正しく機能しない | advisor がリモート・マシンで実行されていない | 問題: advisor が正しく機能しない |
Windows Server 2008 が稼働しているバックエンド・サーバーで memload.exe が異常終了する | これらのツールが必要とするパフォーマンス・キーが Windows Server 2008 のレジストリーに設定されていない可能性があります。 このアプリケーション異常終了は、cpuload アプリケーションから報告されます。 | 問題: Windows Server 2008 バックエンド・サーバーで memload.exe が異常終了する |
Dispatcher、Microsoft IIS、および SSL が機能しない、または続行しない | 暗号化されたデータをプロトコルを介して送信できない | 問題: Dispatcher、Microsoft IIS、および SSL が機能しない (Windows プラットフォーム) |
リモート・マシンへの接続が拒否された | 古いバージョンのキーがまだ使用されている | 問題: リモート・マシンへの Dispatcher 接続 |
dscontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません。」または「RMI サーバーにアクセスできません。」メッセージが表示された |
|
問題: dscontrol コマンドまたは lbadmin コマンドが失敗する |
「ファイルが見つかりません...」というエラー・メッセージが、Netscape をデフォルト・ブラウザーとして稼働し、オンライン・ヘルプを表示すると出される (Windows プラットフォーム) | HTML ファイルの関連付けの設定が誤っている | 問題:「ファイルが見つかりません...」というエラー・メッセージが、オンライン・ヘルプを表示しようとすると出される (Windows プラットフォーム) |
グラフィカル・ユーザー・インターフェースが正しく開始されない | 不適当なページング・スペース | 問題: グラフィカル・ユーザー・インターフェース (GUI) が正しく開始されない |
Caching Proxy がインストールされた Dispatcher の実行のエラー | Caching Proxy ファイル依存関係 | 問題: Caching Proxy がインストールされた Dispatcher の実行のエラー |
グラフィカル・ユーザー・インターフェースが正しく表示されない | レゾリューションが誤りである | 問題: グラフィカル・ユーザー・インターフェース (GUI) が正しく表示されない |
ヘルプ・パネルが他のウィンドウの背後に隠れて見えなくなることがある | Java の制限 | 問題: Windows プラットフォームにおいてヘルプ・ウィンドウが他のウィンドウの背後に隠れて見えなくなることがある |
Load Balancer がフレームを処理および転送できない | 各 NIC に対して固有の MAC アドレスが必要 | 問題: Load Balancer がフレームを処理および転送できない |
青い画面が表示される | ネットワーク・カードがインストールおよび構成されていない | 問題: Load Balancer executor を開始するとブルー・スクリーンが表示される |
Discovery へのパスが戻りトラフィックを妨げる | クラスターがループバック上で別名割り当てされる | 問題: Discovery へのパスが Load Balancer での戻りトラフィックを妨げる |
Load Balancer の広域モードで高可用性が機能しない | Remote Dispatcher をローカル Dispatcher 上のクラスターにおいてサーバーとして定義する必要がある | 問題: Load Balancer の広域モードでハイ・アベイラビリティーが動作しない |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
リモート接続で正しく IP アドレスに解決されない | セキュア Socks 実装でリモート・クライアントを使用するとき、 完全修飾ドメイン・ネームまたはホスト名が正しい IP アドレスに解決されないことがある | 問題: リモート接続で正しく IP アドレスに解決されない |
AIX および Linux システムにおいて、韓国語の Load Balancer インターフェースで、文字が重なり合ったフォントまたは不適切なフォントが表示される | デフォルトのフォントを変更する必要がある | 問題: AIX および Linux システムにおいて、 韓国語の Load Balancer インターフェースで、重なって表示されるフォントまたは不適切なフォントが表示される |
Windows システムにおいて MS ループバック・アダプターの別名割り当て後に、hostname などのコマンドを実行すると、OS が別名アドレスを使用して不正に応答する | ネットワーク接続リストで、新たに追加された別名をローカル・アドレスの上に リストしてはいけない | 問題: Windows システムにおいて、hostname などのコマンドを実行したときに、ローカル・アドレスではなく別名アドレスが戻される |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォームにおいて Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
Linux システムにおいて "rmmod ibmlb" を実行すると、システム・ハングなどの予期しない振る舞いが発生する | Load Balancer カーネル・モジュール (ibmlb) を手動で除去すると、問題が発生する | 問題: "rmmod ibmlb" を実行すると、予期しない振る舞いが発生する (Linux システム) |
Dispatcher マシンでコマンドを実行したときの応答が遅い | 高ボリュームのクライアント・トラフィックによるマシンの過負荷が原因で、応答が遅くなっている可能性がある | 問題: Dispatcher マシンでコマンドを実行したときの応答が遅い |
Dispatcher の mac 転送方式で、SSL または HTTPS advisor がサーバーの負荷を登録しない | SSL サーバー・アプリケーションがクラスター IP アドレスで 構成されていないことが原因で問題が発生する | 問題: SSL または HTTPS advisor がサーバーの負荷を登録しない (mac 転送方式使用時) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows システムで、破壊された Latin 1 国別文字がコマンド・プロンプト・ウィンドウに現れる |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX で、Java メモリー不足またはスレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システムで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合に、IP アドレスをホスト名に解決する際に問題が発生する | ホスト名として設定する IP アドレスは、レジストリーの最初に表示される必要があります。 | 問題: Windows システムで、1 つのアダプターに複数の IP アドレスが構成されている場合に、IP アドレスをホスト名に解決する |
Windows プラットフォームで、ネットワーク障害後に高可用性セットアップで advisor が機能しない | システムは、ネットワーク障害を検出すると、アドレス解決プロトコル (ARP) キャッシュを消去します。 | 問題: Windows システムで、ネットワーク障害後にハイ・アベイラビリティー・セットアップで advisor が機能しない |
Linux システムで、「IP address add」コマンドと、複数のクラスター・ループバックの別名が非互換 | ループバック・デバイスの複数のアドレスに別名を割り当てるときは、ip address add ではなく ifconfig コマンドを使用する必要があります。 | 問題: Linux システムで、 ループバック・デバイスの複数のクラスターに別名アドレスを割り当てるときに 「IP address add」コマンドを使用してはならない |
エラー・メッセージ: サーバーの追加を試行中に、 「ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません」 | サーバーの追加時に発生した問題を判別するための情報のチェックリスト | 問題: "ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません" の エラー・メッセージ |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
Load Balancer 構成の読み込み時に、速度の低下が見られる | 遅延は、サーバー・アドレスを解決して検証す るために行われた、ドメイン・ネーム・システム (DNS) 呼び出しが原因である場合があります。 | 問題: Load Balancer 構成のロード中に遅延が発生する |
Windows システムで、次のエラー・メッセージが 表示される:「ネットワーク上の他のシステムとの IP アドレスの競合があります」 | 高可用性が構成されている場合は、 短時間の間、両方のマシンでクラスター・アドレスが構成されることがあり、この エラー・メッセージが出される原因となります。 | 問題: Windows システムの場合、IP アドレス競合のエラー・メッセージが表示される |
プライマリー・マシンおよびバックアップ・マシンが両方とも HA 構成でアクティブになる | この問題は、go スクリプトがプライマリー・マシンおよびバックアップ・マシンの両方で稼働していないときに発生することがあります。 | 問題: プライマリー・マシンおよびバックアップ・マシンが両方ともハイ・アベイラビリティー構成でアクティブになる |
Dispatcher が大容量のページを戻そうとすると、 クライアントは失敗を要求する | NAT または CBR 転送方式を使用している場合、最大伝送単位 (MTU) が Dispatcher マシンに適切に設定されていないと、クライアントは、 大容量のページの結果がタイムアウトを応答するように要求します。 | 問題: 大容量のページ応答を戻そうとする時、クライアントが失敗を要求する |
Windows システムの場合、dscontrol または lbadmin コマンドを発行すると、「サーバーが応答していません」というエラーが発生する | 複数の IP アドレスが Windows システムに存在し、 ホスト・ファイルがホスト名に関連づけられたアドレスを指定しない時です。 | 問題: Windows システムの場合、dscontrol または lbadmin の発行時に、「サーバーが応答していません」というエラーが発生する |
高可用性 Dispatcher マシンが qeth デバイス上の Linux for S/390 で同期するのに失敗することがある | qeth ネットワーク・ドライバーと一緒に Linux for S/390 で高可用性を使用しているときに、 活動中および待機中の Dispatcher が同期できないことがあります。 | 問題: 高可用性 Dispatcher マシンが qeth デバイス上の Linux for S/390 で同期するのに失敗する可能性がある |
Load Balancer 用の高可用性機能の構成に関するヒント | これらのヒントは、以下のような高可用性の問題の改善に役立ちます。
|
問題: 高可用性の構成に関するヒント |
zSeries および S/390 プラットフォームでの Dispatcher の MAC 転送構成の制限事項 | Linux では、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の制限があります。 実行可能な次善策が提供されます。 | 問題: Linux で、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の Dispatcher 構成の制限 |
一部の Red Hat Linux バージョンでは、 manager と advisor で構成された Load Balancer の実行中にメモリー・リークが発生することがある | Red Hat Enterprise Linux 3.0 などの一部の Linux 配布版に同梱の JVM の IBM Java SDK バージョンおよび Native POSIX Thread Library (NPTL) では、 メモリー・リークが起こる可能性があります。 | 問題: 一部の Linux バージョンで、manager と advisor で構成された Dispatcher の実行中にメモリー・リークが発生する |
SUSE Linux Enterprise Server 9 では、 Dispatcher 報告書に、パケットが転送された (パケット数が増加) にもかかわらず、 パケットが実際にバックエンド・サーバーに到達していないということが示 される | iptables NAT モジュールはロード済みです。 このバージョンの iptables では、Dispatcher との 対話で異常な振る舞いが発生するという、起こりうるが未確認のエラーが発 生します。 | 問題: SUSE Linux Enterprise Server 9 で、Dispatcher がパケットを転送してもパケットがバックエンド・サーバーに到達しない |
Windows システムで、 Dispatcher の高可用性機能を使用するときに、引き継ぎ中に問題が発生することがある | 活動中のマシンでクラスターの IP アドレスを構成する go スクリプトを、 バックアップ・マシンで IP クラスター・アドレスの構成を解除する go スクリプトの前に実行すると、問題が発生することがあります。 | 問題: Windows システムで、ハイ・アベイラビリティーの引き継ぎ中に IP アドレス競合メッセージが表示される |
Linux システムで、iptables によ ってパケットの経路指定が干渉される場合がある | Linux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Load Balancer マシンでは無効にする必要があります。 | 問題: Linux iptables がパケットの経路指定を干渉す る |
システム・パッケージ化ツールを使用してサービス修正をインストールしたり、ネイティブでインストールしたりすると、Java ファイル・セット警告メッセージが表示される | 製品のインストールは、同じマシンにインストー ルする必要はない複数のパッケージで構成されており、各パッケー ジが Java ファイル・セットをインストールします。 同じマシンにインストールすると、Java ファイル・セットが別のファイル・セットにも所有されていることを示す警告メッセージが表示されます。 | |
Load Balancer のインストールとともに提供された Java ファイル・セットのアップグレード | Java ファイル・セットに問題が見つかった場合は、 その問題を IBM サービスに報告し、Load Balancer インストールとともに 提供された Java ファイル・セットのアップグレードを受け取れるようにする必要があります。 | Load Balancer のインストールとともに提供された Java ファイル・セットのアップグレード |
Windows プラットフォームでの高可用性の引き継ぎ中に、持続接続が中断することがある | Microsoft Windows オペレーティング・システム上では、高可用性の引き継ぎ時に パーシスタント接続が切断される場合があります。この問題は、MAC 転送方式を使用する連結サーバーの場合にのみ発生します。 | 問題: 高可用性の引き継ぎ中に、持続接続が中断することがある |
症状 | 考えられる原因 | 参照カ所 |
CBR が正常に実行されない | ポート番号が競合している | CBR ポート番号のチェック |
cbrcontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません。」または「RMI サーバーにアクセスできません。」メッセージが表示された | コマンドは socks 化スタックが原因で失敗する。 あるいは、コマンドは cbrserver の未始動が原因で失敗する。 | 問題: cbrcontrol コマンドまたは lbadmin コマンドが失敗する |
要求がロード・バランシングされない | executor の開始前に Caching Proxy が開始された | 問題: 要求がロード・バランシングされない |
Solaris において、cbrcontrol executor start コマンドが、 「エラー: executor が開始されていませんでした」というメッセージを出し て失敗した | コマンドは、システム IPC デフォルトを変更する必要があるか、 ライブラリーへのリンクに誤りがあるために失敗した。 | 問題: Solaris システムにおいて cbrcontrol executor start コマンドが失敗する |
URL ルールが機能しない | 構文エラーまたは構成エラー | 問題: 構文エラーまたは構成エラー |
Windows システムを Matrox AGP ビデオ・カードとともに使用すると、GUI の予期しない振る舞いが発生する | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォームにおいて Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォームで、破壊された Latin 1 国別文字がコマンド・プロンプト・ウィンドウに現れる |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX で、Java メモリー不足/スレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システムで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Windows プラットフォームで、1 つのアダプターに複数の IP アドレスが構成されている場合、IP アドレスをホスト名に解決できない問題 | ホスト名として設定する IP アドレスは、レジストリーの最初に表示される必要があります。 | 問題: Windows システムで、1 つのアダプターに複数の IP アドレスが構成されている場合に、IP アドレスをホスト名に解決する |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
症状 | 考えられる原因 | 参照カ所 |
---|---|---|
Site Selector が正常に実行されない | ポート番号の競合 | Site Selector ポート番号のチェック |
Site Selector が Solaris クライアントからの受信要求をラウンドロビンしない | Solaris システムが「ネーム・サービス・キャッシュ・デーモン」を実行する | 問題: Site Selector が Solaris クライアントからのトラフィックをラウンドロビンしない |
sscontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません。」または「RMI サーバーにアクセスできません。」メッセージが表示された | コマンドは socks 化スタックが原因で失敗する。 または ssserver の未始動が原因でコマンドが失敗する | 問題: sscontrol コマンドまたは lbadmin コマンドが失敗する |
ssserver は Windows プラットフォームでの開始に失敗している | Windows システムでは、DNS にホスト名が入っている必要はありません。 | 問題: ssserver が Windows プラットフォームでの開始に失敗する |
複製経路のあるマシンが正しくロード・バランシングされず、ネーム・レゾリューションの表示に失敗する | 複数アダプターのある Site Selector マシンが同じサブネットに接続されている | 問題: 重複経路のある Site Selector が正しくロード・バランシングされない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォームにおいて Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォームで、破壊された Latin 1 国別文字がコマンド・プロンプト・ウィンドウに現れる |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX で、Java メモリー不足/スレッド・エラーが発生する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある | 問題: Windows システムで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
症状 | 考えられる原因 | 参照カ所 |
---|---|---|
ccoserver が開始されない | ポート番号が競合している | Cisco CSS Controller ポート番号のチェック |
ccocontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません。」または「RMI サーバーにアクセスできません。」メッセージが表示された | コマンドは socks 化スタックが原因で失敗する。 または ccoserver の未始動が原因でコマンドが失敗する | 問題: ccocontrol または lbadmin コマンドが失敗する |
エラーを受信: ポート 13099 でレジストリーを作成できない | 製品ライセンスの有効期限切れ | 問題: ポート 13099 でレジストリーを作成できない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォームにおいて Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
コンサルタントの追加時に接続エラーを受け取った | スイッチまたはコントローラーで構成設定が正しくない | 問題: コンサルタントの追加時に接続エラーを受け取った |
スイッチで重みが更新されない | コントローラーとスイッチとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: スイッチで重みが更新されない |
リフレッシュ・コマンドによってコンサルタント構成が更新されなかった | スイッチとコントローラーとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: リフレッシュ・コマンドによってコンサルタント構成が更新されなかった |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows プラットフォームで、破壊された Latin 1 国別文字がコマンド・プロンプト・ウィンドウに現れる |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX で、Java メモリー不足/スレッド・エラーが発生する |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
症状 | 考えられる原因 | 参照カ所 |
---|---|---|
nalserver が開始されない | ポート番号が競合している | Nortel Alteon Controller ポート番号のチェック |
nalcontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません。」 または「RMI サーバーにアクセスできません。」メッセージが表示された | コマンドは socks 化スタックが原因で失敗する。 または nalserver の未始動が原因でコマンドが失敗する。 | 問題: nalcontrol または lbadmin コマンドが失敗する |
エラーを受信: ポート 14099 でレジストリーを作成できない | 製品ライセンスの有効期限切れ | 問題: ポート 14099 でレジストリーを作成できない |
Windows プラットフォームを Matrox AGP ビデオ・カードとともに使用すると、GUI が予期しない振る舞いをする | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する | 問題: Windows プラットフォームにおいて Matrox AGP ビデオ・カードを使用すると、GUI の予期しない振る舞いが発生する |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するために十分な量のメモリーへのアクセスがない | 問題: 大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) |
Netscape 経由でリモート Web 管理を使用中にホストから切断される | ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される | 問題: Web 管理使用中に Netscape ブラウザー・ウィンドウのサイズを変更すると、ホストから切断される |
コンサルタントの追加時に接続エラーを受け取った | スイッチまたはコントローラーで構成設定が正しくない | 問題: コンサルタントの追加時に接続エラーを受け取った |
スイッチで重みが更新されない | コントローラーとスイッチとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: スイッチで重みが更新されない |
リフレッシュ・コマンドによってコンサルタント構成が更新されなかった | スイッチとコントローラーとの通信が使用できないか、またはこの通信に割り込みが入った | 問題: リフレッシュ・コマンドによってコンサルタント構成が更新されなかった |
Windows プラットフォームで、破損した Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する | 問題: Windows システムで、破壊された Latin 1 国別文字がコマンド・プロンプト・ウィンドウに現れる |
HP-UX プラットフォームで、「java.lang.OutOfMemoryError unable to create new native thread」というメッセージが表示される | デフォルトによる一部の HP-UX インストールで、プロセスごとに許可されるスレッドが 64 となっている。これでは数が足りない | 問題: HP-UX で、Java メモリー不足/スレッド・エラーが発生する |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
症状 | 考えられる原因 | 参照カ所 |
---|---|---|
Windows プラットフォーム上で .bat または .cmd ユーザー・メトリック・ファイルを実行すると、Metric Server の IOException が発生する | 完全なメトリック名が必要です。 | 問題: .bat または .cmd ユーザー・メトリック・ファイルを実行時の Windows プラットフォーム上の Metric Server IOException |
Metric Server が Load Balancer マシンに負荷情報を報告していない | 考えられる原因には、以下が含まれます。
|
問題: Metric Server が負荷を Load Balancer マシンに報告していない |
Metric Server ログに、サーバーへの鍵ファイルの転送時には「エージェントへのアクセスにはシグニチャーが必要です」と報告されています。 | 鍵ファイルは破壊が原因で許可に失敗しています。 | 問題: Metric Server ログに「エージェントへのアクセスにはシグニチャーが必要です」と報告されている |
AIX システムで、マルチプロセッサー・システム (AIX 5.1) 上で Metric Server が高ストレスの状態で実行されている場合に、ps -vg コマンド出力が破壊されることがあります。 | APAR IY33804 がこの既知の AIX の問題を訂正します。 | 問題: AIX システムで、Metric Server が高ストレスの状態で実行されている間に ps -vg コマンド出力が破壊される場合がある |
ハイ・アベイラビリティー Dispatcher 間の Site Selector ロード・バランシングを使用した 2 層構成での Metric Server の構成 | Metric Server (第 2 層に常駐) は新規 IP アドレスで listen するように構成されていません。 | 問題: ハイ・アベイラビリティー Dispatcher 間の Site Selector ロード・バランシングを使用した 2 層構成での Metric Server の構成 |
マルチ CPU の Solaris マシンで実行されている スクリプト (metricserver、cpuload、memload) が、希望と異なるコンソール・メッセージを出力する | この動作は、カーネルから CPU とメモリーの統計を収集するため に VMSTAT システム・コマンドが使用されていることによるものです。 | 問題: マルチ CPU の Solaris マシン上で実行されているスクリプトが 望まれないコンソール・メッセージを出す |
Solaris システムでは、Load Balancer プロセスを開始した端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 | 問題: Solaris システムでは、Load Balancer プロセスを開始した 端末ウィンドウを終了すると、そのプロセスは終了します |
Metric Server の始動後、メトリック値が -1 を戻す | この問題は、鍵ファイルをクライアントに転送中に、鍵ファイルの保全性が失われたために発生することがあります。 | 問題: Metric Server の始動後、メトリック値が -1 を戻す |
Dispatcher の実行で問題を検出した場合、通常は Dispatcher が使用するポート番号を使用しているアプリケーションがある可能性があります。Dispatcher サーバーは次のポート番号を使用します。
別のアプリケーションが Dispatcher のポート番号の 1 つを使用している場合は、Dispatcher のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Dispatcher のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
CBR の実行で問題が起こっている場合は、CBR が通常使用するポート番号を、アプリケーションの 1 つが使用している可能性があります。 CBR は以下のポート番号を使用します。
別のアプリケーションが CBR のポート番号の 1 つを使用している場合は、CBR のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、CBR のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Site Selector コンポーネントの実行で問題が起きる場合には、Site Selector が通常使用するポート番号をいずれかのアプリケーションが使用している可能性があります。Site Selector は以下のポート番号を使用しています。
別のアプリケーションが Site Selector のポート番号の 1 つを使用している場合は、Site Selector のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Site Selector のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Cisco CSS Controller コンポーネントの実行で問題が起きる場合には、Cisco CSS Controller の ccoserver が使用するポート番号の 1 つを別のアプリケーションが使用している可能性があります。Cisco CSS Controller は以下のポート番号を使用しています。
別のアプリケーションが Cisco CSS Controller のポート番号の 1 つを使用している場合は、Cisco CSS Controller のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Cisco CSS Controller のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
Nortel Alteon Controller コンポーネントの実行で問題が起きる場合には、Nortel Alteon Controller の nalserver が使用するポート番号の 1 つを別のアプリケーションが使用している可能性があります。Nortel Alteon Controller は以下のポート番号を使用しています。
別のアプリケーションが Nortel Alteon Controller のポート番号の 1 つを使用している場合は、Nortel Alteon Controller のポート番号を変更するか、または アプリケーションのポート番号を変更することができます。
次のようにして、Nortel Alteon Controller のポート番号を変更してください。
次のようにして、アプリケーションの RMI ポート番号を変更してください。
この問題は、Dispatcher が使用するポートのいずれかを別のアプリケーションが使用している場合に起こります。詳しくは、Dispatcher ポート番号のチェックを参照してください。
この問題は、指定したアドレス以外の他のアドレスが使用されている場合に起こります。Dispatcher とサーバーを連結している場合は、構成で使用されるサーバー・アドレスは NFA アドレスであるか、連結したものとして構成されていなければなりません。また、ホスト・ファイルで適正なアドレスを確認してください。
この問題には、クライアント・マシンからの接続が使用されていない、接続がタイムアウトであるなどの症状があります。以下のチェックを行い、この問題を診断します。
およびその他のプラットフォームの場合、ロード・バランシングのためのサーバー・マシンのセットアップ も参照してください。
この問題は、Dispatcher の HA 環境が構成されており、クライアント・マシンからの接続がサービスを提供されていない、あるいはタイムアウトになっている場合に起こります。以下をチェックして、問題を訂正または診断します。
以下のステップは、高可用性スクリプトが適切に 機能していることを検査する有効な方法です。
2 つの報告書は、スクリプトが適切に構成されている場合、同一です。
この Windows プラットフォームのエラーは、アダプターに送信元のアドレスが構成されていない場合に起こります。以下をチェックして、問題を訂正または診断します。
dscontrol executor configure <ip address>
広域サポートを使用している場合に、advisor が正しく機能していないと考えられる場合は、 ローカルおよびリモート両方の Dispatcher で advisor が開始していることを確認してください。
ICMP ping は、advisor が要求する前に、サーバーに対して発行されます。 Load Balancer とサーバーとの間にファイアウォールが存在する場合、ping が ファイアウォールを越えてサポートされることを確認してください。このセットアップがご使用のネットワークにセキュリティー・リスクを出している場合、dsserver の java ステートメントを 変更して、java プロパティーを追加することでサーバーに対するすべての ping を オフにしてください。
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Dispatcher の広域サポートとリモート advisor の使用を参照してください。
Windows Server 2008 が稼働するバックエンド・サーバーに Load Balancer が接続していると、メトリック・コレクション・フィーチャーが原因で memload.exe アプリケーションが不意に実行を停止することがあります。
異常終了の理由としては、これらのツールが必要とするパフォーマンス・キーが Windows Server 2008 のレジストリーに設定されていないことが考えられます。 このアプリケーション異常終了は、cpuload アプリケーションから報告されます。
この問題の対処法については、Microsoft のサポート技術情報トピック (http://support.microsoft.com/kb/300956) を参照してください。
Dispatcher、Microsoft IIS、および SSL の使用時に、これらが連係して動作しない場合、SSL セキュリティーの使用可能化で問題となることがあります。 鍵ペアの生成、証明書の取得、鍵ペアを含む証明書のインストール、SSL を必要とするディレクトリーの構成に 関する詳細については、「Microsoft Information and Peer Web Services」資料を参照してください。
Dispatcher は、鍵を使用して、ユーザーがリモート・マシンに接続して構成できるようにします。鍵は、接続用の RMI ポートを指定します。セキュリティー上の理由および競合のため、RMI ポートを変更することができます。RMI ポートを変更した場合は、鍵のファイル名が異なります。同じリモート・マシンの鍵ディレクトリーに複数の鍵があり、異なる RMI ポートを指定している場合は、コマンド行は、最初に見つかったものしか試行しません。誤っていると、接続は拒否されます。誤った鍵を削除しない限り、接続は確立されません。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで稼働していて、dscontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、dsserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=10199 を LB_RMISERVERPORT=yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、dsserver を再始動し、ポート 10099、10004、10199、および 10100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
例: java -Djava.rmi.server.hostname="10.1.1.1"
Windows プラットフォームで、デフォルトのブラウザーとして Netscape を使用している場合、 「ファイル '<filename>.html' (またはそのコンポーネントの 1 つ) が見つかりません」というエラー・メッセージが表示されることがあります。 パスおよびファイル名が正しいか確認し、必要なライブラリーがすべて使用可能 になっているようにしてください。
この問題は、HTML ファイルの関連付けが誤っていることが原因です。解決策は、以下のとおりです。
グラフィカル・ユーザー・インターフェース (GUI) の lbadmin を正しく機能させるには、十分なページング・スペースが必要です。使用可能なページング・スペースが不十分な場合には、GUI は正しく開始されません。これが起こる場合には、ページング・スペースを調べて、必要があればページング・スペースを増加してください。
別のバージョンを再インストールするために Load Balancer をアンインストールして、Dispatcher コンポーネントを開始しようとしたときにエラーが起きた場合には、Caching Proxy がインストールされているかどうかを調べてください。Caching Proxy にはいずれかの Dispatcher ファイルに依存関係があり、このファイルがアンインストールされるのは Caching Proxy をアンインストールしたときだけです。
この問題を避けるには、次のようにしてください。
Load Balancer の GUI の外観に問題が起きる場合は、オペレーティング・システムのデスクトップ解像度の設定を調べてください。GUI の表示には 1024x768 ピクセルのレゾリューションが最適です。
Windows プラットフォームでは、ヘルプ・ウィンドウを最初に開いたとき、既存のウィンドウの背後に隠れて見えなくなることがあります。これが起こる場合は、ウィンドウをクリックして、もう一度前面に出してください。
Solaris 上では、各ネットワーク・アダプターにはデフォルトで同じ MAC アドレスがあります。これは、各アダプターが異なる IP サブネット上にあるときには正しく機能します。しかし、スイッチ環境において、同じ MAC と同じ IP サブネット・アドレスをもつ複数の NIC が同じスイッチと通信すると、そのスイッチはすべてのトラフィックを同じワイヤーの下にある単一 MAC (および両方の IP) に送ります。フレームを最後にワイヤーに入れたアダプターだけが、両方のアダプター行きの IP パケットを表示できます。Solaris は、「誤った」インターフェースに届いた有効な IP アドレスのパケットを破棄する可能性があります。
すべてのネットワーク・インターフェースが、ibmlb.conf で構成されているように Load Balancer 用に指定されておらず、 かつ ibmlb.conf で定義されていない NIC がフレームを受け取った場合には、Load Balancer にはそのフレームを処理および転送する機能はありません。
この問題を避けるには、デフォルトを上書きして、それぞれのインターフェースごとに固有の MAC アドレスを設定する必要があります。以下のコマンドを使用してください。
ifconfig interface ether macAddr
例えば、以下のようになります。
ifconfig eri0 ether 01:02:03:04:05:06
Windows プラットフォームでは、ネットワーク・カードをインストールおよび構成していないと、executor を開始できません。
AIX オペレーティング・システムには、パス MTU ディスカバリーと呼ばれるネットワーク・パラメーターが入っています。クライアントとのトランザクション中に、発信パケットに小さめの最大送信単位 (MTU) を使用しなければならないとオペレーティング・システムが判別すると、パス MTU ディスカバリーは AIX にデータを記憶させるための経路を作成させます。 新規経路はその特定クライアント IP 用であり、そこに到達するために必要な MTU を記録します。
経路を作成しているときには、クラスターがループバック上に別名割り当てされる結果、サーバー上で問題が起きます。経路のゲートウェイ・アドレスがクラスター/ネットマスクのサブネットで途切れると、AIX システムはループバック上で経路を作成します。これは、そのサブネットを別名割り当てされた最後のインターフェースだった場合に起こります。
例えば、クラスターが 9.37.54.69 であり、255.255.255.0 のネットマスクが使用されて、使用予定のゲートウェイが 9.37.54.1 である場合、AIX システムは経路のループバックを使用します。 これにより、サーバーの応答がマシンから出されることがなくなり、クライアントは待機状態でタイムアウトしてしまいます。 通常は、クライアントにはクラスターからの応答が 1 つ表示され、次に経路が作成されてそのクライアントはそれ以上何も受け取りません。
この問題に対処するには、次のコマンドを入力します。
このコマンドにより値が永続的になり、値が現行および今後のリブート値に適用されるようになります。
広域 Load Balancer をセットアップするときには、リモート Dispatcher をローカル Dispatcher のクラスターにあるサーバーとして定義しなければなりません。通常は、リモート Dispatcher の非転送アドレス (NFA) をリモート・サーバーの宛先アドレスとして使用します。これを実行してからリモート Dispatcher 上のハイ・アベイラビリティーをセットアップすると、これは失敗します。 これの NFA を使用してアクセスするときに、ローカル Dispatcher がリモート・サイドのプライマリーを常にポイントしているために、これが起こります。
この問題を回避するには、次のようにしてください。
リモート・プライマリー Dispatcher を使用すると、このアドレスをアダプター上で別名割り当てしてトラフィックを受け入れできるようにします。障害が起きる場合には、アドレスがバックアップ・マシンに移動して、バックアップがそのアドレスのトラフィックの受け入れを継続します。
lbadmin または Web 管理 (lbwebaccess) を使用して大規模の構成ファイル (おおよそ 200 個以上の add コマンド) を ロードしようとすると、GUI がハングするか、あるいは予期しない振る舞い (画面変更への応答が極端に低速になるなど) を示す場合があります。
これは、Java にこのように大きな構成を処理するだけの十分なメモリーへのアクセス権がないことが原因で起こります。
Java に使用可能なメモリー割り振りプールを増やすために指定できる、実行時環境についてのオプションがあります。
オプション -Xmxn です。 ここで、n はメモリー割り振りプールの最大サイズ (バイト単位) です。 n は 1024 の倍数になっていなければならず、2MB より大きくなっていなければなりません。 値 n には、K バイトを示すために k または K が続いているか、あるいは M バイトを示すために m または M が続いていてもかまいません。 例えば、-Xmx128M と -Xmx81920k は両方とも有効です。 デフォルト値は 64M です。
例えば、このオプションを追加するには、lbadmin スクリプト・ファイルを編集し、次のように "javaw" を "javaw -Xmxn" に変更します。 (AIX システムの場合、"java" を "java -Xmxn" に変更します):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
n の推奨値はありませんが、デフォルト・オプションよりも 大きい数値にする必要があります。 手始めに手ごろなのはデフォルト値の 2 倍を指定することです。
構成を更新した後に Load Balancer 管理 (lbadmin) がサーバーから切断される場合は、構成しようとしているサーバーの dsserver のバージョンを確認して、これが lbadmin または dscontrol のバージョンと同じであることを確認してください。
セキュア Socks 実装でリモート・クライアントを使用するとき、 完全修飾ドメイン・ネームまたはホスト名が正しい IP アドレス形式表記の IP アドレスに 解決されないことがあります。Socks 実装は、特定の Socks 関連データを DNS 解決に追加する場合があります。
リモート接続で正しく IP アドレスに解決されない場合は、IP アドレス形式表記の IP アドレスを指定してください。
韓国語の Load Balancer インターフェースでの重複フォントまたは不適切なフォントを訂正するには、以下を行います。
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
Windows システムで MS ループバック・アダプターの別名割り当て後に、hostname などのコマンドを実行すると、OS がローカル・アドレスではなく別名アドレスを使用して不正に応答します。この問題を訂正するには、ネットワーク接続リストで、新たに追加された別名を ローカル・アドレスの下にリストする必要があります。 これで、ループバック別名の前にローカル・アドレスにアクセスされるようになります。
ネットワーク接続リストを確認するには、以下を行います。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
Linux システムで、Load Balancer カーネル・モジュールの手動除去中に dsserver が まだ実行中の場合、システム・ハングや javacore などの予期しない振る舞いが発生することがあります。Load Balancer カーネル・モジュールを手動で除去するときは、最初に dsserver を 停止する必要があります。
"dsserver stop" が機能しない場合、SRV_KNDConfigServer を使用して java プロセスを停止してください。 そのプロセスを停止するには、 ps -ef|grep SRV_KNDConfigServer コマンドを使用してプロセス ID を見つけてから、 killprocess_id コマンドを使用してそのプロセスを終了します。
"rmmod ibmlb" コマンドを実行して カーネルから Load Balancer モジュールを安全に除去することができます。
ロード・バランシング用に Dispatcher コンポーネントを実行している場合、クライアント・トラフィックでコンピューターが過負荷になることがあります。 Load Balancer カーネル・モジュールは最も高い優先度を持っており、これが絶え間なくクライアント・パケットを処理している場合、残りのシステムが 応答しなくなる場合があります。 ユーザー・スペースでコマンドを実行すると、完了するまでに非常に時間がかかるか、または完了しない可能性があります。
これが発生した場合、セットアップを再構成して、Load Balancer マシンが トラフィックで過負荷になることを回避する必要があります。 別の方法としては、複数の Load Balancer マシンに負荷を分散する、または Load Balancer マシンをより処理能力が高く、高速なコンピューターに 置き換える、というものがあります。
高クライアント・トラフィックが原因でマシンの応答が遅いのかどうかを判別するとき、この問題がクライアント・ピーク・トラフィック時間に発生するかどうかを検討します。 システムが誤って構成され、これが経路指定ループを招く場合には、同じ症状を引き起こすことがあります。 Load Balancer セットアップを変更する前に、この症状が高クライアント負荷によるものかどうかを 判別してください。
mac ベースの転送方式の使用すると、Load Balancer は、ループバックで別名を割り当てられた クラスター・アドレスを使用してパケットをサーバーに送信します。 いくつかのサーバー・アプリケーション (SSL など) は、構成情報 (証明書など) が IP アドレスに 基づいていることを必要とします。 受信パケットのコンテンツと一致するには、IP アドレスは、ループバックで 構成されたクラスター・アドレスでなければなりません。 サーバー・アプリケーションの構成時にクラスターの IP アドレスを使用しなかった場合、クライアント要求は正しくサーバーに転送されません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc パラメーターを増やすには、以下のようにします。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
Windows プラットフォームでは、複数の IP アドレスを使用して 1 つのアダプターを構成する場合、ホスト名に関連付ける IP アドレスは、レジストリーの先頭に構成します。
Load Balancer は多くのインスタンス (例えば、lbkeys create など) で InetAddress.getLocalHost() に依存するため、単一アダプターに複数の別名 IP アドレスを割り当てると、問題が起こる可能性があります。この問題を回避するには、ホスト名に解決される IP アドレスをレジストリーの先頭にリストします。例えば、以下のようになります。
デフォルトでは、Windows オペレーティング・システムは、ネットワーク障害を検出すると、すべての静的エントリーを含むアドレス解決プロトコル (ARP) キャッシュをクリアします。ネットワークが使用可能になると、ネットワークで送信された ARP 要求によって ARP キャッシュが再入力されます。
高可用性構成では、ネットワーク接続の切断がサーバーのどちらか、または両方に影響を与えると、両方のサーバーが 1 次運用を引き継ぎます。 ARP 要求が ARP キャッシュを再入力するために送信されると、両方のサーバーが応答し、これによって ARP キャッシュがエントリーに無効のマークを付けます。このため、advisor はバックアップ・サーバーに対するソケットを作成できなくなります。
接続が切断されても Windows オペレーティング・システムが ARP キャッシュをクリアしないようにすると、この問題が解決します。Microsoft は、この作業を行う方法を説明する記事を公開しています。この記事は、Microsoft サポート技術情報、記事番号 239924 (Microsoft Web サイト: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924) で参照できます。
以下は、Microsoft 記事で解説されている、システムによる ARP キャッシュの消去を回避する手順の要約です。
HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters
Linux カーネル 2.4.x サーバーおよび Dispatcher の MAC 転送方式を使用する場合には、 一定の考慮事項があります。 サーバーに、ip address add コマンドを使用してループバック・デバイスにクラスター・アドレスが構成されている場合、1 つのクラスター・アドレスにしか別名アドレスを割り当てることができません。
ループバック・デバイスへの複数のクラスターに別名アドレスを割り当てるときは、ifconfig コマンドを使用します。例えば、次のようになります。
ifconfig lo:num clusterAddress netmask 255.255.255.255 up
また、インターフェースを構成する ifconfig メソッドと ip メソッドには、いくつかの非互換性があります。最良実例では、サイトが 1 つのメソッドを選択し、そのメソッドを排他的に使用することが提案されています。
Dispatcher 構成にサーバーを追加するときに、次の エラー・メッセージが出されることがあります。 "エラー: ルーター・アドレスが指定されていないか、ポート・メソッドに対して有効でありません"
この問題を判別するには、次のチェックリストを使用してください。
router パラメーターのデフォルト値は 0 で、サーバーがローカルであることを示しています。 サーバーのルーター・アドレスを 0 以外に設定すると、サーバーが別のサブネット上のリモート・サーバーであることを示します。 server add コマンドの router パラメーターの詳細については、dscontrol server — サーバーの構成 を参照してください。
追加するサーバーが別のサブネット上に存在する場合は、 router パラメーターの値は、ローカル・サブネット上でリモート・サーバーと通信するために使用される ルーターのアドレスにしてください。
Solaris システムでは、Load Balancer スクリプト (dsserver や lbadmin など) を 端末ウィンドウから開始した場合、そのウィンドウを終了すると、 Load Balancer プロセスも終了します。
この問題を解決するには、nohup コマンドを使用して Load Balancer スクリプトを 開始します。 例えば、次のようになります。 nohup dsserver このコマンドを使用すると、端末セッションが終了するときに 端末セッションから開始されたプロセスが端末からハングアップ・シグナルを受けず、端末セッションが終了した後もプロセスが継続することができます。 端末セッションの終了後も処理を継続させる Load Balancer スクリプトの前には、 nohup コマンドを使用してください。
Load Balancer 構成のロードには、長時間かかることがあります。 これは、サーバー・アドレスを解決して検証するために、ドメイン・ネーム・システム (DNS) 呼び出しが行われるためです。
Load Balancer マシンの DNS の構成に誤りがある場合、または DNS 全般に長時間かかる場合は、 ネットワーク上で DNS 要求を送信する Java プロセスが原因で、構成のロードの速度が低下します。
この問題に対する次善策は、サーバー・アドレスおよびホスト名を ローカルの /etc/hosts ファイルに追加することです。
高可用性が構成されている場合は、 短時間の間、両方のマシンでクラスター・アドレスが構成されていることがあり、 その結果次のエラー・メッセージが出されます:「ネットワーク上の他のシステムとの IP アドレスの競合があります」。 この場合は、メッセージを無視しても問題がありません。 クラスター・アドレスを、短時間の間、両方の高可用性マシンで同時に構成することは可能です (特に片方のマシンのスタートアップ中や、テークオーバーが開始されたとき)。
go* スクリプトを調べ、クラスター・アドレスが正しく構成されたり構成から外されるようになっている ことを確認してください。 ユーザーが構成ファイルを呼び出しており、go* スクリプトがインストールされている場合は、 構成ファイルのクラスター・アドレスに対する "executor configure" コマンド・ステートメントが使用されていない ことを確認してください。このステートメントが使用されていると、go* スクリプト の configure および unconfigure コマンドと競合します。
ハイ・アベイラビリティーの構成時の go* スクリプトについては、 スクリプトの使用を参照してください。
この問題は、go スクリプトがプライマリー・マシンおよびバックアップ・マシンの両方で稼働していないときに発生することがあります。go スクリプトは dsserver が、両方のマシンで開始されていないと稼働しません。 両方のマシンを検査して、dsserver が稼働しているかどうか確認してください。
最大伝送単位 (MTU) が Dispatcher マシンに適切に設定されていないと、クライアントは、 大容量のページの結果がタイムアウトを応答するように要求します。Dispatcher コンポーネントの CBR および NAT 転送方式の場合、Dispatcher が値をネゴシエーションするのではなく、MTU 値を デフォルトとして取るため、これが発生します。
MTU は、通信メディア・タイプ (例えば、イーサネットまたはトークンリング) を基にした オペレーティング・システムごとに設定されます。ローカル・セグメントからのルーターは、 異なるタイプの通信メディアに接続する場合、より小さな MTU セットを持ち ます。標準 TCP トラフィックのもとでは、MTU ネゴシエーションは、接続セットアップ中に 起こり、最も小さな MTU が、マシン間のデータ送信に使用されます。
Dispatcher は、Dispatcher の CBR または NAT 転送方式では MTU ネゴシエーションを サポートしません。TCP 接続のエンドポイントとして積極的に組み込まれているからです。 CBR および NAT 転送方式の場合、Dispatcher はデフォルトとして MTU 値を 1500 に します。この値は、標準イーサネットの標準 MTU サイズです。それで、ほとんどのカスタマーは この設定を調整する必要がありません。
Dispatcher の CBR または NAT 転送方式を使用している時、より小さな MTU を持つ ローカル・セグメントに対するルーターの場合、より小さな MTU にマッチングする Dispatcher マシンに MTU を設定する必要があります。
この問題を解決するには、以下のコマンドを使用して、最大セグメント・サイズ (mss) の値を設定します。dscontrol executor set mss new_value
例えば、以下のようになります。
dscontrol executor set mss 1400
mss のデフォルト値は 1460 です。
mss の設定値は、Dispatcher の mac 転送形式、または Load Balancer の 任意の non-Dispatcher コンポーネントに適用されません。
複数の IP アドレスが Windows システムに存在し、ホスト・ファイルが ホスト名に関連づけられたアドレスを指定しない時、 オペレーティング・システムは最も小さなアドレスを選択して、ホスト名に関連づけます。
この問題を解決するには、c:¥Windows¥system32¥drivers¥etc¥hosts ファイルを、使用するマシンのホスト名、ホスト名に関連付ける IP アドレスで更新してください。
重要: その IP アドレスは、クラスター・アドレスにすることはできません。
qeth ネットワーク・ドライバーと一緒に Linux for S/390 マシンで 高可用性を使用している時、活動中および待機中の Dispatchers が同期するのに失敗することがあります。 この問題は、Linux Kernel 2.6 に限定される可能性があります。
この問題が発生した場合、以下の次善策を使用してください。
活動中と待機中の Dispatcher イメージ間の channel-to-channel (CTC) ネットワーク・デバイスを定義して、2 つの CTC エンドポイント IP アドレス間に ハートビートを追加します。
Load Balancer の高可用性機能を使用すると、 プライマリー・パートナーの障害やシャットダウンの場合に、 パートナー・マシンがロード・バランシングを引き継ぐことができます。 高可用性パートナー間の接続を維持するために、 2 台のマシン間で接続レコードが受け渡しされます。 バックアップ・パートナーがロード・バランシング機能を引き継ぐと、 クラスター IP アドレスがバックアップ・マシンから除去され、新しいプライマリー・マシンに追加されます。 この引き継ぎ操作に影響する可能性のある、タイミングと構成に関する考 慮事項がいくつかあります。
このセクションにリストされているヒントは、以下のような高可用性の構成上の問題から発生する問題の改善に役立ちます。
以下のヒントは、Load Balancer マシンで高可用性を正しく構成するのに役立ちます。
高可用性コマンドの例として、以下のものがあります。
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
通常、高可用性の定義はファイルの終わりに配置する必要があります。 クラスター、ポート、およびサーバーのステートメントは、高可用性ステートメントの前に配置する必要があります。 これは、高可用性が同期する際に、 接続レコードの受信時にクラスター、ポート、およびサーバー定義を検索 するためです。
クラスター、ポート、およびサーバーが存在しない場合、接続レコードはドロップされます。 引き継ぎが行われたときにパートナー・マシンに接続レコードが複製されていないと、 接続は失敗します。
このルールの例外は、MAC 転送方式で構成された連結サーバーを使用する場合です。 この場合、高可用性ステートメントは、連結サーバー・ステートメントの前に配置する必要があります。 高可用性ステートメントが連結サーバー・ステートメントの前にない場合、 Load Balancer は連結サーバーに対する要求を受け取りますが、 この要求はクラスターに対する着信要求と同じように表示され、ロード・バランシングが行われます。 その結果、ネットワーク上でパケットがループし、余分なトラフィックが 発生します。 高可用性ステートメントが連結サーバーの前に配置されると、 Load Balancer は、活動状態になるまで着信トラフィックを転送 してはならないことを認識します。
この振る舞いを訂正するには、goActive スクリプトにスリープ遅延を追加します。 スリープに必要な時間は、デプロイメントによって異なります。 最初はスリープ遅延時間を 10 にすることをお勧めします。
デフォルトで、マシンは 1/2 秒ごとに相互通信を試み、 4 回失敗すると失敗が検出されます。 ビジーのマシンがあると、システムが正しく機能していても、フェ イルオーバーになることがあります。 次のコマンドを実行して、失敗になるまでの回数を増やすことができます。
dscontrol executor set hatimeout <value>
これを行うには、長期に渡って、前の接続がメモリーに残 らないようにする必要があります。 特に、LDAP ポートと (1 日を超過する) 長い staletimeout 期間に関する問題があります。 長い staletimeout 期間を設定すると、 前の接続がメモリーに残り、同期の際に渡される接続レコードが増え、 両方のマシンでのメモリー使用量も増えます。
妥当な staletimeout 期間で同期が失敗した場合は、 次のコマンドを実行して同期タイムアウトを増やすことができます。
e xm 33 5 new_timeoutこのコマンドは、保存の際には構成ファイルに保存されないので、シャットダウンが起こってもこの設定が存続する必要がある場合は、このコマンドを手動で構成ファイルに追加する必要があります。
タイムアウト値は 1/2 秒単位で保管されます。 したがって、new_timeout のデフォルト値は 100 (50 秒) です。
一般に、MAC 転送方式を使用する場合、Load Balancer 構成のサーバーは、 プラットフォームに関係なく、すべて同じネットワーク・セグメント上に存 在する必要があります。 Load Balancer は、ルーター、ブリッジ、およびファイアウォールなどの活動中のネットワーク装置によって干渉されます。 これは、Load Balancer が、ネクスト・ホップと最終ホップへのリン ク層ヘッダーのみを変更する、特殊なルーターとして機能するため です。 ネクスト・ホップが最終ホップではないネットワーク・トポロジーは、 Load Balancer では無効です。
OSA カードを共有する zSeries および S/390 サーバー向けの制限があります。 これは、このアダプターが通常のネットワーク・カードとは異なる動作をするためです。 OSA カードには、独自の仮想リンク層が実装されています。 これは、イーサネットとは関係がなく、その背後にある Linux および z/OS ホスト向けです。 事実上、各 OSA カードは、ちょうどイーサネット間ホスト (OSA ホスト向けではありません) のようなもので、 このカードを使用するホストは、このカードがあたかもイーサネットであるか のように これに応答します。
OSA カードには、IP 層に直接関連したいくつかの機能も実行します。 ARP (アドレス解決プロトコル) 要求への応答は、このホストが実行する機能の 1 例です。 もう 1 つの機能は、イーサネット・アドレスの代わりに、 宛先の IP アドレスを基に、共有 OSA が IP パケットをレイヤー 2 スイッチとして経路指定することです。 事実上、OSA カードは、それ自体へブリッジされたネットワーク・セグメントです。
S/390 Linux または zSeries Linux ホスト上で実行される Load Balancer は、 同じ OSA 上のホストやイーサネット上のホストに転送できます。 同じ共有 OSA 上のすべてのホストは、事実上同じセグメント上にあります。
Load Balancer は、OSA ブリッジの性質により、共有 OSA の外部に転送 することができます。 このブリッジは、クラスター IP を所有する OSA ポートを認識します。 このブリッジは、直接イーサネット・セグメントに接続されているホストの MAC アドレスを認識します。 したがって、Load Balancer は 1 つの OSA ブリッジを介して MAC 転送することができます。
ただし、Load Balancer は共有 OSA 内に転送することはできません。 バックエンド・サーバーが Load Balancer とは異なる OSA カードを使用しているときに、 Load Balancer が S/390 Linux 上にある場合も同様です。 バックエンド・サーバー向けの OSA は、サーバー IP の OSA MAC アドレスを通知しますが、 サーバーの OSA カードは、パケットがサーバー向けの OSA のイーサネットの宛先アドレスとクラスター IP とともに到着した場合、 どのホスト (存在する場合) がそのパケットを受け取るのかを認識しません。 ある共有 OSA の外部へ向けた OSA からイーサネットへの MAC 転送が許可 されるときと同じ原理は、共有 OSA の内部に向けて転送する際には無効です。
次善策:
OSA カードを備えた zSeries または S/390 サーバーを使用する Load Balancer 構成では、 前述の問題の次善策として実行できる方法が 2 つあります。
Load Balancer 構成のサーバーが、同じタイプの zSeries または S/390 プラットフォーム上にある場合、 Load Balancer と各サーバーの間で point-to-point (CTC または IUCV) 接続を定義できます。 プライベート IP アドレスを持つエンドポイントをセットアップします。 point-to-point 接続は、Load Balancer とサーバー間のトラフィックにのみ使用します。 次に、トンネルのサーバー・エンドポイントの IP アドレスを持つサーバーを追加します。 この構成により、クラスター・トラフィックが Load Balancer の OSA カードを介して到達し、 point-to-point 接続を介して転送されます。 この場合、サーバーは独自のデフォルトの経路を通って応答します。 応答は、サーバーの OSA カードを使用して発信されますが、 このカードは同じである場合もあれば、異なる場合もあります。
Load Balancer 構成内のサーバーが同じタイプの zSeries ある いは S/390 プラットフォーム上にない場合、 または Load Balancer と各サーバーの間で point-to-point 接続を定義できない場合は、 Load Balancer の総称経路指定カプセル化 (GRE) 機能を使用することをお勧めします。 これは、Load Balancer に、ルーターを介した転送を許可するプロトコルです。
GRE を使用する場合、クライアントからクラスターへの IP パケットは、 Load Balancer が受け取り、カプセル化してサーバーに送信します。 サーバーでは、元のクライアントからクラスターへの IP パケットがカプセル化され、 サーバーが直接クライアントに応答します。 GRE を使用する利点は、Load Balancer が、サーバーからクライアントへのトラフィックではなく、 クライアントからサーバーへのトラフィックのみを認識することです。 欠点は、カプセル化のオーバーヘッドにより、TCP 接続の最大セグメント・サイズ (MSS) が小さくなることです。
GRE カプセル化を使用して転送するように Load Balancer を構成するには、 次のコマンドを使用してサーバーを追加します。
dscontrol server add cluster_add:port:backend_server router backend_server
この場合、router backend_server は、 Load Balancer とバックエンド・サーバーが同じ IP サブネット上にある場合に有効です。 そうでない場合は、有効な、ネクスト・ホップの IP アドレスをルーター として指定します。
ネイティブの GRE カプセル化を実行するように Linux システムを 構成するには、バックエンド・サーバーごとに、以下のコマンドを発行します。
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add cluster_addr dev grelb0
manager および advisor 機能で構成された Load Balancer を実行中に、 一部の Red Hat Linux バージョンで大量のメモリー・リークが発生することがあります。 advisor の時間間隔を短く設定して構成すると、Java のメモリー・リークが増加します。
Red Hat Enterprise Linux 3.0 などの一部の Linux 配布版に同梱の JVM の IBM Java SDK バージョンおよび Native POSIX Thread Library (NPTL) では、 メモリー・リークが起こる可能性があります。拡張スレッド化ライブラリー NPTL は、NPTL をサポートするいくつかの Linux システムの配布版 (Red Hat Enterprise Linux 3.0 など) に同梱されます。
Linux システムおよびこれらのシステムに同梱の IBM Java SDK に関する最新情報については、 http://www.ibm.com/developerworks/java/jdk/linux/tested.html を参照してください。
問題判別ツールとして、vmstat または ps コマンドを使用してメモリー・リークを検出します。
メモリー・リークを修正するには、Load Balancer マシンを実行する前に 、次のコマンドを発行して NPTL ライブラリーを使用不可にします。
export LD_ASSUME_KERNEL=2.4.10
Suse Linux Enterprise Server 9 では、MAC 転送方式の使用中、 DisPatcher 報告書に、パケットが転送された (パケット数が増加) にも かかわらず、バックエンド・サーバーに到達していないということが示される場合があります。
この問題が発生した場合は、以下のいずれか、またはその両方を監視します。
ip_finish_output2: No header cache and no neighbour!
ICMP Destination unreachable: Fragmentation Needed
この問題は、ロードされた iptables NAT モジュールが原因で発生することがあります。 SLES 9 では、このバージョンの iptables で、Dispatcher との 対話で異常な振る舞いが発生するという、起こりうるが未確認のエラーが発生 します。
解決策:
iptables NAT モジュールと接続トラッキング・モジュールをアンロードします。
例えば、以下のようになります。
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
モジュールをその使用順序に従って除去します。 具体的には、モジュールは参照数 (lsmod 出力の最終列) がゼロである場合にのみ除去できます。 iptables のルールを構成した場合は、それらを除去する必要があります。 例えば、iptables -t nat -F のようにします。
iptable_nat モジュールは ip_conntrack を使用するので、 まず iptable_nat モジュールを除去してから ip_conntrack モジュールを除去します。
Windows システムでは、Load Balancer の高可用性機能を実行する場合、 go スクリプトを使用して活動中の Load Balancer 上にクラスター IP を構成し、 引き継ぎが行われるときにバックアップ・システム上のクラスター IP の構成を解除します。 活動中のマシンでクラスターの IP アドレスを構成する go スクリプトを、 バックアップ・マシンで IP クラスター・アドレスの構成を解除する go スクリプトの前に実行すると、問題が発生することがあります。 システムで IP アドレスの競合が検出されたことを通知するポップアップ・ウィンドウが表示される場合があります。 ipconfig all コマンドを実行した場合に、マシン上に 0.0.0.0 という IP アドレスがあると表示される場合もあります。
解決策:
次のコマンドを発行して、プライマリー・マシンから手動でクラスター IP アドレスの構成を解除します。
dscontrol executor unconfigure clusterIP
これにより、 Windows IP スタックから 0.0.0.0 アドレスが除去されます。
高可用性パートナーがクラスター IP アドレスを解放した後、 次のコマンドを発行して、手動でクラスター IP を追加し直します。
dscontrol executor configure clusterIP
このコマンドの発行後、次のコマンドを発行して、Windows IP スタ ックで再度クラスター IP アドレスを検索します。
ipconfig /all
Linux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Dispatcher マシンでは無効にする必要があります。
次のコマンドを発行して、iptables がロードされているかを判別します。
lsmod | grep ip_tables
このコマンドからの出力は、次のようになります。
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
出力にリストされて いる各 iptable に対して次のコマンドを発行して、テーブルのルールを表示します。
iptables -t <short_name> -L
例えば、以下のようになります。
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
iptable_nat がロード済みの場合は、アンロードする必要があります。 iptable_nat は iptable_conntrack に依存するため、iptable_conntrack も除去する必要があります。 次のコマンドを発行して、これら 2 つの iptables をアンロードします。
rmmod iptable_nat iptable_conntrack
Load Balancer のインストール・プロセスでは、Java ファイル・セットもインストールされます。 Load Balancer は、製品とともにインストールされる Java バージョンを使用する唯一のアプリケーションです。 このバージョンの Java ファイル・セットは、独自にアップグレードしないでください。 Java ファイル・セットのアップグレードを必要とするような問題がある場合は、 IBM サービスに連絡した上で、Load Balancer に同梱の Java ファイル・セットを正式な修正レベルでアップグレードしてください。
Microsoft Windows オペレーティング・システム上では、高可用性の引き継ぎ時に パーシスタント接続が切断される場合があります。この問題は、MAC 転送方式を使用する連結サーバーの場合にのみ発生します。
イーサネット・インターフェースまたはループバック・インターフェースからクラスター IP アドレスが削除された場合、その IP アドレス上のすべての接続がリリースされます。リリースされた接続上でパケットを受信すると、オペレーティング・システムはクライアントに RST 応答を送信し、接続は終了します。
高可用性の引き継ぎ中に接続が切断されるのを回避するには、MAC 転送方式の使用時に、Windows オペレーティング・システム上で連結サーバーを使用しないでください。
この問題は、他のアプリケーションが CBR によって使用されるポートのいずれかを使用している場合に起こります。詳細については、CBR ポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで実行されていて、cbrcontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、cbrserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=11199 を LB_RMISERVERPORT=yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、cbrserver を再始動し、ポート 11099、10004、11199、および 11100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
Caching Proxy および CBR は開始されましたが、要求はロード・バランシングされていません。このエラーは、executor を開始する前に Caching Proxy を開始すると起こる可能性があります。これが起こる場合は、Caching Proxy の stderr ログにエラー・メッセージ「ndServerInit: executor に接続できません」が入ります。この問題を避けるには、Caching Proxy を開始する前に executor を開始します。
Solaris システムで、cbrcontrol executor start コマンドによって「エラー: executor が開始されていませんでした」が戻されます。 このエラーは、そのシステムの IPC (プロセス間通信) を構成していないために、共有メモリー・セグメントとセマフォー ID の最大サイズが、オペレーティング・システムのデフォルトより大きくなっている場合に起こります。共有メモリー・セグメントおよびセマフォー ID のサイズを増加するには、/etc/system ファイルを編集する必要があります。このファイルの構成方法について詳しくは、IPC (プロセス間通信) のシステム・デフォルトの変更のセクションを参照してください。
URL ルールが機能しないときには、構文エラーまたは構成エラーのある可能性があります。この問題が起きる場合には、以下をチェックしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、max_thread_proc パラメーターを増やすのステップを参照してください。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
この設定の構成に関する説明については、タスク・オフロードを使用不可にするのセクションを参照してください。
Windows プラットフォームでは、複数の IP アドレスを使用して 1 つのアダプターを構成する場合、ホスト名に関連付ける IP アドレスはレジストリーの先頭に構成します。
Load Balancer は多くのインスタンス (例えば、lbkeys create など) で InetAddress.getLocalHost() に依存するため、単一アダプターに複数の別名 IP アドレスを割り当てると、問題が起こる可能性があります。この問題を回避するには、ホスト名に解決される IP アドレスをレジストリーの先頭にリストします。
この問題に対処するためには、コントロール パネルの「ネットワーク接続」オプションの「詳細設定」でアダプターの順序を変更してください。 例えば、以下のようになります。
この問題は、他のアプリケーションが Site Selector によって使用されるポートのいずれかを使用している場合に起こります。詳細については、Site Selector ポート番号のチェックを参照してください。
症状: Site Selector コンポーネントが Solaris クライアントからの受信要求をラウンドロビンしません。
考えられる原因: Solaris システムがネーム・サービス・キャッシュ・デーモンを実行しています。このデーモンが実行されていると、後続のリゾルバー要求は Site Selector ではなくこのキャッシュから応答されます。
解決法: Solaris マシン上のネーム・サービス・キャッシュ・デーモンをオフにしてください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで実行されていて、sscontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、ssserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 LB_RMISERVERPORT=10199 を LB_RMISERVERPORT=yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、ssserver を再始動し、ポート 12099、10004、12199、および 12100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
Site Selector は DNS に参加していなければなりません。 構成に関係しているマシンのすべては、このシステムにも関係している必要があります。 Windows システムでは、DNS に必ずしもホスト名が入っていなくても構いません。Site Selector は、正しく開始されるために、そのホスト名が DNS に定義されていることが必要です。
このホストが DNS に定義されていることを確認してください。 ssserver.cmd ファイルを編集し、"w" を "javaw" から除去してください。 これで、エラーについてより多くの情報が提供されます。
Site Selector のネーム・サーバーがマシン上のどのアドレスにもバインドされていません。これは、マシン上の有効な任意の IP 用に予定された要求に応答します。Site Selector は、クライアントに戻す応答の経路指定をオペレーティング・システムに依存します。Site Selector マシンに複数のアダプターがあり、そのいくつかが同じサブネットに接続されている場合は、O/S がクライアントへの応答を受け取ったものとは異なるアドレスから送信することが可能です。クライアント・アプリケーションによっては、送信したアドレス以外から受信した応答を受け入れません。そのために、ネーム・レゾリューションにより失敗することになります。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、max_thread_proc パラメーターを増やすのステップを参照してください。
Load Balancer マシンにアダプターを構成するときには、advisor が機能するように、次の 2 つの設定が正しいことを確認してください。
説明については、タスク・オフロードを使用不可にするのセクションを参照してください。
この問題は、Cisco CSS Controller の ccoserver が使用するいずれかのポートを別のアプリケーションが使用すると起こります。詳細については、Cisco CSS Controller ポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで実行されていて、ccocontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、ccoserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 CCO_RMISERVERPORT=14199 を CCO_RMISERVERPORT=yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、ccoserver を再始動し、ポート 13099、10004、13199、および 13100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
この問題は、有効な製品ライセンスがないときに起こります。ccoserver を開始するときに、以下のメッセージを受け取ります。
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
この問題を訂正するには、次のようにしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
コンサルタントの追加時に、正しくない構成設定が原因で接続エラーが発生することがあります。 この問題を修正するには、次のようにしてください。
この問題を修正するには、次のようにしてください。
コンサルタントのログ・レベルを上げ、コマンドを再試行します。 再度失敗した場合、ログで SNMP タイムアウトまたはその他の SNMP 通信エラーを検索してください。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、max_thread_proc パラメーターを増やすのステップを参照してください。
この問題は、Nortel Alteon Controller の nalserver が使用する いずれかのポートを別のアプリケーションが使用すると起こります。 詳細については、Nortel Alteon Controller ポート番号のチェックを参照してください。
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
これは、管理コンソールの 1 つがファイアウォールと同じマシンで、あるいはファイアウォール経由で実行されている場合、問題の原因となる可能性があります。 例えば、Load Balancer がファイアウォールと同じマシンで実行されていて、nalcontrol コマンドが出されると、「エラー: サーバーが応答していません」などのエラーが出される場合があります。
この問題を避けるには、nalserver スクリプト・ファイルを編集して、ファイアウォール (または他のアプリケーション) 用に RMI が使用するポートを設定します。 行 NAL_RMISERVERPORT=14199 を NAL_RMISERVERPORT=yourPort に変更します。ここで、yourPort は別のポートです。
完了したら、nalserver を再始動し、ポート 14099、10004、14199、および 14100、あるいは管理コンソールの実行元のホスト・アドレス用に選択されてポートのトラフィックをオープンします。
この問題は、有効な製品ライセンスがないときに起こります。nalserver を開始するときに、以下のメッセージを受け取ります。
Your license has expired. Contact your local IBM representative or authorized IBM reseller.
この問題を訂正するには、次のようにしてください。
Windows プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
リモート Web 管理を使用して Load Balancer を構成している場合、 Load Balancer GUI が表示されている Netscape ブラウザー・ウィンドウのサイズを変更 (「Minimize」、「Maximize」、「Restore Down」など) しないでください。 ブラウザー・ウィンドウのサイズが変更されるたびに Netscape はページを再ロードするため、ホストから切断されます。 ウィンドウのサイズを変更するたびにホストに再接続する必要があります。 Windows プラットフォームでリモート Web 管理を行う場合は、Internet Explorer を使用してください。
コンサルタントの追加時に、正しくない構成設定が原因で接続エラーが発生することがあります。 この問題を修正するには、次のようにしてください。
この問題を修正するには、次のようにしてください。
コンサルタントのログ・レベルを上げ、コマンドを再試行します。 再度失敗した場合、ログで SNMP タイムアウトまたはその他の SNMP 通信エラーを検索してください。
Windows オペレーティング・システムのコマンド・プロンプト・ウィンドウに、Latin 1 ファミリーの国別文字の一部が破壊されて表示される場合があります。例えば、波形記号付きの文字 "a" がパイ記号で表示される場合があります。 これを修正するには、コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する必要があります。 フォントを変更するには、以下のようにします。
一部の HP-UX 11i インストールは、各プロセスで 64 のスレッドのみを許可するようにあらかじめ構成されています。ただし、一部の Load Balancer 構成には、これより多くのスレッドが必要です。HP-UX システムの場合、 プロセス当たりのスレッド数を最低 256 に設定してください。 この値を増やすには、"sam" ユーティリティーを使用して max_thread_proc カーネル・パラメーターを設定します。大量に使用することが予想される場合、max_thread_proc を 256 以上にします。
max_thread_proc を増やすには、max_thread_proc パラメーターを増やすのステップを参照してください。
Windows プラットフォーム上で実行する Metric Server のユーザー作成メトリックには、完全メトリック名を使用する必要があります。例えば、usermetric ではなく、usermetric.bat を指定しなければなりません。usermetric の名前はコマンド行では有効ですが、実行時環境内部から実行するときには動作しません。完全メトリック名を使用しないと、Metric Server 入出力例外を受け取ります。metricserver コマンド・ファイルにおいて LOG_LEVEL 変数を 3 の値に設定してから、ログ出力にチェックを入れてください。この例では、例外は次のように表示されます。
... java.io.IOException: CreateProcess: usermetric error=2
Metric Server が負荷情報を Load Balancer に報告していない理由はいくつか考えられます。この原因を判別するには、以下の検査を実行します。
この問題は、metricserver スクリプトの Java プロパティー java.rmi.server.hostname にホスト名を指定することによっても解決できます。
Metric Server ログには、鍵ファイルがサーバーに転送された後で、このエラー・メッセージが報告されています。
このエラーが記録されるのは、ペアのキーの破壊が原因で、鍵ファイルがペアのキーによる許可に失敗する場合です。 この問題を訂正するには、以下を試みます。
マルチプロセッサー AIX プラットフォーム (4.3.3、32 ビット 5.1、または 64 ビット 5.1) 上で Metric Server が高ストレスの状態で実行されている間に、ps -vg コマンドからの出力が破壊される場合があります。 例えば、以下のようになります。
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
ps コマンドの SIZE フィールドまたは RSS フィールド (あるいは、その両方) で、メモリーが過剰に使用されていることを示す場合があります。
これは、AIX カーネルに関する既知の問題です。APAR IY33804 がこの問題を訂正します。 http://techsupport.services.ibm.com/server/fixes の AIX サポートからフィックスを入手するか、 またはお近くの AIX サポート担当者に連絡してください。
2 層 Load Balancer 構成では、Site Selector (第 1 層) が Dispatcher ハイ・アベイラビリティー・パートナーのペアでロード・バランシングを行っている場合、Metric Server コンポーネントを構成するために完了しなければならない手順があります。Metric Server 専用の新規 IP アドレスで listen するように、Metric Server を構成する必要があります。2 つのハイ・アベイラビリティー Dispatcher マシンにおいては、Metric Server はアクティブ Dispatcher でのみアクティブになります。
このセットアップを正しく構成するには、次の手順を完了してください。
例えば、以下のようになります。
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Sleep either max 60 seconds or until the metricserver stops let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
例えば、以下のようになります。
call netsh interface ip delete address "Local Area Connection" addr=9.27.23.61 call netsh interface ip add address "Local Area Connection 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
metricserver、cpuload、および memload スクリプトは、マルチ CPU の Solaris マシンで実行する場合は、 ユーザーの望まないコンソール・メッセージを出す場合があります。 この動作は、カーネルから CPU とメモリーの統計を収集するため に VMSTAT システム・コマンドが使用されていることによるものです。 VMSTAT が戻すメッセージの一部は、 カーネルの状態が変更したことを示しています。 スクリプトは、 これらのメッセージをハンドルできないので、その結果 シェルから不要なコンソール・メッセージが表示されます。
これらのコンソール・メッセージの例として、次のものがあります。
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
これらのメッセージは、無視することができます。
この問題は、クライアントへの転送中に鍵ファイルの保全性が失われた結果、発生することがあります。
FTP を使用して Load Balancer マシンからバックエンド・サーバーに鍵ファイルを転送する場合は、 必ずバイナリー・モードを使用して FTP サーバーとの間で鍵ファイルを put または get してください。