Home > コンセプトペーパ > クラスタリング環境での配備 > SpaceクラタリングSLA

SpaceクラタリングSLA

Spaceクラスタリングは、Spaceパーティションの数、パーティションバックアップの数、およびこれらが有効なグリッドコンテナ（GSC）上に展開する方法を実行します。

このドキュメントでカバーされている3つのノードを持つクラスタでは、それぞれ1つのバックアップを持ち、最小の2つのパーティションを持つSpaceを配備することを推奨しています。さらにSLAは、パーティションおよびそのバックアップが同じホストの配下にないように設定する必要があります。MAGIC_SPACE SLAは、このように設定されています。

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:os-sla="http://www.openspaces.org/schema/sla" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/8.0/sla/openspaces-sla.xsd">

<os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="2" number-of-backups="1" max-instances-per-machine="1">

    </os-sla:sla>

</beans>

SpaceクラスタリングはSLA定義によって制御されます。これは、グリッドがSpaceを配備する時、常に定義されたクラスタリングを維持しようとすることを意味しています。

クラスタリングSLAは、configフォルダに置かれた2つのSLAファイルで定義されます。

またconfigフォルダに置かれたdatasource.xmlファイルは、データベースにJDBCの接続詳細が含まれていて、両方のSpaceで使用されます。

デフォルトでは、SLAファイルは、1つのバックアップを持つ2つのパーティション（各4つ）を定義します。プライマリパーティションとそのバックアップパーティションが同じプロセスで動作することがないように制限されまています。

SLA定義に従うグリッドのために、十分なGSCを定義する必要があります。

上記のデフォルト構成中では、プライマリパーティションが同じプロセスのそのバックアップと一緒に実行することができないため、配備されたSpaceのために実行するGSCが少なくとも2つ必要になります。

最も一般的なSLA設定は、以下の通りです。

  1. cluster-schema …… これは常に partitioned-sync2backup を設定する必要があります。これはデータをパーティションに置くことができ、各パーティションがそれと同期するバックアップを持つことができることを意味します。

  2. number-of-instances …… Spaceパーティションの必要な数です。読み込まれるMagicプロセスユニットのインスタンスを意味しています。デフォルトは、1です。メモリに多くのデータがある場合、この数を増やす必要があるかもしれません。

  3. number-of-backups …… プライマ・パーティションに対するバックアップのパーティションの数です。開発中は、バックアップを必要としないため、この値を 0  に設定することができます。number-of-instances="2"とnumber-of-backups="1"の場合、Magicのプロセスユニットには4つのインスタンスが作成されることになります。

  4. max-instances-per-vm  …… 同じJVM（GSC)つまり、同じプロセス内に配備される同じパーティションのインスタンス数です。現状のままデフォルト（max-instances-per-vm="1"）にしておくと、同じパーティションのプライマリとバックアップのインスタンスは同じGSC上で実行されません。.

  5. max-instances-per-machine …… これが 1 に設定された場合、プライマリパーティションとそのバックアップが同じマシン上で実行されなくなります。この値を 1 に設定すると、最低3台のマシンを含むクラスタに制限されます。そして、マシンのうちの1台が故障すると、失われたパーティションは3番目のマシンへ移ります。または、2台のマシンクラスタで使用することもできます。しかし、2番目のマシンが背後で稼働可能になるまで、バックアップなしでプライマリパーティションを持つことになる危険性があります。

ここに、SLAのいくつかの例があります。

  1. 2つのバックアップを持つ単一パーティションで、プライマリとバックアップのパーティションを個別のGSC上に置く場合は、以下のようにMgxpaGSSpace_sla.xmlファイルを設定します。

    <os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="1" number-of-backups="2" max-instances-per-vm="1">

    上記の例は、１台のPC上に少なくとも3つのコンテナを必要とします。各コンテナには、１つのパーティションを保持します。

  • 2つのバックアップを使用することは推奨できません。この例は、GSCの必要数がどう計算されているかを説明するために示したものです。

  • ユーザは、クラスタ内の両方のマシン上のmagicinfo_sla.xmlファイルとmagicxpi_sla.xmlファイルを更新する必要があります。これが行われないと、MAGIC_SPACEが機能低下hした状態になる可能性があります。

  1. 各々1つのバックアップを持つ２つのパーティションで、プライマリとバックアップのパーティションを個別のGSC上に置く場合は、以下のようにMgxpaGSSpace_sla.xmlファイルを設定します。

    <os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="2" number-of-backups="1" max-instances-per-vm="1">

    上記の例は、1台のPCで少なくとも2つのコンテナを必要とします。各コンテナは、2つのパーティションを保持します。

  2. 1つのバックアップを持つ２つのパーティションで、プライマリとバックアップのパーティションを個別のPC上に置く場合は、以下のようにMgxpaGSSpace_sla.xmlファイルを設定します。

    <os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="2" number-of-backups="1" max-instances-per-machine="1">

    上記の例は、各PCに少なくとも1つのコンテナを持つ少なくとも2台のPCを必要とします。各PCでは、コンテナは2つのパーティションを保持します。2台のPCのクラスタがあり、1つのPCに障害が発生した場合、Magic Spaceの配備は不完全になり（障害発生）、障害が発生したPCが再び起動するまで、バックアップのパーティションは紛失したバックアップのパーティションに置き換わりません。

*** max-instances-per-machine ="1" の使用は、最低3台のPCを含むクラスタに制限されます。このうちの1台で障害が発生しても、紛失したパーティションは3番目のPCに移ります。

*** GSCの数はgs-agent.batファイルで定義されます。このファイルは、GigaSpaces-xpa\binフォルダにあります。gs-agent.batの呼び出しを行うコマンドの開始で、gsa.gscパラメータの次の数値を修正することによって必要なパーティションの数に合うGSCの数を定義する必要があります。