Tibero Active Cluster
Tibero Active Cluster의 기본 개념과 구성요소, 프로세스, 실행 및 운영 방법을 설명합니다.
개요
Tibero Active Cluster(이하 TAC)는 확장성, 고가용성을 목적으로 제공하는 Tibero의 주요 기능입니다. TAC 환경에서 실행 중인 모든 인스턴스는 공유된 데이터베이스를 통해 트랜잭션을 수행하며 공유된 데이터에 대한 접근은 데이터의 일관성과 정합성 유지를 위해 상호 통제하에 이뤄집니다.
큰 업무를 작은 업무의 단위로 나누어 여러 노드 사이에 분산하여 수행할 수 있기 때문에 업무 처리 시간을 단축할 수 있습니다.
여러 시스템이 공유 디스크를 기반으로 데이터 파일을 공유합니다. TAC 구성에 필요한 데이터 블록은 노드 간을 연결하는 고속 사설망을 통해 주고받음으로써 노드가 하나의 공유 캐시(shared cache)를 사용하는 것처럼 동작합니다. 운영 중에 한 노드가 멈추더라도 동작 중인 다른 노드들이 서비스를 지속하게 됩니다. 이 러한 과정은 투명하고 신속하게 처리됩니다.
구성요소
다음은 TAC 구조를 나타내는 그림입니다.
[그림 1] TAC의 구조
TAC의 구조는 다음과 같은 모듈로 구성되어 있습니다.
CWS(Cluster Wait-lock Service)
기존 Wait-lock(이하 Wlock)이 클러스터 내에서 동작할 수 있도록 구현된 모듈입니다. Distributed Lock Manager(이하 DLM)이 내장되어 있습니다.
Wlock은 GWA를 통해 CWS에 접근할 수 있으며 이와 관련된 배경 스레드로는 WATH, WLGC, WRCF이 존재합니다.
GWA(Global Wait-lock Adapter)
Wlock은 CWS를 사용하기 위한 인터페이스 역할을 수행하는 모듈입니다.
CWS에 접근하기 위한 핸들인 CWS Lock Status Block(이하 LKSB)과 파라미터를 설정하고 관리한 다.
Wlock에서 사용하는 잠금 모드(Lock mode)와 타임아웃(timeout)을 CWS에 맞게 변환하며 CWS에서 사용할 Complete Asynchronous Trap(이하 CAST), Blocking Asynchronous Trap(이하 BAST)을 등록 할 수 있습니다.
CCC(Cluster Cache Control)
데이터베이스의 데이터 블록에 대한 클러스터 내 접근을 통제하는 모듈입니다. DLM이 내장되어 있습니다.
CR Block Server, Current Block Server, Global Dirty Image, Global Write 서비스가 포함되어 있습니다.
Cache layer에서는 GCA(Global Cache Adapter)를 통해 CCC에 접근할 수 있으며 이와 관련된 배경 스레드로 CATH, CLGC, CRCF이 존재합니다.
GCA(Global Cache Adapter)
Cache layer에서 CCC 서비스를 사용하기 위한 인터페이스 역할을 수행하는 모듈입니다.
CCC에 접근하기 위한 핸들인 CCC LKSB와 파라미터를 설정하고 관리하며 Cache layer에서 사용하 는 block lock mode를 CCC에 맞게 변환합니다.
CCC의 lock-down event에 맞춰 데이터 블록이나 Redo 로그를 디스크에 저장하는 기능과 DBWR가 Global wirte를 요청하거나 CCC에서 DBWR에게 block write를 요구하는 인터페이스를 제공합니다.
CCC에서는 GCA를 통해 CR block, Global dirty block, current block을 주고받는다.
MTC(Message Transmission Control)
노드 간의 통신 메시지의 손실과 out-of-order 문제를 해결하는 모듈입니다.
문제를 해결하기 위해 retransmission queue와 out-of-order message queue를 관리합니다.
General Message Control(GMC)을 제공하여 CWS/CCC 이외의 모듈에서 노드 간의 통신이 안전하 게 이루어지도록 보장합니다. 현재 Inter-instance call(IIC), Distributed Deadlock Detection(이하 DDD), Automatic Workload Management에서 노드 간의 통신을 위해 GMC를 사용하고 있습니다.
INC(Inter-Node Communication)
노드 간의 네트워크 연결을 담당하는 모듈입니다.
INC를 사용하는 사용자에게 네트워크 토폴로지(network topology)와 프로토콜을 투명하게 제공하며 TCP, UDP 등의 프로토콜을 관리합니다.
NMS(Node Membership Service)
TBCM으로부터 전달받은 정보(node id, ip address, port, incarnation number)와 node workload를 나 타내는 가중치(weight)를 관리하는 모듈입니다.
node 멤버십의 조회, 추가, 삭제 기능을 제공하며 이와 관련된 배경 스레드로 NMGR이 있습니다.
프로세스
TAC는 1개의 프로세스(ACSD, Active Cluster Service Daemon)가 추가로 생성됩니다. 이 프로세스는 ACCT, NMGR, DIAG, WRCF, CRCF, WLGC, CLGC, WATH, CATH, CMPT 스레드(thread)로 구성되며, 각 스레드는 다음과 같은 그룹에 각각 포함됩니다.
Active Cluster Control Thread
ACCT
ACCT는 클러스터 간 메시지 통신을 담당하는 스레드입니다. 클러스터 내의 원격 노드로부터 CWS/CCC의 lock operation과 reconfiguration 요청(request)을 받아 CMPT에게 전달해주거나, 내 노드의 세션으로부터 전송해야 할 메시지를 넘겨 받아 원격 노드로 전송하는 스레드
또한, ACSD 프로세스의 메인 스레드로서 나머지 스레드를 감독하는 역할을 함
Diagnostic Thread
DIAG
DIAG는 클러스터 간 주고받는 요청에서 hang이 발생했을 때 이상 여부를 추 후에 확인하기 위해 필요한 정보를 자동으로 덤프(dump)하는 스레드
Cluster Message Processor(Message handler)
CMPT
CMPT는 다른 노드에서 보낸 메시지의 요청을 처리하는 스레드
CMPT 스레드는 ACF_CMPT_CNT 초기화 파라미터에 설정된 값만큼 공통 풀(pool) 로 생성
CMPT는 ACCT로부터 메시지를 받아 주로 다음과 같은 일을 수행
CR block request를 받아 주어진 스냅샷(snapshot)에 해당하는 CR block을 생성하고 요청자에게 전송
Current block request를 받으면 local block cache에 존재하는 Current block 을 읽어서 요청자에게 전송
Global write request를 받아 주어진 데이터 블록이 dirty이면 BLKW가 이를 디스크에 기록하도록 지시
MTC IIC request를 받아 처리
MLD(Master Lookup Directory) lookup/remove request를 받아 처리
Asynchronous Thread
WATH, CATH
CWS/CCC에서 세션을 담당하는 워킹 스레드가 처리해야 할 비동기적 업무를 대신 수행하는 스레드 WATH, CATH 스레드는 다음과 같은 특징이 있음
BAST를 맞거나 스스로 잠금을 설정할 때 캐시된 lock mode를 downgrade하 기 전에 BLKW로부터 disk write notification이나 LOGW로부터 log flush를 기다린 후 master에게 lock downgrade를 통보(이 특징은 CATH 스레드 만이 수행할 수 있음)
BLKW가 master로부터 받은 global write request 처리를 완료한 후 CATH에 게 통보해줌
또한 master에게 write done notify를 보냅니다. 이 특징은 CATH 스레드만이 수행할 수 있음
shadow resource block를 reclaim하기 전에 master에게 MC lock에 대한 제 거 요청을 보냄
요청을 보낸 후 이에 대한 응답을 받아서 처리
Garbage Collector
WLGC, CLGC
주기적으로 lock resource을 관리하고 타임아웃을 체크하는 스레드
WLGC, CLGC 스레드는 다음과 같은 특징이 있음
DDD(Distributed Deadlock Detection)를 수행하기 위해 주기적으로 타임아 웃이 발생한 lock waiter를 체크. 체크할 때 교착 상태가 발생하면 DDD 를 시작
MTC retransmission queue에 설정된 메시지를 주기적으로 검사해서 타임 아웃이 발생한 메시지를 다시 전송
주기적으로 TSN의 동기화를 수행(이 특징은 WLGC 스레드만이 수행할 수 있다).
lock resource를 위한 공유 메모리가 부족하게 되면 resource block reclaiming 을 시작하여 필요한 리소스를 확보
Reconfigurator
WRCF, CRCF
NMGR 스레드로부터 node join 및 leave event를 받아 CWS/CCC lock remas tering/reconfiguration을 수행
Node Manager
NMGR
TBCM과 통신하여 node join 및 leave event를 받아 처리하며 node 멤버십을 관리
또한 WRCF, CRCF 스레드에 의해 수행되는 CWS/CCC reconfigu ration을 통제(suspend 또는 resume)
TAC 환경설정
TAC는 기본적으로 싱글 인스턴스일 때의 설정은 그대로 사용합니다. 이 외에는 추가로 설정해야 할 초기화 파라미터와 주의 사항이 있습니다.
다음은 TAC를 사용하기 위해 추가로 설정해야 하거나 주의해야 하는 초기화 파라미터의 예입니다.
<<$TB_SID.tip>>
MEMORY_TARGET
인스턴스가 사용할 전체 메모리의 크기를 설정
이것은 공유 메모리, 정렬 및 해시 등의 메모리를 요구하는 연산에서 사용하는 메모리, DBMS 내부에서 사용되는 기타 메모리를 모두 포함
이 중에 공유 메모리는 DBMS의 부팅과 동시에 점유하게 되지만 나머지 메모리는 필요에 따라 할 당 및 해제를 반복하게 됨
TOTAL_SHM_SIZE
인스턴스가 사용할 전체 공유 메모리의 크기를 설정
DB_CACHE_SIZE
TAC는 버퍼 캐시 이외에도 사용하는 공유 메모리가 많음
따라서 버퍼 캐 시의 크기를 싱글 인스턴스의 경우보다 더 작게 설정해야 함
일반적으로 전체 공유 메모리 크기의 절반 정도가 적절
CLUSTER_DATABASE
TAC를 사용할 때 설정합니다. 초기화 파라미터의 값은 반드시 'Y'로 설정해야 함
THREAD
Redo 스레드의 번호로 각 인스턴스마다 고유의 번호를 부여
UNDO_TABLESPACE
Undo 테이블 스페이스의 이름으로 각 인스턴스마다 고유하게 부여
LOCAL_CLUSTER_ADDR
TAC 인스턴스 간에 통신할 내부 IP 주소를 설정
LOCAL_CLUSTER_PORT
TAC 인스턴스 간에 통신할 내부 포트 번호를 설정
이 포트는 노드 간 에 열려 있어야 함
CM_PORT
인스턴스가 CM과 통신하기 위한 포트 번호를 설정
접속할 CM의 초 기화 파라미터 중 CM_UI_PORT 파라미터와 동일하게 설정
다음은 TAC를 설정할 때 주의해야 할 사항입니다.
Redo 스레드의 번호와 Undo 테이블 스페이스의 이름은 동일한 데이터베이스를 서비스하는 서버 사이 에서 유일해야 합니다. “TAC를 위한 데이터베이스 생성”에서 생성한 이름이어야 합니다.
모든 서버의 인스턴스의 설정 파일에 CONTROL_FILES와 DB_CREATE_FILE_DEST는 물리적으로 같은 파일이거나 또는 같은 디바이스를 가리키도록 설정해야 합니다.
15.5.TAC를 위한 데이터베이스 생성
TAC는 공유 디스크 기반의 클러스터 데이터베이스입니다. 여러 데이터베이스 서버의 인스턴스가 물리적으 로 같은 데이터베이스 파일을 보고 사용하기 때문에 데이터베이스 생성은 한 서버에서 한 번만 수행하면 됩니다.
모든 서버의 인스턴스가 동일한 컨트롤 파일 및 데이터 파일을 읽고 쓰게 됩니다. 반면 TAC에서는 공유 디 스크에서 데이터 접근의 경합을 최소화하기 위해 Redo 로그 및 Undo에 대해서는 인스턴스마다 별도의 파일을 가지고 있어야 합니다. Redo 로그 및 Undo 정보는 각 서버의 인스턴스들이 별도의 파일에 저장하지 만 복구 상황 등에 따라 다른 인스턴스의 정보를 읽어야 하므로 반드시 공유 디스크상에 존재해야 합니다.
TAC를 위한 데이터베이스 생성 절차는 다음과 같습니다.
Tibero와 관련된 환경설정 파일을 설정한 후 TBCM을 기동합니다. CM을 설정하고 기동하는 자세한 방법 은 “Tibero Cluster Manager”를 참고합니다.
TBCM을 기동했지만 Tibero를 직접 제어하지는 않습니다.
NOMOUNT 모드로 Tibero를 기동합니다.
SYS 사용자로 접속한 후 CREATE DATABASE 문을 통해 데이터베이스를 생성합니다.
① DB_NAME을 지정합니다.
② 접근할 서버의 최대 인스턴스의 개수를 8로 지정합니다.
기존의 CREATE DATABASE 문과 비교해 달라진 부분은 없습니다. 다만, 데이터베이스 파일을 공유할 인 스턴스의 최대 개수를 나타내는 MAXINSTANCE 파라미터를 주의해야 합니다. 이 파라미터의 값은 컨트 롤 파일과 데이터 파일의 헤더 등에 영향을 미치며 설정된 값 이상으로 Tibero의 인스턴스를 추가할 수 없으므로 TAC를 위해 데이터베이스를 생성할 때 충분한 값을 설정해야 합니다.
앞서 설명한 것처럼 각 서버의 인스턴스는 별도의 Redo 및 Undo 공간을 가져야 합니다. CREATE DATABASE 문을 실행한 시점에 생성된 Undo 테이블 스페이스 및 Redo 로그 파일은 첫 번째 인스턴스 를 위한 것으로 다른 인스턴스가 데이터베이스에 접근하기 위해서는 별도의 Redo 로그 그룹과 Undo 테이블 스페이스를 생성하는 것이 필요합니다.
생성된 Redo 로그 그룹은 자동으로 0번의 Redo 스레드가 됩니다. 따라서 CREATE DATABASE 문을 실 행하기 전에 서버 인스턴스의 환경설정 파일($TB_SID.tip)의 THREAD 초기화 파라미터와 UNDO_TA BLESPACE 초기화 파라미터는 다음과 같이 설정되어 있어야 합니다.
CREATE DATABASE 문을 실행하고 나면 Tibero가 자동으로 종료됩니다. Tibero를 다시 기동한 후 SYS 사용자로 접속하여 다음과 같이 Undo 테이블 스페이스와 새로운 Redo 로그 그룹을 만들고 DDL 문장 을 수행합니다.
① Redo 스레드를 활성화하는 DDL 문장을 실행합니다.
Redo 로그 그룹을 추가하기 위한 기존의 DDL 문장과 같지만 THREAD 번호를 지정했다는 것에 주의 해야 합니다. 이 예제에서는 두 번째 인스턴스가 사용할 Undo 테이블 스페이스 UNDO1과 Redo 스레드 1을 위한 Redo 로그 그룹을 추가하고 활성화시키는 과정을 보여주고 있습니다.
Redo 스레드는 숫자로 지정하며 CREATE DATABASE 문을 실행할 시점에 생성한 Redo 로그 그룹이 0번 스레드가 되므로 반드시 1부터 지정해야 합니다. 0번 스레드는 CREATE DATABASE 문을 실행할 시 점에 자동으로 활성화됩니다.
주의
Redo 로그 그룹의 번호는 Redo 스레드 내에서가 아니라 데이터베이스 전체에서 유일해야 하므로 이미 사용된 0, 1, 2를 사용할 수 없습니다. 또한 최소한 두 개 이상의 Redo 로그 그룹이 존재해야만 해당 Redo 스레드를 활성화시킬 수 있습니다. 또 다른 인스턴스를 추가하려면 위와 같은 과정을 참고하여 Undo 테이블 스페이스와 Redo 스레드를 생성하고 스레드를 활성화합니다.
TAC raw device 환경 또는 공유 파일 시스템이면서 DB_CREATE_FILE_DEST가 적절한 경로로 지정 되지 않은 환경에서는 Tibero가 정상적으로 기동되지 않을 수 있습니다. 이와 같은 경우 다음과 같이 TPR 관련 정보를 저장할 테이블 스페이스(SYSSUB)를 먼저 추가해야 합니다. 테이블 스페이스 생성에 대한 자세한 내용은 "테이블 스페이스 생성, 제거"를 참고합니다.
참고
이 과정을 생략하고 다음 단계를 수행한 경우 "Tibero 설치 안내서"의 "TAC 설치와 제거"와 "Appendix A. 설치 후 문제 해결"을 참고합니다.
$TB_HOME/scripts 디렉터리에 있는 system_install.sh 스크립트 파일을 실행합니다. Windows 환경에서는 system_install.vbs 파일입니다.
다른 서버의 인스턴스를 기동하고 운영합니다.
TAC 실행
본 절에서는 TAC 실행에 필요한 사항과 데이터베이스 생성, TAC의 기동 및 모니터링 방법에 대해서 설명합니다.
실행 전 준비 사항
TAC는 모든 인스턴스가 같이 사용할 수 있는 공유 디스크의 공간과 인스턴스 간의 통신이 가능한 네트워 크만 있으면 실행할 수 있습니다.
TAC를 실행하기 전에 준비해야 할 H/W 요구사항과 운영체제 설정은 다음과 같습니다.
공유 디스크의 공간
TAC의 실행과 운영을 위해서는 최소 7개의 공유 파일이 필요합니다.
컨트롤 파일
Redo 로그 파일 2개
Undo 로그 파일
시스템 테이블 스페이스 파일
임시 테이블 스페이스 파일
TBCM 파일
인스턴스 하나를 추가 할 때마다 최소 3개의 공유 파일이 추가로 필요합니다.
Redo 로그 파일 2개
Undo 로그 파일
공유 디스크의 권한
공유 파일 시스템을 사용할 경우에는 TAC가 사용할 디렉터리의 권한, RAW 파일 시스템을 사용할 경우 에는 각 RAW 파일의 권한을 TAC가 읽고 쓸 수 있도록 설정합니다.
내부 네트워크의 설정
TAC의 실행과 운영을 위해 내부 네트워크는 외부 네트워크와 분리하는 것이 데이터베이스 성능에 좋 다. 내부 네트워크의 인터페이스와 IP, 속도 등을 점검합니다.
참고
TAC에서 내부 네트워크를 구성할 때 크로스오버 케이블을 이용한 방식은 지원하지 않습니다.
데이터베이스 생성
TAC를 처음 기동할 때는 데이터베이스를 생성해야 합니다. 클러스터로 사용할 한 노드에서 생성하면 됩니다. TAC로 Tibero를 기동할 때에는 CM이 필수이므로 CM을 먼저 설정한 후 시작하고 Tibero를 NOMOUNT 모드로 기동합니다. CM 설정에 관한 내용은 자세한 방법은 “Tibero Cluster Manager”를 참고합니다.
다음은 CM 설정을 마친 후 Tibero를 NOMOUNT 모드로 기동하는 예입니다.
NOMOUNT 모드로 기동된 첫 번째 TAC의 인스턴스에 접속하여 데이터베이스를 만든 후 다른 클러스터 의 인스턴스를 위한 Redo 로그, Undo 로그를 생성합니다. 인스턴스의 $TB_SID.tip 환경설정 파일에 지정한 THREAD, UNDO_TABLESPACE 초기화 파라미터의 이름과 반드시 일치해야 합니다.
TAC 기동
데이터베이스 생성과 다른 인스턴스를 위한 환경설정 파일의 생성이 모두 완료하면 TAC를 기동할 수 있 다.
다음은 다른 인스턴스를 모두 실행하고 CM, Tibero 순으로 TAC를 기동하는 예입니다.
TAC 모니터링
$TB_HOME/scripts 디렉터리에 있는 cm_stat.sh 스크립트 파일을 통해 노드 및 인스턴스의 상태를 모니 터링할 수 있습니다. TAC에 참여한 노드의 현재 상태, IP 정보 등을 주기적으로 확인할 수 있습니다.
Tibero는 글로벌 뷰(Global View)를 제공합니다. 싱글 인스턴스에서 사용하는 모든 모니터링 뷰를 TAC의 인 스턴스에서 조회할 수 있습니다.
다음은 모든 클러스터에 연결되어 있는 세션을 확인하는 예입니다. tbSQL 유틸리티, tbAdmin 툴을 통해 다 음과 같은 SQL 문장을 실행합니다.
[예 1] 글로벌 뷰의 조회 - GV$SESSION
참고
글로벌 뷰에서 조회되는 INST_ID는 INSTANCE_NUMBER와는 별개의 값이며, CM 기동 순서에 따 라 변경될 수 있습니다.
Last updated