rook/ceph의crash-collectorpod

개시하다

이 글은 Rook과 파트너, 클라우드 로컬 스토리지의 Advent Calendar 2020 15일째 되는 날 몰래 기입한 것이다.제가 Crash-collector pod를 설명해 드릴게요.

과업

이pod의 역할은 룩부터 사용crash 모듈이 제공하는 기능이다.
/var/lib/ceph/crash 이하에 MON, MGR, OSD 등 Ceph의 다양한 데몬 이상이 끝날 때 만들어진 crash report 정보입니다.그런데 여기 문제가 하나 있어요.Ceph 클러스터는 대규모로 수백, 수천개의 노드로 구성되어 있으며, Crash report를 보기 위해 데몬이 떨어진 노드를 하나하나 방문하는 것은 매우 번거롭다.
이 문제를 해결하기 위해 탄생한 것은crash 모듈이다.crash 모듈은 Crash report를 Ceph 내부에 있는 config-key KVS에 저장하여 관리합니다.이외에도 Ceph는 10분마다/var/lib/ceph/crash를 스캔한 후 새로운crash report ceph-crash 를 수집하는 스크립트를 제공합니다.crash 모듈과 ceph-crash의 조합을 통해crash 리포트를 통일적으로 관리할 수 있습니다.
룩이 하는 일은 매우 간단하다. 단지 자신이 ceph와 관련된pod를 만든 모든 노드에서 ceph-crash동작crash-collectorpod를 했을 뿐이다.crash-collector는daemonset이 아니라 deployment로 실시되기 때문에 무관한node에서 쓸모없는pod를 실행하는 것을 피합니다.

견본

먼저 SIGSEGV를 제작이 완료된 Rook/Ceph 클러스터의 OSD pod에 전송하고 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 리포트가 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 중 하나에 대해 설명하였다.