先日、わずかサーバ2台だけの我が家でSplit-Brainを経験した。いくつかSplit-Brainを引き起こすようなマルチマスターのクラスターソフトがあるのだが、見事にSplit-Brainを引き起こしたのがGlusterFSだった。以前にもGlusterFSのSplit-Brainは取り扱ったことがあるが、今回はバージョンアップ後の初めてのSplit-Brainとなる。いつも通りに対応しようと以下のコマンドでsplit-brainしているファイルやディレクトリを確認する。

gluster vol heal gfs info

出力からして以前のバージョンと異なっており、gluster vol heal gfs infoでsplit-brainしているファイルが表示されるようになった。以前はreplicaがないようなheal対象のファイルは表示されていたが、split-brainは対象外だった。GlusterFSのログを覗いてみないと、その発生を把握することできなかった。どうやって気付いていたかというと、障害やメンテで片肺になったために自ら調べたか、実際にアクセスできないファイルに遭遇して確認する、といった流れだった。それが、heal infoだけでわかるようになったのは非常に便利。

heal infoにリストされるファイルは240ほど。幾つか適当なファイルを、それぞれのサーバのbrickを確認すると、どちらにもファイルは存在するしてサイズやタイムスタンプも問題なさそう。あれ、どういうことだ？今までのSplit-Brainは大抵どちらかのbrickのファイルが古かったりして起きていた。出力情報が変わっているので、split-brainの修正も容易になっていることを期待して、対応方法をぐぐってみる。案の定、glusterコマンドで対応する方法が追加されていた。split-brainを解消する方法は以下3つ。

• bigger-file
• latest-mtime
• source-brick

あまり重要でないファイルを選んで、statでmtimeを確認するとmsecの単位が一致していない。ここで、今回のsplit-brainが本格的なもので、2台それぞれに違う形で同じファイルを生成してしまっていたことに気が付いた。詳細は以前の記事にまとめてあります。ともあれ、このケースについてはlatest-mtimeで解消できそうなので、以下のコマンドを試してみる。

gluster volume heal gfs split-brain latest-mtime /data/rec/test/tmp

これでmtimeが大きい方のファイルで両brickが同期され、split-brainが解消された。heal infoのリストからも消えていた。以前の対応方法に比べたら100倍くらい楽になったな。この方法で1つ1つ対応していってもいいのだが、何せ対象ファイルは240ほどある。効率的に修正する方法がないか調べてみる。基本的にはさきほどのケースと同様に後勝ちの方針で自動修正してもらって問題ないはず。ぐぐってみると、cluster.favorite-child-policyにmtimeを指定することで、考えていた振る舞いを期待できそう。

gluster vol get gfs cluster.favorite-child-policy
gluster vol set gfs cluster.favorite-child-policy mtime

この設定を加えると同時に、split-brainの解消が進み、heal infoにリストされているファイルはなくなるかに見えた。が、どうやら一部のファイルが残ってしまった。目視確認すると、やはりそれぞれのreplica brickに同名ファイルが生成されている。mtimeは異なるので、上記の自動修正の対象になりそうだが、どうもディレクトリごと生成されていて、そのディレクトリがsplit-brainの対象となっている模様。ディレクトリのsplit-brainは対象外らしく、仕方がないので手動で対応する。今回、障害を起こした1号機のファイルをbrick内から別の場所へ移動させてしまう。

すると、さきほどの自動修正が働くようになったようで、もう一方のbrickからデータがコピーされてきた。heal infoからも対象ディレクトリが消滅する。どうやらこの方法で何とかなりそうなので、問題のディレクトリ内にあるファイルを次々とどかして同期していく。heal infoにリストされるファイルやディレクトリはなくなったが、ファイルをどかした1号機側にgfidがのリストが残ってしまった。これらも以下のように移動させると、heal infoで表示される情報は皆無となった。

gluster vol heal gfs info
Brick host1:/data1/gfs
<gfid:84545828-53a5-44e4-9aeb-7b718a967306>
<gfid:e49fc211-fb67-45bc-ad30-566c35e033b7>
<gfid:677409ce-6caa-4e6a-9a6f-586bfbf34d2d>
    :
Status: Connected
Number of entries: 14

mv /data1/.glusterfs/84/54/84545828-53a5-44e4-9aeb-7b718a967306 ~/gfsbackup/

今回は発生した問題が結構難しいものだったので対応に苦慮したが、一般的な運用レベルのSplit-Brainであれば、ほとんど自動で対応してくれるように思う。この障害以降も2号機がネットワークダウンするなどの問題はあったが、GlusterFSでSplit-Brain問題が起きることはなかった。厳密には起きた上で自動修正されていたのかもしれないけどね。GlusterFSのバージョンアップは、自分の主観では非常にハマりがちだが、Split-Brainの対応がこれだけ便利になるのであれば、トライしてみる価値は充分だ。