データ・グリッド、区画、および断片

データ・グリッドは、複数の区画に分割されます。各区画は、データの排他的なサブセットを 保持します。1 つの区画は、1 つ以上の断片 (プライマリー断片とレプリカ断片) を含んでいます。レプリカ断片は区画で必須ではありませんが、使用すると、高可用性を提供できます。デプロイメントが独立したメモリー内のデータ・グリッドであれ、メモリー内のデータベース処理スペースであれ、eXtreme Scale でのデータ・アクセスは、大きく断片に依存しています。

1 つの区画のデータは、実行時、断片の集合に保管されます。この断片の集合には、プライマリー断片と、可能性として 1 つ以上のレプリカ断片が含まれます。 断片は、eXtreme ScaleJava 仮想マシン に対して追加または除去できる最小の単位です。

配置ストラテジーには、固定区画配置 (デフォルト) とコンテナーごとの配置の 2 つがあります。 以下では、固定区画配置ストラテジーの使用に焦点を当てて説明します。

断片の総数

環境にレプリカなしの 1,000,000 のオブジェクトを保持する 10 の区画があるとすると、それぞれ 100,000 のオブジェクトを保管する 10 の断片が存在することになります。このシナリオにレプリカを 1 つ追加すると、各区画には追加の断片が存在することになります。 この場合、20 の断片、すなわち、10 のプライマリー断片と 10 のレプリカ断片が存在することになります。これらの断片の 1 つ 1 つには、100,000 のオブジェクトが保管されます。各区画は、1 つのプライマリー断片と 1 つ以上 (N) のレプリカ断片で構成されます。最適な断片数を決定することは、非常に重要です。少数の断片を構成すると、データが断片間に均等に配分されず、メモリー不足エラーやプロセッサーの過負荷問題が生じることになります。各 JVM あたり、少なくとも 10 の断片になるように見積もってください。初めにデータ・グリッドをデプロイするときは、可能性として多数の区画を使用することになります。

JVM あたりの断片数のシナリオ

シナリオ: 少数の JVM あたりの断片数

データは、断片単位を使用して JVM に対して追加および除去されます。断片がさらに小さく分割されることはありません。10 GB のデータがあり、このデータを保持するために 20 の断片が存在しているとすると、各断片には、平均 500 MB のデータが保持されていることになります。9 つの Java 仮想マシンがデータ・グリッドをホストしている場合、各 JVM には、平均して 2 つの断片を持ちます。20 は 9 で割りきれませんから、いくつかの Java 仮想マシン は次の配分のように 3 つの断片を持つことになります。 各断片には 500 MB のデータが保持されていますから、データ配分は均等ではありません。2 つの断片を持つ 7 つの Java 仮想マシン は、それぞれ 1 GB のデータをホストすることになります。3 つの断片を持つ 2 つの Java 仮想マシン には、50% 多い 1.5 GB のデータが設定され、メモリー負担がずっと大きくなります。2 つの Java 仮想マシン は、3 つの断片をホスティングしているため、そのデータに対しても 50% 多い要求を受信することになります。したがって、各 JVM あたりに少数の断片数が設定される場合は、不均衡が生じます。パフォーマンスを改善するためには、各 JVM あたりの断片数を大きくします。

シナリオ: JVM あたりの断片数を大きくする

このシナリオでは、断片数をより大きくすることを考えます。このシナリオでは、10 GB のデータをホスティングする 9 つの Java 仮想マシンに、101 の断片があるとします。この場合、各断片には 99 MB のデータが保持されます。Java 仮想マシン には、次のように断片が配分されます。 12 の断片を持つ 2 つの Java 仮想マシン は、99 MB のデータだけ他の断片より多くなりますが、これは 9% の違いに相当します。このシナリオの方が、少数の断片によるシナリオの 50% の違いに比べてはるかに均等に配分されています。プロセッサー使用の観点から見れば、12 の断片を持つ 2 つの Java 仮想マシン には、11 の断片を持つ 7 つの Java 仮想マシン に比べてわずか 9% 多くの作業が割り当てられることになります。各 JVM 中の断片数を大きくすることにより、データおよびプロセッサー使用が、平等、均等に配分されることになります。

システムを作成する場合、あるいは、システムが計画期間で最大数の Java 仮想マシンを実行している場合、最大サイズのシナリオとして各 JVM あたり 10 の断片を使用するようにしてください。

追加の配置要因

区画数、配置ストラテジー、およびレプリカの数とタイプは、デプロイメント・ポリシーで設定されます。 配置される断片数は、ユーザーが定義するデプロイメント・ポリシーによって決まります。 minSyncReplicas、developmentMode、maxSyncReplicas、および maxAsyncReplicas 属性は、区画とレプリカが配置される場所に影響します。

次の要因が断片の配置可能な時間に影響します。
  • xscmd -c suspendBalancing コマンドおよび xscmd -c resumeBalancing コマンド。
  • 断片がコンテナー・サーバーに配置される前のミリ秒数を定義する placementDeferralInterval プロパティーが含まれた、サーバー・プロパティー・ファイル。
  • デプロイメント・ポリシー内の numInitialContainers 属性。

初期始動時に最大数のレプリカが配置されない場合、後で追加のサーバーを始動したときに追加のレプリカが配置される場合があります。JVM ごとの断片数を計画する場合、プライマリー断片とレプリカ断片の最大数は、構成されたレプリカの最大数をサポートするのに十分な JVM が開始されているかどうかによって異なります。 レプリカはプライマリーと同じプロセス内に配置するべきではありません。あるプロセスが失われると、プライマリーもレプリカも共に失われます。developmentMode 属性が false に設定されている場合、プライマリーとレプリカは同じ物理サーバーに配置されません。