優先ゾーン・ルーティングを使用して、WebSphere® eXtreme Scale がトランザクションをゾーンに送信する方法を定義できます。
データ・グリッドの断片が配置される場所を制御します。 いくつかの基本的なシナリオ、および、それに合わせたデプロイメント・ポリシーの構成方法について詳しくは、レプリカ配置のためのゾーンの構成を参照してください。
優先ゾーン・ルーティングは、特定のゾーンあるいはゾーンのセットを優先する機能を WebSphere eXtreme Scale クライアントに付与します。 結果として、クライアント・トランザクションを優先ゾーンに送付してから、他のゾーンにも送信することを試みます。
優先ゾーン・ルーティングを試みる前に、アプリケーションがシナリオの要件を満たすことができることを確認してください。
優先ゾーン・ルーティングを使用するには、コンテナーごとの区画の配置が必要です。 この配置ストラテジーはセッション・データを ObjectGrid に保管しようとしているアプリケーションには最適です。 WebSphere eXtreme Scale におけるデフォルトの区画配置ストラテジーは、fixed-partition です。トランザクションのコミット時にキーがハッシュされて、固定区画配置を使用する際に、マップのキー値ペアがどの区画に納められるかが決まります。
コンテナーごとの配置により、データはトランザクション・コミット時に SessionHandle オブジェクトを介してランダムに区画に割り当てられます。 データ・グリッドからデータを取得するには、この SessionHandle オブジェクトを再構成できなければなりません。
ゾーンを使用すると、プライマリー断片とレプリカ断片がドメインに配置される場所に対する制御を強化できます。 デプロイメントで複数ゾーンを使用すると、データが複数の物理ロケーションに存在する場合に有利です。地理的にプライマリーとレプリカを分離させることは、1 つのデータ・センターの壊滅的な損失でも、データの可用性に影響を与えないようにする 1 つの方法です。
データが複数ゾーンに散在される場合、クライアントもそのトポロジーに散在されると考えられます。 クライアントをそれぞれのローカル・ゾーンあるいはデータ・センターにルーティングすることには、ネットワーク待ち時間の削減という明確なパフォーマンス上の利点があります。クライアントをローカル・ゾーン、または、可能であればデータ・センターにルーティングしてください。
次のシナリオを考えてみます。 データ・センターが 2 つ、Chicago と London にあります。 クライアントの応答時間を最小にするために、クライアントはローカル・データ・センターに対してデータの読み取りと書き込みを行うようにします。
トランザクションが各ロケーションでローカルに書き込みが行われるためには、プライマリー断片は各データ・センターに配置される必要があります。 クライアントは、ローカル・ゾーンへ経路指定するためにゾーンについて把握している必要があります。
コンテナーごとの配置により、新しいプライマリー断片は、開始された各コンテナーに配置されます。レプリカは、デプロイメント・ポリシーにより指定されたゾーンと配置のルールに従って配置されます。デフォルトで、レプリカは、プライマリー断片とは異なるゾーンに配置されます。 このシナリオでは、以下のデプロイメント・ポリシーを考えてみます。
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="universe">
<mapSet name="mapSet1" placementStrategy="PER_CONTAINER"
numberOfPartitions="3" maxAsyncReplicas="1">
<map ref="planet" />
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
デプロイメント・ポリシーを使用して開始される各コンテナーで、3 つの新規プライマリーを受け取ります。 各プライマリーには、非同期レプリカが 1 つ作成されます。 各コンテナーを適切なゾーン名で開始します。 コンテナーを startOgServer スクリプトを使用して開始する場合、-zone パラメーターを使用します。
Chicago のコンテナー・サーバーの場合、以下のようにします。
startOgServer.sh s1 -objectGridFile ../xml/universeGrid.xml
-deploymentPolicyFile ../xml/universeDp.xml
-catalogServiceEndPoints MyServer1.company.com:2809
-zone Chicago
startOgServer.bat s1 -objectGridFile ../xml/universeGrid.xml
-deploymentPolicyFile ../xml/universeDp.xml
-catalogServiceEndPoints MyServer1.company.com:2809
-zone Chicago
ご使用のコンテナーが WebSphere Application Server で実行されている場合、ノード・グループを作成して それに「ReplicationZone」という接頭部を付けた名前を指定します。 これらのノード・グループのノード上で実行中のサーバーは、適切なゾーンに配置されます。例えば、Chicago ノードで実行中のサーバーは、ReplicationZoneChicago という名前のノード・グループに含まれる可能性があります。
詳しくは、レプリカ配置のためのゾーンの構成を参照してください。
Chicago ゾーンにプライマリー断片があるものについては、そのレプリカが London ゾーンにあります。 London ゾーンにプライマリー断片があるものについては、そのレプリカが Chicago ゾーンにあります。
クライアントの優先ゾーンを設定します。クライアント・プロパティー・ファイルをクライアント Java 仮想マシン (JVM) に提供します。objectGridClient.properties という名前のファイルを作成し、このファイルが確実にクラスパスに入るようにします。
このファイルに preferZones プロパティーを組み込みます。このプロパティー値を適切なゾーンに設定します。 Chicago のクライアントは、objectGridClient.properties ファイルに以下の値を持っている必要があります。
preferZones=Chicago
London のクライアントのプロパティー・ファイルには、以下の値が含まれていなければなりません。
preferZones=London
このプロパティーにより、各クライアントがトランザクションを可能な限りそのローカル・ゾーンに経路指定するように指示します。 トポロジーは、ローカル・ゾーンのプライマリー断片に挿入されるデータを非同期で外部のゾーンに複製します。
コンテナーごとの配置ストラテジーでは、データ・グリッド内のキー値ペアのロケーションを決定する場合にハッシュ・ベースのアルゴリズムを使用しません。 この配置ストラテジーの使用時は、トランザクションが正しいロケーションに確実に経路指定されるように SessionHandle オブジェクトを使用する必要があります。 トランザクションがコミットされると、SessionHandle オブジェクトがセッションにバインドされます (まだ設定されていない場合)。 また、トランザクションをコミットする前に Session.getSessionHandle メソッドを呼び出すことによって SessionHandle オブジェクトをセッションにバインドすることができます。 以下のコード・スニペットは、トランザクションのコミット前に SessionHandle がバインドされる場合を示しています。
Session ogSession = objectGrid.getSession();
// binding the SessionHandle
SessionHandle sessionHandle = ogSession.getSessionHandle();
ogSession.begin();
ObjectMap map = ogSession.getMap("planet");
map.insert("planet1", "mercury");
// tran is routed to partition specified by SessionHandle
ogSession.commit();
前のコードは、Chicago データ・センターのクライアントで実行されていたと想定してください。 このクライアントの preferZones 属性は、Chicago に設定されています。結果として、このデプロイメントは、Chicago ゾーンのプライマリー区画 0、1、2、6、7、または 8 のいずれかにトランザクションを経路指定します。
SessionHandle オブジェクトは、このコミット済みデータを保管している区画に戻るパスを提供します。 コミット済みデータを含む区画に戻るには、SessionHandle オブジェクトを再使用または再構成して、Session に対して設定する必要があります。
ogSession.setSessionHandle(sessionHandle);
ogSession.begin();
// value returned will be "mercury"
String value = map.get("planet1");
ogSession.commit();
このコードのトランザクションは、挿入トランザクション中に作成された SessionHandle オブジェクトを再使用します。次に、get トランザクションにより、挿入されたデータを保持する区画に経路指定されます。SessionHandle オブジェクトがないと、トランザクションは挿入されたデータを取得できません。
一般に、preferZones プロパティーが設定されているクライアントでは、すべてのトランザクションを指定されたゾーン (複数可) に経路指定します。 ただし、コンテナーの損失があると、レプリカ断片がプライマリー断片にプロモートします。 ローカル・ゾーンの区画に既に経路指定されていたクライアントは、以前に挿入されたデータをリモート・ゾーンから取得する必要があります。
次のシナリオを考えてみます。 Chicago ゾーンの 1 コンテナーが損失したとします。 このコンテナーには区画 0、1、および 2 のプライマリーが既に格納されています。 London ゾーンでこれらの区画のレプリカをホストしたため、これらの区画の新しいプライマリー断片は London ゾーンに配置されます。
フェイルオーバーになった区画のいずれかを指す SessionHandle オブジェクトを使用している Chicago のクライアントは、今度は London に 経路指定します。 新規 SessionHandle オブジェクトを使用している Chicago のクライアントは、Chicago ベースのプライマリーに経路指定します。
同様に、Chicago ゾーン全体が損失した場合、London ゾーンのすべてのレプリカがプライマリーにプロモートされます。 このシナリオでは、すべての Chicago クライアントがそのトランザクションを London に経路指定します。