「Ceph、完全に理解した」って Tweetする為のセッション ｰ Ceph 101 ｰ

Japan Rook Meetup #3での発表スライドです。Ceph、完全に理解した」って Tweetしてもらう為に、Cephの基本について解説しています。

Transcript

1. 「Ceph、完全に理解した」って Tweetする為のセッション ｰ Ceph 101 ｰ ＿・）つかまん @tsukaman https://bit.ly/JRM3_Ceph101
2. 誰？ • 名前︓ ＿・） つかまん （@tsukaman） • 仕事︓ HPE / Pointnext Hybrid IT Practice • 役割︓ 打楽器、Cloud Solution Architect • 書籍︓ Ansible実践ガイド 第3版、Raspberry Pi〔実⽤〕⼊⾨ • 好き︓ せがれいじり、ガジェットIYH、眼鏡、楽しいこと • 参加︓ Cloud Native Days Tokyo、 RancherJP、Tokyo HackerSpace 他 • 最近︓ 社畜業が捗る ＆ ⾃宅仕事でモリモリ太る 2
3. GOAL こ の セ ッ シ ョ ン は 何 を ⽬ 指 す か 3
4. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 4
5. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 5 【参考】
6. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 6 【参考】
7. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 7 【参考】
8. ࠓ೔͸΄΅ ͜ͷϊϦͩΑʂ 8
9. STYLE こ の セ ッ シ ョ ン の や り ⼝ は ︖ 9
10. 他⼈様の 褌で ⼤相撲 い や も う 、 偉 ⼤ な 先 達 の 過 去 の 資 料 が 素 晴 ら し す ぎ て ね … 10
11. 他⼈様の 褌で ⼤相撲 い や も う 、 偉 ⼤ 達 の 過 去 の 資 料 が 素 晴 ら し す ぎ て ね … 11 そこで まずは
12. 中井悦司先⽣（@enakai00）の ⾮常にありがたぁ〜〜〜い資料 • CTC教育サービス コラム「クラウド時代のオープンソース実践活⽤」 – https://www.school.ctc-g.co.jp/columns/nakai/ • 第44回 分散ストレージ技術「Ceph」のからくり • 第45回 ⼀味違うCephの「オブジェクトストア」とは • 第76回 Cephのクラスタ管理とデータ冗⻑化の仕組み • 第77回 分散ファイルシステムCephFSのアーキテクチ 12
13. 中井悦司先⽣（@enakai00）の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 13
14. 中井⼤先⽣（@enakai00）の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 14 そして
15. 岩尾”エマ”はるか先⽣（@Yuryu）の ⾮常にありがたぁ〜〜〜い資料 • Cephアーキテクチャー概説 – https://www.slideshare.net/enakai/ceph-57989510 15
16. 岩尾”エマ”はるか先⽣（@Yuryu）の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 16
17. 岩尾エマ先⽣（@Yuryu）の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 17 おわかり いただけた だろうか
20. 20 あれ？ なんか古い…？ 大丈夫？
21. େৎ෉ʂʂ 21
22. Cephに 歴史 あり 歴 史 も あ れ ば 実 績 も あ る 22
23. センター試験に出る Cephの歴史（ざっくり版） • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている • 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 23
24. センター試験に出る Cephの歴史（ざっくり版） • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている • 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 24 【参考】 Sage氏の論文 https://www.ssrc.ucsc.edu/person/sage.html
25. センター試験に出る Cephの歴史（ざっくり版） • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース • 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL） 25
26. センター試験に出る Cephの歴史（ざっくり版） • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース • 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL） 26 【おまけ】 Cephのロゴ https://ceph.io/logos/ 各リリース毎にロゴがある
27. イケてる頭⾜類Cephさんの マジ♥惚れ♥ポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystem、え、他にも・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPIに・・・Kernel Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 27
28. イケてる頭⾜類Cephさんの マジ惚れポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕︕︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystemにNFS・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPI・・・え、Kernerl Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 28 【参考】 謎カッコイイPR動画 https://youtu.be/QBkH1g4DuKE
29. Cephを 味わう C e p h さ ん の 中 ⾝ を み て み ま し ょ う 。 29
30. ARCHITECTURE C e p h を 構 成 す る ア レ や コ レ や 30
31. The Big Picture of Ceph Architecture 31
32. RADOS Ε ͌ Ͳ ͢ 声 に 出 し て 読 み た い ︖ C e p h 32
33. The Big Picture of Ceph Architecture 33 これ
34. 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） 34
35. • 実際にはこんなかんじ – 各Daemonは共存も可能 – MONとMGRを分けても動く • 推奨はされない 35 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
36. MON ΋ Μ 声 に 出 し て 読 み た い ︖ C e p h 36
37. MON Ceph Monitor Daemon • クラスターの状態を監視し「クラスターマップ」を作成/更新/配布する – クラスターマップには次のマップが含まれる • Monitor Map、OSD Map、PG Map、CRUSH Map、MDS Map – このマップさえあれば計算でオブジェクトの配置場所を算出できる • つまりこのマップはCRUSHアルゴリズムのために超重要 • クライアントもこのマップを利⽤することで直接OSDアクセスが可能に。 • 障害やノード追加などで構成変更が発⽣する場合の指⽰とかを出す • 通常は冗⻑性を考慮して3台以上の奇数台数のMONノードを配置 – 分散合意形成プロトコルのPaxosを使う為に奇数である必要がある • cephコマンドを実⾏した時に返答してくれるのもMONさん 37 MON
38. MGR ͑ Ή ͡ ͌ ͋ ʙ Δ 声 に 出 し て 読 み た い ︖ C e p h 38
39. MGR Ceph Manager Daemon • わりと最近︖（12.xのluminous以降）ほぼ必須となったデーモン • MONと⼀緒に動き、外部へ監視情報を提供したりする – Cephクラスターのステータス出⼒の補助的な役割も持つ • Ceph Dashboard（管理⽤WebUI）の機能を提供する 39 MON MGR
40. OSD ͓ ͎ ͑ ͢ Ͱ ͌ 声 に 出 し て 読 み た い ︖ C e p h 40
41. 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に報告する 41 OSD OSD OSD OSD OSD OSD
42. HOW TO LOCATE? こ こ が C e p h の す ご い と こ ろ 42
43. CRUSH ͘ Β ͬ ͠ Ύ ʂ 声 に 出 し て 読 み た い ︖ C e p h 43
44. CRUSH algorithm Controlled Replication Under Scalable Hashing • RADOS上でオブジェクトをどのOSDに配置するか決定するアルゴリズム • 配置先はクラスターマップがあれば100%計算だけで算出できる – メタデータを中央集約するサーバーが不要 • ボトルネックや単⼀障害点がないので、拡張性が⾼くなる • マップをもつクライアントが直接OSDにアクセスできる • 配置先の決定に重要な要素 – Pool – CRUSH Map – CRUSH rule – Placement Group（PG） 44
45. Pool • オブジェクトを保存するための論理的な領域 • デフォルトのPoolのほか任意で作成することが可能 • 各プール単位で異なる設定をとることができる – 耐障害性 • Replication - オブジェクトを複製することで冗⻑性を担保。性能が良いが⾼コスト。 • Erasure Coding - RAID5/6のようにパリティで冗⻑性を担保。低コストだが⾼負荷。 – Placement Group数 – CRUSH Rule – クォータ – 圧縮 – 紐つけるアプリケーション（⽤途） – 所有者 等 45
46. CRUSH Map & Rule • CRUSH Mapではツリー構造でOSDの物理配置トポロジーを定義できる – フロア、ラック、ノードなど、物理的なトポロジを反映できる • 更にどのように障害ドメインを分けるか、Ruleとして定義できる – 複製するオブジェクトが、異なるノードに配置されるだけではなく、異なるラッ クに配置されるようなRule定義が可能 • 数の構成を例に考えた場合・・・ – ホストレベルの分割だったら6レプリカまで設定可能 – ラックレベルの分割だったら3レプリカまで設定可能 46 root rack.0 node.0 osd.0 osd.1 node.1 osd.2 osd.3 rack.1 node.2 osd.4 osd.5 node.3 osd.6 osd.7 rack.2 node.4 osd.8 osd.9 node.5 osd.10 osd.11
47. 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と直接データのやりとりをする – 他の班員は班⻑の指⽰でデータコピーしたり、チャンク受け渡ししたりする 47
48. PG Placement Group • PG数はPool毎の要件や状況に応じて設定・調整をする – この部分が多くのCeph運⽤者を悩ませてきた・・・ • 最適なPG数を割り出すのに熟練された職⼈の腕が必要になる – PG数が極端に少ないと → OSD間の利⽤量の偏りが⼤きくなる – PG数が極端に多いと → 構成が複雑になり⾃律制御に多くのリソースが必要になる – ⼀応、算出ツール（Ceph PGs per Pool Calculator）もある・・・が、わりと初⾒殺し • https://ceph.com/pgcalc/ – 使う予定のPoolとか将来的なOSDの追加予定とかも加味して算出・・・ • PG数は⼀度⼤きくしたら、⼩さくできない – 状況を確認しつつ、適切に値を増やしていく運⽤になる – ⼀気にあげすぎると、構成変更の影響で⾼負荷状態に陥る可能性も・・・ 48
49. େৎ෉ʂʂ 49
50. 50 https://ceph.io/rados/new-in-nautilus-pg-merging-and-autotuning/
51. 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 51
52. クライアントからのアクセスの流れ どのようにPG/OSDを特定しているのか︖ 1. MONからクラスターマップを⼊⼿ 2. 扱うオブジェクト名前をハッシュしオブジェクトIDを算出 3. オブジェクトIDをPoolのPG数で割った剰余を求める 4. 保存先のPool名からPool IDを求める 5. Pool IDに3で得た値を連結したものがPG IDとなる 6. PG IDから該当するPGのOSDメンバー情報を得る 7. Primary OSDと通信を⾏う 52
53. HOW TO COMMUNICATE? R A D O S と お 喋 り す る ⾊ 々 な ⽅ 法 53
54. The Big Picture of Ceph Architecture 54
55. The Big Picture of Ceph Architecture 55 こっち
56. librados Γ Ϳ Ε ͌ Ͳ ͢ 声 に 出 し て 読 み た い ︖ C e p h 56
57. librados library of using RADOS • 独⾃アプリケーションからRADOSを利⽤する為のライブラリ – librados APIによりMONやODSとの直接通信が可能となる – 各種プログラミング⾔語向けのライブラリが公式で⽤意されている • C++、C、Python、Java、PHP – その他の⾔語でもライブラリを開発/公開している⼈が居たりする 57
58. RadosGW Ε ͌ Ͳ ͢ ͛ ʔ ͱ ΢ Σ ʔ Π 声 に 出 し て 読 み た い ︖ C e p h 58
59. RadosGW RADOS Gateway • RADOSへのRESTfulなゲートウェイを提供するためのインタフェース – RadosGW⾃⾝もlibradosを⽤いて通信の仲介をしているクライアント • 現在は”Ceph Object Gateway”が正式名称・・・っぽい︖ • 次の2種類のインターフェースを提供する – Amazon S3 RESTful API 互換インタフェース – OpenStack Swift API 互換インタフェース 59
60. RBD ͋ ʙ Δ ͼ ͌ Ͱ ͌ 声 に 出 し て 読 み た い ︖ C e p h 60
61. RBD RADOS Block Device • RADOSをバックエンドとするブロックデバイスを提供する • 現在は”Ceph Block Device”が正式名称・・・っぽい︖ • Linuxのカーネルモジュールまたはlibrbdのライブラリを利⽤する – マウントなど、通常のブロックデバイスと同等に利⽤出来る – 仮想化アプリケーションなどからはlibrbdにより柔軟な利⽤が可能 • OpenStack Cinderのバックエンドとしてもよく使われる 61
62. CephFS ͤ ; ͑ ; ͑ ͢ 声 に 出 し て 読 み た い ︖ C e p h 62
63. CephFS Ceph File System • RADOSをバックエンドとしたPOSIX準拠のファイルシステムを提供する – もともとSage⽒はこれを実現したくてCephを開発した • LinuxのカーネルドライバーまたはFUSEを介してマウントする • ファイルデータとメタデータは別々に管理される – メタデータはCeph Metadata Server Daemon（MDS）を介して管理される – ファイルデータは直接クライアントからOSDにアクセスする • NFS-Ganeshaを⽤いてNFS Exportも可能 – Ganesha⾃体RGWをバックエンドに することも可能 • ただしこの場合は制約アリ 63
64. MDS ͑ Ή Ͱ ͌ ʔ ͑ ͢ 声 に 出 し て 読 み た い ︖ C e p h 64
65. MDS Ceph Metadata Server Daemon • CephFSのメタデータを管理する為のデーモン – CephFSのメタデータをメモリ上で管理している • 複数台起動することで冗⻑性や性能を向上できる – メタデータツリーを動的に分割して担当MDSを割当てる • 負荷の⾼い部分を動的に分割して管理 • 障害MDSの担当部分を別MDSに引き継ぎ – メタデータはjournalとして記録される • 必要な情報はRADOSに格納されている • 再⽣することでメタデータを復旧可能 • 障害が起きても別ノードが引き継いで稼働を継続できる 65
66. CephFS構成の例 66
67. CONCLUSION ま ・ と ・ め 67
68. そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Cephはクラウド時代のSoftware Defined Storageの雄として君臨 – ソフトウェアパゥワァーで柔軟な利⽤ができちゃう • Object/Block Storage、FileSystem、なんならAppから直接RADOSつかったり・・・ • 様々なソフトウェアとの親和性が⾼く、⽤途の幅が広い – 専⽤ハードに依存しないDaemon群とライブラリ群 • SPOFがなく、ドンドンスケールさせられる設計 • コンテナ化してコンテナオーケストレーション基盤上に載せやすい 68 そこで
69. ͕ͩ ͔͠͠ʂʂ 69
70. そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Operatorパゥワーにより簡単にデプロイできても〜 – Cephのことを知らないままだと︖ • PG内のOSD Podが全て同⼀ノードに・・・ • MONのPodが全て同⼀ノードに・・・ • MDSのP(略 • CSRUSH Map未編集でラック障害でPG内のOSDが全部死・・・ • なんかよく分からないけどOSD使い切って地獄 has come... • 速度を向上させたいけどどうしていいか分からない・・・ • リソースの分配やネットワークの整備にも迷ってしまったり・・・ • ⾊々な使い⽅ができるのに、結局使わないままに・・・ などなど 70
71. େৎ෉ʂʂ 71
72. େৎ෉ʂʂ 72 なぜなら もう
73. Cephを 完全に 理解 こ の 話 、 覚 え て た ︖ 73
74. Cephを 完全に 理解 終 わ っ た ら ツ イ ー ト し て ね ♪ 74 したから ・・・ね？
75. REFERENCES あ り が た い 参 考 資 料 の 数 々 つ ま り は 他 ⼈ 様 の 褌 ・ ・ ・ 洗 っ て お 返 し せ ね ば 75
76. その他の参考情報 本当にありがとうございました • Rookだらけの Advent Calendar 2019 – https://qiita.com/advent-calendar/2019/rook • 特に、⼆⽇⽬のうつぼさんの記事「Cephの紹介」がおすすめです︕ • Ceph Documentation – https://ceph.readthedocs.io/en/latest/ • 困ったら公式ドキュメント︕ • Ceph の覚え書きのインデックス – http://www.nminoru.jp/~nminoru/unix/ceph/ • 中村 実⽒によるCephに関する情報のページ。 CRUSH Mapを弄るときとかに役⽴ちます。 76
77. その他の参考情報 本当にありがとうございました • Rookだらけの Advent Calendar 2019 – https://qiita.com/advent-calendar/2019/rook • 特に、⼆⽇⽬のうつぼさんの記事「Cephの紹介」がおすすめです︕ • Ceph Documentation – https://ceph.readthedocs.io/en/latest/ • 困ったら公式ドキュメント︕ • Ceph の覚え書きのインデックス – http://www.nminoru.jp/~nminoru/unix/ceph/ • 中村 実⽒によるCephに関する情報のページ。 CRUSH Mapを弄るときとかに役⽴ちます。 77 One More Thing...
78. July Tech Festa 2020で話すよ︕ 今年も7⽉に開催とか凄くない︖ • ただ、ネタとしての本質情報は今⽇とあんまり変わらないです。 – まったく同じってのもアレですし、持ち時間も⻑いので もうすこし内容を追加したりする予定です。 – 皆さんからの⽣暖かいフィードバックをお待ちしております。 ※ 当⽅、⾖腐メンタルなんでフルボッコはご容赦を・・・ｳｯｳｯ（涙） 78 https://techfesta.connpass.com/event/175611/
79. またな︕ 79
80. 頼んだよ︕ 5XFFU ๨Εͳ͍ͰͶʂ 80