Slide 1

Slide 1 text

Rook/Ceph upstream最新状況 Japan Rook Meetup #4 Cybozu, Inc. Neco Project Satoru Takeuchi Twitter: @satoru_takeuchi 1

Slide 2

Slide 2 text

はじめに ▌サイボウズとRook/Cephの関係 ⚫次期インフラ基盤にRook/Cephを採用 ⚫バグ修正/機能追加はすべてupstreamに還元 ▌本セッションの目的 ⚫Rook/Cephクラスタ開発で得た知見を共有

Slide 3

Slide 3 text

目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 3

Slide 4

Slide 4 text

目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 4

Slide 5

Slide 5 text

デバイス • Host-basedクラスタ △ OSDのデプロイにハード構成の知識が必要 △大規模になると管理が困難 ユーザが直接指定 • PVC-basedクラスタ(今日話すのはこちら) 〇 OSDのデプロイはK8sがやってくれる 〇 規模にかかわらずOSDの数だけ指定すればOK CephCluster CR Kubernetes Linux CephCluster CR OSDの設定 CSIドライバ ユーザはここを 知らなくてよい 5 Rook/Cephクラスタは二種類ある テンプレートに合致する ボリュームを作成 OSDの設定 PVC template (Block Volume)

Slide 6

Slide 6 text

二種類のデプロイ方法 6 ▌Dynamic Provisioning ⚫PVはOSD数を増やせばCSIドライバが自動的に作る ⚫例: ⚫ TopoLVM: LVMのLogicalVolumeをPVとして提供 ⚫ zfs-localpv: ZFSのzvolをPVとして提供 ▌Static provisioning: PVは管理者が用意する ⚫例: • 手動 • Local-static-provisioner@k8s-sig • Local-pv-provisioner@cybozu

Slide 7

Slide 7 text

目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 7

Slide 8

Slide 8 text

Failure domainを跨いだデータの均等分散配置 8 rack1 rack0 rack1 rack0 node0 node1 node2 node3 OSD OSD OSD OSD OSD OSD OSD OSD Cephクライアント(RBD,CephFS,RGW) データ CRUSHによるデータの均等分散配置 Rook RookによるOSD Podの均等分散配置

Slide 9

Slide 9 text

実現方法 ▌OSD Podの分散配置 ⚫K8sのTopologySpreadConstraints(TSC)を使う(v1.3~) ⚫ サイボウズ作 ⚫K8sのScheduling profileを使う(v1.4~) ⚫ サイボウズ作 ▌データの分散配置 1. Cephのプールに対応するCRのfailureDomainフィールドを設定 2. RookがCRUSH rule自動生成 9

Slide 10

Slide 10 text

OSD Podのスケジューリング with TSC 10 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にスケジュール

Slide 11

Slide 11 text

課題: TSCとStatefulアプリの相性が悪い 11 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の制約 により作れない • 許容されるnode間OSD Pod数の差は1以下 追加ディスク用 OSDの作成 OSD OSD

Slide 12

Slide 12 text

対処方法 ▌TSCの制約を満たせなくてもスケジュールできるようにする ⚫TSCのwhenUnsatisfiableフィールドをscheduleAnywayにする ▌スケジューラの設定変更 ⚫TSCにおけるPod数の差はスコアリングにおけるweightが低い ⚫ 例えばOSD Pod以外の負荷が高いノードにはOSD Podがスケジュールされづらい ⚫スケジューラの設定によってweightを変更 ⚫ ~K8s 1.17: グローバル設定を変更 ⚫ K8s 1.18~: OSD Pod専用のscheduling profile機能を作る 12

Slide 13

Slide 13 text

PVC-basedクラスタのPVとして使えるデバイス ▌ディスク全体 ▌Logical Volume(v1.2~) ⚫サイボウズが開発 ▌パーティション(v1.3~) ▌Mpath(v1.4~) ▌Crypt(v1.4~) ⚫サイボウズが開発 13

Slide 14

Slide 14 text

リモートレプリケーション ▌RBD mirroring ⚫CRD操作+Cephコマンドで実現 ▌RGW async replication(v1.4~) ⚫CRD操作だけで実現

Slide 15

Slide 15 text

目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 15

Slide 16

Slide 16 text

最近見つかった深刻な問題 ▌発生条件 ⚫PVC-basedクラスタ ⚫PVのバックエンドがLVM: OSD on LV-backed PVC ⚫例: TopoLVM ▌問題 ⚫OSDを一旦ダウンさせると二度と起動しない ⚫復旧方法は無い

Slide 17

Slide 17 text

前提知識: OSDの構造(従来型のLVM mode) ▌CephはデバイスがOSDか否かの判定にLVMメタデータを使う ⚫ディスク上にOSDを作成 → CephはVG,LVを作り、メタデータを変更 ⚫既存LV上にOSDを作成 → Cephはメタデータを変更 ディスク ユーザが作ったVG メタデータ LV0: OSD LV0(OSD用) ディスク ディスク 空き領域 ディスク Cephが作ったVG メタデータ LV0: OSD LV0(OSD用) OSD OSD

Slide 18

Slide 18 text

問題発生までの流れ 1. LVMメタデータをホストとOSD作成用Podから同時に操作 2. LVMメタデータが壊れる ⚫ LV上にOSDがあるという情報が消える 3. OSDを一旦ダウンさせると次回以降起動できなくなる ⚫ Cephはデバイス上にOSDがないとみなす ディスク ユーザが作ったVG メタデータ LV0: OSD LV0(OSD用) LV1(OSD以外用) ディスク ディスク 空き領域 OSD ホスト: LV1を新規作成 OSD作成用Pod: LV0上にOSDを作成 変更 変更

Slide 19

Slide 19 text

解決方法: raw mode OSD ▌構造がシンプルなOSDの新しいモード ⚫ デバイスがOSDか否かの判定にLVMメタデータを使わない ⚫ RookはLVMメタデータを変更しないので前述の問題が発生しない ▌サイボウズがv1.5取り込みを目指して開発中 ⚫ V1.4にもバックポート予定 ディスク ユーザが作ったVG メタデータ LV0(OSD用) ディスク ディスク 空き領域 OSD ホスト: LV1を新規作成 OSD作成用Pod: LV0上にOSDを作成 変更 変更しない LV1(OSD以外用)

Slide 20

Slide 20 text

その他 ▌RBD mirroringの改善(マージ済) ⚫ Cephのコマンドを叩かずCRの設定だけで使える ▌壊れたディスク上におけるOSD削除処理の自動化(マージ済) ⚫ これまでは直接Cephコマンドを叩く必要があった ⚫ v1.4にもバックポート済 ▌hostNetworkが不要に(未マージ) ⚫ これまでは”hostNetwork: true”が必須だった ⚫ セキュリティリスクあり: ノード上のパケットを見られるなど ⚫ 原因: Cephのrbdクライアントがコンテナ上で動くケースを考慮していなかった 20

Slide 21

Slide 21 text

CIの課題 ▌タイミングにより誤って失敗するテストが多く、すべて通すのが困難 ⚫ 原因: 発生頻度が低かったので修正を後回しにしていたら溜まってしまった ⚫ 施策: 頻度の高いものから順番に潰す ▌デグレ発生頻度が高め ⚫ 原因: カバレッジがあまり高くない ⚫ 施策: 新機能、デグレが起きた箇所を中心にテスト追加 ▌時間がかかる: PRマージ時は約1時間、リリース時は約2時間 ⚫ 原因: CI環境のスペックが低い、並列化が不十分 ⚫ 施策: まずは並列度を高める 21 V1.6以降もひたすら継続!

Slide 22

Slide 22 text

v1.5開発への主な貢献者 コミット数 名前 所属 備考 134 Sébastien Han Red Hat Cephメンテナ 112 Travis Nielsen Red Hat Cephメンテナ 24 subhamkrai Red Hat 19 Madhu Rajanna Red Hat Cephレビューア 14 Jiffin Tony Thottan ? 12 Alexander Trost Cloudical EdgeFSメンテナ 9 Satoru Takeuchi サイボウズ Cephレビューア 8 Humble Chirammal Red Hat 6 Blaine Gardner SUSE Cephメンテナ 5 Jared Watts Upbound Cephメンテナ 5 binoue サイボウズ 5 Arun Kumar Mohan Red Hat 5 Ahmad Nurus S ?

Slide 23

Slide 23 text

目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 23

Slide 24

Slide 24 text

プロジェクトの成熟度 ▌プロダクション環境で少なくとも20社が使用中 ⚫Github.com/rook/rook/ADOPTERS.md ▌CNCFのGraduatedプロジェクト目指して活動中 ⚫現在はIncubatingプロジェクト ⚫最終投票中 24

Slide 25

Slide 25 text

Rook/Cephを使う製品 ▌Red Hat OpenShift Container Storage4 ⚫9月にv4.5がリリース済 ⚫この後関連セッションあり! ▌SUSE Enterprise Storage 7 ⚫9月にbeta版リリース済

Slide 26

Slide 26 text

まとめ ▌必須機能はおおよそ実装された ▌ユーザも増え続けている ▌今後必要なもの ⚫安定化 ⚫運用自動化 ▌サイボウズは今後も継続的に貢献 26

Slide 27

Slide 27 text

参考リンク ▌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 27

Slide 28

Slide 28 text

28 Thank you! Any question?