こんにちは私は2つのweblogicアプリケーションサーバーにデプロイされているアプリケーションを持っていますクラスタリングまたはロードバランシングによる問題のトラブルシューティング方法を教えてください。
最近では、返されるユーザーセッションがnullであるという問題があります。開発者からのフィードバックは、セッションによって他のサーバーに複製されない可能性があることです。
これが実際のケースであることをどのように証明しますか？
両方のアプリケーションサーバーが何らかの通信プロトコルでアクセスできる単一のセッションストアを使用していますか？もしそうでなければ、間違いなくそうです。あなたのweblogicサーバがセッションをどこにでもメモリに保存していて、ユーザがセッションIDをクッキーで渡した場合、他のサーバは他のマシンのメモリにアクセスできません。スティッキーロードバランシングを使用している場合を除きます。あなたですか？
ここでは、セッションスティッキーとセッションレプリケーションの2つの概念について検討します。
セッションスティッキ性は、セッションAを持つユーザからの要求がサーバ1に送られた場合、セッションAを持つユーザからの次の要求がサーバ1だけに送られることを保証するメカニズムです。
これは、セッションスティッキーを提供できるハードウェアロードバランサ（F5など）を構成することによって実現されます。 apache/iis/weblogicにインストールされているweblogicプロキシを設定する。
要求がWLS管理対象サーバーに初めて届くと、セッションIDで応答し、サーバーのJVM ID（これはプライマリID）を追加します。管理対象サーバーがクラスタの一部である場合は、
プロキシはすべてのJVM IDとそれに対応する管理対象サーバのIPのテーブルを保持し、サーバが稼動しているかどうかを定期的にチェックします。実行中かどうか。
次回、別のリクエストが既存のセッションIDとプライマリjvm IDを持つプロキシを渡すと、プロキシはこれを解析し、セカンダリサーバーに送信しようとしていない時間があればそのサーバーにリクエストを送信しようとします。 。
セッションレプリケーション - これは、管理対象サーバが2台以上あるWLSクラスタを設定すると、デフォルトで有効になります。すべてのデータがセッションに更新されるたびに、そのデータはセカンダリサーバでも複製されます。
アプリケーションのユーザーがセッションを失っているか、通常の使用の間にログインページにリダイレクトされた場合は、タイムアウトのためにセッションが無効にならないことを確認します。プライマリおよびセカンダリサーバがセッションIDに追加されていることを確認するために、プロキシのデバッグ出力を確認してください。
最後に、セッションレプリケーションとフェールオーバー機能をテストするために使用できるwlsのサンプルアプリケーションデプロイメントの簡単な例があります。セッションは、 1を迷子にされている理由だから、証明するために
）、セッションがタイムアウトのため無効しまったかどうかを確認するために、サーバーログを確認 2）wlproxyを使用している場合、デバッグを有効にし、問題がプロキシにチェックを起こる次回リクエストが別のサーバーに送信された場合、およびそのサーバーがセカンダリサーバーでない場合は、ログに記録されます。
ロードバランスがセッションスティッキーであるかどうかを確認するにはどうすればよいですか？ – Ggf
ソフトウェアまたはハードウェアベースのロードバランサを使用していますか？誰がそれを設定した？彼らはそれが粘着性であるかどうかを知っているか、粘着性ではありません。 –
速くて汚い言い方は、サーバーがすべての要求に、そのマシン名を持つヘッダーで応答するようにすることです。その後、httpプロキシを介して60件のリクエストを発行し、それらのヘッダーを調べます。常に同じマシンであれば、ロード・バランシングは粘着性があります。マシンが変更された場合、それはありません。 –