プロダクション向けRook/Cephクラスタ構築への道

プロダクション向け
Rook/Cephクラスタ構築への道
Japan Rook Meetup #5
Cybozu, Inc. Neco Project
Satoru Takeuchi
Twitter: satoru_takeuchi
1

View Slide

目次
1. CephとRookの基礎
2. サイボウズのインフラ基盤とストレージ基盤
3. プロダクション向けRook/Cephクラスタの構成
4. 現状と今後
2

View Slide

Rook/Cephの基礎
3

View Slide

Cephとは
▌オープンソースの分散ストレージ
▌提供するストレージ
⚫RBD: ブロックデバイス
⚫RGW: S3互換オブジェクトストレージ
⚫CephFS: ファイルシステム
▌ユーザ
⚫大きなところだとNASA, CERNなど
4

View Slide

アーキテクチャ
5
アプリ
RADOS(Ceph独自のオブジェクトストレージ)
Ceph
node node node
…
RBD RGW
ブロックデバイスオブジェクト
ブロックデバイス
ブロックデバイスオブジェクト
S3互換オブジェクト
アプリ
アプリ
pool pool

View Slide

Cephを構成するデーモン
▌Monitor(MON)
⚫Cephクラスタに対する全処理の整合性を保つ
⚫通常システムに奇数個、通常3つ以上存在
▌Manager(MGR)
⚫機能拡張のためのモジュールの管理
⚫通常システムに1つ存在
▌Object Storage Daemon(OSD)
⚫データストアを管理
⚫OSDへのI/O、OSDの相互生存監視を担当
6

View Slide

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

View Slide

データの均等分散配置(例えばラック間分散)
8
rack1
rack0
rack1
rack0
node0 node1 node2 node3
OSD
OSD
OSD
OSD
OSD
OSD
OSD
OSD
Cephクライアント(RBD, RGW)
データ CRUSHによるデータの均等分散配置
Ceph
管理者によるOSDの均等分散配置

View Slide

用語説明
▌CRUSHアルゴリズム
⚫データのOSDへの分散配置方法を決める
⚫各オブジェクトのレプリカを全OSDになるべくランダムに配置
▌CRUSH map
⚫クラスタを構成するハードウェアの物理的な構成を記述
⚫ラックやノード、OSDの関係を示すツリー構造
⚫Failure domainを設定可能
9

View Slide

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

View Slide

Rookとは
▌K8sで動くCephのオーケストレータ
⚫CassandraやNFSなども管理できる
▌CephClusterというCRでクラスタを管理
▌MON,MGR,OSDごとにPodが1つ存在(以下はOSD pod)
11
ブロックデバイス
OSD Pod
OSD

View Slide

• 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

View Slide

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を定義

View Slide

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

View Slide

RGWの使い方(1/2)
15
1. 管理者がオブジェクトストレージを作る
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. 管理者がストレージクラスを作る

View Slide

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:
- secretRef:
4. ユーザが使う
bucketへのアクセス方法が
下記ConfigMapとSecretsに入っている

View Slide

サイボウズのインフラ基盤と
ストレージ基盤
17

View Slide

インフラ基盤のハードウェア構成
▌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

View Slide

特徴
▌ソフトウェアマルチテナンシー
⚫Cephもアプリも同じK8sクラスタ上で動く
▌ラック障害耐性
⚫運用継続
⚫データロスト無し
19

View Slide

必要なストレージ
▌高速ローカルブロックストレージ
⚫ 顧客データを扱うMySQLなど
▌中速&スケーラブルなブロックストレージ
⚫ ファイルシステムを前提としたアプリのデータなど
▌大容量&スケーラブルなブロックストレージ
⚫ メトリクスやログ
▌大容量&スケーラブルなオブジェクトストレージ
⚫ 添付ファイルなど
20

View Slide

ストレージ基盤の構成
21
K8sクラスタ
Rook/CephクラスタA Rook/CephクラスタB
RGW RBD RBD
HDD
SS CS
SSD
HDD
HDD
SSD
SSD
LogicalVolume LogicalVolume
LogicalVolume
LogicalVolume TopoLVMが管理
ローカル
ストレージ

View Slide

全体構成のイメージ
22
K8sクラスタリモート
K8sクラスタ
* 左図と
同様の構成
レプリケーション
Victoria
Metrics
& Loki
Pod Pod Pod
RGW RBD RBD
メトリクス
& ログ
HDD
SS
CS
SSD
HDD
HDD SSD
SSD
LogicalVolume
LogicalVolume
Pod

View Slide

プロダクション向け
Rook/Cephクラスタの構成
23

View Slide

NVMe SSD Cephクラスタの設定
▌OSD用のブロックデバイスは自社製CSIドライバTopoLVMから切り出す
⚫ TopoLVMはDynamic provisioningをサポート
⚫ OSDの数を増やすときに対応するPVが自動的に作られる
24
storage:
…
count: 20
- spec:
resources:
requests:
storage: 1Ti
storageClassName: topolvm-provisioner
CephCluster CRより抜粋

View Slide

HDD Cephクラスタの設定
▌OSD用のブロックデバイスは自社製ツールで自動生成
⚫ KubernetesクラスタにSSを組み込むと自動的にHDD用のPVを作成
▌管理者はPVのprovisioningを気にしなくてよい
25
storage:
…
count: 20
- spec:
resources:
requests:
storage: 1Ti
storageClassName: local-storage
CephCluster CRより抜粋

View Slide

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

View Slide

ラック間のデータの均等分散配置
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の均等分散配置

View Slide

CRUSHによるデータの均等分散配置
▌プールのfailureDomainフィールドを設定
⚫CRUSH ruleはRookが自動生成
28
kind: CephBlockPool
metadata:
name: ceph-ssd-block-pool
namespace: ceph-ssd
spec:
failureDomain: zone
replicated: size: 3
kind: CephObjectStore
metadata:
name: ceph-hdd-object-store
namespace: ceph-hdd
spec:
dataPool:
failureDomain: zone
replicated:
size: 3
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のオブジェクトストア

View Slide

OSDの均等分散配置
▌課題
⚫KubernetesのPodはどのノードにスケジュールされるかわからない
⚫ OSD Podも例外ではない
⚫特定ノードにOSDの配置が偏ると困る
▌解決方法
⚫K8sのTopologySpreadConstraints(TSC)機能
⚫K8sのScheduling profile機能
29

View Slide

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にスケジュール

View Slide

TSCの設定例
31
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.Kubernetes.io/zone
labelSelector:
…
ドメイン間で許容されるPod数の差
Pod数の均衡をすべきドメイン
対象となるPodを選択

View Slide

課題: TSCとStatefulアプリの相性が悪い
▌システムの運用中にハード構成は大きく変わりうる
⚫ ラック/ノード/デバイスの追加/削除/故障
▌ローカルストレージを使うPodは別ノードに移動できない
▌デフォルトではmaxSkewより大きな差があるとOSD Podが増やせない
32

View Slide

問題になるケースの例
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

View Slide

対策: TSCの制約の緩和
▌TSCのwhenUnsatisfiableフィールドの変更
⚫dontSchedule(デフォルト): 制約を満たせる時のみスケジュール
⚫scheduleAnyway: 制約を満たせなくてもスケジュール
⚫ Podの分散具合についてはスケジューラのスコアに影響
▌参考: maxSkewの値を2以上にする対策は困難
⚫小さすぎる: 場合によっては結局OSD Podが作れない
⚫大きすぎる: 設定する意味がない
34

View Slide

さらなる課題
▌TSCのwhenUnsatisfiableフィールドの変更
⚫dontSchedule(デフォルト): 制約を満たせる時のみスケジュール
⚫scheduleAnyway: 制約を満たせなくてもスケジュール
⚫ Podの分散具合についてはスケジューラのスコアに影響
35
ノードのスコアリングにおける
Podの分散具合のweightがほとんどゼロなので、
事実上無視される

View Slide

解決方法: スケジューラの設定変更
▌scheduling profile機能を使用(k8s v1.18~)
⚫アプリごとにスケジューラの設定をprofileとして作れる
▌Profileごとにpodの分散具合のweightを高められる
▌サイボウズではデフォルトスケジューラの設定を変更
⚫他のアプリでもTSCは有用
36

View Slide

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に対応

View Slide

CephClusterのCRにOSD Pod用TSC設定
▌rack間でOSDを均等分散+host間でも均等分散
38
storage:
…
placement:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- rook-ceph-osd
- rook-ceph-osd-prepare
…
…
- maxSkew: 1
topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- rook-ceph-osd
- rook-ceph-osd-prepare

View Slide

現状と今後
39

View Slide

最終的な全体構成のイメージ(再載)
40
K8sクラスタリモート
K8sクラスタ
* 左図と
同様の構成
Victoria
Metrics
& Loki
Pod Pod Pod
RGW RBD RBD
メトリクス
& ログ
HDD
SS
CS
SSD
HDD
HDD SSD
SSD
LogicalVolume
LogicalVolume
Pod

View Slide

進捗
▌基本的な機能検証は完了
⚫既に説明した諸機能
⚫OSD破壊からの復旧
⚫MON quorumの回復
▌インフラ基盤の監視、ログのストレージとして使用中
▌ユーザデータは性能を気にしないものなら置いていい
41

View Slide

現状の構成
42
K8sクラスタ
リモート
Victoria
Metrics
& Loki
Pod Pod Pod
RGW RBD RBD
メトリクス
& ログ
HDD
SS CS
SSD
LogicalVolume
LogicalVolume
Pod
現行インフラリモート
K8sクラスタ
* 左図と
同様の構成

View Slide

基本的な運用はとにかく楽
▌クラスタの作成: CephCluster CRをapplyするだけ
▌クラスタの拡張: 前述のcountフィールドの値を増やすだけ
1. countフィールド値の変化をRookが検知、OSD用のPVCを作る
2. 上記ボリューム上にOSDを作成してクラスタに組み込む
▌故障したOSDの退役: ほぼ自動化するジョブあり
▌ユーザはインフラがCephかどうかは気にしなくていい
⚫ 単に通常通りストレージクラスを指定してPVCを作るだけ
43

View Slide

今後
1. 性能検証&可用性を高める
2. 追加構成
⚫リモートレプリケーション
⚫スナップショット、バックアップ/リストア
⚫RGWの使用方法をKubernetes公式のCOSIに移行
⚫ 現在は事実上Rook独自のインタフェース
3. 全データを(徐々に)移行
44

View Slide

参考
▌サイボウズの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

View Slide

46
Thank you! Any question?

View Slide

プロダクション向けRook/Cephクラスタ構築への道

プロダクション向けRook/Cephクラスタ構築への道

Satoru Takeuchi
PRO

More Decks by Satoru Takeuchi

Other Decks in Technology

Featured

Transcript

プロダクション向けRook/Cephクラスタ構築への道

プロダクション向けRook/Cephクラスタ構築への道

Satoru Takeuchi PRO

More Decks by Satoru Takeuchi

Other Decks in Technology

Featured

Transcript

Satoru Takeuchi
PRO