Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「Ceph、完全に理解した」って Tweetする為のセッション ー Ceph 101 ー
Search
Masataka Tsukamoto
July 03, 2020
Technology
10
7.4k
「Ceph、完全に理解した」って Tweetする為のセッション ー Ceph 101 ー
Japan Rook Meetup #3での発表スライドです。Ceph、完全に理解した」って Tweetしてもらう為に、Cephの基本について解説しています。
Masataka Tsukamoto
July 03, 2020
Tweet
Share
More Decks by Masataka Tsukamoto
See All by Masataka Tsukamoto
インフラSIおじさんが贈る"バズったからってこういう安直な提案はするな!& 乗るな!"
tsukaman
1
470
地雷を避けながら進むEKS - 俺の屍を超えていけ -
tsukaman
2
1.8k
Ceph101: "ワタシハ セフ チョットデキル"への道
tsukaman
1
760
泣きながらPacker/Ansible provisionerでつくるWindows AMI
tsukaman
5
2.2k
Apache Mesos is 何?
tsukaman
1
1.5k
Rancherのヤツ知ってる?いや、そっちじゃなくてLonghornのほう
tsukaman
6
5.7k
Cloud Nativeな俺のCI/CD環境 〜 GitLab x Rancher で夢見るイケてる世界 〜
tsukaman
5
1.7k
Other Decks in Technology
See All in Technology
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
260
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
9
41k
夏休みの(最後の)宿題 for JuliaTokyo #12
antimon2
0
130
waitany と waitall を作った話
mrkn
0
110
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
540
20240906_JAWS_Yamanashi_#1_leap_beyond_the_AWS_all_certifications
tsumita
1
190
[RSJ24] Object Retrieval in Large-Scale Indoor Environments Using Dense Text with a Multi-Modal Large Language Model
keio_smilab
PRO
0
230
Envoy External AuthZとgRPC Extensionを利用した「頑張らない」Microservices認証認可基盤
andoshin11
0
180
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
160
リクルート新人研修2024 テキスト生成AI活用
recruitengineers
PRO
10
450
セキュリティ監視の内製化 効率とリスク
mixi_engineers
PRO
7
780
Chunk computing
matyo91
0
270
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
334
56k
Code Review Best Practice
trishagee
62
16k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
103
47k
StorybookのUI Testing Handbookを読んだ
zakiyama
25
5k
Practical Orchestrator
shlominoach
185
10k
A Modern Web Designer's Workflow
chriscoyier
690
190k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
Transcript
「Ceph、完全に理解した」って Tweetする為のセッション ー Ceph 101 ー _・)つかまん @tsukaman https://bit.ly/JRM3_Ceph101
誰? • 名前︓ _・) つかまん (@tsukaman) • 仕事︓ HPE /
Pointnext Hybrid IT Practice • 役割︓ 打楽器、Cloud Solution Architect • 書籍︓ Ansible実践ガイド 第3版、Raspberry Pi〔実⽤〕⼊⾨ • 好き︓ せがれいじり、ガジェットIYH、眼鏡、楽しいこと • 参加︓ Cloud Native Days Tokyo、 RancherJP、Tokyo HackerSpace 他 • 最近︓ 社畜業が捗る & ⾃宅仕事でモリモリ太る 2
GOAL こ の セ ッ シ ョ ン は 何
を ⽬ 指 す か 3
Cephを 完全に 理解 終 わ っ た ら ツ イ
ー ト し て ね ♪ 4
Cephを 完全に 理解 終 わ っ た ら ツ イ
ー ト し て ね ♪ 5 【参考】
Cephを 完全に 理解 終 わ っ た ら ツ イ
ー ト し て ね ♪ 6 【参考】
Cephを 完全に 理解 終 わ っ た ら ツ イ
ー ト し て ね ♪ 7 【参考】
ࠓ΄΅ ͜ͷϊϦͩΑʂ 8
STYLE こ の セ ッ シ ョ ン の や
り ⼝ は ︖ 9
他⼈様の 褌で ⼤相撲 い や も う 、 偉 ⼤
な 先 達 の 過 去 の 資 料 が 素 晴 ら し す ぎ て ね … 10
他⼈様の 褌で ⼤相撲 い や も う 、 偉 ⼤
達 の 過 去 の 資 料 が 素 晴 ら し す ぎ て ね … 11 そこで まずは
中井悦司先⽣(@enakai00)の ⾮常にありがたぁ〜〜〜い資料 • CTC教育サービス コラム「クラウド時代のオープンソース実践活⽤」 – https://www.school.ctc-g.co.jp/columns/nakai/ • 第44回 分散ストレージ技術「Ceph」のからくり
• 第45回 ⼀味違うCephの「オブジェクトストア」とは • 第76回 Cephのクラスタ管理とデータ冗⻑化の仕組み • 第77回 分散ファイルシステムCephFSのアーキテクチ 12
中井悦司先⽣(@enakai00)の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 13
中井⼤先⽣(@enakai00)の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージソフトウェアCeph アーキテクチャー概要 – https://www.slideshare.net/enakai/ceph-57989510 14 そして
岩尾”エマ”はるか先⽣(@Yuryu)の ⾮常にありがたぁ〜〜〜い資料 • Cephアーキテクチャー概説 – https://www.slideshare.net/enakai/ceph-57989510 15
岩尾”エマ”はるか先⽣(@Yuryu)の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 16
岩尾エマ先⽣(@Yuryu)の ⾮常にありがたぁ〜〜〜い資料 2 • 分散ストレージ技術Cephの最新情報 – https://www.slideshare.net/Yuryu/ceph-42632689 17 おわかり いただけた
だろうか
18
19
20 あれ? なんか古い…? 大丈夫?
େৎʂʂ 21
Cephに 歴史 あり 歴 史 も あ れ ば 実
績 も あ る 22
センター試験に出る Cephの歴史(ざっくり版) • 2003年頃よりカリフォルニア⼤学サンタクルーズ校にて開発される – Sage Weil⽒を中⼼に研究・開発が進められ、成果が論⽂として発表される • RADOS、CRUSHといったCephの本質的な基幹技術が論⽂として公開されている •
細かい機能追加や変更はあれど、原理的な部分は当初から洗練されている – 2012年にSage⽒をファウンダ/CTOとしてInktankが設⽴ – 2014年にRed HatがInktankを買収 • ちなみに・・・ – Amazon S3 は 2006年3⽉にリリース – OpenStack Swift は 2010年10⽉にリリース 23
センター試験に出る 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
センター試験に出る Cephの歴史(ざっくり版) • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース
• 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる(2つ後のメジャーリリースでEOL) 25
センター試験に出る Cephの歴史(ざっくり版) • 現在の最新リリースは 15.x Octopus – 各メジャーリリースには、アルファベット順で頭⾜類の名前がつけられる – 以前は早かったが、現在は1年に1回のペースでメジャーリリース
• 毎年3⽉をリリース⽬標としているらしい – ライフサイクルは約2年間とされる(2つ後のメジャーリリースでEOL) 26 【おまけ】 Cephのロゴ https://ceph.io/logos/ 各リリース毎にロゴがある
イケてる頭⾜類Cephさんの マジ♥惚れ♥ポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕
• なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystem、え、他にも・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPIに・・・Kernel Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります(真顔)。でも、専⽤ハードは必要なし・・・惚れる︕ 27
イケてる頭⾜類Cephさんの マジ惚れポイント • 頼れる背中︕ – SPOFなし︕冗⻑性もバッチリ︕︕なにその⾼い信頼性・・・惚れる︕︕︕ • 無限の伸びしろ︕ – ノード1万台以上︕いくぜエクサバイト︕スケール幅がエグい・・・惚れる︕
• なんでもこなすイケメン︕ – ObjectStorage、BlockDev、FileSystemにNFS・・・しゅごい万能・・・惚れる︕ • 勝⼿に〇〇︕ – 勝⼿にリバランス︕勝⼿にスクラブ︕運⽤負担をさらう怪盗・・・惚れる︕ • コミュニケーションモンスター︕ – 各⾔語ライブラリに種々のAPI・・・え、Kernerl Moduleまで︕︖・・・惚れる︕ • でも、お⾼いんでしょ︖ – 規模によります(真顔)。でも、専⽤ハードは必要なし・・・惚れる︕ 28 【参考】 謎カッコイイPR動画 https://youtu.be/QBkH1g4DuKE
Cephを 味わう C e p h さ ん の 中
⾝ を み て み ま し ょ う 。 29
ARCHITECTURE C e p h を 構 成 す る
ア レ や コ レ や 30
The Big Picture of Ceph Architecture 31
RADOS Ε ͌ Ͳ ͢ 声 に 出 し て
読 み た い ︖ C e p h 32
The Big Picture of Ceph Architecture 33 これ
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
• 実際にはこんなかんじ – 各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
MON Μ 声 に 出 し て 読 み
た い ︖ C e p h 36
MON Ceph Monitor Daemon • クラスターの状態を監視し「クラスターマップ」を作成/更新/配布する – クラスターマップには次のマップが含まれる • Monitor
Map、OSD Map、PG Map、CRUSH Map、MDS Map – このマップさえあれば計算でオブジェクトの配置場所を算出できる • つまりこのマップはCRUSHアルゴリズムのために超重要 • クライアントもこのマップを利⽤することで直接OSDアクセスが可能に。 • 障害やノード追加などで構成変更が発⽣する場合の指⽰とかを出す • 通常は冗⻑性を考慮して3台以上の奇数台数のMONノードを配置 – 分散合意形成プロトコルのPaxosを使う為に奇数である必要がある • cephコマンドを実⾏した時に返答してくれるのもMONさん 37 MON
MGR ͑ Ή ͡ ͌ ͋ ʙ Δ 声 に
出 し て 読 み た い ︖ C e p h 38
MGR Ceph Manager Daemon • わりと最近︖(12.xのluminous以降)ほぼ必須となったデーモン • MONと⼀緒に動き、外部へ監視情報を提供したりする – Cephクラスターのステータス出⼒の補助的な役割も持つ
• Ceph Dashboard(管理⽤WebUI)の機能を提供する 39 MON MGR
OSD ͓ ͎ ͑ ͢ Ͱ ͌ 声 に 出
し て 読 み た い ︖ C e p h 40
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
HOW TO LOCATE? こ こ が C e p h
の す ご い と こ ろ 42
CRUSH ͘ Β ͬ ͠ Ύ ʂ 声 に 出
し て 読 み た い ︖ C e p h 43
CRUSH algorithm Controlled Replication Under Scalable Hashing • RADOS上でオブジェクトをどのOSDに配置するか決定するアルゴリズム •
配置先はクラスターマップがあれば100%計算だけで算出できる – メタデータを中央集約するサーバーが不要 • ボトルネックや単⼀障害点がないので、拡張性が⾼くなる • マップをもつクライアントが直接OSDにアクセスできる • 配置先の決定に重要な要素 – Pool – CRUSH Map – CRUSH rule – Placement Group(PG) 44
Pool • オブジェクトを保存するための論理的な領域 • デフォルトのPoolのほか任意で作成することが可能 • 各プール単位で異なる設定をとることができる – 耐障害性 •
Replication - オブジェクトを複製することで冗⻑性を担保。性能が良いが⾼コスト。 • Erasure Coding - RAID5/6のようにパリティで冗⻑性を担保。低コストだが⾼負荷。 – Placement Group数 – CRUSH Rule – クォータ – 圧縮 – 紐つけるアプリケーション(⽤途) – 所有者 等 45
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
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
PG Placement Group • PG数はPool毎の要件や状況に応じて設定・調整をする – この部分が多くのCeph運⽤者を悩ませてきた・・・ • 最適なPG数を割り出すのに熟練された職⼈の腕が必要になる –
PG数が極端に少ないと → OSD間の利⽤量の偏りが⼤きくなる – PG数が極端に多いと → 構成が複雑になり⾃律制御に多くのリソースが必要になる – ⼀応、算出ツール(Ceph PGs per Pool Calculator)もある・・・が、わりと初⾒殺し • https://ceph.com/pgcalc/ – 使う予定のPoolとか将来的なOSDの追加予定とかも加味して算出・・・ • PG数は⼀度⼤きくしたら、⼩さくできない – 状況を確認しつつ、適切に値を増やしていく運⽤になる – ⼀気にあげすぎると、構成変更の影響で⾼負荷状態に陥る可能性も・・・ 48
େৎʂʂ 49
50 https://ceph.io/rados/new-in-nautilus-pg-merging-and-autotuning/
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
クライアントからのアクセスの流れ どのように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
HOW TO COMMUNICATE? R A D O S と お
喋 り す る ⾊ 々 な ⽅ 法 53
The Big Picture of Ceph Architecture 54
The Big Picture of Ceph Architecture 55 こっち
librados Γ Ϳ Ε ͌ Ͳ ͢ 声 に 出
し て 読 み た い ︖ C e p h 56
librados library of using RADOS • 独⾃アプリケーションからRADOSを利⽤する為のライブラリ – librados APIによりMONやODSとの直接通信が可能となる
– 各種プログラミング⾔語向けのライブラリが公式で⽤意されている • C++、C、Python、Java、PHP – その他の⾔語でもライブラリを開発/公開している⼈が居たりする 57
RadosGW Ε ͌ Ͳ ͢ ͛ ʔ ͱ Σ
ʔ Π 声 に 出 し て 読 み た い ︖ C e p h 58
RadosGW RADOS Gateway • RADOSへのRESTfulなゲートウェイを提供するためのインタフェース – RadosGW⾃⾝もlibradosを⽤いて通信の仲介をしているクライアント • 現在は”Ceph Object
Gateway”が正式名称・・・っぽい︖ • 次の2種類のインターフェースを提供する – Amazon S3 RESTful API 互換インタフェース – OpenStack Swift API 互換インタフェース 59
RBD ͋ ʙ Δ ͼ ͌ Ͱ ͌ 声 に
出 し て 読 み た い ︖ C e p h 60
RBD RADOS Block Device • RADOSをバックエンドとするブロックデバイスを提供する • 現在は”Ceph Block Device”が正式名称・・・っぽい︖
• Linuxのカーネルモジュールまたはlibrbdのライブラリを利⽤する – マウントなど、通常のブロックデバイスと同等に利⽤出来る – 仮想化アプリケーションなどからはlibrbdにより柔軟な利⽤が可能 • OpenStack Cinderのバックエンドとしてもよく使われる 61
CephFS ͤ ; ͑ ; ͑ ͢ 声 に 出
し て 読 み た い ︖ C e p h 62
CephFS Ceph File System • RADOSをバックエンドとしたPOSIX準拠のファイルシステムを提供する – もともとSage⽒はこれを実現したくてCephを開発した • LinuxのカーネルドライバーまたはFUSEを介してマウントする
• ファイルデータとメタデータは別々に管理される – メタデータはCeph Metadata Server Daemon(MDS)を介して管理される – ファイルデータは直接クライアントからOSDにアクセスする • NFS-Ganeshaを⽤いてNFS Exportも可能 – Ganesha⾃体RGWをバックエンドに することも可能 • ただしこの場合は制約アリ 63
MDS ͑ Ή Ͱ ͌ ʔ ͑ ͢ 声 に
出 し て 読 み た い ︖ C e p h 64
MDS Ceph Metadata Server Daemon • CephFSのメタデータを管理する為のデーモン – CephFSのメタデータをメモリ上で管理している •
複数台起動することで冗⻑性や性能を向上できる – メタデータツリーを動的に分割して担当MDSを割当てる • 負荷の⾼い部分を動的に分割して管理 • 障害MDSの担当部分を別MDSに引き継ぎ – メタデータはjournalとして記録される • 必要な情報はRADOSに格納されている • 再⽣することでメタデータを復旧可能 • 障害が起きても別ノードが引き継いで稼働を継続できる 65
CephFS構成の例 66
CONCLUSION ま ・ と ・ め 67
そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Cephはクラウド時代のSoftware Defined Storageの雄として君臨 – ソフトウェアパゥワァーで柔軟な利⽤ができちゃう
• Object/Block Storage、FileSystem、なんならAppから直接RADOSつかったり・・・ • 様々なソフトウェアとの親和性が⾼く、⽤途の幅が広い – 専⽤ハードに依存しないDaemon群とライブラリ群 • SPOFがなく、ドンドンスケールさせられる設計 • コンテナ化してコンテナオーケストレーション基盤上に載せやすい 68 そこで
͕ͩ ͔͠͠ʂʂ 69
そもそもなんで今 Ceph 101︖ ⼀番⼤事なことを最後に⾔うスタイル • Operatorパゥワーにより簡単にデプロイできても〜 – Cephのことを知らないままだと︖ • PG内のOSD
Podが全て同⼀ノードに・・・ • MONのPodが全て同⼀ノードに・・・ • MDSのP(略 • CSRUSH Map未編集でラック障害でPG内のOSDが全部死・・・ • なんかよく分からないけどOSD使い切って地獄 has come... • 速度を向上させたいけどどうしていいか分からない・・・ • リソースの分配やネットワークの整備にも迷ってしまったり・・・ • ⾊々な使い⽅ができるのに、結局使わないままに・・・ などなど 70
େৎʂʂ 71
େৎʂʂ 72 なぜなら もう
Cephを 完全に 理解 こ の 話 、 覚 え て
た ︖ 73
Cephを 完全に 理解 終 わ っ た ら ツ イ
ー ト し て ね ♪ 74 したから ・・・ね?
REFERENCES あ り が た い 参 考 資 料
の 数 々 つ ま り は 他 ⼈ 様 の 褌 ・ ・ ・ 洗 っ て お 返 し せ ね ば 75
その他の参考情報 本当にありがとうございました • 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
その他の参考情報 本当にありがとうございました • 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...
July Tech Festa 2020で話すよ︕ 今年も7⽉に開催とか凄くない︖ • ただ、ネタとしての本質情報は今⽇とあんまり変わらないです。 – まったく同じってのもアレですし、持ち時間も⻑いので もうすこし内容を追加したりする予定です。
– 皆さんからの⽣暖かいフィードバックをお待ちしております。 ※ 当⽅、⾖腐メンタルなんでフルボッコはご容赦を・・・ウッウッ(涙) 78 https://techfesta.connpass.com/event/175611/
またな︕ 79
頼んだよ︕ 5XFFU Εͳ͍ͰͶʂ 80