MongoDB 시스템 CentOS 7.1 crash의 장애물 제거 프로세스

[저자]

왕동: 휴대기술보장센터 데이터베이스 전문가로 데이터베이스 난제에 대한 조사와 데이터베이스 자동화 지능화 운영 도구의 개발에 강한 흥미를 가지고 있습니다.

[문제 설명]

최근에 여러 대의 MongoDB 서버인 CentOS 7.1 시스템에crash가 발생하여 비정기적으로 자동으로 재부팅됩니다.

[사고방식을 배열하다]

1. linux 시스템crash 문제에 부딪히면 우리가 먼저 생각하는 것은 시스템 로그/var/log/message를 검사하여 하드웨어 문제나 다른 원인이 있는지 확인하는 것이다.여러 서버가crash의 시점 메시지에 이상 정보를 기록하지 않은 것을 추출했습니다.
2. CentOS 7의 시스템에 대해 우리는journalctl 도구를 사용하여 내부 핵과 서비스 등에서 발생하는 로그 정보를 볼 수 있다. 관련 로그는 리부팅이 발생한 것만 기록하고 다른 이상 정보는 없다.
3. 일반적인 linux 시스템은 기본적으로 kdump를 설정합니다. kdump는kexec의 핵 붕괴 메모리 메커니즘을 바탕으로 핵 붕괴 시 메모리 이미지를 저장할 수 있습니다.그 중 한 서버에서 우리는/var/crash/127.0.0.1-2018.12.26-00:31:04 디렉터리에서 덤프 파일 vmcore를 찾았다.

【장벽 제거 과정】

1. 생산 환경에 영향을 미치지 않도록 vmcore 파일을 커널 버전과 같은 테스트 서버에 복사합니다
2. crash 도구를 사용하여 vmcore 파일을 분석하고 테스트 서버에 crash 도구를 설치합니다.

yum install crash

3. debuginfo 패키지를 설치하면 홈페이지에서 kernel 버전에 대응하는 debuginfo 패키지를 다운로드할 수 있습니다.

https://buildlogs.centos.org/c7.1511.u/kernel/20161024152721/3.10.0-327.36.3.el7.x86_64/

종속 패키지 및 debuginfo 패키지 설치:

rpm -ivh kernel-debuginfo-common-x86_64-3.10.0-327.36.3.el7.x86_64.rpm

rpm -ivh kernel-debuginfo-3.10.0-327.36.3.el7.x86_64.rpm

4. crash 도구를 사용하여/var/crash의 덤프 파일 vmcore를 분석합니다. 명령은 다음과 같습니다.

crash /usr/lib/debug/lib/modules/3.10.0-327.36.3.el7.x86_64/vmlinux vmcore

5. kernel crash 시 Call Trace를 볼 수 있으며 주요 정보는 노란색 배경 글꼴입니다.

crash> bt

PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: "crond"

#0 [ffff8804b42db778] machine_kexec at ffffffff81051e9b

#1 [ffff8804b42db7d8] crash_kexec at ffffffff810f27e2

#2 [ffff8804b42db8a8] oops_end at ffffffff8163f448

#3 [ffff8804b42db8d0] no_context at ffffffff8162f561

#4 [ffff8804b42db920] __bad_area_nosemaphore at ffffffff8162f5f7

#5 [ffff8804b42db968] bad_area at ffffffff8162f91b

#6 [ffff8804b42db990] __do_page_fault at ffffffff81642235

#7 [ffff8804b42db9f0] trace_do_page_fault at ffffffff81642403

#8 [ffff8804b42dba28] do_async_page_fault at ffffffff81641ae9

#9 [ffff8804b42dba40] async_page_fault at ffffffff8163e678

[exception RIP: netlink_compare+11]

RIP: ffffffff815560bb RSP: ffff8804b42dbaf8 RFLAGS: 00010246

RAX: 0000000000000000 RBX: 000000049f250000 RCX: 00000000c3637c42

RDX: 00000000000026fb RSI: ffff8804b42dbb48 RDI: 000000049f24fb78

RBP: ffff8804b42dbb30 R8: ffff8804b42dbb44 R9: 0000000000002170

R10: 0000000000000000 R11: ffff8804b42db966 R12: ffff88061dcd2678

R13: ffff8804b42dbb48 R14: ffffffff815560b0 R15: ffff88061b639000

ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

#10 [ffff8804b42dbb00] rhashtable_lookup_compare at ffffffff813080d0

#11 [ffff8804b42dbb38] netlink_lookup at ffffffff815569ee

#12 [ffff8804b42dbb68] netlink_getsockbyportid at ffffffff81557d8f

#13 [ffff8804b42dbb80] netlink_alloc_skb at ffffffff81557dff

#14 [ffff8804b42dbbb8] netlink_ack at ffffffff8155a8a9

#15 [ffff8804b42dbbf0] audit_receive at ffffffff811067e7

#16 [ffff8804b42dbc18] netlink_unicast at ffffffff8155a02d

#17 [ffff8804b42dbc60] netlink_sendmsg at ffffffff8155a420

#18 [ffff8804b42dbcf8] sock_sendmsg at ffffffff815112d0

#19 [ffff8804b42dbe58] SYSC_sendto at ffffffff81511841

#20 [ffff8804b42dbf70] sys_sendto at ffffffff815122ce

#21 [ffff8804b42dbf80] system_call_fastpath at ffffffff81646b49

RIP: 00007f4ac19d5353 RSP: 00007ffe233b1fb8 RFLAGS: 00010202

RAX: 000000000000002c RBX: ffffffff81646b49 RCX: 0000000000000000

RDX: 000000000000009c RSI: 00007ffe233b1ff0 RDI: 0000000000000003

RBP: 00007ffe233b1ff0 R8: 00007ffe233b1fe0 R9: 000000000000000c

R10: 0000000000000000 R11: 0000000000000246 R12: ffffffff815122ce

R13: ffff8804b42dbf78 R14: 000000000000044d R15: 0000000000000001

ORIG_RAX: 000000000000002c CS: 0033 SS: 002b

6, 검색 rhashtable_lookup_compare 키워드,kernel Linux 3.10.0-327.36.3입니다.el7.x86_64의 버그 중 하나입니다. 자세한 설명은 아래를 참조하십시오. 이 버그는 7.3kernel(3.10.0-514.el7)에서 복구됩니다.

https://bugs.centos.org/view.php?id=12012

[버그 트리거 조건 포지셔닝]

1. 시스템 업그레이드 비용이 비교적 높다는 것을 감안하여 버그를 트리거하는 조건을 포지셔닝해 보면 이 버그를 트리거하는 것은crond 명령임을 알 수 있다.

PID: 9979 TASK: ffff8804b4020b80 CPU: 2 COMMAND: "crond"

2. 시스템tap 도구를 빌려crash가 발생하는kernel 함수에 탐지기를 추가하고kernel backtrace,process id,processname 등 정보를 출력합니다. 스크립트는 다음과 같습니다.

probe kernel.function("rhashtable_lookup_compare") {

print_backtrace();

printf ("%d
%s
", pid(),execname());

} 

3,crond 등 시스템 명령을 잡으면 rhashtable_lookup_compare 함수, 다른 명령의 호출 스택은 완전히 같지 않습니다.

25756

crond

0xffffffff81308080 : rhashtable_lookup_compare+0x0/0x90 [kernel]

0xffffffff815569ee : netlink_lookup+0x4e/0x80 [kernel]

0xffffffff81557d8f : netlink_getsockbyportid+0x1f/0x70 [kernel]

0xffffffff81559fe9 : netlink_unicast+0xa9/0x1b0 [kernel]

0xffffffff8155a8f9 : netlink_ack+0x99/0x110 [kernel]

0xffffffff811067e7 : audit_receive+0x67/0xa0 [kernel]

0xffffffff8155a02d : netlink_unicast+0xed/0x1b0 [kernel]

0xffffffff8155a420 : netlink_sendmsg+0x330/0x770 [kernel]

0xffffffff815112d0 : sock_sendmsg+0xb0/0xf0 [kernel]

0xffffffff81511841 : SYSC_sendto+0x121/0x1c0 [kernel]

0xffffffff815122ce : SyS_sendto+0xe/0x10 [kernel]

0xffffffff81646b49 : system_call_fastpath+0x16/0x1b [kernel]

4. MongoDB가 최근에 새로 설치한 모니터링 스크립트는crontab를 통해 스케줄링된 것을 감안하면 모니터링을 하기 전에 서버가 다시 시작하는 경우는 드물다.crontab 스케줄링 시스템 모니터링 프로그램이kernelbug를 촉발한 것으로 추정되며, 뒤에서 모니터링 스크립트를 서비스로 바꾸어 버그를 회피할 수 있는지 관찰합니다.

[사고방식 해결]

우리는kernelcrash시 덤프 파일을 분석하여 CentOS 7.1 시스템에 자동으로 재부팅되는 버그가 있음을 포지셔닝하고 새로운 linux 서버는 모두 CentOS 7.4 시스템을 사용하도록 권장합니다.시스템 업그레이드 비용이 비교적 높은 것을 고려하여crontab 스케줄링 프로그램을 서비스 방식으로 바꾸어 버그 발생을 피하려고 합니다.