Oracle RAC 개념
Oracle RAC는 여러 개의 Instance가 하나의 Database를 엑세스 할 수 있다. 이는 application에서 접속할 수 있는 통로는 여러 개이며 Database는 하나인 형태이다.
Oracle RAC = N개의 Instance + 1개의 Database
그리고 RAC로 연결된 N개의 Instance에서 동일한 Datafile을 공유하여 엑세스한다. 하지만 Database 작업에 사용할 수 있는 CPU나 메모리 등의 Resource는 서로 공유하지 않으며 해당 Node의 Resource만을 사용한다.
Cluster
두 개 이상의 독립된 서버들과 Disk를 하나로 연결하는 기법이다. 사용자가 Cluster로 구성된 서버들 중 어느 서버에 접속해도 동일한 Disk를 엑세스하게 되므로 하나의 서버 또는 하나의 Disk에 연결하는 것처럼 인식한다.
Oracle RAC는 Oracle Clusterware를 사용하여 어느 Instance에 접속하여도 사용자에게 동일한 data를 실시간으로 조회, 변경할 수 있는 기능을 제공한다. 또한 Oracle Clusterware를 사용하면 높은 처리량과 고가용성을 보장할 수 있다.
Clusterware의 자세한 특징은 다음에 설명하도록 하겠다.
단일 Instance vs Oracle RAC
단일 Instance 환경에서와 마찬가지로 Oracle RAC 환경의 각 Instance에는 각자의 SGA와 백그라운드 프로세스가 존재한다. 그러나 모든 Datafile과 Control File은 모든 인스턴스에서 동일하게 엑세스할 수 있어야 하므로 공유 Storage에 위치해야 한다.
그리고 각 Instance에는 고유한 Online Redo Log File이 존재한다. Online Redo Log File은 자신이 속한 Instance에 의해서만 기록될 수 있다. 그러나 online redo log file도 인스턴스 복구 시에는 다른 인스턴스에서 엑세스할 수 있어야 한다. 따라서 Online Redo log file도 공유 storage에 저장되어야 한다(redo log group을 공유하고, redo log file에 쓰는 것은 개별적으로 쓴다).
*Data 정합성
Oracle RAC 환경의 Instance는 여러 Instance에서 동시에 동일한 data를 엑세스하는 구조로 data를 공유한다. 동일한 data를 여러 인스턴스가 읽어도 문제는 없지만, 동일한 data에 대해 여러 인스턴스가 동시에 수정, 삽입 등을 하는 경우 data 무결성 문제가 발생할 수 있다. 그래서 Oracle RAC은 Cache lock과 Cache Fusion 등을 사용하여 이를 보장한다. 자세한 것은 다음에 설명하겠다.
Oracle RAC 구성요소
Oracle Grid Infrastructure
Oracle RAC는 Grid Infrastructure에서 제공하는 Oracle Clusterware의 기반하에 여러 Database 서버를 묶어서 하나의 시스템처럼 동작하도록 지원한다.
*GI는 Oracle Custerware 및 ASM으로 구성되며 운영체제와 긴밀하게 통합된 소프트웨어 계층이다.
- Clusterware 설치 : RAC 구성을 위해 필요한 소프웨어이며 오라클 설치 계정 이외 별도의 계정을 생성하여 설치하는 것을 권장한다.
- Clusterware의 OS 계정 : 일반적으로 GI와 ASM을 소유하는 전용 OS 계정인 grid 계정을 사용한다.
공유 Storage
각 Instance는 공유 Storage를 통해 물리적인 data를 공유하며 database에서 사용하는 ASM 및 CFS(Cluster File System)를 구성한다.
공유 Storage에서 Database File은 모든 Node에 동등하게 동시에 엑세스할 수 있어야 한다. 물론 Storage에서 생성된 Disk는 공유 모드가 활성화 되어야 한다.
Oracle RAC Network 구성 요소
- Public IP
각 Node에 대한 고유한 IP로 서버 주소와 동일하다. 일반적으로 Node 관리 목적으로 사용된다.
- Service IP
클라이언트에서 Database 서버의 Public IP를 사용하여 접속할 경우 장애가 발생한 Node에서 세션을 다른 Node로 옮기는데 많은 시간이 걸릴 수 있다. 이때 VIP(Virtual IP)를 사용하여 클라이언트가 node에 장애가 발생했다는 것을 신속하게 인식할 수 있도록 함으로써 다른 Node로 재연결 시간을 향상시킬 수 있다.
- SCAN(Single Client Access Name)
GNS 및 DNS를 사용하여 정의할 수 있다. SCAN을 이용할 경우 Cluster 내 서버 수에 관계없이 Load balancing 및 고가용성을 고려하여 3개의 IP 주소를 권장한다.
- Private IP(Cluster Interconnect)
Cluster Node 별 통신을 위한 IP로 다음과 같은 목적으로 사용한다.
-Resource 동기화를 위해 Cluster에서 Heartbeat 프로세스를 위해서 사용하는 통신 경로
-Instance에서 다른 Instance로 data를 전송(cache fusion)하는 용도로 사용
오라클 RAC DB에서 Fail Over 를 얘기할 때 나오는 용어가 CTF, TAF, SCAN
기본적으로 RAC(Grid 또는 Cluster 라고도 함)를 설치하게 되면 CTF 와 SCAN 은 기본으로 세팅되어 있습니다.
TAF 정도만 신경써서 추가적으로 세팅해주면 됩니다.
* CTF : Connection Time Failover
- 클라이언트에서 RAC DB로 접속을 시도했으나, 해당 DB서버가 장애가 발생하여 접속이 안되는 경우,
일단 에러를 받고, 다음 접속할 때 다른 살아있는 DB서버로 자동 접속시켜주는 기능.
* TAF : Transparent Application Failover
- 위 CTF 설정에 추가적으로 몇줄 더 세팅해주면 되는데, CTF가 일단 에러를 받는 것과 달리 TAF는 에러를 받지 않고,
다른 살아있는 DB서버로 Failover 해줍니다. 마치 장애가 발생하지 않은 것처럼...
- TAF 는 Client Side 방식과 Server Side 방식이 있습니다.
* SCAN : Single Client Access Name
- SCAN 도 CTF 처럼 동작하기는 하지만, 출생목적이 좀 다릅니다.
- SCAN 은 여러 RAC 노드(DB서버)를 하나의 서버인양 느끼도록 공용(공통) Name (IP)을 사용하도록 해주는 기능입니다.
- 그래서 사용자는 SCAN IP 로 접속하면 이걸 다시 1번 RAC Node 로 접속시켜주고, 1번노드에 문제가 생기면 2번노드로 접속시켜주는 방식입니다. 위 CTF 와 비슷
- 차이점은 CTF는 클라이언트쪽에 RAC DB 노드의 모든 IP를 기술해줘야 하고, SCAN 의 경우는 클라이언트쪽에 Scan IP 한개만 기술해주면 됩니다. 즉, RAC 노드가 8개서버로 되어 있다면, CTF/TAF의 경우에는 Tnsnames.ora 파일에 8개의 IP Address 를 기술해줘야 하는데, SCAN의 경우에는 달랑 1개의 IP 만 기술하면 된다.
Oracle Kernal 구성 요소
오라클 커널의 구성요소는 RAC database의 각 인스턴스에 대한 추가 백그라운드 프로세스의 집합(GRD, GCS, GES)이다.
- Database : 데이터를 저장하고 있는 창고의 역할
- Instance : 창고의 데이터를 가져와 작업하는 작업장
하나의 Database 에 여러개의 Instance 로 구성하는 방식을 RAC (Real Application Cluster) 라고 합니다.
8i 까지는 OPS (Oracle Parallel Server) 라고 하였음
- HA 구성: High Availability , 서버의 사용 가능 시간을 최대로 늘리는 것이 목표인 서버 구성방법
HA 는 하나는 Active, 나머지 하나는 Standby 상태
- OPS 는 하나의 Storage 를 공유해서 사용하며, Interconnect 가 없다
- RAC Ping 현상: Instance 1에서 변경 완료 된 데이터를 Instance 2 로 가져오기 위해 우선 디스크에 저장 후
해당 데이터를 Instance 2 로 복사해오는 작업
성능에 문제가 생긴다.
- Cache Fusion (캐쉬 퓨전): Interconnect 을 통해 Instance 1과 2 를 연결하여 디스크를 거치지 않고 데이터를 교환하는 것
클러스터용 소프트웨어: 캐쉬 퓨전을 해주는 것
오라클 10g R1 부터 오라클 사에서 만들어서 제공
10g R1 : crs
10g R2 부터 Clusterware (클러스터웨어) 라고 부름
11g : ASM 기능 통합으로 grid 라는 명칭으로 변경
무결성 유지 관리 기능
rac는 spfile 쓰는 걸 권장 (dynamic sga)
10g asm도 vote, ocr 는 반드시 raw device 에 넣어야 한다.
11g 부터는 asm 안에 ocr, vote 다 들어간다.
ocr 는 registry 같은 기능, 자원관리
vote 는 서버가 살아있나 죽었나 체크
- OCR (Oracle Cluster Repository) : RAC 구성 전체 정보 저장하고 있는 디스크
(11g 에서는 ASM 디스크 사용 가능)
별도의 Raw Device 구성해서 저장
오라클에서 권장하는 OCR 의 최소 크기는 100 MB
- Vote Disk : 각 Node 들이 장애가 있는지 없는지를 구분하기 위해서 사용하는 일종의 출석부 같은 역할
- cssd 프로세스 : 각 Node 들이 정상적으로 작동하고 있는지 Interconnect 를 통해 매 초마다 heartbit 를 보내고,
각 Node 들은 그에 대한 응답을 보내어 자신이 정상적으로 작동하고 있다고 알려준다.
응답이 없다면 cssd 는 2차로 vote disk 를 확인한다.
오라클에서는 vote disk 의 최소 크기는 20 MB 로 3개로 다중화해서 구성하기를 권장한다.
Cache Fusion 이란?
RAC 에서는 어떤 Instance 에서 작업을 해도 마치 하나의 서버에서 작업을 하는 것과 같은 효과를 내게 되는데
이런 것을 가능하게 해주는 RAC 의 대표적인 서비스 두가지가
GES (Global Enqueue Service) ,
GCS (Global Cache Service) 입니다.
GES 란 어떤 Instance 에서 데이터 변경작업 (트랜잭션) 을 하던 하나의 Instance 에서 하는 것처럼 관리하는 기능
GCS 란 Cache Fusion 기능이 구현되기 위한 필수 서비스로서 어떤 사용자가 자신의 Instance 에서 원하는 데이터를 찾지 못해서
다른 Instance 에 있는 데이터를 요청했을 때 Interconnect 를 통해서 데이터를 전달해 주는 서비스를 의미
Interconnect 속도가 관건
gigabit
infiny band
GCS 에서 데이터 블록을 전송하고 관리할 때 3가지 모드로 구분
1) Null (N) 모드 - 해당 블록을 사용 중인 사용자가 없다는 것을 뜻함
2) Share (S) 모드 - 해당 블록을 Select 하고 있는 세션이 있다는 뜻
3) Exclusive (X) 모드 - 해당 블록을 누군가가 변경하고 있다는 뜻
Share 모드는 여러 Instance 에서 동시에 공유해서 사용 가능
1건의 데이터를 여러 Instance 에서 동시에 select 할 수 있다는 뜻
X 모드는 반드시 1개의 Instance 에서만 사용할 수 있습니다.
특정 데이터에 대한 모드를 관리하는 Instance 를 Master node 라고 부른다.
Hasing 알고리즘을 이용해서 랜덤으로 결정된다.
확인하는 방법
$ olsnodes -n
$ pwd
/home/oracle/product/10g/crs/log/rac1/crsd
$ grep MASTER crsd.log
블록 단위로 Master node 를 설정한다
GCS 서비스가 원활하게 운영되도록 요청된 블록을 전송하고 상태를 관리하는 백그라운드 프로세스는 Lock Monitor Services (LMS) 입니다.
GCS_SERVER_PROCESS 라는 파라미터를 사용해서 LMS 프로세스의 개수를 지정할 수 있음.
Interconnect
앞에서 살펴본 예에서 알 수 있듯이 RAC의 핵심 기능인 Cache Fusion이라는 특징때문에
블록들이 이동하는 길인 Interconnect가 RAC 전체 성능에 아주 중요한 역할을 하게 됩니다.
Interconnect 를 통해 이동하는 정보는 크게 Clusterware가 Cluster를 유지하고 운영하기 위해 사용하는 정보와
실제 데이터 블록, Parallel Query 관련 정보들이 있습니다.
일반적으로 Cluster 를 유지하고 운영하는 정보인 GCS/GES 관련 정보는 256bytes 정도로 아주 작지만
실제 데이터 블록은 DB_BLOCK_SIZE (10g/11g 기준으로 기본 크기는 8k) 나 NonStandard Block Size의 크기로 GCS/GES 정보에 비해 아주 큽니다.
그리고 Parallel Query 관련 정보는 Parallel_Execution_message_size에 의해 크기가 결정되는데 기본크기는 8k로 설정되어 있습니다.
이런 내용들이 얼마나 자주 왕래하느냐가 성능에 아주 중요한 영향을 주게 되며,
당연히 가급적이면 이동하는 양을 줄이는 것이 튜닝에 아주 핵심적인 관점이 되겠죠?
그래서 RAC 튜닝에서 Interconnect의 사용량을 측정하여 튜닝하는 것이 아주 자주 언급이 됩니다.
즉 Interconnect를 사용하는 량을 줄이거나 혹은 Interconnect의 속도를 높이는 것이 RAC튜닝에서 아주 중요하다는 뜻입니다.
출처: https://blog.goodgods.com/57 [개발은 너무해:티스토리]
https://myalpaca.tistory.com/17 [공부하는알파카]
'오라클 > 참고' 카테고리의 다른 글
오라클 Grid Infrastructure (2) | 2022.10.01 |
---|---|
오라클 OPatch (2) | 2022.09.30 |
오라클 ASM (Automatic Storage Management) (0) | 2022.09.28 |
오라클 클러스터 (0) | 2022.09.27 |
오라클 그리드, 인스턴스, 노드 (2) | 2022.09.20 |