RAC 구성

물리적인 아키텍처로서의 RAC 구성

• Public Network : 개별 클라이언트 프로그램들은 Public Network를 통해서 오라클 인스턴스와 통신한다. 대부분의 통신은 SQL*Net을 통해서 이루어진다.

• Private Interconnect : 각 노드의 인스턴스들은 Private Interconnect를 통해서 서로 통신한다. Gigabit 이더넷과 UDP 프로토콜을 사용하는 것이 가장 전혀억인 구현 방법이다. 또한 Switch를 통해 인터커넥트를 연결한다. 완벽한 HA(High Availability)를 구현하려면 스위치가 제공하는 Fail Over기능이 필수적이다.

• Oracle Instance : 각 노드에는 하나의 오라클 인스턴스가 기동된다. 각 오라클 인스턴스는 Private Interconnect를 통해서 메시지와 블록을 교환한다. 만일 ASM을 사용한다면 ASM이느턴스가 추가로 기동된다.

• Storage : 여러 노드가 데이터를 공유하기 위해서 공유 스토리지(Shared Storage)를 사용한다. 일반적으로 SAN(Storage Area Network)를 많이 사용하며, 각 노드는 SAN 스위치를 통해 스토리지와 통신한다. 공유 스토리지에서 오라클 파일을 공유하기 위해 Raw Device, 클러스터 파일 시스템(Cluster File System), ASM 등과 같은 파일 디바이스 혹은 파일 시스템을 사용한다.

논리적인 아키텍처로서의 RAC 구성

• RDBMS Instance + Background Process : RDBMS를 구성하는 오라클 인스턴스와 백그라운드 프로세스들의 모임을 말한다. 백그라운드 프로세스는 SMON, PMON 프로세스와 같은 전통적인 백그라운드 프로세스들뿐만 아니라 LMON, LMD, LMS, LCK 프로세스와 같은 RAC 전용 백그라운드 프로ㅔ스들을 포함한다.

• CRS(또느 Clusterware) : 각 노드의 구성과 멤버십을 관리하는 서비스와 프로세스의 모임을 말한다. 오라클 10g부터는 오라클은 독자적인 클러스터 서비스를 제공하며, CRS(10g R1) 또는 Clusterware(10g R2)라고 부른다.

• OS(+Cluster Service) : RAC 시스템은 OS가 제공하는 각종 서비스를 필요로 한다. 또한 대부분의 OS들이 개별적인 클러스터 서비스를 제공한다. IBM AIX는 HACMP(High Availability Cluster Multiprocessing), HP-UX는 Service Guard, Sun OS는 Sun Cluster라는 이름의 클러스터 서비스를 제공한다. 이들 클러스터 서비스가 별도의 비용을 필요로 하지만, 여러가지 펴리한 기능을 제공하기 대문에 많은 경우 오라클의 CRS(Clusterware)와 OS의 클러스터 서비스를 같이 사용한다.

• ASM Instance + Background Process : ASM(Automatic Storage Management)을 사용하는 경우에는 RDBMS 인스턴스 외에 ASM 인스턴스가 추가로 필요하다. 오라클 10g 이전에는 오라클 인스턴스는 단 한 종류, 즉 RDBMS 인스턴스 뿐이었다. 오라클 10g 붙는 ASM 인스턴스가 추가되었기 대문에, 이제 오라클 인스턴스는 RDBMS 인스턴스와 ASM 인스턴스로 구분된다. ASM은 ASM 인스턴스와 여러 개의 백그라운드 프로세스들로 구성된다.

데이터 아키텍처로서의 RAC 구성

• GRD : Global Resource Directory. RAC를 구성하는 각 인스턴스들은 개별 자원들에 대한 메타 정보를 GRD에 관리한다. GRD는 일종의 분산 메모리 뎅터베이스로 이해할 수 있다.

• Global Cache : RAC 시스템은 개별 인스턴스의 버퍼 캐시(Buffer Cache)를 통합해서 마치 하나의 글로벌 캐시(Global Cache)처럼 제공한다. 사용자는 현재 특정 블록이 어떤 인스턴스의 버퍼 캐시에 있느니 알 필요가 없으며, 모든 캐시 통합은 오라클의 캐시 퓨전 매커니즘에 의해 자동으로 이루어진다.

• Shared Storage : 오라클은 공유 스토리지를 이용해 데이터를 공유한다. 공유 스토리지에는 다음과 같은 데이터들이 저장된다.
  • OCR : Oracle Cluser Registry. 클러스 구성에 필요한 모든 메타정보를 관리하는 일종의 데이터베이스 파일
  • Voting Disk : 각 노드의 멤버십을 관리하는데 사요되는 파일. 오라클은 클러스터 환경에서 발생 가능한 Split Brain 현상을 피하기 위해 Voting Disk를 사용한다.
  • Redo Log : RAC에서 각 노드는 별개의 리두 로그 (Redo Log)를 사용하지만, 리두 로그는 반드시 공유 스토리지에 위치해야 한다. 노드 장애(Node Failure)가 발생했을 때 해당 노드의 리두 로그를 읽어서 복구를 수행해야 하기 때문이다.
  • Data file : 데이터 파일은 각 노드 간에 완벽하게 공유된다. 즉 각 노드들은 동일한 데이터 파일을 읽고 쓰게 된다.
  • Control File : 오라클 데이터베이스 컨트로 ㄹ파일 또한 노드 간에 공유된다.
    {info:title=Split Brain}
    Split Brain은 원래 의학 용어로, 좌뇌와 우뇌간의 연결에 이상이 생기는 현상을 말한다. 클러스터 시스템에서의 Split Brain은 말 그대로 각 노드간의 연결에 이상이 생겨 노드간의동기화가 이루어지지 앟는 것을 말한다. Split Braint 현상이 발생하면 각 노드가 서로의 존재를 무시한 채 독립적으로 작업을 하므로 공유 자원의 정하성이 깨지는 현상이 발생할 수 있다. 이 때문에 현존하는 모든 클러스터 솔루션들은 Split Brait을 피할 수 있는 다양한 기법들을 제공하며, 오라클 또한 예외가 아니다.
    {info}

출처 : Advanced OWI, Internals and Performance in Oracle 10g RAC