Lustreファイルシステムの性能評価

第 74 回月例発表会（2004 年 11 月）
知的システムデザイン研究室
Lustre ファイルシステムの性能評価
Performance evaluation of Lustre File System
藤原樹
Tatsuki Fujiwara
Abstract: The number of nodes which cluster have is increasing sharply in recent years.Distributed
file system such as NFS and ASF do not satisfy the requirements of today ’s high-performance computing environments.Lustre provides high I/O throughput in clusters and shared-data environments
and also protection from single points of failure.This paper shows result of benchmark with Lustre.
1
はじめに
とデータの詳細を示す．
いる．クラスタにおいて広く用いられている分散ファイ
• メタデータ
ファイルのサイズ，作成時刻，アクセス時刻，修正
ルシステムの NFS，AFS を用いた場合，NFS サーバ 1
時刻，それに加えてデータの識別子，データの格納
台に対して NFS クライアントが複数マウントするため，
されている位置情報などの情報を持つ．Lustre で
マウントするノード数の増加に伴いサーバに対する負荷
はこのメタデータを用いてデータが格納されている
が増大し，I/O スループットが低下してしまう．また，
位置を知ることができる．メタデータは MDS に
膨大な計算結果を出力するための受け皿となるストレー
よって管理されている．
近年，並列計算に用いられるクラスタが大規模化して
ジ環境が乏しいことなどが問題点として挙げられる．こ
• 実データ
のような問題を解決するためにクラスタ用のファイルシ
ステムとして開発されているのが，Lustre ファイルシス
物理的なデータのことを指す．Lustre のファイルは
テムである．本発表では，Lustre ファイルシステムの構
ストライピングされ，1 つのファイルを複数の OST
築を行い，性能を検討を行った結果を示す．
によって管理されている．
2
2.2
Lustre とは
データの格納方法
Lustre のデータ格納方法には RAID 0（ストライピ
Lustre とは Clustre File Systems, Inc. によって開発
ング）が用いられている．ストライピングを用いること
されているオープンソースの分散ファイルシステムであ
で，OST の増加に伴い I/O 性能が上昇する．例えばそ
る．これは既存のファイルシステムでは対応できないよ
れぞれの OST との帯域幅が 10MB/sec から 15MB/sec
うな大規模なクラスタなどのシステムで利用することを
に制限されている場合，8 台の OST を使うことにより，
目的として開発されている．Lustre の独自で近代的な設
計によって，既存ファイルシステムの操作性，可用性，
100MB/sec の実行スループットを満たすことになる．
Fig. 1 に Lustre においてファイル I/O の高速さを実現
スケーラビリティなどに関する諸問題を解決している．
している RAID 0 の構成を示す．
2.1
Lustre の構成
156
156
NFS の場合，クライアントがサーバに対してマウン
トする際にはサーバの情報やマウントするディレクトリ
%NKGPV
156
156
の情報が必要となる．サーバ側もクライアントのファイ
156
ル共有を許可する設定をしなければならない．このこと
Fig. 1 RAID 0 の構成
から，特定のサーバへの負荷が高くなる．したがって，
このような構成は大規模なシステムで何千ものクライ
3
アントが利用可能なシステムを構築するには不向きであ
OST の増加による I/O 性能の検証
3.1
る．Lustre ではこの問題の対処としてファイルをメタ
データと実データに分離し，それぞれを管理するサーバ
実験内容
2.2 節で述べた通り OST 数を増やすと I/O 性能が比
を用意することで負荷を分散させるシステムを構築して
較的上昇していくと考えられる．本実験では OST 数を
いる．以下に Lustre のファイルを構成するメタデータ
１∼４に変化させたときの I/O スループットの性能の
1
変化を検証した．I/O ベンチマークとしては bonnie++
FH
(KNGU[UVGOMDNQEMU7UGF#XCKNCDNG7UG/QWPVGFQP
FGXJFC‫ޓޓ‬
UJNNOQWPVUJ
FH
(KNGU[UVGOMDNQEMU7UGF#XCKNCDNG7UG/QWPVGFQP
FGXJFC‫ޓ‬
‫ޓ‬NQECNOPVNWUVTG
UJNNOQWPVENGCPWRUJ
FH
(KNGU[UVGOMDNQEMU7UGF#XCKNCDNG7UG/QWPVGFQP
FGXJFC‫ޓޓ‬
を使用した．
3.2
実験環境
実験に用いた PC を Table 1 に示す．
CPU
Table 1 Spec of PC
Intel Pentium
800MHz
メモリ
SDRAM 256MB
OS
Debian 3.0 Woody
ハードディスク
IDE HD20G
通信媒体
FirstEthernet
ノード数
3∼6
Fig. 2 テストスクリプトの実行画面
3.4
bonnie++
bonnie++はハードドライブのボトルネックテスト用
ベンチマークテストである．大量のファイルを作成する
3.3
ことで、パフォーマンスのテストを行なう．デフォルト
実験環境の構築
では Sequential Input/Output では 300M バイトのファ
まず，はじめに Lustre のホームページより以下の３
イルサイズを扱い，Sequential Create，Random Create
つをダウンロードする．なお，現時点での最新バージョ
では約 10 万のファイル (80∼100 バイト) を 10 ディレ
ンは 1.0.4 である．
・kernel-source 2.4.20-28.9 i586.rpm
クトリに作成し，全プロセスの平均値を求める．また，
実験に用いたパラメータを Table 2 に示す．
・kernel-smp 2.4.20-28.9 i586.rpm
・lustre-lite-utils 2.4.20-28.9 i586.rpm
Table 2 Spec of PC
ファイルサイズ
512M
ファイル数
16000
るため，RedHat 用の rpm パッケージを Debian 用の
操作時のサイズ
80∼100byte
deb パッケージに変換しなければならない．変換の際に
は alien コマンドを使用する．そして，インストールし
ディレクトリ数
10
操作時のファイル数
100000
今回の実験で使用するマシンの OS は Debian を用い
パッチをあてる．手順を以下に示す．
# alien kernel-source 2.4.20 28.9 i586.rpm
3.5
実験結果
sequential Input/Output の結果を Fig. 3 に示す．グ
# alien kernel-smp 2.4.20 28.9 i586.rpm
# alien lustre-lite-utils 2.4.20 28.9 i586.rpm
ラフの縦軸は転送速度 (Kbyte/sec), 横軸は OST の数
# dpkg -i kernel-source 2.4.20 29.9 i386.deb
である．転送速度が高いほど性能が高い．なお，図中の
# dpkg -i kernel-smp 2.4.20 29.9 i386.deb
# dpkg -i lustre-lite-utils 2.4.20 29.9 i386.deb
Create，Read，Delete はそれぞれファイルの作成テス
ト，ファイル情報の確認テスト，ファイルの削除テスト
である．
次に Lustre に必要なパッケージをインストールする．
ォㅍㅦᐲ
ォㅍㅦᐲ
-D[VGUGE
-D[VGUGE
必要なパッケージは libxml2，python-xml である．これ
らのパッケージは apt-get で入手できる．手順を以下に
示す．
# apt-get install libxml2
# apt-get install python-xml
C5GSWGPVKCN+PRWV
156ߩ୘ᢙ
D5GSWGPVKCN1WVRWV
156ߩ୘ᢙ
Fig. 3 result of sequentialInput & sequential Output
以上で Lustre 構築の準備は整った．準備ができてい
るかを確認するために１ノードに OST，MDS，Client
を設定するスクリプトが用意されているので，実行して
sequential Create，Random Create の結果を Fig. 4
みる．df コマンドで Lustre が構築されているかを確か
に示す．グラフの縦軸は転送速度, 横軸は OST の数で
める．実行結果を Fig. 2 に示す．
ある．転送速度が高いほど性能が高い．なお，図中の
2
Char，Block，Rewrite はそれぞれキャラクタベースの
書き込みテスト，ブロックベースの書き込みテスト，再
Create，Read，Delete はそれぞれファイルの作成テス
ト，ファイル情報の確認テスト，ファイルの削除テスト
書き込みテストである．
のである．
ォㅍㅦᐲ
ォㅍㅦᐲ
ォㅍㅦᐲ
ォㅍㅦᐲ
(KNGUGE
(KNGUGE
(KNGUGE
(KNGUGE
C5GSWGPVKCN+PRWV
E5GSWGPVKCN%TGCVG
D5GSWGPVKCN1WVRWV
F4CPFQO%TGCVG
Fig. 4 result of sequentialRandom & sequential Create
Fig. 6 result of sequentialRandom & sequential Cre-
3.6
4.3
ate
考察
考察
Lustre と NFS を比較すると NFS が性能が優れてい
Fig. 3，Fig. 4 の結果より，ノード数を増やしても比
例的に I/O パフォーマンスは上がらないことがわかった．
た．Lustre を構成すると，まず MDS に情報を問い合わ
bonnie++の結果では，Sequential Input/Output では
せしなければならないため Client と MDS 間のネット
少し上がるが，Sequential Create，Random Create で
ワークがボトルネックとなる．つまり，通信時間は NFS
はノード数を増やすにつれて I/O パフォーマンスが下
と比べると Fig. 7 のと
がる結果となった．これは Create,Delete の際には空き
この解決策としては，Client と MDS 間のネットワーク
容量を計算するからではないかと考えれる．この解決
インターフェースを高性能にして MDS との通信時間を
の通信時間が余分にかかる．
策として，Client と OST の間のネットワークインター
少なくすると考えられる．また，今回の実験では Client
フェースを高性能にすることが考えられる．
数が１であったため，今後 Client 数を増やして負荷を
4
分散できているか検証する．
Lustre と NFS の性能評価
4.1
実験内容
従来の NFS と比べて I/O パフォーマンスの性能評価
を行った．また，実験に用いたパラメータは Table 2 で
ある．
4.2
実験結果
sequential Input/Output の結果を Fig. 5 に示す．グ
ラフの縦軸は転送速度 (Kbyte/sec), 横軸は OST の数
である．転送速度が高いほど性能が高い．なお，図中の
Create，Read，Delete はそれぞれファイルの作成テス
Fig. 7 NFS & Lustre
ト，ファイル情報の確認テスト，ファイルの削除テスト
5
である．
まとめ
今回の実験ではネットワークインターフェースが重要
ォㅍㅦᐲ
ォㅍㅦᐲ
-D[VGUGE
-D[VGUGE
だとわかった．今後は，ネットワークインターフェース
を Gigabit Ethernet など高性能なものを扱い検証して
いく．
参考文献
C5GSWGPVKCN+PRWV
1) Lustre File System
http://www.lustre.org/
D5GSWGPVKCN1WVRWV
Fig. 5 result of sequentialInput & sequential Output
2) 2003 年度第 65 回月例発表会 Lustre File System 山口尚平
http://mikilab.doshisha.ac.jp/dia/monthly/monthly03/20040105/yamaguchi.p
sequential Input/Output の結果を Fig. 6 に示す．グ
3) bonnie++
ラフの縦軸は転送速度 (Kbyte/sec), 横軸は OST の数
http://www.textuality.com/bonnie/
である．転送速度が高いほど性能が高い．なお，図中の
3

Download Report