ハードウェアRAIDとLinuxカーネルによるソフトウェアRAIDのベンチマーク比較：Validation Case Study（1/3 ページ）

ソフトウェアの処理で行うソフトウェアRAIDと、高価なハードウェアRAIDカードとではディスクアクセスの速度はどれほど向上するのだろうか。ベンチマーク結果を基に、すこし硬派な検証を行ってみよう。

[Open Tech Press]

　ソフトウェアRAIDとハードウェアRAIDの双方について、750GバイトのSamsung SATAドライブ6台を使ってRAIDレベル5、6、10の各構成を評価した。パフォーマンスの測定にはBonnie++とIOzoneの各ベンチマークを用いた。また、チャンクサイズがハードウェアまたはソフトウェアのRAID構成に与える影響を確かめるために、チャンクの大きさを変えてベンチマークを実行した。

　ハードウェアRAIDの評価には、12ポートのAdaptec製SAS-31205 PCI Express RAIDカード（市価800ドル）を用いた。ソフトウェアRAIDの方は、64ビット版Fedora 9システムのLinuxカーネルによるソフトウェアRAID機能を対象とした。評価用マシンにはAMD Athlon X2（2.2HGz）プロセッサと2Gバイトのメモリが載っている。ソフトウェアRAIDを使ったファイルサーバなら、クアッドコアCPUや8Gバイトか16Gバイトのメモリを搭載していてもよさそうだが、前記マシンで得られたハードウェアRAIDとソフトウェアRAIDのパフォーマンスの相対的差異は、ほかのマシンにおける両者のパフォーマンスの違いを知る上でも参考になるはずだ。評価は、各パーティーションのサイズが同じ6台のハードディスクに分散させた100Gバイトほどの領域に対して行った。RAID作成の時間を短縮するために、空きディスクスペース全体を使うことはしなかった。

　テストマシンのマザーボードにはSATAコネクタが4つしかなかったので、6台のSATAドライブで評価を行うにはある部分で妥協が必要だった。そこで、1台のドライブをマザーボードのSATAコントローラーで評価した上で、AdaptecのRAIDカード経由でシングルディスクとしてエクスポートし、AdaptecのRAIDカードが単独ディスクへのアクセスに与える影響を確認した。その後、6台のHDDをAdaptecのRAIDカードに接続し、それぞれを単独の非RAIDボリュームとしてLinuxカーネルにエクスポートした。ソフトウェアRAIDの評価は、Adaptecカード経由でアクセスされる、これら6つの単独ボリューム上にRAIDを作成することによって行った。

　6つのディスクボリュームをAdaptecカード経由で用いる利点は、RAIDの実行にハードウェアRAIDチップを使った場合とLinuxカーネルを使った場合を直接比較できることにある。どちらの場合も、各ドライブが接続しているSATAコントローラーは同じものだからだ。マザーボードのSATAコントローラーを使用する場合とAdaptecカードのものを使用する場合のそれぞれでシングルディスクアクセスのベンチマークを取れば、SATAコントローラーの違いによる影響が分かる。幸いなことに、単独ディスクへのアクセスに関しては、どちらのコントローラーにも特に大きな利点はない。よって、6台のディスクに個別にアクセスし、その上でソフトウェアRAIDを実行した場合の数値は、ほかのSATAコントローラーを使った場合と大きく異なることはなさそうだ。Adaptecカードを使って単独のボリュームにアクセスした場合とオンボードのSATAコントローラーを利用した場合のパフォーマンスの違いが分かったので、以降ではハードウェアRAIDとソフトウェアRAIDのベンチマークの差に注目できる。

　今回の評価には、ext3とXFSの両方のファイルシステムを使った。これらのファイルシステムの作成は、可能な場合にはRAIDのチャンクとストライドを指定して行った。また、マウント時のオプションとしてext3にはwritebackとnobh、XFSにnobarrierをそれぞれ使用した。書き込みバリアを使うとAdaptecカードの時間的ペナルティが非常に大きくなりそうなので、AdaptecカードでXFSを使用するなら、書き込みバリアは使わずに、UPSとバッテリーバックアップを使ってメタデータを保護するのが賢明だ。こうした割り当てオプションに加えて、XFSファイルシステムの作成では「lazy-count=1」を指定した。これにより、ファイルシステムのスーパーブロックに対する書き込み競合が減少する。

　以下に示すグラフの凡例を理解するには、各ファイルシステムの作成条件について知っておく必要がある。“hard”で始まっているものはすべてハードウェアRAID構成である。例えば、“hardext3aligndef”は「-E stride」を使って作成され、特別なオプションを使わずにマウントされたext3ファイルシステムであり、“hardext3alignwb”は「data=writeback,nobh」オプションを使った点だけが“hardext3aligndef”と異なる。また、 “xfsdefaultnb”というXFSファイルシステムは「lazy-count=1」で作成され、「nobarrier」オプションでマウントされたもの、“hardxfsalign”は特定のRAID構成に対してストライドとチャンクサイズを指定した点以外は“xfsdefaultnb”と同じもの、“xfsdlalign”はXFSジャーナルにストライプ割り当てを使用した点が“hardxfsalign”とは異なる。ソフトウェアRAIDの場合は、“ext3”がハードウェアRAIDの“ext3alignwb”の構成に相当し、“xfs”、“xfslogalign”はそれぞれハードウェア RAIDの“hardxfsalign”、“hardxfsdlalign”に当たる。

　各グラフから分かるように、XFSファイルシステムをストライプ境界に割り当てると、作成や削除といったファイルシステムのメタデータ操作の速度がかなり違ってくる。構成のバリエーションをブロック転送のグラフでも示したのは、こうしたファイルシステムのパラメータの影響がメタデータ操作だけでなくブロック転送速度にも現れるからだ。なお、グラフは載せてあるが、本稿ではメタデータ操作のベンチマークについては詳しく取り上げない。明らかに分かるのは、ハードウェアRAIDの場合はext3でのランダム生成および削除の操作がかなり高速なことだ。