[HA, OPS, RAC]
database : 서버의 전원이 꺼져도 데이터를 안전하게 저장하고 있어야 하므로 HDD에 파일로 구현
instance : 많은 사람들이 동시에 접속해서 조회나 변경등의 작업을 동시에 수행하는공간으로 속도가 빨라야 하므로 RAM에 구현
process : database와 instance를 왔다갔다 하면서 작업을 해주는 구성요소 (서버프로세스, 백그라운드 프로세스 등)
- database에 저장해놓고 필요할때 데이터를 instance로 복사해와서 작업을 하고 다시 작업이 끝나면 database에 저장하는 형태
- 하나의 database에 하나의 instance가 할당되는 구성을 single server
- 하나의 database에 여러개의 instance로 구성되는 방식을
8i -> OPS (Oracle Parallel Server) / 9i -> RAC (Real Application Cluster)
1. HA (High Availability)
- 고가용성
- 서버의 사용가능시간을 최대한으로 늘이는 것이 목표인 서버구성방법
- 두대의 서버를 동일하게 구성해서 1대는 active로 두고 다른1대는 standby로 설정
- active상태의 서버가 장애발생시 standby상태의 서버가 즉시 active로 바뀌어서 투입
- Dataguard방식이 HA구성방식
- 단점 : 비용두배, 동기화문제
2. OPS (Oracle Parallel Server)
- 하나의 storage에 두개의 instance가 연결
- 두개의 노드 모두가 active상태로 동작하기 때문에 이론적으로 부하가 50%로 분산될수있고 속도는 두배로
- CTF나 TAF라는 설정이 되어있을 경우 기존 서버에 장애가 발생했을경우 해당작업을 그대로 다른서버로 이전 가능
- HA와는 달리 OPS는 1개의 storage를 공유해서 사용하므로 동기화 문제 없음
- OPS나 RAC는 이론적으로 서버 수의 제한없이 확장 가능
- 단점 : RAC Ping
# RAC ping
같은사용자가 서버각각에 동시에 접속했을때 instance1에서 변경완료된 데이터를 instance2로 가져오기 위해서는 디스크에 저장후 복사
서로 다른 instance에서 변경된 데이터를 다른 instance에서 참조하기위해서는 disk에 저장한 후 다시 불러와야 하는 문제
3. RAC (Real Application Cluster)
- RAC ping문제가 개선되어 성능이 크게 향상됨 (9i부터)
- Cache Fusion : 9i 부터 서로 다른 instance에서 변경된 데이터를 디스크를 거치지 않고 바로 instance로 가져올수있는 기능
- 8i OPS에서 소개가 된 기능이지만 제약사항들이 많아서 많이 사용되지 않았고 9i RAC에서 완전한 cache fusion 기능 구현
- Interconnect : instance1과 instance2를 연결, 즉시 메모리의 데이터를 디스크를 거치지 않고 서로 데이터 교환
- 10g RAC 부터는 저장공간(storage) 관리방식에 큰변화
- 9i RAC 까지는 storage를 Raw Device로 구성
- 10g부터 오라클사가 독자적으로 개발한 ASM (Automatic Storage Management)방식으로 구성 (오라클권장)
# 클러스터용 소프트웨어
- 물리적으로 떨어진 서버들을 하나로 묶어주는 프로그램, 마치 하나의 서버처럼
- 9i버전까지는 클러스터용 프로그램을 오라클사가 아닌 별도의 회사에서 만들어 제공
- 10g R1 : CRS (Cluster Ready Service) (이때부터 클러스터용 프로그램을 오라클 사에서 직접 만들어 제공)
- 10g R2 : Clusterware (클러스터웨어)
- 11g에는 ASM 기능이 통합되어 : gird(그리드)
- 여러 instance에서 데이터가 조회되고 변경되어도 무결성이 유지되도록 관리
- 각 instance간에 생기는 모든 변동사항들을 조정하고 관리
- 10g RAC까지는 OCR과 Vote disk를 ASM Storage에 저장할수 없기때문에 별도의 Raw device를 구성해야함
- 11g RAC부터는 OCR과 Vote disk를 모두 ASM Storage에 저장할수 있음
- 11g부터는 Clusterware가 Grid Infrastructure라는 프로그램에 통합되어 Grid 프로그램을 설치하면 자동으로 설치됨.
- OCR (Oracle Cluster Repository) : RAC 구성의 전체 정보 저장하는 디스크, RAC에서 핵심역할
- RAC를 시작하려면 OCR에 저장된 정보를 보고 구성해야하는데 10g RAC까지는 RAC시작후 ASM instance를 시작하기때문에
- OCR를 ASM에 저장할수 없음 (RAC시작불가)
- 별도의 Raw Device를 구성하여 OCR, Vote Disk 구성
- Vote Disk : 각 Node들의 장애여부를 구분하기위해서 사용, 일종의 출석부역할
- 오라클 권장 OCR 최소 크기 : 100MB
- 오라클 권장 Vote disk 최소크기 : 20MB, 3개로 다중화하여 구성하기를 권장
RAC는 여러개의 instance node들로 구성이 되어 있기때문에 각 node들이 문제가 있는지 없는지를 실시간으로 파악해야함
RAC를 구성하는 프로세스 중 cssd라는 프로세스가 각 Node들이 정상적으로 작동하고있는지 interconnect를 통해 확인
매 초마다 heartbit를 보내고 각 node들은 그에 대한 응답을 다시 보내서 자신이 정상적으로 동작하는것을 알림
( cssd데몬이 1초에 한번씩 각 노드들에게 heartbit를 보내고 heartbit를 받은 노드들이 응답을 보냄)
여러가지 이유로 특정 node가 heartbit에 응답하지 못하였을 경우
cssd는 2차로 vote disk 확인
각 node들은 cssd가 보내는 heartbit에 응답을 보내면서 매초마다 vote disk에도 자신이 정상 동작함을 표시함
특정 node가 heartbit에 응답이 없을경우 vote disk확인해보고
해당 node의 표시가 없다면 cssd는 해당 node가 장애발생으로 생각하고 해당 node를 cluster에서 제외하고 재부팅을 하게됨
[Cache Fusion]
1. Cache Fusion 개념
- 어떤 instance에서 작업을 해도 마치 하나의 서버에서 작업을 하는 것과 같은 효과
# GES (Global Enqueue Service)
- 어떤 instance에서 데이터 변경작업(트랜잭션)을 하든 하나의 instance에서 데이터 변경 작업을 하는 것과 같이 관리
- LMD(Lock Monitor Daemon Process) : 여러 instance끼리 Lock 관련 정보를 전송, Deadlock 등 관리
# GCS (Global Cache Service)
- cache fusion 기능이 구현되기 위한 필수 서비스
- 자신의 instance에서 원하는 데이터를 찾지 못해서 다른 instance에 데이터를 요청했을때 interconnect를 통해 데이터 전달
- 물리적으로 떨어져 있는 각각의 instance를 마치 하나의 database buffer cache인것처럼 가용 가능
- 데이터 무결성문제 발생 <- 1건의 데이터를 여러 instance에서 동시에 변경, 삭제 할수 있기 때문에
- 데이터의 상태를 항상 관리해야함 -> GCS에서는 데이터 블록을 전송하고 관리할때 3가지 모드로 구분
- LMS(Lock Monitor Services) : 요청된 블록을 전송하고 상태를 관리하는 백그라운드 프로세스
- LMS는 모든 instance에 사용되는 블록들을 전송하고 상태를 관리해야 하기때문에 1개로는 부족함
(GCS_SERVER_PROCESS라는 파라미터를 사용하여 LMS프로세스의 개수지정, CPU개수가 4개마다 1개의 LMS프로세스가 적당)
* GCS 데이터 관리 3가지 모드
- Null (N) 모드 : 해당 블록을 사용중인 사용자가 없음
- Share (S) 모드 : 해당 블록을 select 하고 있는 세션이 있음
- Exclusive (X) 모드 : 해당 블록을 누군가가 변경하고 있음
- share모드는 여러 instance에서 동시에 공유해서 사용가능 (1건의 데이터를 여러 instance에서 동시에 select 가능)
- X 모드는 반드시 1개의 instance에서만 사용가능 (1건의 데이터를 여러 instance에서 동시에 변경 불가)
- Master Node : 특정 데이터에 대한 모드를 관리하는 instance
- 어떤 instance에서 특정 데이터에 대한 X모드를 받고싶다면 해당 데이터를 관리하는 master node에게 허락받아야함
- 여러 instance중에서 master node를 결정하는 방법은 Hashing 알고리즘을 이용해서 랜덤으로 결정
2. Cache Fusion 동작원리
# 해당블록을 최초에 select 할 경우
> Node 1 사용자가 SCN 1번인 홍길동 데이터가 들어있는 블록을 Select
① 가장 먼저 해당 블록의 master node인 Node2번에게 해당 블록의 상태 문의
② 해당 블록을 아무도 사용하지 않기때문에 Node1에게 S권한 허락
③ master node에게 S 권한을 받은 node1은 storage에 가서 해당 블록을 자신의 buffer cache에 복사
# 다른 사용자가 동일 블록을 select 할 경우
> 현재 node1에 SCN1번인 홍길동 데이터 블록존재
> 이때 node3에서 홍길동 데이터 select 작업 수행 -> Cache Fusion 동작
① node3는 홍길동 데이터의 master node인 node2에게 홍길동 데이터 블록의 상태 확인
② node3의 요청을 받은 master node는 해당 블록이 node1의 DB cache에 있다는 것을 알고 node3으로 보낼것을 지시
③ master node의 요청을 받은 node1은 해당 블록을 interconnect를 통해 node3에 전송
④ 원하는 블록을 전송받은 node3은 해당 블록에 select할수있는 S권한을 master node로부터 할당받음
OPS의 경우 node3은 storage에 가서 해당 블록 복사 -> 즉 동일한 데이터를 디스크에서 반복적으로 읽는 작업이 빈번 -> 성능저하
RAC의 Cache Fusion에서는 속도가 아주 빠른 interconnect를 통해 메모리의 데이터가 즉시 전송 -> 속도가 비약적으로 개선됨.
# 기존 node에서 데이터의 변경이 발생할 경우
> 현재 node1과 node3에 동일한 SCN을 가진 홍길동 데이터 존재
> 이런 상황에서 node3에서 update작업수행(홍길동->일지매)
① node3에서 update작업을 하기위해서 master node에게 해당 블록을 변경할수있는 X모드 요청
② (X모드는 S모드와 동시에 사용X) master node는 S모드를 가지고있는 node1에게 S를 N모드로 다운그레이드 지시
③ node1은 S모드를 N모드로 다운그레이드 한후 그 결과를 node3에게 알려줌
④ node1로부터 응답을 받은 node3은 자신의 모드를 X모드로 변경
⑤ node1이 N모드로 다운그레이드되고 자신(node3)이 X모드로 변경되었다는 내용을 master node(node2)에게 통보
> 위 과정이 끝난후 node3은 홍길동을 일지매로 update
> node3에는 가장 최신 데이터인 SCN 2번(일지매), node1과 storage에는 이전 데이터인 SCN 1번(홍길동)데이터 존재
# 새로운 node에서 데이터의 변경이 발생하는 경우
> 새로운 노드인 node4가 update하는경우
① node 4번이 일지매 데이터를 강감찬으로 업데이트 하기 위해서 master node인 node2에게 해당 블록의 상태 조회
② node 4의 요청을 받은 node2는 가장 최신 데이터를 가지고 있고 X모드인 node3에게 N모드로 다운그레이드 후 node4에게 전송 지시
③ master node로부터 요청을 받은 node3은 X모드를 N모드로 다운그레이드 후 해당 블록을 interconnect를 통해 node4에게 전송
④ node3으로부터 해당 블록을 전송받은 node4는 권한을 N으로 업그레이 후 master node에게 정보 전송
⑤ 일지매를 강감찬으로 update
> node4는 SCN 3번(강감찬)소유, node3은 SCN 2번(일지매)소유, node1과 storage는 SCN 1번(홍길동)소유
OPS의 경우 이작업을 수행할때 node 3이 변경된 이미지를 디스크에 기록한 후 node 4에서 가져가는 RAC ping현상 발생
# 이전 이미지를 가지고 있던 기존 노드에서 데이터 조회하기
> 현재 node4는 SCN 3번(강감찬), node3은 SCN2번(일지매), node1과 storage는 SCN 1번(홍길동)소유
> 이상황에서 node1에서 강감찬 데이터를 조회할 경우
① master node에게 해당 블록 정보 요청 (무조건 master node를 찾아가지 않고 자신이 가지고 있는 해당 블록의 모드 먼저 확인)
② master node는 해당 블록의 최신 정보를 가지는 node4에게 X모드를 S모드로 다운그레이드 후 node1에게 전송 요청
③ node4는 master node의 요청대로 X모드를 S모드로 다운그레이드
④ 해당 블록을 node1로 전송
⑤ 해당 블록을 받은 node1은 자신이 가지고 있는 해당 블록에 대한 모드를 N모드에서 S모드로 업그레이드
⑥ master node에게 보고
> 모든 노드들이 블록에 대한 정보를 조회할때 자신이 가지고있는 모드를 살펴본후 Null모드일 경우 master node에게 최신정보를 요청
> 이전 이미지를 읽는 경우는 발생하지 않음
[Interconnect(인터커넥트)]
- RAC의 핵심기능인 Cache Fusion이라는 특징 때문에 블록들이 이동하는 길인 interconnect가 RAC 전체성능에 중요한 역할
- interconnect를 통해 이동하는 정보 : Clusterware가 Cluster를 유지.운영하기위한 정보, 실제 데이터 블록, parallel Query 관련 정보 등
- 일반적으로 Cluster를 유지하고 운영하는 정보인 GCS/GES 관련 정보는 256 bytes정도로 작지만
실제 데이터 블록은 DB_BLOCK_SIZE나 Non-Standard Block Size의 크기로 GCS/GES정보에 비해 큼
- Parallel Query 관련 정보는 Parallel_execution_message_size에 의해 크기 결정(기본값 8k)
- interconnect를 사용하는 양을 줄이거나 혹은 interconnect의 속도를 높이는 것이 RAC튜닝에 중요!
'oracle > [RAC] RAC 관련' 카테고리의 다른 글
| [RAC] RAC환경에서 archive log mode로 변경하기 (0) | 2014.11.26 |
|---|---|
| [RAC] OCR 개념 및 관리 (0) | 2014.11.25 |
| [RAC] RAC 운영하기 (0) | 2014.11.25 |
| [RAC] CRS (0) | 2014.11.25 |
| [RAC] RAC기반에서의 Load Balancing과 Application Failover (0) | 2014.11.24 |
댓글