複製では、データを生成するのは 1 度で、生成したデータをクラスター内の他のサーバーにコピー、
つまり複製するので、時間とリソースを節約することができます。
クラスターでのキャッシングには、これ以外にも懸案事項があります。
特に、同一データが要求される場合があり、
同一のデータが複数の場所に生成されることがあります。
また、キャッシュ・データを生成するリソースに必要な許可が制限されて、
データへのアクセスが妨げられることもあります。
キャッシュを複製すれば、データの生成は 1 度で済み、
クラスター内の他のサーバーにそれをコピーすることにより、こうした問題に対処することができます。
また、キャッシュの整合性も保つことができます。不要なキャッシュ・エントリーは、除去または置き換えられます。
データ複製の構成は、
管理コンソールから利用できる Web コンテナーの動的キャッシュ構成の一部として行うか、
または cachespec.xml ファイルを介してキャッシュ・エントリーごとに行うことができます。
cachespec.xml ファイルを使用して、
キャッシュの複製を、Web コンテナー・レベルで構成することも、
特定のキャッシュ・エントリーに対して使用不可にすることもできます。
キャッシュ複製は、複数のサーバントが使用可能になっている基本サーバー上、
あるいはクラスター環境にあるサーバー上で、構成することができます。
クラスター環境でキャッシュ複製を使用可能にすると、
クラスター内の 1 つのサーバーだけがアクティブになっている場合でも、
すべてのサーバント間で複製が行われます。
キャッシュの複製には、以下の 3 つの形式があります。
- PUSH - このオブジェクトに対するキャッシュ・エントリーは、ピア分散サーバーの動的キャッシュに自動的に配布されます。各キャッシュにおいて、エントリーが作成された時点でそのコピーが作成されます。
これらのエントリーには、シリアライズ不可データを保管できません。
- PULL - データがローカルに存在しない場合に、クラスター内の他のサーバーからのデータを要求する。
この複製モードはお勧めしません。
- PUSH/PULL - このオブジェクトに対するキャッシュ・エントリーは、
必要に応じて、複数のアプリケーション・サーバー間で共用されます。アプリケーション・サーバーは、キャッシュ・エントリーを生成すると、
作成したエントリーのキャッシュ ID をすべての連携アプリケーション・サーバーにブロードキャストします。
これにより個々のサーバーは、特定のキャッシュ ID に対するエントリーが存在しているかどうかを認識します。
このようにしてアプリケーション・サーバーは、このエントリーに対する特定の要求に対して、
エントリーを生成するか、どこかほかの場所から取得するかを判別します。
これらのエントリーには、シリアライズ不可データを保管できません。注: DistributedMap.containsKey() メソッドおよび DistributedMap.keySet() メソッドは受信サーバーでブロードキャストされていた鍵を表示しません。
これは、データ構造 (DRSPushPullTable テーブル) に保管されている鍵がローカル・キャッシュ
(DistributedMap) で使用されているバッキング (補助ストレージへの保管) マップとは異なるためです。
しかし、DistributedMap.get(Object key) メソッドは、この鍵をブロードキャストしたサーバーから値を取得します。
動的キャッシュ・サービスはキャッシュ複製の更新を、作成されるとすぐに送信するのではなく、構成可能なもの
(動的キャッシュ・サービスの管理コンソール・パネルでの更新間隔のバッチ) に基づいて非同期でブロードキャストします。失効は即時に送信されます。失効の配布は、失効したデータがクラスター内に常駐することを防止します。
キャッシュ複製の構成について詳しくは、
キャッシュ複製の構成
および動的キャッシュ・サービスの設定
を参照してください。
重要: PUSH/PULL モードでは、
キャッシュ・オブジェクトは、それを作成したサーバーにローカルで保持されますが、
他のサーバーもキャッシュ ID を使用して、
そのオブジェクトを DRSPushPullTable テーブルに保管します。
リモート・サーバーは、オブジェクトを必要とする場合には、
キャッシュ ID、または名前によって、
そのオブジェクトを作成するサーバーから要求します。
各キャッシュ・インスタンスには、
そのインスタンスに関連付けられた DRSPushPullTable テーブルが 1 つあります。
以下のような条件では、DRSPushPullTable テーブルが極端に大きくなります。
- 他のサーバーで共用されるエントリー数が非常に多い。
- 期限切れになっているエントリーが少ない。
- ディスク・オフロード・フィーチャーを使用しているのに、
期限切れのエントリーを除去するディスク・スキャンが
頻繁に実行されていない。
問題を解決するには、以下の作業を行うことをお勧めします。
- 可能であれば、ヒープ・サイズを 1.5 GB または 2 GB に増やす。
- エントリーの有効期限の時間について、より適切な分散を保つようにする。
例えば、以下のようにします。
- エントリーの 20% は、有効期限を定めない。
- エントリーの 30% は、3600 秒で有効期限が切れるようにする。
- エントリーの 30% は、600 秒で有効期限が切れるようにする。
- エントリーの 20% は、60 秒で有効期限が切れるようにする。
WebSphere® Application Server バージョン 6.0.2 または
それ以前のバージョンで、
ディスク・オフロード・フィーチャーを使用する場合は、
ディスク・クリーンアップの頻度を最適な値に調整します。
例えば、エントリーの 約 20% を、その時点で有効期限が切れるようにします。