내용 목차
본 장에서는 Tibero Cluster Manager의 기본 개념과 환경설정 및 실행 방법을 설명한다.
Tibero Cluster Manager(이하 CM)는 클러스터의 가용성을 높이고 관리의 편의를 지원한다. 또한, Tibero Active Cluster 서비스를 위한 인스턴스간 멤버십 관리를 지원한다. CM에서는 클러스터의 각종 구성 요소들을 리소스라는 개념으로 관리하도록 되어있다.
다음은 현재 CM에서 관리 가능한 클러스터 리소스이다.
File
Network
Cluster
Service
DB(Database)
AS(Active Storage)
VIP
CM은 등록된 리소스들에 대한 모니터링을 수행하며, 상태 변화에 따른 필요 동작들을 수행한다. 설정을 통해 같은 클러스터에 속하게 된 CM들 간에는 지정된 네트워크와 공유 디스크를 통해 주기적으로 자신이 살아있음을 알리는 Heartbeat를 서로 주고받으며 클러스터의 멤버십 구성을 파악하게 된다.
클러스터 구성 CM 중 하나의 CM이 마스터의 역할을 맡아 비정상적인 상황이 발생하는 경우 클러스터 멤버십을 자동으로 변경하여, 해당 클러스터 상의 서비스가 중단되지 않도록 한다. 마스터에 문제가 생긴 경우 클러스터에 속한 다른 노드가 마스터 역할을 넘겨 받는다.
환경변수 CM_HOME과 CM_SID를 설정해야 한다. 다음은 그 예제이다. 이 외에 RDBMS를 실행하기 위해 필요한 기본 환경변수들은 “제2장 관리의 기본”을 참고하여 설정한다.
환경변수 | 설명 |
---|---|
$CM_HOME | CM이 설치된 경로를 지정한다.
|
$CM_SID | 노드를 식별할 수 있는 ID를 지정한다. 각 노드는 서로 다른 값을 가져야 한다.
|
CM용 TIP에는 다음과 같은 파라미터들을 설정할 수 있다. 필수 항목은 사용자가 TIP에 명시적으로 값을 지정해야 하며, 선택 항목은 사용자가 지정하지 않을 수 있고 이 경우 기본값으로 입력된다.
초기화 파라미터 | 필수 여부 | 설명 |
---|---|---|
CM_NAME | 필수 | 클러스터를 생성할 때에 node identifier로 쓸 이름이다. 서로 다른 노드의 CM은 다른 값을 가져야 한다. |
CM_UI_PORT | 필수 | cmrctl 명령어 수행할 때에 CM으로 접속하는 용도로 사용할 네트워크 포트 번호이다. 이 포트는 노드 간에 열려 있어야 한다. |
CM_RESOURCE_FILE | 필수 | CM 리소스 파일의 경로를 지정한다. CM 리소스 파일은 다음과 같은 상황에 사용된다.
|
CM_RESOURCE_FILE_BACKUP | 선택 | CM 리소스 파일의 백업 경로를 지정한다. |
CM_RESOURCE_FILE_BACKUP_INTERVAL | 선택 | CM_RESOURCE_FILE_BACKUP 경로에 CM 리소스 파일의 백업을 수행할 시간 간격을 나타낸다. (단위: 분) |
LOG_LVL_CM | 선택 | CM이 로그를 남기는 수준을 지정한다. 값이 높을수록 CM이 더 많은 로그를 저장하며, 1~6 사이의 정수값을 가질 수 있다. (기본값: 2) |
CM_LOG_DEST | 선택 | CM이 로그를 남길 디렉터리를 지정한다. 이 값은 반드시 절대 경로여야 한다. (기본값: $CM_HOME/instance/$CM_SID/log/) |
CM_GUARD_LOG_DEST | 선택 | CM Guard가 로그 파일을 저장할 장소로 이 값은 반드시 로컬 디스크의 절대 경로여야 한다. 또한, CM이 root로 실행되어야만 CM Guard가 로그를 남길 수 있다. 다음은 각 플랫폼별 기본값이다.
|
CM_LOG_FILE_SIZE | 선택 | CM 로그 파일의 최대 크기(용량)를 지정한다. 로그가 계속 생성되어 파일의 크기가 이 값을 넘어서려 할 경우 현재의 로그 파일이 닫히고, 새로운 파일이 생성되어 그 파일에 로그가 저장된다. 값은 100KB~1GB 사이의 정수값을 가질 수 있다. (단위: Byte, 기본값: 10MB) |
CM_LOG_TOTAL_SIZE_LIMIT | 선택 | CM_LOG_DEST에서 지정한 디렉터리에 생성되는 로그 파일들의 크기 총합의 최댓값을 지정한다. 로그 파일들의 크기의 합이 이 값을 넘어가게 되면, 가장 오래된 파일을 삭제함으로써 파일 용량이 끝없이 증가하는 것을 막는다. 이 값은 100KB~1GB 사이의 정수값을 가질 수 있다. (단위: byte, 기본값: 300MB) |
CM_TIME_UNIT | 선택 | CM을 컨트롤할 때 사용되는 단위 시간의 길이를 지정한다. (단위: 0.1초, 기본값: 10) |
CM_HEARTBEAT_EXPIRE | 선택 | Heartbeat expire란 다른 노드의 CM에 문제가 생겼다는 것을 CM이 알아차리는데 필요한 표준 시간을 의미한다. 즉, 현재 노드의 CM에서 Heartbeat expire 시간이 지나도록 통신이 되지 않는 CM이 있으면, 현재 노드의 CM은 통신이 되지 않는 노드의 CM에 문제가 생겼다고 인식하게 된다. (단위: 초(second), 기본값: 300) |
CM_NET_EXPIRE_MARGIN | 선택 | CM을 컨트롤하기 위한 네트워크의 Heartbeat expire 시간이다. 이 값은 5보다 크거나 같아야 한다. (단위: 초(second), 기본값: 5) |
CM_WATCHDOG_EXPIRE | 선택 | RDBMS와 CM 사이에 watchdog 기능이 활성화되어 있을 경우 만료 기간(expiration period)을 지정한다. 만약 CM이 이 값이 지정한 시간 동안 동작하지 않으면, RDBMS가 자동적으로 종료된다. CM_HEARTBEAT_EXPIRE보다 작은 값을 사용해야 한다. (단위: 초(second), 기본값: 290) |
CM_FENCE | 선택 | CM fence 데몬을 실행시킬지를 결정한다. CM이 I/O 수행을 CM_WATCHDOG_EXPIRE에 지정된 시간보다 오래할 경우, 다른 CM들이 이 CM의 노드를 클러스터에서 제외시키기 때문에 이 CM의 노드는 OS를 재부팅해야 한다(그 노드의 RDBMS가 I/O하는 것을 막기 위해). CM fence 데몬은 이러한 일을 수행하며, 재부팅 권한이 필요하므로 이 값을 Y로 지정하려면 CM이 ROOT 권한으로 실행되어야 한다. (기본값: N) |
CM_ENABLE_FAST_NET_ERROR_DETECTION | 선택 | 다른 CM들과 연결된 네트워크의 장애를 감지함으로써 다른 CM의 상태 변화를 빨리 알아차릴 수 있도록 하는 기능을 활성화시킬지를 결정한다. (기본값: N) |
_CM_BLOCK_SIZE | 선택 | CM 파일의 I/O 단위 크기로 Byte 단위이다. 대부분의 운영체제는 기본값을 사용하면 되지만, HP-UX는 1024를 사용해야 한다. (기본값: 512) |
CM 데몬 실행 이후의 작업들은 cmrctl 명령어를 사용하여 수행한다.
CM은 다음의 방법으로 실행한다.
tbcm [option] <argument>
[option]
항목 | 설명 |
---|---|
-b | CM 데몬을 실행한다. |
-d | CM 데몬을 종료한다. |
-i <file path> | 지정된 경로의 text 파일에서 리소스 정보를 import한다. |
-e <file path> | 현재 CM에 추가된 리소스 정보를 지정된 경로에 text 파일로 export한다. |
-x <file path> | 현재 CM에 추가된 리소스 정보를 지정된 경로에 파일로 export한다. |
-X | 현재 CM에 추가된 리소스 정보를 CM_RESOURCE_FILE로 지정해 놓은 경로에 export한다. |
-s | CM의 상태를 보여준다. 초기화 파라미터에 등록된 내용이 표시된다. |
-v | CM의 버전을 보여준다. |
-h | tbcm 명령어에 대한 도움말을 보여준다. |
본 절에서는 CM 명령어인 cmrctl, crfconf에 대해서 설명한다.
cmrctl은 New CM에서 리소스들을 관리 및 제어하기 위해 사용하는 명령어 set이다.
기본적인 cmrctl 명령어 용법은 다음과 같다.
cmrctl <action> <resource_type> [--<attr_key> <attr_val>|...]
항목 | 설명 |
---|---|
action | add, del, show, start, stop, act, deact, modify, relocate |
resource_type | network, cluster, service, db, as, vip, file |
어떤 action, resource type의 조합은 사용이 불가능할 수도 있다. (예: add, file)
같은 클러스터를 구성 중인 CM에 대해서 cmrctl 명령에 추가 attribute를 명시함으로써 원격 제어가 가능하다. 원격 제어를 할 CM 노드의 이름과 해당 노드가 속한 클러스터의 이름을 알고 있어야 하며, 다음과 같은 attribute를 cmrctl 명령에 추가한다.
--remote <node_name>@<cluster_name>
다음의 예제 구문처럼 해당 attribute는 cmrctl add와 cmrctl del 명령에는 사용할 수 없다.
# cls1 클러스터에 속한 cm2 노드의 리소스 조회 $ cmrctl show --remote cm2@cls1 # cls1 클러스터에 속한 cm1 노드의 tibero1 db down $ cmrctl stop db --name tibero1 --remote cm1@cls1 # 원격으로 resource add 시 error 발생 $ cmrctl add db --name tac1 ... --remote cm1@cls1 [ERROR] Cannot add (or delete) resource remotely
지정한 클러스터가 down 상태이거나 지정한 노드가 down 상태일 경우 또는 잘못된 클러스터/노드 이름을 입력했을 경우에는 에러 메시지를 출력한다.
cmrctl add는 다음의 명령어로 구성된다.
명령어 | 설명 |
---|---|
cmrctl add network | 네트워크 리소스를 추가하기 위한 명령어이다. |
cmrctl add cluster | 클러스터 리소스를 추가하기 위한 명령어이다. |
cmrctl add service | 서비스 리소스를 추가하기 위한 명령어이다. |
cmrctl add db | Tibero 인스턴스를 추가하는 명령어이다. |
cmrctl add as | AS(Active Storage) 인스턴스를 추가하는 명령어이다. |
cmrctl add vip | VIP를 등록하기 위한 명령어이다. |
네트워크 리소스를 추가하기 위한 명령어이다. 네트워크가 public/private 용도에 따라서 필요한 attribute가 나뉜다. 네트워크 리소스는 interconnect로 사용할 IP, PORT 조합이나 VIP 등록을 위해 필요한 public 네트워크 인터페이스 등록을 위해 사용하는 자원이다. 등록된 이후에 지정된 네트워크 인터페이스를 감시하여 자동으로 상태를 갱신한다.
cmrctl add network --name <network_name> --nettype <private|public> --ipaddr <network_ipaddr/netmask_addr> --portno <port_no> --ifname <interface_name>
Key | Value Type | 설명 |
---|---|---|
name | string | 네트워크 리소스 이름이다. (unique, mandatory) |
nettype | string | 네트워크 리소스의 type이다.
|
ipaddr | string | interconnect로 사용할 IP 주소이다. 이 포트는 노드 간에 열려 있어야 한다. (only for nettype 'private'. mandatory) |
portno | integer | CM 간의 interconnect로 사용할 포트 번호이다. (only for nettype 'private', mandatory) |
ifname | string | public 용도로 사용할 interface name(VIP 등록용)이다. (only for nettype 'public', mandatory) |
클러스터 리소스를 추가하기 위한 명령어이다. 클러스터 리소스는 환경의 개념으로 노드 간 연결에 사용하는 interconnect, 노드 간 공유하는 스토리지, VIP를 사용하는 경우에 필요한 public network interface로 구성된다.
cmrctl add cluster --name <cluster_name> --incnet <network_resource_name> --pubnet <public_network_resource_name> --cfile <file_path>
Key | Value Type | 설명 |
---|---|---|
name | string | 클러스터 리소스 이름이다. (unique, mandatory) |
incnet | string | interconnect 용도로 사용할 네트워크 리소스 이름이다. (mandatory) |
pubnet | string | public 용도로 사용할 네트워크 리소스 이름이다. VIP를 사용하는 경우 등록한다. |
cfile | file path | 클러스터 파일 경로이다. 콤마(,)로 구분하여 여러 개 등록할 수 있다. (mandatory) cfile attribute의 경우 가장 앞에 '+'를 붙이면 TAS용 경로(diskstring)로 인식한다.
스토리지 서버를 사용할 경우에는 다음과 같이 지정한다. --cfile "-" [참고] 1. cfile을 TAS상의 경로로 설정할 경우 TAS diskstring과 동일하게 설정해야 하며, TAS diskstring이 아닌 raw device나 파일로 지정할 경우 홀수 개로 지정하는 것을 권장한다(과반 법칙). 2. 파일 리소스의 경우 사용자가 수동으로 추가하는 것이 아니라, 클러스터 리소스의 --cfile로 등록된 내용으로 자동 생성된다. TAS diskstring을 등록한 경우 +0, +1, +2와 같은 형태로 리소스가 생성된다. |
서비스 리소스를 추가하기 위한 명령어이다. 서비스는 클러스터라는 환경 위에서 실제 어떤 서비스를 제공하는 인스턴스의 집합을 관리하기 위한 개념이다.
cmrctl add service --name <service_name> --type <DB|AS> --mode <AC|HA> --cname <cluster_resource_name>
Key | Value Type | 설명 |
---|---|---|
name | string | 서비스 리소스 이름이다. (unique, mandatory) 서비스 리소스 이름은 해당 서비스와 매핑되는 DB의 DB_NAME 파라미터와 같아야 한다(TAS는 TIP 파일에 DB_NAME을 안적어도 되지만, 적는다면 서비스의 이름과 같아야 한다). |
type | string | 서비스 타입이다.
|
mode | string | 서비스 인스턴스 클러스터링 모드이다.
|
cname | string | 해당 서비스 리소스가 속할 클러스터 리소스 이름이다. (mandatory) |
AS 서비스의 경우에는 한 클러스터 당 하나만 등록 가능하다. 서비스 리소스는 특정 클러스터를 지정하여 추가하도록 되어 있는데, 한 노드에 추가하면 해당 노드가 속한 클러스터의 모든 노드에 자동으로 공유된다.
Tibero 인스턴스를 추가하는 명령어이다. DB type의 서비스에만 추가 가능하다.
cmrctl add db --name <db_resource_name> --svcname <service_name> --dbhome <directory_path> --envfile <file_path> --retry_cnt<retry_cnt> --retry_interval<retry_interval>
Key | Value Type | 설명 |
---|---|---|
name | string | DB 리소스 이름이다. DB 리소스의 name은 해당 DB 인스턴스의 TB_SID와 동일해야 한다. (unique, mandatory) |
svcname | string | DB 리소스가 속할 서비스 리소스 이름이다. (mandatory) |
dbhome | string(directory path) | 기존의 TB_HOME 개념으로 DB 바이너리가 위치한 경로이다. (mandatory) |
envfile | string(file path) | DB 바이너리를 실행하기 위한 환경설정용 파일이다. (recommended) [참고] envfile은 DB 리소스별로 지정하는 것을 권장한다. envfile에는 RDBMS를 부팅하고 종료하기 위해 필요한 환경변수들을 export하는 내용이 들어간다. |
retry_cnt | integer | 최대 retry 시도 횟수이다. (기본값: 3) |
retry_interval | integer | retry 시도 간의 간격이다. (단위: 초, 기본값: 0(retry 기능 사용하지 않음)) |
다음은 envfile을 입력하지 않았을 때 default로 수행되는 내용이다. 이 외의 환경변수들은 CM이 부팅할 때 터미널이 가지고 있던 환경변수가 그대로 적용된다. LD_LIBRARY_PATH는 Linux 또는 SunOS를 사용할 경우이고, AIX를 사용할 경우 LIBPATH, HP-UX는 SHLIB_PATH를 export한다. 환경변수 설정에 대한 자세한 내용은 "Tibero 설치 안내서"를 참고한다.
export TB_SID=name #db 리소스의 name export TB_HOME=dbhome #db 리소스의 dbhome export PATH=$TB_HOME/bin:$TB_HOME/client/bin:/usr/bin:$PATH export LD_LIBRARY_PATH=$TB_HOME/lib:$TB_HOME/client/lib:$LD_LIBRARY_PATH
AS(Active Storage) 인스턴스를 추가하는 명령어이다. AS type의 서비스에만 추가 가능하다.
cmrctl add as --name <as_resource_name> --svcname <service_name> --dbhome <directory_path> --envfile <file_path> --retry_cnt<retry_cnt> --retry_interval<retry_interval>
Key | Value Type | 설명 |
---|---|---|
name | string | AS 리소스 이름이다. (unique, mandatory) |
svcname | string | AS 리소스가 속할 서비스 리소스 이름이다. (mandatory) |
dbhome | string(directory path) | 기존의 TB_HOME 개념으로 AS 바이너리가 위치한 경로이다. (mandatory) |
envfile | string(file path) | AS 바이너리를 실행하기 위한 환경설정용 파일이다. (recommended) |
retry_cnt | integer | 최대 retry 시도 횟수이다. (기본값: 3) |
retry_interval | integer | retry 시도 간격이다. (단위: 초, 기본값: 0(retry 기능 사용하지 않음)) |
AS 리소스의 name은 해당 AS 인스턴스의 TB_SID와 동일해야 한다. envfile에 관한 설명은 "cmrctl add db"를 참고한다.
VIP를 등록하기 위해서는 tbcm이 ROOT 권한으로 실행되어 있어야 하며, svcname으로 지정한 서비스에 pubnet attribute가 등록되어 있어야 한다. 환경변수 PATH에 /sbin 경로가 잡혀있지 않으면 VIP alias에 실패하므로 확인해야 한다.
VIP failover/failback
클러스터의 특정 노드에서 장애가 발생하면 사용 중인 VIP를 정상적으로 작동하는 노드 중 한 노드에 VIP를 옮겨 설정한다(failover). 이를 통해서 Tibero는 장애가 발생한 노드의 VIP로도 계속해서 서비스를 할 수 있다. 장애가 발생했던 노드가 복구되면 다시 원래 소유했던 노드로 VIP를 옮겨 설정한다(failback).
cmrctl add vip --name <vip_name> --node <CM_SID> --svcname <service_name> --ipaddr <vip_ipaddr/netmask_addr> --bcast <bcast_addr>
Key | Value Type | 설명 |
---|---|---|
name | string | VIP 리소스 이름이다. (unique, mandatory) |
node | string | VIP를 원래 소유했던 CM_SID 이다. (optional, 기본값: 해당 명령어를 수행한 노드의 CM_SID) |
svcname | string | VIP를 사용할 서비스 이름이다. (mandatory) |
ipaddr | string(IP address/Netmask) | VIP IP address/Netmask로 조합된 주소이다. - IP address (mandatory) - Netmask (optional, 기본값: public interface의 netmask) |
bcast | Broadcast | VIP broadcast 주소이다. (optional) |
VIP로 접속할 때 사용해야 할 포트는 DB인스턴스에서 LISTENER_VIP_PORT로 설정이 가능하다. 설정한 포트는 VIP failback 과정에서 세션을 정리해주기 위해 잠시 막힌다. LISTENER_VIP_PORT와 LISTENER_PORT를 다르게 설정한다면 VIP failback 과정 중에도 LISTENER_PORT로의 접속은 가능하다.
특정 리소스를 삭제하기 위한 명령어이며, DOWN 또는 DEACT 상태의 리소스만 삭제 가능하다.
cmrctl del <resource_type> --name <resource_name>
CM에 등록된 리소스의 정보를 확인하기 위한 명령어이다.
다음의 3가지 방법으로 사용이 가능하다.
방법 1)
cmrctl show
현재 CM 데몬에 등록된 리소스의 목록을 출력한다.
cmrctl show all
현재 CM 데몬의 클러스터에 등록된 모든 노드의 리소스의 목록을 출력한다.
방법 2)
cmrctl show <resource_type>
현재 CM 데몬에 등록된 리소스들 중 <resource_type>의 리소스 목록을 출력한다.
방법 3)
cmrctl show <resource_type> --name <resource_name>
지정한 특정 리소스의 상세한 정보를 출력한다.
특정 리소스를 시작하기 위한 명령어이다. 서비스 리소스를 start하는 경우 해당 서비스에 속한 모든 인스턴스를 기동시킨다.
cmrctl start <resource_type> --name <resource_name> [--option <options>]
특정 리소스를 중지하기 위한 명령어이다. 서비스 리소스를 stop하는 경우 해당 서비스에 속한 모든 인스턴스를 중지시킨다. 또한, auto-restart 기능이 동작 중이라면 중지된다.
auto-restart 모드가 동작 중에 서비스의 인스턴스가 중지된 경우 해당 상황을 인지한 후에 중지된 인스턴스를 재시작시켜주는 기능이다.
cmrctl stop <resource_type> --name <resource_name> [--option <options>]
다음의 이유로 인해 deactivate된 리소스를 다시 activate시켜주기 위한 명령어이다.
DB 또는 AS 리소스를 추가할 때 입력한 retry_cnt(기본값: 3) 이상 start를 수행했는데도 실패한 경우
사용자가 cmrctl deact 명령어를 명시적으로 사용하여 비활성화시킨 경우
서비스 리소스를 act하는 경우에는 해당 서비스 리소스의 인스턴스들에 대한 auto-restart 기능을 동작시키겠다는 의미로 사용된다.
cmrctl act <resource_type> --name <resource_name>
특정 리소스를 deactivate시켜주기 위한 명령어이며, deactivate된 리소스는 auto-restart 대상에서 제외된다. 서비스 리소스를 deact하는 경우에는 해당 서비스 리소스의 인스턴스들에 대한 auto-restart 기능을 중지시키겠다는 의미로 사용된다.
cmrctl deact <resource_type> --name <resource_name>
인스턴트 리소스의 retry_cnt, retry_interval을 변경시켜 주기 위한 명령어이다.
cmrctl modify <resource_type> --name <resource_name> [--option <options>]
cmrctl 명령어의 경우 CM이 온라인 상태일 때 CM에 접속하여 사용자가 리소스를 관리할 수 있는 명령어라면, crfconf는 CM이 오프라인 상태일 때 CM TIP에 지정된 경로에 있는 CM 리소스 파일에 접근하여 해당 파일을 관리할 수 있도록 하는 유틸리티이다. CM 리소스 파일의 경우 바이너리 파일이기 때문에 사용자가 임의로 파일을 수정할 수 없다. 따라서, 사용자가 CM을 부팅하기 전에 CM 리소스 파일에 있는 리소스 정보를 변경하려면 crfconf를 사용하여 원하는 작업을 수행할 수 있다. 이때 VIP 등과 같은 글로벌 리소스의 변경을 시도하는 경우에는 마스터가 관리하기 때문에 마스터로 기동할 CM의 CM 리소스 파일을 변경해야 정상적으로 적용된다.
crfconf의 사용법은 cmrctl과 동일하며, 사용 가능한 action이 add, del, show의 3가지로 제한된다는 점만 다르다.
crfconf <action> <resource_type> [--<attr_key> <attr_val>|...]
CM이 리소스 파일에 접근할 수 있는 CM 동작 상황에서는 crfconf를 수행할 때 다음과 같은 에러를 출력하며 실패로 처리된다.
$ crfconf show [ERROR] CM is online. use 'cmrctl' command crfconf failed!
CM이 VIP 등과 같은 글로벌 리소스를 관리할 때 클러스터의 구성원이 모두 ROOT 권한이어야 하는 일들이 발생한다. 따라서 클러스터 리소스에는 ROOT 모드라는 것이 존재하는 데, 어떤 클러스터에 포함된 모든 CM들이 ROOT 권한으로 실행되었을 때 그 클러스터는 ROOT 모드가 된다. ROOT 모드의 클러스터는 ROOT 모드를 유지하기 위해 ROOT 권한이 없는 CM이 접속하는 것을 막는다.
다음은 클러스터가 ROOT 모드가 되는 두 가지 예이다.
클러스터에 처음 접속한 CM이 ROOT 권한으로 띄워진 경우
이 경우 해당 클러스터는 시작부터 ROOT 모드가 되므로, 이 이후로 클러스터에 접속하려는 CM들은 모두 ROOT 권한으로 실행되어야만 접속이 가능하다.
클러스터 내의 ROOT 권한으로 실행되지 않은 노드들이 모두 down된 경우
5개의 노드로 구성된 클러스터를 생각해보자. 1~2번 노드는 ROOT 권한 없이 실행된 CM이고, 3~5번 노드는 ROOT 권한으로 실행된 CM이라면 이 순간 해당 클러스터는 ROOT 모드가 아니다. 이때 1번과 2번노드를 다운시키면, 클러스터에 접속해있는 CM은 3개가 되고, 3개 모두 ROOT 권한을 가진 CM이므로 클러스터가 ROOT 모드가 된다. 이 후로는 클러스터가 ROOT 모드이기 때문에 1번과 2번 노드가 다시 클러스터에 접속하기 위해서는 ROOT 모드로 CM을 실행시켜야만 한다.
ROOT 모드 클러스터에는 ROOT 권한이 없는 CM이 접속할 수 없으므로, ROOT 모드 클러스터를 ROOT 모드가 아닌 클러스터로 만들려면 모든 노드에서 클러스터를 down시킨 후 ROOT 권한이 없는 CM이 처음 클러스터에 접속하도록 해야 한다. 단, ROOT 모드가 아닌 클러스터에는 ROOT 권한 유무에 상관 없이 CM이 접속할 수 있지만, ROOT 권한을 가진 CM이라 해도 VIP 사용이 불가능하다는 점을 주의할 필요가 있다.
어떤 CM이 ROOT 권한을 가지고 실행되었는지와 클러스터가 ROOT 모드인지는 다음의 방법으로 확인할 수 있다.
cmrctl show cluster --name 'cluster name'
다음은 2-node-cluster에서 두 노드 모두 ROOT 권한이 있는 CM으로 접속한 상황이다. Status의 UP 옆에 (ROOT)라는 표시는 cluster가 ROOT 모드임을 의미하며, NODE LIST에 Mst 아래 R은 각 노드 CM의 ROOT 권한 소유를 의미한다.
cmrctl show cluster --name cls1
Cluster Resource Info
===============================================================
Cluster name : cls1
Status : UP (ROOT)
Master node : (1) cm0
Last NID : 2
Local node : (2) cm1
Storage type : Active Storage
As Diskstring : /data/*
No. of cls files : 3
(1) +0
(2) +1
(3) +2
===============================================================
| NODE LIST |
|-------------------------------------------------------------|
| NID Name IP/PORT Status Schd Mst FHB NHB |
| --- -------- -------------------- ------ ---- --- ---- ---- |
| 1 cm0 123.1.1.1/29000 UP Y R M 30 35 |
| 2 cm1 124.1.1.1/29100 UP Y R [ LOCAL ] |
===============================================================
다음은 두 노드 모두 ROOT 권한이 없는 CM으로 클러스터에 접속한 상황이다. 앞에서와 달리 Status에 (ROOT)가 없고, NODE LIST에도 Mst에 R을 가진 노드가 없다.
cmrctl show cluster --name cls1
Cluster Resource Info
===============================================================
Cluster name : cls1
Status : UP
Master node : (1) cm0
Last NID : 2
Local node : (2) cm1
Storage type : Active Storage
As Diskstring : /data/*
No. of cls files : 3
(1) +0
(2) +1
(3) +2
===============================================================
| NODE LIST |
|-------------------------------------------------------------|
| NID Name IP/PORT Status Schd Mst FHB NHB |
| --- -------- -------------------- ------ ---- --- ---- ---- |
| 1 cm0 123.1.1.1/29000 UP Y M 30 35 |
| 2 cm1 124.1.1.1/29100 UP Y [ LOCAL ] |
===============================================================
다음은 한 노드가 ROOT 권한이 없는 CM으로 클러스터에 접속하고, 다른 노드는 ROOT 권한을 가진 CM으로 접속한 상황이다. 노드 2번만 Mst에 R이 있고, 클러스터가 ROOT 모드가 아니므로 Cluster Resource Info의 Status에 (ROOT)가 없다.
cmrctl show cluster --name cls1
Cluster Resource Info
===============================================================
Cluster name : cls1
Status : UP
Master node : (1) cm0
Last NID : 2
Local node : (2) cm1
Storage type : Active Storage
As Diskstring : /data/*
No. of cls files : 3
(1) +0
(2) +1
(3) +2
===============================================================
| NODE LIST |
|-------------------------------------------------------------|
| NID Name IP/PORT Status Schd Mst FHB NHB |
| --- -------- -------------------- ------ ---- --- ---- ---- |
| 1 cm0 123.1.1.1/29000 UP Y M 30 35 |
| 2 cm1 124.1.1.1/29100 UP Y R [ LOCAL ] |
===============================================================
마지막으로 바로 위의 상황에서 루트 권한이 없는 1번 노드의 클러스터를 stop시킨 후 다시 cluster start를 하려는 상황이다. 1번 노드에서 클러스터가 stop됨으로 인해 클러스터에 ROOT 권한 노드만 남게 되고, 이에 따라 클러스터가 ROOT 모드가 됨을 확인할 수 있다. 또한 클러스터가 ROOT 모드이므로, ROOT 권한이 없는 1번 노드 CM은 클러스터에 재접속할 수 없게 된다.
1번 노드
cmrctl stop cluster --name cls1
cmrctl start cluster --name cls1
Failed to start the resource 'cls1'
[ERROR] To join this cluster(cls1), you must be root
2번 노드
cmrctl show cluster --name cls1
Cluster Resource Info
===============================================================
Cluster name : cls1
Status : UP (ROOT)
Master node : (1) cm1
Last NID : 2
Local node : (2) cm1
Storage type : Active Storage
As Diskstring : /data/*
No. of cls files : 3
(1) +0
(2) +1
(3) +2
===============================================================
| NODE LIST |
|-------------------------------------------------------------|
| NID Name IP/PORT Status Schd Mst FHB NHB |
| --- -------- -------------------- ------ ---- --- ---- ---- |
| 1 cm0 123.1.1.1/29000 DOWN N 0 0 |
| 2 cm1 124.1.1.1/29100 UP Y R M [ LOCAL ] |
===============================================================
본 절에서는 TAC의 구성을 위해 Linux 환경에서 참고할 수 있는 예제를 설명한다.
1번 노드에서의 TB_SID와 CM_SID는 각각 ac1와 cm1, 2번 노드에서의 TB_SID와 CM_SID는 각각 ac2와 cm2로 정하였다. 먼저 CM TIP 파일을 설정해야 한다. 위의 초기화 파라미터에 보면 필수 항목이 3개이므로 그 3개는 반드시 설정해야 한다.
본 예제에서는 1번 노드를 위한 CM TIP 파일을 1번 노드의 $TB_HOME/config 아래에 cm1.tip으로, 2번 노드를 위한 CM TIP 파일을 2번 노드의 $TB_HOME/config 아래에 cm2.tip으로 저장하였으며, 다음과 같이 TIP 파일을 작성하였다(config 폴더에 저장해야 한다).
<<cm1.tip>>
CM_NAME=cm1
CM_UI_PORT=8635
CM_RESOURCE_FILE=/home/tibero7/cm1_res.crf
<<cm2.tip>>
CM_NAME=cm2
CM_UI_PORT=8655
CM_RESOURCE_FILE=/home/tibero7/cm2_res.crf
다음으로 TAC용 TIP 파일을 설정해야 한다.
본 예제에서는 1번 노드를 위한 TAC TIP 파일을 1번 노드의 $TB_HOME/config 아래에 ac1.tip으로, 2번 노드를 위한 TAC TIP 파일을 2번 노드의 $TB_HOME/config 아래에 ac2.tip으로 저장한다. “제15장 Tibero Active Cluster”를 보면 각 파라미터들의 의미를 알 수 있다(본 예제에서는 TB_HOME이 /home/tibero7 이다).
<<ac1.tip>>
DB_NAME=ac #DB_NAME은 ac1과 ac2가 같은 값을 가진다.
LISTENER_PORT=21000
CONTROL_FILES="/home/tibero7/database/ac/c1.ctl"
MAX_SESSION_COUNT=20
TOTAL_SHM_SIZE=512M
MEMORY_TARGET=1G
THREAD=0
UNDO_TABLESPACE=UNDO0
CLUSTER_DATABASE=Y
LOCAL_CLUSTER_ADDR=123.1.1.1
LOCAL_CLUSTER_PORT=21100
CM_PORT=8635 #cm1의 CM_UI_PORT
<<ac2.tip>>
DB_NAME=ac #DB_NAME은 ac1과 ac2가 같은 값을 가진다.
LISTENER_PORT=21010
CONTROL_FILES="/home/tibero7/database/ac/c1.ctl"
MAX_SESSION_COUNT=20
TOTAL_SHM_SIZE=512M
MEMORY_TARGET=1G
THREAD=1
UNDO_TABLESPACE=UNDO1
CLUSTER_DATABASE=Y
LOCAL_CLUSTER_ADDR=124.1.1.1
LOCAL_CLUSTER_PORT=21110
CM_PORT=8655 #cm2의 CM_UI_PORT
1번 노드부터 구성을 하면 먼저 CM을 실행시켜야 하는데, 이를 위해서는 CM_SID가 앞서 작성한 TIP 파일의 파일 이름과 같아야 한다(따라서 본 예제에서는 CM_SID가 cm1이어야 한다).
CM_SID를 설정하기 위해 아래의 내용을 터미널에서 실행시킨다. TB_SID도 같이 설정한다(나중에 데이터베이스를 만들 때 필요하다).
export CM_SID=cm1
export TB_SID=ac1
이렇게 CM_SID 설정을 완료하면, 아래의 명령어를 이용해 CM을 실행한다.
tbcm -b
성공적으로 부팅되었다면, 다음과 같이 출력된다.
CM Guard daemon started up. import resources from '/home/tibero7/cm1_res.crf'... Tibero 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Tibero cluster manager started up. Local node name is (cm1:8635).
이 과정을 거치고 나면 CM_RESOURCE_FILE에 설정해 놓은 디렉터리에 cm1_res.crf라는 리소스 바이너리 파일이 생성되게 된다. 이 파일에 앞으로 등록할 리소스에 대한 정보들이 저장된다.
완료되면 CM의 부팅 상태를 확인하기 위해 다음과 같이 명령어를 실행한다.
cmrctl show
다음과 같이 나온다면 정상적인 상황이다(아직 아무런 리소스도 등록하지 않았기 때문에 CLUSTER, TYPE, NAME, STATUS, DETAIL이 모두 빈칸이다).
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- ====================================================================
먼저 아래의 명령어처럼 네트워크 리소스를 등록한다.
cmrctl add network --name net1 --ipaddr 123.1.1.1 --portno 29000
성공적으로 리소스가 등록되면 다음과 같이 출력된다.
Resource add success! (network, net1)
다시 한 번 cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력된다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 ====================================================================
다음으로 아래의 명령어와 같은 방법으로 클러스터를 등록한다. 이때, cfile이 저장될 폴더는 미리 만들어 놓아야 한다. 또한, cfile 경로는 공유 디스크에 있도록 지정해야 한다.
cmrctl add cluster --name cls1 --incnet net1 --cfile /'shared disk 경로'/cls1_cfile
성공적으로 클러스터 리소스가 등록되면 다음과 같이 출력된다.
Resource add success! (cluster, cls1)
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력된다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 COMMON cluster cls1 DOWN inc: net1, pub: N/A ====================================================================
등록된 클러스터 아래에 TAC 서비스 리소스를 등록해야 하는데, 그에 앞서 클러스터 cls1을 활성화시켜야 한다.
cmrctl start cluster --name cls1
성공적으로 클러스터가 시작되면 다음과 같이 출력된다(이때 실패한다면 cfile이 저장될 디렉터리를 미리 안만들어 놓았을 가능성이 높다).
SUCCESS!
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력된다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 COMMON cluster cls1 UP inc: net1, pub: N/A cls1 file cls1:0 UP /'shared disk 경로'/cls1_cfile ====================================================================
다음과 같은 명령어를 이용해 서비스 리소스를 등록한다(이때, 서비스의 이름은 나중에 만들 데이터베이스의 이름과 같아야 한다).
cmrctl add service --name ac --cname cls1
성공적으로 등록하면 다음과 같이 출력된다.
Resource add success! (service, ac)
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력된다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 COMMON cluster cls1 UP inc: net1, pub: N/A cls1 file cls1:0 UP /'shared disk 경로'/cls1_cfile cls1 service ac DOWN Database, Active Cluster (auto-restart: OFF) ====================================================================
마지막으로 DB 리소스를 등록한다.
여기서 --name의 값은 Active Cluster에서 해당 노드가 사용할 TB_SID(본 예제에서는 ac1를 사용)와 같아야 한다. ac1를 위한 환경변수 설정을 담은 envfile은 /home/tibero7/ 아래에 envfile_ac1으로 저장하였다.
cmrctl add db --name ac1 --svcname ac --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ac1
성공적으로 등록하면 다음과 같이 출력된다.
Resource add success! (db, ac1)
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력된다.
Resource List of Node cm1
====================================================================
CLUSTER TYPE NAME STATUS DETAIL
----------- -------- ------------- --------- -----------------------
COMMON network net1 UP (private) 123.1.1.1/29000
COMMON cluster cls1 UP inc: net1, pub: N/A
cls1 file cls1:0 UP /'shared disk 경로'/cls1_cfile
cls1 service ac DOWN Database, Active Cluster
(auto-restart: OFF)
cls1 db ac1 DOWN ac, /home/tibero7
====================================================================
이제 실제로 운용할 데이터베이스를 만들어야 한다. “15.5. TAC를 위한 데이터베이스 생성” 과정의 2번 ~ 6번까지의 과정을 실행한다. 과정을 수행하는 데 다음의 두 가지 유의사항을 지켜야 한다.
tbsql로 접속하기 위해 tbdsn.tbr을 설정할 때 다음과 같은 내용들을 넣어주어야 한다.
ac1=( (INSTANCE=(HOST=123.1.1.1) (PORT=21000) (DB_NAME=ac) ) )
접속 후 “15.5. TAC를 위한 데이터베이스 생성”에서 데이터베이스를 만들 때 CREATE DATABASE "ac" (앞서 입력한 서비스 리소스의 이름)로 해야 한다. 데이터베이스 생성을 모두 마치고 나면, cmrctl show의 결과에서 다음과 같이 STATUS가 모두 UP으로 바뀌어 있다.
Resource List of Node cm1
====================================================================
CLUSTER TYPE NAME STATUS DETAIL
----------- -------- ------------- --------- -----------------------
COMMON network net1 UP (private) 123.1.1.1/29000
COMMON cluster cls1 UP inc: net1, pub: N/A
cls1 file cls1:0 UP /'shared disk 경로'/cls1_cfile
cls1 service ac UP Database, Active Cluster
(auto-restart: OFF)
cls1 db ac1 UP ac, /home/tibero7
====================================================================
이로써 첫 노드에서의 구성이 끝났다. 이제 다음 노드를 구성해야 한다. 먼저 2번 노드의 tbdsn.tbr 설정을 마친 후 다음의 명령어들을 차례대로 입력한다. 이때 유의할 점은 클러스터를 추가할 때 cfile의 경로가 앞서 1번 노드에서 설정한 cfile의 경로와 같아야 한다.
export CM_SID=cm2 export TB_SID=ac2 tbcm -b cmrctl add network --name net1 --ipaddr 124.1.1.1 --portno 29100 cmrctl add cluster --name cls1 --incnet net1 --cfile /'shared disk 경로'/cls1_cfile cmrctl start cluster --name cls1
cmrctl show를 해보면 다음과 같이 서비스가 이미 등록되어 있는 것을 확인할 수 있다. 이는 cfile에 있는 내용을 cm1에서 직접 읽어왔기 때문이다.
Resource List of Node cm2 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 124.1.1.1/29100 COMMON cluster cls1 UP inc: net1, pub: N/A cls1 file cls1:0 UP /'shared disk 경로'/cls1_cfile cls1 service ac DOWN Database, Active Cluster (auto-restart: OFF) ====================================================================
마지막으로 ac2이 사용할 envfile을 저장한 후 다음의 명령어들을 입력하면 2 노드 TAC 구성과 실행이 완료된다.
cmrctl add db --name ac2 --svcname ac --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ac2 cmrctl start service --name ac
본 절에서는 먼저 TAS를 구성하는 과정에 대해서 설명한다.
다음은 TAS-TAC(Tibero Active Storage - Tibero Active Cluster)의 구성을 위해 Linux 환경에서 참고할 수 있는 예제이다.
1번 노드에서 TAS를 위한 TB_SID를 as1, TAC를 위한 TB_SID를 ac1, CM을 위한 CM_SID를 cm1으로 한다. TB_SID를 따서 예제 내용을 as1.tip은 1번 노드의 $TB_HOME/config/as1.tip에 저장한다.
2번 노드에서 TAS를 위한 TB_SID를 as2, TAC를 위한 TB_SID를 ac2, CM을 위한 CM_SID를 cm2로 한다. TB_SID를 따서 예제 내용을 as2.tip은 2번 노드의 $TB_HOME/config/as2.tip에 저장한다. TAS는 DB_NAME을 지정하지 않고, TAC는 DB_NAME을 ac로 한다.
전체적인 흐름은 TAS를 구성하고 “14.6. TAC 구성”에 설명된 정보를 수정해서 수행한다.
다음은 수행과정에 대한 설명이다.
cm1.tip과 cm2.tip은 “14.6. TAC 구성”을 참고해서 생성한다.
다음 TIP 파일 내용에서 메모리 사이즈 등 다양한 수치들은 예제일 뿐이고, 사용 목적에 맞게 조정할 수 있다(본 예제에서는 raw 디바이스를 사용하지 않고, 각각의 용량이 5GB인 /data/disk01과 /data/disk02라는 두 파일을 사용하여 한 컴퓨터에 두 노드를 띄울 예정이다). 디스크 구성은 "Tibero Active Storage 관리자 안내서"의 "A.1.2 디스크 준비"를 참조한다.
<<as1.tip>>
LISTENER_PORT=30011 MEMORY_TARGET=2G MAX_SESSION_COUNT=50 TOTAL_SHM_SIZE=1G CLUSTER_DATABASE=Y #필수 THREAD=0 CM_PORT=8635 #cm1의 CM_UI_PORT LOCAL_CLUSTER_ADDR=123.1.1.1 LOCAL_CLUSTER_PORT=30111 INSTANCE_TYPE=AS #필수 AS_ALLOW_ONLY_RAW_DISKS=N #RAW 디바이스를 사용하지 않으므로, 이 설정이 필요하다. AS_THR_CNT=10 AS_DISKSTRING="/data/*" #/data/disk01과 data/dis02를 사용하므로 /data/*값을 준다.
<<as2.tip>>
LISTENER_PORT=40011 MEMORY_TARGET=2G MAX_SESSION_COUNT=50 TOTAL_SHM_SIZE=1G CLUSTER_DATABASE=Y #필수 THREAD=1 CM_PORT=8655 #cm2의 CM_UI_PORT LOCAL_CLUSTER_ADDR=123.1.1.1 LOCAL_CLUSTER_PORT=40111 INSTANCE_TYPE=AS #필수 AS_ALLOW_ONLY_RAW_DISKS=N #RAW 디바이스를 사용하지 않으므로, 이 설정이 필요하다. AS_THR_CNT=10 AS_DISKSTRING="/data/*" #/data/disk01과 data/dis02를 사용하므로 /data/*값을 준다.
TAS용 TIP 파일이 준비되면 1번 노드부터 순서대로 설정한다.
먼저 1번 노드에서 export CM_SID=cm1으로 환경변수를 설정한다. 그 후, CM을 부팅하여 네크워크를 추가하는 곳까지 앞의 내용대로 수행하여 cmrctl show 커맨드를 수행하였을 때 다음과 같이 조회될 수 있도록 한다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 ====================================================================
다음으로 클러스터를 등록해야 하는데, 다음과 같이 cfile 부분이 앞에서와 달라진다.
cmrctl add cluster --name cls1 --incnet net1 --cfile "+/data/*"
성공적으로 수행 되었다면,TB_SID를 as1으로 export 한 후 다음의 커맨드를 수행하여 TAS 인스턴스를 띄운다(“14.6. TAC 구성”과 달리 클러스터를 start시키지 않는다).
tbboot nomount
부팅이 완료되면 tbsql을 통해 TAS 인스턴스에 접속하여 다음과 같은 sql로 디스크 스페이스를 만든다(TAS에서도 Tibero 혹은 TAC와 마찬가지로 tbdsn.tbr에 as1의 설정을 써주어야 tbsql로 인스턴스에 접속할 수 있다).
CREATE DISKSPACE ds0 NORMAL REDUNDANCY FAILGROUP fg1 DISK '/data/disk01' NAME disk101 FAILGROUP fg2 DISK '/data/disk02' NAME disk201 ATTRIBUTE 'AU_SIZE'='4M';
수행 완료 후 tbsql을 종료하고, TAS 인스턴스도 종료되었음을 확인한 후 아래의 커맨드를 통해 클러스터를 실행시킨다.
cmrctl start cluster --name cls1
그 후 cmrctl show를 이용해 리소스를 확인해 보면 다음과 같이 조회된다.
Resource List of Node cm1 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29000 COMMON cluster cls1 UP inc: net1, pub: N/A cls1 file cls1:0 UP +0 cls1 file cls1:1 UP +1 cls1 file cls1:2 UP +2 ====================================================================
이제 다음의 커맨드를 사용하여 as용 서비스 리소스를 등록한다.
cmrctl add service --name as --cname cls1 --type as
다음으로 as를 등록한다. envfile은 tibero7/ 아래에 envfile_for_as1으로 저장하였고, --name의 값은 TIP 파일에 사용된 이름인 as1로 해야 한다.
cmrctl add as --name as1 --svcname as --dbhome /home/tibero7 --envfile /home/tibero7/envfile_for_as1
다음의 커맨드를 통해 TAS 인스턴스를 normal 모드로 부팅시킨다.
cmrctl start service --name as 혹은 cmrctl start as --name as1
위의 커맨드를 통해 TAS 인스턴스가 성공적으로 부팅되었으면, 다음과 같이 tbsql로 커맨드를 수행하여 2번 노드의 TAS 인스턴스가 사용할 스레드를 생성해야 한다.
tbsql sys/tibero@as1 sql> alter diskspace ds0 add thread 1;
여기까지 왔으면 나머지 2번 노드에서도 TAS 인스턴스를 띄울 준비가 완료된 것이다.
2번 노드에서 export CM_SID=cm2와 export TB_SID=as2 커맨드를 수행하여 환경변수를 설정해준다. 그 후 tbcm -b로 CM을 부팅하고, 다음의 커맨드들을 수행해준다(본 예제에서는 같은 컴퓨터에 두 노드를 구성하므로 네트워크의 ippaddr이 cm1에서와 같고 portno만 다르다).
cmrctl add network --name net1 --ipaddr 123.1.1.1 --portno 29100 cmrctl add cluster --name cls1 --incnet net1 --cfile "+/data/*" cmrctl start cluster --name cls1
이제 cmrctl show를 실행해보면 다음과 같이 서비스가 등록된 것을 확인할 수 있다.
Resource List of Node cm2 ==================================================================== CLUSTER TYPE NAME STATUS DETAIL ----------- -------- ------------- --------- ----------------------- COMMON network net1 UP (private) 123.1.1.1/29100 COMMON cluster cls1 UP inc: net1, pub: N/A cls1 file cls1:0 UP +0 cls1 file cls1:1 UP +1 cls1 file cls1:2 UP +2 cls1 service as DOWN Active Storage, Active Cluster (auto-restart: OFF) ====================================================================
다음의 커맨드로 AS를 등록한 후 2번 노드에서도 TAS 인스턴스를 실행시킨다.
cmrctl add as --name as2 --svcname ac --dbhome /home/tibero7 --envfile /home/tibero7/envfile_for_as2 cmrctl start as --name as2
정상적으로 위 과정이 수행되었다면 각 노드에서의 cmrctl show의 결과는 다음과 같이 출력된다.
노드 1에서의 cmrctl show 결과
Resource List of Node cm1
====================================================================
CLUSTER TYPE NAME STATUS DETAIL
----------- -------- ------------- --------- -----------------------
COMMON network net1 UP (private) 123.1.1.1/29000
COMMON cluster cls1 UP inc: net1, pub: N/A
cls1 file cls1:0 UP +0
cls1 file cls1:1 UP +1
cls1 file cls1:2 UP +2
cls1 service as UP Active Storage, Active Cluster
(auto-restart: OFF)
cls1 as as1 UP as, /home/tibero7
====================================================================
노드 2에서의 cmrctl show 결과
Resource List of Node cm2
====================================================================
CLUSTER TYPE NAME STATUS DETAIL
----------- -------- ------------- --------- -----------------------
COMMON network net1 UP (private) 123.1.1.1/29100
COMMON cluster cls1 UP inc: net1, pub: N/A
cls1 file cls1:0 UP +0
cls1 file cls1:1 UP +1
cls1 file cls1:2 UP +2
cls1 service as UP Active Storage, Active Cluster
(auto-restart: OFF)
cls1 as as2 UP as, /home/tibero7
====================================================================
두 노드에서의 TAS 구성이 완료되었다. 이제 각 노드에서 TAC 구성을 진행하면 된다. 먼저 각 노드의 $TB_HOME/config에 ac1.tip과 ac2.tip을 만드는데, 내용은 다음과 같이 한다.
<<ac1.tip>>
DB_NAME=ac LISTENER_PORT=21000 CONTROL_FILES="+DS0/c1.ctl","+DS0/c2.ctl" DB_CREATE_FILE_DEST="+DS0" LOG_ARCHIVE_DEST="/home/ac/data/archive1" MEMORY_TARGET=1G MAX_SESSION_COUNT=50 TOTAL_SHM_SIZE=512M USE_ACTIVE_STORAGE=Y AS_PORT=30011 CLUSTER_DATABASE=Y THREAD=0 UNDO_TABLESPACE=UNDO0 LOCAL_CLUSTER_ADDR=123.1.1.1 CM_PORT=8635 LOCAL_CLUSTER_PORT=21100
<<ac2.tip>>
DB_NAME=ac LISTENER_PORT=21010 CONTROL_FILES="+DS0/c1.ctl","+DS0/c2.ctl" DB_CREATE_FILE_DEST="+DS0" LOG_ARCHIVE_DEST="/home/ac/data/archive2" MEMORY_TARGET=1G MAX_SESSION_COUNT=50 TOTAL_SHM_SIZE=512M USE_ACTIVE_STORAGE=Y AS_PORT=40011 CLUSTER_DATABASE=Y THREAD=1 UNDO_TABLESPACE=UNDO1 LOCAL_CLUSTER_ADDR=123.1.1.1 CM_PORT=8655 LOCAL_CLUSTER_PORT=21110
TAC용 TIP 파일을 저장하였으면, 각 노드에 아래의 커맨드를 수행한다(각 노드의 TB_HOME에 envfile_ac1과 envfile_ac2를 만들었다. envfile에 대한 내용은 “14.4.1.1. cmrctl add”와 “14.6. TAC 구성”을 참고한다).
1번 노드
cmrctl add service --name ac --cname cls1 cmrctl add db --name ac1 --svcname ac --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ac1
2번 노드
cmrctl add db --name ac2 --svcname ac --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ac2
이제 1번 노드에서 “15.5. TAC를 위한 데이터베이스 생성”의 2번부터 6번까지 과정을 수행한다. 이때 DB 인스턴스를 nomount 모드로 부팅하는 커맨드로 다음의 명령어를 사용한다.
cmrctl start db --name ac1 --option "-t NOMOUNT"
또는
tbboot nomount
“15.5. TAC를 위한 데이터베이스 생성”의 6번까지 과정을 수행하고 나면 다음의 명령어를 통해 각 노드에 DB를 띄워 TAS-TAC 구성을 마친다. 단, 데이터베이스를 생성하는 과정에서 logfile의 경로를 지정할 때에는 '+DS0/log001'(+는 TAS용 경로임을 표시하고, DS0는 앞서 생성한 디스크 스페이스 이름이다.)과 같은 TAS용 경로를 사용해야 한다.
cmrctl start service --name ac
본 절에서는 HA(High Availability) 구성을 위해 Linux 환경에서 참고할 수 있는 예제를 설명한다.
HA를 구성하는 방법은 TAC와 비슷하여 TIP 파일 설정과 서비스 리소스에 --mode ha가 들어가는 점만 다르다. 1번 노드의 TB_SID는 ha1, CM_SID는 cm1이고, 2번 노드의 TB_SID는 ha2, CM_SID는 cm2이다.
cm1.tip과 cm2.tip은 “14.6. TAC 구성”에서와 똑같이 작성하고, ha1.tip과 ha2.tip만 다음과 같이 작성한다(본 예제에서는 쉬운 설명을 위해 같은 컴퓨터에 두 노드를 띄웠다).
<<ha1.tip>>
DB_NAME=ha #DB_NAME은 ac1과 ac2가 같은 값을 가진다. LISTENER_PORT=25001 CONTROL_FILES="/home/tibero7/database/ha/c1.ctl" DB_CREATE_FILE_DEST="/home/tibero7/database/ha" LOG_ARCHIVE_DEST="/home/tibero7/database/ha/archive1" MAX_SESSION_COUNT=20 TOTAL_SHM_SIZE=1G MEMORY_TARGET=2G CLUSTER_DATABASE=Y THREAD=0 UNDO_TABLESPACE=UNDO0 LOCAL_CLUSTER_ADDR=123.1.1.1 LOCAL_CLUSTER_PORT=21100 CM_PORT=8635
<<ha2.tip>>
DB_NAME=ha #DB_NAME은 ac1과 ac2가 같은 값을 가진다. LISTENER_PORT=35001 CONTROL_FILES="/home/tibero7/database/ha/c1.ctl" DB_CREATE_FILE_DEST="/home/tibero7/database/ha" LOG_ARCHIVE_DEST="/home/tibero7/database/ha/archive1" MAX_SESSION_COUNT=20 TOTAL_SHM_SIZE=1G MEMORY_TARGET=2G CLUSTER_DATABASE=Y THREAD=0 #TAC에서와 달리 ha1과 ha2가 같은 thread, UNDO_TABLESPACE 값을 가진다. UNDO_TABLESPACE=UNDO0 LOCAL_CLUSTER_ADDR=123.1.1.1 LOCAL_CLUSTER_PORT=31100 CM_PORT=8655
HA용 TIP 파일이 준비되었으니, ha1과 ha2를 위한 envfile을 만든 후 다음과 같은 커맨드로 네트워크와 클러스터, 서비스, HA를 등록한다.
1번 노드
export CM_SID=cm1 export TB_SID=ha1 tbcm -b cmrctl add network --name net1 --ipaddr 123.1.1.1 --portno 29000 cmrctl add cluster --name cls1 --incnet net1 --cfile /home/tibero7/cfile/cls1_cfile cmrctl start cluster --name cls1 cmrctl add service --name ha --cname cls1 --mode ha cmrctl add db --name ha1 --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ha1
2번 노드
export CM_SID=cm2 export TB_SID=ha2 tbcm -b cmrctl add network --name net1 --ipaddr 123.1.1.1 --portno 29100 cmrctl add cluster --name cls1 --incnet net1 --cfile /home/tibero7/cfile/cls1_cfile cmrctl start cluster --name cls1 cmrctl add db --name ha2 --dbhome /home/tibero7 --envfile /home/tibero7/envfile_ha2
이제 운용할 데이터베이스를 만들어야 한다.
먼저 NOMOUNT 모드로 부팅한 후 single Tibero에서와 같은 방식으로 데이터베이스를 생성한다. 그 후 system.sh를 수행하면 데이터베이스 생성이 완료된다. 마지막으로 다음의 커맨드를 1번 노드에 적용하면 1번 노드가 다운되었을 때 2번 노드에 DB 인스턴스가 실행되게 된다(1번 노드가 Active, 2번 노드를 Standby라고 하며 이는 cmrctl show service --name ha로 확인 가능하다).
cmrctl act service --name ha cmrctl show service --name ha Service Resource Info ====================================== Service name : ha Service type : Database Service mode : HA Cluster : cls1 Inst. Auto Start: ON ======================== | INSTANCE LIST | |----------------------| | NID Status HA MODE | | --- -------- ------- | | 1 UP Active | | 2 DOWN Standby | ========================
만약 1번 노드가 다운되어 2번 노드가 자동실행되면, 1번 노드가 deact되어 있을 수 있다. 이럴 경우 deact된 리소스를 act시켜주면 1번노 드가 standby가 되어 2번 노드를 failover하게 된다.
CM Observer는 Tibero-TSC 구조에서 관제 대상이 되는 CM들과의 통신을 토대로 TSC로의 failover 수행을 지원한다. CM Observer는 그 관제 하의 CM과의 heartbeat 및 DB 변화에 대한 메시지를 주고 받으며, 이를 기반하여 failover의 실행을 결정한다.
CM Observer를 구성하는 방법은 일반적인 CM을 구성하는 방식과 다르다. Observer는 CM TIP에 자신이 일반적인 CM이 아닌 Observer 노드로 동작함을 명시해주어야 하며, 그 관제 하의 CM 노드들과 통신할 Observer port도 명시해주어야 한다.
관제 하의 CM은 TSC 구성을 한 후 DB 서비스를 등록할 때에 Observer의 ip, port 및 TSC ID를 명시해주어야하며(CM은 이 과정을 통해 Observer에 등록된다.) 또한 DB는 TIP 파일에 몇몇 파라미터를 적용해주어야 한다. 나머지는 일반적인 TSC 구성과 유사하다.
Observer는 관제 대상 CM, Instance들과 독립된 HW에서 동작시켜야 하며, Observer가 동작하는 장비는 troubleproof해야 한다. 만약 독립된 HW가 아닌 경우 기능이 제한될 수 있다. 또한 한 TSC 내의 CM들은 서로 다른 CM NAME을 가져야 한다.
CM Observer도 CM과 마찬가지로 환경변수 CM_HOME과 CM_SID를 설정해야 한다.
다음은 설정 예이다.
환경변수 | 설명 |
---|---|
$CM_HOME | CM Observer가 설치된 경로를 지정한다.
|
$CM_SID | 노드를 식별할 수 있는 ID를 지정한다. 각 노드는 서로 다른 값을 가져야 한다.
|
본 절에서는 CM Observer용 초기화 파라미터와 Observer를 사용하는 경우 필수 DB 파라미터에 대해서 설명한다.
CM Observer용 TIP에는 다음과 같은 파라미터들을 설정할 수 있다. 필수 항목은 사용자가 TIP에 명시적으로 값을 지정해야 하며, 선택 항목은 사용자가 지정하지 않을 수 있고 이 경우 기본값으로 입력된다.
초기화 파라미터 | 필수 여부 | 설명 |
---|---|---|
CM_NAME | 필수 | Observer의 identifier로 쓸 이름이다. 서로 다른 노드의 CM은 다른 값을 가져야 한다. |
CM_MODE_OBSERVER | 필수 | CM 노드가 Observer 모드로 동작함을 명시해주어야 한다. (Y로 설정) |
CM_UI_PORT | 필수 | cmrctl 명령어 수행할 때에 CM으로 접속하는 용도로 사용할 네트워크 포트 번호이다. 이 포트는 노드 간에 열려 있어야 한다. |
CM_OBSERVER_PORT | 필수 | CM Observer와 그 관제대상 CM들과 연결하기 위한 용도로 사용할 네트워크 포트 번호이다. |
CM_OBSERVER_EXPIRE | 선택 | CM Observer expire란 관제 하의 CM에 문제가 생겼다는 것을 CM Observer이 알아차리는데 필요한 표준 시간을 의미한다. 즉, 관제 하의 CM 중 Heartbeat expire 시간이 지나도록 통신이 되지 않는 CM이 있으면, CM Observer는 통신이 되지 않는 노드의 CM에 문제가 생겼다고 인식하게 된다. 이 값은 CM_HEARTBEAT_EXPIRE와 CM_NET_EXPIRE_MARGIN을 더한 값보다 작아야 한다. (단위: 초(second), 기본값: 60) |
LOG_LVL_CM | 선택 | CM이 로그를 남기는 수준을 지정한다. 값이 높을수록 CM이 더 많은 로그를 저장하며, 1~6 사이의 정수값을 가질 수 있다. (기본값: 2) |
CM_LOG_DEST | 선택 | CM이 로그를 남길 디렉터리를 지정한다. 이 값은 반드시 절대 경로여야 한다. (기본값: $CM_HOME/instance/$CM_SID/log/) |
CM_LOG_FILE_SIZE | 선택 | CM 로그 파일의 최대 크기(용량)를 지정한다. 로그가 계속 생성되어 파일의 크기가 이 값을 넘어서려 할 경우 현재의 로그 파일이 닫히고, 새로운 파일이 생성되어 그 파일에 로그가 저장된다. 값은 100KB~1GB 사이의 정수값을 가질 수 있다. (단위: Byte, 기본값: 10MB) |
CM_LOG_TOTAL_SIZE_LIMIT | 선택 | CM_LOG_DEST에서 지정한 디렉터리에 생성되는 로그 파일들의 크기 총합의 최댓값을 지정한다. 로그 파일들의 크기의 합이 이 값을 넘어가게 되면, 가장 오래된 파일을 삭제함으로써 파일 용량이 끝없이 증가하는 것을 막는다. 이 값은 100KB~1GB 사이의 정수값을 가질 수 있다. (단위: byte, 기본값: 300MB) |
CM_TIME_UNIT | 선택 | CM을 컨트롤할 때 사용되는 단위 시간의 길이를 지정한다. (단위: 0.1초, 기본값: 10) |
CM Observer 데몬 실행 이후의 작업들은 cmrctl 명령어를 사용하여 수행한다.
CM Observer는 다음의 방법으로 실행한다.
tbcmobs [option]
[option]
옵션 | 설명 |
---|---|
-b | CM Observer 데몬을 실행한다. |
-d | CM Observer 데몬을 종료한다. |
-s | CM Observer의 상태를 보여준다. 초기화 파라미터에 등록된 내용이 표시된다. |
-h | tbcmobs 명령어에 대한 도움말을 보여준다. |
cmrctl은 New CM 및 Observer에서 리소스들을 관리 및 제어하기 위해 사용하는 명령어 set이다. 단 지원하는 명령의 종류는 New CM일 때와 Observer일 때 서로 다르며, Observer에서 지원하는 cmrctl 명령어 용법은 다음과 같다.
Observer에 등록된 리소스의 정보를 확인하기 위한 명령어이다.
다음의 2가지 방법으로 사용이 가능하다.
방법 1)
cmrctl show
현재 CM Observer에 등록된 CM 및 DB Instance들의 목록을 출력한다.
방법 2)
cmrctl show --tscid <tscid>
지정한 특정 TSC의 상세한 정보를 출력한다.
Observer에 등록된 TSC의 동작을 설정하기 위한 명령어이다.
다음의 3가지 방법으로 사용이 가능하다.
방법 1)
cmrctl set --tscid <tscid> --<type> <act_var>
위의 명령 상으로 지원하는 type과 act_var는 다음과 같다.
type | act_var | 설명 |
---|---|---|
auto_failover | on | 해당 TSC의 autofailover를 수행한다. (기본값) |
auto_failover | off | 해당 TSC의 autofailover를 수행하지 않는다. |
mode | protective | 해당 TSC에 대한 Auto Failover의 동작방식을 protective 모드로 설정한다. (기본값) |
mode | disaster_plan | 해당 TSC에 대한 Auto Failover의 동작방식을 disaster_plan 모드로 설정한다. |
방법 2)
cmrctl set --tscid <tscid> --target <target_clsid / mr>
지정한 특정 TSC의 failover 대상(Target)을 특정 클러스터로 설정(고정)하거나, 가장 최신의 TSN을 받은(Most Received) 클러스터가 failover 대상(Target)이 되도록 한다.
방법 3)
cmrctl set --tscid <tscid> --target <target_clsid / mr> --auto_failover <act_var>
Failover 대상 클러스터 설정 및 auto_failover 여부를 설정한다.
다음은 Observer를 구성하는 과정에 대한 설명이다.
CM TIP 파일의 설정과 DB TIP 파일의 설정은 “13.6. TAC-TSC 구성”을 참고하여 작성한다.
다음은 Observer TIP 파일의 예시이다.
<<cmobs.tip>>
CM_NAME=cmobs CM_MODE_OBSERVER=Y # Observer로 기동시킬 것이기에 반드시 설정해야 한다. CM_OBSERVER_PORT=14500 # 관제 하의 CM노드에서 service를 등록할 때 이 port를 사용한다. CM_UI_PORT=13500 # Observer는 resource file이 없다. # 따라서 Resource file의 경로를 지정할 필요가 없다.
다음은 일반적인 CM TIP 파일의 예시이다.
<<cm1.tip>>
CM_NAME=cm1 CM_UI_PORT=27500 CM_RESOURCE_FILE=/home/tibero/cm1_res CM_HEARTBEAT_EXPIRE=120 CM_WATCHDOG_EXPIRE=110 # Observer가 아닌 CM은 resource file이 필요하다. # 따라서 Resource file의 경로를 지정해야 한다.
Observer용 TIP 파일 및 다른 CM, DB TIP 파일들이 준비되었으니, 네트워크와 클러스터, 서비스, DB를 등록한다. 대부분의 등록과정은 “13.6. TAC-TSC 구성”과 같다. 단, DB 서비스 등록과정이 약간 다른데, 아래의 예시와 같이 서비스 등록과정에서 이를 관제할 Observer의 ip와 port, TSC ID를 명시해주어야 한다(본 예제에서는 쉬운 설명을 위해 같은 컴퓨터에 옵저버와 노드를 띄웠다).
Observer 미사용 시 DB 서비스 등록
cmrctl add service --type db --name tac --cname cls0
Observer 사용 시 DB 서비스 등록(관제 대상 CM 노드에서 서비스 등록 시)
cmrctl add service --type db --name tac --cname cls0 --tscid 11 --obsip 127.0.0.1 --obsport 14500
관제 대상 CM은 이를 통해 Observer에 등록된다.
구성이 완료되면 Observer에서 cmrctl show 명령을 통해 아래와 같이 TSC가 구성되었음을 확인할 수 있다.
Observer가 관제하는 cm 및 DB Instance 확인
cmrctl show Resource List of Observer cmobs =================================================================== TSC_ID CLS_ID CM_NAME NID CM_STAT INST_STAT PRI/TAR -------- -------- ----------- ----- --------- ----------- --------- 11 0 cm0 1 UP UP(NRML) PRIMARY 1 cm0_sb 1 UP UP(RECO) TARGET ===================================================================
특정 TSC에 대한 정보 확인
cmrctl show --tscid 11 TSC(ID: 11) Information =============================================================================== FAILOVER MODE CLS_ID CM_NAME CONN LOG Heartbeat RCVD.TSN --------- ----------- -------- ----------- ------ ----- ---------- ------------ ON(TSN) PROTECTIVE 0 cm0 Y(M) - 60 0 1 cm0_sb Y(M) 1 60 13655 ===============================================================================
다음은 Observer 동작을 위한 설정값에 대한 설명이다.
Observer에 등록된 클러스터의 분류
설정 값 | 설명 |
---|---|
Primary | Normal 모드로 부팅한 Tibero가 포함된 클러스터이며, 한 TSC 안에 복수의 Primary 클러스터는 존재할 수 없다. 만약 Normal 모드로 부팅한 Tibero가 포함된 클러스터가 복수 개라면 모두 Primary 지위를 박탈당한다. |
Standby | Primary와 Observer가 등록한 Standby 클러스터, 한 TSC 안에서 여러 클러스터가 Standby일 수 있다. |
Target | Standby로 등록된 클러스터 중 auto failover의 대상이 될 클러스터이며, 한 TSC 안에는 단 하나의 Target 클러스터만 존재할 수 있다. |
N | 위의 종류에 속하지 않는 클러스터이다. |
Auto Failover 여부
설정 값 | 설명 |
---|---|
OFF | Primary가 종료되어 auto failover를 하지 않는다. 또한 Primary는 어떠한 경우에도 스스로 종료되지 않는다. |
ON(TSN) | Standby 클러스터 중 received tsn이 가장 높은 Standby 클러스터를 auto failover의 대상(target)으로 설정한다. |
ON(FIXED) | 사용자가 지정한 Standby 클러스터를 auto failover의 대상(target)으로 설정한다. |
Auto Failover 모드
설정 값 | 설명 |
---|---|
PROTECTIVE | Primary 클러스터의 안정성을 최우선으로 하는 모드로써, 어떠한 경우에도 Primary 클러스터는 스스로 종료하지 않는다. 그러나 정전 등의 이유로 관제 대상 CM까지 종료되어 버리는 경우에는 auto failover가 일어나지 못한다. 즉, Observer와 CM과의 접속이 유효할 때만 DB Instance의 상황에 따라 auto failover를 수행할 수 있다. (기본값) |
DISASTER_PLAN | 재난대비 모드로써, Primary 클러스터 전체가 재난 등으로 종료되었을 때도 failover를 수행할 수 있다. 즉, Primary 클러스터의 CM들이 모두 Observer와 연결이 끊겨도 auto failover가 가능하다. 그러나 특정 조건에서 Primary 클러스터가 스스로를 종료시킬 수 있다. |
Observer를 사용하는 경우 기동과 종료는 다음의 순서를 따른다.
기동
Observer 기동
Primary, Standby CM 기동 후 Observer에서 Primary, Standby CM 접속 확인 (observer cmrctl show)
Primary, Standby Tibero 인스턴스 기동 후 Observer에서 정상적인 상태 확인 (Primary/Standby/Target)
종료
Observer 종료
Primary, Standby Tibero 인스턴스 종료
Primary, Standby CM 종료