RAIDを導入する前に考えること

はじめに

実体験から学ぶことは多いわけで、ここではZFSのRAIDZで少々失敗したお話。ZFSでの話ではあるが、特にZFSに依存した話ではなく同様のハードウェアでRAID 5や6を構成すれば同じ問題が起きるはずなので、参考になれば幸いである。

事の起こり、RAIDZ2の導入

3年ぐらい前の話になるが、会社でUSB 3.0接続でHDDを5台入る筐体に1TB HDDを積んだものを用意してもらった。つまり総容量は5TBである。製品はセンチュリーの「裸族の集合住宅5Bay SATA6G USB3.0&eSATA Ver.2」で、インターフェースにはUSB 3.0の他にeSATAも用意されていたが、サーバー側にはeSATAは無いためUSB 3.0で接続した。

当時の要望として容量の面では1TBもあれば用が足りるため、5台あればRAIDZ2を構成しても3TB確保できることから、RAIDZ2として構成したのであった。

RAIDZ

ZFSではRAIDを構成する場合、RAIDZという名称を用い、一般的なRAIDに当てはめるとRAIDZはRAID 5、RAIDZ2はRAID 6に相当する。ここでRAID 5とRAID 6について簡単に説明する。

RAID 5やRAID 6では、ストレージデバイス（以下ストレージ）を一定サイズ（ここでは簡単のため1MBとする）のブロックに分割し、ストレージ台数分のブロックをまとめて（例：5台なら5MB）、パリティを割り当てて管理する。RAID 5はシングルパリティ、RAID 6はダブルパリティであるため、5台構成の場合、RAID 5ではデータ4MB＋パリティ1MB、RAID 6ではデータ3MB＋パリティ2MBとなる。この管理単位を各ストレージに分散配置し、書き込み時にパリティを生成、読み出し時にパリティを検証することで、データの整合性と冗長性を確保する。

RAID 5であればストレージが1台故障してもデータの継続性が保証され、RAID 6では1台故障してもデータ整合性は保証され、2台故障してもデータの継続性が維持される。

ただし、一般的なRAID 5や6では管理単位より小さいサイズの書き込みに大きなペナルティが発生する。例えば上記構成のRAID 6で1MBのデータを更新する場合、管理単位のデータ3MBとパリティ2MBを読み出し整合性を確認したうえで、更新後の1MBを含むブロック全体を書き戻す必要がある。つまり1MBの書き込みに対し、5MBの読み込みと同容量の書き戻しが必要になる。多くの場合、OSのバッファによりアプリ側の影響は小さいが、読み込みが必要になる点はパフォーマンス上無視できない。市販のRAIDシステムでは、大容量バッファメモリを搭載し、この性能低下を緩和している。

一方、ZFSのRAIDZでは管理単位を固定サイズではなく可変サイズとし、さらにコピー・オン・ライト方式で動作するため、書き込み時に既存データの読み出しを必要としない。このためRAIDZでは小さな書き込みでも大きなペナルティが発生せず、特別なバッファメモリを用いなくても実用上十分な書き込み性能が得られる。

データの読み出しが遅い！

ZFSの経験はそれなりにあるものの、RAIDZ2を利用するのはこのシステムが初めてであった。実際にRAIDZ2を使い始めてすぐに気づいたのは、一般的なHDDに比べてデータの読み出しに時間がかかるということである。

考えてみれば当然の話で、5台のHDDでRAIDZ2であれば、3MB分のデータを読み込むにはデータ分に加えてパリティ分2MBを読み出す必要がある。つまり単純に1台のHDDから3MBのデータを読み出すのに比較し、5/3(1.67)倍の読み出し時間が必要になる(パリティの計算時間はHDDのアクセス時間に比べると無視できる)。

5台のHDDそれぞれを並行で同時に読み出すことが出来れば大きなペナルティにはならないはずであるが、ここで使っているUSB接続のHDDでは1台づつ順番に読み出しているようである(観察に基づく推測)。SATAやSAS接続のHDDであればまた違った動作になる。

USB 3.0接続なのに根本的に遅い！

データの読み出しが遅いことは把握していたものの、一旦運用を始めたサーバーでは簡単に構成変更はできず、そのまま使い続けてきた。そして3年近く経過した半年ほど前の話になるが、HDDの筐体はそのままでサーバー側を交換することになり、新たなサーバにOSをインストールして、今まで使っていたものをそのまま接続した。

以前からサーバーではMacのタイムマシンバックアップを行っていたのだが新サーバーにはSATAで1TBのHDDが内蔵されていたので、ある日試しに内蔵HDDにタイムマシンバックアップを行ってみてその結果に愕然とした。1回あたりのタイムマシンのバックアップ時間が今までは30分～1時間、あるいはもっとかかっていたものが、ほんの数分程度(大部分が10分以下)で済むようになったのである。

タイムマシンのバックアップの挙動を観測すると、実際のバックアップデータの書き込み前に前回のバックアップとの比較と思われる大量の比較的小さなデータの読み出しが発生している。ここでRAIDでのHDD読み出しの挙動を考えてみると、5台構成のRAIDZ2(RAID 6)であればどんなに小さなデータを読み出す場合であっても5 台のHDDからの読み出しが必要となるのは明らかである。これに対して1台のHDDであれば、読み出しは1台分済む。

実際のデータの読み出しでは、HDDに対して読み込みのコマンドの発行とデータの取り込みが必要である。コマンドの発行に必要な時間と実際にデータ転送が始まるまでの時間をA、データの転送に必要な時間をBすると、データの読み込みに必要な時間は次のようになる。

1台のHDD	A + B
5台構成のRAIDZ2 (RAID 6)	(A' * 5) + B

これだけでも明らかに5台構成のRAIDは不利であるが、さらに使っている筐体のUSB 3.0とSATAでは A と A' の時間には大きな差があるように思える(機会があれば計測したい)。

USB 3.0のインターフェースの速度は 5Gbpsであり、SATAの6Gbpsと比較すると遅いとは言え、そこまで大きな差ではない。しかしこの筐体のUSB接続のHDDの場合、HDD自体のインターフェースはSATAであるため、内部でUSB⇔SATAのインターフェース変換をおこなっている。そのせいかどうまでは不明だが、USB経由のHDDアクセスのレイテンシは、SATAのレイテンシに比べて相当大きいのではないかと推測する。

結局どうしたの？

これらの現実を把握したこともあり、タイムマシンバックアップはサーバーの内蔵HDDだけで行うように変更した。それと共にRAIDZ2のHDD箱のデータを整理し、容量的にも問題ないので、4台のHDDを組み合わせてRAID 1+0に構成変更を行った。HDDが1台余るのでスペアHDDとして割り当てた。以前のRAIDZ2に比べると、読み書きのパフォーマンスは一回りよくなったようである。

まとめ

長文となってしまったが結局言いたいことは、こんなところだろうか。

この筐体をUSB接続でRAIDによる冗長性を確保する場合は、5や6は避けRAID 1つまりミラーで構成するのが得策である

その後

初めに書いたように当記事でのUSB接続はあくまでも「裸族の集合住宅5Bay SATA6G USB3.0&eSATA Ver.2」での話である。その後実際にこの筐体をeSATA接続で使用したところ、USB接続とはうって変わって十分なパフォーマンスを発揮しRAIDZ2で使ってもパフォーマンスはまったく悪化しないどころか、並行に動作するため台数を増やした場合のパフォーマンスの向上も確認できた。

実際に計測した結果は「ストレージインターフェースにおけるSATAとUSBの性能差」にまとめてある。