導入以来、想像以上にタフに動いてくれているglusterfs。当初はcephfsとの選択を迷う時期もあったが、現時点ではglustefsが自分の環境にはフィットしている。2ノードの3TBディスク8本の構成なので、分散FSとしての性能はまったく期待していない。8本の中でRAID10的なdistributed-replicateを構成しており、その冗長性とネットワーク経由でのファイルシステムの共有に大きな価値を見出している。ファイルシステムレベルで冗長性を確保できたことによって、多くのミドルウェアの冗長性を気にする必要がなくなり、構成管理が非常にシンプルにすることができた。あくまで個人管理の趣味システムを前提とした話だが。
当初よく起きていた問題が、冗長化された2つのデータが異なってしまう障害。それをglusterfsではSplit-Brainと位置付けている。もしかしたらデータを3つに冗長化すれば、quorumでSplit-Brainを回避してくれるのかもしれないが、自分の環境では3ノードの冗長化は想像以上に性能が劣化したので見合わせている。発生するのはいずれかのノードを停止して再構築する際。片肺状態のときにGlusterFS上のkickstartファイルやansibleのplaybookファイルに不足していた設定を加えることが多々あり、再構築後のクラスタージョイン時にSplit-Brainとなってしまった。
片肺作業時によく起きる印象ではあったが、ファイルのタイムスタンプはかなり古い日付だったりすることもあったので、もともとクラスター的に問題のあったファイルが、単に大きな作業時に発覚したというだけかもしれない。というのも、2号機の外付けディスクアレイが突然外れて勝手に再接続されている、なんてことが何度かあり、物理的にも信用ならない状況であったからだ。そういうこともあってUSBの外付けを信用しなくなり、現在は2台のSh170R8を使って8台のディスク全てを内部接続に切り替えた。それからというものSplit-Brainは起きなくなったので、やはりディスクアレイの安定性が問題だったのかもしれない。
Split-Brainの問題は、任意のファイルに対するI/Oが出来なくなってしまって発覚する。削除や更新を行おうとするとInput/Output Errorが発生して変更不可になる。初めて目にした時はファイルシステムが壊れたんじゃないかと相当焦る。特に頻繁にアクセスするgitのbareリポジトリなどで起きやすく、GlusterFS上にbareリポジトリを置くのは危険と考えた時期もあった。他のファイルにはアクセスできるのに一部のファイルにだけ問題が起きる場合は、きっとSplit-Brainで正しく対処すれば整合性は回復できる。まずはSplit-Brainしているファイルを確認する。GlusterFSのファイルシステム名は仮にbrickfsとしておく。
gluster vol heal brickfs info
Brick host2:/data1/brick
Number of entries: 0
Brick host1:/data1/brick
Number of entries: 0
Brick host2:/data2/brick
Number of entries: 0
Brick host1:/data2/brick
Number of entries: 0
Brick host2:/data3/brick
Number of entries: 0
Brick host1:/data3/brick
Number of entries: 0
Brick host2:/data4/brick
Number of entries: 0
Brick host1:/data4/gfs
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host1.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host2.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host3.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host4.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5> - Is in split-brain
Number of entries: 5
こんな感じで問題のあるファイルが表示される。自分の場合はファイル名からパスもわかるようなものだったので、両サーバの実ファイルをそれぞれ確認してタイムスタンプやデータサイズに差異があることを確認した。どちらかに統一すればいい訳だが、大抵はタイムスタンプが新しいものに統一すればよい。GlusterFSには実ファイルとは別にメタデータもあるので、そちらのファイル名も確認しておく必要がある。以下のコマンドでメータデータのファイル名を調べる。
getfattr -d -m trusted.gfid -e hex /data4/brick/ks/host1.cfg
getfattr: Removing leading '/' from absolute path names
# file: data4/brick/ks/host1.cfg
trusted.gfid=0x0d973b0f0f0f442293af9d569c7601cc
ここで表示されたgfidの最初の2byteと次の2byteがディレクトリになる。8byte目以降にハイフンがはいってしまうので、その辺りを考慮して実際のパスを確認する。慣れるとすぐにパス化できるが、よくわからなければ頭に8byteくらいでfindかけてしまってもよいだろう。
ls -l /data4/brick/.glusterfs/0d/97/0d973b0f*
-rw-r--r-- 2 root root 1432 7月 9 14:27 /data4/brick/.glusterfs/0d/97/0d973b0f-0f0f-4422-93af-9d569c7601cc
これらのファイルを2つのサーバで見比べて、古いものを新しいもので上書きしてあげると、Split-Brainは解消する。念のため、バックアップを取った上でファイルの統一を行い、もう一度整合性を確認すると、一覧から該当ファイルは消えているはずだ。
rsync -a /data4/brick/ks/host1.cfg host2:/data4/brick/ks/host1.cfg
rsync -a /data4/brick/.glusterfs/0d/97/0d973b0f-0f0f-4422-93af-9d569c7601cc host2:/data4/gfs/.glusterfs/0d/97
gluster vol heal brickfs info
:
Brick host1:/data4/brick
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host2.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host3.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5>/host4.cfg
<gfid:8c19df72-eec9-4d88-ae59-b0a3bb0bbba5> - Is in split-brain
あとは同じ事を繰り返せば、すべてのSplit-Brainを解消できる。あとから気付いたのだが、これらのエラーはGlusterFSのログにも出ていたので、ログ監視をきちんと行っていれば問題に速やかに気づくことも可能。ディスクを内部接続に切り替えてからは一度も起きていないので、とりあえず監視は後回しにしてる。自分管理のシステムもそれなりの規模になってきたから、そろそろ統合的な監視も検討しないといけないなあ。。。