前回試した際に、動作が不安定だったために具体的な検証すら見送ったcephfs。実は4月にcephfsのstable版を含むcephのメジャーリリースがあった。評価してみたいなあと思いつつも、ファイルサーバ用途としてはglusterfsが充分な機能を持っていたので、今の今まで後回しにしていた。ansibleとか録画サーバとかいじってたからだけど。そんな満足度の高いglusterfsだけど、唯一の欠点がopen()が異常に遅い事。大きいファイルを置くだけで、参照も更新も少ないファイルサーバくらいならいいんだけど、頻繁に更新が伴うような用途には向かない。例えば、lxcで作るコンテナの配置先とか。

コンテナに必要なファイル一式をglusterfs上に置ければ、そこをマウントするだけで、どのノードでもそのコンテナを起動可能になる。同じコンテナを複数ノードに作るよりも、そういう形で冗長化を図るのもありかと思った。コンテナ構築時にはlxcのファイルキャッシュから多くのファイルコピーが行われる。配置先をglusterfsにすると、これがもうびっくりするくらい遅くなるので使う気になれない。ローカルディスクのSSDでlxc-createすると数10秒でコンテナが作れるが、配置先をglusterfsにするだけで数10分かかってしまう。cephfsにはその代替としての可能性を評価したい。もちろんstable版の安定性も確認しながら。

という訳で、cephfsを構築する。検証に使うサーバは、dfs1/2/3という3台で、どれもSSDのルートディスクを使う。構築方法は以前同様だが、何故かsystemdで使うシンボリックリンクがきちんと張れなかった。mon, mds, osd用のシンボリックリンクを全て手動で用意してからcerateやらactivateを行った。

ln -s /usr/lib/systemd/system/ceph-mon@.service /etc/systemd/system/multi-user.target.wants/ceph-mon@`hostname -s`.service
ln -s /usr/lib/systemd/system/ceph-mds@.service /etc/systemd/system/multi-user.target.wants/ceph-mds@`hostname -s`.service
ln -s /usr/lib/systemd/system/ceph-osd@.service /etc/systemd/system/multi-user.target.wants/ceph-osd@0.service

ちなみにmdsも3つ作ったので、multi mds構成となる。ファイルシステムはSSDであるルートディスクを使いたかったのでext4になる。個人的にxfsにつらい思い出があるので、未だにext4を自分標準としているので、ご容赦を。osdでext4を使う場合はceph.confに以下の設定を加えてからactivateする必要がある。

osd max object name len = 256
osd max object namespace len = 64

幸いにもcephの起動に成功したら、前回同様にcephfsを構築する。今回はファイルサーバ用途でなく、コンテナの配置先なので、レプリ数は変更せずに3のままにしておいた。作成したcephfsをマウントして、lxcで作ったtest1というコンテナをそこにrsyncしてみる。具体的には、サイズが1.2GBでディレクトリ数は4340、ファイル数は33819。尚、SSDのローカルディスクにrsyncする処理は16秒だった。

ssh root@dfs1
ceph osd pool create cephfs_data 64
ceph osd pool create cephfs_meta 64
ceph fs new cephfs cephfs_meta cephfs_data
mkdir /ctest
mount -t ceph dfs1:6789:/ /ctest -o name=admin,secret=`sudo ceph-authtool -p /etc/ceph/ceph.client.admin.keyring`
time rsync -a /var/lib/lxc/test1 /ctest
     :
real    5m33.528s
user    0m14.118s
sys    0m14.000s

time rsync -a /ctest/test1 ~/ctest
     :
real    3m1.000s
user    0m13.183s
sys    0m12.017s

そもそも以前のバージョンではrsyncが途中で刺さってしまうという問題があったが、少なくとも今回のバージョンでそういうことは1度も起きなかった。処理結果としては、cephfsへの書き出しが5分ほど、cephfsからローカルディスクへの書き戻しが3分となる。続いて、比較のためにレプリカ数3のglusterfsを構築して同様にrsyncを行ってみる。コマンドは以下。

gluster vol create gtest replica 3 dfs1:/gtest1 dfs2:/gtest1 dfs3:/gtest1 force
gluster vol start gtest
mount -t glusterfs dfs1:/gtest /gtest
time rsync -a /var/lib/lxc/test1 /gtest
     :
real    135m19.889s
user    0m17.927s
sys     0m20.952s

目を疑うような結果だった。replica 3はまるで実用性がないということか。それとも何か設定間違えたのかな。。。自分で使っていても、さすがにここまで遅い事はないのでreplica 2でも試験してみる。

gluster vol stop gtest
gluster vol delete gtest
gluster vol create gtest replica 2 dfs1:/gtest1 dfs2:/gtest1 force
gluster vol start gtest
mount -t glusterfs dfs1:/gtest /gtest
time rsync -a /var/lib/lxc/test1 /gtest
     :
real    15m28.599s
user    0m16.080s
sys     0m19.804s

time rsync -a /gtest/test1 ~/gtest
     :
real    2m12.792s
user    0m13.765s
sys     0m12.770s

ちょっとは現実的な数値になった。それでも15分かかっているので、いかにglusterfsがこういう用途に向かないかがわかる。ローカルディスクへの書き戻しは2分なのでcephfsよりも速い。参照のみに使うような用途ならありなのかな。書き込みについてはcephfsの方が速いが、それでも6分かかってしまうので積極的に使う気にはなれない。lxcなんてポコポコ作ってポコポコ壊すような使い方が多いし。共有できるコンテナとして使いたかったのはchefサーバで、ansible移行後はそのニーズも弱まり、この性能で無理に使いたいほどの要件はない。やっぱり使うならブロックデバイスとしてなのかなあ。