| Oracle® Coherenceスタート・ガイド リリース3.6 B61369-01 |
|
 戻る |
 次へ |
レプリケーション・キャッシュ・サービスに潜在的に存在するスケーラビリティの制約に対応するために、メモリーと通信の両方のボトルネックに対して、Coherenceではリリース1.2以降、分散キャッシュ・サービスを提供しています。分散キャッシュという用語は、多くの製品でその機能を説明するために使用されてきました。そこで、ここでも、Coherenceにおけるこの用語の正確な意味について説明します。Coherenceにおける分散キャッシュは、任意の数のクラスタ・ノード間で分散（パーティション化）されたデータのコレクションとして定義されます。ここでいう分散とは、キャッシュ内の個々のデータがクラスタ内の1つのノードによってのみ保持されるよう、すべてのクラスタ・ノード間でその役割を分担する（ロード・バランシングする）ことを意味します。
分散キャッシュには、いくつかの重要な留意事項があります。
パーティション化: 分散キャッシュ内のデータは、同じデータが2つのサーバーで保持されることがないようにすべてのサーバーに分配されます。これは、キャッシュのサイズ、およびキャッシュの管理に関連する処理能力が、クラスタのサイズとともに線形に拡大することを意味します。また、キャッシュ内のデータに対する操作を単一ホップ（他のサーバーを多くても1つしか必要としない）で実行できることになります。
ロード・バランシング: データがサーバー間に均等に分配されるため、データを管理する役割はクラスタ全体を通して自動的にロード・バランシングされます。
位置の透過性: データはクラスタ・ノード全体に分配されますが、データのアクセスにはまったく同じAPIが使用され、各APIメソッドからも同じ動作が実行されます。これを位置の透過性と呼びます。ローカルのJCache、レプリケートされたキャッシュ、または分散キャッシュではAPIおよびAPIの動作が同じになるため、開発者はキャッシュのトポロジに基づいてコードを記述する必要がありません。
フェイルオーバー: Coherenceのすべてのサービスは、データ損失のないフェイルオーバーおよびフェイルバックを実行しますが、分散キャッシュ・サービスも例外ではありません。分散キャッシュ・サービスではバックアップの回数を設定できます。バックアップ回数を1以上に設定すれば、いずれかのクラスタ・ノードに障害が発生しても、データを失うことはありません。
分散キャッシュにアクセスするには、一般に、ネットワークを介して別のクラスタ・ノードに接続する必要があります。他の条件がすべて同じであるとして、n個のクラスタ・ノードがある場合は、(n-1)/nの操作がネットワークを経由することになります。
各データは1つのクラスタ・ノードのみで管理されるため、ネットワーク経由のアクセスは単一ホップ操作になります。このタイプのアクセスは、Point-to-Point通信を使用できるためスイッチド・ネットワークを最大限に活用できます。そのため、スケーラビリティに非常に優れています。
同様に、キャッシュの更新操作にも同じ単一ホップのPoint-to-Point方式を使用できます。この方法を使用すると、レプリケーション・キャッシュの2つの制限のうち、すべてのクラスタ・ノードにキャッシュの更新をプッシュする必要があるという制限に対応できます。
上の図では、データはプライマリ・クラスタ・ノードとバックアップ・クラスタ・ノードに送信されています。これはフェイルオーバーを目的としたものであり、この場合のバックアップ回数は1になります（デフォルトのバックアップ回数は1に設定されています）。キャッシュのデータがクリティカルでない（ディスクから再ロードできる）場合は、バックアップ回数をゼロに設定できますが、クラスタ・ノードに障害が発生したときに分散キャッシュ・データの一部が失われる可能性があります。キャッシュがきわめてクリティカルな場合は、バックアップ回数を2などの高い値に設定します。バックアップ回数は、キャッシュ・エントリの追加、変更、削除などによるキャッシュの変更パフォーマンスにのみ影響します。
キャッシュに対する変更は、すべてのバックアップが変更を受信したことを認識するまで完了したとは見なされません。したがって、分散キャッシュのバックアップを使用する場合は、キャッシュの変更パフォーマンスが若干低下します。しかし、クラスタ・ノードに予期しない障害が発生しても、データの整合性が維持されることが保証され、データが損失することはありません。
分散キャッシュのフェイルオーバーでは、バックアップ・データがプライマリ記憶域に昇格されます。あるクラスタ・ノードに障害が発生すると、残りのすべてのクラスタ・ノードは、障害が発生したクラスタ・ノードがプライマリ記憶域で停止時に管理していたデータを各自のバックアップ記憶域から判別します。これらのデータの管理は、それをバックアップ記憶域に保持していたクラスタ・ノードに引き継がれます。
バックアップに複数のレベルがある場合は、最初のバックアップでデータがバックアップされ、2番目以降のバックアップでは前のバックアップがバックアップされるようになります。レプリケーション・キャッシュ・サービスとまったく同じように、サーバーの障害時にはロック情報も維持されます。ただし、唯一の例外として、障害が発生したクラスタ・ノードのロックは自動的に解除されます。
分散キャッシュ・サービスでは、データを格納するクラスタ・ノードと格納しないクラスタ・ノードを構成できます。これにはlocal storage enabledという設定を使用します。local storage enabledオプションを有効にして構成されたクラスタ・ノードが、分散キャッシュのキャッシュ記憶域とバックアップ記憶域を提供します。この設定にかかわらず、データはすべてのクラスタ・ノードでまったく同じように表示できます。これは位置の透過性によるものです。
local storage enabledオプションには、次のような利点があります。
クラスタ・ノードのlocal storage enabledを無効にすると、データが他のクラスタ・ノードにキャッシュされるため、このノードのJavaヒープ・サイズはキャッシュ内のデータ量に影響されません。この機能は、大きなJavaヒープを持つ古いバージョンのJVMでアプリケーション・サーバー・プロセスを実行している場合に特に有用です。これらのプロセスは、ヒープ・サイズとともに急激に増加するガベージ・コレクションの一時停止に妨げられることが多いためです。
Coherenceでは、クラスタ・ノードごとに、サポートされている任意のJVMバージョンを実行できます。したがって、local storage enabledを有効にしたクラスタ・ノードでは、大きなヒープ・サイズ、またはJava NIOの機能を使用するCoherenceのヒープ外記憶域をサポートする、新しいJVMバージョンを実行できます。
local storage enabledオプションを使用すると、一部のクラスタ・ノードをキャッシュ・データの格納目的にのみ使用できます。このようなクラスタ・ノードをCoherenceキャッシュ・サーバーと呼びます。キャッシュ・サーバーは、主にCoherenceの分散問合せ機能の拡張に使用されます。
