配置と区画

WebSphere® eXtreme Scale には、固定区画とコンテナーごとの、2 つの配置ストラテジーがあります。 配置ストラテジーの選択は、デプロイメント構成が区画をどのようにリモート・データ・グリッド内に配置するかに影響します。

固定区画配置

配置ストラテジーはデプロイメント・ポリシー XML ファイルで設定することができます。 デフォルトの配置ストラテジーは固定区画配置で、これは FIXED_PARTITION 設定で使用可能になります。 使用可能なコンテナーに配置されるプライマリー断片の数と numberOfPartitions 属性で構成した区画の数が等しくなります。 レプリカを構成した場合は、配置される断片の最小合計数は次の式によって定義されます。((1 プライマリー断片 + 同期断片の最小数) * 定義されている区画の数)。 配置される断片の最大合計数は次の式によって定義されます。 ((1 プライマリー断片 + 同期断片の最大数 + 非同期断片の最大数) * 区画数)WebSphere eXtreme Scale のデプロイメントにより、これらの断片は使用可能なコンテナーに拡散されます。 各マップのキーは、定義した合計区画数に基づいて、割り当てられた区画にハッシュされます。 フェイルオーバーやサーバー変更のために区画が移動された場合でも、これらのキーは同じ区画にハッシュされます。

例えば、numberPartitions 値が 6 で、MapSet1 の minSync 値が 1 である場合は、6 個の区画のそれぞれが同期レプリカを必要とするため、そのマップ・セットの合計断片数は 12 となります。 コンテナーが 3 つ開始されると、WebSphere eXtreme Scale は MapSet1 用にコンテナーごとに 4 個の断片を配置します。

コンテナーごとの配置

代替配置ストラテジーはコンテナーごとの配置です。これは、デプロイメント XML ファイルのマップ・セット・エレメントにある placementStrategy 属性に対する PER_CONTAINER 設定で使用可能になります。 このストラテジーでは、各新規コンテナーに配置されたプライマリー断片の数と構成した区画の数 (P) が等しくなります。 WebSphere eXtreme Scale デプロイメント環境では、残っているコンテナーごとに各区画の P 個のレプリカが配置されます。 コンテナーごとの配置を使用していると、numInitialContainers 設定は無視されます。 区画はコンテナーの増大につれて大きくなります。 このストラテジーでは、マップのキーは特定の区画に固定されません。 クライアントはある区画に経路指定して、ランダム・プライマリーを使用します。 再度キーの検出に使用される同じセッションに再接続したいクライアントがあると、そのクライアントはセッション・ハンドルを使用しなければなりません。

詳しくは、ルーティング用の SessionHandleを参照してください。

フェイルオーバーまたはサーバーが停止された場合、WebSphere eXtreme Scale 環境はプライマリー断片を (まだそこにデータが入っていれば) コンテナーごとの配置ストラテジーに従って移動します。 空の断片は廃棄されます。 コンテナーごとのストラテジーでは、すべてのコンテナーについて新しいプライマリー断片が配置されるため、古いプライマリー断片は保存されません。

WebSphere eXtreme Scale では、「標準的」配置ストラテジーと称される、区画の 1 つにマップのキーをハッシュする固定区画を使用した方法の代替として、コンテナーごとの配置が可能です。 コンテナーごとの場合 (PER_CONTAINER で設定)、デプロイメントは区画を一連のオンライン・コンテナー・サーバーに配置し、コンテナーがサーバー・データ・グリッドに追加またはサーバー・データ・グリッドから削除されるのに合わせて、自動的にスケールアウトまたはスケールインします。 固定区画を使用した方法のデータ・グリッドは、キー・ベースのグリッドに使用すると効果があり、アプリケーションはキー・オブジェクトを使用してグリッドのデータを検索します。 次に、代替方法について説明します。

コンテナーごとのデータ・グリッドの例

PER_CONTAINER データ・グリッドはさまざまです。 デプロイメント XML ファイルの placementStrategy 属性で、データ・グリッドが PER_CONTAINER 配置ストラテジーを使用するように指定します。 データ・グリッド内の区画が合計でいくつ必要なのかを構成する代わりに、開始するコンテナーごとに区画がいくつ必要なのかを指定します。

例えば、コンテナーごとに 5 つの区画を設定する場合、そのコンテナー・サーバーを始動すると、5 つの新しい匿名プライマリー区画が作成され、必要なレプリカはデプロイ済みの他のコンテナー・サーバー上に作成されます。

以下は、データ・グリッドが拡張していくに従い、コンテナーごとの環境で可能性のあるシーケンスです。

  1. 5 つのプライマリー (P0 から P4) をホスティングしているコンテナー C0 を開始します。
    • C0 ホスト: P0、P1、P2、P3、P4。
  2. さらに 5 つのプライマリー (P5 から P9) をホスティングしているコンテナー C1 を開始します。 コンテナー上でレプリカのバランスが取られます。
    • C0 ホスト: P0、P1、P2、P3、P4、R5、R6、R7、R8、R9。
    • C1 ホスト: P5、P6、P7、P8、P9、R0、R1、R2、R3、R4。
  3. さらに 5 つのプライマリー (P10 から P14) をホスティングしているコンテナー C2 を開始します。 さらにレプリカのバランスが取られます。
    • C0 ホスト: P0、P1、P2、P3、P4、R7、R8、R9、R10、R11、R12。
    • C1 ホスト: P5、P6、P7、P8、P9、R2、R3、R4、R13、R14。
    • C2 ホスト: P10、P11、P12、P13、P14、R5、R6、R0、R1。

さらに多くのコンテナーが開始される間このパターンが続き、5 つの新しいプライマリー区画が毎回作成されて、データ・グリッド内の使用可能なコンテナー上で再度レプリカのバランスが取られます。

注: WebSphere eXtreme Scale は PER_CONTAINER ストラテジーを使用する場合、プライマリーは移動せず、レプリカのみを移動します。

区画番号は任意でキーと無関係なため、キー・ベースのルーティングは使用できないことに注意してください。 コンテナーが停止するとそのコンテナー用に作成された区画 ID は使用されなくなるので、区画 ID の間に抜けができます。 例では、コンテナー C2 に障害が起こると区画 P5 から P9 がなくなり、P0 から P4 と P10 から P14 のみが残るため、キー・ベースのハッシュは不可能です。

コンテナーの障害の影響を考慮すれば、5 あるいはさらに適当な 10 などの数字をコンテナーごとの区画数に使用するのが最も適切に機能します。 データ・グリッド中に断片を均等にホスティングするという負荷を分散するには、各コンテナーに対して複数の区画が必要です。 コンテナーごとの区画が単一だった場合、コンテナーに障害が起こると 1 つのコンテナー (対応するレプリカ断片をホスティングするコンテナー) だけで失われたプライマリーの負荷をすべて引き受けなければなりません。 この場合、負荷はコンテナーに対して直ちに 2 倍になります。 ただし、コンテナーごとに 5 つの区画があれば、5 つのコンテナーが失われたコンテナーの負荷を受け取り、各コンテナーへの影響は 80 パーセント減少します。 コンテナーごとに複数の区画を使用すると、各コンテナーへの実質的な影響の可能性は一般的に低くなります。 さらに直接的に、コンテナーが予想外に急増するケースを考えてください。コンテナーのレプリカ生成の負荷は、1 つだけではなく 5 つのコンテナーに分散されます。

コンテナーごとのポリシーの使用

いくつかのシナリオでは、HTTP セッション・レプリカ生成またはアプリケーション・セッション状態などの場合、コンテナーごとのストラテジーは理想的な構成だと考えられています。 そのような場合、HTTP ルーターはセッションをサーブレット・コンテナーに割り当てます。 サーブレット・コンテナーは HTTP セッションを作成する必要があり、5 つのローカル・プライマリー区画のうちの 1 つをそのセッション用に選択します。 その後、選択された区画の「ID」は Cookie に保管されます。 これでサーブレット・コンテナーは、セッション状態へのローカル・アクセス権限を持ち、セッション・アフィニティーが保持されている限り、この要求に対するデータへのアクセス待ち時間はゼロになることを意味します。 さらに、eXtreme Scale は、すべての変更を区画に複製します。

実際には、コンテナーごとに複数区画を持つ場合の悪影響に注意してください (再度 5 つの例を使用します)。 当然、新たに開始した各コンテナーには、さらに 5 つのプライマリー区画と、さらに 5 つのレプリカがあります。 時間とともに、さらに区画が作成され、移動または破棄されないはずです。 しかし、これは実際にコンテナーが振る舞う様子ではありません。 コンテナーは、開始すると 5 つのプライマリー断片をホストします。これは「ホーム」プライマリーと呼ばれ、それらを作成したそれぞれのコンテナー上に存在します。 コンテナーに障害が起こると、レプリカがプライマリーになり、eXtreme Scale はさらに 5 つのレプリカを作成し、高可用性を保持します (自動修復を使用不可にしていない場合)。 新規プライマリーはそれを作成したコンテナーとは別のコンテナーにあり、「外部」プライマリーと呼ばれます。 アプリケーションは、新規状態または新規セッションを外部プライマリーには決して配置しません。 最終的に、外部プライマリーはエントリーを持たず、eXtreme Scale は外部プライマリーとその関連レプリカを自動的に削除します。 外部プライマリーの目的は、既存のセッション (新しいセッションではなく) を引き続き使用可能にしておくことです。

クライアントは、キーを利用しないデータ・グリッドとも対話することができます。 クライアントは、ただトランザクションを開始し、データをどのキーとも無関係のデータ・グリッドに保管します。 クライアントは、必要なときに同じ区画と対話できるようにするシリアライズ可能ハンドル、SessionHandle オブジェクトをセッションに要求します。 WebSphere eXtreme Scale は、ホーム・プライマリー区画のリストからクライアント用の区画を選択します。 外部プライマリー区画は戻されません。 SessionHandle は、例えば HTTP Cookie でシリアライズされ、後で Cookie を元の SessionHandle に変換することができます。 次に WebSphere eXtreme Scale API は SessionHandle を使用して、再度同じ区画にバインドされたセッションを取得します。

注: エージェントを使用して PER_CONTAINER データ・グリッドと対話することはできません。

利点

コンテナーごとのクライアントは、データをグリッド内の場所に保管し、データへのハンドルを取得し、そのハンドルを使用してデータに再びアクセスするため、上記の説明は通常の FIXED_PARTITION またはハッシュ・データ・グリッドと異なります。 固定区画の場合のような、アプリケーション提供のキーはありません。

デプロイメントは、各セッションごとに新規区画を作りません。 そのため、コンテナーごとのデプロイメントでは、データを区画に保管するために使用されるキーは、その区画内で固有でなければなりません。 例えば、クライアントが固有の SessionID を生成し、それをキーとして使用してその区画内のマップの情報を検索するという例が考えられます。 複数のクライアント・セッションが同じ区画と対話するため、アプリケーションは固有のキーを使用してセッション・データを特定の各区画に保管する必要があります。

上記の例では 5 つの区画を使用しましたが、objectgrid XML ファイルの numberOfPartitions パラメーターを使用すると、必要に応じて区画を指定することができます。 データ・グリッドごとではなく、設定はコンテナーごとです。 (レプリカの数は、固定区画ポリシーの場合と同じ方法で指定されます。)

コンテナーごとのポリシーは、複数ゾーンでも使用できます。 可能であれば、eXtreme Scale は、プライマリーがそのクライアントと同じゾーンにある区画に SessionHandle を返します。 クライアントは、コンテナーのパラメーターとして、または API を使用してゾーンを指定できます。 クライアント・ゾーン ID は serverproperties または clientproperties を使用して設定することができます。

データ・グリッドの PER_CONTAINER ストラテジーは、データベース指向データではなく、会話型状態を保管するアプリケーションに適しています。データにアクセスするキーは会話 ID で、特定のデータベース・レコードには関係しません。 このストラテジーにより、パフォーマンスはさらに向上し (例えばプライマリー区画をサーブレットと連結できるので)、構成はさらに容易になります (区画およびコンテナーを計算する必要はありません)。