ECC 오류 감시: 커널 이벤트부터 알림까지 검증

데이터베이스 프로세스가 예기치 않게 종료되고 같은 시점에 커널 로그에서 메모리 오류가 확인된다면, 애플리케이션을 재시작하는 것만으로는 프로세스를 복구할 수 있을 뿐 장애 원인을 설명할 수 없습니다. ECC는 일부 메모리 오류를 정정하지만, 이벤트 보존이나 추세 분석, 지원 티켓에 필요한 증거 수집까지 자동으로 수행하지는 않습니다. 물리 서버를 운영에 투입하기 전에는 하드웨어 보고, 커널 수신, 이벤트 저장, 모니터링 인식, 알림 전달로 이어지는 전체 경로를 검증해야 합니다.

CloudSFP의 AMD EPYC 7543P 물리 서버는 DDR4-3200 ECC를 사용하며, 메모리는 128GB와 256GB 두 가지로 제공됩니다. 아래에서는 Debian 12를 기준으로 점검 절차를 구성합니다. 명령은 게스트 운영체제가 아닌 호스트 운영체제에서 실행합니다. 커널과 펌웨어에 따라 제공되는 정보가 다를 수 있으므로, 데이터 소스가 없는 경우는 별도로 기록해야 하며 오류가 0건인 것으로 처리해서는 안 됩니다.

1. 오류와 모니터링 공백부터 구분하기

정정 가능한 오류는 보통 CE로 표시되며, 해당 오류가 정정되었음을 의미합니다. 정정 불가능한 오류는 보통 UE로 표시되며, 해당 오류를 그 오류 정정 메커니즘으로 복구할 수 없음을 의미합니다. 실제 영향은 오류 위치, 커널의 처리 방식, 영향을 받은 프로세스에 따라서도 달라집니다. 약어만 보고 업무 데이터가 반드시 온전하다고 판단해서는 안 됩니다.

CE를 판단할 때는 증가량, 동일 위치에서의 반복 발생 여부, 발생 당시의 부하를 중점적으로 살펴야 합니다. 한 번 발생한 단발성 이벤트와 같은 위치에서 계속 발생하는 이벤트는 대응 우선순위를 다르게 정해야 합니다. UE가 발생했다면 데이터 보호를 우선하고, 프로세스 종료 여부와 시스템 이상, 기존 백업을 확인하면서 관련 부하를 더 늘리지 않아야 합니다.

“기록이 없다”는 사실은 수집 경로가 정상적으로 작동한다고 확인된 경우에만 판단 근거가 됩니다. EDAC 디렉터리가 비어 있거나 수집 서비스가 중지되어 있거나 이벤트 데이터베이스를 읽을 수 없는 상태는 모두 모니터링 공백이지, 정상 상태의 증거가 아닙니다.

ECC는 데이터 검증, 스토리지 이중화, 백업을 대신하지도 않습니다. 애플리케이션의 잘못된 결과나 파일 손상을 메모리 오류와 연결하려면 시간대와 업무상의 증거를 대조해야 합니다. 곧바로 인과관계를 단정해서는 안 됩니다.

2. 커널이 실제로 제공하는 데이터 소스 확인하기

먼저 부팅 식별자와 커널 버전을 기록한 다음, 메모리 컨트롤러 디렉터리와 커널 이벤트를 확인합니다. 다음 명령은 현재 상태를 조회하기만 하며, 드라이버를 로드하거나 하드웨어 설정을 변경하지 않습니다.

uname -r
cat /proc/sys/kernel/random/boot_id
ls -ld /sys/devices/system/edac/mc
find /sys/devices/system/edac/mc -maxdepth 2 -type f \
  \( -name ce_count -o -name ue_count -o -name mc_name \) \
  -print -exec cat {} \;
sudo journalctl -k -b --no-pager \
  --grep='EDAC|MCE|Hardware Error|memory error'

디렉터리의 mc_name은 컨트롤러 이름을 확인하는 데 사용하며, ce_count와 ue_count는 해당 컨트롤러의 누적 카운터입니다. 처음 조회한 값이 0이 아니라면 먼저 기준값으로 저장해야 합니다. 과거의 누적 건수 전체를 방금 발생한 오류로 간주해 알림을 보내서는 안 됩니다.

디렉터리가 없거나 컨트롤러 항목이 없다면 명령 출력을 보존하고, 커널 로그에서 드라이버 초기화 정보를 확인해야 합니다. 드라이버 지원 여부, 펌웨어 설정, 플랫폼의 보고 경로가 모두 데이터의 노출 여부에 영향을 줄 수 있습니다. 운영 서버에서 잘 모르는 모듈을 반복해서 로드하며 확인하는 방식은 권장하지 않습니다.

커널 로그에 MCE나 Hardware Error가 나타났다고 해서 반드시 메모리 장애인 것도 아닙니다. 다른 하드웨어 구성 요소에서 발생한 이벤트일 수 있습니다. 전체 맥락을 보존해야 하며, “error”가 포함된 한 줄만 추출해 오류 유형을 분류해서는 안 됩니다.

3. rasdaemon 기록과 카운터 기준값 설정하기

Debian 12에서는 배포판 패키지로 rasdaemon을 설치할 수 있습니다. 변경 전에 기존 서비스 설정을 보존하고, 설치 후에는 서비스 상태, 시작 인수, 실제 실행 중인 프로세스를 함께 확인합니다.

sudo apt-get update
sudo apt-get install rasdaemon
sudo systemctl enable --now rasdaemon
systemctl status rasdaemon --no-pager
systemctl cat rasdaemon
ps -C rasdaemon -o pid,args
sudo ras-mc-ctl --status
sudo ras-mc-ctl --summary
sudo ras-mc-ctl --errors

--status는 점검 항목 중 하나일 뿐, 시스템이 정상이라는 종합적인 결론을 제공하지 않습니다. 서비스 로그에서도 이벤트 구독 실패, 권한 오류, 데이터베이스 쓰기 문제가 있는지 확인해야 합니다.

sudo journalctl -u rasdaemon -b --no-pager

기록 프로세스가 실행된다고 디스크에 저장되는 것은 아니다

시작 인수에서 -r 또는 --record가 활성화되어 있는지 확인하고, 현재 패키지가 데이터베이스 기능을 지원하는지도 확인합니다. 서비스가 실행 중이어도 기록을 영구 저장하지 않는다면 수집 프로세스를 재시작할 때 증거가 끊길 수 있습니다. 데이터베이스 위치는 실제 패키지 설정을 기준으로 확인해야 하며, 다른 배포판의 경로를 그대로 적용해서는 안 됩니다.

매번 값을 수집할 때는 최소한 서버 식별 번호, 부팅 식별자, 수집 시각, 컨트롤러 이름, CE 및 UE 카운터를 저장합니다. 카운터 증가량은 동일한 부팅 식별자와 동일한 데이터 소스 안에서 비교해야 합니다. 시스템 재부팅, 모듈 재로드 또는 카운터 감소가 발생하면 기준값을 다시 설정해야 합니다. 음수 증가량을 계산한 뒤 무시하는 방식으로 처리해서는 안 됩니다.

rasdaemon과 EDAC가 다루는 데이터 범위는 완전히 같지 않을 수 있습니다. 비교하기 전에 이벤트 유형, 수집 시작 시점, 컨트롤러를 먼저 대조해야 하며, 두 기록의 총건수가 무조건 일치해야 하는 것은 아닙니다.

4. 메시지를 쌓기보다 위험을 전달하는 알림 구성하기

모니터링은 수집 경로 장애, CE 신규 발생, UE 신규 발생의 세 범주로 나누는 것이 좋습니다. 수집 경로 장애에는 서비스 중지, 값 읽기 실패, 데이터베이스 조회 오류가 포함됩니다. 이러한 문제는 별도로 알림을 보내야 하며, 이상 상태를 숫자 0으로 덮어서는 안 됩니다.

CE 신규 발생 알림에는 이번 증가량, 컨트롤러, 원본 이벤트를 포함해야 합니다. 기록에 위치 필드가 제공된다면 위치별로 반복 이벤트를 집계할 수 있습니다. 다만 모든 서버에 공통으로 적용할 수 있는 “안전한 발생 횟수”를 정해서는 안 됩니다. 이벤트 발생률, 특정 위치에 집중되는 정도, 업무상 증상을 함께 고려해 대응 수준을 높일지 결정해야 합니다.

UE가 새로 발생하면 대응 우선순위를 높이고, 장애 당시의 상태를 보존한 뒤 업무 데이터의 무결성을 확인해야 합니다. 부하 테스트로 장애를 추가 검증하거나, 카운터를 초기화하려고 먼저 서버를 재부팅해서는 안 됩니다.

알림 경로 검증에는 오프라인 샘플을 사용할 수 있습니다. 변경 전후의 카운터 입력 두 개를 만들어 증가량 0, CE 증가, UE 증가, 값 읽기 실패, 부팅 식별자 변경을 각각 검증합니다. 테스트 메시지는 모의 훈련임을 명확히 표시하고, 모니터링 파서에만 입력해야 합니다. 실제 하드웨어 이벤트 데이터베이스에 기록해서는 안 됩니다.

운영 서버에서는 오류 주입으로 알림 전달을 검증하지 않습니다. 알림 테스트에 성공했다는 것은 파싱과 전달이 정상적으로 작동한다는 의미일 뿐입니다. 커널이 하드웨어 이벤트를 실제로 수신할 수 있는지는 드라이버 상태, 이벤트 소스, 실제 기록을 근거로 별도로 확인해야 합니다.

5. 하드웨어 원인 조사에 필요한 증거 보존하기

오류가 반복해서 발생하면 먼저 현재 부팅 이후의 커널 로그, rasdaemon 서비스 로그, 이벤트 조회 결과를 내보낸 다음 카운터 스냅샷을 저장합니다. 증거 수집 디렉터리는 접근 권한을 제한하고, 지원 티켓에 파일을 첨부하기 전에 주소, 계정 또는 업무상 민감한 정보가 포함되어 있는지 확인합니다.

지원 티켓은 다음 순서로 작성합니다.

• 서버 식별 번호, 운영체제 및 커널 버전, 부팅 식별자.
• 최초 발견 시각과 명확한 시간대, 오류가 계속 추가로 발생하는지 여부.
• CE와 UE의 원본 이벤트 및 전후 카운터. 알림 화면 캡처만 첨부하지 않습니다.
• 보고 내용의 컨트롤러 및 위치 필드. 누락된 필드는 누락 사실을 그대로 명시합니다.
• 같은 시점의 업무상 증상, 이미 수행한 조치와 그 결과.

이벤트에 표시된 DIMM 레이블이나 주소를 임의로 물리 슬롯 번호로 환산해서는 안 됩니다. 플랫폼마다 매핑이 다를 수 있습니다. 하드웨어 위치 식별은 지원 담당자가 서버 정보와 함께 확인하도록 맡기고, 서버 이용자는 운영체제, 업무 데이터, 백업을 보호해야 합니다.

점검의 최종 산출물은 모든 항목이 녹색으로 표시된 화면 캡처가 아닙니다. 다시 검증할 수 있는 기준값, 명확히 파악된 데이터 소스의 수집 범위, 모의 훈련을 거친 알림 경로, 완전한 장애 증거가 남아야 합니다. 커널을 업데이트하거나 서버를 재부팅한 뒤에는 이 조건들을 다시 확인해야 합니다. 수집이 중단된 것을 오류가 사라진 것으로 오인하지 않기 위해서입니다.

자주 묻는 질문