ExaCC 분기 패치 중 diskmon 에러로 Patch fail 발생시 조치 방법 공유합니다.

Oracle Exadata Cloud@Customer(ExaCC) 환경을 운영하는 데이터베이스 엔지니어(DBA)나 인프라 관리자에게 ‘분기별 정기 인프라 패치(Quarterly Infrastructure Patching)’는 시스템의 안정성과 보안을 유지하기 위한 필수 관문입니다. 오라클의 철저한 클라우드 자동화(Cloud Automation) 기술 덕분에 과거에 비해 패치 과정이 매우 간소화되었다고는 하지만, 고성능 하드웨어와 복잡한 그리드 인프라(Grid Infrastructure) 아키텍처가 결합된 Exadata 특성상 예기치 못한 에러로 패치가 중단되는 상황은 언제나 발생할 수 있습니다.

작업시간은 한정되어 있는데 패치 fail 이 발생하면 난감합니다. 2분기 패치시 조치한 내용을 기반으로 작성하였습니다.

최근 운영 중인 ExaCC 환경에서 분기 인프라 패치를 진행하던 중, 특정 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) 상태에 빠지게 됩니다.

본 포스팅에서는 ExaCC 인프라 패치 중 왜 이러한 diskmon heartbeat stopped 에러가 발생하는지 그 근본 아키텍처를 파헤치고, 일반적인 명령어로 내려가지 않는 CRS(Cluster Ready Services)를 강제 종료한 뒤 프로세스 간 통신(IPC) 찌꺼기 파일을 클리닝하고 재기동하여 패치를 성공적으로 재개한 실무 트러블슈팅 과정을 아주 상세하게 공유하고자 합니다.

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

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

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

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

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

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

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

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

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

그렇다면 평소에는 잘 작동하던 diskmon 하트비트가 왜 하필 분기 인프라 패치 중에 중단되어 패치 작업을 멈추게 만들었을까요? 실무에서 발생할 수 있는 주요 원인은 다음과 같이 3가지 유형으로 압축됩니다.

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

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

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

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

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

분기 패치 중에는 다양한 사전 검사(Precheck) 스크립트, RPM 업데이트, 설정 복사 등 평소보다 많은 OS 백그라운드 작업이 수행됩니다. 만약 해당 ExaCC VM 클러스터의 관리 영역(Management Area) 메모리가 부족했거나, 특정 버그로 인해 메모리 누수(Memory Leak)가 발생 중이었다면, 리눅스 커널의 OOM Killer가 diskmon 프로세스를 강제로 빌딩(Kill)하여 하트비트가 중단되는 현상이 발생하기도 합니다.

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

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

실제 장애를 해결한 단계별 기술 절차와 핵심 명령어를 공개합니다. 모든 작업은 해당 VM 노드에 root 계정으로 접속하여 수행해야 합니다.

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

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

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 또는 ps -ef | grep ohasd 명령 실행 시 여전히 프로세스가 좀비처럼 남아있는 경우가 있습니다. 이럴 때는 아래 명령어를 통해 남아있는 오라클 고성능 프로세스들을 수동으로 완벽히 킬(Kill)해주어야 다음 단계로 넘어갈 수 있습니다.

Bash

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

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

이번 장애 해결의 가장 중요한 핵심 분기점입니다. diskmon이 비정상적으로 종료되면서 리눅스 파일 시스템 내부에 남겨둔 유닉스 도메인 소켓(Unix Domain Socket) 및 락 파일들을 청소해야 합니다. 이 파일들이 남아있으면 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(Oracle High Availability Services Daemon)부터 차례대로 시스템을 리스타트합니다.

Bash

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

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

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

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

Bash

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

# 2. 전체 클러스터 리소스(RAC 노드, ASM, 디스크그룹, DB 등) 상태를 테이블 형태로 확인
$GRID_HOME/bin/crsctl stat res -t

모든 리소스의 Status가 ONLINE으로 변경되고 Target 상태와 일치하는 것을 확인했다면, OCI(Oracle Cloud Infrastructure) 웹 콘솔 화면으로 이동합니다. 멈춰 있던 ‘Infrastructure Patching…’ 상태의 태스크가 정상적인 통신을 회복하면서 자동으로 다음 단계(Next Storage Cell 또는 Next Node)로 재개(Resume)되거나 완료 상태로 전환되는 것을 확인할 수 있습니다.

4. ExaCC 정기 패치 시 장애 예방을 위한 체크리스트 및 주의점

이번 diskmon 하트비트 장애는 사후 조치를 통해 성공적으로 해결되었지만, 가장 좋은 것은 이러한 패치 중단 사태를 사전에 예방하는 것입니다. ExaCC 정기 패치 성공률을 100%로 끌어올리기 위해 현업에서 반드시 지켜야 할 가이드라인을 공유합니다.

4.1 패치 전 최신 EXACHK 수행 (필수 중의 필수)

오라클 엔지니어드 시스템 전용 헬스체크 툴인 exachk를 패치 일주일 전과 하루 전에 반드시 실행해야 합니다.

• 이유: exachk는 현재 고속 RoCE 네트워크의 일시적 패킷 드롭, ASM 디스크의 정합성 불안정, OS 커널 파라미터 미스매치 등 패치 도중 diskmon 크래시를 유발할 수 있는 잠재적 유해 요소를 사전에 완벽히 걸러내 줍니다. 만약 여기서 WARNING이나 FAIL이 뜬다면 패치를 수립하기 전에 해당 이슈부터 선행 조치해야 합니다.

4.2 /u01 및 /u02 파일 시스템 공간 확보

패치 가동 전 각 VM 노드의 로컬 디스크 공간을 체크하세요. 특히 오라클 홈이 위치한 파일 시스템에 최소 15GB에서 20GB 이상의 여유 공간이 확보되어 있어야 합니다. 패치 압축 해제 및 백업본 생성 과정에서 디스크 공간이 100%를 치면 프로세스 간 소켓 파일 생성 자체가 실패하면서 diskmon heartbeat stopped 같은 엉뚱한 에러로 발현될 수 있습니다.

4.3 배치 작업 및 대용량 I/O 윈도우 피하기

인프라 패치는 롤링 방식으로 무중단 진행되는 것이 원칙이지만, 스토리지 셀이 리부팅될 때 ASM 디스크 리싱크(Resync) 부하가 필연적으로 발생합니다. 이 타이밍에 대규모 배치 데이터 적재나 대용량 백업 작업이 수행되면 I/O 병목으로 인해 하트비트 타임아웃 에러가 발생할 확률이 비약적으로 상승합니다. 따라서 시스템 서비스 사용량이 가장 적은 새벽 시간대나 주말로 유지보수 윈도우(Maintenance Window)를 지정해야 합니다.

4.4 클라우드 자동화 규칙 준수 (수동 패치 금지)

ExaCC는 사용자가 root 권한을 가지고 있다고 해서 일반 온프레미스(On-Premise) 서버처럼 yum update를 수동으로 치거나, 오라클 서포트에서 직접 다운로드한 패치 파일로 수동 OPatch를 진행하면 절대 안 됩니다.

• 이유: 수동으로 패키지를 건드리면 OCI 백엔드 제어부(Control Plane)의 메타데이터와 실제 VM의 상태 정보가 불일치하게 되어, 향후 오라클이 제공하는 분기 인프라 패치 자동화 기능이 영구적으로 에러를 뿜으며 실패하게 됩니다. 패치와 업그레이드는 무조건 OCI 콘솔 UI, OCI CLI, 또는 정식 dbaascli 툴만을 이용해야 합니다.

임시 조치 이후의 사후 관리 (Root Cause 분석)

이번에 발생한 Heartbeat with diskmon stopped 현상은 CRS 강제 종료 후 /var/tmp/.oracle 내부의 찌꺼기 소켓 파일들을 수동으로 완벽히 청소해 줌으로써 성공적으로 해결되었습니다.

하지만 엔지니어로서 여기서 작업을 끝내서는 안 됩니다. 현재 취한 조치는 꼬여버린 프로세스 상태를 풀어준 우회 조치(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