HA와 OPS 그리고 RAC란?

- HA

- OPS

- RAC

- Cache fusion

- Interconnect

일반적으로 DB서버를 구현 할 때는 1개의 서버를 사용한다. 

그러나 이런 방식은 Instance 역할을 하는 서버에 장애가 발생했을 때 

Storage에 저장된 데이터를 사용할 수 없게 되는 위험이 늘 존재한다.

이런 문제를 대비하기 위해 HA구조가 등장!

HA?

HA구성이란 High Availability의 약자로 고가용성이란 뜻이다.

이름 그대로 서버의 사용 가능시간을 최대한 늘이는 것이 목표인 서버 구성방법. 두 대의 서버를 동일하게 구성해서 서버 1대는 Active로 두고 서버 1대는 Standby 로 설정해서 만약 Active 상태의 서버가 장애가 발생 할 경우 Srandby 상태의 서버가 즉시 Active 상태로 바뀌여서 투입되어 서비스 중단이 발생하지 않도록 조치되는 구성.

오라클에서는 Dataguard방식이 위 설명과 같은 HA구성 방식이다.

그러나 이런 HA방식이 가지는 다양한 문제가 있어서 

Oracle에서는 HA방식을 한 단계 더 발전시킨 OPS라는 방식을 도입

OPS?

OPS(Oracle Parallel Serve)라는 방식이란 평소에는 사용자들이 Instance 1과 Instance 2를 통해서 데이터가 저장된 Storage에 접근해서 데이터를 조회, 변경 등의 작업을 수행하는데 Instance 1에서 장애가 발생할 경우 남아 있는 Instance 2를 통해서 Storage에 접근 가능하기 때문에 서비스가 중단되는 경우를 예방. 서비스의 중단시간을 획기적으로 개선한 HA을 구현하는 대표적인 방법이다.

HA와 OPS의 차이점 : 

OPS는 앞서 언급한 HA의 문제점을 보완한 방식이다.

Stanby로 준비해둔 서버는 장애가 발생하지 않는한 이용률은 제로에 가깝다. 

Stanby는 한가로운데 비해 Active 서버는 부하가 발생한다. 이런 비효율적인 부분을 개선하였다.

OPS방식은 하나의 Storage 서버에 두개의 Instance Server를 두는데 두 서버를 모두 Active로 만들어서 부하를 분산시킨다.

HA방식에서 Active에서 장애가 발생하면 기존의 서비스는 모두 취소되고 Stanby로 서비스를 넘긴다. 

그러나 OPS 에서는 CTF, TAF라는 설정을 통해 기존 서버에 장애가 발생할 경우 해당 작업을 그대로 다른 서버로 넘길수 있다.

HA 방식의 문제점은 각 서버별로 Storage를 가지고 있기 때문에 데이터의 동기화 문제도 발생한다. 즉 Active sever에 의해 변경된 작업이 Stanby sever에 반영되지 못한 경우 데이터의 불일치 문제가 생길수 있다. 따라서 OPS는 1개의 Storage를 공유해서 사용하기 때문에 데이터의 동기화 문제는 발생하지 않는다.

HA는 Active 상태와 Srandby 상태로 구분되어 두개의 서버로 구성되지만 하나의 서버에서만 구동되는 반면,

OPS나 RAC는 모든 노드가 Active 상태로 동작하기 때문에 이론적으로 서버수의 제한이 없고 확장이 가능하다는 장점이 있고, 부하가 분산됨으로 속도가 빨라질 수 있다.

하지만 OPS에서도 *RAC ping이라는 문제가 발생해서 심각한 성능저하가 발생한다. 

* RAC Ping 

PAC Ping 이란 Instance 1에서 데이터를 변경하고 완료 했을때 그 내용을 Instance 2가 조회한다면 

Instance 1의 변경내용은 반드시 디스크(storage)에 저장한 후에 Instance 2로 복사해 올 수 있다. 

이런 과정이 디스크를 사용해서 시간이 오래 걸리기 때문에 OPS 환경에서 RAC Ping 작업은 성능 저하의 주요 원인으로 지적된다.

어떤 Instance 에서 변경된 데이터를 다른 Instance 에서 참조하기 위해서는 Disk로 저장 한 후 다시 불러와야 하는 것이다. 

이때 지연이가 발생한다.

이러한 RAC ping 현상을 해결한 것이 9i 부터 등장한 RAC(Real Application Cluster)이다.

8i 까지는 OPS

9i 부터는 RAC 

RAC?

RAC(Oracle Real Application Clusters)는 Instance 1과 Instance 2를 연결하는 *Interconnect라는 특징이 생김. Interconnect는 디스크를 거치지 않고 메모리의 데이터를 Interconnect를 통해서 즉시 서로 교환하는 구조로 설정된다.

그래서 Instance 1에 있는 데이터와 Instance 2에 있는 데이터를 서로 즉시 볼 수 있기 때문에 

이 기능을 Cache Fusion( 캐쉬 퓨전 )이라고 부른다.

오라클 RAC을 사용하면 여러 대의 컴퓨터가 동시에 한 대의 DBMS 서버에 접속하여 데이터를 이용할 수 있다. 

이를 이용해 DB 클러스터링을 구현할 수 있다. 

Cache Fusion?

Oracle 9i 버전부터는 서로 다른 Instance 에서 변경된 데이터를 디스크를 거치지 않고 바로 Instance로 가져올 수 있는 기능인 Cache Fusion (캐시 퓨전) 이라는 기능이 사용된다.

Cache Fusion 기술이 도입되면서 사용자가 어떤 물리적인 Instance에서 작업하는가는 자연스럽게 중요하지 않게 된다.

여러 Instance를 마치 하나의 서버처럼 만들어버리기 때문에 이것이 가능한데 이런 역할을 해 주는 것이 *클러스터용 소프트웨어라고 한다.

* 클러스터용 소프트웨어 

캐시퓨전 기능을 가능하게 해주는 프로그램을 클러스터용 소프트웨어라고 한다.

여러 인스턴스에서 데이터가 조회되고 변경되어도 무결성이 유지되도록 관리해주며 각 인스턴스간에 생기는 변동사항을 조정하고 관리해주는 역할을 한다. 

이전에는 클러스터 프로그램을 오라클이 직접 만들지 않았다 10g R1버전부터 클러스터용 프로그램을 오라클에서 직접 만들어 제공하기 시작하였다.

10g R1에서는 CRS (Cluster Ready Service)

10g R2 버전부터는 Clusterware

11g 에서는 ASM기능이 통합되어 grid라는 명칭으로 변경되었다.

캐시퓨전은 서로 독립적인 인스턴스를 마치 하나의 인스턴스인것 처럼 데이터의 교환이 이루어지면서 섞여 있다라는 의미로 해석할 수 있을것 같다. 

자세하게 살펴보면,

RAC에서는 어떤 Instance에서 작업을 해도 하나의 서버에서 작업을 하는 것과 같은 효과를 내게 되는데,

이런 것을 가능하게 해 주는 것이 RAC의 대표적인 서비스 GES, GCS 

GES (Global Enqueue Service) 란,

어떤 Instance 에서 데이터 변경작업 ( 트랜잭션 ) 을 하든 하나의 Instance 에서 데이터 변경 작업을 하는것과 같이 관리하는 기능

GCS (Global Cache Fusion) 란,

Cache Fusion 기능이 구현되기 위한 필수 서비스로서 어떤 사용자가 자신의 Instance 에서 원하는 데이터를 찾지 못해서 다른 Instance 에 있는 데이터를 요청했을 때 Insterconnect 를 통해서 데이터를 전달해 주는 서비스를 말함

GCS 에서는 데이터 블록을 전송하고 관리할 때 아래의  3가지 모드로 구분함 

  - Null (N) 모드 : 해당 블록을 사용중인 사용자가 없다는 것을 뜻함

  - Share (S) 모드 : 해당 블록을  select 하고 있는 세션이 있다는 뜻함

  - Exclusive (X) 모드 : 해당 블록을 누군가가 변경하고 있다는 뜻함

Interconnect?

interconnet는 인스턴스간의 데이터 교환을 직접적으로 할 수 있도록 연결해준다.

따라서, interconnet가 있어서 cache fusion이 가능하다.

앞에서 살펴본 예에서 알 수 있듯이 RAC의 핵심 기능인 Cache Fusion이라는 특징 때문에 블록들이 이동하는 길인 Interconnect가 RAC 전체 성능에 아주 중요한 역할을 하게 된다.

Interconnect를 통해 이동하는 정보는 크게  Clusterware 가  Cluster를  유지하고  운영하기 위해 사용하는 정보와 실제 데이터 블록, Parallel Query 관련 정보들이 있다. 

일반적으로  Cluster를 유지하고 운영하는 정보인  GCS/GES 관련 정보는  256 bytes 정도로 아주 작지만  실제  데이터  블록은  DB_BLOCK_SIZE ( 10g/11g  기준으로  기본  크기는  8k )나  Non-Standard Block Size 의 크기로 GCS/GES 정보에 비해 아주 크다.

그리고 Parallel Query 관련 정보는 Parallel_Execution_message_size 에 의해 크기가 결정되는데 기본크기는 8k로 설정되어 있다. 

이런 내용들이 얼마나 자주 왕래하느냐가 성능에 아주 중요한 영향을 주게 되며 당연히 가급적이면 이동하는 양을 줄이는 것이 튜닝에 아주 핵심적인 관점이 된다.

그래서 RAC 튜닝에서 Interconnect의 사용량을 측정하여 튜닝하는 것이 아주 자주 언급이 됩니다. 

즉, Interconnect를 사용하는 량을 줄이거나, Interconnect의 속도를 높이는 것이 RAC 튜닝에서 아주 중요하다.