NIES - 白線オール

■GlusterFS性能評価

TwitterのTLで話題になったので，最近測ったGlusterFS (version 3.2.1)の性能評価を公開してみたいと思います．

■評価環境

ノード数: 8 nodes

CPU: Intel(R) Xeon(TM) CPU 3.00GHz 2socket 1core + Hyper Threading

ネットワーク: 1Gbps

(iperf 839Mbps = 100MiB/sec)

ディスク性能:

/dev/sdb(2TB HDD) ext3

write: 103.70 MiB/sec

read: 124.32 MiB/sec

■ I/O throuput (dd)

write測定方法: dd if=/dev/zero of=file bs=1M count=4k conv=fdatasync

read測定方法: echo 1 > /proc/sys/vm/drop_caches後に dd if=file of=/dev/null bs=1M count=4k

各サーバ1つずつbrickをvolumeに登録．8 bricksで1 volumeを構成．

• ext3
  • 比較用ext3ファイルシステム
• dist_remote
  • distributed volumes リモートbrickへのファイルI/O
• dist_local
  • distributed volumes ローカルbrickへのファイルI/O
• dist_rep_*
  • distributed replicated volume (4 distributed x 2 replicated = 8bricks)
• dist_str_*
  • distributed striped volume (4 distributed x 2 striped = 8bricks)
• rep_8
  • replicated volumesで8ノードへ複製作成
• stripe_8
  • striped volumesで8ノードへストライピング

考察

• マウントポイントと実際にファイルの実体を書くサーバが一致してると速い
• ネットワークが1Gib(実測で100MiB/sec)なので，ネットワークがボトルネックとなっている．(10Gibの環境で評価が必要)

■ ファイルシステム操作のスループット (mdtest)

ファイルシステム操作のスループット: mdtest(http://sourceforge.net/projects/mdtest/)を使用

8 clientからの並列{file|directory} create->stat->delete

各クライアント1000個，合計8000個の{file|directory}をcreate->stat->delete

• *_shared
  • マウントポイント直下に8000{file|directory}を並列にcreate->stat->deleteした場合
• *_unique
  • マウントポイント直下に，クライアントごとにディレクトリを作成してから，それぞれのディレクトリに1000個ずつ{file|directory}をcreate->stat->deleteした場合

ditributed striped volumeについては，ファイルの作成・削除に失敗する為，測定できなかった．原因は調査中です．

考察

• ディレクトリ操作が全体的に遅い
  • ディレクトリの作成は，すべてのglusterfsサーバで行われる為．
• ファイル作成，削除はディレクトリ操作と比べて速い
• replicateやstripeをすると，ファイル create/stat/deleteの性能は低下する