Rook/Ceph最新状況 in Japan Rook Meetup #3

Transcript

1. Rook/Ceph upstream最新状況 Japan Rook Meetup #3 Cybozu, Inc. Neco Project Satoru Takeuchi Twitter: @satoru_takeuchi 1
2. はじめに ▌サイボウズとRook/Cephの関係 ⚫次期インフラ基盤にRook/Cephを採用 ⚫upstream firstでバグ修正&機能追加する方針 ▌本セッションの目的 ⚫Rook/Cephクラスタ開発で得た知見を共有
3. 目次 1. 前提知識 2. Rook最新安定版(v1.3)の変更点 3. Rook次期安定版(v1.4)の開発状況 4. Rookを取り巻く状況 3
4. 目次 1. 前提知識 2. Rook最新安定版(v1.3)の変更点 3. Rook次期安定版(v1.4)の開発状況 4. Rookを取り巻く状況 4
5. デバイス OSD on device ユーザが指定 OSD on PVC PVC template (Block Volume) Cephクラスタの カスタムリソース Kubernetes Linux Cephクラスタの カスタムリソース OSDの設定 CSIドライバ ユーザはここを 気にしなくていい ユーザが指定 5 2種類のOSD作成方法 OSDの設定 ボリュームを作成
6. OSD on device ▌ノード上のデバイス名を直接指定 spec: … storage: … nodes: - name: “node0“ devices: - name: “sdb” - name: “node1“ deviceFilter: “^sd[^a]“ sda sdb sdc 6 node0 node1 sda sdb sdc OSD OSD OSD OSD Pod OSD Pod OSD Pod • クラスタ管理者にハードウェア構成の知識が必要 • 大規模になるほどマニフェストを書くのがツラい
7. • クラスタ管理者はOSD podのありかを気にしなくてよい OSD on PVC ▌CSIドライバ提供のraw block volumeを使う spec: … storageClassDeviceSets: - name: set0 count: 2 … volumeClaimTemplates: - metadata: name: data spec: resources: requests: storage: 10Gi storageClassName: my-class 7 PVC set0-1 OSD OSD Pod PVC set0-2 OSD OSD Pod • ボリュームの提供方法も気にしなくてよい
8. OSD on PVCの理想的な状態 8 PVC PVC OSD OSD OSD Pod OSD Pod CSIドライバが管理 Dynamic provisioningで 自動作成 disk disk disk disk disk TopoLVM: LVMベースのローカルディスク用CSIドライバ PV PV
9. ▌OSD on Deviceのかわりに使える 自分でPVを作るという手段もある 9 PVC PVC OSD OSD OSD Pod OSD Pod CSIドライバが管理 static provisioningで 手動作成 disk disk disk disk disk PV PV
10. 目次 1. 前提知識 2. Rook最新安定版(v1.3)の変更点 3. Rook次期安定版(v1.4)の開発状況 4. Rookを取り巻く状況 10
11. OSD on PVCの均等分散配置 ▌K8sにTopologySpreadConstraintsという機能がある(後述) ⚫所定のPodをfailure domain間で均等分散配置可能 ⚫入れ子構造も可能 ⚫名前が長いので、これ以降はTSCと記載 ▌OSD PodにおいてTSCをサポート ⚫サイボウズ作 11
12. 背景 ▌以下構成を例に必要性を説明 ⚫要件:ラック&ノード障害耐性 ⚫データのレプリカ数: 2 12 rack1 rack0 node0 node1 node2 node3
13. Kubernetesの仕様のおさらい ▌Podはどのノードにもスケジュールされうる ⚫OSD on PVCにおけるOSD Podも同様 ▌例) OSD数を2にすると以下のようになるかも… 13 rack1 rack0 node0 node1 node2 node3 OSD Pod OSD Pod
14. 問題 ▌ここでrack0が故障するとデータ消失 ▌→ラック障害耐性の要件を満たせない 14 rack1 rack0 node0 node1 node2 node3 OSD Pod OSD Pod
15. OSD Podのスケジューリング with TSC 15 rack0 node0 OSD Pod OSD Pod node1 OSD Pod OSD Pod rack1 node2 OSD Pod OSD Pod node3 OSD Pod 新規OSD Pod 1. rack0のOSD Pod数 > rack1のOSD Pod数 →rack1にスケジュール 2. node2のOSD Pod数 > node3のOSD Pod数 →node3にスケジュール
16. TSCの詳細
17. ストレージプロバイダ ▌Minioのコードが削除された ⚫理由: 誰もメンテしていない
18. その他 ▌パーティション上のOSD作成をサポート ▌FileStoreの新規作成が不可能に ⚫今後作成されるOSDは全てBlueStore ⚫既存のFileStore OSDのサポートは継続 18
19. 目次 1. 前提知識 2. Rook最新安定版(v1.3)の変更点 3. Rook次期安定版(v1.4)の開発状況 4. Rookを取り巻く状況 19
20. Scheduling profileのサポート ▌Kubernetesの機能(v1.18ではalpha) ▌Pod単位でスケジューリング方針を簡単に設定可能 1. profileを任意の数だけ定義 2. Podごとに使うprofileを指定 ▌OSD Podへのprofile設定をサポート ⚫サイボウズ作 20
21. 背景 ▌システムの運用中にハード構成は変わる ⚫ラック/ノード/デバイスの追加/削除/故障 ▌TSCで強い制約を付けるのは現実的ではない ⚫例: Node間のOSD pod数の差 <= 1 21 rack0 node0 node1 disk0 disk1 disk2 disk0 disk1 disk2 時間が経つと… rack0 node0 node1 disk0 disk1 disk2 disk0 disk1 disk2 node2 disk0 disk1 disk2 追加 このディスクは上記制約が あると使えない
22. 解決案1: TSCのmaxSkewフィールド ▌Failure domain間で許容するPod数の差を決める ▌欠点: 根拠のある数値を決めづらい ⚫小さすぎる値: 前ページの問題が発生 ⚫大きすぎる値: そもそも分散されない 22
23. 解決案2: TSCのwhenUnsatisfiableフィールド 23 https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#api • TSCの制約を満たせないとき: • DoNotSchedule (デフォルト): Podをスケジュールさせない • ScheduleAnyway: できる限り差分を最小化するようスケジュール これだ！
24. 辛い現実 24 https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#api • TSCの制約を満たせないとき: • DoNotSchedule (デフォルト): Podをスケジュールさせない • ScheduleAnyway: できる限り差分を最小化するようスケジュール 実際の動き • DoNotSchedule (デフォルト): TSCの制約を満たすようスケジュール 満たせなければスケジュールしない • ScheduleAnyway: TSCの制約を満たそうという努力を一切しない • Pod数の偏りをスコアリングの参考にするだけ • 偏りが大きくてもスコアへの影響は少ない • 例えばCPU負荷が高いnodeにはまずOSD Podは作られない コレジャナイ！
25. upstream k8sでの議論 ▌スケジューラ開発者たちの見解 ⚫記述が間違っているけどいまさら変えられない ⚫スコアリングルールを変えて対処するしかない 25
26. 最終的な対処方法 ▌OSD pod専用のScheduling profileを利用 1. TSCのスコアへの寄与が高いprofileを作る 2. OSD podに上記profileを指定 3. 他の因子の影響を受けずにOSD podを均等分散可能 26
27. Scheduling profileの詳細
28. OSD on PVCがサポートするデバイスタイプの増加 ▌現状 ⚫ディスク全体、パーティション、Logical Volume ▌追加 ⚫Mpath: merged ⚫Crypt: サイボウズが追加予定 28
29. ストレージプロバイダ ▌EdgeFS本体がclosed source化 ▌今後はCeph一極化が加速? ストレージプロバイダ V1.2.0～v1.3.0のコミット数 V1.3.0～のコミット数 Ceph 277 215 EdgeFS 13 5 NFS 6 9 Cassandra 3 5 YugabyteDB 5 2 CockroachDB 1 1 Minio 2 ※ ひとまずremoveは回避された
30. リモートレプリケーション ▌RBD mirroring専用のCR: マージ済 ⚫v1.3以前からのUpgrade時に要注意 ▌Object Store Multisite CR: 開発中
31. その他 ▌カスタムリソースのバリデーション改善: 開発中 ⚫Admission controllerを使用 ▌Reviewer(approved権限保持者)の増員: マージ済 ⚫Satoru Takeuchi@サイボウズ ⚫Madhu Rajanna@Red Hat
32. v1.4開発への主な貢献者 コミット数 名前 所属 備考 176 Sébastien Han Red Hat メンテナ 151 Travis Nielsen Red Hat メンテナ 36 Satoru Takeuchi サイボウズ レビューア 26 Madhu Rajanna Red Hat レビューア、ceph-csiメンテナ 12 Jiffin Tony Thottan Red Hat メンテナ 7 Umanga Chapagain Red Hat 7 n.Fraison 不明 7 Dmitry Yusupov Nexenta EdgeFSメンテナ 7 Alexander Trost Cloudical 5 Binoue サイボウズ
33. 目次 1. 前提知識 2. Rook最新安定版(v1.3)の変更点 3. Rook次期安定版(v1.4)の開発状況 4. Rookを取り巻く状況 33
34. プロジェクトの成熟度 ▌プロダクション環境で少なくとも20社が使用中 ⚫Github.com/rook/rook/ADOPTERS.md ▌CNCFのGraduatedプロジェクト目指して活動中 ⚫現在はIncubatingプロジェクト ⚫順調に進行中 34
35. Rook/Cephを使う製品 ▌Red Hat OpenShift Container Storage4 ⚫4月にv4.3がリリース済 ▌Containerized SUSE Enterprise Storage 6 on CaaS Platform 4 Kubernetes Cluster ⚫Technical Preview
36. まとめ ▌Rook/Cephは成熟度を高めながら活発に開発中 ▌ユーザも増え続けている ▌サイボウズは今後も継続的に貢献 ⚫機能/テスト/ドキュメント追加 ⚫バグ修正 ⚫ユーザサポート 36
37. 参考リンク ▌ストレージオーケストレーターRookへのサイボウズのコミット方針 ⚫ https://blog.cybozu.io/entry/2019/12/03/114746 ▌賢く「散らす」ための Topology Spread Constraints ⚫ https://speakerdeck.com/ytaka23/kubernetes-meetup-tokyo-25th ▌Scheduling Profileが実現するPod配置戦略の最前線 ⚫ https://speakerdeck.com/ytaka23/infra-study-meetup-2nd ▌Kubernetesでローカルストレージを有効活用しよう ⚫ https://blog.cybozu.io/entry/2019/11/08/090000 37
38. 38 Thank you! Any question?