Kubernetes実践トラブルシューティング

Transcript

1. Kubernetes 実践トラブルシューティング Aug. 26th, 2021 sat@サイボウズ ストレージチーム 1

2. はじめに ▌サイボウズのインフラ基盤はKubernetesクラスタ ▌ストレージもK8sクラスタ上に構築 ⚫Rook/Ceph(後述)によって分散ストレージを提供 ▌ストレージ開発中に発生した問題を例にトラブル シューティングのノウハウを共有 ⚫ストレージ、Rook/Cephについての前提知識は不要 2

3. このセッションで学べること ▌実際に起きた問題のトラブルシューティングの流れ ▌なぜその調査をしたのか、という思考プロセス ▌ログやメトリクスの重要性 3

4. もくじ ▌Rook/Ceph概要 ▌サイボウズのRook/Cephクラスタと監視/ログ基盤 ▌トラブル解析事例 ▌まとめ 4

5. Rook/Ceph概要 5

6. Cephとは ▌OSSのスケーラブルな分散ストレージ ⚫多くの種類のストレージを提供可能(後述) ⚫ペタバイトスケールのデータを扱える ▌20年以上にわたって幅広く使われてきた ⚫CERN, NASA ▌主な開発元はRed Hat ⚫Red

   Hat Ceph Storageなどの製品を提供 6

7. 提供するストレージの種類 ▌S3互換オブジェクトストレージRGW ⚫今日取り扱うのはこれ ▌ブロックデバイスRBD ▌分散ファイルシステムCephFS 7

8. アーキテクチャ 8 アプリ ストレージプール Ceph node node node … RBD

   RGW ブロックデバイス オブジェクト ブロックデバイス ブロックデバイス オブジェクト オブジェクトストレージ CephFS ブロックデバイス ブロックデバイス 分散ファイルシステム

9. ▌RGWが提供するendpointにアプリがアクセス オブジェクトストレージの使い方 9 Rook/Cephクラスタ アプリ RGW daemon

10. Rookとは ▌Kubernetes上で動作するCephのオーケストレータ ⚫CNCFのgraduated Project ▌主な開発元 ⚫Red Hat, サイボウズ ▌製品 ⚫Red

    Hat OpenShift Container Storage 10

11. Rook/Ceph関連コンポーネント 11 K8sクラスタ Rook/Cephクラスタ オブジェクト ストレージ ブロック ストレージ HDD node

    HDD アプリ Rook/Cephオペレータ CephCluster CR 操作 参照

12. オブジェクトストレージの使い方 12 K8sクラスタ Rook/Cephクラスタ アプリのPod RGW Pod

13. サイボウズの Rook/Cephクラスタと監視/ログ基盤 13

14. なぜRook/Cephなのか ▌商用製品はできれば避けたい ⚫ユーザデータは極めて重要 ⚫データ消失するとお客様もサイボウズも大ダメージ ⚫無いものは無い。取り返しがつかない ⚫商用製品には勝手に手を入れられない ⚫トラブル発生時にとれる手段が減る ▌OSSの自前運用が有力な選択肢 ⚫Rook/Cephが要件を満たしていた 14

15. サイボウズのRook/Cephクラスタ 15 K8sクラスタ Rook/Cephクラスタ (HDD) オブジェクト ストレージ ブロック ストレージ HDD

    node node SSD HDD HDD SSD NVMe SSD アプリ Rook/Cephクラスタ (NVMe SSD) ブロック ストレージ

16. 開発/運用プロセス 1. 検証&構築&実機上で運用 2. 課題が見つかる ⚫基本はupstreamで修正&次回の新版を使う ⚫マージまで一時的に独自版運用 and/or パラメタ設定で回避 ⚫マージ不可能ならば上記の運用を続けることも許容

    3. 1に戻る 16

17. 監視/ログ基盤 17 Rook/Cephクラスタ Loki (ログ基盤) VictoriaMetrics (監視基盤) オブジェクト ストレージ ブロック

    ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard アプリ監視用 Rook/Ceph監視用

18. 監視/ログ基盤の使い方(1/4) 18 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node

    SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ①メトリクス収集 ①ログ収集

19. 監視/ログ基盤の使い方(2/4) 19 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node

    SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ②通知

20. 監視/ログ基盤の使い方(3/4) 20 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node

    SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ③操作

21. 監視/ログ基盤の使い方(4/4) 21 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node

    SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ④クエリ発行

22. 監視/ログ基盤の嬉しさ ▌システムのログやメトリクスを一か所に保存できる ▌システム全体の長期的な挙動がわかる ⚫ 「正常なときと異常なときと何が違うか」など ⚫ クエリ言語(PromQL, LogQL)により一括して情報を取得可能 ▌システムにおかしなことがあれば技術者に通知できる ⚫

    技術者が常にダッシュボードを監視していなくてよい 22

23. トラブル解析事例 23

24. 発生した問題 ▌RGW podが落ちたというAlertが数十秒に1回飛んできた ▌考えられる可能性 ⚫ Pod内でエラーが起きて死んでいる ⚫ {liveness,readiness}Probeで死んでいる ▌可能性は五分五分なので上から順番に 24

    Rook/Cephクラスタ(HDD) RGW Pod

25. Pod内で死んでいるかどうかの確認 ▌ログを見る ⚫DashboardからLokiのログを確認 ▌以下のようなログが繰り返し出力されていた ▌“…lock failed”というメッセージは問題ないとわかった ▌しかし自ら強制終了した形跡はない - NOTICE: resharding

    operation on bucket index detected, blocking - RGWReshardLock::lock failed to acquire lock on loki-bucket-XXX ret=-16 25

26. {liveness,readiness}Probeの発生有無を確認 ▌Podに起きたイベントを確認 ▌livenessProbeで殺され続けていた ▌Next action ⚫livenessProbeで何をチェックしているか確認 $ kubectl –n ceph-hdd

    describe pod rook-ceph-rgw-XXX … Events: … spec.containers{rgw} Warning Unhealthy Liveness probe failed:… 26

27. livenessProbeの設定を確認 ▌RGW Podの定義を見る ▌Endpointは”swift/healthcheck” ▌Next action ⚫上記endpointの意味を調べる $ kubectl get

    pod rook-ceph-rgw-XXX –o yaml … livenessProbe: … httpGet: path: /swift/healthcheck … 27

28. /swift/healthcheckの意味を調査 1. Web検索&ソース調査 2. RGWのサービスが生きていれば成功するとわかった 3. ダッシュボードからRGWのオブジェクト数を確認 28 オブジェクト数→ 時間→

    • 全然増えていない • 普段はLokiが作るオブジェクトが 定期的に増える

29. 状況の整理 ▌明らかになったこと 1. RGWのサービスが停止している 2. livenessProbeの使い方を間違えている ⚫ livenessProbe: Podの正常動作可否を確認 ⚫

    readinessProbe: サービス提供可否を確認 ▌Next action ⚫重要度が高い①を先に調査 29

30. なぜサービスが停止するのかを調査 ▌RGW podのログを再び確認 ▌Dynamic resharding(後述)という処理が繰り返し動いている 0 block_while_resharding ERROR: bucket is

    still resharding, please retry 0 check_bucket_shards: resharding needed: … 0 check_bucket_shards: resharding needed: … … 0 NOTICE: resharding operation on bucket index detected, blocking 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000009 ret=-16 1 RGWRados::check_bucket_shards bucket loki-bucket-XXX needs resharding; … 30

31. Dynamic reshardingとは ▌resharding ⚫1つのbucketに対して1つindexが存在 ⚫ オブジェクト名からオブジェクトの場所を引く ⚫Indexは複数の領域にshardされている ⚫オブジェクト数増加にって検索速度が劣化 ⚫速度の劣化はreshardによって防げる ▌Dynamic

    resharding ⚫オブジェクト数が増えてくると自動的にreshardする機能 31

32. 仮説 ▌以下のようにreshard処理が永久に終わらない 1. オブジェクト数が増えたためdynamic resharding発動 2. Reshard中は/swift/healthcheckを叩くと失敗 3. ゆえにRGW PodのlivenessProbeが失敗

    4. Podが殺される 5. Reshard処理が中断 6. 1に戻る ▌Next Action ⚫実際にそうなっているか確認 32

33. Reshardのstatusを確認 ▌Reshard処理の進捗を確認 ▌定期的にreshard処理が失敗し続けていた ⚫ 仮説は裏付けられた $ radosgw-admin reshard status --bucket=loki-bucket-XXX

    [ { "reshard_status": "in-progress", "new_bucket_instance_id": “YYY", "num_shards": 419 }, { "reshard_status": "in-progress", "new_bucket_instance_id": “YYY", "num_shards": 419 }, … 33

34. 対策を考える ▌短期対策 ⚫今まさにオブジェクトストレージが使えない問題を解決 ▌中長期対策 ⚫次回以降問題を起きなくする ⚫短期対策の後で考える 34

35. 短期対策 ▌livenessProbeを無効化してreshardを実行 ▌手順 1. operatorを一時停止(deploymentのreplica数を0に) ⚫ 以下操作の後にoperatorがDeploymentを再度書き換えるのを防ぐ 2. RGWのDeploymentからlivenessProbeを削除 3.

    手動でreshard処理を起動 4. reshard終わったらoperatorを再度動かす 35

36. 結果 ▌数十分後に無事終了 36 オブジェクト数→ 時間→ reshard開始 Reshard終了

37. 中期対策 ▌考えられる案 1. dynamic reshardingを無効化 2. 最初からshardの数を十分に増やしておく ▌ひとまず上記対処は見送り ⚫次に起きるのは数か月後 ⚫現状このストレージは可用性の保証がない

    ⚫他に優先すべきタスクがある 37

38. 長期対策 1. まずは過去事例調査 ⚫Rookにほぼ同じissueが報告されていた 2. Issueにコメントして議論開始 3. 長期対策向けの方針を決定 ⚫最新版のCephで再現させ、再現するならreshard処理中にサービス停 止をしなくするよう活動(自分でPR投げるかも)

    ⚫RookのlivenessProbeのありかたについて議論 38

39. 得られたもの ▌今後同じ問題を回避できるようになった ▌技術者の経験値が上がった ⚫今後の類似トラブル調査に当たりがつくようになった 39

40. その他トラシュー用のTIPS ▌システムに対して「いつ」「何をしたか」を常に記録 ⚫何か起きたときに発生契機を突き止めるためのヒントになる ▌調査中のログも可能な限り残す ⚫今後の調査に役立つ ▌最後にwikiなどにまとめる ⚫色々なところに情報が散らばっていると後から追いにくい ⚫そのうち記憶が無くなる 40

41. まとめ 41

42. 学んだこと ▌実際に起きた問題のトラブルシューティングの流れ ▌なぜその調査をしたのか、という思考プロセス ▌ログやメトリクスの重要性 42

43. 今後について ▌やること ⚫性能チューニング&可用性を高める ⚫技術者を育てる ⚫機能追加 ⚫ リモートレプリケーション ⚫ バックアップ/リストア ⚫既存データの移行

    ▌一緒に働いてくれるかたを募集中! 43

44. 44 おわり