내용 목차
본 장에서는 Tibero Active Cluster의 기본 개념과 구성요소, 프로세스, 실행 및 운영 방법을 설명한다.
Tibero Active Cluster(이하 TAC)는 확장성, 고가용성을 목적으로 제공하는 Tibero의 주요 기능이다. TAC 환경에서 실행 중인 모든 인스턴스는 공유된 데이터베이스를 통해 트랜잭션을 수행하며 공유된 데이터에 대한 접근은 데이터의 일관성과 정합성 유지를 위해 상호 통제하에 이뤄진다.
큰 업무를 작은 업무의 단위로 나누어 여러 노드 사이에 분산하여 수행할 수 있기 때문에 업무 처리 시간을 단축할 수 있다.
여러 시스템이 공유 디스크를 기반으로 데이터 파일을 공유한다. TAC 구성에 필요한 데이터 블록은 노드 간을 연결하는 고속 사설망을 통해 주고받음으로써 노드가 하나의 공유 캐시(shared cache)를 사용하는 것처럼 동작한다. 운영 중에 한 노드가 멈추더라도 동작 중인 다른 노드들이 서비스를 지속하게 된다. 이러한 과정은 투명하고 신속하게 처리된다.
TAC의 구조는 다음과 같은 모듈로 구성되어 있다.
CWS(Cluster Wait-lock Service)
기존 Wait-lock(이하 Wlock)이 클러스터 내에서 동작할 수 있도록 구현된 모듈이다. Distributed Lock Manager(이하 DLM)이 내장되어 있다.
Wlock은 GWA를 통해 CWS에 접근할 수 있으며 이와 관련된 배경 스레드로는 WATH, WLGC, WRCF이 존재한다.
Wlock은 CWS를 사용하기 위한 인터페이스 역할을 수행하는 모듈이다.
CWS에 접근하기 위한 핸들인 CWS Lock Status Block(이하 LKSB)과 파라미터를 설정하고 관리한다.
Wlock에서 사용하는 잠금 모드(Lock mode)와 타임아웃(timeout)을 CWS에 맞게 변환하며 CWS에서 사용할 Complete Asynchronous Trap(이하 CAST), Blocking Asynchronous Trap(이하 BAST)을 등록할 수 있다.
데이터베이스의 데이터 블록에 대한 클러스터 내 접근을 통제하는 모듈이다. DLM이 내장되어 있다.
CR Block Server, Current Block Server, Global Dirty Image, Global Write 서비스가 포함되어 있다.
Cache layer에서는 GCA(Global Cache Adapter)를 통해 CCC에 접근할 수 있으며 이와 관련된 배경 스레드로 CATH, CLGC, CRCF이 존재한다.
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를 사용하는 사용자에게 네트워크 토폴로지(network topology)와 프로토콜을 투명하게 제공하며 TCP, UDP 등의 프로토콜을 관리한다.
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
Diagnostic Thread
Cluster Message Processor(Message handler)
Asynchronous Thread
Garbage Collector
Reconfigurator
Node Manager
TAC는 기본적으로 싱글 인스턴스일 때의 설정은 그대로 사용한다. 이 외에는 추가로 설정해야 할 초기화 파라미터와 주의 사항이 있다.
다음은 TAC를 사용하기 위해 추가로 설정해야 하거나 주의해야 하는 초기화 파라미터의 예이다.
<<$TB_SID.tip>>
MEMORY_TARGET=6144M TOTAL_SHM_SIZE=4096M DB_CACHE_SIZE=2048M CLUSTER_DATABASE=Y THREAD=0 UNDO_TABLESPACE=UNDO0 LOCAL_CLUSTER_ADDR=192.168.1.1 LOCAL_CLUSTER_PORT=12345 CM_PORT=30000
초기화 파라미터 | 설명 |
---|---|
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 테이블 스페이스의 이름은 동일한 데이터베이스를 서비스하는 서버 사이에서 유일해야 한다. “15.5. TAC를 위한 데이터베이스 생성”에서 생성한 이름이어야 한다.
모든 서버의 인스턴스의 설정 파일에 CONTROL_FILES와 DB_CREATE_FILE_DEST는 물리적으로 같은 파일이거나 또는 같은 디바이스를 가리키도록 설정해야 한다.
TAC는 공유 디스크 기반의 클러스터 데이터베이스이다. 여러 데이터베이스 서버의 인스턴스가 물리적으로 같은 데이터베이스 파일을 보고 사용하기 때문에 데이터베이스 생성은 한 서버에서 한 번만 수행하면 된다.
모든 서버의 인스턴스가 동일한 컨트롤 파일 및 데이터 파일을 읽고 쓰게 된다. 반면 TAC에서는 공유 디스크에서 데이터 접근의 경합을 최소화하기 위해 Redo 로그 및 Undo에 대해서는 인스턴스마다 별도의 파일을 가지고 있어야 한다. Redo 로그 및 Undo 정보는 각 서버의 인스턴스들이 별도의 파일에 저장하지만 복구 상황 등에 따라 다른 인스턴스의 정보를 읽어야 하므로 반드시 공유 디스크상에 존재해야 한다.
TAC를 위한 데이터베이스 생성 절차는 다음과 같다.
Tibero와 관련된 환경설정 파일을 설정한 후 TBCM을 기동한다. CM을 설정하고 기동하는 자세한 방법은 “제14장 Tibero Cluster Manager”를 참고한다.
$ tbcm -b
TBCM을 기동했지만 Tibero를 직접 제어하지는 않는다.
NOMOUNT 모드로 Tibero를 기동한다.
$ tbboot -t NOMOUNT -c
SYS 사용자로 접속한 후 CREATE DATABASE 문을 통해 데이터베이스를 생성한다.
[tibero@tester ~]$ tbsql sys/tibero SQL> CREATE DATABASE "ac" ... ① ... USER sys IDENTIFIED BY tibero MAXINSTANCES 8 ... ② ... MAXDATAFILES 256 CHARACTER SET MSWIN949 LOGFILE GROUP 0 'log001' SIZE 50M, GROUP 1 'log011' SIZE 50M, GROUP 2 'log021' SIZE 50M MAXLOGFILES 100 MAXLOGMEMBERS 8 NOARCHIVELOG DATAFILE 'system001' SIZE 512M AUTOEXTEND ON NEXT 8M MAXSIZE 3G DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE 'temp001' SIZE 512M AUTOEXTEND ON NEXT 8M MAXSIZE 3G EXTENT MANAGEMENT LOCAL AUTOALLOCATE UNDO TABLESPACE UNDO0 DATAFILE 'undo001' SIZE 512M AUTOEXTEND ON NEXT 8M MAXSIZE 3G EXTENT MANAGEMENT LOCAL AUTOALLOCATE Database created.
① 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_TABLESPACE
초기화 파라미터는 다음과 같이 설정되어
있어야 한다.
THREAD=0 UNDO_TABLESPACE=UNDO0
CREATE DATABASE 문을 실행하고 나면 Tibero가 자동으로 종료된다. Tibero를 다시 기동한 후 SYS 사용자로 접속하여 다음과 같이 Undo 테이블 스페이스와 새로운 Redo 로그 그룹을 만들고 DDL 문장을 수행한다.
[tibero@tester ~]$ tbboot [tibero@tester ~]$ tbsql sys/tibero SQL> CREATE UNDO TABLESPACE UNDO1 DATAFILE 'undo011' SIZE 512M AUTOEXTEND ON NEXT 8M MAXSIZE 3G EXTENT MANAGEMENT LOCAL AUTOALLOCATE Tablespace 'UNDO1' created.
SQL> ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 3 'log031' size 50M;
Database altered.
SQL> ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 4 'log041' size 50M;
Database altered.
SQL> ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 5 'log051' size 50M;
Database altered.
SQL> ALTER DATABASE ENABLE PUBLIC THREAD 1; ... ① ...
Database altered.
① 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@tester ~]$ tbsql sys/tibero SQL> CREATE TABLESPACE SYSSUB DATAFILE '<SYSSUB 위치>/syssub001.dtf' ...; Tablespace 'SYSSUB' created.
이 과정을 생략하고 다음 단계를 수행한 경우 "Tibero 설치 안내서"의 "7장 TAC 설치와 제거"와 "Appendix A. 설치 후 문제 해결"을 참고한다.
$TB_HOME/scripts 디렉터리에 있는 system.sh 스크립트 파일을 실행한다. Windows 환경에서는 system.vbs 파일이다.
[tibero@tester scripts]$ system.sh $TB_HOME/bin/tbsvr Creating the role DBA... Creating system users & roles... Creating virtual tables(1)... Creating virtual tables(2)... Granting public access to _VT_DUAL... Creating the system generated sequences... Creating system packages: Running /home/tibero/tibero7/scripts/pkg_standard.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_output.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_lob.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_utility.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_obfuscation.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_transaction.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_random.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_lock.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_system.sql... Running /home/tibero/tibero7/scripts/pkg_dbms_job.sql... Running /home/tibero/tibero7/scripts/pkg_utl_raw.sql... Running /home/tibero/tibero7/scripts/pkg_utl_file.sql... Running /home/tibero/tibero7/scripts/pkg_tb_utility.sql... Creating public synonyms for system packages... ............................................
다른 서버의 인스턴스를 기동하고 운영한다.
본 절에서는 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 설정에 관한 내용은 자세한 방법은 “제14장 Tibero Cluster Manager”를 참고한다.
다음은 CM 설정을 마친 후 Tibero를 NOMOUNT 모드로 기동하는 예이다.
tac1@tester ~]$ tbboot -t NOMOUNT listener port = xxxx change core dump dir to /home/tibero7/bin/prof Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NOMOUNT mode). tac1@tester ~]$
NOMOUNT 모드로 기동된 첫 번째 TAC의 인스턴스에 접속하여 데이터베이스를 만든 후 다른 클러스터의 인스턴스를 위한 Redo 로그, Undo 로그를 생성한다. 인스턴스의 $TB_SID.tip 환경설정 파일에 지정한 THREAD, UNDO_TABLESPACE 초기화 파라미터의 이름과 반드시 일치해야 한다.
데이터베이스 생성과 다른 인스턴스를 위한 환경설정 파일의 생성이 모두 완료하면 TAC를 기동할 수 있다.
다음은 다른 인스턴스를 모두 실행하고 CM, Tibero 순으로 TAC를 기동하는 예이다.
tac2@tester ~]$ tbcm -b CM Guard daemon started up. import resources from 'CM TIP에 입력된 resource file path'... Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero cluster manager started up. Local node name is (cm0:xxxx). tac2@tester ~]$ tbboot listener port = xxxx change core dump dir to /home/tibero7/bin/prof Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero instance started up (NORMAL mode). tac2@tester ~]$
$TB_HOME/scripts 디렉터리에 있는 cm_stat.sh 스크립트 파일을 통해 노드 및 인스턴스의 상태를 모니터링할 수 있다. TAC에 참여한 노드의 현재 상태, IP 정보 등을 주기적으로 확인할 수 있다.
Tibero는 글로벌 뷰(Global View)를 제공한다. 싱글 인스턴스에서 사용하는 모든 모니터링 뷰를 TAC의 인스턴스에서 조회할 수 있다.
다음은 모든 클러스터에 연결되어 있는 세션을 확인하는 예이다. tbSQL 유틸리티, tbAdmin 툴을 통해 다음과 같은 SQL 문장을 실행한다.
글로벌 뷰에서 조회되는 INST_ID는 INSTANCE_NUMBER와는 별개의 값이며, CM 기동 순서에 따라 변경될 수 있다.