#はじめに
Ceph の性能については、今までに様々な分析やチューニングを行なった結果がネット上に公開されておりますが、中には(古くなって)現在は当てはまらないものや誤解を与えるものが多いと思います。
少し前に、Ceph community 向けに Anthony D'Atri さんがとても良いドキュメントを公開されていたので、紹介させていただきます。
次のドキュメントを読めば、Ceph の Performacne に関する考え方、ベンチマーク方法や Tuning の勘所が確実に理解できます。ドキュメント内で考察されている内容についても、私が実際に Ceph を運用して得られた知見とほぼ合致しており、妥当だと考えられます。
また、SSD に関する情報については mysql や postgress 等、transaction を多用するアプリでも同様の考え方ができるはずなので、もし RAID + SSD を使っているのに RDBMS の性能がイマイチ低いと感じている人があれば、確認されると良さそうです。
#ドキュメントのまとめ
忙しくない人は前記のドキュメントを隅々まで読むことをお勧めしますが、時間のない人のために、重要なポイントを次にまとめさせていただきます。
-
Ceph(RBD) は遅いのか?
- All-HDD、または HDD+SSD の組み合わせで使う分には十分に性能が出る
- Sequential Read/Write については、All-HDD, HDD+SSD, All-SSD 全てについて十分に性能が出る
- Random Read/Write については、All-SSD にしたとしても SSD のポテンシャルに見合う性能が出ない
-
All-SSD にしても十分な性能が出ないのは何故か? (その1)
- ceph-osd は ソフトウェア側で消費する I/O処理時間(latency) が大きいため、SSD を使っても IOPS 性能が上がらない
- read latency: 0.5ms, write latency: 1ms
- IOPS に換算すると、read: 2000 IOPS, write: 1000 IOPS
- DBMS のように single thread にて fsync 等を用いた同期 read/write を多用するアプリについては latency の影響を大きく受けるため、Ceph(RBD)だとあまり良い性能が出せないことになる
- ceph-osd は ソフトウェア側で消費する I/O処理時間(latency) が大きいため、SSD を使っても IOPS 性能が上がらない
-
All-SSD にしても十分な性能が出ないのは何故か? (その2)
- Ceph では全ての書き込みを Transactional として処理することにより、高いデータの一貫性を実現している
- ただし、高い一貫性を得られることの引き換えに、write の度に fsync(または sync) が実施されるため、SSD によっては大幅な I/O 性能低下を引き起こしてしまう
- Supercapaciter が内蔵されている SSD の場合は Disk の Write Cache を Disable にすることにより、fsync による性能低下を抑止できる可能性がある
#Hardware RAIDの闇
高性能な SSD を使う場合は Hardware RAID を使うことにより発生するデメリットがあるため、影響を十分に調査をしておく必要があります。
前述のドキュメントからも言及されていた、参考情報のリンクを次に記載します。
-
New best practices for OSDs?
-
All-SSD で Hardware RAID を使うべきか?
- 結論: (どうしても必要な要件がない限りは)使用を避けるべき
- RAID機能が内蔵されている controller の場合は、JBOD (または pass-through) に設定する
- JBOD設定が無い場合は、firmware の update で対応できる場合もある
- どうしても設定変更ができない場合は、HBA に買い換えるべき
Hardware RAID を使うことで被るデメリットとしては、次のようなものが挙げられます。
- RAID Controller 自体が IOPS 性能の観点でボトルネックになる
- SSD の単体性能が飛躍的に向上したため、特に 5台、10台以上のように沢山の SSD を1ホストで束ねる場合は RAID Controller 側でボトルネックが発生してしまう
- Write Cache を有効化して 1-2 年運用したら、気づかないうちに Battery Backup Unit (BBU) のバッテリーが消耗して機能が無効になっていた
- バッテリーを交換するためには shutdown が必要になり現地作業も伴うため、運用コストが大きくなってしまう
- 突然 RAID Controller の reset が発生し、I/O が刺さった
- 余分なものが挟まれていなければ、避けられたはずの事象
- RAID Write Hole のリスク
- 突然の電源停止が発生した場合、RAID として書き込まれたデータの内容が壊れる可能性がある
- 緩和策としては、定期的な Consistency Check の実施や BBU の搭載が挙げられるが、Ceph のように上位レイヤで consistency を担保できる場合はそもそも必要無い
- smartctl で disk の情報を取得するのに、余分な手間がかかる
- 予め Device Id の mapping 情報を調べておく必要がある
少なくとも Datacenter Grade の SSD を使用できる場合は、Hardware RAID の代わりに Linux MD または ZFS(ZRAID) の使用を検討する価値がありそうです。
参考情報として、Hardware RAID と Software RAID どちらを使うべきかについて示唆が得られる情報を次にまとめておきます。
-
Software vs hardware RAID performance and cache usage
- 最近はCPU の処理性能が高まっているので、RAID計算処理をオフロードする観点での Hardware RAID は不要
- SSD を使うのであれば Software RAID の方が良い
- ただし、synchronized random write を多用する場合は Datacenter グレードの製品 (powerloss-protected SSD) を選びましょう
- Improving software RAID with a write-ahead log
- A journal for MD/RAID5
#さいごに
Disk の Write Cache を Disable にすることにより random write 性能が劇的に向上するという事実は直感と真逆になると思います。前述のドキュメントに原因の考察が書いてあるので興味のあるひとは熟読してみると良いと思います。
Ceph の Tuning に関する考え方は、Ceph に限らず Transaction を多用するアプリであれば応用できるはずです。SSD の性能が十分に引き出せていないと感じる場合はチェックをしてみると良さそうです。