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
Satoru Takeuchi
PRO
April 02, 2021
Technology
3
5.2k
プロダクション向けRook/Cephクラスタ構築への道
以下イベントの発表資料です。
https://rook.connpass.com/event/202147/
Satoru Takeuchi
PRO
April 02, 2021
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Linuxの時間を10秒止める
sat
PRO
2
58
プロセスへのメモリ割り当て4 - 実際に使うときにメモリを獲得するデマンドページング(実践編)
sat
PRO
1
22
プロセスへのメモリ割り当て(3) 実際に使うときにメモリを獲得するデマンドページング
sat
PRO
1
29
プロセスへのメモリ割り当て(1) mmap
sat
PRO
2
45
プロセスへのメモリ割り当て2-Pythonのようなナウい言語ではどうやってメモリ獲得するのか
sat
PRO
1
38
サイボウズのOSPO
sat
PRO
3
230
無いはずのパーティションがある Phantom Atari Partition
sat
PRO
1
42
仮想アドレスから物理アドレスにはどうやって変換するの?
sat
PRO
2
78
仮想アドレスと物理アドレスの対応を実機確認してみよう
sat
PRO
0
58
Other Decks in Technology
See All in Technology
Classmethod Odyssey 登壇資料
yamahiro
0
390
AWSで”最小権限の原則”を実現するための考え方 /20240722-ssmjp-aws-least-privilege
opelab
10
4.3k
AutomatedLabを使って内部ペンテストを勉強しよう! -やられ社内ネットワークの自動構築-
n_etupirka
1
610
AOAI Dev Day - Opening Session
yoshidashingo
2
430
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
Azure Pipelinesを使用したCICDベースラインアーキテクチャ実践
yuriemori
0
190
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
ソフトウェアエンジニアリングの知見を活かして データ基盤をいい感じにする on Snowflake [MIERUNE BBQ #10]
mtpooh
2
150
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
地理情報とAPIのトレンド
nagix
0
160
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
17
8.7k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
The Language of Interfaces
destraynor
151
23k
Testing 201, or: Great Expectations
jmmastey
33
6.9k
Web development in the modern age
philhawksworth
203
10k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
Faster Mobile Websites
deanohume
303
30k
Into the Great Unknown - MozCon
thekraken
20
1.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Gamification - CAS2011
davidbonilla
78
4.9k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
34
1.9k
Six Lessons from altMBA
skipperchong
24
3.2k
Transcript
プロダクション向け Rook/Cephクラスタ構築への道 Japan Rook Meetup #5 Cybozu, Inc. Neco Project
Satoru Takeuchi Twitter: satoru_takeuchi 1
目次 1. CephとRookの基礎 2. サイボウズのインフラ基盤とストレージ基盤 3. プロダクション向けRook/Cephクラスタの構成 4. 現状と今後 2
Rook/Cephの基礎 3
Cephとは ▌オープンソースの分散ストレージ ▌提供するストレージ ⚫RBD: ブロックデバイス ⚫RGW: S3互換オブジェクトストレージ ⚫CephFS: ファイルシステム ▌ユーザ
⚫大きなところだとNASA, CERNなど 4
アーキテクチャ 5 アプリ RADOS(Ceph独自のオブジェクトストレージ) Ceph node node node … RBD
RGW ブロックデバイス オブジェクト ブロックデバイス ブロックデバイス オブジェクト S3互換オブジェクト アプリ アプリ pool pool
Cephを構成するデーモン ▌Monitor(MON) ⚫Cephクラスタに対する全処理の整合性を保つ ⚫通常システムに奇数個、通常3つ以上存在 ▌Manager(MGR) ⚫機能拡張のためのモジュールの管理 ⚫通常システムに1つ存在 ▌Object Storage Daemon(OSD)
⚫データストアを管理 ⚫OSDへのI/O、OSDの相互生存監視を担当 6
Object Storage Daemon(OSD) ▌Cephがストレージデバイスを管理する単位 ⚫ OSDをあらわすデータ構造もOSDを管理するデーモン(後述)も両方OSDと呼ぶ ▌1つのデバイスに1つ以上のOSDを作れる ⚫ HDDは通常1つ、NVMe SSDは通常2以上
7 RADOS node HDD node NVMe SSD OSD OSD OSD
データの均等分散配置(例えばラック間分散) 8 rack1 rack0 rack1 rack0 node0 node1 node2 node3
OSD OSD OSD OSD OSD OSD OSD OSD Cephクライアント(RBD, RGW) データ CRUSHによるデータの均等分散配置 Ceph 管理者によるOSDの均等分散配置
用語説明 ▌CRUSHアルゴリズム ⚫データのOSDへの分散配置方法を決める ⚫各オブジェクトのレプリカを全OSDになるべくランダムに配置 ▌CRUSH map ⚫クラスタを構成するハードウェアの物理的な構成を記述 ⚫ラックやノード、OSDの関係を示すツリー構造 ⚫Failure domainを設定可能
9
CRUSH mapの例 ▌2rack,2node per 1rack,2osd per 1nodeの例 10 node OSD
OSD rack node OSD OSD node OSD OSD rack node OSD OSD root
Rookとは ▌K8sで動くCephのオーケストレータ ⚫CassandraやNFSなども管理できる ▌CephClusterというCRでクラスタを管理 ▌MON,MGR,OSDごとにPodが1つ存在(以下はOSD pod) 11 ブロックデバイス OSD Pod
OSD
• Host-basedクラスタ • ハード構成を直接CRに書く • 大規模になると管理が困難 • PVC-basedクラスタ(サイボウズはこちら) • CRに書くのはOSDを作るPVのVolumeClaimTemplates
• ボリュームの作成/配置はK8sとCSIドライバの責任 • countフィールドを増やすとOSD(Pod)が増える • 規模にかかわらず構築後の拡張は楽 storage: nodes: - name: foo devices: - sdb - sdc - name: bar … 12 2種類のRook/Cephクラスタ storage: … count: 3 volumeClaimTemplates: - spec: resources: requests: storage: 10Gi storageClassName: my-class
RBDの使い方(1/2) 13 apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: name: ceph-block-pool namespace:
rook-ceph spec: replicated: size: 3 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-block provisioner: ceph-ssd.rbd.csi.ceph.com parameters: clusterID: ceph-ssd pool: ceph-ssd-block-pool 2. 管理者がストレージクラスを定義 1. 管理者がPoolを定義
RBDの使い方(2/2) 14 3. ユーザがPVCを作る apiVersion: v1 kind: PersistentVolume metadata: name:
myclaim spec: storageClassName: ceph-block 4. PodからPVCを使う apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: foo image: foo volumeMounts: - mountPath: "/mnt" name: myvolume volumes: - name: myvolume persistentVolumeClaim: claimName: myclaim
RGWの使い方(1/2) 15 1. 管理者がオブジェクトストレージを作る apiVersion: ceph.rook.io/v1 kind: CephObjectStore metadata: name:
ceph-object-store namespace: rook-ceph spec: dataPool: replicated: size: 3 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-bucket provisioner: ceph-hdd.ceph.rook.io/bucket parameters: objectStoreName: ceph-object-store objectStoreNamespace: rook-ceph 2. 管理者がストレージクラスを作る
RGWの使い方(2/2) 16 3. ユーザがbucketを作る kind: ObjectBucketClaim metadata: name: test-object-bucket namespace:
default spec: generateBucketName: test-object-bucket storageClassName: ceph-bucket kind: Pod metadata: name: app-pod spec: containers: - name: foo image: bar envFrom: - configMapRef: name: test-object-bucket - secretRef: name: test-object-bucket 4. ユーザが使う bucketへのアクセス方法が 下記ConfigMapとSecretsに入っている
サイボウズのインフラ基盤と ストレージ基盤 17
インフラ基盤のハードウェア構成 ▌2種のサーバを詰めたラックを並べる 18 rack CS SS SS SS rack CS
CS CS SS rack CS CS SS SS … CS SS • Computing Server • 全サービスが使う • ストレージはNVMe SSD • Storage Server • Ceph専用 • ストレージはHDD
特徴 ▌ソフトウェアマルチテナンシー ⚫Cephもアプリも同じK8sクラスタ上で動く ▌ラック障害耐性 ⚫運用継続 ⚫データロスト無し 19
必要なストレージ ▌高速ローカルブロックストレージ ⚫ 顧客データを扱うMySQLなど ▌中速&スケーラブルなブロックストレージ ⚫ ファイルシステムを前提としたアプリのデータなど ▌大容量&スケーラブルなブロックストレージ ⚫ メトリクスやログ
▌大容量&スケーラブルなオブジェクトストレージ ⚫ 添付ファイルなど 20
ストレージ基盤の構成 21 K8sクラスタ Rook/CephクラスタA Rook/CephクラスタB RGW RBD RBD HDD SS
CS SSD HDD HDD SSD SSD LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume TopoLVMが管理 ローカル ストレージ
全体構成のイメージ 22 K8sクラスタ リモート K8sクラスタ * 左図と 同様の構成 レプリケーション Victoria
Metrics & Loki Rook/CephクラスタA Rook/CephクラスタB Pod Pod Pod RGW RBD RBD メトリクス & ログ HDD SS CS SSD HDD HDD SSD SSD LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume Pod
プロダクション向け Rook/Cephクラスタの構成 23
NVMe SSD Cephクラスタの設定 ▌OSD用のブロックデバイスは自社製CSIドライバTopoLVMから切り出す ⚫ TopoLVMはDynamic provisioningをサポート ⚫ OSDの数を増やすときに対応するPVが自動的に作られる 24
storage: … count: 20 volumeClaimTemplates: - spec: resources: requests: storage: 1Ti storageClassName: topolvm-provisioner CephCluster CRより抜粋
HDD Cephクラスタの設定 ▌OSD用のブロックデバイスは自社製ツールで自動生成 ⚫ KubernetesクラスタにSSを組み込むと自動的にHDD用のPVを作成 ▌管理者はPVのprovisioningを気にしなくてよい 25 storage: … count:
20 volumeClaimTemplates: - spec: resources: requests: storage: 1Ti storageClassName: local-storage CephCluster CRより抜粋
Cephコマンド実行ツールのdeploy ▌Rookが提供するtoolbox Pod ⚫ソースのcluster/example/Kubernetes/ceph/toolbox.yamlにある ⚫両方のクラスタにdeploy ▌使い方 ⚫kubectl apply –f toolbox.yaml
⚫kubectl –n rook-ceph exec rook-ceph-tool-XXX –- ceph status ▌使いどころ ⚫CRの記述では実現できない一部オペレーション ⚫デバッグ 26
ラック間のデータの均等分散配置 27 rack1 rack0 rack1 rack0 node0 node1 node2 node3
OSD OSD OSD OSD OSD OSD OSD OSD Cephクライアント(RBD, RGW) データ CRUSHによるデータの均等分散配置 Rook RookによるOSD Podの均等分散配置
CRUSHによるデータの均等分散配置 ▌プールのfailureDomainフィールドを設定 ⚫CRUSH ruleはRookが自動生成 28 apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata:
name: ceph-ssd-block-pool namespace: ceph-ssd spec: failureDomain: zone replicated: size: 3 apiVersion: ceph.rook.io/v1 kind: CephObjectStore metadata: name: ceph-hdd-object-store namespace: ceph-hdd spec: dataPool: failureDomain: zone replicated: size: 3 apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: name: ceph-hdd-block-pool namespace: ceph-hdd spec: failureDomain: zone replicated: size: 3 SSD CephのRBDのpool HDD CephのRBDのpool HDD Cephのオブジェクトストア
OSDの均等分散配置 ▌課題 ⚫KubernetesのPodはどのノードにスケジュールされるかわからない ⚫ OSD Podも例外ではない ⚫特定ノードにOSDの配置が偏ると困る ▌解決方法 ⚫K8sのTopologySpreadConstraints(TSC)機能 ⚫K8sのScheduling
profile機能 29
OSD Podのスケジューリング with TSC 30 rack0 node0 OSD OSD node1
OSD OSD rack1 node2 OSD OSD node3 OSD 新規OSD Pod 1. rack0のOSD数 > rack1のOSD数 →rack1上のノードにスケジュール 2. node2のOSD数 > node3のOSD数 →node3にスケジュール
TSCの設定例 31 apiVersion: v1 kind: Pod metadata: name: mypod spec:
topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.Kubernetes.io/zone labelSelector: … ドメイン間で許容されるPod数の差 Pod数の均衡をすべきドメイン 対象となるPodを選択
課題: TSCとStatefulアプリの相性が悪い ▌システムの運用中にハード構成は大きく変わりうる ⚫ ラック/ノード/デバイスの追加/削除/故障 ▌ローカルストレージを使うPodは別ノードに移動できない ▌デフォルトではmaxSkewより大きな差があるとOSD Podが増やせない 32
問題になるケースの例 33 node0 node1 disk0 disk1 disk2 disk0 disk1 disk2
node0 node1 disk0 disk1 disk2 disk0 disk1 disk2 OSD OSD OSD OSD OSD OSD OSD 時間経過 node0 node1 disk0 disk1 disk2 disk0 disk1 disk2 node2 disk0 disk1 disk2 OSD Node2を追加 node0 node1 disk0 disk1 disk2 disk0 disk1 disk2 node2 disk0 disk1 disk2 OSD このディスク用のOSDは デフォルトではTSCの 制約により作れない 追加ディスク用 OSDの作成 OSD OSD
対策: TSCの制約の緩和 ▌TSCのwhenUnsatisfiableフィールドの変更 ⚫dontSchedule(デフォルト): 制約を満たせる時のみスケジュール ⚫scheduleAnyway: 制約を満たせなくてもスケジュール ⚫ Podの分散具合についてはスケジューラのスコアに影響 ▌参考:
maxSkewの値を2以上にする対策は困難 ⚫小さすぎる: 場合によっては結局OSD Podが作れない ⚫大きすぎる: 設定する意味がない 34
さらなる課題 ▌TSCのwhenUnsatisfiableフィールドの変更 ⚫dontSchedule(デフォルト): 制約を満たせる時のみスケジュール ⚫scheduleAnyway: 制約を満たせなくてもスケジュール ⚫ Podの分散具合についてはスケジューラのスコアに影響 35 ノードのスコアリングにおける
Podの分散具合のweightがほとんどゼロなので、 事実上無視される
解決方法: スケジューラの設定変更 ▌scheduling profile機能を使用(k8s v1.18~) ⚫アプリごとにスケジューラの設定をprofileとして作れる ▌Profileごとにpodの分散具合のweightを高められる ▌サイボウズではデフォルトスケジューラの設定を変更 ⚫他のアプリでもTSCは有用 36
Default scheduling profileの変更 37 profiles: - schedulerName: default-scheduler plugins: score:
… enabled: - name: PodTopologySpread weight: 500 pluginConfig: - name: PodTopologySpread args: defaultConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway weightを大きくする デフォルトTSC ラック間でPod分散配置 * サイボウズのK8sクラスタでは zoneがrackに対応
CephClusterのCRにOSD Pod用TSC設定 ▌rack間でOSDを均等分散+host間でも均等分散 38 storage: … placement: topologySpreadConstraints: - maxSkew:
1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchExpressions: - key: app operator: In values: - rook-ceph-osd - rook-ceph-osd-prepare … … - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway labelSelector: matchExpressions: - key: app operator: In values: - rook-ceph-osd - rook-ceph-osd-prepare
現状と今後 39
最終的な全体構成のイメージ(再載) 40 K8sクラスタ リモート K8sクラスタ * 左図と 同様の構成 レプリケーション Victoria
Metrics & Loki Rook/CephクラスタA Rook/CephクラスタB Pod Pod Pod RGW RBD RBD メトリクス & ログ HDD SS CS SSD HDD HDD SSD SSD LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume Pod
進捗 ▌基本的な機能検証は完了 ⚫既に説明した諸機能 ⚫OSD破壊からの復旧 ⚫MON quorumの回復 ▌インフラ基盤の監視、ログのストレージとして使用中 ▌ユーザデータは性能を気にしないものなら置いていい 41
現状の構成 42 K8sクラスタ リモート レプリケーション Victoria Metrics & Loki Rook/CephクラスタA
Rook/CephクラスタB Pod Pod Pod RGW RBD RBD メトリクス & ログ HDD SS CS SSD LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume LogicalVolume Pod 現行インフラ リモート K8sクラスタ * 左図と 同様の構成
基本的な運用はとにかく楽 ▌クラスタの作成: CephCluster CRをapplyするだけ ▌クラスタの拡張: 前述のcountフィールドの値を増やすだけ 1. countフィールド値の変化をRookが検知、OSD用のPVCを作る 2. 上記ボリューム上にOSDを作成してクラスタに組み込む
▌故障したOSDの退役: ほぼ自動化するジョブあり ▌ユーザはインフラがCephかどうかは気にしなくていい ⚫ 単に通常通りストレージクラスを指定してPVCを作るだけ 43
今後 1. 性能検証&可用性を高める 2. 追加構成 ⚫リモートレプリケーション ⚫スナップショット、バックアップ/リストア ⚫RGWの使用方法をKubernetes公式のCOSIに移行 ⚫ 現在は事実上Rook独自のインタフェース
3. 全データを(徐々に)移行 44
参考 ▌サイボウズのRook関連のマニフェスト ⚫ https://github.com/cybozu-go/neco-apps/tree/main/rook ▌Production-grade Deployment of PVC-based Rook/Ceph Cluster
⚫ https://blog.kintone.io/entry/2020/09/18/175030 ▌賢く「散らす」ためのTopology Spread Constraints ⚫ https://speakerdeck.com/ytaka23/kubernetes-meetup-tokyo-25th ▌Scheduling Profileが実現するPod配置戦略の最前線 ⚫ https://speakerdeck.com/ytaka23/infra-study-meetup-2nd ▌Capacity-aware Dynamic Volume Provisioning For LVM Local Storage ⚫ https://static.sched.com/hosted_files/kccnceu20/a4/kubecon-eu2020_topolvm.pdf 45
46 Thank you! Any question?