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