Slide 1
Slide 1 text
Kubernetes
実践トラブルシューティング
Aug. 26th, 2021
sat@サイボウズ ストレージチーム
1
Slide 2
Slide 2 text
はじめに
▌サイボウズのインフラ基盤はKubernetesクラスタ
▌ストレージもK8sクラスタ上に構築
⚫Rook/Ceph(後述)によって分散ストレージを提供
▌ストレージ開発中に発生した問題を例にトラブル
シューティングのノウハウを共有
⚫ストレージ、Rook/Cephについての前提知識は不要
2
Slide 3
Slide 3 text
このセッションで学べること
▌実際に起きた問題のトラブルシューティングの流れ
▌なぜその調査をしたのか、という思考プロセス
▌ログやメトリクスの重要性
3
Slide 4
Slide 4 text
もくじ
▌Rook/Ceph概要
▌サイボウズのRook/Cephクラスタと監視/ログ基盤
▌トラブル解析事例
▌まとめ
4
Slide 5
Slide 5 text
Rook/Ceph概要
5
Slide 6
Slide 6 text
Cephとは
▌OSSのスケーラブルな分散ストレージ
⚫多くの種類のストレージを提供可能(後述)
⚫ペタバイトスケールのデータを扱える
▌20年以上にわたって幅広く使われてきた
⚫CERN, NASA
▌主な開発元はRed Hat
⚫Red Hat Ceph Storageなどの製品を提供
6
Slide 7
Slide 7 text
提供するストレージの種類
▌S3互換オブジェクトストレージRGW
⚫今日取り扱うのはこれ
▌ブロックデバイスRBD
▌分散ファイルシステムCephFS
7
Slide 8
Slide 8 text
アーキテクチャ
8
アプリ
ストレージプール
Ceph
node node node
…
RBD
RGW
ブロックデバイス
オブジェクト ブロックデバイス
ブロックデバイス
オブジェクト
オブジェクトストレージ
CephFS
ブロックデバイス
ブロックデバイス
分散ファイルシステム
Slide 9
Slide 9 text
▌RGWが提供するendpointにアプリがアクセス
オブジェクトストレージの使い方
9
Rook/Cephクラスタ
アプリ
RGW daemon
Slide 10
Slide 10 text
Rookとは
▌Kubernetes上で動作するCephのオーケストレータ
⚫CNCFのgraduated Project
▌主な開発元
⚫Red Hat, サイボウズ
▌製品
⚫Red Hat OpenShift Container Storage
10
Slide 11
Slide 11 text
Rook/Ceph関連コンポーネント
11
K8sクラスタ
Rook/Cephクラスタ
オブジェクト
ストレージ
ブロック
ストレージ
HDD
node
HDD
アプリ
Rook/Cephオペレータ
CephCluster CR
操作
参照
Slide 12
Slide 12 text
オブジェクトストレージの使い方
12
K8sクラスタ
Rook/Cephクラスタ
アプリのPod
RGW Pod
Slide 13
Slide 13 text
サイボウズの
Rook/Cephクラスタと監視/ログ基盤
13
Slide 14
Slide 14 text
なぜRook/Cephなのか
▌商用製品はできれば避けたい
⚫ユーザデータは極めて重要
⚫データ消失するとお客様もサイボウズも大ダメージ
⚫無いものは無い。取り返しがつかない
⚫商用製品には勝手に手を入れられない
⚫トラブル発生時にとれる手段が減る
▌OSSの自前運用が有力な選択肢
⚫Rook/Cephが要件を満たしていた
14
Slide 15
Slide 15 text
サイボウズのRook/Cephクラスタ
15
K8sクラスタ
Rook/Cephクラスタ
(HDD)
オブジェクト
ストレージ
ブロック
ストレージ
HDD
node node
SSD
HDD
HDD SSD
NVMe SSD
アプリ
Rook/Cephクラスタ
(NVMe SSD)
ブロック
ストレージ
Slide 16
Slide 16 text
開発/運用プロセス
1. 検証&構築&実機上で運用
2. 課題が見つかる
⚫基本はupstreamで修正&次回の新版を使う
⚫マージまで一時的に独自版運用 and/or パラメタ設定で回避
⚫マージ不可能ならば上記の運用を続けることも許容
3. 1に戻る
16
Slide 17
Slide 17 text
監視/ログ基盤
17
Rook/Cephクラスタ
Loki
(ログ基盤)
VictoriaMetrics
(監視基盤)
オブジェクト
ストレージ
ブロック
ストレージ
HDD
node node SSD
HDD
HDD SSD
NVMe SSD
VictoriaMetrics
(監視基盤)
Grafana Dashboard
アプリ監視用
Rook/Ceph監視用
Slide 18
Slide 18 text
監視/ログ基盤の使い方(1/4)
18
Rook/Cephクラスタ
Loki
(ログ基盤)
オブジェクト
ストレージ
HDD
node node SSD
HDD
HDD SSD
NVMe SSD
VictoriaMetrics
(監視基盤)
Grafana Dashboard
①メトリクス収集
①ログ収集
Slide 19
Slide 19 text
監視/ログ基盤の使い方(2/4)
19
Rook/Cephクラスタ
Loki
(ログ基盤)
オブジェクト
ストレージ
HDD
node node SSD
HDD
HDD SSD
NVMe SSD
VictoriaMetrics
(監視基盤)
Grafana Dashboard
②通知
Slide 20
Slide 20 text
監視/ログ基盤の使い方(3/4)
20
Rook/Cephクラスタ
Loki
(ログ基盤)
オブジェクト
ストレージ
HDD
node node SSD
HDD
HDD SSD
NVMe SSD
VictoriaMetrics
(監視基盤)
Grafana Dashboard
③操作
Slide 21
Slide 21 text
監視/ログ基盤の使い方(4/4)
21
Rook/Cephクラスタ
Loki
(ログ基盤)
オブジェクト
ストレージ
HDD
node node SSD
HDD
HDD SSD
NVMe SSD
VictoriaMetrics
(監視基盤)
Grafana Dashboard
④クエリ発行
Slide 22
Slide 22 text
監視/ログ基盤の嬉しさ
▌システムのログやメトリクスを一か所に保存できる
▌システム全体の長期的な挙動がわかる
⚫ 「正常なときと異常なときと何が違うか」など
⚫ クエリ言語(PromQL, LogQL)により一括して情報を取得可能
▌システムにおかしなことがあれば技術者に通知できる
⚫ 技術者が常にダッシュボードを監視していなくてよい
22
Slide 23
Slide 23 text
トラブル解析事例
23
Slide 24
Slide 24 text
発生した問題
▌RGW podが落ちたというAlertが数十秒に1回飛んできた
▌考えられる可能性
⚫ Pod内でエラーが起きて死んでいる
⚫ {liveness,readiness}Probeで死んでいる
▌可能性は五分五分なので上から順番に
24
Rook/Cephクラスタ(HDD)
RGW Pod
Slide 25
Slide 25 text
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
Slide 26
Slide 26 text
{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
Slide 27
Slide 27 text
livenessProbeの設定を確認
▌RGW Podの定義を見る
▌Endpointは”swift/healthcheck”
▌Next action
⚫上記endpointの意味を調べる
$ kubectl get pod rook-ceph-rgw-XXX –o yaml
…
livenessProbe:
…
httpGet:
path: /swift/healthcheck
…
27
Slide 28
Slide 28 text
/swift/healthcheckの意味を調査
1. Web検索&ソース調査
2. RGWのサービスが生きていれば成功するとわかった
3. ダッシュボードからRGWのオブジェクト数を確認
28
オブジェクト数→
時間→
• 全然増えていない
• 普段はLokiが作るオブジェクトが
定期的に増える
Slide 29
Slide 29 text
状況の整理
▌明らかになったこと
1. RGWのサービスが停止している
2. livenessProbeの使い方を間違えている
⚫ livenessProbe: Podの正常動作可否を確認
⚫ readinessProbe: サービス提供可否を確認
▌Next action
⚫重要度が高い①を先に調査
29
Slide 30
Slide 30 text
なぜサービスが停止するのかを調査
▌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
Slide 31
Slide 31 text
Dynamic reshardingとは
▌resharding
⚫1つのbucketに対して1つindexが存在
⚫ オブジェクト名からオブジェクトの場所を引く
⚫Indexは複数の領域にshardされている
⚫オブジェクト数増加にって検索速度が劣化
⚫速度の劣化はreshardによって防げる
▌Dynamic resharding
⚫オブジェクト数が増えてくると自動的にreshardする機能
31
Slide 32
Slide 32 text
仮説
▌以下のようにreshard処理が永久に終わらない
1. オブジェクト数が増えたためdynamic resharding発動
2. Reshard中は/swift/healthcheckを叩くと失敗
3. ゆえにRGW PodのlivenessProbeが失敗
4. Podが殺される
5. Reshard処理が中断
6. 1に戻る
▌Next Action
⚫実際にそうなっているか確認
32
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
対策を考える
▌短期対策
⚫今まさにオブジェクトストレージが使えない問題を解決
▌中長期対策
⚫次回以降問題を起きなくする
⚫短期対策の後で考える
34
Slide 35
Slide 35 text
短期対策
▌livenessProbeを無効化してreshardを実行
▌手順
1. operatorを一時停止(deploymentのreplica数を0に)
⚫ 以下操作の後にoperatorがDeploymentを再度書き換えるのを防ぐ
2. RGWのDeploymentからlivenessProbeを削除
3. 手動でreshard処理を起動
4. reshard終わったらoperatorを再度動かす
35
Slide 36
Slide 36 text
結果
▌数十分後に無事終了
36
オブジェクト数→
時間→
reshard開始
Reshard終了
Slide 37
Slide 37 text
中期対策
▌考えられる案
1. dynamic reshardingを無効化
2. 最初からshardの数を十分に増やしておく
▌ひとまず上記対処は見送り
⚫次に起きるのは数か月後
⚫現状このストレージは可用性の保証がない
⚫他に優先すべきタスクがある
37
Slide 38
Slide 38 text
長期対策
1. まずは過去事例調査
⚫Rookにほぼ同じissueが報告されていた
2. Issueにコメントして議論開始
3. 長期対策向けの方針を決定
⚫最新版のCephで再現させ、再現するならreshard処理中にサービス停
止をしなくするよう活動(自分でPR投げるかも)
⚫RookのlivenessProbeのありかたについて議論
38
Slide 39
Slide 39 text
得られたもの
▌今後同じ問題を回避できるようになった
▌技術者の経験値が上がった
⚫今後の類似トラブル調査に当たりがつくようになった
39
Slide 40
Slide 40 text
その他トラシュー用のTIPS
▌システムに対して「いつ」「何をしたか」を常に記録
⚫何か起きたときに発生契機を突き止めるためのヒントになる
▌調査中のログも可能な限り残す
⚫今後の調査に役立つ
▌最後にwikiなどにまとめる
⚫色々なところに情報が散らばっていると後から追いにくい
⚫そのうち記憶が無くなる
40
Slide 41
Slide 41 text
まとめ
41
Slide 42
Slide 42 text
学んだこと
▌実際に起きた問題のトラブルシューティングの流れ
▌なぜその調査をしたのか、という思考プロセス
▌ログやメトリクスの重要性
42
Slide 43
Slide 43 text
今後について
▌やること
⚫性能チューニング&可用性を高める
⚫技術者を育てる
⚫機能追加
⚫ リモートレプリケーション
⚫ バックアップ/リストア
⚫既存データの移行
▌一緒に働いてくれるかたを募集中!
43
Slide 44
Slide 44 text
44
おわり