일본 IDC 내 물리 서버 운영 중 발생하는 Linux Soft Lockup 및 Hard Lockup 현상의 발생 원인을 분석하고, 커널 왓치독 설정 및 IPMI/OOB를 통한 진단과 복구 절차를 실무 관점에서 다룹니다.
해외 IDC 환경에서 물리 서버를 운영하다 보면 특정 시점에 서버가 반응을 멈추거나 원격 SSH 접속이 중단되는 현상을 겪을 수 있습니다. 네트워크 장비나 인프라 상의 문제가 아님에도 서버 응답이 불가능한 경우, 대다수는 Linux 커널 수준에서 발생한 CPU Lockup 상태에 해당합니다. 커널이 특정 작업에 갇혀 스케줄링을 진행하지 못하거나 인터럽트를 처리하지 못하면 웹 서비스 및 DB 응답이 즉시 중단되므로 빠른 원인 분석과 대처가 요구됩니다.
특히 일본 IDC 환경처럼 원격으로 물리 장비를 관리해야 하는 조건에서는 현장 콘솔 접근 방식과 시스템 로그 채집 방법을 사전에 준비해 두는 것이 중요합니다. 본 문서에서는 Linux 시스템에서 발생하는 Soft Lockup과 Hard Lockup의 차이점을 파악하고, 커널 메커니즘을 통한 진단 및 조치 방안을 실무 관점에서 정리합니다.
Linux Soft Lockup과 Hard Lockup의 개념 및 원인 비교
Linux 커널은 각 CPU 코어가 정상적으로 작업을 분배받아 실행 중인지 모니터링하기 위해 타이머 및 인터럽트 기반 메커니즘을 사용합니다. 특정 코어가 정상적인 흐름을 벗어나 오랫동안 응답하지 않을 때 커널은 이를 Lockup 상태로 판단하고 로그를 기록합니다.
Soft Lockup의 정의와 원인
Soft Lockup은 특정 CPU 코어가 커널 공간에서 동작하는 동안 다른 스레드에 제어권을 넘겨주지 않고 독점하는 상태를 의미합니다. 이 상태에서는 인터럽트(Interrupt) 자체는 계속 수신될 수 있으나, 커널 스케줄러가 해당 코어에서 새로운 작업 스케줄링을 수행하지 못합니다.
- 스핀락(Spinlock) 교착 상태: 커널 모듈이나 커널 드라이버에서 임계 구역을 보호하기 위해 설정한 스핀락이 해제되지 않을 때 발생합니다.
- 무한 루프 또는 과도한 커널 루프: 특정 커널 코드 내에서 조건이 충족되지 않아 시스템 호출 처리가 끝없이 연장될 때 나타납니다.
- 특정 커널 모듈 버그: 타사 드라이버나 특정 가상화 모듈, 방화벽 모듈의 버그로 인해 발생할 수 있습니다.
Hard Lockup의 정의와 원인
Hard Lockup은 Soft Lockup보다 심각한 상태로, 특정 CPU 코어가 CPU 인터럽트조차 처리하지 못할 정도로 완전히 정지된 상황을 뜻합니다. 커널의 타이머 인터럽트(hrtimer)조차 실행되지 않으므로 시스템은 인터럽트 기반의 기본적인 작동을 멈추게 됩니다.
- NMI 인터럽트 차단: CPU가 비마스크 불가능 인터럽트(NMI)를 제외한 모든 인터럽트를 비활성화한 상태로 응답 불능에 빠질 때 발생합니다.
- 하드웨어 고장 또는 버스 락(Bus Lock): CPU, 메모리 버스, PCIe 슬롯 또는 마더보드 전원부 이상 등 물리적 자원의 고장이 원인이 될 수 있습니다.
- 심각한 커널 버그: 커널의 하위 레벨 인터럽트 핸들러 내에서 정지 현상이 일어나는 경우입니다.
Kernel Watchdog 감지 메커니즘과 설정
Linux 커널에는 Lockup 현상을 자동으로 감지하여 로그를 남기거나 시스템을 패닉(Panic) 상태로 전환해 재부팅을 유도하는 Watchdog 기능이 포함되어 있습니다.
Watchdog 작동 원리
Soft Lockup 감지는 커널 스레드인 watchdog/N 스레드가 정해진 주기마다 갱신하는 핑(Ping) 메커니즘을 바탕으로 작동합니다. 지정된 시간(기본값 20초) 동안 이 스레드가 스케줄링되지 않으면 시스템 로그에 BUG: soft lockup - CPU#X stuck for YYs! 메시지가 출력됩니다.
Hard Lockup 감지는 NMI(Non-Maskable Interrupt) Watchdog을 활용합니다. 타이머 인터럽트 발생 횟수를 주기적으로 점검하여, 비마스크 인터럽트 처리 중에도 수치가 증가하지 않으면 Watchdog detected HARD LOCKUP on cpu X 메시지를 남깁니다.
주요 sysctl 파라미터 설정
시스템 운영 정책에 따라 Lockup 발생 시 자동 재부팅을 수행할지, 아니면 로그만 기록하고 대기할지 설정할 수 있습니다. 시스템 상태를 안전하게 보존하고 즉시 재가동해야 하는 환경에서는 아래 파라미터를 조절합니다.
kernel.watchdog_thresh: Lockup으로 판단하는 기준 시간(초)을 설정합니다.kernel.softlockup_panic: Soft Lockup 감지 시 커널 패닉을 유발할지 여부(0 또는 1)를 결정합니다.kernel.hardlockup_panic: Hard Lockup 감지 시 커널 패닉을 유발할지 여부(0 또는 1)를 결정합니다.kernel.nmi_watchdog: NMI Watchdog 활성화 여부(0 또는 1)를 지정합니다.
시스템 응답 불가 시 원격 진단 및 조치 절차
물리 서버가 Lockup 상태에 빠지면 네트워크 패킷 응답이 끊기거나 SSH 접속이 불가능해집니다. 이때 현장 조치 전 원격 제어 인터페이스를 통해 시스템 상태를 파악해야 합니다.
IPMI/Out-of-Band(OOB) 콘솔을 활용한 점검
해외 리전에 위치한 물리 서버 운영 시 IPMI(Intelligent Platform Management Interface)나 iLO/iDRAC 같은 원격 관리 채널은 정지된 서버 상태를 확인할 수 있는 수단입니다. HARU IDC의 원격 콘솔 인프라를 활용하면 물리적 위치에 관계없이 직렬 콘솔(Serial-over-LAN)이나 KVM 화면에 접근하여 덤프 메시지를 확인할 수 있습니다.
SysRq 키를 통한 메모리 덤프 및 안전한 재부팅
네트워크가 차단되었으나 커널이 NMI 인터럽트에 일부 응답할 수 있는 상태라면, IPMI 가상 키보드나 콘솔을 통해 Magic SysRq 명령을 전송하여 현상을 진단합니다.
- SysRq + t: 현재 모든 CPU의 스택 트레이스(Stack Trace)를 콘솔 출력으로 내보냅니다.
- SysRq + m: 메모리 할당 정보 및 잔여 메모리 현황을 콘솔에 기록합니다.
- SysRq + c: 의도적으로 커널 패닉을 발생시켜 Kdump 분석용 덤프 파일을 생성합니다.
- SysRq + b: 파일 시스템 동기화 없이 즉시 시스템을 재부팅합니다.
Soft/Hard Lockup 발생 시 로그 분석 및 진단 방법
서버가 재부팅된 후에는 시스템 로그 및 콜 스택(Call Stack) 정보를 분석하여 어떤 프로세스나 드라이버가 원인이었는지 추적해야 합니다.
콜 스택(Call Stack) Trace 분석
Lockup 로그에는 RIP: 라인과 함께 해당 순간 CPU가 실행 중이던 커널 함수 정보가 기록됩니다. 연동된 모듈 이름(예: [iptable_filter], [kvm], [megaraid_sas] 등)을 확인하여 소프트웨어 이슈인지 장치 드라이버 문제인지 파악합니다.
하드웨어 이벤트 로그(SEL) 확인
Hard Lockup인 경우 커널 소프트웨어 문제가 아닌 물리적 하드웨어 불량일 가능성을 배제할 수 없습니다. IPMI 콘솔의 System Event Log(SEL)나 ipmitool sel list 명령을 사용하여 ECC 메모리 오류, CPU 과열, PCI Express 버스 에러(AER) 등이 동반되었는지 점검합니다.
Lockup 예방 및 안정화 체크리스트
Lockup 현상은 예가 불명확한 경우가 많으므로 운영 환경 전반에 걸친 정기 점검과 시스템 최적화가 필요합니다.
| 점검 영역 | 상세 점검 항목 | 권장 조치 사항 |
|---|---|---|
| 커널 및 드라이버 | OS 커널 버전 및 NIC/RAID 드라이버 최적화 상태 | 최신 안정판 커널 업데이트 및 제조사 정품 드라이버 적용 검토 |
| Watchdog 설정 | Watchdog Threshold 및 Panic 옵션 지정 | 서비스 SLA에 맞춰 kernel.watchdog_thresh 및 panic 옵션 설정 |
| 로그 보존 | kdump 및 Persistent Journald 활성화 | 재부팅 후에도 vmcore 및 커널 로그가 보존되도록 스토리지 확보 |
| 하드웨어 모니터링 | IPMI SEL 로그 및 하드웨어 온도/전원 상태 | HARU IDC 기술지원팀과 협력하여 주기적 하드웨어 진단 및 부품 교체 진행 |
| 마이크로코드 | CPU Microcode 최적화 여부 확인 | CPU 벤더(Intel/AMD)의 최신 microcode 팩 적용 확인 |
안정적인 IDC 운영을 위한 기술적 제언
Linux 커널의 Soft Lockup 및 Hard Lockup 현상은 복합적인 원인으로 발생하며, 해외 IDC에 배치된 물리 서버의 경우 장애 발생 시 신속하게 콘솔을 확보하고 진단 로그를 남기는 체계가 필수적입니다. 무작정 서버 전원을 리셋하기보다는 OOB 콘솔을 통한 스택 트레이스 수집 및 Kdump 설정을 선행함으로써 동일 장애의 재발을 방지할 수 있습니다.
시스템 특성에 맞춰 커널 파라미터를 적절히 조정하고, 하드웨어 센서 및 IPMI 로그 모니터링을 지속해서 수행하는 것이 장기적인 인프라 안정성을 확보하는 방법입니다.
기업용 VPN 구성이 필요하신가요?
고정 IP, 관리자 접근 제한, 원격 업무 환경에 맞는 VPN 구성을 안내해드립니다.