アプリケーションを単一の Websphere Application Server から Websphere クラスターに移動する前に注意すべきこと
3 に答える
これは私の経験からのリストです。完全ではありませんが、最も一般的な問題領域をカバーする必要があります。
- 分散セッション管理の構成を計画します (つまり、メモリ間またはデータベース ベースのレプリケーションを使用しますか)。まだ 32 ビット プラットフォームを使用している場合、アプリケーションが既に大量のメモリを使用している場合、クラスタリングによるリソース要件のオーバーヘッドによって不安定性の問題が発生する可能性があることに注意してください。
- ユーザーセッションに入れるものはすべて、デフォルトのシリアライザーでシリアライズできることを確認してください (Serializable を実装します)。そうしないと、分散セッションで問題が発生する可能性があります。
- DynaCache に入れるすべてのものについても同じことが言えます。すべてが正しくシリアル化されていることを確認してください。
- すべてのリソース定義 (JDBC プロバイダーなど) が適切なスコープになるように指定して確認します。通常、クラスターにインストールされたアプリケーションが使用するすべてのものに対して、実際のクラスター スコープを使用することをお勧めします。これにより、テスト機能が適切なポイントから適切に機能し、矛盾する定義を作成しないことが保証されます。
- アプリケーションが Web インターフェースのリソースに相対パスを使用していることを確認してください。ロードバランシングなどを開始すると、多くのものをボルトで固定している場合、深刻な問題が発生する可能性があります。
- 何らかの種類のタイマーがある場合は、それらがクラスターでうまく機能することを確認してください。Quartz では、おそらくタイマー タスクに JDBC ストアを使用する必要があることを意味します。EJB タイマーでは、タイマーを 1 回だけ登録し (複数のノードが同時に登録しようとすると、WAS のタイマー データベースが破損する可能性があります)、それらをクラスター スコープにインストールするようにしてください。
- WAS が提供する SSO メカニズムを使用していることを確認してください。カスタム実装を使用している場合は、クラスター内のサーバー間でユーザーを適切に移動できることを確認してください。
要件に応じて、HTTP セッションで状態を保持せずにスティッキー セッションを使用するようにロード バランサーを構成してみてください。そうすれば、メモリ セッション レプリケーションで大量のリソースを使用する必要がなくなります。
シングル サインオンは、HTTP クライアントが同じhttp://server.acme.com/ ... ホスト ドメイン名から移動しないため、単一のクラスターでは問題になりません。
ほとんどのテストでは、データベースの競合に焦点を当てる必要があります。高度なトランザクション アプリケーション (つまり、同じテーブルへの多数の書き込み) を使用している場合は、ロックが不必要に保持されないように、データベースの分離レベルを確認してください。トランザクション demarkaction についても同様です。取引はできるだけ簡潔にしましょう。自分でデータベースのスキルを持っていない場合は、テスト中にデータベースを監視するのに役立つデータベース アナリストを取得してください。
また、今回の変更や新しいバージョンへのアップグレードなどの主要な変更の前に、PMR を IBM サポートに提出することをお勧めします。「ソフトウェア使用に関する質問」として提出すると、知識データベースに基づくフィードバックを提供できます。他の顧客の入力について。サポート契約を結んでいるどのタイプの製品にも同じことが当てはまります。問題が発生する前にサポートに問い合わせてください。