第39章 データセンター間のレプリケーションのセットアップ
39.1. データセンター間レプリケーション
Red Hat JBoss Data Grid では、データセンター間レプリケーションにより、管理者は複数のクラスターでデータのバックアップを作成することができます。これらのクラスターは物理的に同じ場所または異なる場所に置くことができます。JBoss Data Grid のサイト間レプリケーションの実装は JGroups の RELAY2 プロトコルをベースとします。
データセンター間レプリケーションにより、クラスター全体におけるデータの冗長性が保証されます。データを復元するためのバックアップを作成する他に、これらのデータセットをアクティブ-アクティブモードで使用することもできます。このように設定されると、あるクラスターに障害が発生したときに別の環境にあるシステムがセッションを処理することができます。各クラスターを他のクラスターとは物理的に異なる場所に置くことが理想的です。
39.2. データセンター間レプリケーションの操作
Red Hat JBoss Data Grid のデータセンター間レプリケーションの操作は、以下のような例を使用して説明できます。
図39.1 データセンター間レプリケーションの例
この例では、LON
、NYC
および SFO
の 3 つのサイトが設定されます。それぞれのサイトは、3 つから 4 つの物理ノードから構成される実行中の JBoss Data Grid クラスターをホストします。
Users
キャッシュは、LON
、NYC
および SFO
の 3 つのすべてのサイトでアクティブです。これらのサイトのいずれかの Users
キャッシュへの変更は、キャッシュが設定で他の 2 つのサイトをバックアップとして定義している限り、それらの他の 2 つのサイトにレプリケートされます。ただし、Orders
キャッシュは、他のサイトにレプリケートされないため LON
サイトでのみ利用できます。
Users
キャッシュは各サイトで異なるレプリケーションメカニズムを使用できます。たとえば、データのバックアップを SFO
に同期的に、NYC
と LON
に非同期的に行います。
さらに、Users
キャッシュの設定をサイトごとに変えることもできます。たとえば、LON
サイトでは owners
を 2
に設定した分散キャッシュとして設定し、NYC
サイトではレプリケートされたキャッシュとして、さらに SFO
サイトでは owners
を 1
に設定した分散キャッシュとして設定することができます。
JGroups は各サイト内の通信やサイト間の通信に使用されます。RELAY2 という JGroups プロトコルは、サイト間の通信を容易にします。詳細は、JBoss Data Grid Administration Guide の RELAY2 のセクションを参照してください。
39.3. プログラミングによるデータセンター間レプリケーションの設定
Red Hat JBoss Data Grid でのデータセンター間のレプリケーションを設定するプログラムを用いた方法を以下に示します。
プログラミングによるデータセンター間レプリケーションの設定
ノードの場所を特定します。
ノードが所属するサイトを宣言します。
globalConfiguration.site().localSite("LON");
JGroups を設定します。
RELAY プロトコルを使用するように JGroups を設定します。
globalConfiguration.transport().addProperty("configurationFile", jgroups-with-relay.xml);
リモートサイトをセットアップします。
リモートサイトにレプリケートするために JBoss Data Grid キャッシュをセットアップします。
ConfigurationBuilder lon = new ConfigurationBuilder(); lon.sites().addBackup() .site("NYC") .backupFailurePolicy(BackupFailurePolicy.WARN) .strategy(BackupConfiguration.BackupStrategy.SYNC) .replicationTimeout(12000) .sites().addInUseBackupSite("NYC") .sites().addBackup() .site("SFO") .backupFailurePolicy(BackupFailurePolicy.IGNORE) .strategy(BackupConfiguration.BackupStrategy.ASYNC) .sites().addInUseBackupSite("SFO")
オプション: バックアップクラッシュを設定します。
JBoss Data Grid は、リモートサイトと同じ名前でデータをキャッシュに暗黙的にレプリケートします。リモートサイトのバックアップキャッシュの名前が異なる場合、データが確実に正しいキャッシュにレプリケートされるようにするため
backupFor
キャッシュを指定する必要があります。注記この手順は任意であり、リモートサイトのキャッシュの名前が元のキャッシュとは異なる場合にのみ必要になります。
LON
からのバックアップデータを受信できるようにサイトNYC
のキャッシュを設定します。ConfigurationBuilder NYCbackupOfLon = new ConfigurationBuilder(); NYCbackupOfLon.sites().backupFor().remoteCache("lon").remoteSite("LON");
LON
からバックアップデータを受信できるようにサイトSFO
のキャッシュを設定します。ConfigurationBuilder SFObackupOfLon = new ConfigurationBuilder(); SFObackupOfLon.sites().backupFor().remoteCache("lon").remoteSite("LON");
設定ファイルの内容を追加します。
デフォルトでは、Red Hat JBoss Data Grid の infinispan-embedded-{VERSION}.jar パッケージに default-configs/default-jgroups-tcp.xml や default-configs/default-jgroups-udp.xml などのJGroups 設定ファイルが含まれています。
JGroups 設定ファイルを新規ファイル (この例ではファイル名は jgroups-with-relay.xml) にコピーし、指定の設定情報をこのファイルに追加します。relay.RELAY2 プロトコル設定は設定スタックの最新のプロトコルである必要があります。
<config> <!-- Additional configuration information here --> <relay.RELAY2 site="LON" config="relay.xml" relay_multicasts="false" /> </config>
relay.xml ファイルを設定します。
relay.xml ファイルで relay.RELAY2 設定をセットアップします。このファイルにはグローバルクラスター設定が記述されています。
<RelayConfiguration> <sites> <site name="LON" id="0"> <bridges> <bridge config="jgroups-global.xml" name="global"/> </bridges> </site> <site name="NYC" id="1"> <bridges> <bridge config="jgroups-global.xml" name="global"/> </bridges> </site> <site name="SFO" id="2"> <bridges> <bridge config="jgroups-global.xml" name="global"/> </bridges> </site> </sites> </RelayConfiguration>
グローバルクラスターを設定します。
relay.xml で参照される jgroups-global.xml ファイルには、グローバルクラスター、つまりサイト間の通信で使用される別の JGroups 設定が含まれます。
グローバルクラスターは、通常 TCP ベースで、TCPPING プロトコル (PING や MPING ではなく) を使用してメンバーを検索します。default-configs/default-jgroups-tcp.xml の内容を jgroups-global.xml にコピーし、TCPPING を設定するために以下の設定を追加します。
<config> <TCP bind_port="7800" <!-- Additional configuration information here --> /> <TCPPING initial_hosts="lon.hostname[7800],nyc.hostname[7800],sfo.hostname[7800]" ergonomics="false" /> <!-- Rest of the protocols --> </config>
TCPPING.initial_hosts
のホスト名 (または IP アドレス) をサイトマスターに使用されるものに置き換えます。ポート (この例では7800
) はTCP.bind_port
と一致する必要があります。TCPPING プロトコルの詳細は、JBoss Data Grid の Administration and Configuration Guide を参照してください。
39.4. サイトをオフラインにする
Red Hat JBoss Data Grid のデータセンター間のレプリケーション設定では、一定の時間間隔に 1 つのサイトへのバックアップが複数回失敗する場合、そのサイトを自動的にオフラインとすることができます。この機能により、サイトをオフラインとする管理者による手動の介入が不要になります。
プログラムを用いて Red Hat JBoss Data Grid でデータセンター間のレプリケーションサイトを自動的にオフラインにするよう設定するには、以下を行います。
サイトをオフラインにする (プログラムを使用)
lon.sites().addBackup() .site("NYC") .backupFailurePolicy(BackupFailurePolicy.FAIL) .strategy(BackupConfiguration.BackupStrategy.SYNC) .takeOffline() .afterFailures(500) .minTimeToWait(10000);
39.5. Hot Rod サイト間クラスターフェイルオーバー
クラスター内のフェイルオーバーに加えて、Hot Rod クライアントは、それぞれが独立したサイトを表す異なるクラスターにフェイルオーバーできます。Hot Rod サイト間クラスターフェイルオーバーは自動および手動モードの両方で利用できます。
自動サイト間フェールオーバー
メイン/プライマリークラスターノードが利用できない場合、クライアントアプリケーションは、代替方法で定義されたクラスターをチェックし、それらへのフェイルオーバーを試行します。フェイルオーバーが正常に実行されると、クライアントはその代替クラスターが利用不可になるまでそのクラスターに接続されたままになります。その後、クライアントは他の定義済みクラスターにフェイルオーバーし、接続が復元される場合は最終的に元のサーバー設定を持つメイン/プライマリークラスターに切り替わります。
Hot Rod クライアントに代替クラスターを設定するには、以下の例が示す設定済みクラスターのそれぞれに対して 1 つ以上のホスト/ポートのペアの詳細情報を指定します。
代替クラスターの設定
org.infinispan.client.hotrod.configuration.ConfigurationBuilder cb = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder(); cb.addCluster("remote-cluster").addClusterNode("remote-cluster-host", 11222); RemoteCacheManager rcm = new RemoteCacheManager(cb.build());
クラスター定義を問わず、デフォルトのサーバーホストおよびポートの詳細を使用して初期サーバーが解決されない場合は初期サーバー設定を指定する必要があります。
手動によるサイト間クラスターフェイルオーバー
手動によるサイトクラスターのスイッチオーバーでは、RemoteCacheManager の switchToCluster(clusterName)
または switchToDefaultCluster()
を呼び出します。
switchToCluster(clusterName)
を使用すると、ユーザーは Hot Rod クライアント設定で事前定義されたクラスターの 1 つへの切り替えをクライアントに対して強制できます。デフォルトのクラスターへ切り替える場合は、代わりに switchToDefaultCluster()
を使用します。