ExaCC 분기 패치 중 diskmon 에러로 Patch fail 조치 방법 공유

Oracle Exadata Cloud@Customer(ExaCC) 환경을 운영하는 데이터베이스 엔지니어(DBA)나 인프라 관리자에게 ‘분기별 정기 인프라 패치(Quarterly Infrastructure Patching)’는 피할 수 없는 정기 행사와 같습니다. 오라클의 클라우드 자동화 기술이 워낙 좋아져서 요즘은 버튼 몇 번이면 패치가 끝난다고 하지만, 고성능 하드웨어와 복잡한 그리드 인프라(Grid Infrastructure)가 얽혀 있는 Exadata 특성상 꼭 한 번씩 예기치 못한 에러로 사람 간을 떨어뜨리곤 합니다.

작업 시간은 한정되어 있는데 패치 Fail이 뜨면 그야말로 식은땀이 흐르죠. 얼마 전 진행했던 2분기 패치 중 실제로 겪었던 아찔한 장애 상황과, 이를 해결하기 위해 새벽을 하얗게 불태우며 조치했던 내용을 생생하게 공유해 보려고 합니다.

당시 인프라 패치를 진행하던 중 특정 VM 노드에서 아래와 같은 치명적인 얼럿 로그(Alert Log) 메시지와 함께 패치 프로세스가 완전히 멈춰 서는(Hang) 장애 상황을 마주했습니다.

Plaintext

2026-05-16T15:47:33.091049+0000 Heartbeat with diskmon (pid 000000) stopped on oy-eac-prd-exa2
2026-05-16T15:47:33.091061+0000 Heartbeat with diskmon (pid 000000) stopped on oy-eac-dev-exa1

인프라 패치는 오라클이 관리하는 스토리지 셀(Storage Cell)과 물리 서버(Dom0) 영역을 순차적으로 업데이트하는 롤링(Rolling) 방식으로 진행됩니다. 하지만 이 과정에서 상위 게스트 VM(DomU)의 핵심 클러스터 프로세스인 diskmon과의 통신이 끊어지면 전체 패치 워크플로우가 락(Lock) 상태에 빠지게 됩니다.

콘솔은 먹통이 되었고 시간은 흐르는 상황. 왜 이런 diskmon heartbeat stopped 에러가 발생하는지 구조를 파헤치고, 일반적인 명령어로 내려가지 않는 CRS를 강제 종료한 뒤 프로세스 간 통신(IPC) 찌꺼기 파일을 클리닝하여 패치를 성공적으로 재개한 실무 트러블슈팅 과정을 상세히 정리해 드립니다.

Exadata 아키텍처 관점에서 본 diskmon 프로세스의 본질

문제를 해결하려면 먼저 우리가 마주한 에러의 주인공인 diskmon이 Exadata 내에서 어떤 역할을 수행하는지 정확히 알아야 합니다.

diskmon(Disk Monitor)이란 무엇인가?

diskmon은 Oracle Grid Infrastructure 및 RAC 환경, 특히 Exadata 아키텍처에서 가장 낮은 레이어에서 작동하는 핵심 백그라운드 데몬 프로세스입니다. 일반적인 엔터프라이즈 서버 환경과 달리, Exadata는 고속의 RoCE(RDMA over Converged Ethernet) 네트워크를 통해 DB 서버(Compute Node)와 스토리지 서버(Storage Cell)가 유기적으로 연결되어 있습니다.

여기서 diskmon의 주 목적은 “데이터베이스 서버와 스토리지 서버 간의 I/O 경로 및 생존 상태를 실시간으로 감시하는 것”입니다.

하트비트(Heartbeat) 메커니즘과 스토리지 펜싱(Fencing)

diskmon은 마스터 클러스터 동기화 서비스인 ocssd와 밀접하게 연동되어 작동합니다. 스토리지 셀과 지속적으로 하트비트(핑 신호)를 주고받으며 통신 상태를 체크하다가, 특정 스토리지 셀이나 네트워크 라인에 이상이 감지되면 즉시 해당 경로를 차단하고 클러스터에서 제외하는 ‘스토리지 펜싱(Storage Fencing)’을 수행합니다. 데이터의 일관성을 보장하고, 스토리지 장애가 DB 전체의 커럽션(Corruption)으로 이어지는 것을 방지하는 최종 수문장인 셈입니다.

💡 한 줄 요약

Heartbeat with diskmon stopped라는 것은 데이터베이스 인스턴스나 클러스터 핵심 데몬이 이 필수적인 감시 프로세스(diskmon)와 대화를 나누지 못하는 상태, 즉 **”심각한 통신 단절 혹은 프로세스 먹통 상태”**에 빠졌음을 의미합니다.

ExaCC 인프라 패치 중 에러 발생 원인 심층 분석

그렇다면 평소에는 멀쩡하던 diskmon 하트비트가 왜 하필 분기 인프라 패치 중에 중단되어 우리를 곤란하게 만들었을까요? 제 경험과 오라클 기술 문서를 종합해 보면 원인은 크게 3가지 유형으로 압축됩니다.

① 패치 중 스토리지 셀/Dom0 순차 리부팅에 따른 일시적 핑 타임아웃

ExaCC 인프라 패치가 시작되면 오라클 자동화 시스템은 스토리지 서버와 물리 호스트(Dom0)를 하나씩 순차적으로 업데이트하고 리부팅합니다. 이 과정에서 네트워크 경로가 재구성되거나 일시적인 전환(Failover)이 일어나는데, 하필 해당 VM 노드의 커널 리소스가 고갈되어 있거나 I/O 부하가 극도로 높은 상태였다면 diskmon이 정해진 임계 시간 내에 하트비트 신호를 처리하지 못해 프로세스가 멈춰버릴 수 있습니다.

② 클러스터 IPC(Inter-Process Communication) 소켓 파일 오염

오라클 클러스터웨어 내부 프로세스들은 리눅스 OS 레벨의 로컬 소켓 파일이나 명명된 파이프(Named Pipe)를 사용해 초당 수천 번씩 데이터를 주고받습니다. 패치 스크립트가 실행되면서 일부 프로세스를 내리고 올리는 과정에서, diskmon이나 관련 데몬이 정상적인 시그널을 받지 못하고 비정상 종료되면 이 통신용 임시 파일들이 /tmp 또는 /var/tmp 디렉터리에 ‘잠김(Lock)’ 상태의 찌꺼기로 남게 됩니다. 이 찌꺼기들 때문에 프로세스가 데드락(Deadlock)에 걸려 패치 진행이 불가능해집니다.

③ OS 리소스 경합 및 OOM(Out of Memory)

분기 패치 중에는 다양한 사전 검사(Precheck) 스크립트, RPM 업데이트, 설정 복사 등 평소보다 많은 OS 백그라운드 작업이 동시에 돕니다. 만약 해당 ExaCC VM 클러스터의 관리 영역 메모리가 아슬아슬했거나 특정 버그로 인해 메모리 누수가 발생 중이었다면, 리눅스 커널의 OOM Killer가 diskmon 프로세스를 강제로 죽여버리면서 하트비트가 끊기기도 합니다.

해결 프로세스: CRS 강제 종료부터 찌꺼기 파일 삭제, 재기동까지

패치가 중단되고 해당 노드의 데이터베이스 및 클러스터웨어가 행(Hang) 상태에 빠졌을 때, 가장 신속하고 확실한 해결책은 문제가 된 노드의 클러스터(CRS) 스택을 강제 종료하고, 통신을 방해하는 임시 파일을 깨끗이 지운 뒤 처음부터 깨끗하게 구동(Clean Start)하는 것입니다.

실제 제가 장애를 해결했던 단계별 기술 절차입니다. 모든 작업은 해당 VM 노드에 root 계정으로 접속하여 수행해야 합니다.

[단계 1] 먹통이 된 CRS 강제 종료 (Force Stop)

diskmon 하트비트가 멈추면 일반적인 종료 명령인 crsctl stop crs는 내부 타임아웃을 기다리느라 몇 시간 동안 응답이 없을 수 있습니다. 따라서 클러스터웨어 엔진에게 즉시 종료 시그널을 보내는 -f (Force) 옵션을 사용하여 강제로 프로세스들을 걷어내야 합니다.

Bash

# root 계정으로 Grid Infrastructure 홈 디렉터리로 이동 후 강제 종료 실행
export GRID_HOME=/u01/app/21.0.0/grid  # 환경에 맞는 GI 홈 경로 지정
$GRID_HOME/bin/crsctl stop crs -f

⚠️ 실무 팁 (경험담)

-f 옵션을 주었음에도 불구하고 ps -ef | grep grid 명령을 쳐보면 여전히 특정 프로세스가 좀비처럼 남아있는 경우가 많습니다. 이럴 때는 아래 명령어를 통해 남아있는 오라클 프로세스들을 수동으로 완벽히 킬(Kill)해주어야 다음 단계로 안전하게 넘어갈 수 있습니다.

Bash

# 종료되지 않고 남아있는 오라클 클러스터 관련 프로세스 강제 종료
kill -9 $(ps -ef | grep -E 'ohasd|ocssd|crsd|diskmon' | grep -v grep | awk '{print $2}')

[단계 2] 통신 장애를 유발하는 로컬 IPC 및 소켓 파일 삭제 (Clean up)

이번 장애 해결의 가장 중요한 핵심 하이라이트입니다. diskmon이 비정상적으로 종료되면서 리눅스 파일 시스템 내부에 남겨둔 유닉스 도메인 소켓 및 락 파일들을 청소해야 합니다. 이 파일들이 남아있으면 CRS를 다시 켜려고 해도 *”이미 프로세스가 실행 중이거나 소켓이 점유되어 있다”*는 에러를 뿜으며 구동에 실패합니다.

오라클 클러스터웨어가 통신용으로 사용하는 임시 디렉터리는 주로 /var/tmp/.oracle 또는 /tmp/.oracle입니다.

Bash

# 1. 관련 임시 디렉터리로 이동
cd /var/tmp/.oracle

# 2. 존재하는 파일 목록 확인 (diskmon, scls, sock 관련 찌꺼기 확인)
ls -al

# 3. 안전하게 해당 디렉터리 내의 오라클 관련 찌꺼기 파일 일괄 삭제
# (주의: 반드시 CRS 프로세스가 완벽히 죽은 것을 확인하고 수행해야 합니다!)
rm -rf /var/tmp/.oracle/*
rm -rf /tmp/.oracle/*

추가로 노드 간 인증 및 클러스터 동기화 상태를 기록하는 내장 디렉터리 내부도 체크하여 문제가 될 만한 임시 파일을 정리해 줍니다.

Bash

# CSS 및 인증 관련 임시 파일 보관소 확인 및 정리
cd $GRID_HOME/auth/css/
ls -al

[단계 3] 청정 상태에서 Grid Infrastructure(CRS) 재기동

공유 메모리와 소켓 파일 시스템을 태초의 상태로 깨끗하게 비웠으니, 이제 클러스터 스택의 최하단 가디언 데몬인 ohasd부터 차례대로 시스템을 리스타트합니다.

Bash

# CRS 재기동 명령어 실행
$GRID_HOME/bin/crsctl start crs

명령어를 실행하면 백그라운드에서 ohasd -> ora.diskmon -> ora.cssd -> ora.crsd -> ora.asm -> DB 인스턴스 순서로 컴포넌트들이 도미노처럼 차례대로 살아나기 시작합니다.

[단계 4] 클러스터 자원 및 패치 재개 상태 실시간 모니터링

정상적으로 구동이 완료되는지, 그리고 중단되었던 ExaCC 인프라 패치 워크플로우가 다시 정상 궤도에 진입했는지 실시간으로 모니터링해야 합니다.

Bash

# 1. CRS 기본 데몬들의 정상 구동 여부 확인
$GRID_HOME/bin/crsctl check crs

# 2. 전체 클러스터 리소스 상태를 테이블 형태로 확인
$GRID_HOME/bin/crsctl stat res -t

모든 리소스의 Status가 ONLINE으로 변경된 것을 확인했다면, OCI(Oracle Cloud Infrastructure) 웹 콘솔 화면으로 이동해 봅니다. 멈춰 있던 ‘Infrastructure Patching…’ 상태의 태스크가 정상적인 통신을 회복하면서 자동으로 다음 단계(Next Storage Cell 또는 Next Node)로 진행되거나 완료 상태로 전환되는 것을 보실 수 있습니다. 메인 화면의 초록 불을 확인하는 순간 비로소 안도의 한숨이 나옵니다.

ExaCC 정기 패치 시 장애 예방을 위한 체크리스트

사후 조치로 문제를 해결하는 것도 중요하지만, 가장 좋은 것은 애초에 패치가 멈추지 않도록 예방하는 것이겠죠. 다음 분기 패치 성공률을 높이기 위해 현업에서 반드시 체크해야 할 가이드라인을 정리했습니다.

• 패치 전 최신 EXACHK 수행 (필수):패치 일주일 전과 하루 전에 exachk를 반드시 실행하세요. RoCE 네트워크의 일시적 패킷 드롭, ASM 디스크 정합성, OS 커널 파라미터 미스매치 등 패치 도중 diskmon 크래시를 유발할 수 있는 잠재적 유해 요소를 사전에 완벽히 걸러내 줍니다.
• /u01 및 /u02 파일 시스템 공간 확보:오라클 홈이 위치한 파일 시스템에 최소 15~20GB 이상의 여유 공간이 있어야 합니다. 패치 압축 해제 및 백업본 생성 과정에서 디스크 공간이 100%를 치면 프로세스 간 소켓 파일 생성 자체가 실패하면서 엉뚱하게 diskmon 에러로 발현될 수 있습니다.
• 배치 작업 및 대용량 I/O 윈도우 피하기:인프라 패치는 무중단(Rolling)이 원칙이지만, 스토리지 셀이 리부팅될 때 ASM 디스크 리싱크(Resync) 부하가 필연적으로 발생합니다. 이 타이밍에 대규모 배치 데이터 적재나 백업 작업이 겹치면 I/O 병목으로 인해 하트비트 타임아웃 에러가 발생할 확률이 비약적으로 상승합니다.
• 클라우드 자동화 규칙 준수 (수동 패치 금지):ExaCC는 사용자가 root 권한을 가지고 있다고 해서 일반 온프레미스 서버처럼 yum update를 수동으로 치거나 오라클 서포트에서 직접 다운로드한 패치 파일로 수동 OPatch를 진행하면 절대 안 됩니다. OCI 백엔드 제어부의 메타데이터와 실제 VM 상태가 틀어지면 향후 자동화 기능이 영구적으로 에러를 뿜게 됩니다. 패치는 무조건 OCI 콘솔 UI나 정식 dbaascli 툴만 이용하세요.

에디터의 사후 관리 제안 (Root Cause 분석)

이번에 발생한 현상은 CRS 강제 종료 후 소켓 찌꺼기 파일들을 수동으로 완벽히 청소해 줌으로써 성공적으로 우회 조치(Workaround)되었습니다.

하지만 엔지니어라면 여기서 작업을 끝내서는 안 됩니다. 현재 조치는 꼬여버린 상태를 풀어준 것뿐이므로, 패치가 완료된 이후 “왜 인프라 패치 중에 하필 그 노드에서 diskmon 하트비트가 끊겼는가?”에 대한 근본 원인(Root Cause) 분석이 동반되어야 다음 패치 때 동일한 장애를 막을 수 있습니다.

장애가 발생했던 시간대의 아래 로그 파일들을 백업하여 Oracle Support에 정식 SR(Service Request)을 개설하고 진단을 받으시는 것을 강력히 권장합니다.

Plaintext

📌 분석이 필요한 필수 오라클 로그 경로
1. Grid Infrastructure alert 로그: $GRID_HOME/log/<node_name>/alert<node_name>.log
2. CSSD 데몬 상세 로그: $GRID_HOME/log/<node_name>/cssd/ocssd.log
3. Diskmon 데몬 상세 로그: $GRID_HOME/log/<node_name>/diskmon/diskmon.log
4. OS 시스템 로그: /var/log/messages (장애 시점 전후 30분)

ExaCC와 같은 고도화된 클라우드 환경일수록 아키텍처에 대한 정확한 이해를 바탕으로 한 트러블슈팅이 빛을 발합니다. 밤샘 작업 중 유사한 에러로 모니터 앞에서 고뇌하고 계실 동료 DBA 분들에게 이 글이 한 줄기 빛이 되기를 바랍니다.

전문가의 인사이트 : 함께 읽어 보세요.

[[ExaCC 운영 꿀팁] exachk 180일 오류 해결 및 AHF 업그레이드]

참조 및 출처 URL:

https://docs.oracle.com/en/engineered-systems/exadata-cloud-at-customer