特集
» 2009年01月29日 08時00分 公開

Linux Hacks:リモートファイルシステムを使ってRAID1を構成できるChiron FS (2/2)

[Ben Martin,SourceForge.JP Magazine]
SourceForge.JP Magazine
前のページへ 1|2       

パフォーマンス

 NFSレプリカが1つだけの前記の設定を用いて、ベンチマーク評価を行った。このテストでは、Chiron FSを実行しているマシンと別のマシン「p1」の両方をIntel Core 2 Quad Q6600 CPU上の仮想マシンとして動作させる。この物理マシンはハードウェア仮想化の機能を持つため、仮想マシン内部の実行パフォーマンスを示す数値は主として2台の仮想マシン間のネットワーク接続の影響を受けることになる。どちらの仮想マシンも同じ物理ハードウェア上で動作するので、理論的には、仮想化によって実際より高いパフォーマンスが得られると考えられる。また、仮想マシン内におけるファイルシステムへのローカルなアクセスとNFS経由のアクセスを数値で比較すると、このベンチマーク評価にはネットワーク利用の有無が大きく影響することが分かる。ただし、すべてのテストを同じ仮想マシン上で実行すれば、それらのパフォーマンスの相対比較によって、実環境におけるパフォーマンスの違いがだいたい予測できるはずだ。

 テストではまず「/noaccess/raw」を使って、Chiron FSによってレプリカが格納されるのと同じファイルシステムにこのマシンがどれくらい速くアクセスできるかを測定する。続いて、「/noaccess」内の2つのローカルレプリカで構成された「/data-localonly」を使って測定を行う。Chiron FSによってこの「/data-localonly」というファイルシステムを用意したのは、ベンチマーク評価から仮想ネットワーク接続の要因を取り除くためである。さらに、ネットワークを利用した場合のChiron FSの評価には「/p1export」にマウントされたNFS共有フォルダを用いる。以下に、評価の結果を示す。

ファイルシステム 構成(ローカル/NFS) 展開(秒) 削除(秒)
/noaccess/raw ローカルのカーネルファイルシステム×1 20 0.6
/data-localonly ローカルのカーネルファイルシステム×2 42 5.4
/p1export NFSファイルシステム×1 90 20
/data ローカルのカーネルファイルシステム×1
およびNFSファイルシステム×1
150 25

 ご覧のように、Chiron FSによる「/data-localonly」でのファイル展開には、それぞれのローカルファイルシステムをそのまま使った場合の2倍近い時間がかかった。また、NFSファイルシステムではローカルファイルシステムに比べてアクセス速度がかなり低下する。NFSによるこのパフォーマンス低下は Chiron FSの「/data」にも影響しており、ローカルファイルシステムとNFSファイルシステムそれぞれの単独のアクセス時間を足し合わせた値よりも多くの時間がかかっている。これらの結果から、低速なレプリカファイルシステムが1つでもあるとChiron FS全体のパフォーマンスがいちじるしく低下することが分かる。

 続いて、レプリカの一方(ここではNFSファイルシステム)が他方(ローカルファイルシステム)よりも低速であることをコロン(:)オプションによって明示的にChiron FSに伝えた場合の効果を確認するために、Linuxカーネルのtarballを展開しておき、「/data」と「/noaccess/local-mirror」の両ディレクトリからそれらのファイルを参照する評価も行った。なお、コロンオプションは読み取りのパフォーマンスにしか影響しないはずである。書き込みの方は、その性質上、すべてのレプリカに対して実行しないとデータの整合性を維持できないからだ。こちらのテストでは、Chiron FSである「/data」ディレクトリがローカルファイルシステム「/noaccess/local-mirror」とNFSファイルシステム「/p1export」で構成されている。「/data」でのtarballの作成には30秒近くかかったのに対し、「/noaccess/local- mirror」の場合は6秒ほどしかかからなかった。また、NFSファイルシステム(/p1export)上で直接tarballを作成してもやはり30秒ほどかかった。「/data」でも「/p1export」でも同じくらい時間がかかったことから、コロンオプションは今のところ無視されているか、あるいはわたしのやり方がまずいためにこのオプションが機能せず、読み取りの操作が双方のレプリカに対して行われているかのどちらかだと考えられる。

まとめ

 Chiron FSの使用時には、カーネルの展開済みソースファイルすべての削除に相当な時間がかかった。耐えられないほどの長さではないが、その時間の差は歴然としている。一方、カーネルのtarballを展開するのに要した時間は、2つのローカルファイルシステムで構成されたChiron FSの使用時で通常の2倍ほどであり、ファイルの展開と書き込みの場合はChiron FSによるパフォーマンスのオーバーヘッドはそこまで大きくならない。また、Chiron FSにおける書き込みでは常にディスクへの書き込みが2回必要になるため、Chiron FSによるtarball展開の速度が大幅に向上することもない。ただし、Chiron FSの一方のファイルシステムをNFSマウントした場合は、NFSサーバによる書き込みの遅さがかなり効いてくる。

 現行のChiron FSでは、特定のレプリカを書き込み専用にできるはずのコロンオプションが働いていないようだ。この機能が有効になればNFSサーバからの読み取りを避けるように指定できるので、読み取り時のネットワークトラフィックの増加を防ぎ、書き込み時のパフォーマンス低下を抑えることができる。現状のNFSのパフォーマンスに不満がなければ、Chiron FSを使っても動作速度が大幅に低下することはないので、ファイルシステムの可用性の向上とハードウェアの故障に対するある程度の備えがわずかなコストで可能になる。

Ben Martinは10年以上前からファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティング業務に従事。


あなたが知らないLinux環境のだいご味をそっと教える「Linux Hacks」も合わせてどうぞ。


前のページへ 1|2       

Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ