DB 이중화 / 클러스터링

DB 클러스터링

• DB 장애 시 가용성을 유지하기 위한 클러스터링 방안
• Oracle 기준이긴 하지만, 다른 DB에서도 비슷한 옵션이 있는 경우 있음.

HA ( High Availability )

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

*** 오라클에서는 데이터 가드 라는 이름으로 제공하고 있다. *** 위와 같은 문제점 때문에 OPS 방식이 8i 버전까지 사용되었음.

OPS ( Oracle Parallel Serve )

• 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의 의미가 없다.

[!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) ✓ 실행 중

참고

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