Content Based Routing で発生する可能性のある問題を解決する手助けとなるように提供されている情報を使用します。
症状 | 考えられる原因 |
---|---|
Dispatcher が正常に実行されない | ポート番号が競合している |
クライアント・マシンからの接続がサービスを受けていない、あるいは接続がタイムアウトである |
|
Dispatcher、Microsoft IIS、および SSL が機能しない、または続行しない | 暗号化されたデータをプロトコルを介して送信できない |
dscontrol コマンドまたは lbadmin コマンドが失敗し、「サーバーが応答していません」または「RMI サーバーにアクセスできません」メッセージが表示される |
|
advisor が正しく機能しない | advisor が実行されていない |
「ファイルが見つかりません...」というエラー・メッセージが、Netscape をデフォルト・ブラウザーとして稼働し、オンライン・ヘルプを表示すると出される (Windows プラットフォーム) | HTML ファイルの関連付けの設定が誤っている |
グラフィカル・ユーザー・インターフェースが正しく開始されない | 不適当なページング・スペース |
グラフィカル・ユーザー・インターフェースが正しく表示されない | レゾリューションが誤りである |
ヘルプ・パネルが他のウィンドウの背後に隠れて見えなくなることがある | Java™ の制限 |
大きい構成ファイルをロードしようとしているときに GUI がハングする (あるいは予期しない振る舞い) | Java には、GUI に対するこのように大きな変更を処理するための十分な量のメモリーへのアクセス権限がない |
AIX® および Linux システムにおいて、韓国語の Load Balancer インターフェースで、文字が重なりあったフォントまたは不適切なフォントが表示される | デフォルトのフォントを変更する必要がある |
Windows プラットフォームと Matrox AGP ビデオ・カードの組み合わせで使用すると、GUI の予期しない振る舞いが発生する | Load Balancer GUI の実行中に Matrox AGP ビデオ・カードを使用すると、問題が発生する |
Dispatcher マシンでコマンドを実行したときの応答が遅い | 高ボリュームのクライアント・トラフィックによるマシンの過負荷が原因で、応答が遅くなっている可能性がある |
SSL advisor または HTTPS advisor がサーバーの負荷を登録しない | SSL サーバー・アプリケーションがクラスター IP アドレスで 構成されていないことが原因で問題が発生する |
Windows プラットフォームで、破壊された Latin 1 国別文字がコマンド・プロンプトに現れる | コマンド・プロンプト・ウィンドウのフォント・プロパティーを変更する |
Windows プラットフォームで、advisor およびリーチ・ターゲットがすべてのサーバーにダウンのマークを付ける | タスクのオフロードが使用不可になっていない、または ICMP を使用可能にする必要がある |
Windows プラットフォームで、ネットワーク障害後に高可用性セットアップで advisor が機能しない | システムは、ネットワーク障害を検出すると、アドレス解決プロトコル (ARP) キャッシュを消去します。 |
Linux システムで、「IP address add」コマンドと、複数のクラスター・ループバックの別名が非互換 | ループバック・デバイスの複数のアドレスに別名を割り当てるときは、ip address add ではなく ifconfig コマンドを使用する必要があります。 |
Solaris システムでは、Load Balancer プロセスを開始した 端末セッション・ウィンドウを終了すると、そのプロセスは終了します。 | nohup コマンドを使用することで、 端末セッションを終了したときに、開始したプロセスがハングアップ・シグナルを受けないようにしてください。 |
Load Balancer 構成の読み込み時には、速度の低下が見られます。 | 遅延は、サーバー・アドレスを解決して検証す るために行われた、ドメイン・ネーム・システム (DNS) 呼び出しが原因である場合があります。 |
Windows システムで、次のエラー・メッセージが 表示される:「ネットワーク上の他のシステムとの IP アドレスの競合があります」 | 高可用性が構成されている場合は、 短時間の間、両方のマシンでクラスター・アドレスが構成されることがあり、この エラー・メッセージが出される原因となります。 |
Windows システムの場合、dscontrol または lbadmin コマンドを発行すると、「サーバーが応答していません」というエラーが発生する | 複数の IP アドレスが Windows システムに存在し、 ホスト・ファイルがホスト名に関連づけられたアドレスを指定しない時です。 |
zSeries® および S/390® プラットフォームでの Dispatcher の MAC 転送構成の制限 | Linux では、オープン・システム・アダプター (OSA) カードを備えた zSeries または S/390 サーバーを使用する際の制限があります。実行可能な次善策が提供されます。 |
Linux システムで、iptables によってパケットのルーティングが干渉される場合がある | LinuxLinux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Load Balancer マシンでは無効にする必要があります。 |
Solaris システムで、Dispatcher マシンに IPv6 サーバーを構成しようとすると、 「サーバーを追加できません」というメッセージが表示される | これは、Solaris オペレーティング・システムによる IPv6 アドレスに対する ping 要求の処理方法が原因である可能性があります。 |
Load Balancer のインストールで提供された Java ファイル・セットのアップグレード | Java ファイル・セットに問題が見つかった場合は、 その問題を IBM® サービスに報告し、Load Balancer インストールとともに 提供された Java ファイル・セットのアップグレードを受け取れるようにする必要があります。 |
HP-UX バックエンド・サーバーへの転送時に、 クライアント要求が失敗する | HP-UX オペレーティング・システム上で Load Balancer for IPv6 をセットアップした後、クラスター・アドレスに対するクライアント要求は失敗します。このエラーは、オペレーティング・システムの隣接者探索機能と Load Balancer の相互作用の結果です。 |
Load Balancer for IPv4 and IPv6 が IP セキュリティー (IPsec) と競合する | IP セキュリティー (IPsec) が使用可能な Load Balancer for IPv4 and IPv6 を使用している場合、出力パケットが正しくないことがあり、Dispatcher 構成情報が WebSphere® Application Server のコマンド行インターフェースおよび管理コンソールで正しく表示されない場合があります。 Load Balancer は、接続を転送していることを報告しますが、クライアントは応答を受信していません。 |
サーバーの状況に影響を与えるコマンドを Load Balancer に対して発行すると、serverUp スクリプトが実行される可能性がある | manager サイクルが既にサーバーの重みを取得した後に、dscontrol manager unquiesce コマンド や dscontrol manager quiesce コマンドなどのサーバーの状況に影響を与える コマンドを実行した場合、問題を検出する可能性があります。これらのコマンドを実行した 場合、manager サイクル時に保存された値が上書きされ、予期せずに serverUp スクリプトが実行される可能性があります。 |
この問題は、他のアプリケーションが Load Balancer によって使用されるポートの いずれかを使用している場合に起こります。詳しくは、『Load Balancer マシンの構成』トピック を参照してください。
netstat
-ni を使用してチェックします。
netstat
-nr を使用してチェックします。
Dispatcher、Microsoft IIS、および SSL の使用時は、これらが連係して動作しない場合は、SSL セキュリティーの有効化に問題がある場合があります。鍵ペアの生成、証明書の取得、鍵ペアを含む証明書のインストール、SSL を必要とするディレクトリーの構成に 関する詳細については、「Microsoft Information and Peer Web Services」資料を参照してください。
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"
LB_ADV_NO_PING="true"
java -DLB_ADV_NO_PING="true"
Windows プラットフォームで、デフォルトのブラウザーとして Netscape を使用している場合、 「ファイル '<filename>.html' (またはそのコンポーネントの 1 つ) が見つかりません」というエラー・メッセージが表示されることがあります。 パスおよびファイル名が正しいか確認し、必要なライブラリーがすべて使用可能 になっているようにしてください。
グラフィカル・ユーザー・インターフェース (GUI) の lbadmin を正しく機能させるには、十分なページング・スペースが必要です。 使用可能なページング・スペースが不十分な場合には、GUI は正しく開始されません。これが起こる場合には、ページング・スペースを調べて、必要があればページング・スペースを増加してください。
Load Balancer GUI の外観に問題が起きる場合は、オペレーティング・システムのデスクトップ解像度の設定を調べてください。GUI の表示には 1024x768 ピクセルの解像度が最適です。
Windows プラットフォームでは、初めてヘルプ・ウィンドウを開いたとき、ヘルプ・ウィンドウが既存のウィンドウの背後に隠れて見えなくなることがあります。 これが起こる場合は、ウィンドウをクリックして、もう一度前面に出してください。
lbadmin または Web 管理 (lbwebaccess) を使用して大規模の構成ファイル (おおよそ 200 個以上の add コマンド) を ロードしようとすると、GUI がハングするか、あるいは予期しない振る舞い (画面変更への応答が極端に低速になるなど) を示す場合があります。
これは、Java にこのように大きな構成を処理するだけの十分なメモリーへのアクセス権がないことが原因で起こります。
Java に使用可能なメモリー割り振りプールを増やすために指定できる、実行時環境についてのオプションがあります。
オプション -Xmxn です。 ここで、n はメモリー割り振りプールの最大サイズ (バイト単位) です。 n は 1024 の倍数になっていなければならず、2MB より大きくなっていなければなりません。 値 n の後に、 キロバイトを示す k または K か、メガバイトを示す m または M を 付けることができます。例えば、-Xmx128M と -Xmx81920k は両方とも有効です。 デフォルト値は 64M です。 Solaris 8 では、最大値は 4000M です。
java -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 倍を指定することです。
-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 プラットフォームで Matrox AGP カードを使用すると、Load Balancer GUI で予期しない振る舞いが発生することがあります。マウスをクリックすると、マウス・ポインターよりわずかに大きいスペースのブロックが壊れて、画面上で強調表示が反転したり、イメージの位置がずれることがあります。 古い Matrox カードではこの振る舞いは発生しませんでした。 Matrox AGP カードを使用する場合の既知のフィックスはありません。
ロード・バランシング用に Dispatcher コンポーネントを実行している場合、クライアント・トラフィックでコンピューターが過負荷になることがあります。 Load Balancer カーネル・モジュールは最も高い優先度を持っており、これが絶え間なくクライアント・パケットを処理している場合、残りのシステムが 応答しなくなる場合があります。 ユーザー・スペースでコマンドを実行すると、完了するまでに非常に時間がかかるか、または完了しない可能性があります。
これが発生した場合、セットアップを再構成して、Load Balancer マシンが トラフィックで過負荷になることを回避する必要があります。 別の方法としては、複数の Load Balancer マシンに負荷を分散する、または Load Balancer マシンをより処理能力が高く、高速なコンピューターに 置き換える、というものがあります。
高クライアント・トラフィックが原因でマシンの応答が遅いのかどうかを判別するとき、この問題がクライアント・ピーク・トラフィック時間に発生するかどうかを検討します。 システムが誤って構成され、これが経路指定ループを招く場合には、同じ症状を引き起こすことがあります。 Load Balancer セットアップを変更する前に、この症状が高クライアント負荷によるものかどうかを 判別してください。
Load Balancer は、ループバックで別名を割り当てられたクラスター・アドレスを使用してパケットをサーバーに送信します。いくつかのサーバー・アプリケーション (SSL など) は、構成情報 (証明書など) が IP アドレスに基づいていることを必要とします。受信パケットのコンテンツと一致するには、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) で参照できます。
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters
Linux カーネル 2.4.x サーバーを使用するときには、若干の考慮事項があります。サーバーに、ip address add コマンドを使用してループバック・デバイスにクラスター・アドレスが構成されている場合、1 つのクラスター・アドレスにしか別名アドレスを割り当てることができません。
ifconfig lo:num clusterAddress netmask 255.255.255.255 up
また、インターフェースを構成する ifconfig メソッドと ip メソッドには、いくつかの非互換性があります。最良実例では、サイトが 1 つのメソッドを選択し、そのメソッドを排他的に使用することが提案されています。
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 アドレスの競合があります」。 この場合は、メッセージを無視しても問題がありません。短時間の間、 両方の高可用性マシンでクラスター・アドレスが同時に構成されることは可能 です (特にいずれかのマシンの始動中や、テークオーバーが開始されたとき)。
この問題を解決するには、c:\Windows\system32\drivers\etc\hosts ファイルを、 ご使用のマシンのホスト名、およびそのホスト名に関連付ける IP アドレスで更新してください。
dscontrol host@@<ip_address or host_name> <command>
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 の内部に向けて転送する際には無効です。
次善策:
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 のカプセル化機能を使用することをお勧めします。これは、Load Balancer に、ルーターを介した転送を許可するプロトコルです。
カプセル化を使用する場合、クライアントからクラスターへの IP パケットは、Load Balancer が受け取り、カプセル化してサーバーに送信します。サーバーでは、元のクライアントからクラスターへの IP パケットがカプセル化され、 サーバーが直接クライアントに応答します。 GRE を使用する利点は、Load Balancer が、サーバーからクライアントへのトラフィックではなく、 クライアントからサーバーへのトラフィックのみを認識することです。 欠点は、カプセル化のオーバーヘッドにより、TCP 接続の最大セグメント・サイズ (MSS) が小さくなることです。
カプセル化を使用して転送を行うように Load Balancer を構成する方法について詳しくは、カプセル化転送を使用したネットワーク・セグメント間のトラフィックの転送のトピックを参照してください。
Linux iptables は、トラフィックのロード・バランシングを干渉する可能性があるため、 Dispatcher マシンでは無効にする必要があります。
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
Solaris システムで、Websphere Load Balancer for IPv4 and IPv6 インストール済み環境で IPv6 サーバーを構成しようと試みると、「サーバーを追加できません」というメッセージが表示されることがあります。 これは、Solaris オペレーティング・システムによる IPv6 アドレスに対する ping 要求の処理方法が原因である可能性があります。
Solaris システムで構成にサーバーを追加する際、Load Balancer はサーバーの MAC アドレスを取得するためにサーバーへの ping を試みます。 Solaris マシンは、マシンの NFA アドレスを使用する代わりに、 構成されたクラスター・アドレスを ping 要求のソース・アドレスとして選択する場合があります。 クラスター・アドレスがサーバーのループバックに構成されている場合、 ping 応答は Load Balancer マシンでは受信されません。 このため、サーバーは構成に追加されません。
解決策は、Load Balancer マシンに別の IPv6 アドレスを構成することです。 これは、IPv6 クラスター・アドレスを構成する前か後に行います。 このアドレスは、Load Balancer 構成の追加先であるバックエンド・サーバーのループバックで別名割り当てされていないアドレスでなければなりません。 その後で、サーバーを Load Balancer 構成に追加します。
Load Balancer のインストール・プロセスでは、Java ファイル・セットもインストールされます。Load Balancer は、製品とともにインストールされる Java バージョンを使用する唯一のアプリケーションです。このバージョンの Java ファイル・セットは、独自にアップグレードしないでください。Java ファイル・セットのアップグレードを必要とするような問題がある場合は、 IBM サービスに連絡した上で、Load Balancer に同梱の Java ファイル・セットを正式な修正レベルでアップグレードしてください。
HP-UX オペレーティング・システム上で Load Balancer for IPv6 をセットアップした後、クラスター・アドレスに対するクライアント要求は失敗します。このエラーは、オペレーティング・システムの隣接者探索機能と Load Balancer の相互作用の結果です。
バックエンド・サーバーが構成に追加されると、MAC アドレスを取得するために Load Balancer が新規サーバーへの ping を試みます。HP-UX サーバーは、マシンの非転送先アドレス (NFA) を使用する代わりに、 構成されたクラスター・アドレスを ping 要求のソース・アドレスとして選択する場合があります。 この場合、ローカル・ループバック・エントリーに加えて、バックエンド HP-UX サーバーの ルーティング・テーブルにクラスター・アドレス用の新規エントリーが作成されます。 新規エントリーのルーティングの優先度は、 ローカル・ループバックよりも高くなります。 そのため、バックエンド・サーバーに到達したクライアント要求は Load Balancer サーバーに リダイレクトされますが、Load Balancer サーバーは応答しません。
この問題を回避するには、Load Balancer が完全にセットアップされた後、最終ステップとしてバックエンド・サーバーでループバック別名を構成します。Load Balancer 構成がロードされる ときに、クラスター・アドレスにループバックで別名が割り当てられた場合には、バックエンド・サーバーのクラスター・ループバック別名を完全に除去し、再び別名割り当てをします。 ループバック別名を除去するには、端末ウィンドウから ifconfig lo0:1 inet6 コマンドを入力します。それからループバック別名を再割り当てします。
IP セキュリティー (IPsec) が使用可能な状態の Load Balancer を使用している場合、出力パケットが正しくないことがあり、また Dispatcher 構成情報が WebSphere Application Server のコマンド行インターフェースおよび管理コンソールで正しく表示されないことがあります。Load Balancer は、接続を転送していることを報告しますが、クライアントは応答を受信していません。
同じホスト上で Load Balancer 機能と IP セキュリティーを使用している場合、Load Balancer とアプリケーション・サーバー間に通信の問題が発生する場合があります。Load Balancer コンポーネントは IPsec 機能と完全に互換性があるわけではなく、セキュリティー層の両側からデータを伝送します。Load Balancer が IPsec より下位でパケットを受信すると、 結果として暗号化解除されない暗号化パケットを受信することになります。データ送信時に、Load Balancer が IPsec より上位で パケットを伝送すると、暗号化されていないパケットをアプリケーション・サーバーに送信しますが、 これらのパケットは IPsec によってもう一方の終端で暗号化されることになります。したがって、 アプリケーション・サーバーは使用できない暗号化データを受信します。
dscontrol manager quiesce server
dscontrol manager unquiesce server
manager によって重みが取得された後に unquiesce コマンドが発行されると、executor 機能によって、サーバー状態が変更されたかどうか判定するために使用される重みが上書きされます。サーバーも静止しない限り、このプロセスによる副次作用は起こりません。構成が大きくなるにしたがって manager サイクルの実行時間が長くなるため、この問題を検出する機会が増えます。また、unquiesce コマンドが発行されたとき に、manager サイクルが進行中である可能性がより高くなります。