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

by Masataka Tsukamoto

Slide 1

Slide 1 text

「Ceph、完全に理解した」って Tweetする為のセッションｰ Ceph 101 ｰ＿・）つかまん @tsukaman https://bit.ly/JRM3_Ceph101

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 他 • 最近︓ 社畜業が捗る＆⾃宅仕事でモリモリ太る 2

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Cephを完全に理解終わったらツイートしてね ♪ 5 【参考】

Slide 6

Slide 6 text

Cephを完全に理解終わったらツイートしてね ♪ 6 【参考】

Slide 7

Slide 7 text

Cephを完全に理解終わったらツイートしてね ♪ 7 【参考】

Slide 8

Slide 8 text

ࠓ೔͸΄΅ ͜ͷϊϦͩΑʂ 8

Slide 9

Slide 9 text

STYLE このセッションのやり⼝は ︖ 9

Slide 10

Slide 10 text

他⼈様の褌で⼤相撲いやもう、偉⼤な先達の過去の資料が素晴らしすぎてね … 10

Slide 11

Slide 11 text

他⼈様の褌で⼤相撲いやもう、偉⼤達の過去の資料が素晴らしすぎてね … 11 そこでまずは

Slide 12

Slide 12 text

中井悦司先⽣（@enakai00）の⾮常にありがたぁ〜〜〜い資料 • CTC教育サービスコラム「クラウド時代のオープンソース実践活⽤」 – https://www.school.ctc-g.co.jp/columns/nakai/ • 第44回分散ストレージ技術「Ceph」のからくり • 第45回⼀味違うCephの「オブジェクトストア」とは • 第76回 Cephのクラスタ管理とデータ冗⻑化の仕組み • 第77回分散ファイルシステムCephFSのアーキテクチ 12

Slide 13

Slide 13 text

中井悦司先⽣（@enakai00）の⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 13

Slide 14

Slide 14 text

中井⼤先⽣（@enakai00）の⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 14 そして

Slide 15

Slide 15 text

岩尾”エマ”はるか先⽣（@Yuryu）の⾮常にありがたぁ〜〜〜い資料 • Cephアーキテクチャー概説 – https://www.slideshare.net/enakai/ceph-57989510 15

Slide 16

Slide 16 text

岩尾”エマ”はるか先⽣（@Yuryu）の⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 16

Slide 17

Slide 17 text

岩尾エマ先⽣（@Yuryu）の⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 17 おわかりいただけただろうか

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 あれ？なんか古い…？大丈夫？

Slide 21

Slide 21 text

େৎ෉ʂʂ 21

Slide 22

Slide 22 text

Cephに歴史あり歴史もあれば実績もある 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

The Big Picture of Ceph Architecture 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

The Big Picture of Ceph Architecture 33 これ

Slide 34

Slide 34 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） 34

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 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に報告する 41 OSD OSD OSD OSD OSD OSD

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 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と直接データのやりとりをする – 他の班員は班⻑の指⽰でデータコピーしたり、チャンク受け渡ししたりする 47

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

େৎ෉ʂʂ 49

Slide 50

Slide 50 text

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

Slide 51

Slide 51 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 51

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

The Big Picture of Ceph Architecture 54

Slide 55

Slide 55 text

The Big Picture of Ceph Architecture 55 こっち

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

CephFS構成の例 66

Slide 67

Slide 67 text

CONCLUSION ま・と・め 67

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

͕ͩ ͔͠͠ʂʂ 69

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

େৎ෉ʂʂ 71

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

REFERENCES ありがたい参考資料の数々つまりは他⼈様の褌・・・洗ってお返しせねば 75

Slide 76

Slide 76 text

その他の参考情報本当にありがとうございました • 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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

July Tech Festa 2020で話すよ︕ 今年も7⽉に開催とか凄くない︖ • ただ、ネタとしての本質情報は今⽇とあんまり変わらないです。 – まったく同じってのもアレですし、持ち時間も⻑いのでもうすこし内容を追加したりする予定です。 – 皆さんからの⽣暖かいフィードバックをお待ちしております。 ※ 当⽅、⾖腐メンタルなんでフルボッコはご容赦を・・・ｳｯｳｯ（涙） 78 https://techfesta.connpass.com/event/175611/