Ceph のプロセス配置ベストプラクティス

Ceph はブロック型の分散ストレージファイルシステムです。POSIX のファイルシステ ムとしてマウント出来ます。Linux の Kernel ドライバや FUSE ドライバを用いてマウ ントします。またブロックデバイスとしてマウントする方法もあります。

だいぶ前ですが、Ceph に関する記事を以前下記の通り書きました。

• http://jedipunkz.github.io/blog/2013/05/25/ceph-cluster-network/
• http://jedipunkz.github.io/blog/2013/05/11/ceph-deploy/

Ceph の構築方法について記したブログだったのですが、今まで mon, osd, mds の各プ ロセスをそれぞれ何台のノードに対して配置し、またそれぞれのプロセス幾つを何に対 して配置するのか？という疑問が付きまとわっていました。node, disk, process のそ れぞれの数の関係について知りたいなぁと思っていました。幾つかのドキュメントを読 んでいて、ぼんやり見えてきた事があるのでそれを今回はまとめたいと思います。

また、皆さん気になるトコロだと思われる容量設計についても軽く触れたいと思います。

参考資料

• http://ceph.com/docs/master/rados/configuration/mon-config-ref/
• http://www.sebastien-han.fr/blog/2013/12/02/ceph-performance-interesting-things-going-on/

各要素の数の関係

ハードウェア要素である node, disk(hdd), ssd そしてソフトウェア要素である mon, osd, mds の数の関係はどのようにするべきか？基本となる関係は

• 1 mds process / node
• 1 mon process / node
• 1 osd process / disk
• n jornal ssd device / disk / node

だと考えられます。僕が今のところ理想かなぁと思っている構成をまとめたいと思いま す。

下記の図がそれです。

+------------------------+
|         client         |
+------------------------+
|
+--------------------------+--------------------------+-------------------------------+-------------------------
|                          |                          |                               |            public network
+------------------------+ +------------------------+ +------------------------+      +------------------------+
|          mon           | |          mon           | |          mon           |      |          mds           |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+      +------------------------+
| osd  | | osd  | | osd  | | osd  | | osd  | | osd  | | osd  | | osd  | | osd  |      |                        |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+      |                        |
| disk | | disk | | disk | | disk | | disk | | disk | | disk | | disk | | disk |....> |                        |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+scale |          node          |
|          ssd           | |          ssd           | |          ssd           |      |                        |
+------------------------+ +------------------------+ +------------------------+      |                        |
|          node          | |          node          | |          node          |      |                        |
+------------------------+ +------------------------+ +------------------------+      +------------------------+
|                          |                          |                               |
+--------------------------+--------------------------+-------------------------------+-------------------------
                                                                                                  cluster network

mds と node の関係

mds はリモートクライアントへのファイルシステムサービスの提供を行うことや特性が 全く異なることから別ノードに切り出しました。また mds は幾つかのノードで稼働さ せる事も可能。が、mds はそれぞれのサービスを HA 組む仕組みは持っていないので どれか一方の mds をクライアントは指し示す必要があり、その mds が停止すれば直 ちに障害に発展します。

mon と node の関係

mon は比較的少量のリソースで稼働します。今回 osd と同じノードの搭載しましたが 別ノードに切り出すことも勿論可能です。mon は CRUSH Maps アルゴリズムの元に連携 が取れますので複数のプロセスを稼働することが推奨されていることからも、比較的少 ないノード数のクラスタの場合は osd と同ノードに搭載するのが容易かなと考えまし た。

osd と node の関係

1 osd プロセスに対して 1 disk が基本となります。osd は実データのレプリケーショ ンを行うことからコンフィギュレーションに対して上図の様にクラスタ用のネットワー クを紐付け、高トラヒックに対応する必要があります。また osd 用の disk device で すが RAID を組まないことが推奨されています。CEPH 自体に HA の仕組みがあること、 また RAID 構成にもよりますがディスクアクセスが遅くなることは Ceph にとってボト ルネックを早く招くことになりますし、小さいディスク容量しか扱えなくなることは Ceph にとって不利になると思います。

journal 用の ssd device と disk, node の関係

現在の Stable Release 版の Ceph は journal を用いてメタデータを管理します。各 osd の disk 単位に journal 用の disk device を指定出来るようになっています。メ タデータですので実データ用の disk よりだいぶ小さな容量で構わないこと、また比較 的高速なアクセスを要求されることからも SSD を選択することが推奨されつつあるよ うです。実際にストアされるデータの特性にもよりますが 1 node に対して 1 ssd device を配置すれば十分かと思います。また osd のプロセスの数 (disk の数) に対 して一つのパーティションを切ることで対応出来るかと思います。

設定方法の例を記します。ここに ceph01-03 の3台のノードがありそれぞれ 2 disk, 1 ssd が搭載されているとします。/dev/ssd は gdisk 等を用いて2つ以上のパーティショ ンに切り分けます。

下記のように /dev/sdb (hdd) に対して /dev/ssd1 (ssd), /dev/sdc (hdd) に対して /dev/ssd2 (ssd) を割り当てることが出来ます。

% ceph-deploy --cluster cluster01 osd create ceph01:sdb:/dev/ssd1 ceph02:sdb:/dev/ssd1 ceph03:sdb:/dev/ssd1
% ceph-deploy --cluster cluster01 osd create ceph01:sdc:/dev/ssd2 ceph02:sdc:/dev/ssd2 ceph03:sdc:/dev/ssd2

Ceph ストレージ全体の容量設計と mon の ratio の関係

3TB のディスクを持ったノードが 33 台並んでいるとします。各ノードには osd プロ セスが1つ稼働します。合計容量は 99 TB となりますが mon が持っているコンフィギュ レーションである full ratio というパラメータがありデフォルト値が 0.95 となって います。よってこのクラスタで扱える全体のディスク容量は 95TB となります。

また、ラックに数台のノードを積むのが通常ですが、電源故障等で一気にラック単位で 障害が発生したとします。この場合 Ceph はすべてのデータに関してレプリカを取り復 旧作業を行います。しかしながら停止するノード数によってはストレージ全体の扱える 容量をオーバーすることも懸念されます。これに対応するために先ほど登場した ratio パラメータを調整することが出来ます。

[global]

mon osd full ratio = .80
mon osd nearfull ratio = .70

上記の例では full ステートの ratio が 0.80, nearfull ステートの ratio が 0.70 となります。想定の障害ノード数を考慮し ratio パラメータにてその台数分を減算す れば良いわけです。

まとめ

前述した通り上図は比較的少ないノード数のクラスタを組む場合を想定しています。ノー ド数が増える場合は mon は mds, osd とも必要とするリソースの特性が異なりますの で別ノードに切り出すことも考えたほうが良さそうです。2014年の2月には Firefly と いう新しいリリース版が出ます。ここでのブループリント(設計書)を確認すると…

http://wiki.ceph.com/Planning/Blueprints/Firefly/osd%3A_new_key%2F%2Fvalue_backend

journal に変わる新たなメタデータ管理方法として KVS データベースを扱うことも視 野に入っているようです。上記の URL 見る限りでは Facebook がオープンソースにし た rocksdb や fusionio の nvmkv, seagate の kinetic 等が挙がっています。2月に 期待しましょう！