2020/7/25にオンラインで開催のJuly Tech Festa 2020における、F-6のセッションの発表スライドです。 Cephの基礎について解説しています。
Ceph 101:“ワタシハ セフ チョットデキル”への道＿・）つかまん@tsukamanhttps://bit.ly/JTF2020-F6
View Slide
誰？• 名前︓ ＿・） つかまん （@tsukaman）• 仕事︓ HPE / Pointnext Hybrid IT Practice• 役割︓ 打楽器、Cloud Solution Architect• 書籍︓ Ansible実践ガイド 第3版、Raspberry Pi〔実⽤〕⼊⾨• 好き︓ せがれいじり、ガジェットIYH、眼鏡、楽しいこと• 参加︓ Cloud Native Days Tokyo、RancherJP、Tokyo HackerSpace 他• 最近︓ 毎⽇のようにAmazonさんや楽天さんやヨドバシさん等からモノが届くぜ・・・2
はじめに先 に ⾔ わ な け れ ば な ら な い こ と が あ り ま す 。3
今回の発表内容について実は 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
GOALこ の セ ッ シ ョ ン は 何 を ⽬ 指 す か5
セフチョットデキルま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖6
͍ʂͪΐͬͱ·ͯʂ7
セフチョットデキルま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖8【参考】
セフチョットデキルま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖9【参考】
セフチョットデキルま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖10いきなりここまでは無理ﾎﾟﾖ
セフチョットデキルま ぁ 、 セ ッ シ ョ ン タ イ ト ル が コ レ だ し ︖11なのでまずは
Cephを完全に理解意 訳 ︓ C e p h の チ ュ ー ト リ ア ル 終 わ っ た12
ऴΘͬͨΒ5XFFUΑΖ͘͠ʂ13
OVERVIEWC e p h っ て ⼀ 体 な に や つ ︖14
Cephさんマジイケ頭⾜類C e p h ≓ C e p h a l o p o d : 頭 ⾜ 類15
イケてる頭⾜類Cephさんのマジ♥惚れ♥ポイント• 頼れる背中︕– SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕• 無限の伸びしろ︕– ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕• なんでもこなすイケメン︕– ObjectStorage、BlockDev、FileSystem、え、他にも・・・しゅごい万能・・・惚れる︕• 勝⼿に〇〇︕– 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕• コミュニケーションモンスター︕– 各⾔語ライブラリに種々のAPIに・・・Kernel Moduleまで︕︖・・・惚れる︕• でも、お⾼いんでしょ︖– 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕16
イケてる頭⾜類Cephさんのマジ惚れポイント• 頼れる背中︕– SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕︕︕• 無限の伸びしろ︕– ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕• なんでもこなすイケメン︕– ObjectStorage、BlockDev、FileSystemにNFS・・・しゅごい万能・・・惚れる︕• 勝⼿に〇〇︕– 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕• コミュニケーションモンスター︕– 各⾔語ライブラリに種々のAPI・・・え、Kernerl Moduleまで︕︖・・・惚れる︕• でも、お⾼いんでしょ︖– 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕17【参考】 謎カッコイイPR動画https://youtu.be/QBkH1g4DuKE
センター試験に出るCephの歴史（ざっくり版）• 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される– Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される• RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている• 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている– 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴– 2014年にRed HatがInktankを買収• ちなみに・・・– Amazon S3 は 2006年3⽉にリリース– OpenStack Swift は 2010年10⽉にリリース18
センター試験に出る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
センター試験に出るCephの歴史（ざっくり版）• 現在の最新リリースは 15.x Octopus– 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる– 以前は早かったが、現在は1年に1回のペースでメジャーリリース• 毎年3⽉をリリース⽬標としているらしい– ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL）20
センター試験に出るCephの歴史（ざっくり版）• 現在の最新リリースは 15.x Octopus– 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる– 以前は早かったが、現在は1年に1回のペースでメジャーリリース• 毎年3⽉をリリース⽬標としているらしい– ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL）21【おまけ】 Cephのロゴhttps://ceph.io/logos/各リリース毎にロゴがある
Cephを味わうC e p h さ ん の 中 ⾝ を み て み ま し ょ う 。22
ARCHITECTUREC e p h を 構 成 す る ア レ や コ レ や23
The Big Picture of Ceph Architecture24
RADOSΕ ͌ Ͳ ͢声 に 出 し て 読 み た い ︖ C e p h25
The Big Picture of Ceph Architecture26これ
RADOSReliable 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
• 実際にはこんなかんじ– 各Daemonは共存も可能– MONとMGRを分けても動く• 推奨はされない28MONMGROSDOSDOSDOSDOSDOSDMONMGRMONMGROSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDOSDAccess⽤Replication⽤RADOSReliable Autonomic Distributed Object Store
MON Μ声 に 出 し て 読 み た い ︖ C e p h29
MONCeph Monitor Daemon• クラスターの状態を監視し「クラスターマップ」を作成/更新/配布する– クラスターマップには次のマップが含まれる• Monitor Map、OSD Map、PG Map、CRUSH Map、MDS Map– このマップさえあれば計算でオブジェクトの配置場所を算出できる• つまりこのマップはCRUSHアルゴリズムのために超重要• クライアントもこのマップを利⽤することで直接OSDアクセスが可能に。• 障害やノード追加などで構成変更が発⽣する場合の指⽰とかを出す• 通常は冗⻑性を考慮して3台以上の奇数台数のMONノードを配置– 分散合意形成プロトコルのPaxosを使う為に奇数である必要がある• cephコマンドを実⾏した時に返答してくれるのもMONさん30MON
MGR͑ Ή ͡ ͌ ͋ ʙ Δ声 に 出 し て 読 み た い ︖ C e p h31
MGRCeph Manager Daemon• わりと最近︖（12.xのluminous以降）ほぼ必須となったデーモン• MONと⼀緒に動き、外部へ監視情報を提供したりする– Cephクラスターのステータス出⼒の補助的な役割も持つ• Ceph Dashboard（管理⽤WebUI）の機能を提供する32MONMGR
OSD͓ ͎ ͑ ͢ Ͱ ͌声 に 出 し て 読 み た い ︖ C e p h33
OSDCeph 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に報告する34OSDOSDOSDOSDOSDOSD
HOW TO LOCATE?こ こ が C e p h の す ご い と こ ろ35
CRUSH͘ Β ͬ ͠ Ύ ʂ声 に 出 し て 読 み た い ︖ C e p h36
CRUSH algorithmControlled Replication Under Scalable Hashing• RADOS上でオブジェクトをどのOSDに配置するか決定するアルゴリズム• 配置先はクラスターマップがあれば100%計算だけで算出できる– メタデータを中央集約するサーバーが不要• ボトルネックや単⼀障害点がないので、拡張性が⾼くなる• マップをもつクライアントが直接OSDにアクセスできる• 配置先の決定に重要な要素– Pool– CRUSH Map– CRUSH rule– Placement Group（PG）37
Pool• オブジェクトを保存するための論理的な領域• デフォルトのPoolのほか任意で作成することが可能• 各プール単位で異なる設定をとることができる– 耐障害性• Replication - オブジェクトを複製することで冗⻑性を担保。性能が良いが⾼コスト。• Erasure Coding - RAID5/6のようにパリティで冗⻑性を担保。低コストだが⾼負荷。– Placement Group数（後述します）– CRUSH Rule（後述します）– クォータ– 圧縮– 紐つけるアプリケーション（⽤途）– 所有者 等38
CRUSH Map & Rule• CRUSH Mapではツリー構造でOSDの物理配置トポロジーを定義できる– フロア、ラック、ノードなど、物理的なトポロジを反映できる• 更にどのように障害ドメインを分けるか、Ruleとして定義できる– 複製するオブジェクトが、異なるノードに配置されるだけではなく、異なるラックに配置されるようなRule定義をPool毎に定義可能• 障害ドメインの分割レベルを変えると・・・– ホストレベル分割だったら6レプリカまで設定可能– ラックレベル分割だったら3レプリカまで設定可能39rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11
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 など40roothost.0osd.0 osd.1host.1osd.2 osd.3host.2osd.4 osd.5host.3osd.6 osd.7host.4osd.8 osd.9host.5osd.10 osd.11
CRUSH Map & Rule• 必要に応じて、物理配置トポロジーをMapに定義– 障害ドメインをどのように分けたいかの要件による• Pool毎で障害ドメインの分割レベルをRuleとして指定できる– 例えば以下の物理トポロジーがMapで定義されて居た場合• Pool A は host レベルで保存先を選択する → 最⼤6レプリカまで設定可能• Pool B は rack レベルで保存先を選択する → 最⼤4レプリカまで設定可能• Pool C は room レベルで保存先を選択する → 最⼤2レプリカまで設定可能41rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11rack.3host.6osd.12 osd.13host.7osd.14 osd.15room.0 rootroom.1
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が組み合わされることはない42rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11rack.3host.6osd.12 osd.13host.7osd.14 osd.15room.0 rootroom.1
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が組み合わされることはない43rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11rack.3host.6osd.12 osd.13host.7osd.14 osd.15room.0 rootroom.1このOSDの組み合わせ
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が組み合わされることはない44rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11rack.3host.6osd.12 osd.13host.7osd.14 osd.15room.0 rootroom.1これこれこれ
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が組み合わされることはない45rootrack.0host.0osd.0 osd.1host.1osd.2 osd.3rack.1host.2osd.4 osd.5host.3osd.6 osd.7rack.2host.4osd.8 osd.9host.5osd.10 osd.11rack.3host.6osd.12 osd.13host.7osd.14 osd.15room.0 rootroom.1これこれこれの事をこう呼びます
PGPlacement 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
PGPlacement Group• PG数はPool毎の要件や状況に応じて原則⼿動で設定・調整をする– この部分が多くのCeph運⽤者を悩ませてきた・・・• 最適なPG数を割り出すのに熟練された職⼈の腕が必要になる– PG数が極端に少ないと → OSD間の利⽤量の偏りが⼤きくなる– PG数が極端に多いと → 構成が複雑になり⾃律制御に多くのリソースが必要になる– ⼀応、算出ツール（Ceph PGs per Pool Calculator）もある・・・が、わりと初⾒殺し• https://ceph.com/pgcalc/– 使う予定のPoolとか将来的なOSDの追加予定とかも加味して算出・・・• PG数は⼀度⼤きくしたら、⼩さくできない– 状況を確認しつつ、適切に値を増やしていく運⽤になる– ⼀気にあげすぎると、構成変更の影響で⾼負荷状態に陥る可能性も・・・47
େৎʂʂ48
49https://ceph.io/rados/new-in-nautilus-pg-merging-and-autotuning/
PGPlacement 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/1feec5db96213b7e0bb550
クライアントからのアクセスの流れどのように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
HOW TOCOMMUNICATE?R A D O S と お 喋 り す る ⾊ 々 な ⽅ 法52
The Big Picture of Ceph Architecture53
The Big Picture of Ceph Architecture54こっち
libradosΓ Ϳ Ε ͌ Ͳ ͢声 に 出 し て 読 み た い ︖ C e p h55
libradoslibrary of using RADOS• 独⾃アプリケーションからRADOSを利⽤する為のライブラリ– librados APIによりMONやODSとの直接通信が可能となる– 各種プログラミング⾔語向けのライブラリが公式で⽤意されている• C++、C、Python、Java、PHP– その他の⾔語でもライブラリを開発/公開している⼈が居たりする56
RadosGWΕ ͌ Ͳ ͢ ͛ ʔ ͱ Σ ʔ Π声 に 出 し て 読 み た い ︖ C e p h57
RadosGWRADOS Gateway• RADOSへのRESTfulなゲートウェイを提供するためのインタフェース– RadosGW⾃⾝もlibradosを⽤いて通信の仲介をしているクライアント• 現在は”Ceph Object Gateway”が正式名称・・・っぽい︖• 次の2種類のインターフェースを提供する– Amazon S3 RESTful API 互換インタフェース– OpenStack Swift API 互換インタフェース58
RBD͋ ʙ Δ ͼ ͌ Ͱ ͌声 に 出 し て 読 み た い ︖ C e p h59
RBDRADOS Block Device• RADOSをバックエンドとするブロックデバイスを提供する• 現在は”Ceph Block Device”が正式名称・・・っぽい︖• Linuxのカーネルモジュールまたはlibrbdのライブラリを利⽤する– マウントなど、通常のブロックデバイスと同等に利⽤出来る– 仮想化アプリケーションなどからはlibrbdにより柔軟な利⽤が可能• OpenStack Cinderのバックエンドとしてもよく使われる60
CephFSͤ ; ͑ ; ͑ ͢声 に 出 し て 読 み た い ︖ C e p h61
CephFSCeph File System• RADOSをバックエンドとしたPOSIX準拠のファイルシステムを提供する– もともとSage⽒はこれを実現したくてCephを開発した• LinuxのカーネルドライバーまたはFUSEを介してマウントする• ファイルデータとメタデータは別々に管理される– メタデータはCeph Metadata Server Daemon（MDS）を介して管理される– ファイルデータは直接クライアントからOSDにアクセスする• NFS-Ganeshaを⽤いてNFS Exportも可能– Ganesha⾃体はRGWをバックエンドにすることも可能• ただしこの場合は制約アリ62
MDS͑ Ή Ͱ ͌ ʔ ͑ ͢声 に 出 し て 読 み た い ︖ C e p h63
MDSCeph Metadata Server Daemon• CephFSのメタデータを管理する為のデーモン– CephFSのメタデータをメモリ上で管理している• 複数台起動することで冗⻑性や性能を向上できる– メタデータツリーを動的に分割して担当MDSを割当てる• 負荷の⾼い部分を動的に分割して管理• 障害MDSの担当部分を別MDSに引き継ぎ– メタデータはjournalとして記録される• 必要な情報はRADOSに格納されている• 再⽣することでメタデータを復旧可能• 障害が起きても別ノードが引き継いで稼働を継続できる64
CephFS構成の例65
CONCLUSIONま ・ と ・ め66
そもそもなんで今 Ceph 101︖⼀番⼤事なことを最後に⾔うスタイル• Cephはクラウド時代のSoftware Defined Storageの雄として君臨– ソフトウェアパゥワァーで柔軟な利⽤ができちゃう• Object/Block Storage、FileSystem、なんならAppから直接RADOSつかったり・・・• 様々なソフトウェアとの親和性が⾼く、⽤途の幅が広い– 専⽤ハードに依存しないDaemon群とライブラリ群• SPOFがなく、ドンドンスケールさせられる設計• コンテナ化してコンテナオーケストレーション基盤上に載せやすい67そこで
͕͔ͩ͠͠ʂʂ68
そもそもなんで今 Ceph 101︖⼀番⼤事なことを最後に⾔うスタイル• Operatorパゥワーにより簡単にデプロイできても〜– Cephのことを知らないままだと︖• PG内のOSD Podが全て同⼀ノードに・・・• MONのPodが全て同⼀ノードに・・・• MDSのP(略• CSRUSH Map未編集でラック障害でPG内のOSDが全部死・・・• なんかよく分からないけどOSD使い切って地獄 has come...• 速度を向上させたいけどどうしていいか分からない・・・• リソースの分配やネットワークの整備にも迷ってしまったり・・・• ⾊々な使い⽅ができるのに、結局使わないままに・・・などなど69
େৎʂʂ70
େৎʂʂ71なぜならもう
Cephを完全に理解こ の 話 、 覚 え て た ︖72
Cephを完全に理解終 わ っ た ら ツ イ ー ト し て ね ♪73したから・・・ね？
TIPSお ・ ま ・ け74
Cephと明⽇からいちゃつく君へ親⽗の⼩⾔的なアレを贈ります•Ϧιʔε͚ͪΔͳ•04%ৗʹ༨༟Λͯ•͍ωοτϫʔΫਖ਼ٛ•ݥ΄Ͳ΄Ͳʹ•શͯΛ੍ޚ͠Α͏ͱ͢Δͳ•Ϧόϥϯεͷিܸʹඋ͑Ζ•Ջ͕͋ͬͨΒDFQI TΛୟ͚75
REFERENCESあ り が た い 参 考 資 料 の 数 々 。76
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-5798951077
Ceph101 参考情報エマ先⽣（@Yuryu）のありがたい資料• Cephアーキテクチャー概説– https://www.slideshare.net/Yuryu/ceph-36503772• 分散ストレージ技術Cephの最新情報– https://www.slideshare.net/Yuryu/ceph-4263268978
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
頼んだよ︕5XFFUΕͳ͍ͰͶʂ81
tsukaman
unclejoe
.jpg){kind=avatar}
izzii
bengo4com
tatsuru
hirosatogamo
miyashino
yamasatimi
dahatake
lmi
junki
hamadakoji
yrhorita
geoffreycrofte
ddemaree
jcasabona
colly
eitanlees
addyosmani
notwaldorf
maltzj
cromwellryan
jennybc
danielanewman
chrislema