-
RAC 01: 개념 & 아키텍처 — Cluster · GCS/GES · Cache FusionDB 스터디/04_RAC 2026. 5. 6. 15:53
목차
1. RAC란?
2. SMP vs RAC 모델 비교
3. Scale-up vs Scale-out / Speed-up vs Scale-up
4. I/O 구성요소
5. RAC 소프트웨어 구성
6. RAC 데이터베이스 저장소 구조
7. RAC 네트워크 구성 — Public · Private · VIP · SCAN
8. 공유 스토리지 구성 — ASM
9. Clusterware 구성 요소 — OCR · Voting Disk
10. 전역 자원 관리 — GRD · GCS · GES
11. Object Affinity · Dynamic Remastering
12. Cache Fusion
13. Dynamic Reconfiguration
14. 백그라운드 프로세스
15. Row-Level Locking in RAC
16. 메모리 요구사항
1. RAC란?
- RAC(Real Application Clusters): 여러 서버(노드)가 하나의 오라클 DB를 동시에 Active-Active 방식으로 운영하는 구성
- 단일 인스턴스 대비 고가용성(HA), 수평 확장(Scale-out), 부하 분산(Load Balancing) 동시 제공
항목 단일 인스턴스 RAC 구성 1 Server — 1 Instance — 1 DB N Server — N Instance — 1 DB 확장 방식 Scale-up (서버 사양 업그레이드) Scale-out (노드 추가) 장애 대응 서버 장애 시 서비스 중단 한 노드 장애 시 나머지 노드가 서비스 지속 스토리지 로컬 또는 공유 공유 스토리지 필수 - RAC는 하나의 DB 파일 집합을 여러 인스턴스가 동시에 마운트·오픈
- 각 인스턴스는 독립적인 SGA/PGA를 가지되, 동일한 데이터를 읽고 씀
2. SMP vs RAC 모델 비교
- 서버 자체를 여러 대 묶는 RAC는 단일 서버 내에서 CPU를 늘리는 SMP(Symmetric Multi-Processing)와 확장 방식이 근본적으로 다름
항목 SMP RAC 구조 하나의 서버 — 다수의 CPU 공유 메모리 다수의 서버 — 각 서버가 독립 메모리 보유 확장 방식 Scale-up (CPU · 메모리 업그레이드) Scale-out (노드 추가) 병목 지점 공유 메모리 버스 및 I/O 경합 Interconnect 대역폭, 블록 충돌(Hot Block) 장애 대응 서버 단일 장애 시 전체 중단 노드 장애 시 나머지 노드가 서비스 지속 비용 구조 고사양 단일 서버 — 하드웨어 비용 급증 범용 서버 다수 — 단계적 비용 투자 가능 - SMP는 하나의 OS 이미지 안에서 모든 CPU가 동일한 메모리 공간 공유. 메모리 버스가 병목이 되면 CPU를 추가해도 성능이 선형으로 늘지 않음
- RAC는 각 노드가 독립적인 메모리를 가지며, 노드 간 데이터 공유는 Interconnect와 Cache Fusion으로 해결
3. Scale-up vs Scale-out / Speed-up vs Scale-up
- RAC를 선택하는 이유를 이해하려면 두 가지 확장 방식을 구분해야 함
확장 방식 비교
방식 정의 적용 예 Scale-up (수직 확장) 기존 서버의 CPU · 메모리 · 스토리지를 업그레이드 단일 인스턴스 서버 사양 강화 Scale-out (수평 확장) 서버(노드)를 추가하여 전체 처리 능력 확장 RAC 노드 추가 성능 개선 방식 비교
방식 정의 비고 Speed-up 동일한 작업을 더 빠르게 완료 하드웨어 성능 향상으로 달성 Scale-up (성능 관점) 더 많은 작업을 동시에 처리 병렬 처리 · 노드 추가로 달성 - RAC는 Scale-out + Scale-up(성능 관점) 을 동시에 지향. 노드를 추가할수록 동시 처리 가능한 트랜잭션 수 증가
- Scale-up은 하드웨어 한계와 비용 급증이라는 물리적 천장 존재. RAC는 이 천장을 노드 추가로 우회
4. I/O 구성요소
- RAC 환경에서 스토리지 I/O 성능은 여러 구성요소의 조합으로 결정됨
구성요소 역할 비고 Bandwidth (대역폭) 단위 시간당 전송 가능한 데이터 양 GB/s 단위, 스토리지 연결 방식에 따라 결정 Latency (지연) I/O 요청 발생 후 응답까지 걸리는 시간 ms 단위, SSD가 HDD 대비 월등히 낮음 HBA (Host Bus Adapter) 서버와 SAN(Storage Area Network)을 연결하는 I/O 어댑터 FC HBA 또는 iSCSI HBA FC Switch (Fibre Channel Switch) 서버(HBA)와 Disk Array를 중간에서 연결하는 스위치 이중화 구성 권장 Disk Array 실제 데이터가 저장되는 스토리지 장치 집합 SAN Storage, 내부적으로 RAID 구성 - RAC에서 모든 노드는 동일한 Disk Array에 동시 접근해야 함. HBA와 FC Switch의 이중화가 필수
- Interconnect(노드 간 네트워크)와 Storage 경로(HBA → FC Switch → Disk Array)는 독립된 별도 경로로 구성해야 성능 간섭 방지 가능
5. RAC 소프트웨어 구성
- RAC를 구성하는 소프트웨어 레이어는 다섯 가지 구성 요소로 분리됨
계층 구성 요소 역할 Clusterware Oracle Grid Infrastructure 클러스터 전체 관리 — 노드 감시 · 리소스 시작/중지 · 장애 복구 스토리지 관리 ASM (Automatic Storage Management) 공유 디스크 그룹 관리 — 미러링 · 스트라이핑 · 자동 재배치 클러스터 메타데이터 OCR (Oracle Cluster Registry) 클러스터 구성 정보 저장 (노드 목록 · 서비스 · 리소스 의존성) 네트워크 가상화 VIP (Virtual IP) 노드 장애 시 클라이언트 접속을 살아있는 노드로 자동 전환 이벤트 알림 ONS (Oracle Notification Service) 노드 장애 · 서비스 재배치 이벤트를 클라이언트에게 즉시 통보 소프트웨어 기동 순서
OHASD (부팅 시 자동 시작) └─ CSS / CRS 데몬 기동 └─ ASM 인스턴스 기동 └─ DB 인스턴스 기동 └─ 리스너 · VIP · ONS 기동- Clusterware는 DB 소프트웨어보다 먼저 설치·기동되어야 함. Grid Infrastructure 설치가 선행 조건
- ONS: JDBC Thin 드라이버가 FCF(Fast Connection Failover)를 사용할 때 의존하는 이벤트 채널. 클라이언트가 노드 장애를 즉시 인지하려면 ONS 활성화 필수
6. RAC 데이터베이스 저장소 구조
- RAC에서 공유 스토리지에 접근하는 방식은 역사적으로 세 가지
방식 설명 현재 권장 여부 CFS (Cluster File System) OS 레벨 클러스터 파일시스템 위에 오라클 파일 배치 비권장 — 추가 OS 레이어 복잡성 Raw Device 파티션을 파일시스템 없이 직접 오라클이 사용 비권장 — 관리 불편, 현대 OS에서 지원 축소 ASM 오라클 전용 볼륨 관리자 + 파일시스템 통합 현재 표준 - ASM은 CFS와 Raw Device의 단점을 동시에 해결. 파일시스템 없이 직접 디스크를 관리하면서도, 오라클 파일 단위로 자동 미러링과 스트라이핑 제공
- 본 실습 환경에서는 ASM 사용
7. RAC 네트워크 구성 — Public · Private · VIP · SCAN
- RAC는 용도별로 분리된 네트워크를 반드시 구성해야 함
네트워크 용도 비고 Public Network 클라이언트 접속 일반 IP (예: 192.168.56.x) Private Network (Interconnect) 노드 간 Cache Fusion · GCS/GES 통신 전용 NIC 분리 권장 (예: 192.168.100.x) VIP (Virtual IP) 노드 장애 시 빠른 접속 전환 노드당 1개, Public과 동일 서브넷 SCAN (Single Client Access Name) 클라이언트 단일 진입점 DNS 또는 /etc/hosts에 3개 IP 등록 - Interconnect: RAC 성능의 핵심. 노드 간 블록 전송이 이 네트워크를 통해 이루어지므로, 대역폭이 낮거나 지연이 크면 성능 저하가 직접 발생
- SCAN: 클라이언트가 노드 IP를 직접 지정하지 않아도 되도록 하는 단일 접속 이름. SCAN Listener가 부하를 각 노드 리스너로 분배
8. 공유 스토리지 구성 — ASM
- RAC에서 모든 노드는 동일한 데이터파일, 컨트롤파일, Redo Log, Undo Tablespace에 동시 접근해야 함
- 이를 위해 공유 스토리지 필수, 오라클 환경에서는 ASM을 표준으로 사용
디스크 그룹 용도 구성 예시 +DATA 데이터파일 · 컨트롤파일 · SPFILE NORMAL 미러링 권장 +FRA 아카이브 로그 · RMAN 백업 NORMAL 미러링 권장 +REDO Redo Log (Thread 별) HIGH 미러링 권장 +OCR OCR · Voting Disk HIGH 미러링 권장 - ASM 인스턴스는 각 노드에서 독립적으로 기동되며, Grid Infrastructure가 관리
- RAC에서 ASM 인스턴스는 DB 인스턴스보다 반드시 먼저 기동되어야 함
9. Clusterware 구성 요소 — OCR · Voting Disk
- Oracle Clusterware: RAC 환경에서 클러스터 전체를 관리하는 소프트웨어 레이어. Grid Infrastructure 설치 시 함께 구성됨
구성 요소 역할 OCR (Oracle Cluster Registry) 클러스터 구성 정보 저장 (노드 목록 · 서비스 정의 · 리소스 의존성) Voting Disk 노드 장애 판단 기준 — Split-Brain 방지를 위한 과반수 투표 CSS (Cluster Synchronization Services) 노드 멤버십 관리, 노드 생존 여부 감시 CRS (Cluster Ready Services) 리소스(DB · ASM · 리스너 · VIP) 시작·중지·재시작 자동화 OHASD (Oracle High Availability Services Daemon) Clusterware 최하위 데몬, 시스템 부팅 시 자동 시작 - Voting Disk는 ASM +OCR 디스크 그룹 안에 저장됨. 노드 수가 홀수일 때 과반수 판단이 명확해지므로 투표 디스크 수도 홀수(3개, 5개)로 구성
- OCR은 OCRCHECK로 정합성 확인, OCRDUMP로 내용을 텍스트 형태로 덤프 가능
10. 전역 자원 관리 — GRD · GCS · GES
- RAC는 전역 자원 디렉터리(GRD) 사용
- 여러 인스턴스가 동일한 데이터에 접근할 때 충돌 없이 관리하는 것이 목적
구성 요소 전체 명칭 역할 GRD Global Resource Directory 모든 데이터 블록의 현재 위치·상태를 추적하는 메타데이터 저장소 GCS Global Cache Services 버퍼 캐시 내 데이터 블록을 노드 간에 일관성 있게 관리 GES Global Enqueue Services 전역 Lock 및 래치를 노드 간에 조율 동작 흐름
[노드1 — 버퍼 캐시] [GRD (모든 노드에 분산)] [노드2 — 버퍼 캐시] 노드2가 블록 요청 → GRD에서 블록 현재 위치(노드1) 확인 → GCS가 노드1에 블록 전송 요청 → 노드1 → Interconnect → 노드2 블록 전달 → GRD 메타데이터 갱신- GRD는 어느 한 노드에 집중되어 있지 않고, 모든 노드의 SGA에 분산됨
- 특정 블록의 GRD 정보가 어느 노드에 있는지를 Master Node라고 함
- Master Node는 블록 요청마다 고정되어 있지 않고, Dynamic Remastering에 의해 자주 접근하는 노드로 자동 이동
11. Object Affinity · Dynamic Remastering
- GRD는 정적으로 고정되어 있지 않음
- 오라클은 블록 접근 패턴을 분석해 GRD 정보를 자동으로 재배치
개념 설명 Object Affinity 특정 오브젝트(테이블, 인덱스)에 대한 접근이 특정 노드에 집중되는 패턴 Dynamic Remastering Object Affinity가 감지되면 해당 오브젝트의 GRD Master를 접근이 집중되는 노드로 자동 이동 동작 효과
[초기 상태] 노드1 → 오브젝트 A의 GRD Master: 노드2 노드1이 오브젝트 A에 반복 접근 → 매번 노드2에 GRD 조회 필요 (3-way 전송) [Dynamic Remastering 발생 후] 오브젝트 A의 GRD Master → 노드1로 이동 노드1이 오브젝트 A에 접근 → 로컬 GRD 조회 (2-way 전송으로 단축)- Dynamic Remastering은 자동으로 동작, DBA가 별도로 설정하지 않아도 됨
- 노드가 장애로 제거되거나 새 노드가 추가될 때는 GRD 전체가 재구성(Reconfiguration)되며, 이 과정에서 Remastering도 리셋됨
12. Cache Fusion
- Cache Fusion: RAC의 핵심 기술. 노드 간에 디스크를 거치지 않고 Interconnect를 통해 직접 버퍼 블록을 전달하는 메커니즘
블록 전송 흐름 비교
전송 유형 흐름 발생 조건 Current Block
(쓰기 목적)보유 노드 → Interconnect → 요청 노드 다른 노드가 해당 블록을 수정하려 할 때 CR Block
(읽기 목적)보유 노드가 CR 블록 생성 → Interconnect → 요청 노드 다른 노드가 읽기 일관성(Read Consistency)이 필요할 때 2-way vs 3-way 전송
방식 흐름 설명 2-way 요청 노드 → Master → 보유 노드 (블록 직접 전달) 블록을 가진 노드가 Master인 경우 3-way 요청 노드 → Master → 보유 노드 → 요청 노드 Master와 보유 노드가 다른 경우, 한 단계 추가 - Cache Fusion이 정상적으로 동작하면 디스크 I/O 없이 노드 간 데이터 공유 가능
- Interconnect 지연이 크거나 Hot Block이 집중되면 gc cr request, gc buffer busy 대기 이벤트 증가
13. Dynamic Reconfiguration
- 노드 장애가 발생하면 Clusterware는 즉시 Dynamic Reconfiguration을 시작해 클러스터 재구성
재구성 단계
1. LMON이 노드 장애 감지 (Heartbeat 미응답) ↓ 2. 생존 노드들이 새 클러스터 구성으로 합의 (Cluster Membership 재확정) ↓ 3. GRD 재구성 — 장애 노드가 보유하던 GRD Master 정보를 생존 노드에 재분배 ↓ 4. 전역 Lock 재배분 — 장애 노드가 보유하던 전역 Lock을 해제 또는 재할당 ↓ 5. 장애 인스턴스 Redo 적용 — 장애 노드의 Online Redo Log를 생존 노드가 읽어 커밋된 트랜잭션 복구 ↓ 6. 서비스 재시작 — CRS가 장애 노드에서 실행 중이던 서비스를 생존 노드로 이전- 3단계~5단계가 완료되기 전까지 해당 데이터 블록에 대한 접근은 일시 대기(freeze) 상태 유지
- Redo 적용(5단계)은 생존 노드가 담당하므로, 장애 노드가 완전히 복구되기 전에 데이터 일관성 보장됨
- 이 과정 전체가 수초~수십 초 이내에 자동으로 완료됨
- 클라이언트는 TAF(Transparent Application Failover) 설정이 있으면 세션을 자동으로 생존 노드로 전환
14. 백그라운드 프로세스
- RAC 인스턴스에는 단일 인스턴스에 없는 RAC 전용 백그라운드 프로세스가 추가됨
프로세스 역할 LMS (Lock Manager Server) GCS 메시지 처리 — 블록 전송 요청 수신 및 응답 (LMS0, LMS1 ...) LMD (Lock Manager Daemon) GES 메시지 처리 — 전역 Lock·래치 관리 LMON 클러스터 그룹 관리 — 노드 장애 감지 및 Dynamic Reconfiguration 수행 LCK 전역 Lock 요청 처리 (Instance Lock) DIAG 인스턴스 상태 진단 및 블록 손상 감지 RMSn 클러스터 리소스 관리 (CRS 연동) - LMS는 인스턴스당 여러 개 기동되며, 노드 간 블록 전송 부하에 따라 자동으로 수가 조정됨
- LMON이 노드 장애를 감지하면 Dynamic Reconfiguration을 시작해 GRD 재구성, 락 재배분, 장애 인스턴스 Redo 적용을 순서대로 수행
15. Row-Level Locking in RAC
- RAC에서 Lock은 단일 인스턴스와 동일하게 행(Row) 단위로 동작하지만, 여러 노드에 걸쳐 조율 필요
항목 단일 인스턴스 RAC Lock 범위 행 단위 행 단위 (동일) Lock 관리 주체 로컬 Lock Manager GES (Global Enqueue Services) Lock 요청 경로 로컬 메모리 내 처리 Interconnect를 통해 GES에 전달 후 조율 Deadlock 감지 로컬 감지 전역 Deadlock 감지 (노드 간 주기적 확인) - 단일 인스턴스와 마찬가지로 DML은 Low Level Lock 사용, 다른 행에 대한 동시 DML을 차단하지 않음
- RAC에서 추가되는 부분은 Lock 요청이 다른 노드에서 왔을 때 GES가 Interconnect를 통해 중재
- 전역 Deadlock은 단일 인스턴스 Deadlock보다 감지 시간이 다소 길 수 있음
- 오라클은 주기적으로 전역 Lock 그래프를 확인해 Deadlock을 탐지하고 자동 롤백
16. 메모리 요구사항
- RAC에서는 GCS/GES 구조를 위해 단일 인스턴스보다 더 많은 메모리 필요
메모리 영역 단일 인스턴스 대비 추가 필요량 이유 Shared Pool 약 15% 추가 GCS/GES 메타데이터, 전역 락 정보 저장 Buffer Cache 약 10% 추가 추가 CR 블록 보관, 노드 간 블록 이동 준비
핵심 요약
주제 핵심 포인트 RAC 구조 N개 인스턴스 — 1개 DB, Active-Active 구성 SMP vs RAC SMP는 단일 서버 Scale-up, RAC는 다중 서버 Scale-out Scale-out 노드 추가로 처리 용량 확장 — 하드웨어 천장 없이 단계적 확장 가능 I/O 구성 HBA → FC Switch → Disk Array 경로, Interconnect와 독립 구성 필수 RAC 소프트웨어 Clusterware · ASM · OCR · VIP · ONS 구성 요소별 역할 분리 Storage 방식 CFS · Raw Device는 비권장, ASM이 현재 표준 네트워크 Public / Private(Interconnect) / VIP / SCAN 용도별 분리 필수 공유 스토리지 모든 노드가 동일 ASM 디스크 그룹에 동시 접근 OCR 클러스터 구성 정보 저장소, ASM +OCR에 위치 Voting Disk 노드 장애 판단 기준, Split-Brain 방지, 홀수 개 구성 GRD 전역 자원 디렉터리 — 블록 위치·상태 추적 메타데이터 GCS 노드 간 버퍼 블록 일관성 관리 GES 노드 간 전역 Lock · 래치 조율 Object Affinity 특정 노드에 접근이 집중된 오브젝트 패턴 Dynamic Remastering GRD Master를 접근 집중 노드로 자동 이동 — 3-way → 2-way 전송 단축 Cache Fusion Interconnect를 통한 블록 직접 전달 — 디스크 I/O 없이 노드 간 공유 Dynamic Reconfiguration LMON 감지 → GRD 재구성 → Lock 재배분 → Redo 적용 → 서비스 이전 LMS GCS 처리 핵심 프로세스 — 블록 전송 요청 수신 및 응답 LMON 노드 장애 감지 및 Dynamic Reconfiguration 수행 Row-Level Locking RAC도 행 단위 Lock — 전역 조율은 GES가 Interconnect로 처리 메모리 단일 인스턴스 대비 Shared Pool +15%, Buffer Cache +10% 추가 필요 'DB 스터디 > 04_RAC' 카테고리의 다른 글
RAC 05: RMAN 백업 & Recovery — Catalog 서버 구축 · 인스턴스 장애 복구 (0) 2026.07.02 RAC 04: RAC 파라미터 · SPFILE · Redo · UNDO 관리 (0) 2026.06.19 RAC 03: Clusterware 관리 — crsctl · srvctl · OCR · 로그 분석 (0) 2026.06.18 RAC 02: 2 Node RAC 구축 — VM 환경 준비 & Grid 설치 (0) 2026.05.20