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

Slide 1

Slide 1 text

Ceph 101: “ワタシハセフチョットデキル” への道＿・）つかまん @tsukaman https://bit.ly/JTF2020-F6

Slide 2

Slide 2 text

誰？ • 名前︓ ＿・）つかまん（@tsukaman） • 仕事︓ HPE / Pointnext Hybrid IT Practice • 役割︓ 打楽器、Cloud Solution Architect • 書籍︓ Ansible実践ガイド第3版、Raspberry Pi〔実⽤〕⼊⾨ • 好き︓ せがれいじり、ガジェットIYH、眼鏡、楽しいこと • 参加︓ Cloud Native Days Tokyo、 RancherJP、Tokyo HackerSpace 他 • 最近︓ 毎⽇のようにAmazonさんや楽天さんやヨドバシさん等からモノが届くぜ・・・ 2

Slide 3

Slide 3 text

はじめに先に⾔わなければならないことがあります。 3

Slide 4

Slide 4 text

今回の発表内容について実は 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

Slide 5

Slide 5 text

GOAL このセッションは何を⽬指すか 5

Slide 6

Slide 6 text

セフチョットデキルまぁ、セッションタイトルがコレだし ︖ 6

Slide 7

Slide 7 text

͍΍ʂ ͪΐͬͱ·ͯʂ 7

Slide 8

Slide 8 text

セフチョットデキルまぁ、セッションタイトルがコレだし ︖ 8 【参考】

Slide 9

Slide 9 text

セフチョットデキルまぁ、セッションタイトルがコレだし ︖ 9 【参考】

Slide 10

Slide 10 text

セフチョットデキルまぁ、セッションタイトルがコレだし ︖ 10 いきなりここまでは無理ﾎﾟﾖ

Slide 11

Slide 11 text

セフチョットデキルまぁ、セッションタイトルがコレだし ︖ 11 なのでまずは

Slide 12

Slide 12 text

Cephを完全に理解意訳 ︓ C e p h のチュートリアル終わった 12

Slide 13

Slide 13 text

ऴΘͬͨΒ 5XFFUΑΖ͘͠ʂ 13

Slide 14

Slide 14 text

OVERVIEW C e p h って⼀体なにやつ ︖ 14

Slide 15

Slide 15 text

Cephさんマジイケ頭⾜類 C e p h ≓ C e p h a l o p o d : 頭⾜類 15

Slide 16

Slide 16 text

イケてる頭⾜類Cephさんのマジ♥惚れ♥ポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystem、え、他にも・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPIに・・・Kernel Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 16

Slide 17

Slide 17 text

イケてる頭⾜類Cephさんのマジ惚れポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕︕︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕ • なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystemにNFS・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPI・・・え、Kernerl Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります（真顔）。でも、専⽤ハードは必要なし・・・惚れる︕ 17 【参考】謎カッコイイPR動画 https://youtu.be/QBkH1g4DuKE

Slide 18

Slide 18 text

センター試験に出る Cephの歴史（ざっくり版） • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている • 細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

センター試験に出る Cephの歴史（ざっくり版） • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース • 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる（2つ後のメジャーリリースでEOL） 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Cephを味わう C e p h さんの中⾝をみてみましょう。 22

Slide 23

Slide 23 text

ARCHITECTURE C e p h を構成するアレやコレや 23

Slide 24

Slide 24 text

The Big Picture of Ceph Architecture 24

Slide 25

Slide 25 text

RADOS Ε ͌ Ͳ ͢ 声に出して読みたい ︖ C e p h 25

Slide 26

Slide 26 text

The Big Picture of Ceph Architecture 26 これ

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

• 実際にはこんなかんじ – 各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

Slide 29

Slide 29 text

MON ΋ Μ 声に出して読みたい ︖ C e p h 29

Slide 30

Slide 30 text

MON Ceph Monitor Daemon • クラスターの状態を監視し「クラスターマップ」を作成/更新/配布する – クラスターマップには次のマップが含まれる • Monitor Map、OSD Map、PG Map、CRUSH Map、MDS Map – このマップさえあれば計算でオブジェクトの配置場所を算出できる • つまりこのマップはCRUSHアルゴリズムのために超重要 • クライアントもこのマップを利⽤することで直接OSDアクセスが可能に。 • 障害やノード追加などで構成変更が発⽣する場合の指⽰とかを出す • 通常は冗⻑性を考慮して3台以上の奇数台数のMONノードを配置 – 分散合意形成プロトコルのPaxosを使う為に奇数である必要がある • cephコマンドを実⾏した時に返答してくれるのもMONさん 30 MON

Slide 31

Slide 31 text

MGR ͑ Ή ͡ ͌ ͋ ʙ Δ 声に出して読みたい ︖ C e p h 31

Slide 32

Slide 32 text

MGR Ceph Manager Daemon • わりと最近︖（12.xのluminous以降）ほぼ必須となったデーモン • MONと⼀緒に動き、外部へ監視情報を提供したりする – Cephクラスターのステータス出⼒の補助的な役割も持つ • Ceph Dashboard（管理⽤WebUI）の機能を提供する 32 MON MGR

Slide 33

Slide 33 text

OSD ͓ ͎ ͑ ͢ Ͱ ͌ 声に出して読みたい ︖ C e p h 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

HOW TO LOCATE? ここが C e p h のすごいところ 35

Slide 36

Slide 36 text

CRUSH ͘ Β ͬ ͠ Ύ ʂ 声に出して読みたい ︖ C e p h 36

Slide 37

Slide 37 text

CRUSH algorithm Controlled Replication Under Scalable Hashing • RADOS上でオブジェクトをどのOSDに配置するか決定するアルゴリズム • 配置先はクラスターマップがあれば100%計算だけで算出できる – メタデータを中央集約するサーバーが不要 • ボトルネックや単⼀障害点がないので、拡張性が⾼くなる • マップをもつクライアントが直接OSDにアクセスできる • 配置先の決定に重要な要素 – Pool – CRUSH Map – CRUSH rule – Placement Group（PG） 37

Slide 38

Slide 38 text

Pool • オブジェクトを保存するための論理的な領域 • デフォルトのPoolのほか任意で作成することが可能 • 各プール単位で異なる設定をとることができる – 耐障害性 • Replication - オブジェクトを複製することで冗⻑性を担保。性能が良いが⾼コスト。 • Erasure Coding - RAID5/6のようにパリティで冗⻑性を担保。低コストだが⾼負荷。 – Placement Group数（後述します） – CRUSH Rule（後述します） – クォータ – 圧縮 – 紐つけるアプリケーション（⽤途） – 所有者等 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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の組み合わせ

Slide 44

Slide 44 text

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 これこれこれ

Slide 45

Slide 45 text

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 これこれこれの事をこう呼びます

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

PG Placement Group • PG数はPool毎の要件や状況に応じて原則⼿動で設定・調整をする – この部分が多くのCeph運⽤者を悩ませてきた・・・ • 最適なPG数を割り出すのに熟練された職⼈の腕が必要になる – PG数が極端に少ないと → OSD間の利⽤量の偏りが⼤きくなる – PG数が極端に多いと → 構成が複雑になり⾃律制御に多くのリソースが必要になる – ⼀応、算出ツール（Ceph PGs per Pool Calculator）もある・・・が、わりと初⾒殺し • https://ceph.com/pgcalc/ – 使う予定のPoolとか将来的なOSDの追加予定とかも加味して算出・・・ • PG数は⼀度⼤きくしたら、⼩さくできない – 状況を確認しつつ、適切に値を増やしていく運⽤になる – ⼀気にあげすぎると、構成変更の影響で⾼負荷状態に陥る可能性も・・・ 47

Slide 48

Slide 48 text

େৎ෉ʂʂ 48

Slide 49

Slide 49 text

49 https://ceph.io/rados/new-in-nautilus-pg-merging-and-autotuning/

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

クライアントからのアクセスの流れどのように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

Slide 52

Slide 52 text

HOW TO COMMUNICATE? R A D O S とお喋りする⾊々な⽅法 52

Slide 53

Slide 53 text

The Big Picture of Ceph Architecture 53

Slide 54

Slide 54 text

The Big Picture of Ceph Architecture 54 こっち

Slide 55

Slide 55 text

librados Γ Ϳ Ε ͌ Ͳ ͢ 声に出して読みたい ︖ C e p h 55

Slide 56

Slide 56 text

librados library of using RADOS • 独⾃アプリケーションからRADOSを利⽤する為のライブラリ – librados APIによりMONやODSとの直接通信が可能となる – 各種プログラミング⾔語向けのライブラリが公式で⽤意されている • C++、C、Python、Java、PHP – その他の⾔語でもライブラリを開発/公開している⼈が居たりする 56

Slide 57

Slide 57 text

RadosGW Ε ͌ Ͳ ͢ ͛ ʔ ͱ ΢ Σ ʔ Π 声に出して読みたい ︖ C e p h 57

Slide 58

Slide 58 text

RadosGW RADOS Gateway • RADOSへのRESTfulなゲートウェイを提供するためのインタフェース – RadosGW⾃⾝もlibradosを⽤いて通信の仲介をしているクライアント • 現在は”Ceph Object Gateway”が正式名称・・・っぽい︖ • 次の2種類のインターフェースを提供する – Amazon S3 RESTful API 互換インタフェース – OpenStack Swift API 互換インタフェース 58

Slide 59

Slide 59 text

RBD ͋ ʙ Δ ͼ ͌ Ͱ ͌ 声に出して読みたい ︖ C e p h 59

Slide 60

Slide 60 text

RBD RADOS Block Device • RADOSをバックエンドとするブロックデバイスを提供する • 現在は”Ceph Block Device”が正式名称・・・っぽい︖ • Linuxのカーネルモジュールまたはlibrbdのライブラリを利⽤する – マウントなど、通常のブロックデバイスと同等に利⽤出来る – 仮想化アプリケーションなどからはlibrbdにより柔軟な利⽤が可能 • OpenStack Cinderのバックエンドとしてもよく使われる 60

Slide 61

Slide 61 text

CephFS ͤ ; ͑ ; ͑ ͢ 声に出して読みたい ︖ C e p h 61

Slide 62

Slide 62 text

CephFS Ceph File System • RADOSをバックエンドとしたPOSIX準拠のファイルシステムを提供する – もともとSage⽒はこれを実現したくてCephを開発した • LinuxのカーネルドライバーまたはFUSEを介してマウントする • ファイルデータとメタデータは別々に管理される – メタデータはCeph Metadata Server Daemon（MDS）を介して管理される – ファイルデータは直接クライアントからOSDにアクセスする • NFS-Ganeshaを⽤いてNFS Exportも可能 – Ganesha⾃体はRGWをバックエンドにすることも可能 • ただしこの場合は制約アリ 62

Slide 63

Slide 63 text

MDS ͑ Ή Ͱ ͌ ʔ ͑ ͢ 声に出して読みたい ︖ C e p h 63

Slide 64

Slide 64 text

MDS Ceph Metadata Server Daemon • CephFSのメタデータを管理する為のデーモン – CephFSのメタデータをメモリ上で管理している • 複数台起動することで冗⻑性や性能を向上できる – メタデータツリーを動的に分割して担当MDSを割当てる • 負荷の⾼い部分を動的に分割して管理 • 障害MDSの担当部分を別MDSに引き継ぎ – メタデータはjournalとして記録される • 必要な情報はRADOSに格納されている • 再⽣することでメタデータを復旧可能 • 障害が起きても別ノードが引き継いで稼働を継続できる 64

Slide 65

Slide 65 text

CephFS構成の例 65

Slide 66

Slide 66 text

CONCLUSION ま・と・め 66

Slide 67

Slide 67 text

そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Cephはクラウド時代のSoftware Defined Storageの雄として君臨 – ソフトウェアパゥワァーで柔軟な利⽤ができちゃう • Object/Block Storage、FileSystem、なんならAppから直接RADOSつかったり・・・ • 様々なソフトウェアとの親和性が⾼く、⽤途の幅が広い – 専⽤ハードに依存しないDaemon群とライブラリ群 • SPOFがなく、ドンドンスケールさせられる設計 • コンテナ化してコンテナオーケストレーション基盤上に載せやすい 67 そこで

Slide 68

Slide 68 text

͕ͩ ͔͠͠ʂʂ 68

Slide 69

Slide 69 text

そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Operatorパゥワーにより簡単にデプロイできても〜 – Cephのことを知らないままだと︖ • PG内のOSD Podが全て同⼀ノードに・・・ • MONのPodが全て同⼀ノードに・・・ • MDSのP(略 • CSRUSH Map未編集でラック障害でPG内のOSDが全部死・・・ • なんかよく分からないけどOSD使い切って地獄 has come... • 速度を向上させたいけどどうしていいか分からない・・・ • リソースの分配やネットワークの整備にも迷ってしまったり・・・ • ⾊々な使い⽅ができるのに、結局使わないままに・・・などなど 69

Slide 70

Slide 70 text

େৎ෉ʂʂ 70

Slide 71

Slide 71 text

େৎ෉ʂʂ 71 なぜならもう

Slide 72

Slide 72 text

Cephを完全に理解この話、覚えてた ︖ 72

Slide 73

Slide 73 text

Cephを完全に理解終わったらツイートしてね ♪ 73 したから・・・ね？

Slide 74

Slide 74 text

TIPS お・ま・け 74

Slide 75

Slide 75 text

Cephと明⽇からいちゃつく君へ親⽗の⼩⾔的なアレを贈ります •Ϧιʔε͸͚ͪΔͳ •04%͸ৗʹ༨༟Λ΋ͯ •଎͍ωοτϫʔΫ͸ਖ਼ٛ •๯ݥ͸΄Ͳ΄Ͳʹ •શͯΛ੍ޚ͠Α͏ͱ͢Δͳ •Ϧόϥϯεͷিܸʹඋ͑Ζ •Ջ͕͋ͬͨΒDFQI TΛୟ͚ 75

Slide 76

Slide 76 text

REFERENCES ありがたい参考資料の数々。 76

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

Ceph101 参考情報エマ先⽣（@Yuryu）のありがたい資料 • Cephアーキテクチャー概説 – https://www.slideshare.net/Yuryu/ceph-36503772 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 78

Slide 79

Slide 79 text

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