9.3.2　クラスタを監視するタイマの設定

(1)　ハートビートの送信，および生存確認

ハートビートの送信によるクラスタ監視については，「2.10　クラスタ監視」を参照してください。

ハートビートの送信，および生存確認のタイマを次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(b)：「9.3.3(1)(b)　eads.cluster.heartbeat.interval」

(c)：「9.3.3(1)(c)　eads.cluster.heartbeat.timeout」

(d)：「9.3.3(1)(d)　eads.cluster.failureDetector.connect.timeout」

(e)：「9.3.3(1)(e)　eads.cluster.failureDetector.read.timeout」

ページの先頭へ

(2)　クラスタの開始

ezstartコマンドを実行してクラスタを開始する場合を例に，EADsサーバ開始時のタイマを次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(h)：「9.3.3(1)(h)　eads.cluster.boot.timeout」

なお，クラスタ内では，クラスタ定義で設定したEADsサーバIDがいちばん小さいEADsサーバから起動します。以降，順番に起動したEADsサーバは，最初に起動したEADsサーバからのハートビートを受信し，クラスタに参加していきます。

最初に起動したEADsサーバは，ほかのEADsサーバから受信したハートビートを基に，クラスタ構成情報を更新します。更新したクラスタ構成情報は，クラスタ内で共有します。

ページの先頭へ

(3)　クラスタの運用操作

eztoolコマンドを実行して，クラスタを運用操作する際のタイマを次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(a)：「9.3.3(2)(a)　eads.management.connect.timeout」

(b)：「9.3.3(2)(b)　eads.management.read.timeout」^※1

(c)：「9.3.3(2)(c)　eads.management.command.timeout」^※2

注※1

次に示すコマンドを実行する場合は，コマンド定義のeads.management.long_running.read.timeoutパラメタの値が適用されます。

• eztool export

• eztool import

• eztool createcache

• eztool deletecache

• eztool execfunc

• eztool importecf

• eztool resume

• eztool compaction

• eztool stop

注※2

次に示すコマンドを実行する場合は，コマンド定義のeads.management.long_running.command.timeoutパラメタの値が適用されます。

• eztool export

• eztool import

• eztool createcache

• eztool deletecache

• eztool execfunc

• eztool importecf

• eztool resume

• eztool compaction

• eztool stop

ページの先頭へ

(4)　EADsサーバの縮退処理

EADsサーバの縮退処理の流れとタイマの関係を次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(c)：「9.3.3(3)(c)　eads.client.clusterInfo.update.interval」

(j)：「9.3.3(1)(j)　eads.gracefulstop.wait_time」

eztool isolateコマンドを実行してEADsサーバを縮退させる場合，サーバ定義のeads.gracefulstop.wait_timeパラメタで，EADsサーバの縮退処理が完了してから停止するまでの時間を指定できます。クライアント定義のeads.client.clusterInfo.update.intervalパラメタの指定値よりもこの値を大きくすることで，EADsクライアントのクラスタ構成情報の更新完了後に，EADsサーバを停止できます。

なお，クラスタ監視によってEADsサーバが縮退する場合，eads.gracefulstop.wait_timeパラメタの指定は無効となります。

更新操作の履歴の補完処理については，「9.3.2(6)　更新操作の履歴の補完処理」を参照してください。

ページの先頭へ

(5)　クラスタの復旧処理

クラスタを復旧する際のタイマを次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(l)：「9.3.3(1)(l)　eads.restore.dataSender.send.timeout」

(m)：「9.3.3(1)(m)　eads.restore.dataReceiver.read.timeout」

(n)：「9.3.3(1)(n)　eads.restore.dataSender.sendInterval」

サーバ定義のeads.restore.dataSender.sendSizeパラメタに指定したサイズを超えるまで，10キロバイト単位でデータを連続して送信します。例えば，25キロバイトを指定した場合は，30キロバイトまでデータを送信します。

復旧処理では，データの整合性を回復するために，稼働中のEADsサーバが復旧対象のEADsサーバにデータを送信します。

そのため，次の点に留意してください。

• EADsサーバが復旧するまでに，少なくともデータ取得分の時間が掛かります。

• データ送信元のEADsサーバでは，データを送信する分，オンライン性能に影響があります。

参考

ディスクキャッシュ，および2Wayキャッシュを復旧する場合は，復旧処理で送信するデータサイズをキャッシュ定義のeads.cache.restore.dataSender.sendSizeパラメタで指定します。また，復旧処理でのデータ送信間隔をeads.cache.restore.dataSender.sendIntervalパラメタで指定します。

データの更新中でも，データの整合性を回復した状態で，縮退したEADsサーバをクラスタに復帰させることができます。縮退状態が発生した場合の復旧までの流れについては，「12.2.1　縮退状態が発生した場合」を参照してください。

更新操作の履歴の補完処理については，「9.3.2(6)　更新操作の履歴の補完処理」を参照してください。

ページの先頭へ

(6)　更新操作の履歴の補完処理

EADsサーバの縮退処理，復旧処理，および排他制御では，EADsサーバ間で更新操作の履歴を確認します。EADsサーバ間で更新操作の履歴に差異がある場合は，更新操作の履歴の補完処理を行います。これによって，データの書き込み順序の整合性を確保します。

更新操作の履歴の補完処理は，次の2つの処理から成ります。

• 他EADsサーバの更新操作の履歴の補完処理

• 自EADsサーバの更新操作の履歴の補完処理

なお，この場合の自EADsサーバとは次のEADsサーバを指します。

縮退処理の場合：

縮退するEADsサーバの処理を引き継ぐEADsサーバ（データのコピー先EADsサーバ）

復旧処理の場合：

復旧対象のEADsサーバ

更新操作の履歴の補完処理の流れとタイマの関係を次の図に示します。

図中のアルファベットは，「9.3.3　タイムアウトに関連するパラメタ」の説明と次のように対応しています。

(o)：「9.3.3(1)(o)　eads.consensus.fillgap.copy.timeout」

他EADsサーバの更新操作の履歴の補完処理

1. 自EADsサーバの更新操作の履歴を各EADsサーバに送信します。

2. 自EADsサーバと他EADsサーバの更新操作の履歴に差異がある場合，他EADsサーバに対して，自EADsサーバの更新操作の履歴を送信します。このとき，サーバ定義のeads.consensus.fillgap.copy.dataSizeパラメタに指定したサイズのデータを送信します。

3. 他EADsサーバは，自EADsサーバから送信された更新操作の履歴を基に更新操作の履歴を補完します。

   他EADsサーバの更新操作の履歴は次のように補完されます。

   

   他EADsサーバの更新操作の履歴の補完処理は，データのコピー先EADsサーバに対して，更新操作の履歴の差異の数だけ実行されます。

自EADsサーバの更新操作の履歴の補完処理

1. 自EADsサーバの更新操作の履歴に差異があるかを確認するため，各EADsサーバに更新操作の履歴の補完処理の要求を送信します。

2. 更新操作の履歴の補完処理の要求に対して合意処理が行われます。

   サーバ定義のeads.cache.consensus.timeoutパラメタに指定した時間内に合意処理が完了しない場合はタイムアウトして，再度，合意処理を行います。合意できるまで無限に繰り返します。

3. 合意処理によって，他EADsサーバから自EADsサーバに更新操作の履歴が送信されます。

4. 自EADsサーバは，各EADsサーバから送信された更新操作の履歴を基に更新操作の履歴を補完します。

   自EADsサーバの更新操作の履歴は次のように補完されます。

   

   自EADsサーバの更新操作の履歴の補完処理は，自EADsサーバの更新操作の履歴の差異の数だけ実行されます。

1回の復旧処理，または縮退処理に対して，更新操作の履歴の補完処理が1回だけとは限りません。最大で（データの多重度−1）×（キャッシュ数）回，実行されます。

更新操作の履歴の補完処理の同時実行スレッド数は，サーバ定義のeads.cluster.controller.cache.max_execute_threadsでパラメタ指定できます。

ページの先頭へ