Tibero Cluster Manager
Tibero Cluster Manager의 기본 개념과 환경설정 및 실행 방법을 설명합니다.
개요
Tibero Cluster Manager(이하 CM)는 클러스터의 가용성을 높이고 관리의 편의를 지원합니다. 또한, Tibero Active Cluster 서비스를 위한 인스턴스간 멤버십 관리를 지원합니다. CM에서는 클러스터의 각종 구성 요소 들을 리소스라는 개념으로 관리하도록 되어있습니다.
다음은 현재 CM에서 관리 가능한 클러스터 리소스입니다.
File
Network
Cluster
Service
DB(Database)
AS(Active Storage)
VIP
Group
Agent
CM은 등록된 리소스들에 대한 모니터링을 수행하며, 상태 변화에 따른 필요 동작들을 수행합니다. 설정을 통해 같은 클러스터에 속하게 된 CM들 간에는 지정된 네트워크와 공유 디스크를 통해 주기적으로 자신이 살아있음을 알리는 Heartbeat를 서로 주고받으며 클러스터의 멤버십 구성을 파악하게 됩니다.
클러스터 구성 CM 중 하나의 CM이 마스터의 역할을 맡아 비정상적인 상황이 발생하는 경우 클러스터 멤버십을 자동으로 변경하여, 해당 클러스터 상의 서비스가 중단되지 않도록 합니다. 마스터에 문제가 생긴 경우 클러스터에 속한 다른 노드가 마스터 역할을 넘겨 받습니다.
환경변수 및 초기화 파라미터
환경변수
환경변수 CM_HOME과 CM_SID를 설정해야 합니다. 다음은 그 예제입니다. 이 외에 RDBMS를 실행하기 위 해 필요한 기본 환경변수들은 “관리의 기본”을 참고하여 설정합니다.
$CM_HOME
CM이 설치된 경로를 지정
예) \nexport CM_HOME=/home/tibero7\n
$CM_SID
노드를 식별할 수 있는 ID를 지정
각 노드는 서로 다른 값을 가져야 함
예) \nexport CM_SID=cm0\n
초기화 파라미터
CM용 TIP에는 다음과 같은 파라미터들을 설정할 수 있습니다. 필수 항목은 사용자가 TIP에 명시적으로 값을 지정해야 하며, 선택 항목은 사용자가 지정하지 않을 수 있고 이 경우 기본값으로 입력됩니다.
CM_NAME
필수
클러스터를 생성할 때의 node identifier로 쓸 이름
서로 다른 노드의 CM은 다른 값을 가져야 함
CM_UI_PORT
필수
cmrctl 명령어 수행할 때에 CM으로 접속하는 용도로 사용할 네트워크 포트 번호
이 포트는 노드 간에 열려있어야 함
CM_RESOURCE_FILE
필수
CM 리소스 파일의 경로를 지정
CM 리소스 파일은 다음과 같은 상황에서 사용됨
동작 중인 CM이 등록된 리소스의 내용을 저장해두기 위해 사용하는 파일– 리소스의 추가, 변경 혹은 삭제할 때 리소스 파일에 자동으로 동기화
CM_RESOURCE_FILE_BACKUP
선택
CM 리소스 파일의 백업 경로를 지정
CM_RESOURCE_FILE_BACKUP_INTERVAL
선택
CM_RESOURCE_FILE_BACKUP 경로에 CM 리소스 파일의 백업을 수행할 시간 간격을 나타냄 (단위: 분)
LOG_LVL_CM
선택
CM이 로그를 남기는 수준을 지정
값이 높을수록 CM이 더 많은 로그를 저장하며, 1~6 사이의 정수값을 가질 수 있음(기본값: 3)
CM_LOG_DEST
선택
CM이 로그를 남길 디렉터리를 지정
이 값은 반드시 절대 경로여야 함 (기본값: $CM_HOME/instance/$CM_SID/log/)
CM_GUARD_LOG_DEST
선택
CM Guard가 로그 파일을 저장할 장소로 이 값은 반드시 로컬 디스크의 절대 경로여야 함
(기본값: $CM_HOME/instance/$CM_SID/log/cm_guard/)
Windows는 Guard가 뜨지 않음
CM_LOG_FILE_SIZE
선택
CM 로그 파일의 최대 크기(용량)를 지정
로그가 계속 생성되어 파일의 크기가 값을 넘어설 경우 현재의 로그 파일이 닫히고, 새로운 파일이 생성되어 그 파일에 로그가 저장됨
값은 100KB~1GB 사이의 정수값을 가질 수 있음(단위: Byte, 기본값: 10MB)
CM_LOG_TOTAL_SIZE_LIMIT
선택
CM_LOG_DEST에서 지정한 디렉터리에 생성되는 로그 파일들의 크기 총합의 최댓값을 지정
로그 파일들이 크기의 합이 값을 넘어가기 전까지는, 가장 오래된 파일을 삭제함으로써 파일 용량이 줄어든 후 새로운 로그 파일을 생성함으로써 증가하는 것을 막음
이 값은 100KB~10GB 사이의 정수값을 가질 수 있음 (단위: byte, 기본값: 300MB)
CM_TIME_UNIT
선택
CM을 컨트롤할 때 사용되는 단위 시간의 길이를 지정 (단위: 0.1초, 기본값: 10)
CM_HEARTBEAT_EXPIRE
선택
Heartbeat expire란 다른 노드의 CM에 문제가 생겼다는 것을 CM이 알아차리는데 필요한 표준 시간 값을 의미
즉, 현재 노드의 CM에서 Heartbeat expire 시간이 지나도록 통신이 되지 않는 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의 상태 변화를 빨리 알아차릴 수 있도록 하는 기능을 활성화시킬지를 결정 (기본값: Y)
CM 실행
CM 데몬 실행 이후의 작업들은 cmrctl 명령어를 사용하여 수행합니다. CM은 다음의 방법으로 실행합니다.
[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 명령어에 대한 도움말을 보여줌
-g <level>
지정된 레벨로 로그 레벨을 변경 (1 ~ 6)
CM 명령어
본 절에서는 CM 명령어인 cmrctl, crfconf에 대해서 설명합니다.
cmrctl 명령어
cmrctl은 New CM에서 리소스들을 관리 및 제어하기 위해 사용하는 명령어 set입니다.
기본적인 cmrctl 명령어 용법은 다음과 같습니다.
action
add, del, show, start, stop, act, deact, modify, relocate
resource_type
network, cluster, service, db, as, vip, file, group, agent
참고 어떤 action, resource type의 조합은 사용이 불가능할 수도 있습니다. (예: add, file)
cmrctl 명령어를 통한 CM 원격 제어
같은 클러스터를 구성 중인 CM에 대해서 cmrctl 명령에 추가 attribute를 명시함으로써 원격 제어가 가능 합니다. 원격 제어를 할 CM 노드의 이름과 해당 노드가 속한 클러스터의 이름을 알고 있어야 하며, 다음과 같은 attribute를 cmrctl 명령에 추가합니다.
다음의 예제 구문처럼 해당 attribute는 cmrctl add와 cmrctl del 명령에는 사용할 수 없습니다.
지정한 클러스터가 down 상태이거나 지정한 노드가 down 상태일 경우 또는 잘못된 클러스터/노드 이름 을 입력했을 경우에는 에러 메시지를 출력합니다.
14.4.1.1. cmrctl add
cmrctl add는 다음의 명령어로 구성됩니다.
네트워크 리소스를 추가하기 위한 명령어입니다.
클러스터 리소스를 추가하기 위한 명령어입니다.
서비스 리소스를 추가하기 위한 명령어입니다.
Tibero 인스턴스를 추가하는 명령어입니다.
AS(Active Storage) 인스턴스를 추가하는 명령어입니다.
VIP를 등록하기 위한 명령어입니다.
그룹을 추가하기 위한 명령어입니다.
에이전트를 추가하기 위한 명령어입니다.
cmrctl add network
네트워크 리소스를 추가하기 위한 명령어입니다. 네트워크가 public/private 용도에 따라서 필요한 attribute 가 나뉩니다. 네트워크 리소스는 interconnect로 사용할 IP, PORT 조합이나 VIP 등록을 위해 필요한 public 네트워크 인터페이스 등록을 위해 사용하는 자원입니다. 등록된 이후에 지정된 네트워크 인터페이스를 감 시하여 자동으로 상태를 갱신합니다.
Key
Value Type
설명
name
string
네트워크 리소스 이름입니다. (unique, mandatory)
nettype
string
네트워크 리소스의 type입니다. – private : interconnect를 의미합니다. (기본값) – public : VIP 용으로 사용합니다.
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)
cmrctl add cluster
클러스터 리소스를 추가하기 위한 명령어입니다. 클러스터 리소스는 환경의 개념으로 노드 간 연결에 사용 하는 interconnect, 노드 간 공유하는 스토리지, VIP를 사용하는 경우에 필요한 public network interface로 구성됩니다.
Key
Value Type
설명
Key
Value Type
설명
name
string
클러스터 리소스 이름입니다. (unique, mandatory)
incnet
string
interconnect 용도로 사용할 네트워크 리소스 이름입니다. (mandatory)
pubnet
string
public 용도로 사용할 네트워크 리소스 이름입니다. VIP를 사용하는 경우 등록합니다.
cfile
file path
클러스터 파일 경로입니다. 콤마(,)로 구분하여 여러 개 등록할 수 있다. (mandatory)cfile attribute의 경우 가장 앞에 '+'를 붙이면 TAS용 경로(diskstring)로 인식합니다.
– 예제 1) 올바른 경로 사용방법\n--cfile "/dev/sda,/dev/sdb,/dev/sdc"\n\n\n--cfile "/mnt/file1,/mnt/file2,/mnt/file3"\n\n\n--cfile "+/dev/sda,/dev/sdb,/dev/sdc"\n일반 경로와 TAS 경로를 혼용할 수 없습니다.
– 예제 2) 잘못된 사용 방법“+/dev/sdb”라는 경로는 없으므로 인식하지 못함\n--cfile "+/dev/sda,/ +/dev/sdb"\n\n\n--cfile "/dev/sda,/ +/dev/sdb"\nTAS용 경로를 사용하는 경우 AS_DISKSTRING으로 지정한 디스크와 나중에 추가될 디스크를 모두 포함해야 합니다. 따라서 디스크 추가가 예상되는 경우 wildcard 사용을 권장합니다.
– 예제 3) 나중에 추가될 /dev/sdd를 고려하는 경우\n--cfile "+/dev/sd*"\n\n\n--cfile "+/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd"\n
– 예제 4) 나중에 추가될 sdd를 고려하지 못한 경우. sdd가 추가되어 TAS rebalance에 의해 cfile의 위치가 변경되면 cm이 cfile을 찾지 못하게 될 수 있다. 이 경우 cluster 재구성을 통한 cfile 재등록이 필요하다.
(나중에 추가될 sdd를 고려하지 못한 경우)
\n--cfile "+/dev/sda,/dev/sdb,/dev/sdc"\n
(클러스터 재구성을 통한 cfile 재등록)
\n--cfile "+/dev/sda,/dev/sdb,/dev/sdc,/dev/sdd"\n
TAS를 사용하는 환경에서 TAS가 관리하는 디스크를 '+' prefix 없이 cfile로 등록하게 되면 raw device로 인식하게 되어 TAS 디스크를 덮어쓸 수 있으므로 주의가 필요하다.
– 예제 5) TAS가 사용중인 /dev/sda를 덮어쓰게 되는 경우\n--cfile "/dev/sda"\n스토리지 서버를 사용할 경우에는 다음과 같이 지정합니다.
– 예제 6)\n--cfile "-"\n
[참고]
1. cfile은 TAS 용 경로가 아닌 raw device나 파일로 지정할 경우를 우선 개로 지정하는 것을 권장합니다(권고사항).
2. 파일 리소스의 경우 사용자가 수동으로 추가하는 것이 아니라, 클러스터 리소스의 --cfile로 등록된 내용으로 자동 생성됩니다. TAS diskstring을 등록한 경우 +0, +1, +2와 같은 형태로 리소스가 생성 됩니다.
cmr ctl add service
서비스 리소스를 추가하기 위한 명령어입니다. 서비스는 클러스터라는 환경 위에서 실제 어떤 서비스를 제 공하는 인스턴스의 집합을 관리하기 위한 개념입니다.
name
string
서비스 리소스 이름입니다. (unique, mandatory)서비스 리소스 이름은 해당 서비스와 매핑되는 DB의 DB_NAME 파라미터와 같아야 합니다(TAS는 TIP 파일에 DB_NAME을 안정어도 되지만, 적는다면 서비스의 이름과 같아야 합니다).
type
string
서비스 타입입니다.– DB : Tibero 인스턴스가 동작하는 서비스입니다. (기본값)– AS : TAS 인스턴스가 동작하는 서비스입니다.
mode
string
서비스 인스턴스 클러스터링 모드입니다.– AC : 한 서비스에 대한 인스턴스가 여러 노드에서 동시에 실행되어 동작 가능한 모드입니다. (기본값)– HA : 한 서비스에 대한 인스턴스가 하나만 동작 가능한 모드입니다.
cname
string
해당 서비스 리소스가 속할 클러스터 리소스 이름입니다. (mandatory)
AS 서비스의 경우에는 한 클러스터 당 하나만 등록 가능합니다. 서비스 리소스는 특정 클러스터를 지정하여 추가하도록 되어 있는데, 한 노드에 추가하면 해당 노드가 속한 클러스터의 모든 노드에 자동으로 공유됩니다.
cmrctl add db
Tibero 인스턴스를 추가하는 명령어입니다. DB 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 시도 간의 간격입니다.(단위: 초, 기본값: 1)
다음은 envfile을 입력하지 않았을 때 default로 수행되는 내용입니다. 이 외의 환경변수들은 CM이 부팅할 때 터미널이 가지고 있던 환경변수가 그대로 적용됩니다. LD_LIBRARY_PATH는 Linux 또는 SunOS를 사 용할 경우이고, AIX를 사용할 경우 LIBPATH, HP-UX는 SHLIB_PATH를 export합니다. 환경변수 설정에 대 한 자세한 내용은 "Tibero 설치 안내서"를 참고합니다.
cmrctl add as
AS(Active Storage) 인스턴스를 추가하는 명령어입니다. AS 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"를 참고합니다.
cmrctl add vip
VIP를 등록하기 위해서는 tbcm이 ROOT 권한으로 실행되어 있어야 하며, svcname으로 지정한 서비스에 pubnet attribute가 등록되어 있어야 합니다. 환경변수 PATH에 /sbin 경로가 잡혀있지 않으면 VIP alias에 실 패하므로 확인해야 합니다. 또한 vip 기능 사용을 위해 net-tools를 반드시 설치해야 합니다.
VIP failover/failback
클러스터의 특정 노드에서 장애가 발생하면 사용 중인 VIP를 정상적으로 작동하는 노드 중 한 노드에 VIP를 옮겨 설정합니다(failover). 이를 통해서 Tibero는 장애가 발생한 노드의 VIP로도 계속해서 서비스 를 할 수 있습니다. 장애가 발생했던 노드가 복구되면 다시 원래 소유했던 노드로 VIP를 옮겨 설정합니다(fail back).
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)
retry_cnt
integer
최대 retry 시도 횟수 (기본값: 3)
retry_interval
integer
retry 시도 간격 (단위: 초, 기본값: 0(retry 기능 사용하지 않음))
참고
VIP로 접속할 때 사용해야 할 포트는 DB인스턴스에서 LISTENER_VIP_PORT로 설정이 가능합니다. 설정한 포트는 VIP failback 과정에서 세션을 정리해주기 위해 잠시 막힌다. LISTENER_VIP_PORT 와 LISTENER_PORT를 다르게 설정합니다면 VIP failback 과정 중에도 LISTENER_PORT로의 접속 은 가능합니다.
cmrctl add group
그룹 리소스를 추가하기 위한 명령어입니다. 그룹은 클러스터라는 환경 위에서 제공하는 에이전트의 집합 을 관리하기 위한 개념입니다.
name
string
그룹 리소스 이름(unique, mandatory)
grptype
string
그룹의 타입(optional)
그룹의 종류를 나타내기 위한 용도 (기본값: "")
failover
boolean
그룹에 속한 에이전트의 failover 기능 사용 여부
true : 에이전트가 종료되었을 때 failover 기능 사용 여부(기본값, optimal)
false : 에이전트는 failover되지 않음
cname
string
해당 서비스 리소스가 속할 클러스터 리소스 이름(mandatory)
그룹 리소스는 특정 클러스터를 지정하여 추가하도록 되어 있는데, 한 노드에 추가하면 해당 노드가 속한 클러스터의 모든 노드에 자동으로 공유됩니다.
cmrctl add agent
에이전트를 추가하는 명령어입니다.
name
string
에이전트 리소스 이름
에이전트 리소스의 name은 관리하고자 하는 에이전트의 이름과 동일해야 함
등록된 이름으로 pid를 찾음 (unique, mandatory)
grpname
string
에이전트 리소스가 속할 그룹 리소스 이름 (mandatory)
script
string(file path)
에이전트 관리를 위해 수행할 스크립트의 절대 경로(mandatory)
에이전트별로 별도의 스크립트를 구성 및 등록하면 cm에서 주기적으로 스크립트를 수행
retry_cnt
integer
최대 retry 시도 횟수 (기본값: 3)
pubnet
string
public 네트워크는 클러스터의 failover 조건이 아니므로 failover 조건에 네트워크를 추가하기 위한 용도(optional)
cmrctl del (delete)
특정 리소스를 삭제하기 위한 명령어이며, DOWN 또는 DEACT 상태의 리소스만 삭제 가능합니다.
cmrctl show
CM에 등록된 리소스의 정보를 확인하기 위한 명령어입니다.
다음의 3가지 방법으로 사용이 가능합니다.
방법 1)
현재 CM 데몬에 등록된 리소스의 목록을 출력합니다.
현재 CM 데몬의 클러스터에 등록된 모든 노드의 리소스의 목록을 출력합니다.
방법 2)
현재 CM 데몬에 등록된 리소스들 중 <resource_type>의 리소스 목록을 출력합니다.
방법 3)
지정한 특정 리소스의 상세한 정보를 출력합니다.
cmrctl start
특정 리소스를 시작하기 위한 명령어입니다. 서비스 리소스를 start하는 경우 해당 서비스에 속한 모든 인스 턴스를 기동시킵니다.
서비스나 인스턴스 리소스의 경우 --option을 통해 bootmode를 지정해줄 수 있습니다.
cmrctl stop
특정 리소스를 중지하기 위한 명령어입니다. 서비스 리소스를 stop하는 경우 해당 서비스에 속한 모든 인스 턴스를 중지시킵니다. 또한, auto-restart 기능이 동작 중이라면 중지됩니다.
서비스나 인스턴스 리소스의 경우 --option을 통해 shutdown mode를 지정해줄 수 있습니다.
auto-restart 모드가 동작 중에 서비스의 인스턴스가 중지된 경우 해당 상황을 인지한 후에 중지된 인스턴 스를 재시작시켜주는 기능입니다.
cmrctl act
다음의 이유로 인해 deactivate된 리소스를 다시 activate시켜주기 위한 명령어입니다.
DB 또는 AS 리소스를 추가할 때 입력한 retry_cnt(기본값: 3) 이상 start를 수행했는데도 실패한 경우
사용자가 cmrctl deact 명령어를 명시적으로 사용하여 비활성화시킨 경우
서비스 리소스를 act하는 경우에는 해당 서비스 리소스의 인스턴스들에 대한 auto-restart 기능을 동작시 키겠다는 의미로 사용됩니다.
cmrctl deact
특정 리소스를 deactivate시켜주기 위한 명령어이며, deactivate된 리소스는 auto-restart 대상에서 제외된 다. 서비스 리소스를 deact하는 경우에는 해당 서비스 리소스의 인스턴스들에 대한 auto-restart 기능을 중 지시키겠다는 의미로 사용됩니다.
cmrctl modify
인스턴트 리소스의 retry_cnt, retry_interval을 변경시켜 주기 위한 명령어입니다.
cmrctl relocate
CM 멀티노드 환경에서 vip의 소유권 이전/변경하기 위한 명령어입니다.
target_nid는 vip 소유권을 가질 노드로서 cmrctl show cluster --name [cluster_name] 명령어를 통해 노드 별 nid 및 현재 vip를 소유하는 nid를 확인할 수 있습니다.
crfconf 명령어
cmrctl 명령어의 경우 CM이 온라인 상태일 때 CM에 접속하여 사용자가 리소스를 관리할 수 있는 명령어 라면, crfconf는 CM이 오프라인 상태일 때 CM TIP에 지정된 경로에 있는 CM 리소스 파일에 접근하여 해 당 파일을 관리할 수 있도록 하는 유틸리티입니다. CM 리소스 파일의 경우 바이너리 파일이기 때문에 사용 자가 임의로 파일을 수정할 수 없습니다. 따라서, 사용자가 CM을 부팅하기 전에 CM 리소스 파일에 있는 리소 스 정보를 변경하려면 crfconf를 사용하여 원하는 작업을 수행할 수 있습니다. 이때 VIP 등과 같은 글로벌 리 소스의 변경을 시도하는 경우에는 마스터가 관리하기 때문에 마스터로 기동할 CM의 CM 리소스 파일을 변경해야 정상적으로 적용됩니다.
crfconf의 사용법은 cmrctl과 동일하며, 사용 가능한 action이 add, del, show의 3가지로 제한됩니다는 점만 다릅니다.
CM이 리소스 파일에 접근할 수 있는 CM 동작 상황에서는 crfconf를 수행할 때 다음과 같은 에러를 출력 하며 실패로 처리됩니다.
Cluster Resource의 ROOT 모드
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 모드인지는 다음의 방법으로 확인 할 수 있습니다.
다음은 2-node-cluster에서 두 노드 모두 ROOT 권한이 있는 CM으로 접속한 상황입니다. Status의 UP 옆에 (ROOT)라는 표시는 cluster가 ROOT 모드임을 의미하며, NODE LIST에 Mst 아래 R은 각 노드 CM의 ROOT 권한 소유를 의미합니다.
다음은 두 노드 모두 ROOT 권한이 없는 CM으로 클러스터에 접속한 상황입니다. 앞에서와 달리 Status에 (ROOT)가 없고, NODE LIST에도 Mst에 R을 가진 노드가 없습니다.
다음은 한 노드가 ROOT 권한이 없는 CM으로 클러스터에 접속하고, 다른 노드는 ROOT 권한을 가진 CM 으로 접속한 상황입니다. 노드 2번만 Mst에 R이 있고, 클러스터가 ROOT 모드가 아니므로 Cluster Resource Info의 Status에 (ROOT)가 없습니다.
마지막으로 바로 위의 상황에서 루트 권한이 없는 1번 노드의 클러스터를 stop시킨 후 다시 cluster start를 하려는 상황입니다. 1번 노드에서 클러스터가 stop됨으로 인해 클러스터에 ROOT 권한 노드만 남게 되고, 이에 따라 클러스터가 ROOT 모드가 됨을 확인할 수 있습니다. 또한 클러스터가 ROOT 모드이므로, ROOT 권 한이 없는 1번 노드 CM은 클러스터에 재접속할 수 없게 됩니다.
1번 노드
2번 노드
TAC 구성
본 절에서는 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>>
<<cm2.tip>>
다음으로 TAC용 TIP 파일을 설정해야 합니다.
본 예제에서는 1번 노드를 위한 TAC TIP 파일을 1번 노드의 $TB_HOME/config 아래에 ac1.tip으로, 2 번 노드를 위한 TAC TIP 파일을 2번 노드의 $TB_HOME/config 아래에 ac2.tip으로 저장합니다. “Tibero Active Cluster”를 보면 각 파라미터들의 의미를 알 수 있습니다(본 예제에서는 TB_HOME이/home/tibero7 입니다).
<<ac1.tip>>
<<ac2.tip>>
1번 노드부터 구성을 하면 먼저 CM을 실행시켜야 하는데, 이를 위해서는 CM_SID가 앞서 작성한 TIP
파일의 파일 이름과 같아야 합니다(따라서 본 예제에서는 CM_SID가 cm1이어야 합니다).
CM_SID를 설정하기 위해 아래의 내용을 터미널에서 실행시킨다. TB_SID도 같이 설정합니다(나중에 데 이터베이스를 만들 때 필요합니다).
이렇게 CM_SID 설정을 완료하면, 아래의 명령어를 이용해 CM을 실행합니다.
성공적으로 부팅되었습니다면, 다음과 같이 출력됩니다.
이 과정을 거치고 나면 CM_RESOURCE_FILE에 설정해 놓은 디렉터리에 cm1_res.crf라는 리소스 바 이너리 파일이 생성되게 됩니다. 이 파일에 앞으로 등록할 리소스에 대한 정보들이 저장됩니다.
완료되면 CM의 부팅 상태를 확인하기 위해 다음과 같이 명령어를 실행합니다.
다음과 같이 나온다면 정상적인 상황입니다(아직 아무런 리소스도 등록하지 않았기 때문에 CLUSTER, TYPE, NAME, STATUS, DETAIL이 모두 빈칸입니다).
먼저 아래의 명령어처럼 네트워크 리소스를 등록합니다.
성공적으로 리소스가 등록되면 다음과 같이 출력됩니다.
다시 한 번 cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력됩니다.
다음으로 아래의 명령어와 같은 방법으로 클러스터를 등록합니다. 이때, cfile이 저장될 폴더는 미리 만들 어 놓아야 합니다. 또한, cfile 경로는 공유 디스크에 있도록 지정해야 합니다.
성공적으로 클러스터 리소스가 등록되면 다음과 같이 출력됩니다.
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력됩니다.
등록된 클러스터 아래에 TAC 서비스 리소스를 등록해야 하는데, 그에 앞서 클러스터 cls1을 활성화시 켜야 합니다.
성공적으로 클러스터가 시작되면 root 권한 여부에 따라 다음과 같이 출력 됩니다. (이때 실패한다면 cfile이 저장될 디렉터리를 미리 안 만들어 놓았을 가능성이 높습니다.)
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력됩니다.
다음과 같은 명령어를 이용해 서비스 리소스를 등록합니다(이때, 서비스의 이름은 나중에 만들 데이터베 이스의 이름과 같아야 합니다).
성공적으로 등록하면 다음과 같이 출력됩니다.
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력됩니다.
마지막으로 DB 리소스를 등록합니다.
여기서 --name의 값은 Active Cluster에서 해당 노드가 사용할 TB_SID(본 예제에서는 ac1를 사용)와 같아야 합니다. ac1를 위한 환경변수 설정을 담은 envfile은 /home/tibero7/ 아래에 envfile_ac1으로 저장 하였다.
성공적으로 등록하면 다음과 같이 출력됩니다.
cmrctl show를 이용하여 리소스 상태를 확인하면 다음과 같이 출력됩니다.
이제 실제로 운용할 데이터베이스를 만들어야 합니다. “TAC를 위한 데이터베이스 생성” 과정의 2번
~ 6번까지의 과정을 실행합니다. 과정을 수행하는 데 다음의 두 가지 유의사항을 지켜야 합니다.
– tbsql로 접속하기 위해 tbdsn.tbr을 설정할 때 다음과 같은 내용들을 넣어주어야 합니다.
– 접속 후 “TAC를 위한 데이터베이스 생성”에서 데이터베이스를 만들 때 CREATE DATABASE "ac" (앞서 입력한 서비스 리소스의 이름)로 해야 합니다. 데이터베이스 생성을 모두 마치고 나면, cmrctl show의 결과에서 다음과 같이 STATUS가 모두 UP으로 바뀌어 있습니다.
이로써 첫 노드에서의 구성이 끝났다. 이제 다음 노드를 구성해야 합니다. 먼저 2번 노드의 tbdsn.tbr 설정 을 마친 후 다음의 명령어들을 차례대로 입력합니다. 이때 유의할 점은 클러스터를 추가할 때 cfile의 경로 가 앞서 1번 노드에서 설정한 cfile의 경로와 같아야 합니다.
cmrctl show를 해보면 다음과 같이 서비스가 이미 등록되어 있는 것을 확인할 수 있습니다. 이는 cfile에 있 는 내용을 cm1에서 직접 읽어왔기 때문입니다.
마지막으로 ac2이 사용할 envfile을 저장한 후 다음의 명령어들을 입력하면 2 노드 TAC 구성과 실행이 완료됩니다.
TAS-TAC 구성
본 절에서는 먼저 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를 구성하고 “TAC 구성”에 설명된 정보를 수정해서 수행합니다.
다음은 수행과정에 대한 설명입니다.
cm1.tip과 cm2.tip은 “TAC 구성”을 참고해서 생성합니다.
다음 TIP 파일 내용에서 메모리 사이즈 등 다양한 수치들은 예제일 뿐이고, 사용 목적에 맞게 조정할 수 있습니다(본 예제에서는 raw 디바이스를 사용하지 않고, 각각의 용량이 5GB인 /data/disk01과 /data/disk02 라는 두 파일을 사용하여 한 컴퓨터에 두 노드를 띄울 예정입니다). 디스크 구성은 "Tibero Active Storage 관리자 안내서"의 "디스크 준비"를 참조합니다.
<<as1.tip>>
<<as2.tip>>
TAS용 TIP 파일이 준비되면 1번 노드부터 순서대로 설정합니다.
먼저 1번 노드에서 export CM_SID=cm1으로 환경변수를 설정합니다. 그 후, CM을 부팅하여 네크워크를 추가하는 곳까지 앞의 내용대로 수행하여 cmrctl show 커맨드를 수행하였을 때 다음과 같이 조회될 수 있도록 합니다.
다음으로 클러스터를 등록해야 하는데, 다음과 같이 cfile 부분이 앞에서와 달라집니다.
성공적으로 수행 되었습니다면,TB_SID를 as1으로 export 한 후 다음의 커맨드를 수행하여 TAS 인스턴스 를 띄운다(“14.6. TAC 구성”과 달리 클러스터를 start시키지 않습니다).
부팅이 완료되면 tbsql을 통해 TAS 인스턴스에 접속하여 다음과 같은 sql로 디스크 스페이스를 만든다 (TAS에서도 Tibero 혹은 TAC와 마찬가지로 tbdsn.tbr에 as1의 설정을 써주어야 tbsql로 인스턴스에 접 속할 수 있습니다).
수행 완료 후 tbsql을 종료하고, TAS 인스턴스도 종료되었음을 확인한 후 아래의 커맨드를 통해 클러스 터를 실행시킨다.
그 후 cmrctl show를 이용해 리소스를 확인해 보면 다음과 같이 조회됩니다.
이제 다음의 커맨드를 사용하여 as용 서비스 리소스를 등록합니다.
다음으로 as를 등록합니다. envfile은 tibero7/ 아래에 envfile_for_as1으로 저장하였고, --name의 값은 TIP 파일에 사용된 이름인 as1로 해야 합니다.
다음의 커맨드를 통해 TAS 인스턴스를 normal 모드로 부팅시킨다.
위의 커맨드를 통해 TAS 인스턴스가 성공적으로 부팅되었으면, 다음과 같이 tbsql로 커맨드를 수행하 여 2번 노드의 TAS 인스턴스가 사용할 스레드를 생성해야 합니다.
여기까지 왔으면 나머지 2번 노드에서도 TAS 인스턴스를 띄울 준비가 완료된 것입니다.
2번 노드에서 export CM_SID=cm2와 export TB_SID=as2 커맨드를 수행하여 환경변수를 설정해준다. 그 후 tbcm -b로 CM을 부팅하고, 다음의 커맨드들을 수행해준다(본 예제에서는 같은 컴퓨터에 두 노드 를 구성하므로 네트워크의 ippaddr이 cm1에서와 같고 portno만 다릅니다).
이제 cmrctl show를 실행해보면 다음과 같이 서비스가 등록된 것을 확인할 수 있습니다.
다음의 커맨드로 AS를 등록한 후 2번 노드에서도 TAS 인스턴스를 실행시킨다.
정상적으로 위 과정이 수행되었습니다면 각 노드에서의 cmrctl show의 결과는 다음과 같이 출력됩니다.
노드 1에서의 cmrctl show 결과
노드 2에서의 cmrctl show 결과
두 노드에서의 TAS 구성이 완료되었습니다. 이제 각 노드에서 TAC 구성을 진행하면 됩니다. 먼저 각 노드의 $TB_HOME/config에 ac1.tip과 ac2.tip을 만드는데, 내용은 다음과 같이 합니다.
<<ac1.tip>>
<<ac2.tip>>
TAC용 TIP 파일을 저장하였으면, 각 노드에 아래의 커맨드를 수행합니다(각 노드의 TB_HOME에 en vfile_ac1과 envfile_ac2를 만들었다. envfile에 대한 내용은 “cmrctl add”와 “TAC 구성”을 참고합니다).
1번 노드
2번 노드
이제 1번 노드에서 “TAC를 위한 데이터베이스 생성”의 2번부터 6번까지 과정을 수행합니다. 이때 DB 인스턴스를 nomount 모드로 부팅하는 커맨드로 다음의 명령어를 사용합니다.
또는
“TAC를 위한 데이터베이스 생성”의 6번까지 과정을 수행하고 나면 다음의 명령어를 통해 각 노드 에 DB를 띄워 TAS-TAC 구성을 마친다. 단, 데이터베이스를 생성하는 과정에서 logfile의 경로를 지정 할 때에는 '+DS0/log001'(+는 TAS용 경로임을 표시하고, DS0는 앞서 생성한 디스크 스페이스 이름이 다.)과 같은 TAS용 경로를 사용해야 합니다.
HA Service 구성
본 절에서는 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은 “TAC 구성”에서와 똑같이 작성하고, ha1.tip과 ha2.tip만 다음과 같이 작성한 다(본 예제에서는 쉬운 설명을 위해 같은 컴퓨터에 두 노드를 띄웠다).
<<ha1.tip>>
<<ha2.tip>>
HA용 TIP 파일이 준비되었으니, ha1과 ha2를 위한 envfile을 만든 후 다음과 같은 커맨드로 네트워크 와 클러스터, 서비스, HA를 등록합니다.
1번 노드
2번 노드
이제 운용할 데이터베이스를 만들어야 합니다.
먼저 NOMOUNT 모드로 부팅한 후 single Tibero에서와 같은 방식으로 데이터베이스를 생성합니다. 이 때역시 tbsql 접속을 위한 tbdsn.tbr 파일에 ha1을 추가해주어야 합니다. 그 후 system_install.sh를 수행하면 데이터베이스 생성이 완료됩니다.
마지막으로 다음의 커맨드를 1번 노드에 적 용하면 1번 노드가 다운되고 retry_cnt만큼 재기동에 실패하여 DEACT 처리되었을 때 2번 노드에 DB 인스턴스가 실행되게 됩니다(1번 노드가 Active, 2번 노 드를 Standby라고 하며 이는 cmrctl show service --name ha로 확인 가능합니다).
만약 1번 노드가 다운되어 2번 노드가 자동실행되면, 1번 노드가 deact되어 있을 수 있습니다. 이 경우 deact된 리소스를 act시켜주면 1번노 드가 standby가 되어 2번 노드를 failover하게 됩니다.
CM Observer 구성
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가 설치된 경로로 지정
예)export CM_HOME=/home/tibero7
$CM_SID
노드를 식별할 수 있는 ID를 지정
각 노드는 서로 다른 값을 가져야 함
예)export CM_SID=cmobs
파라미터 설정
본 절에서는 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)
필수 DB 파라미터
CM Observer를 정상적으로 사용하기 위해 DB TIP에 Observer에 대한 파라미터를 설정해야 합니다.
STANDBY_USE_OBSERVER
일반적인 Tibero-TSC 구조에서 Observer를 통해 관제 및 Failover를 진행할지를 결정(필수 설정 값: Y)
CM Observer 실행
CM Observer 데몬 실행 이후의 작업들은 cmrctl 명령어를 사용하여 수행합니다. CM Observer는 다음의 방법으로 실행합니다.
[option]
-b
CM Observer 데몬을 실행
-d
CM Observer 데몬을 종료
-s
CM Observer의 상태를 보여줌
초기화 파라미터에 등록된 내용이 표시됨
-h
tbcmobs 명령어에 대한 도움말을 보여줌
Observer 명령어
cmrctl은 New CM 및 Observer에서 리소스들을 관리 및 제어하기 위해 사용하는 명령어 set입니다. 단 지원 하는 명령의 종류는 New CM일 때와 Observer일 때 서로 다르며, Observer에서 지원하는 cmrctl 명령어 용법은 다음과 같습니다.
cmrctl show
Observer에 등록된 리소스의 정보를 확인하기 위한 명령어입니다. 다음의 2가지 방법으로 사용이 가능합니다.
방법 1)
현재 CM Observer에 등록된 CM 및 DB Instance들의 목록을 출력합니다.
방법 2)
지정한 특정 TSC의 상세한 정보를 출력합니다.
cmrctl set
Observer에 등록된 TSC의 동작을 설정하기 위한 명령어입니다. 다음의 3가지 방법으로 사용이 가능합니다.
방법 1)
위의 명령 상으로 지원하는 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)
지정한 특정 TSC의 failover 대상(Target)을 특정 클러스터로 설정(고정)하거나, 가장 최신의 TSN을 받 은(Most Received) 클러스터가 failover 대상(Target)이 되도록 합니다.
방법 3)
Failover 대상 클러스터 설정 및 auto_failover 여부를 설정합니다.
cmrctl switchover
지정된 tsc를 switchover하기 위한 명령어입니다. 다음의 2가지 방법으로 사용이 가능합니다.
방법 1)
현재 Target 클러스터로 switchover를 수행합니다.
방법 2)
지정한 Target 클러스터로 switchover를 수행합니다.
Observer 구성 예시
다음은 Observer를 구성하는 과정에 대한 설명입니다.
CM TIP 파일의 설정과 DB TIP 파일의 설정은 “TAC-TSC 구성”을 참고하여 작성합니다.
다음은 Observer TIP 파일의 예시입니다.
<<cmobs.tip>>
다음은 일반적인 CM TIP 파일의 예시입니다.
<<cm1.tip>>
Observer용 TIP 파일 및 다른 CM, DB TIP 파일들이 준비되었으니, 네트워크와 클러스터, 서비스, DB 를 등록합니다. 대부분의 등록과정은 “TAC-TSC 구성”과 같습니다. 단, DB 서비스 등록과정이 약간 상이하나, 아래의 예시와 같이 서비스 등록과정에서 이를 관제할 Observer의 ip와 port, TSC ID를 명시해주어야 합니다(본 예제에서는 쉬운 설명을 위해 같은 컴퓨터에 옵저버와 노드를 띄웠습니다).
– Observer 미사용 시 DB 서비스 등록
– Observer 사용 시 DB 서비스 등록(관제 대상 CM 노드에서 서비스 등록 시)
관제 대상 CM은 이를 통해 Observer에 등록됩니다.
구성이 완료되면 Observer에서 cmrctl show 명령을 통해 아래와 같이 TSC가 구성되었음을 확인할 수 있습니다.
– Observer가 관제하는 cm 및 DB Instance 확인
– 특정 TSC에 대한 정보 확인
Observer 동작
다음은 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를 사용하는 경우 기동과 종료는 다음의 순서를 따릅니다.
기동
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 종료
CM STONITH 기능 구성
cm의 cluster 구성에서 어떤 노드의 문제가 발생하게 된다면 schedule out이 진행됩니다. Schedule out 과정 에서 해당 노드가 이미 종료되어 있지 않는다면 해당 노드에게 schedule out 사실을 알려주고 종료 과정을 수행하도록 합니다. 그 후 cluster에 속한 resource들의 재구성이 시작됩니다.(ex. service reconfiguration)
이 때, 해당 노드가 hang이 걸려 종료를 처리하지 못하는 경우가 발생할 수 있습니다. 이 경우 cluster에 속한 re source가 재구성 되었을 때, schedule out 되었지만 아직 종료과정을 완료하지 못한 노드에 의해 오류가 발생하게 됩니다. 이를 해결하는 간단한 방법은 해당 노드가 종료를 알려오는 것을 기다리는 방식입니다. 하지만 hang이 1-2시간 이상 지속되는 경우라면, 기다리는 해결법은 장시간 service 불가를 유발하게 됩니다. 따라서 정상 동작(cluster의 master로서 여러 동작들 수행) 중인 master 노드에서 schedule out된 노드가 cluster의 공유 볼륨에 접근하는 것을 차단하는 기능을 개발하게 되었습니다.
각 사용법을 확인 후 “STONITH 기능 주의 사항” 부분을 반드시 참고해야 합니다.
sg_persist를 사용하는 STONITH 기능
개요
본 기능의 경우 sg_persist라는 툴을 사용하여 진행됩니다. sg_persist는 device에 registration & reservation 을 수행하기 위한 SCSI PERSISTENT RESERVE 명령어를 날려주는 툴입니다. 간단하게 설명하면 각 노드 는 device에 registration을 통해 자신의 key를 등록할 수 있고 이 key를 이용해 해당 device의 접근 방식을 reservation할 수 있습니다. 기본적으로 write exclusive mode 즉, key를 등록한 노드만 write을 할 수 있는 모드 로 설정하였다. 그리고 어떤 node가 schedule out 시 해당 node의 key를 제거함으로써 더이상 device에 write을 수행하지 못하도록 만들었다. 이를 통해 schedule out된 노드가 공유 볼륨을 접근해서 유발되는 문제를 차단할 수 있게 됩니다.
자신의 노드에서 종료를 진행하는 기존의 fencing 방식과 달리 sg_persist를 이용하게 되면 다른 노드에서 fencing을 진행하게 되며, 이러한 방식을 일반적으로 STONITH(Shoot The Other Node In The Head)라고 부른다.
설정 방법
device를 multipath를 이용하여 구성했을 경우, “mpathpersist를 사용하는 STONITH 기능” 설명을 참고합니다.
sg_persist를 사용하기 위해서는 관련 툴이 설치되어 있어야 합니다. 아래 명령어를 통해 관련 툴이 설치되 어 있는지 확인 가능합니다.
설치되어 있지 않는 경우, 설치 명령어를 통해 설치를 진행해야 합니다.
sg_persist가 최신 버전으로 올라가며 여러가지 오류 수정이 있어 아래와 같이 버전 업데이트를 수행해야 합니다. (2020년 이후 출시 버전을 추천합니다.)
sg_persist를 사용하기 위해서는 CM의 root 권한 기동이 필요합니다.
CM tip에 관련 IPARAM설정이 필요합니다.
cluster add 시 --stonith 옵션을 통해 관리할 디바이스 목록을 입력해 주어야 기능이 동작합니다. 이 옵션의 경우 모든 cluster에서 입력해야 하며 입력하지 않을 경우 cluster join이 거부됩니다.각 cluster에서 입력한 디바이스 목록은 동일 디바이스를 가리키고 있어야 하며 그렇지 않을 경우 이상 동작을 하게 됩니다.
아래와 같은 방식으로 옵션을 추가하여 입력합니다.
추가한 정보를 확인하는 방법은 다음과 같습니다.
mpathpersist를 사용하는 STONITH 기능
개요
서버에서 한 device에 대해 물리적으로 분리된 여러 I/O path를 가지게 할 수 있고 이를 device mapper multipath 기능이라고 합니다. 이 multipath로 구성된 device에 대해서 linux의 경우 sg_persist의 multipath 전용의 mpathpersist라는 툴을 이용합니다. 해당 툴의 경우 linux에서만 동작 확인이 되었으며, solaris / hp- ux 등은 별도의 테스트가 필요합니다. 또한, linux의 경우에도 /etc/multipath.conf 에 설정할 내용 중 redhat
7.5 이상 버전에서만 동작하는 내용이 있어 우선 7.5 이상 버전에서만 지원하고 있습니다. (7.5 release date 2018-04-10) (cat /etc/redhat-release 로 OS 버전 확인이 가능합니다.)
설정 방법
mpathpersist가 최신 버전으로 올라가며 여러가지 오류 수정이 있어 아래와 같이 버전 업데이트를 수행해야 합니다. (2020년 이후 출시 버전을 추천합니다.)
sg_persist 버전과 마찬가지로 root 권한 기동이 필요합니다. 루트 권한으로 /etc/multipath.conf 의 defaults란에 reservation_key file 옵션 추가가 필요합니다.
그 후 루트 권한으로 아래 명령어를 수행합니다.
reload 후 루트 권한으로 multipath -ll 을 입력해 보았을 때 정상적으로 뜨지 않고 config file parsing 실패 와 같은 에러 message가 뜬다면 옵션을 지원하지 않는 버전이므로 /etc/multipath.conf의 reservation_key file을 지우고 service multipathd start를 수행해주어야 합니다.
CM tip에 관련 IPARAM설정이 필요합니다.
sg_persist 사용 시와 마찬가지로 cluster add시 --stonith 옵션을 통해 관리할 디바이스 목록을 입력해 주 어야 기능이 동작합니다. 이 옵션의 경우 모든 cluster에서 입력해야하며 입력하지 않을 경우 cluster join이 거부됩니다. mpathpersist를 쓸 경우 cluster add 시 --stonith 옵션의 입력값으로 multipath 경로를 입력해야 합니다.
multipath -ll을 통해 나오는 경로로 --stonith "/dev/mapper/mpatha" 혹은 --stonith "/dev/dm-3" 와 같 이 입력해야 합니다. 해당 경로를 별도로 링크를 걸어둔 상태라면 그 링크를 입력해도 무방합니다.
STONITH 기능 주의 사항
스토리지 관련 주의사항
스토리지가 SCSI-3 Persistent Reservation을 지원해야 합니다. 만약 지원하지 않습니다면, 일반적으로 --stonith옵션을 준 cluster add가 실패하고 기능을 사용할 수 없음을 의미합니다.
스토리지가 별도의 툴을 통하여 이미 관리되고 있는 상태라면 사용이 불가합니다. 해당 툴과 어떠한 문제를 일으킬 지 모르기 때문입니다.
기능 사용 관련 주의사항
본 기능은 기본적으로 지속적으로 사용하는 것을 가정하여 만들어 졌다. 따라서 전체 노드를 종료하더라 도 device에 등록된 정보가 남아 있으며, 새로 cm이 기동하여 cluster가 최초 기동할 때, 이 정보를 초기화 하고 재등록 하게 됩니다.
만약 전체 cluster 종료 후 cluster에 stonith 옵션으로 입력한 device에 대해 어떠한 작업을 수행해야 합니다 면, 아래 기술할 stonith 기능 해제 방법을 참고하여 해제 후 수행하거나 작업할 노드의 cm 기동 후 cluster 수준까지 기동하여 노드가 권한을 가져온 후 수행해야 합니다.
혹은 기능을 사용합니다 사용하지 않게 될 경우 device에 등록된 정보를 제거해 주어야 하며 이 방법은 다음 과 같습니다.
아래 동작들은 반드시 전체 cluster가 종료된 후 수행되어야 합니다.
device에 등록된 정보를 제거하는 과정이며 해당 device가 공유 볼륨이라 한 노드에서만 수행해도 전체에 적용이 되어 sg_persist, mpathpersist 방법 모두 한 노드에서만 수행하면 됩니다.
cm에 등록된 정보를 이용하여 제거 (반드시 cluster stop 상태에서 수행해야 함)
sg_persist 명령어를 이용하여 제거 (루트 권한 필요)
device 경로에 /dev/raw/raw*와 같이 hint를 주는 것은 동작하지 않으며 device 개수마다 별도로 수행해 주어야 합니다.
mpathpersist의 경우 sg_persist 부분을 mpathpersist로 대체하면 됩니다.
CM 에이전트 구성
CM 에이전트는 TAC 구조에서 CM이 리소스 관리 및 failover 기능이 필요한 프로그램을 등록하여 사용할 수 있습니다. (ex. prosync)
파라미터 설정
CM 에이전트에서 사용되는 파라미터에 대해서 설명합니다.
CM_ID
선택
CM을 식별하기 위해 고유 번호를 설정
에이전트에서 특정 CM을 지정하기 위해 사용(기본값: -1)
CM_AGENT_THREAD_CHECK_EX PIRE
선택
에이전트 스레드가 동작하지 않는 시간을 확인하기 위한 파라미터로 CM_AGENT_THREAD_INTERVAL 보ek 4배 이상 값을 권고하고, cmrctl check agent로 정상/비 정상을 확인할 수 있음 (기본값: 40s)
CM_AGENT_THREAD_INTER VAL
선택
에이전트 스레드가 반복하여 동작하는 주기(기본 값: 10s)
CM 에이전트 count 값
CM 에이전트에서 사용하는 count 값 설명으로 cmrctl show agent에서 확인 가능합니다.
MAX retry count
cmrctl add 명령어에서 입력한 --retry_cnt에 해당하는 값
Failed retry count
probe를 제외한 명령어 실패한 횟수
Probe retry count
probe 명령어 실패한 횟수
start retry count
cmrctl start 명령어 실패한 횟수
Abnormal count
script가 문제가 생겨서 실패한 횟수
CM 에이전트 명령어
cmrctl은 New CM에서 리소스들을 관리 및 제어하기 위해 사용하는 명령어입니다. 에이전트와 관련된 명령어 사용법은 다음과 같습니다.
cmrctl act
다음의 이유로 인해 deactivate된 리소스를 다시 activate시켜주기 위한 명령어입니다.
에이전트를 추가할 때 입력한 --retry_cnt(기본값: 3)이상 start를 수행했는데도 실패한 경우
사용자가 cmrctl deact 명령어를 명시적으로 사용하여 비활성시킨 경우
에이전트를 추가할 때 입력한 --script에 문제가 있는 경우
입력한 경로에 스크립트 파일이 없는 경우
스크립트의 실행 권한이 없는 경우
스크립트가 문제가 생겨 timeout될 경우
cmrctl modify
그룹 리소스의 failover 기능 사용 여부를 수정하기 위한 명령어입니다.
CM 에이전트 스크립트 설정 예시
cmrctl add agent 등록시 --script에 입력한 스크립트 파일에 대한 예시입니다.
<<$TB_HOME/agent0.sh>>
Last updated