SSDをどう使うか
そろそろ、SSDをサーバサイドで使う方法についてちゃんと検討したい。
高いIOPS
15000rpmのHDDでおよそ150から300ぐらい。SSDでは読み込みで数万、書き込みで数千程度。ベアドライブでは10倍から300倍ぐらいの速度差がある。
読み込みではどのドライブもHDDと比べて桁違いに速いが、書き込みは製品によって千差万別。安価なものはHDDよりも遥かに遅いものも多いようだ。
4KB読込みで35,000 IOPS以上、4KB書込みで3,300 IOPS
http://japanese.engadget.com/2008/08/21/x25-m-x18-m-sata-ssd/
IntelのSSDは従来のSSDより頭一つ飛び抜けている印象なので、検討するとしたらこれかこれへの対抗機種だろう。
According to Sun, a 146GB disk drive with 15,000 RPM gets about 180 write IOPS and 320 read IOPS, while a 32GB flash drive gets 5,000 or more write IOPS and at least 30,000 read IOPS.
http://www.bigdbahead.com/?p=53
最も目を引く数字は、IOPS（I/O per Second：1秒間当たりのI/Oの回数）が、1万5,000回転のハードディスクに比べて30倍も大きいという点だ。
http://www.computerworld.jp/topics/storage/95309.html
SSDは，HDDよりIOPSが10倍〜50倍と高いことから
http://techon.nikkeibp.co.jp/article/NEWS/20070919/139313/
さらにSASディスクのおよそ倍の、1台でおよそ360IOPS（64KB時）を発揮する
http://katuyou.dospara.co.jp/archives/51491761.html
現在入手可能な組み合わせでのベンチマークなので、気になる結果。
低消費電力
先日発表になったIntelのSSDとSeagateのES2 seriesの比較
| active | Idle | |
| Intel MLC | 0.15W | 0.06W |
| Intel SLC | 2.4W | 0.06W |
| Seagate ES2 | 11.6W | 8W |
かなり圧倒的。MLCとならば100倍近く差がある。
信頼性
やはり同じくIntelのSSDとSeegateのES2 Seriesの比較では、以下のようになる
| MTBF | Read Error Rate | |
| Intel MLC | 120万時間 | 1 sector per 10E15 |
| Intel SLC | 200万時間 | 1 sector per 10E15 |
| Seagate ES2 | 120万時間 | 1 sector per 10E15 |
http://journal.mycom.co.jp/articles/2008/09/09/x25m/index.html
http://www.seagate.com/www/en-us/products/servers/barracuda_es/
エラーレートでは同等。MTBFではSLCの物を使えば、現状のディスクよりもやや信頼性が高いぐらい。
ちなみに一般的なSATAのディスクでMTBFは40万から60万時間程度。
高いビット単価
HDDは安いものなら10円/GBから有る。Intelが出したSSDならば、800円/GB以上。但し、これは高性能なSSDと低性能なHDDの比較なので、高性能なHDDでの比較ならば5倍程度まで差は縮まる。
| Gbyte単価 | ||
| Intel MLC | 850円 | |
| Intel SLC | 不明 | |
| Seagate ES2 1TB | 21円 | |
| Seagate ES2 250GB | 30円 |
SSDとファイルシステム
既存のファイルシステムでは比較的小さなサイズのブロックサイズ(4kBとか)を使うが、これはNAND型フラッシュの素子自体のもつ管理方法とは相性がよくなさそうである。できればもっと大きめの管理単位で扱った方が削除や上書きのさいに効率が良いだろう。
また、NAND型フラッシュは書き換えをメディア全体で平滑化するような仕組みで管理している。これに対しては@ITでのLinux Kernel Watchに気になる記事があった。つまりはOS側からデータを破棄したことをデバイス側に明示的に情報を渡してやろうと言うもの。まだ議論が始まったばかりで実装はまだのようだが、確かにこういった仕組みが導入されればパフォーマンスと寿命の点でも非常に期待できそう。
詳細は不明だが、ZFSはSSDに最適化した実装があるらしい。
OpenSolarisコミュニティーを通じてSSD向けに最適化したZFSを提供している
http://www.itmedia.co.jp/news/articles/0806/05/news047.html
SSDの故障
現在、HDDの監視にはよくS.M.A.R.T.を使うが、SSDでも同様だろう。但し、現在取得可能な標準的なパラメータはHDDでの監視に有用なものを中心に揃えられているので、SSDでは独自拡張するか別プロファイルのようなものを定義する必要があるかもしれない。
故障のパターンもHDDのときとは異なってくるだろう。ざっと思つくのは以下のような死に方。
- 全体が見えなくなる
- あるセクタが突然見えなくなる
- 書き込みだけ失敗する
- データが化ける
RAID1で対応するなどで対応可能なのか。ビザンチン障害になってしまうので、単純な多重化では対応ができないのか。
SSDの応用分野
RDBMSのストレージ
ランダムアクセスへの強さから非常に有利。書き込みと読み込みの比率などによって、どの程度パフォーマンスが出るかが大きく変わりそう。
データの本体だけを置くかや、インデックスのみを置くかなどの選択肢があるが、サイズや性能が許すならば全てSSDに置いた方がいいだろう。一方を置くとするならば、データ本体の更新よりもインデックスの更新の方が少ないことやデータサイズの関連からインデックスのみを置くというのも有りだろう。
一部のサーバではIOPSを稼ぐためだけに小さなディスクを大量に抱えるような構成にすることもあるので、こういうった構成には非常に効きそう。
http://www.bigdbahead.com/?p=37
このページでは、色々な指標でMtronとRaptorを比較していて面白い。Raptorは10000rpmのSATAとあるのでWD RaptorR Xとかだろう。RD/WRの比率を変えたベンチマークとかDBを置いてのベンチマークなどを行っており。読み込みだけならRaptorの30倍以上速いケースもある。読み書きを混ぜると、どんどん差が縮まり、5:5だとややMtronが速いぐらい。全部書き込みなら、Raptorの方が速い。
やはり書き込みが少ない用途や減らせる用途が最適だろう。
squidのストレージ
やはりランダムアクセスへの強さから有利。変化の少ないコンテンツをキャッシュするときや追記を止めた状態で運用すると有利かも。
squidではサイズ固定の単一ファイルでディスクに記録するCOSSをストレージとして使うときに、ブロックサイズが指定できる。フラッシュベースのSSDならば、小さなサイズでの書き換えが内部的に大きなブロックでの書き換え処理になってしまうので、管理ブロックは大きめ(128kbなど)にしておくといいだろう。
一次ストレージとして
HTTPで配るstaticなファイルを置くなど。主記憶のキャッシュが大きくなってきているので、使いどころはサイジング次第か。
SSDとスケジューラ
SSDはHDDでの平均回転待ち時間に相当する時間が非常に短かい。HDDでは7200rpmで8ms、15000rpmで4ms程度だが、SSDのカタログスペックでは100usを切るものも有る。
現在のI/Oスケジューラはアクセスへの遅延が非常に大きいことを前提に書かれているので、それらの仮定が成り立たない条件では色々とやり直す必要がありそう。
Linuxでは現在CFQ(Completely Fair Queuing)というスケジューラが使われているが、これは複数同時に発行されるI/O要求を優先度に従って公平に処理が完了するよう並べ替えを行うものだ。HDDではIOPSが貴重な資源であるし、発行してから完了までの時間が長いのでそういったスケジューラのアルゴリズムは意味があったが、SSDではあまり意味はないかもしれない。いっそ単純に要求された順でI/Oを発行するnoopにした方が性能面では有利かもしれない(要検証)。
http://wiki.bit-hive.com/linuxkernelmemo/pg/I%2FO%A5%B9%A5%B1%A5%B8%A5%E5%A1%BC%A5%E9
http://www.valinux.co.jp/contents/tech/techlib/eos/cfq/cfq_01.html
SSDとキャッシュ
フラッシュベースのSSDは、いくら速いといってもDRAMほど速いわけではないので、相変らずキャッシュは有効だろう。
そこそこいいコントローラならカード上にRAMを載せられて、バッテリーバックアップと合わせてライトバックキャッシュが使える。設定によってはリードとライトの比率を変えたりもできる。SSDはライトが遅いので、ライトに振り分けるべきだろう。HDDに対するライトバックキャッシュの意義はランダムアクセスとシーケンシャルアクセスの差が大きいため、キャッシュ上でライト要求を上手くマージすることで高速化が図れる。ところがSSDではランダムとシーケンシャルアクセスで性能差があまり大きくないため、その効果は期待できないかもしれない。
バースト的に書き込みがあったり、同期書き込みするようなケースにはよいかもしれない。
SSDのベンチマークはよく見掛けるが、HDDで使うようなインテリジェントなコントローラと組み合わせた結果はあまり見掛けない。
