Rook/Ceph upstream最新状況

本スライド公開時点(2020/3/27)でのRook最新版v1.2におけるRook/Cephの新機能、およびv1.3の開発状況について紹介しています。

Japan Rook Meetup #2の発表資料です。

Transcript

1. Rook/Ceph upstream最新状況 Japan Rook Meetup #2 Cybozu, Inc. Neco Project Satoru Takeuchi Twitter: @satoru_takeuchi 1
2. はじめに ▌サイボウズとRook/Cephの関係 ⚫自社サービスの次期インフラ基盤に Rook/Cephを採用 ⚫upstream firstでバグ修正&機能追加する方針 ▌本セッションの目的 ⚫検証/開発活動で得た情報を共有
3. 目次 1. 前提知識: OSD作成方法 2. Rook最新安定版(v1.2)の新機能 3. Rook次期安定版(v1.3)の開発状況 4. Rookを取り巻く状況 3
4. 目次 1. 前提知識: OSD作成方法 2. Rook最新安定版(v1.2)の新機能 3. Rook次期安定版(v1.3)の開発状況 4. Rookを取り巻く状況 4
5. デバイス 従来の方法 ユーザが 指定 OSD on PVC(v1.1～) PVC template (Block Volume) Rookの クラスタリソース Kubernetes Linux Rookの クラスタリソース OSDの設定 CSIドライバ ユーザはここを 気にしなくていい ユーザが 指定 5 OSD作成方法 OSDの設定 PVを作成
6. 従来の方法 ▌ノード上のデバイス名を直接指定 apiVersion: ceph.rook.io/v1 kind: CephCluster … 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 • クラスタ管理者にハードウェア構成の知識が必要 • K8sの枠外で自力構成
7. クラスタ管理者はOSD podがどこにあるかを 気にしなくていい OSD on PVC ▌CSIドライバ提供のblock volumeを使う spec: … storageClassDeviceSets: - name: set0 count: 3 … volumeClaimTemplates: - metadata: name: data spec: resources: requests: storage: 10Gi storageClassName: my-class 7 PVC Set0-0 PVC set0-1 OSD OSD OSD Pod OSD Pod PVC set0-2 OSD OSD Pod 同、PVCの提供方法を気にしなくてよい
8. 目次 1. 前提知識: 2種類のOSD作成方法 2. Rook最新安定版(v1.2)の新機能 3. Rook次期安定版(v1.3)の開発状況 4. Rookを取り巻く状況 8
9. OSD on PVCでLVをサポート ▌OSD on LV-backed PVC(サイボウズ作) ▌サイボウズのOSD on PVCのユースケース ⚫ローカルのNVMe SSD上にOSDを作りたい ⚫管理コスト削減のためDynamic provisioningを使いたい 9
10. 前記ユースケースの理想的な実現 10 NVMe SSD NVMe SSD PVC PVC PVC OSD OSD アプリAのPod OSD Pod OSD Pod CSIドライバが管理 Dynamic provisioning
11. 既存の方法では理想通りいかない 11 ▌以下条件を満たすCSIドライバが無い ⚫ローカルボリューム向け ⚫dynamic provisioningをサポート ⚫POCレベルではなく実用的 ▌→デバイス追加時に手作業でPV作成が必要
12. 解決方法: 要件を満たすドライバを自作 12 NVMe SSD NVMe SSD Volume Group Logical Volume Logical Volume Logical Volume PVC PVC PVC OSD OSD アプリAのPod OSD Pod OSD Pod サイボウズ自作 CSIドライバ TopoLVMが管理 Dynamic provisioning
13. デバイス 従来の方法 ユーザが 指定 OSD on PVC PVC template (Block Volume) Rookの クラスタリソース Kubernetes Linux Rookの クラスタリソース OSDの設定 OSD on PVC(TopoLVM) 物理デバイス 物理デバイス 物理デバイス Volume Group Logical Volume Logical Volume Logical Volume PVC template (Block Volume) Rookの クラスタリソース TopoLVM CSIドライバ ユーザはここを 気にしなくていい ユーザが 指定 ユーザが 指定 13 OSDの作成方法(TopoLVM含む) OSDの設定 OSDの設定 PVを作成 PVを作成
14. 従来方式でudev persistent nameをサポート ▌V1.1以前 ⚫/dev/直下のデバイスのみ指定可能 ⚫Udevのpersistent device nameが使えなかった ⚫ /dev/直下のデバイス名は変わりうるのでデータ破壊の危険あり ▌V1.2以降 ⚫新機能devicePathFilter(サイボウズ作) ⚫ 絶対パスを使ったデバイスを指定可能 ⚫Udev persisten device name使用可能 ⚫ 例: devicePathFilter: /dev/disk/by-path/pci-0:1:2:3-scsi-1
15. その他変更 ▌デバッグ支援機能cech-crash collector ⚫MON,OSDなどの各種デーモンのクラッシュ情報 をCephクラスタに保存 ⚫トラブルシューティングに便利 ⚫デフォルトで有効 ▌FileStore OSDがobsoleteに ⚫既存のFileStore OSDはサポートし続ける
16. 目次 1. 前提知識: 2つのOSD作成方法 2. Rook最新安定版(v1.2)の新機能 3. Rook次期安定版(v1.3)の開発状況 4. Rookを取り巻く状況 16
17. Failure domainをまたいだOSDの均等分散配置 ▌K8sのTopologySpreadConstraints機能のサポート ⚫OSD on PVCにほぼ必須 ⚫次ページで機能説明 ▌実装完了&テスト作成中(サイボウズ) ⚫V1.3でサポート予定 17
18. topologySpreadConstraintsが必要な例 ▌クラスタ構成 ⚫ 2ラック構成のクラスタ ⚫ 1ラック2ノード ⚫ データのレプリカは2つ ▌要件 ⚫ ラック障害耐性 ⚫ ノード障害耐性 18 rack1 rack0 node0 node1 node2 node3
19. おさらい ▌K8sではPodは通常どのノードで動くか不明 ⚫OSD on PVCにおけるOSD Podも同様 ▌例えばOSD数を2にすると以下のようになるかも 19 rack1 rack0 node0 node1 node2 node3 OSD Pod OSD Pod
20. 問題 ▌ここでrack0が故障するとデータにアクセス不能 ▌→ラック障害耐性無し 20 rack1 rack0 node0 node1 node2 node3 OSD Pod OSD Pod
21. topologySpreadConstraints ▌複数のPodをノードやラックなどの間で均等分散配置可能 ⚫入れ子構造も可能 ⚫K8s 1.18でbetaに 21
22. 機能使用時のOSD Podのスケジュール 22 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にスケジュール
23. OSD on LV-backed PVCのテスト追加 ▌RookはPRマージ時にテスト全パスが必須 ⚫OSD on LV-backed PVCのテストはまだ無い ⚫将来のリグレッションを避けるためにテストが欲しい ▌鋭意作成中(サイボウズ) ⚫サイボウズ作のTopoLVMを使用 ▌が…現在は3つの大きな壁に衝突中 23
24. 壁1: masterでOSD on LV-backed PVCが動かない ▌下記PRのマージ時にリグレッション発生 ▌Issue発行済&修正作成中(サイボウズ) ▌CI重要！ 24
25. 壁2: テストがテスト環境を破壊 ▌テスト冒頭でシステムの全LV/VG/PVを強制削除 ⚫テスト環境の初期化(OSDの削除)のために存在する処理 ⚫公式CI環境ではテスト以外にLVMを使わないので問題無し ⚫筆者の環境はLV上にインストールされたUbuntu! ▌PR送付済&マージ待ち 25
26. 壁3: ローカル環境でテストがパスしない ▌CIがパスするbranchをローカル環境でテストすると約半分が失敗 ⚫ どうやらRBDのテストが怪しいらしい ▌修正予定。鋭意調査中(サイボウズ) 26
27. FileStoreの新規作成が不可能に ▌今後作成されるOSDは全てBlueStore ▌既存のFileStore OSDはサポートし続ける 27
28. ストレージプロバイダ ▌新ストレージプロバイダは無し ▌V1.3でMinioのコードを削除 ⚫理由: 誰もメンテしていない ▌現在のストレージプロバイダの問題点 ⚫コア部分と全ストレージプロバイダを同じリポジトリで管理 ⚫ リリースサイクルが同じで開発がやりにくい ⚫今後ストレージプロバイダを別リポジトリに分けるかも ⚫ まだ議論は始まったばかり
29. 参考: V1.3開発における主な貢献者 コミット数 名前 備考 188 Sébastien Han@Red Hat メンテナ 170 Travis Nielsen@Red Hat メンテナ 23 Blaine Gardner@SUSE メンテナ 17 Madhu Rajanna 12 Alexander Trost メンテナ 10 Nizamudeen@Red Hat 9 Dmitry Yusupov@Nexenta NexentaはEdgeFs開発元 8 Satoru Takeuchi@サイボウズ 8 Ashish Ranjan@Red Hat 7 Juan Miguel Olmo Martínez@Red Hat
30. その他サイボウズからの貢献予定 ▌テストの充実 ⚫テストされていない機能がたくさんある ▌暗号化デバイス上のOSD作成をサポート ⚫RookだけでなくCephも修正が必要 ▌今後の使用中に見つけたバグ、機能不測の解決 30
31. 目次 1. 前提知識: 2つのOSD作成方法 2. Rook最新安定版(v1.2)の新機能 3. Rook次期安定版(v1.3)の開発状況 4. Rookを取り巻く状況 31
32. プロジェクトの成熟度 ▌CNCFのGraduatedプロジェクト目指して活動中 ⚫現在はIncubatingプロジェクト 32
33. Rook/Cephを使う製品 ▌Red Hat OpenShift Container Storage4 ⚫GAリリース済 ▌Containerized SUSE Enterprise Storage on CaaSP ⚫Technical Preview
34. まとめ ▌Rook/Cephは成熟度を高めながら活発に開発中 ▌ユーザも増え続けている ▌サイボウズは今後も継続的に貢献 ⚫機能追加 ⚫バグ修正 ⚫ドキュメント追加 ⚫ユーザサポート 34
35. 参考リンク ▌ストレージオーケストレーターRookへのサイボウズのコミット方針 ⚫ https://blog.cybozu.io/entry/2019/12/03/114746 ▌賢く「散らす」ための Topology Spread Constraints https://speakerdeck.com/ytaka23/kubernetes-meetup-tokyo-25th ▌Kubernetesでローカルストレージを有効活用しよう ⚫ https://blog.cybozu.io/entry/2019/11/08/090000 ▌Rook - Graduation Proposal ⚫ https://docs.google.com/presentation/d/1mMPYMDC4JMGWhoL3FzFgeasSLJepNwYMfwQD- T_gET4/edit#slide=id.g3e2163a66f_0_0 35
36. 36 Thank you! Any question?