Ceph
2.6.34からLinus treeに統合されたので、どんなもんか調べてみた
Cephというのは分散ファイルシステムであるらしい。特徴としてはスケーラビリティであるようだけど、他の実装との違いはストレージノードにOSDを使っていることのようだ。
OSDとは何ぞや
http://www.ibm.com/developerworks/jp/linux/library/l-nilfs-exofs/
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch06a.html
この2つの記事に非常にわかり易い説明があるので、もはや追加するべきものはないのだけど。
ファイルシステムが実際にディスクにデータを記録するためには以下のような4つの空間での情報のマッピングを行なっていると思う。
- ファイルシステム的なパス空間
- inode番号空間
- ディスクブロック単位での空間
- 媒体上の記録空間
一般的なディスクではブロック単位でアクセスするので、抽象度としては一番下の部分だけを面倒見ることになる。OSDとはそれより一つ上の任意のサイズの塊(オブジェクト)単位でのアクセスが可能なデバイスだそうで、やや高級なストレージ製品などでは直接OSDを話すデバイスもあるそうな
上記の記事でもある通り、OSDを下のレイヤとして使ったファイルシステムとしてEXOFSというものがありこちらは2.6.30で統合された。こちらはCephと違い通常のローカルファイルシステムのみ。OSDをバックエンドにする薄いレイヤと聞いて読んでみたが、中々にボリュームがあって雰囲気しか分らなかった。スーパーブロックが他のファイルシステムと比較して極端に簡素な内容しか無いのはかなり印象的。
OSD自体は64bitのフラットな番号空間とその中身を持つので、実質はinode番号から先の実装はデバイス側に丸投げできてしまうようだ。ファイルシステムとしてはパスの階層構造やら権限周りだけを見ていればいいことになる。
OSDの実装
OSD自体がSCSIの拡張として標準化されただけあって、ホスト側のイニシエータとデバイス側のターゲットがあるのだがカーネルでサポートしているのはとりあえずイニシエータだけ。
SCSIが媒体を選ばないように本来であれば、FCやSAS経由でのOSDというのもあり得るのだけど、とりあえずiSCSIをトランスポートとする動作のみのサポートらしい。
http://www.open-osd.org/bin/view/Main/OscOsdProject
Ceph
で、ようやくCephの話
ストレージノードをOSDにしてしまう事で実装する範囲がぐっと限定されるようになっているのは上手いと思った。メタデータ操作などはCephのメタデータノードと行い、実際のファイルI/OはOSDとやりとりするのでパフォーマンスもそこに依存しそうに見える。
ストレージノードとして動くOSDのdeamonはCephのパッケージの中にも独自の実装(cosd)があり、ローカルストレージとしてbtrfsを使いつつそれをosdとして見せるような動きになる。
ノードの動的追加や、ノードが持つデータの再配置、冗長度を指定しての構成など一般的な分散ファイルシステムに求められるものは一通り揃っているようだ。
ストレージ全体をAmazon S3互換のAPIで見せるゲートウェイの実装なんかがあるのは面白い。
http://ceph.newdream.net/wiki/FAQでは他の実装に比べてのメリットとして、「もっとスケールする、簡単な導入、再帰的なディレクトリstat、近々ディレクトリ単位でのスナップショット」「Lustreはレプリケーション無いよね。他のノードへのフェイルオーバーがあるだけで」と言っている。
OSDを使ったことでストレージノードの調達が楽になったり、複数の実装から選べる未来が来るとかなり有力になっていくのではないかなと思った。
