"멀쩡하던 2번 노드가 죽었습니다" Oracle RAC Eviction 발생 시 범인 찾는 순서

📚 같이 보면 좋은 글

• CPU 캐시 메모리 완벽 가이드 | L1, L2, L3 캐시의 모든 것
• 로컬에서 RAG 구축하는 방법 완벽 가이드 | Ollama + LangChain 무료 설치
• 양자 컴퓨팅 혁명의 핵심 열쇠: 큐비트·중첩·얽힘 완벽 이해하기
• 게임 물리 엔진이란? 초보자도 이해하는 쉬운 가이드
• 딥러닝 활성화 함수 완벽 가이드: ReLU, Sigmoid, Tanh 비교와 최적 선택법

Oracle RAC Node Eviction 완벽 이해

클러스터 노드 축출의 원인과 해결 방법 총정리 | DBA가 반드시 알아야 할 5가지 핵심 사례

📑 목차

1. Oracle RAC Eviction이란 무엇인가?
2. Node Eviction이 발생하는 근본 원인
3. Eviction을 유발하는 5가지 주요 사례
   • 사례 1: 네트워크 하트비트 실패
   • 사례 2: 디스크 하트비트 지연
   • 사례 3: 시스템 리소스 고갈
   • 사례 4: 인터커넥트 네트워크 문제
   • 사례 5: 스토리지 성능 저하
4. Node Eviction 발생 시 대응 방법
5. Eviction 예방을 위한 모니터링 전략
6. 자주 묻는 질문 (FAQ)

Oracle RAC 클러스터는 여러 노드가 협력하여 고가용성 데이터베이스 서비스를 제공합니다

 

Oracle RAC Eviction이란 무엇인가?

Oracle RAC(Real Application Clusters) 환경에서 Node Eviction은 클러스터의 무결성과 데이터 보호를 위해 문제가 있는 노드를 강제로 클러스터에서 제거하는 자동 보호 메커니즘입니다. 이는 버그가 아니라 Oracle이 데이터 손상을 방지하기 위해 설계한 필수적인 안전장치입니다.

💡 핵심 개념: RAC 클러스터는 여러 서버(노드)가 하나의 데이터베이스를 공유하는 구조입니다. 만약 한 노드가 다른 노드들과 제대로 통신하지 못하거나 클러스터 규칙을 위반하면, 데이터 손상을 막기 위해 해당 노드가 자동으로 축출됩니다. 이 과정에서 노드는 재부팅되며, 로그에는 ORA-29740 에러가 기록됩니다.

Eviction이 발생하면 해당 노드의 데이터베이스 인스턴스가 종료되고, 운영체제 수준에서 노드가 재시작됩니다. 이는 Split-Brain 시나리오(클러스터가 분리되어 각각 독립적으로 작동하는 상황)를 방지하고 데이터 일관성을 보장하기 위한 최후의 수단입니다.

Node Eviction이 발생하는 근본 원인

Oracle RAC는 클러스터의 건강 상태를 지속적으로 모니터링하며, 다음과 같은 핵심 메커니즘을 통해 노드 상태를 평가합니다:

1. 하트비트 메커니즘

Oracle Clusterware는 두 가지 방식으로 노드 간 하트비트를 교환합니다:

• 네트워크 하트비트: 프라이빗 인터커넥트를 통해 노드 간 주기적으로 신호를 주고받습니다
• 디스크 하트비트: Voting Disk에 주기적으로 상태 정보를 기록합니다

기본적으로 misscount 파라미터는 30초로 설정되어 있으며, 이 시간 내에 하트비트 응답이 없으면 노드는 위험 상태로 간주됩니다. 90% 임계값에 도달하면 Eviction이 실행됩니다.

2. Cluster Synchronization Services (CSS)

CSS는 클러스터 멤버십을 관리하는 핵심 프로세스입니다. ocssd.bin 프로세스가 다른 노드로부터 하트비트를 받지 못하거나, Voting Disk에 접근할 수 없으면 해당 노드를 클러스터에서 제거합니다.

3. Instance Membership Recovery (IMR)

IMR은 인스턴스 레벨에서 실패를 감지하고 복구하는 메커니즘입니다. LMON(Lock Monitor) 프로세스가 이를 담당하며, 통신 장애 발생 시 Global Resource Directory를 재구성하고 필요시 노드를 축출합니다.

RAC 클러스터의 프라이빗 인터커넥트는 노드 간 통신의 생명선입니다

 

Eviction을 유발하는 5가지 주요 사례

사례 1: 네트워크 하트비트 실패 (가장 흔한 원인)

🔴 실제 사례

프라이빗 인터커넥트 스위치에서 한 포트가 플래핑(flapping) 현상을 보이면서 노드 간 통신이 간헐적으로 끊어졌습니다. 로그에는 다음과 같은 메시지가 나타났습니다:

[cssd] CRS-1610: Network communication with node racnode2 missing for 90% of timeout interval. Removal of this node from cluster in 2.510 seconds

발생 원인:

• 인터커넥트 스위치 포트 장애
• 네트워크 케이블 불량
• NIC(Network Interface Card) 드라이버 문제
• 방화벽 정책으로 인한 패킷 차단
• 네트워크 혼잡으로 인한 지연

해결 방법: 인터커넥트는 최소 1Gbps 이상의 전용 네트워크를 사용해야 하며, 가능하면 이중화(bonding, LACP)를 구성해야 합니다. 네트워크 성능 최적화에 대한 깊이 있는 이해가 필요합니다.

사례 2: 디스크 하트비트 지연

🔴 실제 사례

SAN 스토리지에서 갑작스러운 I/O 폭증으로 Voting Disk 쓰기 지연이 발생했습니다. disktimeout 값인 200초를 초과하면서 노드가 축출되었습니다.

발생 원인:

• 스토리지 컨트롤러 과부하
• SAN 스위치 병목 현상
• Voting Disk가 있는 디스크 그룹 성능 저하
• 과다한 백업 작업으로 인한 I/O 경합
• 파일시스템 레벨의 락 경합

해결 방법: Voting Disk는 반드시 고성능 스토리지에 배치하고, 최소 3개 이상의 Voting Disk를 서로 다른 디스크에 분산 배치해야 합니다. ASM을 사용하는 경우 Normal 또는 High Redundancy를 권장합니다.

사례 3: 시스템 리소스 고갈 (CPU/메모리 부족)

🔴 실제 사례

갑작스러운 쿼리 폭주로 CPU가 100%에 도달하고 메모리 스와핑이 발생했습니다. 이로 인해 CSS 프로세스가 적시에 하트비트를 전송하지 못해 노드가 축출되었습니다.

발생 원인:

• CPU 100% 사용으로 인한 OS 스케줄링 지연
• 메모리 부족으로 인한 과도한 스와핑
• ORAAGENT 프로세스의 과도한 리소스 소비
• 통제되지 않은 병렬 쿼리 실행
• /var 파일시스템 용량 100% 도달

해결 방법: Oracle Resource Manager를 설정하여 워크로드를 제어하고, CPU를 Clusterware 프로세스를 위해 예약(cgroups 사용)해야 합니다. 시스템 성능 모니터링 전략을 수립하는 것이 중요합니다.

사례 4: 인터커넥트 네트워크 설정 오류

🔴 실제 사례

cluster_interconnects 파라미터를 잘못 설정하여 HAIP(Highly Available IP)가 제대로 작동하지 않았습니다. 한 인터페이스가 다운되자 HAIP 페일오버가 실패하고 노드가 축출되었습니다.

발생 원인:

• cluster_interconnects 파라미터 잘못된 설정
• 인터커넥트 인터페이스의 MTU 크기 불일치
• 방화벽에서 UDP 포트 차단
• HAIP 주소가 올바르게 생성되지 않음
• Link Local 주소(169.254.x.x) 충돌

해결 방법: Oracle 11gR2 이후 버전에서는 cluster_interconnects 파라미터를 설정하지 않는 것이 권장됩니다. HAIP가 자동으로 관리하도록 두어야 합니다. 여러 인터페이스를 사용할 경우 bonding 대신 HAIP를 활용하는 것이 좋습니다.

사례 5: 스토리지 성능 저하 및 Hang

🔴 실제 사례

스토리지 어레이에서 컨트롤러 페일오버가 발생하면서 I/O 응답 시간이 수십 초까지 증가했습니다. 데이터베이스 인스턴스가 Hang 상태에 빠지면서 Hang Manager가 인스턴스를 종료하고 노드를 축출했습니다.

발생 원인:

• 스토리지 컨트롤러 페일오버
• 디스크 장애로 인한 RAID 재구성
• 스토리지 펌웨어 버그
• 멀티패스 설정 오류
• 과도한 I/O 부하로 인한 큐잉

해결 방법: 스토리지 QoS를 구성하고, ASM Disk Group에 적절한 리던던시를 설정해야 합니다. 또한 데이터베이스 성능 최적화 작업을 통해 불필요한 I/O를 줄여야 합니다.

Node Eviction 발생 시 대응 방법

1. 로그 파일 분석

문제 발생 시 다음 로그 파일들을 우선 확인해야 합니다:

• $GRID_HOME/log/<hostname>/cssd/ocssd.log - CSS 데몬 로그
• $GRID_HOME/log/<hostname>/agent/crsd/oraagent_oracle/oraagent_oracle.log
• /var/log/messages - 시스템 로그
• 데이터베이스 alert.log 및 LMON trace 파일

2. OSWatcher를 활용한 사후 분석

OSWatcher는 Oracle이 제공하는 무료 모니터링 도구로, 시스템 통계를 주기적으로 수집합니다. Eviction 발생 시점의 oswnetstat, oswprvtnet, oswiostat 데이터를 분석하면 근본 원인을 파악할 수 있습니다.

3. CSS Misscount 조정

네트워크 환경에 따라 misscount 값을 조정할 수 있습니다:

# 현재 설정 확인
crsctl get css misscount

# misscount 변경 (root 권한 필요)
crsctl set css misscount 60

# 설정 확인
crsctl get css misscount

⚠️ 주의: misscount를 너무 높게 설정하면 실제 장애 발생 시 복구 시간이 길어질 수 있습니다. 일반적으로 30~60초 범위에서 설정하는 것이 권장됩니다.

Eviction 예방을 위한 모니터링 전략

Node Eviction을 예방하기 위해서는 사전에 잠재적 문제를 감지하는 것이 중요합니다:

모니터링 체크리스트

• Cluster Health Monitor (CHM): 서브초 단위로 OS 메트릭을 수집하여 성능 저하 조기 감지
• 네트워크 지연 모니터링: 인터커넥트 지연이 2ms를 초과하면 경고
• CPU 예약: Clusterware 프로세스를 위한 CPU 코어 예약 (cgroups 활용)
• 스토리지 QoS: 데이터베이스 I/O에 우선순위 부여
• 정기적인 네트워크 테스트: iperf, orion 도구를 사용한 인터커넥트 성능 검증

이러한 모니터링은 고급 시스템 관리 기법과 함께 적용하면 더욱 효과적입니다.

자주 묻는 질문 (FAQ)

Q1. Node Eviction이 발생하면 데이터가 손실되나요?

아니요, 데이터는 손실되지 않습니다. Eviction은 오히려 데이터 손상을 방지하기 위한 보호 메커니즘입니다. 축출된 노드의 트랜잭션은 다른 노드에서 복구되며, 클러스터는 정상적으로 계속 작동합니다.

Q2. Node Eviction과 Instance Crash의 차이는 무엇인가요?

Instance Crash는 데이터베이스 인스턴스만 종료되는 반면, Node Eviction은 인스턴스 종료에 더해 운영체제까지 재부팅됩니다. Eviction은 클러스터 레벨의 결정으로 더 심각한 상황으로 간주됩니다.

Q3. RAC 환경에서 하나의 노드만 운영해도 되나요?

Oracle RAC One Node를 사용하면 가능합니다. 이는 단일 노드로 운영하다가 장애 발생 시 다른 노드로 자동 페일오버되는 Active-Passive 구성입니다. 라이선스 비용을 절감하면서도 고가용성을 확보할 수 있습니다.

Q4. 클라우드 환경에서도 Node Eviction이 자주 발생하나요?

클라우드 환경(특히 가상화된 환경)에서는 네트워크 지연이나 리소스 경합으로 인해 Eviction이 더 자주 발생할 수 있습니다. VM의 CPU 스틸 타임, 스토리지 레이턴시 등을 주의 깊게 모니터링해야 합니다.

Q5. Voting Disk는 몇 개를 사용하는 것이 좋나요?

Oracle은 최소 3개, 최대 5개의 Voting Disk를 권장합니다. 홀수 개를 사용하는 것이 좋으며, 과반수의 Voting Disk에 접근할 수 있어야 노드가 클러스터에 남을 수 있습니다. ASM을 사용한다면 Normal Redundancy로 자동 관리됩니다.

Q6. Eviction 발생 시 고객 서비스에 영향이 있나요?

제대로 설계된 RAC 환경에서는 한 노드가 축출되어도 다른 노드들이 즉시 부하를 인수받아 서비스를 계속합니다. 하지만 세션 레벨에서는 일시적인 연결 끊김이 발생할 수 있으므로, 애플리케이션에 TAF(Transparent Application Failover)를 구현하는 것이 좋습니다.

Q7. misscount 값을 증가시키면 Eviction을 완전히 막을 수 있나요?

misscount를 증가시키면 일시적인 네트워크 지연에 대한 허용 범위가 늘어나지만, 근본적인 문제 해결은 아닙니다. 오히려 실제 장애 발생 시 복구 시간이 길어질 수 있으므로, 네트워크와 스토리지 인프라 자체를 개선하는 것이 올바른 접근 방법입니다.

Q8. Oracle Grid Infrastructure 업그레이드 중에도 Eviction이 발생할 수 있나요?

가능합니다. 업그레이드 중 일시적인 서비스 중단이나 리소스 경합으로 인해 Eviction이 발생할 수 있습니다. 따라서 업그레이드 전에 충분한 테스트를 수행하고, 가능하면 점진적 업그레이드(Rolling Upgrade) 방식을 사용하는 것이 안전합니다.

📘 Oracle RAC 공식 문서

Oracle RAC 19c 관리 가이드 바로가기 →

마무리하며

Oracle RAC Node Eviction은 데이터베이스 관리자에게 가장 까다로운 문제 중 하나입니다. 하지만 그 원리를 제대로 이해하고 적절한 모니터링 체계를 갖춘다면, 대부분의 Eviction은 사전에 예방하거나 신속하게 대응할 수 있습니다.

RAC 클러스터는 고가용성을 제공하는 강력한 아키텍처이지만, 동시에 네트워크, 스토리지, 시스템 리소스 등 여러 계층이 완벽하게 조화를 이루어야 합니다. 따라서 인프라 전반에 대한 깊은 이해와 지속적인 모니터링이 필수적입니다.

이 글에서 다룬 5가지 주요 사례와 대응 방법을 참고하여, 안정적인 RAC 운영 환경을 구축하시기 바랍니다. 문제가 발생했을 때는 당황하지 말고 로그를 체계적으로 분석하며, 필요하다면 Oracle Support의 도움을 받는 것도 좋은 방법입니다.