Oracle RAC란?

 

[★RAC에 대해 많이 물어보는 질문들★]

1. RAC 설치가능여부 (엔지니어) - 10g / 11g 2. RAC IP 설명. (private, public ..) 3. RAC 용어, 개념 4. RAC 명령어들 (난도 상)  - RAC잘작동되는지 알아보는 명령어 : crs_stat -t  - rac listener 껐다 키는 명령어 : lsnrctl stop 쓰면 안되!! RAC listener만 껐다켜야되. 찾아볼것!! crs stop ?? 5. RAC스펠링(Real application cluster) / HA스펠링

 

1. 일반적인 Oracle server 구성방식.

 

* Process : A는 작업장1로 복사해와서 작업을하고, B는 작업장2로 복사를 해와서 작업을 하며, 저장을 database에 한다. 이렇게 instance와 database 사이를 왔다 갔다 하면서 작업을 해주는 구성요소.

 - server process

 - background process

 

* oracle server의 구성 방식.

- single server 구성 : 하나의 database에 하나의 instance가 할당되는 구성.    : 일반적으로 DB서버 구현시 1개의 서버를 사용하게 되는데, 이런 경우 instance 역할을 하는 서버에 장애 발생했을 때 storage에 저장된 데이터를 사용할 수 없게 되는 위험이 존재한다.

- OPS(8i버전까지) 또는 RAC(9i버전부터) : 하나의 database에 여러 개의 instance로 구성하는 방식.

 

 

 

2. HA 구성 (High availability = 고가용성) ★★★ 

 

: 똑같은 장비를 두개를 구축해서, 하나는 실제 서비스(active)를 하고, 한대는 대기상태(standby)로 두는 서버구성방식.   그래서 active상태였던 서버가 고장나면, standby상태의 서버가 즉시 active 상태로 바뀌어서 투입되어 서비스 중단이 발생하지   않도록 조치되는 구성이다.        * 문제점  ① 비용이 많이 든다.  ② 데이터 동기화 문제 : active상태의 node에서 작업을 하다가 db가 죽으면, standby상태의 node로 작업을 할 수는 있다고 쳐도, 데이터가 동기화 되지 않았으므로, 데이터는 이미 날라간 상태이다.   -> 미러링을 어떻게 해 줄거냐에 따라서 성능이 결정된다.    -> DG(data guard) (HA구성 방식으로 사용시, 데이터 동기화 문제를 해결하기 위해 오라클에서 제공하는 무료 프로그램.)       : 운영db를 백업받는 용도로 규칙적으로 동기화. (별로 쓸모없다.)    **24X7X365 (무정지) : 하루24시간 7일 365일 내내 stop하는 시간으로 -> 0이 될 수록 좋다.

 

 

 

3. OPS 구성 (Oracle Parallel Server) ★★★ (rac의 원조)

 

: 하나의 storage에 두 개의 instance가 연결되어 있는 구성으로, 사용자가 각각 다른 instance에 접속을 해도 storage가 하나이므로, 같은 데이터를 조회, 변경할 수 있다.    * 장점  : 만약 1개의 instance에서 장애가 발생할 경우 남아 있는 다른 instacne를 통해 storage에 접근가능하기 때문에 서비스가 중단되는 경우를 예방할 수 있다. (데이터 날라가지 않음. 그 데이터 그대로 다른 instance에서 쓸 수 있음.)      * 문제점 : rac ping★    [현재 상황] : storage에 저장된 홍길동 데이터를 A사용자가 instance1로 접속해서 조회하고, B사용자는 instance 2에 접속한 후 조회했다. 이후에 A사용자가 홍길동을 일지매로 update한 후 commit까지 완료했다.  [문제 발생] : 이 때 instance 2에 접속해 있는 B사용자가 홍길동 데이터를 조회할 경우 일지매라는 데이터가 보여야하는데, instance 1에서 변경완료후 commit된 일지매 데이터를 instance2로 가져오기 위해서는 storage에 우선 저장을 한 후,instance2로 가져와야 한다.      [RAC Ping] : instance1에서 변경완료된 데이터를 instance2로 가져오기 위해서 우선 디스크에 저장을 한 후 해당 데이터를 instance2로 복사해오는 작업. (디스크를 사용해서, 시간이 오래 걸린다.)

 

 

 

4. HA와 OPS의 비교.

 

HA구성	OPS
* 하나는 Active이고, 나머지 하나는 대기상태인 Standby이다.  * 만약 100명의 사용자가 접속할 경우 Active 상태인 서버로 모두 접속하게 되고,  standby 상태의 서버는 장애를 대비하여 대기만 하고, 실제 서비스에는 전혀 도움을 주지 않는다는 뜻.  (예를 들어, 차를 살 때 한대가 고장날 경우를 대비해 똑같은 차를 한꺼번에 2대를 사서, 1대는 늘 타고다니고, 1대는 주차장에 세워두면서 대비해두는 방식과 같다.)  * 비용이 많이 들고, 아주 비 효율적이다.  * Active 상태의 서버가 장애가 날 경우 해당 서버에 접속해 있던 연결들은 모두 접속이 종료된 후 standby 서버가 가동되면서 다시 접속되므로, 즉 active상태였던 서버에서 하던 모든 작업들이 전부 취소된다는 뜻.  * 각 서버 별로 Storage를 별도로 가지고 있기 때문에 active상태였던 서버에서 변경된 작업이 standby상태 서버에 반영되지 못할 경우 데이터의 불일치 현상이 생길 수 있다.(데이터 동기화 문제)  * 두 개의 서버로만 구성할 수 있다.	* 두 노드 모두가 Active상태로 동작하기에 이론적으로는 부하가 50%로 분산될 수 있고, 서비스 속도도 두 배 빨라질 수 있다.    * OPS의 경우에는 CTF나 TAF라는 설정이 되어있을 경우 기존 서버에 장애가 발생했을 경우 작업을 그대로 다른 서버로 이전시킬 수 있다. (단 수행 중이던 작업의 종류에 따라 다름.)    * 1개의 storage를 공유하므로 한 서버에서 변경된 작업을 다른 서버에서도 그대로 반영이 된다.    * OPS나 RAC는 이론적으로 서버수의 제한이 없이 확장이 가능하다.    * Down Time 을 획기적으로 줄일 수 있다.    * RAC ping이라는 현상으로 심각한 성능저하 발생.

 

 

5. RAC (Real Application Cluster) (9i버전부터)

 

: OPS의 RAC ping문제가 개선되어 성능이 크게 향상 된 것으로, oracle9i버전부터는 서로 다른 instance에서 변경된 데이터를 디스크를 거치지 않고 바로 instance로 가져올 수 있는 기능인 Cache Fusion(캐쉬 퓨전)이라는 기능이 사용된다.  ((사실 cache fusion이라는 기능이 8i OPS에서 소개가 된 기능이지만, 8i에서는 많은 제약 사항들이 있었고, ㅇ전히 디스크 기반의 동기화를 사용했었다.))        * public network (public 망) : ip3개 중 관리자가 유지,보수 할 때 쓰는것으로. public망에 붙어쓰는게 vip인데,  service ip임.  * inter connect = private network (private 망) : instance1과 instance2를 연결하는 망.  * cache fusion : instance1에 있는 데이터와 instance2에 있는 데이터를 서로 즉시 볼 수 있고, 어떤 물리적인 instance에서 작업을 하든지 내용이 구분없이 섞여 있으므로 cache fusion이라고 부른다.

 

클러스터용 소프트웨어

CRS (10g R1) ---> clusterware (10g R2) ---> Grid(11g)   : 10g R1버전부터 클러스터용 프로그램을 오라클에서 직접 만들어 제공하기 시작했고, 10g R2버전부터 클러스터웨어라는 용어로 부른다. 11g에서는 ASM 기능이 통합되어 grid라는 명칭으로 변경되었다. Grid는 여러개의 local lock 떨어져 있는 것을 하나로 묶어주는 것이다.

 

** 설치할 때 그 회사에 라이센스를 보고, 제대로 깔아야된다. 무조건 다 깔면 안되.

 

clusterware (10g R2)

: 동일한 데이터를 동시에 변경을 하게되는 문제가 생기지 않도록 관리해주는 역할을 한다.    (어디에 뭐가 깔리는지 잘 볼것.)    - storage 구성방식   : 9i RAC 까지는 storage를 Raw device를 사용해서 구성했으나, 10g 부터는 ASM(Automatic Storage management)라는 방식으로 storage를 구성할 수 있게 되었고, ASM이 오라클이 권장하는 방법이다. 그러나 ASM으로 구성된 예가 거의 없어서, 10g RAC의 경우에도 대부분이 Raw Device로 구성되어 사용되었다.

 

 

ASM기반

-10g R2까지는 OCR과 Vote disk를 ASM storage에 저장할 수 없기 때문에 별도의 Raw device를 구성해서 저장해야 한다.   -11g부터는 OCR이나 vote disk가 전부 ASM에 들어간다.     * OCR(Oracle cluster repository)★ : RAC 구성의 전체 정보를 저장하고 있는 디스크로, RAC에서의 핵심역할을 한다.   - RAC를 시작할 때 OCR에 저장되어 있는 정보를 보고 RAC를 구성해야 하는데, 10g RAC까지는 RAC 시작후 ASM instance를 시작하기 때문에 OCR을 ASM에 저장할 경우 RAC를 시작할 수 없게 되는데, 그래서 별도의 Raw device에 저장한다.   (최소크기 100MB)     * VoteDisk★ : 각 Node들이 장애가 있는지 없는지를 구분하기 위해서 사용하는 일종의 출석부 같은 역할을 하며, cssd가 보내는 heartbeat에 응답을 보내면서 매 초마다 vote disk에도 자신이 정상적으로 동작하고 있다는 표시를 해둔다.   - RAC를 구성하는 프로세스 중 cssd라는 프로세스가 각 Node들이 정상적으로 작동하고 있는지 interconnect를 통해 매 초마다 핑(heartbeat)[핫빗] 을 보내고 각 node들은 그에대한 응답을 다시 보내어 자신이 정상적으로 동작하고 있다는 것을 알려준다.  -> 만약 어떤 이유로 특정 node가 heartbeat에 응답을 하지 못했을 경우, cssd는 2차로 vote Disk를 확인한다. 그 vote disk를 확인해보고 그곳에서  해당 node의 표시가 없다면 해당 node가 장애가 생겼다고 가정하고 해당 node를 cluster에서 제외하고 재부팅한다. 만약 heartbeat에 응답이 없었는데, votedisk에 해당 node의 표시가 있다면, node가 바빴다고 생각하고 넘어간다.   (최소크기 20MB, 3개로 다중화해서 구성하기를 권장)

 

 

6. Cache Fusion  

 

1) Cache Fusion 개념.

 : 물리적으로 떨어져 있어도 하나로 만들어 주는 것.

 

 : instance1에서 A user가 홍길동을 강감찬으로 update후 commit 수행한 후 B user가 원래 홍길동이었던 deptno=10번을 조회할 경우, instance1에서 변경된 데이터를 디스크를 거치지 않고(RAC ping현상 없이) interconnect를 통해서 즉시 instance2로 전달된다.

 

 

* Global Enqueue service(GES)

어떤 instance에서 데이터 변경작업(트랜잭션)을 하든지 하나의 instance에서 데이터 변경작업을 하는 것처럼 관리하는 기능.  ex) A user가 instance1에서 홍길동을 강감찬으로 변경작업을 하고 있을 경우 해당 변경작업이 종료될 때까지 마치 하나의 서버에서 작업을 하는 것처럼 B user가 instance2에서 홍길동을 delete할 수 없도록 막아준다는 뜻  ## Lock Monitor Deamon process(LMD) : GES기능을 하는 RAC용 백그라운드 프로세스로, 여러 instnace끼리 Lock 관련 정보를 전송하고 혹시 발생할 지 모를 deadlock 등을 관리하는 일을 한다.

* Global Cache Service(GCS)

cache fusion 기능이 구현되기 위한 필수 서비스로서 어떤 사용자가 자신의 instance에서 원하는 데이터를 찾지 못해서 다른 instance에 있는 데이터를 요청했을 때 interconnect를 통해서 데이터를 전달해주는 서비스. (물리적으로 떨어져있는 각각의 instance이지만 마치 하나의 database buffer cache인 것처럼 사용할 수 있는 서비스.)  ex) A 매장에 핸드폰을 사러 갔는데 해당 매장에 원하는 핸드폰이 없고, 근처 다른 위치에 있는 다른 B 핸드폰 매장에는 해당 핸드폰이 있을 경우, 사용자가 B매장으로 가지않고 A매장에서 B매장의 물건을 받을 수 있는 서비스.     Null(N)모드  해당 블록을 사용중인 사용자가 없다는 것을 뜻한다.   Share(S)모드  해당 블록을 select하고 있는 세션이 있다는 뜻 - 여러 instance에서 동시에 select할 수 있다.   Exclusive(X)모드  해당 블록을 누군가가 변경하고 있다는 뜻 - 반드시 1개의 instance 에서만 변경할 수 있다.  ** 만약 현재 select를 해서 S모드로 해당 데이터를 가지고 있는데 update를 수행해야 한다면 update 하기 전에 X모드로 변경해야 한다. 문제는 모든 instance의 프로세스가 동시에 자신이 작업중인 instance에서 X모드로 임의로 변경할 수 있기 때문에 누군가가 관리를 해줘야 한다. ** 어떤 instance에서 특정 데이터에 대한 X모드를 받고 싶다면 해당 데이터를 관리하는 Master node에게 가서 허락을 받아야 한다.    [Master node 확인하는 명령어] : olsnodes -n       ## Lock Monitor Services(LMS) : GCS 서비스가 원할하게 운영되도록 요청된 블록을 전송하고 상태를 관리하는 백그라운드 프로세스로, 모든 instance에 사용되는 블록들을 전송하고 상태도 관리해야 하기 때문에 1개만으로는 부족하다.   -> GCS_SERVER_PROCESS 라는 파라미터를 사용해서 LMS프로세스의 개수를 지정할 수 있다. (값을 크게 주는 것을 권장)    (오라클 권장 값은 CPU 개수가 4개마다 1개의 LMS 프로세스가 적당하다고 가이드함)

 

 

 

2) cache fusion의 동작 원리 ★

 (1) 해당 블록을 최초에 select 할 경우.

 ① node1 사용자가 SCN1번인 홍길동 데이터가 들어있는 블록을 select

 ② 가장 먼저 해당 블록의 master node인 node2번에 해당블록의 상태를 문의

 ③ 요청을 받은 node2가 해당 블록을 아무도 사용하고 있지 않으면, 해당 블록을 조회할 수 있는 S권한을 node1에게 허락.

 ④ s권한을 받은 node1은 storage에 가서 해당 블록을 자신의 buffer cache로 복사.

 

 

 (2) 다른 사용자가 동일 블록을 select할 경우.

ⓞ node1에서 SCN1번인 홍길동 데이터의 블록이 위치해 있다.

① node3이 홍길동 데이터의 마스터노드인 node2에게 홍길동 데이터의 블록 상태를 확인.

② master node가 해당블록이 node1의 DB cache에 있다는 것을 알고 node1에게 해당 블록을 node3에게 보낼 것을 지시.

③ node1이 해당블록을 interconnect를 통해 node3에게 전송하게됨 (읽기 또는 읽기cache fusion이라고 부른다.)

④ 원하는 블록을 전송받은 node3이 해당 블록에 select 할 수 있는 s권한을 master node로 부터 할당받음. 

 

 

 (3) 기존 node에서 데이터의 변경이 발생

ⓞ 현재 node1과 node3에 동일한 SCN을 가진 홍길동 데이터가 존재하는 상황이다.

① node3이 홍길동을 일지매로 update하기 위해 master node에게 X모드를 요청.

② X모드는 특징상 S모드와 동시에 사용될 수 없으므로, master node는 s모드를 가지고 있는 node1에게 s모드를 n모드로 다운그레이드 하라고 지시.

③ node1은 s모드를 n모드로 다운그레이드 한 후, 그 결과를 node3에게 알려준다.

④ node3은 자신의 모드를 x모드로 변경하고나서, node1이 N모드로 다운그레이드되고, 자신이 x모드로 변경되었다는 내용을 amster node에게 통보한다.

⑤ 위 과정이 끝난 후 node3은 홍길동을 일지매로 업데이트 한다. -> node3에는 일지매 데이터가 존재하고, node1과 storage에는 홍길동 데이터가 저장되어있는 상황이 된다.

 

 

 (4) 새로운 node에서 데이터 변경이 발생하는 경우.

① node4번이 일지매 데이터를 강감찬으로 업데이트하기 위해 master node에게 해당 블록의 상태를 조회.

② master node가 node3이 가장 최근의 데이터를 가지고 있으며, x모드를 소유하고 있으므로, node3에게 x모드를 n모드로 다운그레이드 한 후, node4에게 해당블록을 전송할 것을 요청.

③ node3은 x모드를 N모드로 다운그레이드 한 후 해당 블록을 interconnect를 통해 node4에게 전송.

④ node3으로부터 해당 블록을 전송받은 node4는 자신의 군한을 X모드로 업그레이드 한 후 그 내용을 master node에게 전송

⑤ 이후 node4가 일지매데이터를 강감찬으로 업그레이드 한다. -> node4는 강감찬 데이터를 소유하고, node3은 일지매 데이터를 소유하고, node1과 storage는 홍길동을 소유하게 된다.

 

 

 (5) 이전 이미지를 가지고 있던 기존 노드에서 데이터 조회. 

 

ⓞ 현재 상태 : node4는 가장 최근 데이터인 강감찬 데이터를 소유하며, node3은 일지매 데이터, node1과 storage는 홍길동을 소유중.

① node1에서 강감찬 데이터를 조회하기 위해, 자신이 가지고 있는 해당 블록의 모드를 본 후, N모드일 경우 master node에게 해당 블록에 대한 정보를 요청.

② master node는 해당 블록의 최신 정보를 node4가 가지고 있다는 것을 알고 있으므로 node4에게 X모드를 S모드로 다운그레이드 한 후 해당 블록을 node1로 전송하라고 요청.

③ node4는 자신이 가지고 있던 해당 블록에 대한 X모드를 N모드로 변경.

④ node4가 해당 블록을 node1로 전송.

⑤ node1이 자신이 가지고 있는 해당 블록에 대한 모드를 N모드에서 S모드로 업그레이드.

⑥ node1이 업그레이드한 내역을 master node에게 알림.

-> 모든 노드들이 블록에 있는 정보를 조회할 때 자신이 가지고 있는 모드를 살펴본 후 null모드일 경우 master node에게 최신 정보를 요청하기 때문에, 이전 이미지를 읽는 경우가 없게 된다.

 

 

7. interconnect (인터커넥트)

* interconnet를 통해 이동하는 정보

- GCS/GES관련정보 : cluster를 유지하고 운영하기 위해 사용하는 정보. (256 bytes 정도로 아주 작다.)

- 실제 데이터 블록 : DB_BLOCK_SIZE나 Non-standard block size의 크기. (GCS/GES정보에 비해 아주 크다.)

- Parallel query 관련 정보 : Parallel_Excution_message_size에 의해 크기가 결정. (기본 : 8k)

 

** interconnect를 사용하는 양을 줄이거나 혹은 interconnect의 속도를 높이는 것이 RAC튜닝에서 아주 중요하다.