Red Hat Enterprise Linux에서 커널 덤프 구성의 중요성

시스템 관리자로 일한 적이 있는 분이라면 프로덕션 중단을 초래한 시스템 충돌에 따라 스트레스 수준이 높은 상황에 처해본 경험이 있을 것입니다. 이러한 상황에서 주요 목표는 가능한 한 빨리 프로덕션 시스템을 다시 가동시키는 것입니다. 그러나 모든 것이 백업되어 다시 정상 가동되는 즉시 목표는 근본 원인 분석(RCA)으로 전환되어야 합니다. 문제가 발생한 이유를 이해하여 문제 재발을 방지해야 합니다.

Linux 커널은 Red Hat Enterprise Linux(RHEL)의 핵심이며 시스템에서 RHEL이 작동할 수 있도록 하는 모든 낮은 수준의 세부 정보를 처리합니다. 커널에서 복구할 수 없는 오류를 감지하면 커널 패닉이 발생하여 시스템 충돌을 초래합니다. 이러한 유형의 커널 충돌은 하드웨어 문제, 타사 커널 모듈의 문제, 커널의 버그 등 다양한 요인으로 인해 발생할 수 있습니다.

RHEL에는 kdump 서비스가 포함되어 있습니다. 커널 충돌 시 kdump는 시스템 메모리의 덤프를 파일에 쓰기 위해 보조 커널로 부팅할 수 있습니다. 이 커널 덤프 파일을 분석하여 커널 충돌의 근본 원인을 파악하는 데 사용할 수 있습니다. 커널 덤프 파일이 없으면 근본 원인을 파악하기가 불가능한 경우가 많습니다.

프로덕션 환경에서는 커널 충돌이 발생하기 훨씬 전에 kdump가 올바르게 구성되고 작동하는지 주기적으로 검증하는 것이 중요합니다.

kdump 활성화 옵션

kdump를 활성화하는 방법에는 다음과 같은 다양한 방법이 있습니다.

• RHEL 설치 프로그램(시스템을 처음 빌드하는 경우)
• 커맨드라인을 사용하여 수동으로 
• Red Hat Customer Portal 랩의 kdump 도우미
• RHEL 웹 콘솔
• RHEL kdump 시스템 롤

이 문서에서는 RHEL kdump 시스템 롤을 사용하여 커널 덤프용 RHEL 시스템을 구성하고, 그런 다음 RHEL 웹 콘솔을 사용하여 kdump가 제대로 작동하는지 확인하는 방법을 보여줍니다.

RHEL kdump 시스템 롤 사용

RHEL 시스템 롤을 시작하는 방법에 대한 개요는 RHEL 시스템 롤 소개 블로그 포스트를 참조하세요.  

최근 SSH를 통한 커널 덤프 구성과 관련된 kdump 시스템 롤에 몇 가지 버그가 있었으나 해결되었습니다. 이 문서의 예시에는 RHEL 시스템 롤 버전 1.22 이상이 필요하며, 현재 Ansible 오토메이션 허브(Ansible Automation Platform 서브스크립션을 보유한 고객에게 제공), RHEL 8 및 RHEL 9 Beta AppStream 리포지토리에서 사용할 수 있습니다.

제 환경에는 세 개의 RHEL 9 시스템이 있습니다. 하나는 Ansible 제어 노드(rhel9-controlnode.example.com) 역할을 하고, 두 개는 제가 kdump를 구성할 관리 노드입니다(rhel9-server1.example.com 및 rhel9 -server2.example.com).  

충돌이 발생하는 경우 커널 덤프를 시스템에서 로컬로 작성하거나 SSH 또는 NFS를 통해 원격 호스트에 작성하도록 구성할 수 있습니다. 이 예시에서는 SSH를 통해 rhel9-controlnode.example.com 호스트에 커널 덤프를 작성하도록 두 개의 관리 노드를 구성하려고 합니다. 또한 kdump가 제대로 작동하는지 쉽게 확인할 수 있도록 각 관리 노드에서 RHEL 웹 콘솔을 구성하려고 합니다.

제어 노드 호스트에서 다음 내용으로 inventory.yml이라는 Ansible 인벤토리 파일을 생성하여 시작합니다

.

all:
  hosts:
    rhel9-server1.example.com:
    rhel9-server2.example.com:
  vars:
    kdump_target:
      type: ssh
      location: kdump@rhel9-controlnode.example.com
    kdump_path: "/home/kdump/crash"
    kdump_ssh_user: kdump
    kdump_ssh_server: rhel9-controlnode.example.com
    cockpit_manage_firewall: true

인벤토리 파일의 상단에는 두 개의 관리 노드가 나열됩니다. 그런 다음 kdump 및 cockpit RHEL 시스템 롤에 대한 Ansible 변수를 정의합니다.

• kdump_target 변수는 SSH를 통해 kdump를 rhel9-controlnode.example.com 호스트로 전송하도록 지정합니다.
• kdump_path 변수는 kdump를 /home/kdump/crash 디렉터리에 작성하도록 지정합니다.
• kdump_ssh_user 및 kdump_ssh_server 변수는 rhel9-controlnode.example.com 호스트에서 kdump 사용자 계정(kdump 시스템 롤을 실행하기 전에 rhel9-controlnode.example.com 호스트에서 생성한 계정)을 사용하여 kdumps를 전송하도록 지정합니다.
• cockpit_manage_firewall 변수는 cockpit 시스템 롤이 방화벽에서 cockpit 서비스를 활성화하도록 지정합니다.

그런 다음 system_roles.yml이라는 Ansible Playbook을 다음 내용으로 정의합니다.

- name: Run RHEL kdump system role
  hosts: all
  roles:
    - redhat.rhel_system_roles.kdump
- name: Run RHEL cockpit system role
  hosts: all
  roles:
    - redhat.rhel_system_roles.cockpit

이 플레이북은 RHEL kdump 및 cockpit 시스템 롤을 호출합니다.

ansible-playbook 명령으로 플레이북을 실행합니다.

$ ansible-playbook -i inventory.yml -b system_roles.yml

이 예시에서는 system_roles.yml 플레이북을 실행하고, 루트로 에스컬레이션하며(-b 플래그), inventory.yml 파일을 내 Ansible 인벤토리(-i 플래그)로 사용하도록 지정합니다.

제 환경에서는 Fail if reboot is required and kdump_reboot_ok is false 태스크에서 롤이 실패합니다.  

kdump를 구성하려면 시스템을 재부팅해야 할 수 있습니다. 인벤토리 파일에서 kdump_reboot_ok 변수를 true로 설정한 경우 호스트가 자동으로 재부팅됩니다. 이 예시에서는 호스트를 수동으로 재부팅한 다음 플레이북을 다시 실행합니다. 플레이북의 두 번째 실행이 성공적으로 완료됩니다.

kdump 구성 확인

두 개의 관리 노드 각각에서 kdump 시스템 롤은 새 SSH 키를 생성하여 /root/.ssh/kdump_id_rsa에 저장하고 kdump.conf 구성 파일을 구성했습니다.  

제어 노드 호스트 rhel9-controlnode.example.com에서 kdump 시스템 롤은 두 관리 노드 각각에서 해당 공개 키로 kdump 사용자 계정 authorized_keys 파일을 구성했습니다.  

모든 항목이 제대로 작동하는지 확인하는 가장 좋은 방법은 각 관리 노드에서 커널을 충돌시키고 커널 덤프가 올바르게 생성되었는지 확인하는 것입니다. 경고: 커널이 충돌하면 시스템에 다운타임이 발생합니다! 이 작업은 유지 관리 기간에만 수행해야 합니다.

커맨드라인에서 또는 웹 콘솔을 사용하여 커널 충돌을 강제로 발생시킬 수 있습니다.

웹 브라우저에서 포트 9090의 호스트 이름에 연결함으로써 RHEL 웹 콘솔을 사용해 각 관리 노드에 로그인합니다. 로그인한 후 왼쪽 메뉴에서 커널 덤프를 선택한 다음 테스트 구성 버튼을 클릭합니다. 이 경우 커널이 충돌한다는 경고 메시지가 표시됩니다.

이제 rhel9-controlnode.example.com 호스트에서 /home/kdump/crash 디렉터리를 확인합니다.

[rhel9-controlnode]$ ls -l /home/kdump/crash/
total 0
drwxr-xr-x. 2 kdump kdump 72 Sep  6 15:07 192.168.122.102-2023-09-06-15:07:39
drwxr-xr-x. 2 kdump kdump 72 Sep  6 15:07 192.168.122.103-2023-09-06-15:07:44

커널 덤프가 발생할 때 각 호스트에 대해 디렉터리가 생성되었으며, 디렉터리 이름은 충돌이 발생한 IP 주소 및 날짜/시간을 나타냅니다. 커널 덤프 파일도 생성되었습니다.

[rhel9-controlnode]$ ls -l /home/kdump/crash/192.168.122.103-2023-09-06-15\:07\:44/
total 99120
-rw-------. 1 kdump kdump     77622 Sep  6 15:07 kexec-dmesg.log
-rw-------. 1 kdump kdump     66633 Sep  6 15:07 vmcore-dmesg.txt
-rw-------. 1 kdump kdump 101350015 Sep  6 15:07 vmcore.flat

kdump 기능을 정기적으로 테스트하여 제대로 작동하는지 확인하는 것이 좋습니다. 이는 패치 적용, 스토리지 변경, 하드웨어 교체, 네트워크 계층 변경(kdump 대상이 SSH 또는 NFS로 설정된 경우) 등 시스템에 변경 사항이 있는 경우 특히 중요합니다.

결론

RHEL 시스템 중 하나에 커널 충돌이 발생하는 경우 원인을 파악해야 하나요? 그렇다면 RHEL 환경에서 커널 덤프를 올바르게 구성하고 테스트하는 것이 중요합니다. RHEL kdump 시스템 롤을 사용하면 자동화를 통해 RHEL 환경 전반에서 규모에 맞게 커널 덤프를 구성할 수 있습니다. RHEL 환경에서 kdump를 설정하는 데 어려움이 있는 경우 언제든지 지원 티켓을 열어 Global Support Services(GSS) 팀에 문의하시기 바랍니다.