TECH

 

안녕하세요 여러분~!!

오늘은  Kdump 에 대해 알아보겠습니다.

 

 

1. kdump 및 kexec 소개 

 

kdump 는 크래시 덤프 메커니즘을 제공하는 서비스입니다. 이 서비스를 사용하면 분석을 위해 시스템 메모리의 내용을 저장할 수 있습니다. 

 

kdump 는 kexec 시스템 호출을 사용하여 재부팅하지 않고 두 번째 커널(커널 캡처)으로 부팅한 다음 충돌된 커널 메모리 ( crash dump 또는 vmcore)의 콘텐츠를 캡처하여 파일에 저장합니다. 두 번째 커널은 시스템 메모리의 예약된 부분에 있습니다.

  

----중요----

커널 크래시 덤프는 실패 시 사용할 수 있는 유일한 정보일 수 있으며, 비즈니스에 중요한 환경에서 이 데이터를 갖는 것의 중요성은 과소평가할 수 없습니다. Red Hat은 시스템 관리자가 일반 커널 업데이트 주기에서 kexec-tools 를 정기적으로 업데이트하고 테스트하는 것이 좋습니다. 이는 새로운 커널 기능을 구현할 때 특히 중요합니다 

------------ 

 

 

2.  메모리 요구 사항 

     kdump가 커널 크래시 덤프를 캡처하여 추가 분석을 위해 저장할 수 있으려면 캡처 커널에 대해 시스템 메모리의 일부를 영구적으로 예약해야 합니다. 예약된 경우 시스템 메모리의 이 부분은 기본 커널에서 사용할 수 없습니다.

 

 

 

1) kdump 설치 

        -    기본적으로 OS 설치 시 Kdump를 활성화 하게 되면 자동으로 설치가 됩니다. 하지만

  

   >  설치가 안 된  서버라면 아래와 같이 진행합니다.

 # yum install kexec-tools

  # yum install system-config-kdump

 

 

 2) kdump 설정

       kdump 커널용으로 예약된 메모리를 지정하려면 crashkernel= 옵션을 필수 값으로 설정합니다. 예를 들어 128MB의 메모리를 예약하려면 다음을 사용합니다.

 

 Ex) grub2.cfg

 root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet crashkernel=512M

 

  

3) kdump 디렉토리 설정 

        - 로컬 파일 시스템의 /var/crash/ 디렉터리에 vmcore 파일을 저장하려면 /etc/kdump.conf 파일을 편집하고 경로를 지정합니다.

  

주의.  물리적 메모리가 20G라고 가정하면 vmcore를 받을  /var/crash 디렉토리는 20G 보다 커야합니다. 메모리가 20G로 꽉차있다면, 그것을 다 내려받아야하기 때문입니다. 하지만, 실제로는 그렇게 다 떨어지진 않습니다. 하지만 레드햇 권고입니다~

 

 Ex)

# etc/kdump.conf 

......

ext4 /dev/mapper/vg00-varcrashvol

path /var/crash 

core_collector makedumpfile -c --message-level 1 -d 31 

..... 

4)  서비스 활성화

 

-    쉘 프롬프트에 root 로 다음을 입력합니다.

# systemctl enable kdump.service 

 # systemctl start kdump.service

 

4.     

     4. kdump 설정 테스트

        - 쉘 프롬프트에 다음 명령을 입력합니다.

 

# echo 1 > /proc/sys/kernel/sysrq

# echo c > /proc/sysrq-trigger

  

이렇게 하면 Linux 커널이 충돌하게 되며 주소-YYYY-MM-DD-HH:MM:SS/vmcore 파일이 구성에서 선택한 위치에 복사됩니다(즉, 기본적으로 /var/crash/ 로 변경).

  

ls -al /var/crash/

 

-rw------- 1 root root 123456789012 May 22 04:12 vmcore

-rw-r--r-- 1 root root 77206 May 22 04:12 vmcore-dmesg.txt 

 

위 vmcore를 레드햇에 분석요청을 하면 원인을 파악해줍니다. 

 

 

  

제가 실제로 사용하는 설정에 대해 설명드립니다~

 

# cat etc/grub2.cfg

 

.... crashkernel=auto  ..... 

 

 

 # cat etc/sysctl.conf

 kernel.unknown_nmi_panic=1

 kernel.sysrq = 1

 kernel.panic_on_unrecovered_nmi = 1

 kernel.panic_on_io_nmi = 1

 

 설명:

 * kernel.unknown_nmi_panic

   - default: 0

   - 1인 경우 커널이 H/W로 부터 인식 할 수 없는 NMI 신호를 받을 경우 패닉 발생

   - 일반적으로 NMI 스위치를 수동으로 눌러 정의 되지 않은 NMI 생성

   - NMI watch dog thread는 정의 되지 않은 NMI를 사용하기 때문에 kernel.nmi_watchdog를 1로 설정하면 kernel.unknown_nmi_panic 값은 0이어야 함

 

* kernel.panic_on_unrecovered_nmi

   - default: 0

   - 1인 경우 복구 불가능한 parity 또는 ECC 메모리 오류를 나타내는 알 수 없는 NMI가 감지 된경우 패닉

 

* kernel.panic_on_io_nmi

  - 커널이 일반적으로 수정할 수 없는 I/O 오류로 인해 NMI(Non Maskable Interrupt)가 발생 할 경우 패닉 허용 여부 

 

 

# cat etc/kdump.conf

path /kdump          <-- 직관적으로 쉽게 알수있게 디렉토리를 따로 만들었습니다. 메모리의 1.5배 

                           하지만 제경험상으로 20G 이상 떨어진적이 없어 최대 50G 설정해놓습니다. 

core_collector makedumpfile -l --message-level 1 -d 31    <---  전 딱히 레벨을 변경하지 않았습니다. 레벨 

                                                                     변경 시 파일이 더 커 질수있습니다.

  

그리고 이건 경험인데요, 제가 기술지원을 다니면서 Kdump를 꼭 하는 사이트가 있고, 절대 안하는 사이트들이 있었습니다.

  

-  설정하는 사이트 : 정확한 원인이 꼭 필요하다고 생각하는 사이트들입니다. 그리고 서비스가 모두 이중화 되어있어서, 1대가 죽어도 크게 상관않하는 곳.

-  설정 안하는 사이트: 서비스가 먼저인곳, 사실 vmcore가 떨어지게되면 얼마나 걸릴지 아무도 모릅니다. 서버가 재부팅될때까지 무조건 기다려야합니다. 

                          그래서 서비스를 먼저 복구하려고 서버가 패닉걸리면 그냥 재부팅을 해버립니다.

 

저의 개인적 경험이니  참고만하세요~^^

 

 

 

감사합니다.

 

 

 

참고사이트 : https://access.redhat.com/documentation/ko-kr/red_hat_enterprise_linux/7/html-single/kernel_administration_guide/index#chap-introduction-to-kdump