RAC와 몰락
Big Picture
그림 8-1 개략적인 RAC 시스템
- 네트워크
- public 네트워크: 사용자 프로그램의 접속
- private 네트워크: 인스터스간의 통신과 SGA의 일관성을 유지하기 위해 인스턴스간에 사용
- 최대한 낮은 대기시간( lowest latency )을 보장할 필요가 있다.
- 스토리지 : 모든 인스턴스는 모든스토리지를 액세스할 수 있어야만 한다.
- 장비간의 통신 실패를 제어하는 메커니즘으로써 사용되는 특별한 디스크가 존재한다.
- 특히, RAC의 각 노드간의 물리적인 거의가 먼 경우에 RAC를 매우 정교하게 다루기를 원한다면,
이런한 디스크가 최소한 3개를 필요하면, 이상적으로는 물리적으로 분리된 곳에 위치하는 것이 바람직하다.
- 운영 체제와 오라클 인스턴스 사이에서 수행되는 소프트웨어( 클러스터 서비스 )의 몇 개의 계층은 장비간의 통신을 보장하는 역할을 한다.
- 오라클의 클러스터 소프트웨어에 의한 설정되는 "virtual 네트워크"가 존재하며, public 네트워크 위에서 동작한다.
- 실제로 virtual 네트워크는 클라이언트 프로그램이 오라클 인스턴스와 통신하기 위해 사용된다.
이것은 오라클 데이터베이스 장비와 장애를 매우 빠르게 클라이언트에게 전달하는 것을 가능하게 하며,
클리이언트는 짧은 시간 내에 정상적인 장비로 접속할 수 있다.
- 만일 오라클이 선호하는 설치방식을 사용한다면, 각 장비에 두 개의 인스턴스가 기동된다.
- 데이터 베이스 인스턴스( SID )
- 스토리지 관리용 ( ASM )
- 장비당 하나만 필요하다. 실질적으로 ASM 은 운영체제와 데이터베이스 인스터스 사이의 계층에서 logical 볼륨 매니저처럼 동작한다.
VIRTUAL IP 주소 및 SCAN
- 클러스터 서비스가 기동되자 마자 real IP 주소 위에 virtual IP ( VIP )주소를 입력한 후, 장비간의 통신은 VIP를 이용하도록 전환된다.
Virtual IP와 real IP 차이점
- real IP : 논리적으로 하드웨어의 특정 부분( 기술적으로 네트워크 카드의 MAC 주소 )과 연결
- VIP : 소프트웨어에 의해 제어되고 하드웨어와 연관된 부분도 동적으로 변경가능
장애
- 1. 클라인어트 프로그램이 real IP로 접속한 데이터베이스 장비에 장애가 발생
- 2. 클라이언트 프로그램은 서버 장비의 장애 발생에 대한 응답을 오랜 시간( 10 ~ 100 여초 ) 대기 할 수 있다.
- 3. 오라클은 virtual IP를 사용하므로, 장비 장애가 발생할 때, 인스턴스 중의 하나가 장애 사실을 매우 바르게 감지하고,
- 4. 현재 요청을 처리하기 위해 장애가 발생한 장비의 virtual IP를 가져오게 된다.
- 5. 이러한 재구성은 장애가 발생한 VIP에 대해서는 더 이상의 접속을 중단시킨다. ( 장비와 인스턴스가 복구된 후 기동 전까지 )
- 6. 이것은 클라이언트가 접속하려는 인스턴스에 장애가 발생해도, 오랜 시간 대기하지 않는다는 것은 의미한다.
SCAN ( Single Client Aceess Name )
- 11.2는 그리드 인프라스트럭처의 한 부분
- SCAN을 사용하기 위한 사전 작업으로 새로운 DNS( Domain Name Service ) 항목을 설정하거나,
오라클의 GNS( Grid Naming Service )를 사용하기 위한 DNS의 서브항목을 설정하기 위해 시스템 관리자 권한을 얻어야 한다. - 설정이 완료되면, 모든 클라이언트 프로그램은 SCAN을 통해 시스템을 참조할 수 있으며,
시스템을 다른 하드웨어로 이전하거나, 노드를 추가 또는 제거할 때도 클라이언트 설정을 재구성할 필요가 없게 된다.
다양한 안전장치
- 네트워크 장애로 인해 다른 인스턴스들과 상호 통신할 수 없을 때 어떤 일이 발생할까?
적절한 안전장치가 없다면 각 인스턴스내의 변경사항들이 중복되어 써지게 될 것이다.( 이로 인해 데이터 불일치 현상이 발생한다 )- 이런한 위협은 두 개의 계층에서 발생할 수 있다.
- 첫 번째는 장비간의 통신 단절
- 두 번째는 오라클 인스턴스 간의 통신 단절
장비 레벨에서의 방어
- 각 장바의 클러스터 서비스는 네트워크를 통해 상호간의 통신 수행 및 voting 디스크를 통해서도 상호간의 통신ㅇ르 수행한다.
통신 문제를 처리할 수 있는 몇 가지 옵션
- 1. 매초마다, 모든 장바는 voting 디스크에 기록한다.
- 디스크 내에는 장비당 하나의 파일( 1나의 블록으로 구성 )이 존재하며, 각 장비는 단순히 블록 내의 카운터를 증가한다.
만일 파일에 기록할 수 없다면, 해당 장비는 스스로를 클러스터로부터 분리한 후 클러스터를 보호하기 위해
재 기동될 수 있다.( 비정상적으로 종료되고 다른 인스턴스중 하나가 해당 인스턴스에 대한 복구를 수행한다. )
- 각 장비는 자신의 블록( voting 디스크 )에 기록 작업을 수행한다.
- 클러스터 내의 다른 모든 장비들이 기록 작업ㅇ르 수행했는지 체크한다.
- 따라서 가장 최근에 자신의 블록을 변경하지 못한 장비를 발견할 수 있다.
- 문제를 발겨한 장비는 문제가 있는 장비를 종료시킬 수 있다.
- 모든 장비들은 블록( voting 디스크)에 기록작업을 수행할 수 있지만, 네트워크 문제로 인해 장비 상호간의 통신이 단절되는 경우도 존재한다
- 한 장비는 voting 디스크에 대한 모든 기록을 제한하고(?), 통신 가능한 장비의 수를 계산한다.
만일 해당 장비가 속한 그룹이 전체 장바의 반 이상을 포함하거나, 만일 장비의 수가 동일하다면,
가장 작은 클러스트 id를 가진 장비를 포함한 그룹이 나머지 장비들을 클러스터로부터 분리하고 그들을 재 기동하게 된다.- 만일 해당 장비가 필요한 정족수( 이로 인핸 voting 디스크를 "quorum(정족수)"디스크라고도 한다 )를 얻지 못하면,
스스로를 클러스터로부터 분리한다.
오라클 레벨에서의 방어
- 각 인스턴스가 기동되면 다른 인스턴스들에게 시작 사실을 알린다.
- 모든 인스턴스는 살아있는 다른 인스턴스들의 수를 알수 있다.
- 인스턴스가 종료되면, 다른 인스턴스들에게 종료 사실을 전달한다.
- 인스턴스 그룹의 마지막 상태에 따라, 인스턴스들은 스스로를 변경된 수에 맞추어 "rebalance"한다.
- 이 시점 이후부터, 모든 인스턴스는 다른 인스턴스들과 네트워크를 통해서 지속적으로 통신한다.( 네트워크 heartbeat 프로세스로써 LMON이 사용된다 )
LMHB( lock manager heart beat monitor )
- 11.2
- RAC에서의 모든 인스턴스가 자신의 CKPT 프로세스를 소유한다
- 이에 따라 컨트롤 파일은 heartbeat 파일로써 동작할 수 있다.
- 인스턴스가 컨트롤 파일에 더 이상 기록할수 없다는 것을 감지하면, 시스템의 안정성를 위해서 스스로 종료할 수 있다.
- 인스턴스가 hang을 감지하면 다른 인스턴스들에게 hang 상태를 알리는 것도 가능할 것이다.
- 한 인스턴스 ( 정족수 그룹 내에 존재하는 인스턴스인 경우 )가 다른 인스턴스를 종료시키는 것을 허용하는 코드를 포함
RAC의 핵심
고 가용성
- 1. RAC 시스템 중의 한 노드에 장애가 발생하면, 아주 짧은 순간에 다른 노드 중의 하나가 장애가 발생한 노드의 리두를 이용하여 장애를 복구
- 2. 노드들을 rebalance한 후에 정상적인 처리를 계속한다는 것이다.
재 기동 시간은 얼마나 중요한가? 예들 들어 10초 이내? 그리고 느리더라도 대체 장비를이용하는 것이 가능한가?
디스크 또는 네트워크 장애에 비해서 장비 장애가 얼마나 자주 발생하는가? RAC로 부터 얻게 된느 이득을 얼마나 되는가?
갈수록 복잡해지는 RAC 소프트웨어와 패치 및 업그레이드를 수행할 수 있는 인적 자원을 보유하고 있는가?
성능에 영향을 주지 않고 N개의 노드의 작업량을 N-1 개에서 처리하려면 몇개의 노드가 필요한가?
Failover
- failover는 사용자 프로그램 관점에서는 거의 투명하게( 만일 프로그램을 재 작성하지 않는다면, 현재 수행중인 트랜잭션에는 적용되지 않지만 )이루어진다.
- 단점 : failover 시간이 길어진다. 장비가 유휴상태이거나 사용 중이더라도 여분의 처리 능력이 있어야 한다는 것
확장성
- 동일한 작업을 더 빨리 수행한다 - 향상된 응답시간 ( 개별적인 큰 작업을 수행한다 )
- 동일한 시간에 동일한 작업을 여러 번 수행한다 - 향상된 처리량 ( 다수의 작은 작업을 수행한다 )
그리드
- 하나의 대형 장비에 의존하는 것보다 저 비용의 장비들을 클러스터로 묶어서 사용하는 것은 그리드에서 유래된 개념
- 클러스터 내에 다수의 소형 장비( 아직 어떤 오라클 인스턴스도 수행되지 않은 )가 존재한다면
다수의 데이터베이스를 생성할 수 있으며,
각 애플맄이션을 위해 각 장비에서 수행될 인스턴스의 수를 선택할수 있으며,
동적으로 작업량을 재분배할 수 있다.
active/passive 모드
- 오라클은 통신비용을 제거한 특별한 2노드 RAC 구성을 제공한다.
- 한 인스턴스만 일하고 다른 한 인스턴스는 첫 번째 인스턴스가 장애가 날 때 까지는 (원칙적으로)아무 일도 하지 않는다. ( 라인센스가 틀린건가;; )
- 장점 : 작은 클러스터 내에 빠른 복구를 필요로 할 경우에 사용할만한 전략
RAC 동작 원리
GRD ( Global Resource Directory )
- GES: global enqueue service 는 이미 싱글 인스턴스에서 논의되었던 일반적인 락킹을 다룬다.
- 한 인스턴스에서 모드 3(row-share)으로 테이블에 락을 획드했다면, 다른 인스턴스에서 모드 6( exclusive )으로 테이블에 락을 설정할 수 없다.
- 백그라운드 프로세스 : LCK0, LMD, LMON
- GCS: global cache service는 블록 관리 ( 또는, 캐시 일관성 )를 다룬다.
- 한 인스턴스가 블록의 복사본을 변경했다면, 다른 인스턴스는 해당 복사본( bufffered copy )을 변경할 수 없다.
- 복사본 중 하나만이 디스크로 저장되기 때문, 따리서 상호간의 수행하는 일과 단하나의 current 복사본만을 유지하는 메커니즘이 필요하다.
- 백그라운드 프로세스 : LMSn ( 다른 인스턴스의 SGA를 직접 읽지 않고, 대부분 LMSn과 LMD를 통해 메시지를 전달한다. )
리소스의 락킹 및 모든 인스턴스에서 리소스를 명확히 확인 할 수 잇는 메커니즘
- v$dlm_ress : distribute lock manager resources
- v$ges_enqueue : global enqueues services enqueues ( 이전버전 : v$dlm_locks )
- GDS
v$sgastat 및 v$resource_limit
22:52:55 SYSTEM @ ec_test> SELECT RESOURCE_NAME, CURRENT_UTILIZATION, MAX_UTILIZATION
22:53:24 2 FROM V$RESOURCE_LIMIT
22:53:37 3 WHERE RESOURCE_NAME LIKE '%g_s%'
22:53:52 4 order by 1
22:54:00 5 ;
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION
------------------------------ ------------------- ---------------
gcs_resources 321051 467528
gcs_shadows 168214 188362
ges_big_msgs 24 586
ges_cache_ress 19779 23526
ges_locks 9228 41217
ges_procs 404 636
ges_reg_msgs 255 701
ges_ress 46737 192394
ges_rsv_msgs 0 0
9 개의 행이 선택되었습니다.
22:54:02 SYSTEM @ ec_test> select *
22:54:22 2 from v$sgastat
22:54:31 3 where name like '%gcs%'
22:54:39 4 or name like '%ges%'
22:54:47 5 order by name
22:54:51 6 ;
POOL NAME BYTES
------------ -------------------------- ----------
shared pool KSXR pending messages que 861984
shared pool gcs commit sga state 106504
shared pool gcs dynamic r 8677760
shared pool gcs opaque in 8208
shared pool gcs procsss descriptor 42832
shared pool gcs res hash bucket 4194304
shared pool gcs res latch table 25600
shared pool gcs resources 88575408
shared pool gcs shadows 61321440
shared pool ges big msg buffers 15090728
shared pool ges deadlock xid freelist 11264
shared pool ges deadlock xid hash tab 17800
shared pool ges enqueues 84225136
shared pool ges process array 6081520
shared pool ges process descriptor 21416
shared pool ges process hash table 176000
shared pool ges regular msg buffers 10825208
shared pool ges reserved msg buffers 8440008
shared pool ges resource 73898392
shared pool ges resource hash seq tab 131072
shared pool ges resource hash table 5767168
shared pool ges shared global area 33944
shared pool messages 960000
23 개의 행이 선택되었습니다.
22:54:52 SYSTEM @ ec_test>
- v$sgastat : GES enqueues
- v$resource_limt : GES_locks
- GCS에 대한 enqueue( 또는 lock )는 보고되지 않는다는 것을 알 수 있다.
- GCS shadows : 오라클은 캐시 처리와 일반적인 enqueue 처리를 분리
- 캐시 처리를 위한 수행 빈도수가 휠씬 많고, 인터커네터를 통해 전송되는 패킷의 크기도 훨씬 크기 때문이다.
- global cache resources를 위한 분리적인 구조를 갖는다. ( 물론, 분리된 구조를 갖는 다른 이유도 존재한다 )
- 즉, 인스턴스 장애가 발생할 때, 장애가 발생한 인스턴스가 획득한 일반적인 락,
또는 딕셔너리 캐시, 똔느 라이브러리 캐시 항목에 대해서 걱정할 필요가 없다는 것이다.
또한, 캐시 내에 존재하는 데이터 블록과 이들 블록의 상태를 확인하기 위해서
GCS는 블록의 위치와 상태를 보다 정교하게 추적해야 하고,
이를 위한 별도의 구조가 필요하다.
따라서 오라클은 global cache resources를 위한 분리된 구조를 제공한다.
- 이들 뷰는 gcs RESOURCES 와 gcs SHADOWS를 제공한다.
- 오라클은 리소스를 제어( 또는 mastering ) 하기 위한 권한을 클러스터 내에 모든 인스
턴스에게 동등하게 공유한다. - 하지만 현재 리소스를 사용하는 모든 다른 인스턴스( master를 제외한 )는 master
리소스로부터 중요한 정보의 일부를 포함하는 shadow 리소스를 유지한다.
그리고 캐시 리소스의 경우에는 이를 확인할 수 있는 명확한 뷰를 가진다.
Master 및 Shadow
- 근본적으로, 해시 함소를 사용하여 임의로 분배하는 것에 기반을 둔다.
- 만일 한 인스턴스에서 특정 인스턴스의 글로벌상태를 확인하기를 원한다면,
- 리소스 식별자를 이용하여 해시 값을 계산하 후 해당 리소스의 마스터 인스턴스를 찾는다.
- 예를 들어, 테이블 xyz에 락을 설정하기 원한다면, 해당 인스턴스는 테이블의 오브젝트
아이디를 이용하여 몇 가지 연산을 수행한 후 해당 테이블의 마스터 TM 리소스를
소유한 노드를 확인할 수 있다.- 그런 후에 다른 인스턴스들이 호환되지 않는 모드로 해당 리소스에 락을 설정했는지의 여부를 확인한다.
REMASTERING
- 필자님 왈 : 오라클이 산술적인 연산을 수행함으로써 오브젝트의 마스터 리소스를 찾는다고 언급
- 이러한 동작원리의 원칙은 오라클 버전에 따라 다르고, 데이터 블록에 대해서 특별한 경우도 존재한다.
- 만일 DATA OBJECTS가 다른 인스턴스들 보다 특정 인스턴스에서 더 많이 사용된다는 것을
감지하면, 일반적인 주소 기반의 연산을 수행하지 않고, 해당 인스턴스를 해당 오브젝트의
모든 블록에 대한리소스 마스터로 정한다 ( 버전에 따라 이 절차는 세 단계를 통해 진화 되었다. )- A : 전혀 동작하지 않음
- B : 파일 레벨에서 동작
- C :오브젝트( 데이터 세그먼트 ) 레벨에서 동작
- 오브젝트의 맵 : 데이터 오브젝트의 수는 데이터베이스 내의 블록 수와 비교하면 상대적으로 작은 경향이 있으므로,
각 인스턴스는 모든 데이터 오브젝틔 맵을 유지하는 것이 가능하다.- 리스토 마스터에 대한 정보 : 개별블록에 대한 마스터를 찾기 위한 산술 연산을 수행하기 전에 데이터 오브젝트 마스터링을 확인하기 위한 용도
- 알고리즘 핵심 : 동적으로 오브젝트를 리마스터 한다는 것
- 단점 : 오브젝트에 대한 기존의 리소스 마스터를 새로운 인스턴스로 이동하기 위해, 아주 짧은 순간 GRD를 동결시킬 필요가 있다.
처리 속송에 따라 몇 개의 오브젝트는 상당히 정기적으로 리마스터 될 수 도 있다.( Statspack, AWR 확인 가능 )
TM 리소스 확인
20:13:31 SYSTEM @ EC_TEST> SELECT OBJECT_NAME, OBJECT_ID, '0x'||TO_CHAR( OBJECT_ID, 'FMxxxxxxxx' ) "16진수"
20:13:32 2 FROM DBA_OBJECTS
20:13:32 3 WHERE OBJECT_NAME = 'WRH$_LATCH'
20:13:32 4 AND OBJECT_TYPE = 'TABLE';
OBJECT_NAME OBJECT_ID 16진수
-------------------------------------------------------------------------------------------------------------------------------- ---------- -----------
WRH$_LATCH 6241 0x1861
20:13:34 SYSTEM @ EC_TEST> select *
20:13:40 2 from gv$dlm_ress
20:13:40 3 where 1 = 1
20:13:40 4 and RESOURCE_NAME like '%0x1861%'
20:13:40 5 and RESOURCE_NAME like '%TM%';
INST_ID RESP RESOURCE_NAME ON_CONVERT_Q ON_GRANT_Q PERSISTENT_RES MASTER_NODE NEXT_CVT_ VALUE_BLK_STATE VALUE_BLK
---------- ---------------- ------------------------------ ------------ ---------- -------------- ----------- --------- -------------------------------- ---------------------------------------------------------
2 0700010110B461E8 [0x1861][0x0],[TM][ext 0x0,0x0 0 1 0 1 KJUSERNL KJUSERVS_NOVALUE 0x00000000000000000000000000000000 .
1 070001010FEA0FE0 [0x1861][0x0],[TM][ext 0x0,0x0 0 0 0 1 KJUSERNL KJUSERVS_NOVALUE 0x00000000000000000000000000000000 .
20:13:43 SYSTEM @ EC_TEST>
20:21:01 SYSTEM @ EC_TEST> SELECT inst_id
20:21:03 2 , handle
20:21:03 3 , grant_level
20:21:03 4 , request_level
20:21:03 5 , resource_name1
20:21:03 6 , resource_name2
20:21:03 7 , state
20:21:03 8 , owner_node
20:21:03 9 FROM gv$ges_enqueue
20:21:03 10 WHERE 1 = 1
20:21:03 11 AND resource_name1 LIKE '%0x1861%'
20:21:03 12 AND resource_name1 LIKE '%TM%';
INST_ID HANDLE GRANT_LEV REQUEST_L RESOURCE_NAME1 RESOURCE_NAME2 STATE OWNER_NODE
---------- ---------------- --------- --------- ------------------------------ ------------------------------ ---------------------------------------------------------------- ----------
2 0700010134AF1090 KJUSERCW KJUSERCW [0x1861][0x0],[TM][ext 0x0,0x0 6241,0,TM GRANTED 0
20:21:11 SYSTEM @ EC_TEST>
- v$ : 싱글 인스턴스 내의 동적 성능 뷰 ( 싱글 인스턴스 )
- gv$로 시작하는 글로벌 뷰의 부분집합
- 조회 : 다른 노드들에 병렬 쿼리 슬레이브 프로세스를 생성한다. ( PZ99 )
- parallel_max_servers 를 0으로 병렬 쿼리를 비활성화 해도 RAC에서 이들 슬레이브는 여전히 동작한다.
- MASTER_NODE : 1
- 마스터 노드는 리소스에 대한 마스터임에도 불고하고 리소스에 대한 enqueue를 소유하지 않았다.
- KJUSERCW( concurrent write ) == v$lock 의 row-exclusive 동등
shadow 리소스
- shadow 리소스에 등록된 enqueue는 shadow 노드에서만 볼 수있다.