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
Rook-Cephでいろいろベンチとってみる
Search
Takuya Utsunomiya
March 27, 2020
Technology
2
6.3k
Rook-Cephでいろいろベンチとってみる
Rook-CephでいろいろIO測ってみました。
Takuya Utsunomiya
March 27, 2020
Tweet
Share
More Decks by Takuya Utsunomiya
See All by Takuya Utsunomiya
OpenShift Virtualizationのストレージ、しゃべりたいだけしゃべる / ocpv-storage
tutsunom
0
340
VMをPodで起動するKubeVirtの真髄 / KubeVirt
tutsunom
1
5.6k
オブジェクトストレージゲートウェイ:NooBaa / Object Storage Gateway NooBaa
tutsunom
1
970
Multi-Cloud Gatewayでデータを統治せよ!/ Data Federation with MCG
tutsunom
1
1.3k
運用者にやさしいOpenShift / OpenShift is operator-friendly
tutsunom
0
950
OpenShiftのクラスターバックアップリストア / OpenShift Cluster Backup Restore
tutsunom
2
2.2k
COSI (Container Object Storage Interface) で広がる永続ストレージの世界 / CNDT2021 COSI
tutsunom
0
1.5k
このろくでもない、すばらしきストレージの世界。/storage is brilliant
tutsunom
1
1k
Kasten K10でBackup&Restore / Kasten K10 Backup Restore
tutsunom
1
1.2k
Other Decks in Technology
See All in Technology
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
0
140
異業種出身エンジニアが気づいた、転向して十数年経っても変わらない自分の武器とは
macnekoayu
0
260
kubellが考える戦略と実行を繋ぐ活用ファーストのデータ分析基盤
kubell_hr
0
120
トヨタ生産方式(TPS)入門
recruitengineers
PRO
6
1.4k
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
150
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
2
1.9k
生成AI時代のデータ基盤設計〜ペースレイヤリングで実現する高速開発と持続性〜 / Levtech Meetup_Session_2
sansan_randd
1
110
Language Update: Java
skrb
1
130
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
shibayu36
0
160
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
10
700
ZOZOマッチのアーキテクチャと技術構成
zozotech
PRO
2
1.1k
ヒューリスティック評価を用いたゲームQA実践事例
gree_tech
PRO
0
420
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Fireside Chat
paigeccino
39
3.6k
How STYLIGHT went responsive
nonsquared
100
5.8k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
BBQ
matthewcrist
89
9.8k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Transcript
で いろいろベンチとってみる Takuya Utsunomiya Storage Solution Architect, Red Hat K.K.
apiVersion: apiextentions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: 宇都宮 卓也 spec: group:
レッドハット株式会社 role: ストレージソリューションアーキテクト born: 大阪 version: 38歳 favorites: technology: ストレージ hobby: [“野球好き”, “プロレス好き”,”将棋好き”] drink: [“ビール”, “ワイン”] @japan_rook Japan Rook https://rook.connpass.com/ 一部執筆 してます #japanrook 2
で 計測してみる
モチベーション • IO測るの楽しいから • バックエンドのストレージ直で使うのと Rook-Cephを挟むのとでどれくらい変わるかみたい • Cephの構成変えることでどれくらい変わるのか見たい • IO測るの楽しいから
◦ ほんとだよ? なんでIO計測とかするの? 4
環境 • k8s 1.16 on AWS • 3 master +
3 worker ◦ master : m5.xlarge (4vCPU, 16Gi RAM) ◦ worker : m5.4xlarge (16vCPU, 64Gi RAM) • Rook-Cephはworkerへ • Rook 1.2.7, Ceph 14.2.8 ◦ 最新の組み合わせ 5
遊びかた • FIO 3.13 ◦ Kubestoneのfioを使う ◦ Fio Custom Resourceが便利
• fioのPodから100GBのPVマウント(xfs)してIOかける • 4K random read, 4K random writeでIOPSとlatencyをみる • 他のFioのオプションは ----> ◦ 割と適当に… 6 [global] direct=1 size=1G ioengine=libaio overwrite=1 runtime=120 ramp_time=10 startdelay=10 time_based [rw-64] rw=randwrite directory=/tmp bs=4k iodepth=64 [rr-64] rw=randread directory=/tmp bs=4k iodepth=64 ...
何を測るか • 素のEBS(gp2) vs Rook-Ceph 3x replica RBD • Cephクラスタのosd数
◦ 3 osd vs 12 osd • レプリカ数 ◦ 3x replica RBD vs 2x replica RBD 7
None
補足説明 • イメージはこんな感じ ----> • gp2は1TB未満だと3,000IOPSが天井 • 事前の予想 「readは互角くらい」 「writeは純粋にEBSの方が3倍はやい」
9 node EBS node EBS node EBS osd osd osd RBD 3x replica EBS raw EBS(gp2)
結果 • ReadはRook-Cephの方がIOPSもlatencyも断然はやい ◦ 全osdからreadできるから3,000IOPS以上出せる • WriteはEBSの方がはやい。けど3倍もいかない。 ◦ 三重書きのオーバーヘッド ◦
とは言え負荷が高くなって天井に当たると変わらない 10 結論 : 負荷が低い時のwriteは結構違う。 個人的にはreadが強いRook-Cephの方が役に立つ気がする。
None
補足説明 • イメージはこんな感じ ----> • 合計容量は同じになるようにする ◦ 3 osd …
600Gi x 3 ◦ 12 osd … 150Gi x 12 • 事前の予想 「OSDの数が多い方がreadもwriteも圧倒的に はやいはず」 12 node EBS node EBS node EBS osd osd osd RBD node node node RBD 3x replica EBSEBSEBSEBS EBSEBSEBSEBS EBSEBSEBSEBS osd osd osd osd osd osd osd osd osd osd osd osd 3x replica
結果 • やっぱりosdが多いほうがはやい ◦ 負荷が高いほうが違いがはっきりする • osdの容量を増やすよりScale-Outする方が断然おすすめ 13 結論 :
なにはともあれosdが多い方が正義。
None
補足説明 • イメージはこんな感じ ----> • Cephは3x replicaが主流だけど2x replicaもで きる。もちろんnodeをまたいで複製する。 •
利用可能容量は増えるけど、二重障害で data lossになるリスクがある。 • 事前の予想 「readはどちらも同じくらい」 「writeは2x replicaの方がはやい」 15 node node node RBD 2x replica EBSEBSEBSEBS EBSEBSEBSEBS EBSEBSEBSEBS osd osd osd osd osd osd osd osd osd osd osd osd node node node RBD 3x replica EBSEBSEBSEBS EBSEBSEBSEBS EBSEBSEBSEBS osd osd osd osd osd osd osd osd osd osd osd osd
結果 • Readは3xの方がちょっとはやい ◦ 2xの方がprimary osd偏りやすい?運ゲー? ◦ pg数を増やせば同じくらいになる? • Writeは2xの方がはやい
◦ さすがに二重書きの方がオーバーヘッド少ない 16 結論 : writeは結構変わる。 冗長性を取るか、write速い&少ない容量消費を取るか。
まとめ どうだった? 17 • テストケースが少ないけれど大まかな傾向は見えた。 • パブリッククラウドみたいにストレージに QoSをかけられている環境では Rook-Cephは限界突 破する手段になる。
• とにかくosdはたくさんあるに越したことない。 • Write intensiveな用途では2x replicaも一つの手。 • 12osdにするとなかなか4x3で分散してくれなくて困った。 TopologySpreadConstraintsサ ポートが待たれる。 • やっぱりIO測るのは楽しい。
18