DB 이중화 / 클러스터링

DB 클러스터링

• DB 장애 시 가용성을 유지하기 위한 클러스터링 방안
• Oracle 기준이긴 하지만, 다른 DB에서도 비슷한 옵션이 있는 경우 있음.
• 크게 두 축으로 분류할 수 있다.
  • IDC 내 이중화 : 같은 데이터센터 내에서 가용성·부하 분산 목적. storage 공유 기반.
  • IDC 간 이중화 : 서로 다른 데이터센터(사이트) 간 재해 복구(DR) 목적. storage 분리 + redo 기반 동기화.
• 실무에서는 각 IDC에 RAC를 두고, IDC 간을 ADG로 연결하는 하이브리드 구성이 일반적이다.

IDC 내 이중화

• 같은 IDC 내에 instance를 여러 개 두고 하나의 storage를 공유하는 방식.
• InterConnect(저지연 사설망)가 필수이므로 거리 제약이 크다 → 원거리 IDC 간에는 적합하지 않음.
• 주 목적은 부하 분산 + 인스턴스 단위 장애 대응.

OPS ( Oracle Parallel Server )

• storage는 하나만 두고, 오라클 인스턴스를 instance1, instance2 두개로 띄우는 방법
• instance 하나에서 장애 발생 시 다른 instance 통해 접근하면 된다.
• 문제점 RAC ping?
  • instance1 에서 commit한 데이터가 instance2에 보이려면 일단 storage에 저장되고, 저장된 데이터를 instance2에서 복사해가야 함.
  • 따라서 변경 사항이 instance2에 적용되기까지,디스크에 쓰고 가져오는 작업이라 딜레이가 좀 있음.

*** 오라클 9i 부터는 이를 개선한 RAC 사용

RAC ( Real Application Cluster )

• storage는 하나만 두고, 스토리지를 관리하는 오라클 인스턴스를 여러개 두는 것은 OPS와 동일.
• 다만 다른 instance에서 변경한 데이터를 스토리지 저장, 복사 과정 없이 instance 끼리 바로 동기화 할 수 있는 Cache Fusion 지원
• InterConnect : Private network로 instance 끼리 연결하여 동기화
• fail 되었을 때 다른쪽 node로 넘어가야 하기 때문에, 양쪽 노드 CPU 사용률 합이 100%가 넘어가면 RAC의 의미가 없다.
• Extended RAC로 IDC 간 구성도 가능하나, 거리·네트워크 지연 제약이 커서 일반적으로 RAC는 단일 IDC 내에 구성한다.

[!warning] 반드시 2개 node에 부하를 분산 하는 것이 좋은가? 하면 꼭 그렇지는 않다. 같은 데이터를 RAC 양쪽 노드가 같이 사용하는 상황에서는 global cache lock 이 더 빈번히 발생할 수 있다.

LB, failover 방식

• (11g 이상) SCAN 리스너
  • connection string에 node의 IP를 구분해서 입력하게 되면 fail 되었을 때 다른쪽 node로 넘어가지 못하기 때문에, SCAN이라는 RAC의 단일 진입점의 IP를 입력해서 사용하게 된다.
• (11g 미만)node 1, 2 IP를 connection string을 다 입력해두고, Client-side에서 load balancing한다.
  • node 별로 service를 나눠 실행하기 때문에, 1번 IP로 접속 시도해보고, 해당 service_name이 1번 IP에서 실행중이지 않다면 2번 IP로 접속해보고… (반복)

RAC는 service를 실행할 때 node 별로 나눠서 실행한다.

RAC 클러스터
├─ node1
│  ├─ SERVICE_A (preferred) ✓ 실행 중
│  └─ SERVICE_B (available)  대기
│
└─ node2
   ├─ SERVICE_A (available)  대기
   └─ SERVICE_B (preferred) ✓ 실행 중

IDC 간 이중화

• 서로 다른 IDC(사이트)에 Primary / Standby DB를 두고, 별도 storage를 가진 채 redo log 전송으로 동기화하는 방식.
• 주 목적은 재해 복구(DR). 한 IDC 전체 장애 시 다른 IDC로 서비스 전환.
• storage를 공유하지 않으므로 거리 제약이 작고, 원거리 IDC 간에도 구성 가능.

HA ( High Availability ) / Data Guard

• 같은 장비를 Active 1대 , Standby 1대로 구성해서 Active에 문제 생기면 Standby로 서비스 하는 방식.
• Active, Standby 각자가 별도 storage를 가지고 있음. => Active와 Standby의 데이터 동기화 문제 및 성능 저하 => Active 가 죽고 Standby로 전환되기 전 그 사이에 발생하는 트랜잭션은 유실됨 - 데이터 불일치. 정합성 bad

*** 오라클에서는 데이터 가드 라는 이름으로 제공하고 있다. *** (참고) 위와 같은 storage 분리 방식의 한계 때문에, IDC 내 이중화로는 storage 공유 방식인 OPS / RAC가 발전해왔다.

ADG ( Active Data Guard )

• Oracle의 Data Guard를 확장한 옵션으로, Standby DB를 read-only로 open한 상태에서 redo log를 실시간으로 적용(Redo Apply)하는 방식.
• 기존 Data Guard의 Standby는 평소에 mount 상태로만 대기하다 장애 시에만 open 되었지만, ADG는 평시에도 standby를 읽기 전용으로 활용할 수 있다.
• Primary → Standby로 redo를 전송(Redo Transport) 후 Standby에서 적용(Redo Apply) 하므로, Primary와 Standby 간 데이터가 거의 실시간으로 동기화된다.
  • 동기화 모드에 따라 데이터 유실 가능성/성능 trade-off 존재
    • Maximum Protection : 동기 전송, 데이터 유실 0. Standby 장애 시 Primary도 중단.
    • Maximum Availability : 동기 전송이 기본이나, Standby 장애 시 비동기로 전환하여 Primary는 계속 서비스. 데이터 유실 0에 수렴.
    • Maximum Performance (default) : 비동기 전송, Primary 성능 우선. 일부 데이터 유실 가능.
  • IDC 간 거리가 멀어 네트워크 지연이 큰 경우 동기 전송은 Primary 성능에 영향을 주므로 보통 Maximum Performance(비동기)로 운영.
• 주요 활용
  • 읽기 부하 분산 : 조회성 트래픽(리포팅, 통계, 백업 등)을 Standby로 오프로딩하여 Primary 부담 감소.
  • DR (Disaster Recovery) : 물리적으로 떨어진 사이트에 Standby를 두어 재해 복구 용도로 사용.
  • Switchover / Failover : 계획된 전환(Switchover) 또는 장애 시 자동 전환(Failover, Fast-Start Failover)으로 가용성 확보.
• RAC와의 차이
  • RAC는 하나의 storage를 공유하는 다중 instance 구조(Active-Active, IDC 내 부하 분산 + 가용성).
  • ADG는 별도 storage를 가진 별개의 DB를 redo 기반으로 동기화(Active-Standby, IDC 간 DR + 읽기 분산).
  • 실제 운영 환경에서는 RAC + ADG를 함께 구성해서 IDC 내 가용성과 IDC 간 재해 복구를 모두 확보하는 경우가 많다.

참고

https://12bme.tistory.com/322완전 상세하게 나와 있음.