Rook/Ceph最新状況@Japan Rook Meetup #4

Japan Rook MeetupでRook v1.4の現状とv1.5の開発状況についての発表に使ったスライドです。

https://rook.connpass.com/event/182592/

Transcript

1. Rook/Ceph upstream最新状況 Japan Rook Meetup #4 Cybozu, Inc. Neco Project Satoru Takeuchi Twitter: @satoru_takeuchi 1
2. はじめに ▌サイボウズとRook/Cephの関係 ⚫次期インフラ基盤にRook/Cephを採用 ⚫バグ修正/機能追加はすべてupstreamに還元 ▌本セッションの目的 ⚫Rook/Cephクラスタ開発で得た知見を共有
3. 目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 3
4. 目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 4
5. デバイス • 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)
6. 二種類のデプロイ方法 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
7. 目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 7
8. 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の均等分散配置
9. 実現方法 ▌OSD Podの分散配置 ⚫K8sのTopologySpreadConstraints(TSC)を使う(v1.3~) ⚫ サイボウズ作 ⚫K8sのScheduling profileを使う(v1.4~) ⚫ サイボウズ作 ▌データの分散配置 1. Cephのプールに対応するCRのfailureDomainフィールドを設定 2. RookがCRUSH rule自動生成 9
10. 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にスケジュール
11. 課題: 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
12. 対処方法 ▌TSCの制約を満たせなくてもスケジュールできるようにする ⚫TSCのwhenUnsatisfiableフィールドをscheduleAnywayにする ▌スケジューラの設定変更 ⚫TSCにおけるPod数の差はスコアリングにおけるweightが低い ⚫ 例えばOSD Pod以外の負荷が高いノードにはOSD Podがスケジュールされづらい ⚫スケジューラの設定によってweightを変更 ⚫ ~K8s 1.17: グローバル設定を変更 ⚫ K8s 1.18~: OSD Pod専用のscheduling profile機能を作る 12
13. PVC-basedクラスタのPVとして使えるデバイス ▌ディスク全体 ▌Logical Volume(v1.2~) ⚫サイボウズが開発 ▌パーティション(v1.3~) ▌Mpath(v1.4~) ▌Crypt(v1.4~) ⚫サイボウズが開発 13
14. リモートレプリケーション ▌RBD mirroring ⚫CRD操作+Cephコマンドで実現 ▌RGW async replication(v1.4~) ⚫CRD操作だけで実現
15. 目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 15
16. 最近見つかった深刻な問題 ▌発生条件 ⚫PVC-basedクラスタ ⚫PVのバックエンドがLVM: OSD on LV-backed PVC ⚫例: TopoLVM ▌問題 ⚫OSDを一旦ダウンさせると二度と起動しない ⚫復旧方法は無い
17. 前提知識: 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
18. 問題発生までの流れ 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を作成 変更 変更
19. 解決方法: raw mode OSD ▌構造がシンプルなOSDの新しいモード ⚫ デバイスがOSDか否かの判定にLVMメタデータを使わない ⚫ RookはLVMメタデータを変更しないので前述の問題が発生しない ▌サイボウズがv1.5取り込みを目指して開発中 ⚫ V1.4にもバックポート予定 ディスク ユーザが作ったVG メタデータ LV0(OSD用) ディスク ディスク 空き領域 OSD ホスト: LV1を新規作成 OSD作成用Pod: LV0上にOSDを作成 変更 変更しない LV1(OSD以外用)
20. その他 ▌RBD mirroringの改善(マージ済) ⚫ Cephのコマンドを叩かずCRの設定だけで使える ▌壊れたディスク上におけるOSD削除処理の自動化(マージ済) ⚫ これまでは直接Cephコマンドを叩く必要があった ⚫ v1.4にもバックポート済 ▌hostNetworkが不要に(未マージ) ⚫ これまでは”hostNetwork: true”が必須だった ⚫ セキュリティリスクあり: ノード上のパケットを見られるなど ⚫ 原因: Cephのrbdクライアントがコンテナ上で動くケースを考慮していなかった 20
21. CIの課題 ▌タイミングにより誤って失敗するテストが多く、すべて通すのが困難 ⚫ 原因: 発生頻度が低かったので修正を後回しにしていたら溜まってしまった ⚫ 施策: 頻度の高いものから順番に潰す ▌デグレ発生頻度が高め ⚫ 原因: カバレッジがあまり高くない ⚫ 施策: 新機能、デグレが起きた箇所を中心にテスト追加 ▌時間がかかる: PRマージ時は約1時間、リリース時は約2時間 ⚫ 原因: CI環境のスペックが低い、並列化が不十分 ⚫ 施策: まずは並列度を高める 21 V1.6以降もひたすら継続!
22. 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 ?
23. 目次 1. 2種類のクラスタ 2. Rook最新安定版(v1.4)でできること 3. Rook次期安定版(v1.5)の開発状況 4. Rookを取り巻く状況 23
24. プロジェクトの成熟度 ▌プロダクション環境で少なくとも20社が使用中 ⚫Github.com/rook/rook/ADOPTERS.md ▌CNCFのGraduatedプロジェクト目指して活動中 ⚫現在はIncubatingプロジェクト ⚫最終投票中 24
25. Rook/Cephを使う製品 ▌Red Hat OpenShift Container Storage4 ⚫9月にv4.5がリリース済 ⚫この後関連セッションあり！ ▌SUSE Enterprise Storage 7 ⚫9月にbeta版リリース済
26. まとめ ▌必須機能はおおよそ実装された ▌ユーザも増え続けている ▌今後必要なもの ⚫安定化 ⚫運用自動化 ▌サイボウズは今後も継続的に貢献 26
27. 参考リンク ▌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
28. 28 Thank you! Any question?