しかし、この構成はまったく性能が出ませんでした。負荷がほぼ100%のときにディスクアレイ1基あたりで約20MB/sしか出ません。1基20MB/sなら2基合わせて40MB/s、ビットにすると320Mbps、ARCの助けを借りても、ftp.jaist.ac.jpの出力帯域は450Mbpsがいいところでした。これではSun Fire T2000が宝の持ち腐れです。
その前に運用していたftp.jaist.ac.jpには、少し玉の小さい同じ型のディスクアレイを1基つないでいました。構成は7D+1Pと6D+1PのRAID 5に共有のスペアを一つです。これで約80MB/s出てましたし、出力帯域も750Mbpsくらいありました。このときのファイルシステムはUFSでした。
そこで、Sun Fire T2000にこのディスクアレイを追加して、14D+1P+1SでRAID 5を組んでUFSで運用したら80MB/s以上出ました。この結果を見て、ZFSはだめな子だから捨てて、すべてUFSにするべきなのではないかと思いました。でも、だめだったのはZFSではなくて、RAID 5でpoolを作ったことだったんです。
ZFS Best Practices GuideのGeneral Storage Pool Performance Considerationsには、「別々のディスクか、少なくとも数個のディスクからなるLUNを使え。ZFSからLUNの構成をよく見えるようにすると、ZFSはI/Oスケジューリングをよりうまく行える。」とあります。
RAIDの上に作られたZFSの性能が出ないことを示すベンチマークもいくつかあります。
- ZFS Performance Versus Hardware RAID
- ZFS, XFS, and EXT4 filesystems compared
- HW RAID vs. ZFS software RAID - part II
このことは知ってはいたのですが、まさか何倍もの差をくつがえすようなことにはならないと思っていました。
とりあえず一度やってみようということになり、UFS側のディスクアレイのRAID 5をやめてディスクに全部LUNを振ろうとしたのですが、コントローラの都合でできませんでした。そこでディスク2本ずつでRAID 0を8つ組んで、vdev 8個でRAID-Z2を組みました。14D+1P+1SのRAID 5は、いつ壊れるか気が気ではなかったので、今回はダブルパリティにしました。
ベンチマークを取ったところ、ランダムリード、シーケンシャルリードともに、RAID 5上のZFSと比べて2倍近い性能が出ました。実運用でもリードで40MB/s程度は出ています。残念ながらUFSの80MB/sには及びません。このディスクアレイのコントローラは、相当ZFSと相性が悪いようです。
残りの2基を同じ構成にしても全部合わせて120MB/sです。4Gbpsのネットワーク帯域を埋めるにはぜんぜん足りません。でも今はSSDのキャッシュと巨大なARCがありますから、ディスクの性能はあまり問題ではありません。
RAID-Z2はソフトウェアRAIDなので書き込み性能が気になるところですが、コントローラによるRAID 5より速いです。書き込み中のCPUの負荷はほとんどありません。ダブルパリティを計算しているとは思えないほどです。
ZFSで注目すべきは、その信頼性です。実は数日前にRAID-Z2を組んだディスクアレイのバックプレーンが故障しました。ディスクアレイのログにそれらしいエラーメッセージはあったのですが、コントローラでディスク障害が検出されることはありませんでした。
しかし、ZFSがチェックサムエラーで異常を検出して、vdevを一つフォルトにしてpoolをデグレードしました。このときの警告で、我々はディスクアレイの異常に気付きました。ZFSのEnd-to-Endのチェックサムは、RAIDコントローラで検出されない障害も検出できます。
性能だけでなく信頼性の点でも、ZFSにはRAIDコントローラを介さずにディスクを直接見せるべきです。これは規模にもよりますが、ZFSを利用できるシステムのストレージは、我々がSSDを増設したときに作ったようなディスクエンクロージャを、RAIDコントローラのないHBAでつなぐのがいいです。RAIDコントローラはいりません。
0 件のコメント:
コメントを投稿