Hitachi

インメモリデータグリッド　Hitachi Elastic Application Data Store ユーザーズガイド

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

クラスタ内のEADSサーバは，互いにハートビートを送信し合い，正常に稼働していることをクラスタ内に知らせています。

また，コマンド実行時のEADSサーバとの通信や，コマンド実行開始から終了までに掛かる時間を監視することによって，通信障害を検知しています。

考え方

監視時間を短くすることで通信障害を検知するスピードを早めたり，長くすることで頻繁にタイムアウトが発生するのを防いだりします。

〈この項の構成〉

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

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

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

[図データ]

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

(c)：「9.3.3(1)(c)　eads.failureDetector.heartbeat.interval」

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

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

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

ページの先頭へ

(2)　クラスタの開始

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

[図データ]

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

(i)：「9.3.3(1)(i)　eads.admin.boot.timeout」

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

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

(a)　クラスタ定義の内容がほかのEADSサーバと異なる場合

すでに起動しているEADSサーバは，ハートビートにクラスタ定義の内容をハッシュ化した値を付与して送信します。

すでに起動しているEADSサーバからハートビートを受信すると，そのハッシュ値をチェックして，ハッシュ値が異なれば，起動に失敗します。

(b)　クラスタ起動中に，すでにクラスタに参加しているEADSサーバがダウンした場合

クラスタ起動中に，すでにクラスタに参加しているEADSサーバがダウンした場合，ダウンしたEADSサーバは縮退状態に遷移します。ほかのEADSサーバも起動処理を中断し，起動に失敗します。

クラスタ内の半数以上のEADSサーバが同時にダウンした場合，タイムアウトします。

(c)　クラスタ起動中に，まだクラスタに参加していないEADSサーバがダウンした場合

クラスタ起動中に，まだクラスタに参加していないEADSサーバがダウンした場合，全EADSサーバの起動処理が完了しないため，すでに起動しているEADSサーバはタイムアウトします。

ページの先頭へ

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

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

[図データ]

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

(a)：「9.3.3(2)(a)　eads.command.connection.timeout」

(b)：「9.3.3(2)(b)　eads.command.common.read.timeout」※1

(c)：「9.3.3(2)(c)　eads.command.common.execution.timeout」※2

注※1

コマンド定義のeads.command.＜サブコマンド名＞.read.timeoutパラメタを指定した場合は，eads.command.＜サブコマンド名＞.read.timeoutパラメタの値が適用されます。

注※2

コマンド定義のeads.command.＜サブコマンド名＞.execution.timeoutパラメタを指定した場合は，eads.command.＜サブコマンド名＞.execution.timeoutパラメタの値が適用されます。

ページの先頭へ

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

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

[図データ]

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

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

(k)：「9.3.3(1)(k)　eads.admin.operation.isolate.gracefulstop.waitTime」

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

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

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

ページの先頭へ

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

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

[図データ]

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

(m)：「9.3.3(1)(m)　eads.transfer.timeout」

(n)：「9.3.3(1)(n)　eads.transfer.interval」

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

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

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

参考

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

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

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

ページの先頭へ

(6)　クラスタのスケールアウト処理（EADSサーバの追加）

クラスタをスケールアウトする（クラスタにEADSサーバを追加する）際のタイマは，クラスタを復旧する際のタイマと同じです。

クラスタを復旧する際のタイマについては，「9.3.2(5)　クラスタの復旧処理」を参照してください。その際には，説明の「復旧」を「スケールアウト」に読み替えてください。

ページの先頭へ

(7)　クラスタのリバランス処理（レンジに格納できるkeyの数の均等化）

クラスタをリバランスする（レンジに格納できるkeyの数を均等にする）際のタイマは，クラスタを復旧する際のタイマと同じです。

クラスタを復旧する際のタイマについては，「9.3.2(5)　クラスタの復旧処理」を参照してください。その際には，説明の「復旧」を「リバランス」に読み替えてください。

また，リバランスの場合は，稼働中のEADSサーバから稼働中のEADSサーバに対してデータを送信します。このため，説明のパラメタ名を次のように読み替えてください。

ページの先頭へ

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

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

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

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

縮退処理の場合：

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

復旧処理，スケールアウト処理，およびリバランス処理の場合：

復旧対象のEADSサーバ，スケールアウト処理で追加するEADSサーバ，およびリバランス処理で位置を変更するEADSサーバ

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

[図データ]

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

(p)：「9.3.3(1)(p)　eads.replication.fillgap.copy.timeout」

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

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

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

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

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

    [図データ]

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

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

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

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

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

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

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

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

    [図データ]

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

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

更新操作の履歴の補完処理の同時実行スレッド数は，データの多重度−1（データの多重度が1の場合は1）になります。

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2015, 2021, Hitachi, Ltd.