rook/cephのcrash-collector pod

はじめに

本記事はRookと仲間たち、クラウドネイティブなストレージの Advent Calendar 202015日目を後からこっそり埋めたものです。crash-collector podについて述べます。

役割

このpodの役割は、crashモジュールが提供する機能をRookから使うことです。

CephはMON,MGR,OSDなどのCephの各種daemonが異常終了したときに作られるcrash reportと呼ばれる情報を/var/lib/ceph/crash以下に格納します。しかし、ここで一つ問題があります。Cephクラスタは大規模なものだと数百、数千ノードから構成され、crash reportを見るためにいちいちdaemonが落ちたnodeにアクセスするのは非常に面倒です。

この問題を解決するために生まれたのがcrashモジュールです。crashモジュールはcrash reportを、Cephが内部的に持っているconfig-keyと呼ばれるKVSに保存、管理するものです。これに加えてCephは10分に1回/var/lib/ceph/crash以下を走査して新しいcrash reportを収集するceph-crashというスクリプトを提供します。crashモジュールとceph-crashの組み合わせによってcrash reportを一元管理できるようになる、というわけです。

Rookがやっていることは非常に単純で、自身がceph関連のpodを作成した全ノード上にceph-crashを動かすcrash-collector podを作るだけです。crash-collectorはdaemonsetではなくdeploymentとして実装されているために、関係ないnode上で無駄なpodを実行するのを避けています。

サンプル

まずは作成済のRook/CephクラスタのOSD podにSIGSEGVを送って意図的にcrash reportを生成します。

$ kubectl -n rook-ceph exec -it rook-ceph-osd-0-6874455499-szfqm -- bash
# kill -SEGV 1

このときcrash reportが/var/lib/ceph/以下に作成されます。2020-ではじまるディレクトリ以下にあるファイルが該当します。

# ls /var/lib/ceph/crash
2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b/ posted/

ceph-crashが動作するように10分待つと、上記ディレクトリはpostedディレクトリ以下に移動するとともにconfig-keyに保存されます。

# ls /var/lib/ceph/crash/posted/
2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b/

toolboxコマンドからceph crash lsコマンドを実行すると上記crash reportがconfig-keyに保存されていることがわかります。

$ kubectl -n rook-ceph exec -it rook-ceph-tools-549bfc67cd-5wm68 -- ceph crash ls
ID                                                                ENTITY  NEW
2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b  osd.0    *

ceph crash infoコマンドによってcrash reportの中身が見られます。

$ kubectl -n rook-ceph exec -it rook-ceph-tools-549bfc67cd-5wm68 -- ceph crash ls
ID                                                                ENTITY  NEW
2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b  osd.0    *
sat@ubuntu1804:~/go/src/github.com/rook/rook$ kubectl -n rook-ceph exec -it rook-ceph-tools-549bfc67cd-5wm68 -- ceph crash info 2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b
{
    "backtrace": [
        "(()+0x12b20) [0x7f9e53109b20]",
        "(pthread_cond_wait()+0x1fc) [0x7f9e531052fc]",
        "(std::condition_variable::wait(std::unique_lock<std::mutex>&)+0x10) [0x7f9e527538f0]",
        "(AsyncMessenger::wait()+0x1ff) [0x55d56e76bdaf]",
        "(main()+0x48ac) [0x55d56df1f32c]",
        "(__libc_start_main()+0xf3) [0x7f9e51d5d7b3]",
        "(_start()+0x2e) [0x55d56df4d56e]"
    ],
    "ceph_version": "15.2.8",
    "crash_id": "2020-12-31T20:16:48.073102Z_137b9a10-3b2f-43b4-b7be-900eb2f6a61b",
    "entity_name": "osd.0",
    "os_id": "centos",
    "os_name": "CentOS Linux",
    "os_version": "8",
    "os_version_id": "8",
    "process_name": "ceph-osd",
    "stack_sig": "2a31fa65a650777a15845b7c557d0a172fa949a4ca9cea6da934856404748ad9",
    "timestamp": "2020-12-31T20:16:48.073102Z",
    "utsname_hostname": "rook-ceph-osd-0-6874455499-szfqm",
    "utsname_machine": "x86_64",
    "utsname_release": "4.15.0-99-generic",
    "utsname_sysname": "Linux",
    "utsname_version": "#100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020"
}

おわりに

大規模クラスタではクラスタを構成するノード上の各種情報の一元化が非常に大事です。本記事ではそのうちの一つ、crash reportの一元化をするcrash-collector podについて説明しました。