Ceph101: "ワタシハ セフ チョットデキル"への道

2020/7/25にオンラインで開催のJuly Tech Festa 2020における、F-6のセッションの発表スライドです。
Cephの基礎について解説しています。

Transcript

1. Ceph 101: “ワタシハ セフ チョットデキル” への道 ＿・）つかまん @tsukaman https://bit.ly/JTF2020-F6
2. 誰？ • 名前︓ ＿・） つかまん （@tsukaman） • 仕事︓ HPE / Pointnext Hybrid IT Practice • 役割︓ 打楽器、Cloud Solution Architect • 書籍︓ Ansible実践ガイド 第3版、Raspberry Pi〔実⽤〕⼊⾨ • 好き︓ せがれいじり、ガジェットIYH、眼鏡、楽しいこと • 参加︓ Cloud Native Days Tokyo、 RancherJP、Tokyo HackerSpace 他 • 最近︓ 毎⽇のようにAmazonさんや楽天さんや ヨドバシさん等からモノが届くぜ・・・ 2
3. はじめに 先 に ⾔ わ な け れ ば な ら な い こ と が あ り ま す 。 3
4. 今回の発表内容について 実は Ver 1.2.0 です • Japan Rook Meetup #3での発表をベースにしています – 「Ceph、完全に理解した」って Tweetする為のセッション ｰ Ceph 101 ｰ • イベントURL: https://rook.connpass.com/event/174294/ • スライドURL: https://bit.ly/JRM3_Ceph101 • 動画URL: https://youtu.be/QSunWLF9pQc – この内容の構成を⾒直し、⼀部内容を修正・追加しました • 特に前半部分におけるスライドの並びを変更/削除 • 上記イベントで駆け⾜になってしまった後半部分を⼿厚く • CRUSH Map 部分など、⼀部のスライドを追加および加筆 – （時間があれば︖）どのように変化しているか⽐較してみてください︕ 4
5. GOAL こ の セ ッ シ ョ ン は 何 を ⽬ 指 す か 5
6. セフ チョット デキル ま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖ 6
7. ͍΍ʂ ͪΐͬͱ·ͯʂ 7
8. セフ チョット デキル ま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖ 8 【参考】
9. セフ チョット デキル ま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖ 9 【参考】
10. セフ チョット デキル ま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖ 10 いきなり ここまでは 無理ﾎﾟﾖ
11. セフ チョット デキル ま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖ 11 なので まずは
12. Cephを 完全に 理解 意 訳 ︓ C e p h の チ ュ ー ト リ ア ル 終 わ っ た 12
13. ऴΘͬͨΒ 5XFFUΑΖ͘͠ʂ 13
14. OVERVIEW C e p h っ て ⼀ 体 な に や つ ︖ 14
15. Cephさん マジイケ 頭⾜類 C e p h ≓ C e p h a l o p o d : 頭 ⾜ 類 15
16. イケてる頭⾜類Cephさんの マジ♥惚れ♥ポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystem、え、他にも・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPIに・・・Kernel Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 16
17. イケてる頭⾜類Cephさんの マジ惚れポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕︕︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystemにNFS・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPI・・・え、Kernerl Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 17 【参考】 謎カッコイイPR動画 https://youtu.be/QBkH1g4DuKE
18. センター試験に出る Cephの歴史（ざっくり版） • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている • 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 18
19. センター試験に出る Cephの歴史（ざっくり版） • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている • 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 19 【参考】 Sage氏の論文 https://www.ssrc.ucsc.edu/person/sage.html
20. センター試験に出る Cephの歴史（ざっくり版） • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース • 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL） 20
21. センター試験に出る Cephの歴史（ざっくり版） • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース • 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL） 21 【おまけ】 Cephのロゴ https://ceph.io/logos/ 各リリース毎にロゴがある
22. Cephを 味わう C e p h さ ん の 中 ⾝ を み て み ま し ょ う 。 22
23. ARCHITECTURE C e p h を 構 成 す る ア レ や コ レ や 23
24. The Big Picture of Ceph Architecture 24
25. RADOS Ε ͌ Ͳ ͢ 声 に 出 し て 読 み た い ︖ C e p h 25
26. The Big Picture of Ceph Architecture 26 これ
27. RADOS Reliable Autonomic Distributed Object Store • Cephの中核/基盤となるオブジェクトデータストア – ⾼信頼、⾃律制御、多数の物理ノードに分散配置なオブジェクトストア – Cephが引き受けるデータはメタデータも含めて全てRADOSに保存される – データの出し⼊れは”CRUSHアルゴリズム”に則って⾏われる • データの配置される場所を全て計算のみで決定できる • この計算はクライアント⾃⾝で⾏えるのでスケールしても性能劣化がない • 2つ（現在は実質3つ）の主要Daemonから構成される – 多くの Ceph Object Storage Device Daemon（OSD） – 少数の Ceph-Monitor（MON） – MONと⼀緒に動く Ceph-Manager（MGR） 27
28. • 実際にはこんなかんじ – 各Daemonは共存も可能 – MONとMGRを分けても動く • 推奨はされない 28 MON MGR OSD OSD OSD OSD OSD OSD MON MGR MON MGR OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD OSD Access⽤ Replication⽤ RADOS Reliable Autonomic Distributed Object Store
29. MON ΋ Μ 声 に 出 し て 読 み た い ︖ C e p h 29
30. MON Ceph Monitor Daemon • クラスターの状態を監視し「クラスターマップ」を作成/更新/配布する – クラスターマップには次のマップが含まれる • Monitor Map、OSD Map、PG Map、CRUSH Map、MDS Map – このマップさえあれば計算でオブジェクトの配置場所を算出できる • つまりこのマップはCRUSHアルゴリズムのために超重要 • クライアントもこのマップを利⽤することで直接OSDアクセスが可能に。 • 障害やノード追加などで構成変更が発⽣する場合の指⽰とかを出す • 通常は冗⻑性を考慮して3台以上の奇数台数のMONノードを配置 – 分散合意形成プロトコルのPaxosを使う為に奇数である必要がある • cephコマンドを実⾏した時に返答してくれるのもMONさん 30 MON
31. MGR ͑ Ή ͡ ͌ ͋ ʙ Δ 声 に 出 し て 読 み た い ︖ C e p h 31
32. MGR Ceph Manager Daemon • わりと最近︖（12.xのluminous以降）ほぼ必須となったデーモン • MONと⼀緒に動き、外部へ監視情報を提供したりする – Cephクラスターのステータス出⼒の補助的な役割も持つ • Ceph Dashboard（管理⽤WebUI）の機能を提供する 32 MON MGR
33. OSD ͓ ͎ ͑ ͢ Ͱ ͌ 声 に 出 し て 読 み た い ︖ C e p h 33
34. OSD Ceph Object Storage Device Daemon • オブジェクトの保存領域を管理し、データの出し⼊れをする • 保存領域単位（通常はディスク単位）でOSDデーモンが起動する – 最近はceph-volumeの機能によりディスク単位でLVMの論理ディスクを作成 • 現在はBlueStoreというストレージバックエンドで領域を管理している – Write Ahead Log（WAL）を⽤いることで整合性を担保し、かつ性能も向上 – 内部メタデータを領域内にあるRocksDB（DB）に格納 – WALやDBをSSD/NVMe上に配置で性能向上も可能 • 同⼀ノード上のOSDはこのWAL/DBデバイスを共有可 – 容量が溢れるとHDD上に記録するようになるので注意 • OSD同⼠は互いに死活監視している – 異常があればMONに報告する 34 OSD OSD OSD OSD OSD OSD
35. HOW TO LOCATE? こ こ が C e p h の す ご い と こ ろ 35
36. CRUSH ͘ Β ͬ ͠ Ύ ʂ 声 に 出 し て 読 み た い ︖ C e p h 36
37. CRUSH algorithm Controlled Replication Under Scalable Hashing • RADOS上でオブジェクトをどのOSDに配置するか決定するアルゴリズム • 配置先はクラスターマップがあれば100%計算だけで算出できる – メタデータを中央集約するサーバーが不要 • ボトルネックや単⼀障害点がないので、拡張性が⾼くなる • マップをもつクライアントが直接OSDにアクセスできる • 配置先の決定に重要な要素 – Pool – CRUSH Map – CRUSH rule – Placement Group（PG） 37
38. Pool • オブジェクトを保存するための論理的な領域 • デフォルトのPoolのほか任意で作成することが可能 • 各プール単位で異なる設定をとることができる – 耐障害性 • Replication - オブジェクトを複製することで冗⻑性を担保。性能が良いが⾼コスト。 • Erasure Coding - RAID5/6のようにパリティで冗⻑性を担保。低コストだが⾼負荷。 – Placement Group数（後述します） – CRUSH Rule（後述します） – クォータ – 圧縮 – 紐つけるアプリケーション（⽤途） – 所有者 等 38
39. CRUSH Map & Rule • CRUSH Mapではツリー構造でOSDの物理配置トポロジーを定義できる – フロア、ラック、ノードなど、物理的なトポロジを反映できる • 更にどのように障害ドメインを分けるか、Ruleとして定義できる – 複製するオブジェクトが、異なるノードに配置されるだけではなく、異なるラッ クに配置されるようなRule定義をPool毎に定義可能 • 障害ドメインの分割レベルを変えると・・・ – ホストレベル分割だったら6レプリカまで設定可能 – ラックレベル分割だったら3レプリカまで設定可能 39 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11
40. CRUSH Map & Rule • CRUSH Mapはコマンドや⼿動編集などでカスタマイズ可能 – CRUSHマップの編集は中村 実⽒のCeph情報ページが分かりやすい • Ceph の覚え書きのインデックス – http://www.nminoru.jp/~nminoru/unix/ceph/ • デフォルトではどのhost配下にどのOSDがあるかの情報をMap内に持つ – デフォルトのRuleでもhost単位で分散してレプリカを配置する • 冗⻑レベルとして 3 Replicas を設定したPoolにオブジェクトを保存する場合･･･ – hostの異なるOSD3つが保存先として選ばれる • osd.0 と osd.3 と osd.10 や osd.4 と osd.6 と osd.9 など 40 root host.0 osd.0 osd.1 host.1 osd.2 osd.3 host.2 osd.4 osd.5 host.3 osd.6 osd.7 host.4 osd.8 osd.9 host.5 osd.10 osd.11
41. CRUSH Map & Rule • 必要に応じて、物理配置トポロジーをMapに定義 – 障害ドメインをどのように分けたいかの要件による • Pool毎で障害ドメインの分割レベルをRuleとして指定できる – 例えば以下の物理トポロジーがMapで定義されて居た場合 • Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能 • Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能 • Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能 41 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11 rack.3 host.6 osd.12 osd.13 host.7 osd.14 osd.15 room.0 root room.1
42. CRUSH Map & Rule • Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.3, osd.7]、[osd.6, osd.9, osd.11]、[osd.4, osd.12, osd.15] など – 同⼀host配下のOSDが組み合わされることはない • Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.5, osd.13]、[osd.4, osd.11, osd.15]、[osd.2, osd.9, osd.12] など – 同⼀rack配下のOSDが組み合わされることはない • Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.9]、[osd.2, osd.13]、[osd.5, osd.9] など – 同⼀room配下のOSDが組み合わされることはない 42 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11 rack.3 host.6 osd.12 osd.13 host.7 osd.14 osd.15 room.0 root room.1
43. CRUSH Map & Rule • Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.3, osd.7]、[osd.6, osd.9, osd.11]、[osd.4, osd.12, osd.15] など – 同⼀host配下のOSDが組み合わされることはない • Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.5, osd.13]、[osd.4, osd.11, osd.15]、[osd.2, osd.9, osd.12] など – 同⼀rack配下のOSDが組み合わされることはない • Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.9]、[osd.2, osd.13]、[osd.5, osd.9] など – 同⼀room配下のOSDが組み合わされることはない 43 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11 rack.3 host.6 osd.12 osd.13 host.7 osd.14 osd.15 room.0 root room.1 このOSDの 組み合わせ
44. CRUSH Map & Rule • Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.3, osd.7]、[osd.6, osd.9, osd.11]、[osd.4, osd.12, osd.15] など – 同⼀host配下のOSDが組み合わされることはない • Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.5, osd.13]、[osd.4, osd.11, osd.15]、[osd.2, osd.9, osd.12] など – 同⼀rack配下のOSDが組み合わされることはない • Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.9]、[osd.2, osd.13]、[osd.5, osd.9] など – 同⼀room配下のOSDが組み合わされることはない 44 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11 rack.3 host.6 osd.12 osd.13 host.7 osd.14 osd.15 room.0 root room.1 これ これ これ
45. CRUSH Map & Rule • Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.3, osd.7]、[osd.6, osd.9, osd.11]、[osd.4, osd.12, osd.15] など – 同⼀host配下のOSDが組み合わされることはない • Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.5, osd.13]、[osd.4, osd.11, osd.15]、[osd.2, osd.9, osd.12] など – 同⼀rack配下のOSDが組み合わされることはない • Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能 – OSDの組み合わせ例︓ [osd.0, osd.9]、[osd.2, osd.13]、[osd.5, osd.9] など – 同⼀room配下のOSDが組み合わされることはない 45 root rack.0 host.0 osd.0 osd.1 host.1 osd.2 osd.3 rack.1 host.2 osd.4 osd.5 host.3 osd.6 osd.7 rack.2 host.4 osd.8 osd.9 host.5 osd.10 osd.11 rack.3 host.6 osd.12 osd.13 host.7 osd.14 osd.15 room.0 root room.1 これ これ これ の事を こう呼びます
46. PG Placement Group • OSDをPoolの設定値に応じてグループ化したもの – 例︓Replication poolでReplica数を3にしたPoolの場合 PG2.0[OSD.0, OSD.5, OSD.8]、PG2.1[OSD5, OSD.2, OSD.0]、PG2.2[OSD.1, OSD.6, OSD.9]、 PG2.3[OSD.6, OSD.3, OSD.1]、PG2.4[OSD.2, OSD.7, OSD.10]、PG2.5[OSD.7, OSD.4, OSD.2]・・・ ･･･みたいな感じになる（この例はてきとうな値です） – 各OSDに設定されるWeight値で出現率が変わる • 厳格に均等分散するのは⾼コストなのでユルフワ分散する – 1つのOSDは複数のPGに所属することに通常はなる – 全く同じ内容のPGができることもあるが問題は無い • 各PGの先頭のOSDが班⻑（Primary）となる – この班⻑がClientと直接データのやりとりをする – 他の班員は班⻑の指⽰でデータコピーしたり、チャンク受け渡ししたりする 46
47. PG Placement Group • PG数はPool毎の要件や状況に応じて原則⼿動で設定・調整をする – この部分が多くのCeph運⽤者を悩ませてきた・・・ • 最適なPG数を割り出すのに熟練された職⼈の腕が必要になる – PG数が極端に少ないと → OSD間の利⽤量の偏りが⼤きくなる – PG数が極端に多いと → 構成が複雑になり⾃律制御に多くのリソースが必要になる – ⼀応、算出ツール（Ceph PGs per Pool Calculator）もある・・・が、わりと初⾒殺し • https://ceph.com/pgcalc/ – 使う予定のPoolとか将来的なOSDの追加予定とかも加味して算出・・・ • PG数は⼀度⼤きくしたら、⼩さくできない – 状況を確認しつつ、適切に値を増やしていく運⽤になる – ⼀気にあげすぎると、構成変更の影響で⾼負荷状態に陥る可能性も・・・ 47
48. େৎ෉ʂʂ 48
49. 49 https://ceph.io/rados/new-in-nautilus-pg-merging-and-autotuning/
50. PG Placement Group • 最近のリリースで⾊々できるように︕︕ – PG数を減らす • 2つのPGを1つに統合することで実現（PG Merge） – 最適なPG数となるように⾃動的に調整させる • PG auto-scalerの実装 • これらついてはTakashi Sogabeさん ( @rev4t ) の Qiita 記事が分かりやすい – Ceph 最適な PG count で運⽤するための Best Practice (Nautilus, <=Luminous 対応) • https://qiita.com/rev4t/items/1feec5db96213b7e0bb5 50
51. クライアントからのアクセスの流れ どのようにPG/OSDを特定しているのか︖ 1. MONからクラスターマップを⼊⼿ 2. 扱うオブジェクト名前をハッシュしオブジェクトIDを算出 l Object_ID = hash(Object_Name) 3. オブジェクトIDをPoolのPG数で割った剰余を求める l Object_ID % PG _Count → 仮に 「12」 という値が得られたとする 4. 保存先のPool名からPool IDを求める l アクセス先のPoolのIDが、仮に 「3」 だったとする 5. Pool IDに3.で得た値を連結したものがPG IDとなる l この例でのPG IDは 「3.12」となる 6. PG IDから該当するPGのOSDメンバー情報を得る l PG ID「3.12」に含まれるOSDが、仮に [OSD.6, OSD.3, OSD.1] だったとする 7. Primary OSDと通信を⾏う l 6. で得られたリストの先頭OSD（OSD.6）が、今回の Primary OSD となる l 書き込み時は、Primaryから他OSDへ書き込み指⽰をして、全部完了したらClientへACKを返す l 読み込み時は、PrimaryがObjectを返答（ErasureCoding時はPrimaryOSDがChunkを集め再構成） 51
52. HOW TO COMMUNICATE? R A D O S と お 喋 り す る ⾊ 々 な ⽅ 法 52
53. The Big Picture of Ceph Architecture 53
54. The Big Picture of Ceph Architecture 54 こっち
55. librados Γ Ϳ Ε ͌ Ͳ ͢ 声 に 出 し て 読 み た い ︖ C e p h 55
56. librados library of using RADOS • 独⾃アプリケーションからRADOSを利⽤する為のライブラリ – librados APIによりMONやODSとの直接通信が可能となる – 各種プログラミング⾔語向けのライブラリが公式で⽤意されている • C++、C、Python、Java、PHP – その他の⾔語でもライブラリを開発/公開している⼈が居たりする 56
57. RadosGW Ε ͌ Ͳ ͢ ͛ ʔ ͱ ΢ Σ ʔ Π 声 に 出 し て 読 み た い ︖ C e p h 57
58. RadosGW RADOS Gateway • RADOSへのRESTfulなゲートウェイを提供するためのインタフェース – RadosGW⾃⾝もlibradosを⽤いて通信の仲介をしているクライアント • 現在は”Ceph Object Gateway”が正式名称・・・っぽい︖ • 次の2種類のインターフェースを提供する – Amazon S3 RESTful API 互換インタフェース – OpenStack Swift API 互換インタフェース 58
59. RBD ͋ ʙ Δ ͼ ͌ Ͱ ͌ 声 に 出 し て 読 み た い ︖ C e p h 59
60. RBD RADOS Block Device • RADOSをバックエンドとするブロックデバイスを提供する • 現在は”Ceph Block Device”が正式名称・・・っぽい︖ • Linuxのカーネルモジュールまたはlibrbdのライブラリを利⽤する – マウントなど、通常のブロックデバイスと同等に利⽤出来る – 仮想化アプリケーションなどからはlibrbdにより柔軟な利⽤が可能 • OpenStack Cinderのバックエンドとしてもよく使われる 60
61. CephFS ͤ ; ͑ ; ͑ ͢ 声 に 出 し て 読 み た い ︖ C e p h 61
62. CephFS Ceph File System • RADOSをバックエンドとしたPOSIX準拠のファイルシステムを提供する – もともとSage⽒はこれを実現したくてCephを開発した • LinuxのカーネルドライバーまたはFUSEを介してマウントする • ファイルデータとメタデータは別々に管理される – メタデータはCeph Metadata Server Daemon（MDS）を介して管理される – ファイルデータは直接クライアントからOSDにアクセスする • NFS-Ganeshaを⽤いてNFS Exportも可能 – Ganesha⾃体はRGWをバックエンドに することも可能 • ただしこの場合は制約アリ 62
63. MDS ͑ Ή Ͱ ͌ ʔ ͑ ͢ 声 に 出 し て 読 み た い ︖ C e p h 63
64. MDS Ceph Metadata Server Daemon • CephFSのメタデータを管理する為のデーモン – CephFSのメタデータをメモリ上で管理している • 複数台起動することで冗⻑性や性能を向上できる – メタデータツリーを動的に分割して担当MDSを割当てる • 負荷の⾼い部分を動的に分割して管理 • 障害MDSの担当部分を別MDSに引き継ぎ – メタデータはjournalとして記録される • 必要な情報はRADOSに格納されている • 再⽣することでメタデータを復旧可能 • 障害が起きても別ノードが引き継いで稼働を継続できる 64
65. CephFS構成の例 65
66. CONCLUSION ま ・ と ・ め 66
67. そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Cephはクラウド時代のSoftware Defined Storageの雄として君臨 – ソフトウェアパゥワァーで柔軟な利⽤ができちゃう • Object/Block Storage、FileSystem、なんならAppから直接RADOSつかったり・・・ • 様々なソフトウェアとの親和性が⾼く、⽤途の幅が広い – 専⽤ハードに依存しないDaemon群とライブラリ群 • SPOFがなく、ドンドンスケールさせられる設計 • コンテナ化してコンテナオーケストレーション基盤上に載せやすい 67 そこで
68. ͕ͩ ͔͠͠ʂʂ 68
69. そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Operatorパゥワーにより簡単にデプロイできても〜 – Cephのことを知らないままだと︖ • PG内のOSD Podが全て同⼀ノードに・・・ • MONのPodが全て同⼀ノードに・・・ • MDSのP(略 • CSRUSH Map未編集でラック障害でPG内のOSDが全部死・・・ • なんかよく分からないけどOSD使い切って地獄 has come... • 速度を向上させたいけどどうしていいか分からない・・・ • リソースの分配やネットワークの整備にも迷ってしまったり・・・ • ⾊々な使い⽅ができるのに、結局使わないままに・・・ などなど 69
70. େৎ෉ʂʂ 70
71. େৎ෉ʂʂ 71 なぜなら もう
72. Cephを 完全に 理解 こ の 話 、 覚 え て た ︖ 72
73. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 73 したから ・・・ね？
74. TIPS お ・ ま ・ け 74
75. Cephと明⽇からいちゃつく君へ 親⽗の⼩⾔的なアレを贈ります •Ϧιʔε͸͚ͪΔͳ •04%͸ৗʹ༨༟Λ΋ͯ •଎͍ωοτϫʔΫ͸ਖ਼ٛ •๯ݥ͸΄Ͳ΄Ͳʹ •શͯΛ੍ޚ͠Α͏ͱ͢Δͳ •Ϧόϥϯεͷিܸʹඋ͑Ζ •Ջ͕͋ͬͨΒDFQI TΛୟ͚ 75
76. REFERENCES あ り が た い 参 考 資 料 の 数 々 。 76
77. Ceph101 参考情報 中井先⽣（@enakai00）のありがたい資料 • CTC教育サービス 「クラウド時代のオープンソース実践活⽤」 – https://www.school.ctc-g.co.jp/columns/nakai/ • 第44回 分散ストレージ技術「Ceph」のからくり • 第45回 ⼀味違うCephの「オブジェクトストア」とは • 第76回 Cephのクラスタ管理とデータ冗⻑化の仕組み • 第77回 分散ファイルシステムCephFSのアーキテクチャー • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 77
78. Ceph101 参考情報 エマ先⽣（@Yuryu）のありがたい資料 • Cephアーキテクチャー概説 – https://www.slideshare.net/Yuryu/ceph-36503772 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 78
79. Ceph101 参考情報 これで完全理解は完璧でパーフェクト • Ceph Documentation – https://ceph.readthedocs.io/en/latest/ • 困ったら公式ドキュメント︕ • Rook Documentation – https://rook.io/docs/rook/v1.3/ – https://rook.io/docs/rook/v1.3/ceph-quickstart.html – https://rook.io/docs/rook/v1.3/ceph-storage.html • k8sでRook/Cephを使いたい貴⽅に︕ • Rookだらけの Advent Calendar 2019 – https://qiita.com/advent-calendar/2019/rook • 特に、⼆⽇⽬のうつぼさんの記事「Cephの紹介」がおすすめです︕ 79
80. またな︕ 80
81. 頼んだよ︕ 5XFFU ๨Εͳ͍ͰͶʂ 81