Self-heal daemonの仕組み

Pending Operationフラグについて

レプリカ構成のファイルは、ファイルへの書き込みの際に、一方のノードへの書き込みに失敗すると、書き込みに成功したノードにおいて「Pending Operationフラグ」が立ちます。Self-heal daemonは、10分毎に起動して、Pending Operationフラグの立ったファイルの再レプリケーションを試みます。

従って、一方のノードが停止/起動した場合、停止中に書き込まれたファイルに対しては、他方のノードにおいてPending Operationフラグが立って、Self-heal daemonによる自動再レプリケーションの対象となります。

あるいは、下記のコマンドは、Self-heal daemonの起動を待たずに、その場で、Pending Operationフラグが立ったファイルの再レプリケーションを行います。

# gluster vol heal <Volume>

スプリットブレインの検知について

「スプリットブレインの解消」にあるように、レプリカされたノード間でファイルの内容に矛盾が生じて、どちらのファイルが正しいか判断できない状況を「スプリットブレイン」と言います。スプリットブレインは、前述のPending Operationフラグの状態によって検知されます。

たとえば、「ノード１」と「ノード２」でレプリカされているとして、「ノード２」が停止中にファイルへの書き込みがあると、「ノード１」においてPending Operationフラグが立ちます。

その後、「ノード２」が起動すると、「ノード２」にはPending Operationフラグが無いため、Self-heal daemonは、「ノード１」のファイルを正として、「ノード２」に再レプリケーションを行います。

一方、「ノード２」が起動すると同時に「ノード１」が停止して、さらにファイルへの書き込みがあると、「ノード２」においてもPending Operationフラグが立ちます。この後、「ノード１」が起動すると、結局、「ノード１」「ノード２」の両方でPending Operationフラグが立った状態になります。

この場合、Self-heal daemonは、両方のノードでPending Operationフラグを検出するため、どちらを正としてよいか判断できずに、該当ファイルを「スプリットブレイン」状態と判断します。

ノード再構築時の再レプリケーション方法

正常にレプリカされたファイルがある状態において、一方のノードを「ノード交換」の手順で再構築したとします。この場合、再構築したノードからは該当ファイルは消失しますが、他方のノードで「Pending Operationフラグ」は立っていないため、Self-heal daemonによる自動再レプリケーションの対象にはなりません。

この場合は、次のコマンドを実行することにより、再レプリケーションが行われます。

# gluster vol heal <Volume> full

「full」オプションは、Pending Operationフラグの有無にかかわらず、全てのファイルに対して、レプリケーションの状態を再確認した上で、再レプリケーション処理を実施します。

あるいは、クライアントからファイルの属性情報へのアクセスがあった場合は、そのタイミングでレプリケーション状態の確認が行われますので、ボリュームをマウントしたクライアント上で、lsコマンドなどでファイルの属性を取得することでも再レプリケーションが行われます。ただし、NFSクライアントの場合は、クライアント側で属性情報のキャッシュが行われますので、lsコマンドでは再レプリケーションされない場合があります。