복사본 1 Tmax Administration Guide · 2019. 4. 9. · 135-708 서울시 강남구 대치동 946-1 글라스타워 18층 Tel: +82-2-6288-2114, 2006 Fax: +82-2-6288-2115 E-Mail:

Tmax Administration

Guide

파트번호 : TMAG-0119-09-380 버 전 : Tmax 3.8 개 정 : Jan 19, 2004 인 쇄 : Jan 19, 2004

Tmax Administration Guide 1

Tmax Administration Guide

Tmax 3.8


저작권 Copyright (c) 2004 Tmax Soft Co., Ltd. All Rights Reserved. 본 서의 일부나 전체의 내용은 어떠한 형태로든 무단 복제를 금하며 전기적, 물리적, 사진, 기록 또는 다른 매체로의 복제를 위해서는 반드시 Tmax Soft의 사전 동의를 얻어야 합니다. 본 제품 사용 중 일어난 특정한, 우발적, 비직접적, 필연적인 손실을 책임지지 않습니다. 그러나 특수한 목적에 적합하고 유통가능하며 규정사항에 위배되지 않을 경우에는 제외됩니다. 본 서에는 기술적인 오류나 인쇄상의 오류가 있을 수 있습니다. 본 서의 내용 중 수정된 부분은 정기적으로 제품의 개정본에 추가 될 것입니다. 본 문서에 포함된 내용은 별도의 사전 통보 없이 내용을 보강하기 위해서 수정되어질 수 있습니다.

상표 Tmax, WebT, WebtoB, JEUS, Host-Link, WebInOne 은 Tmax Soft Co., Ltd.의 상표입니다.

업체 정보 ㈜ Tmax소프트 135-708 서울시 강남구 대치동 946-1 글라스타워 18층 Tel: +82-2-6288-2114, 2006 Fax: +82-2-6288-2115 E-Mail: [email protected]

Tmax Administration Guide Document Edition Date Version TMAG-0119-09-380 Jan 19, 2004 Tmax 3.8

Tmax 제품은 아래 표와 같습니다. 본 서는 Tmax Standard와 옵션 중에 굵게 기울임꼴로 인쇄되어 있는 내용을 포함하고 있습니다. Tmax Standard TP Function + 2 Phase Commit

Tmax Options Web Admin Console, X.25 Gateway, TCP/IP Gateway, Host-Link, Power Builder Interface Module, SERIAL Gateway, TCP/IP Service Gateway


이 책에 관하여… Tmax Administration Guide는 Tmax를 이용하기 위한 환경설정 파일과 시스템 운영방식에 대해서 설명한다. 모든 프로그램이 설치 후 올바르게 작동하기 위해서는, 계속적으로 시스템 환경 및 구성과 동작을 조율하는 작업이 필요하다. 이러한 작업에는 시스템이 기동 되기 위한 사전 준비작업 뿐만 아니라 기동과 종료, 동작 중의 상태에 대한 관리까지도 포함된다. 시스템 관리에 앞서 관리자는 UNIX system 작동, Client/Server 환경설정, Transaction, Tmax에 관한 기본 지식에 대한 전반적인 이해가 필요하다.

누구를 위한 책인가? 이책은 관리자들의 효율적인 Tmax 사용을 돕기 위한 지침서임과 동시에 클라이언트와 서비

스 프로그램 개발을 위한 간단한 정보를 제공한다.

어떻게 사용하는가? 1. 소개: Tmax의 일반적인 구조와 요구 처리의 기본 개념, 그리고 Tmax 환경설정과 컴파

일 방법에 대해 간단히 소개한다. 2. Tmax 환경설정: 환경파일 설정과 컴파일하는 방법에 대해 설명한다. 이 책에서 소개되는 각각의 환경파일은 데이터베이스, 트랜잭션, 부하조절, 장애대책, 보안기능의 환경설정에 관한 내용을 포함한다. 그리고 Server Process를 위한 service table에 대한 일반적인 설명도 포함한다. 3. 시동과 종료: Tmax 시스템 시동과 종료 방법에 대해 설명한다. 4. Tmax 관리체제: Tmax 관리체제와 그 작동 방법에 대해 설명한다.

관련서 Tmax Getting Started Guide Tmax Reference Manual Tmax FDL Reference Manual


규약

규약 설명

{ } [ ] |

( ) Numeric String Literal

필수 항목 옵션 항목

지정된 여러 개의 값 중 배타적인 선택 구분자 디폴트 값

숫자 abc 형태의 문자열

“abc” 형태의 문자열


차 례

I. 개요 ............................................................................................... 7

1. Tmax 소개 ......................................................................................................................... 7

2. Tmax 내부구조.................................................................................................................. 8

3. Tmax System 구성도...................................................................................................... 11

4. Tmax System Administration ....................................................................................... 12

4.1 정적관리 ................................................................................................................. 13

4.2 동적관리 ................................................................................................................. 14

5. Tmax 시스템의 구성 ....................................................................................................... 15

5.1 디렉토리 구성도 .................................................................................................... 16

5.2 디렉토리별 용도 .................................................................................................... 16

II. 환경설정..................................................................................... 20

1. 환경변수 등록 ................................................................................................................. 20

1.1 Tmax 환경변수 ....................................................................................................... 20

1.2 Tmax 환경변수의 설정 방법 ................................................................................. 23

2. 환경파일 작성 ................................................................................................................. 25

2.1 개요 ........................................................................................................................ 25

Tmax 환경파일이란? ............................................................................................ 25

환경파일의 형식.................................................................................................... 27

Tmax 환경파일 작성 시 주의사항....................................................................... 30

Tmax 환경파일 설정............................................................................................. 32

2.2 기본 환경설정........................................................................................................ 33

DOMAIN 절 ........................................................................................................... 33

NODE 절 ............................................................................................................... 48

SVRGROUP 절 ..................................................................................................... 63

SERVER 절........................................................................................................... 72

SERVICE 절.......................................................................................................... 81

GATEWAY 절 ........................................................................................................ 87

ROUTING 절......................................................................................................... 93

RQ 절 .................................................................................................................... 93

2.3 Database 환경설정 ................................................................................................ 95

SVRGROUP 절 ..................................................................................................... 96

2.4 분산트랜잭션 환경설정 ....................................................................................... 100

DOMAIN 절 ......................................................................................................... 101

NODE 절 ............................................................................................................. 103

SVRGROUP 절 ................................................................................................... 104

2.5 부하조절 환경설정............................................................................................... 106


시스템 성능에 따른 부하조절 ............................................................................ 107

SVRGROUP 절 ................................................................................................... 107

데이터값에 따른 부하조절 ................................................................................. 113

SVRGROUP 절 ................................................................................................... 113

SERVICE 절........................................................................................................ 113

ROUTING 절....................................................................................................... 114

SVRGROUP 절 ................................................................................................... 120

RQ 절 .................................................................................................................. 121

2.6 장애대책 환경설정............................................................................................... 123

서비스 백업을 이용한 장애대책 ........................................................................ 123

서버프로세스의 재시작(restart)에 의한 장애대책 ............................................. 124

2.7 보안 환경설정...................................................................................................... 126

보안 설정............................................................................................................. 127

2.8 멀티 도메인 환경설정 ......................................................................................... 129

3. Tmax 환경파일 컴파일 ................................................................................................. 135

4. 서비스 테이블 생성....................................................................................................... 137

III. 기 동 및 종 료 ...................................................................... 139

1. Tmax 기동 (tmboot)..................................................................................................... 139

2. Tmax 종료 (tmdown)................................................................................................... 144

IV. Tmax 관리 ............................................................................. 147

1. Tmax 어드민 툴 ............................................................................................................ 147

2. 정보 출력....................................................................................................................... 150

2.1 환경정보 ............................................................................................................... 151

2.2 동작 상태 정보 .................................................................................................... 161

2.3 상태 정보 반복 표시 기능 .................................................................................. 168

3. 운용 관리....................................................................................................................... 168

3.1 서버 프로세스 운용 및 재개 .............................................................................. 168

3.2 프로세스 통계 정보 내용을 리셋 ....................................................................... 169

3.3 서버 프로세스 변경............................................................................................. 169

3.4 서비스 동적 추가 ................................................................................................ 171

3.5 서버 동적 추가 .................................................................................................... 172

3.6 서버 그룹 동적 추가 ........................................................................................... 174

3.7 환경설정 값 동적 변경 ....................................................................................... 175

3.8 적체 해소 ............................................................................................................. 175

3.9 클라이언트 연결해제 ........................................................................................... 176

3.10 Logging 관리 ...................................................................................................... 177


1 개요

1.1 Tmax 소개

Tmax 는 클라이언트/서버(Client/Server) 중심의 컴퓨팅 환경 하에서 클라이언트 수의 증가에 의해 발생하는 다종 머신(machine), 운영체제, 데이터베이스 등의 혼재 문제와 데이터 호환성 결여, 클라이언트 증가로 인한 서버 성능 저하 등의 문제점들을 해결하여 프로세스 관리, 트랜잭션 관리, 부하조절, 이기종 자원 관리 등의 기능을 제공하기 위한 트랜잭션 처리 미들웨어이다.

그림 1 Tmax 의 역할

프로세스 관리

서버 프로세스 기동, 업무분산, 프로세스 자동생성 등 수행과정 모니터링

트랜잭션 관리

ACID 특성을 보장하도록 트랜잭션 처리

부하 조절

시스템 성능을 최적화하여 일정한 응답시간 유도


이기종 자원 관리

이기종 간에 발생할 수 있는 여러가지 문제점 해결

1.1.1 Tmax 내부구조

Tmax 에는 내부적으로 7 개의 운용 프로세스(TMM, TMS, CLL, CLH, RQS, GW, CAS)와 4 개의 관리 명령어(tmadmin, racd, tmboot, tmdown)가 존재한다.

그림 2 Tmax 의 구조

TMM (Tmax Manager)

전체적인 Tmax 시스템의 운용 프로세스로써 시스템의 운영 정보를 관리하고, CLL, CLH, TMS, RQS 프로세스 및 업무처리 프로세스들을 관리하는 프로세스이다. Tmax 시스템이 멀티 노드로 구성되었을 경우 타 노드내의 TMM 과 세션을 유지하며 heartbeat 를 체크하여 서버 그룹 단위의 장애 대책을 지원한다. Tmax 시스템 기동 시 TMM 은 가장 먼저 메모리에 로드 되고 시스템 종료 시에는 가장 나중에 종료된다.

모든 공유 정보의 갱신과 각 프로세스의 로그 기록을 담당하며 디스크 풀과 같은 원인으로 인하여 로그 기록이 불가능 할 경우에도 추가적인 로그 기록을 중단하여


문제가 해결될 때 까지의 정상적인 운영이 가능하도록 한다.

CLL (Client Listener)

CLL 은 클라이언트와 Tmax 간의 연결을 관리하는 Listener 프로세스이다. 클라이언트가 처음 Tmax 에 접속할 때에는 CLL 과 연결을 맺어 통신이 이루어지나 서비스 요청이 있을 경우, 내부적으로 CLH 와 연결이 되어 모든 서비스 처리가 이루어진다.

CLH (Client Handler)

클라이언트 매니저라고도 하며 실질적으로 클라이언트와 서버의 업무처리 프로세스 사이를 중계하는 프로세스이다. CLH 는 업무처리 프로세스들과 기타 게이트웨이, RQ 프로세스, TMAX 프로세스와 연결을 맺으며 이들과의 통신을 통해 모든 실제적인 데이터의 흐름을 관리한다. 즉 클라이언트의 서비스 요청을 받아 그에 해당하는 업무를 처리하며 그 결과를 수신하여 다시 클라이언트에게 되돌려준다.

TMS (Transaction Management Server)

데이터베이스 관리 및 분산 트랜잭션 처리를 담당하는 프로세스로써 해당 데이터베이스의 라이브러리를 이용하여 만들어진다. Tmax 시스템의 운영에 필수적인 TMM, CLL, CLH 프로세스들과는 달리 TMS 는 DBMS 와 관련된 작업을 하는 Tmax 시스템에서만 동작하는 프로세스이다.

RQS (Reliable Queue Server)

Tmax 시스템의 디스크 큐를 관리하는 프로세스이다. 일반적인 경우 데이터는 메모리에 저장되어 처리되므로 돌발적인 시스템 장애가 발생할 경우 메모리에 있는 데이터는 지워지게 된다. 중요한 서비스의 수행에 있어 데이터의 신뢰도를 높이기 위해 Tmax 시스템이 제공하는 RQS 는 서비스 요청 전, 후의 데이터를 디스크에 저장하며 만일의 경우에도 시스템이 재부팅 된후 장애 이전에 저장된 데이터를 다시 처리할 수 있도록 해준다. 서비스 수행 속도를 떨어뜨릴수 있으므로 Tmax 시스템의 기동시 기본적으로 동작하지는 않으며 사용자의 필요에 따라 환경파일에 정의된 시스템에서만 동작하게 된다.


GW (Gateway)

멀티 도메인으로 시스템을 구축한 경우 도메인 간의 통신을 담당하는 프로세스로써 Tmax 시스템간에는 물론이고 TCP/IP, SNA/LU0, SNA/LU6, X.25 등 다양한 시스템과의 연동이 가능하다. 실제 수행되는 프로세스명은 사용자가 환경파일에 정의하기에 따라 다르며 게이트웨이 종류에 따라 특별한 설정을 더 필요로 하는 경우도 있다. 이 프로세스 역시 Tmax 시스템에 항상 기본적으로 동작하는 프로세스가 아니고 환경파일에 GATEWAY 가 정의된 시스템에서만 동작한다.

CAS (Client Authentication Server)

보안이 필요한 Tmax 시스템을 운영하는 경우에 사용되는 프로세스로 1 단계 및 2 단계 보안을 담당하며 사용자의 신원을 확인하는 역할을 한다.

tmadmin (Tmax Administration)

tmadmin 은 Tmax 에서 제공하는 어드민 툴로써 운영중인 Tmax 시스템의 환경을 확인하거나 동적으로 변경하는 기능을 제공하며 현재 서버 프로세스의 동작 상태와 통계정보, 서비스나 큐의 상태 정보를 확인할 수 있다.

racd (Remote Access Control Daemon)

여러 개의 노드를 하나의 도메인으로 Tmax 시스템을 구축하였을 경우 한 노드에서 다른 시스템을 관리할 수 있도록 각각의 노드에 미리 기동시키는 데몬 프로세스이다. racd 를 사용하여 도메인 내 한 노드에서 tmadmin 을 통하여 전체 노드를 모니터링할 수 있으며 일일히 파일을 복사하지 않아도 하나의 환경파일을 모든 노드에 적용할 수 있다.

tmboot (Tmax System Boot)

tmboot 는 환경파일에 정의된 내용에 따라 Tmax 시스템을 초기화하여 기동한다. 가장 일반적으로 Tmax 시스템 프로세스(TMM, CLL, CLH)들이 먼저 기동되고 이후 부가적인 환경을 위한 RQ, TMS, GW 프로세스가 기동되며 마지막으로 개발된 서버 프로세스들이 기동된다. tmboot 는


다양한 옵션을 제공하여 다양한 방법으로 Tmax 시스템을 기동 할 수 있다.

tmdown (Tmax System Down)

tmdown 은 환경파일의 내용을 토대로 tmboot 로 기동 된 시스템을 종료 시키는 명령어이다. 종료순서는 tmboot 와 반대로 먼저 모든 응용 서버 프로세스를 종료 시킨 후에 Tmax 시스템 관리 프로세스들을 종료한다.

1.1.2 Tmax System 구성도

그림 3 Tmax System 구성도


도메인(domain)은 하나의 동일한 환경파일을 공유하는 Tmax system 의 구성단위이다. 도메인은 하나 이상의 노드(machine)들로 구성될 수 있으며, 이들은 peer-to-peer 방식으로 연결되어 일정한 시간 간격으로 다른 노드들과 통신하며 환경파일에 구성된 정보를 공유한다. 따라서 모든 노드가 도메인 전체의 상태와 도메인의 모든 노드에 대한 정보를 가지고 있기 때문에 클라이언트는 도메인내 어느 노드에 연결하더라도 도메인에서 제공하는 모든 서비스를 제공받을 수 있다.

클라이언트는 도메인을 구성하는 특정 노드와 연결될 수 있으며 연결된 노드는 해당 클라이언트의 서비스를 담당한다. 클라이언트가 요청한 서비스가 현재 연결된 노드에서 제공하는 것이면, 연결된 노드가 이를 처리하고, 다른 노드에서 제공하는 서비스이면 클라이언트와 연결된 노드가 서비스를 제공하는 노드에 이를 요청하여 처리 결과를 클라이언트에게 되돌려주는 역할을 담당한다.

다른 노드에서 제공되는 서비스를 클라이언트가 요청하는 경우에는 다음과 같은 흐름으로 처리된다.

클라이언트와 처음에 연결된 노드(1)가 서비스를 제공하는 노드와 통신하여 그 서비스 처리를 요청하고(2) 그 응답을 받아(3) 클라이언트에 돌려준다(4).

그림 4 타 노드의 서비스 요청 시 클라이언트와 Tmax 시스템과의 연관 관계

1.1.3 Tmax System Administration

Tmax 시스템 관리는 크게 정적관리와 동적관리로 나누어 볼 수 있다.


정적관리란, 시스템이 기동 되기 전에 이루어질 수 있는 관리, 또는 동작중인 시스템에 영향을 미치지 않는 관리 행위를 말하며 시스템 환경설정(configuration) 작업을 의미한다.

동적관리란, 시스템이 동작하고 있는 상황에서 시스템의 상태나 성능에 영향을 줄 수 있는 관리 행위를 말하며, Tmax 시스템 기동/종료(tmboot/tmdown), 시스템 동작 관리(Tmax administration) 및 시스템 환경변수 변경 등을 의미한다.

정적관리 동적관리

시스템 환경설정

시스템 기동/종료

시스템 동작 관리

시스템 환경 변경

1.1.3.1 정적관리

시스템 정적 관리는 환경설정을 통해서 이루어진다.

Tmax 시스템 환경설정을 위해서는 다음과 같은 선행 작업이 필요하다.

Tmax 환경파일 설정

Tmax 시스템 환경설정을 위해 환경파일 작성이 필요하다. 이 환경파일은 하나의 독립적인 시스템을 구성하는 도메인(Domain), 도메인(Domain)간의 연결이나 레거시 시스템과 통신 하는 게이트웨이(Gateway), 시스템을 구성하는 노드(Node), 각 노드의 서비스(Service), 서비스를 제공하는 서버(Server) 프로세스, 연관된 서버들의 모임인 서버그룹(Server Group) 등에 대한 전반적인 시스템 환경정보를 담고있다. 환경파일작성은 Tmax 관리자가 해야 할 가장 핵심적인 일로써, 이에 대한 자세한 설명은 ‘환경설정 ’에서 다루어질 것이다.

Tmax 환경파일 컴파일

Tmax 환경파일을 작성한 후에는 컴파일 작업을 통하여 올바른 환경파일이 만들어졌는지에 대한 검증이 이루어져야 한다. 올바른 환경파일이 컴파일 되면 이진(binary) 형태로 변환된 Tmax 환경파일이 만들어진다.


이렇게 만들어진 이진 Tmax 환경파일은 Tmax 시스템이 기동과 종료시 참조된다.

서비스 테이블 생성

Tmax 시스템에게 서비스의 종류와 위치를 알려주기 위해 위에서 작성한 환경파일로 서비스 테이블을 생성하는 과정이 필요하다. 서비스 테이블은 환경파일의 내용을 근거로 각 서버 프로세스별로 테이블 형태로 만들어지며 개발자들이 만드는 서버용 소스 프로그램과 함께 컴파일 되어 서버측 실행 프로그램을 만드는데 사용된다. 서비스 테이블을 링크하지 않은 실행 프로그램은 Tmax 시스템이 인식하지 못하므로 실행될 수 없다.

1.1.3.2 동적관리

시동과 종료

환경설정 작업이 완료되면 관리자는 Tmax 를 기동 시킬 수 있다. 시스템 기동 시에는 Tmax 의 기능 프로세스들, 즉 TMM,CLL,CLH(데이터베이스 관련 시 TMS 프로세스, RQ 관련 시 RQ 프로세스 포함) 뿐만 아니라 실질적인 업무처리 서버 프로세스들도 포함된다. 다시 말해, 업무처리 서버 프로세스가 별도로 동작하는 것이 아니라, 기능 프로세스와 함께 기동 및 종료되어 Tmax 시스템에 의해 관리가 이루어진다.

시스템 동작관리

Tmax 시스템이 동작 중일 때, 관리자는 각 구성 부분들의 상태를 확인하고 필요 시 적절한 조치를 취할 수 있다. Tmax 시스템에서는 tmadmin 이라는 console 상의 대화형 모니터 프로그램을 사용하여 동작 상태 변경 등 동적인 작업을 가능하게 한다.

각종 정보 출력 : tmadmin 은 현재 환경설정에 대한 정보를 확인 할 수 있는 명령어들을 제공한다. Tmax 관리자는 tmadmin 에서 명령어와 옵션들을 통해 클라이언트(이름, 위치), 서버(위치, 그룹, 프로세스 상태, 수행횟수), 서비스(위치, 상태, 처리시간, 수행횟수, 적체된 데이터량), 네트웍(connected node, partitioned node)


등과 이 외에도 수행되고 있는 트랜잭션, 응용프로그램 파라미터 등에 대한 정보를 확인할 수 있다.

동적 환경설정 변경 : 관리자는 시스템 환경이나 환경설정을 통해 시스템의 설정을 수정할 수 있다. 수정작업의 종류는 응답시간 초과(timeout), 처리 우선 순위(priority), 부하조절(load) 값 조정 혹은 동작 불능의 서버 프로세스 재시작(restart) , 서버 프로세스 종료, 종료된 프로세스 다시 기동 등이 있다. 또한 운영중인 서버 프로세스에 동적으로 새로운 서비스를 추가하는 기능을 제공한다. <주의> 동적으로 변경된 Tmax 환경변수는 동작 중일 때는 변경된 대로 적용되지만, 시스템을 종료(tmdown) 하고 난 후 다시 기동(tmboot)했을 때에는 원래의 Tmax 환경파일 설정 사항대로 동작함에 유의해야 한다

1.1.4 Tmax 시스템의 구성

일반적으로 Tmax 시스템이 설치될 파일 시스템의 디렉토리 구성은 아래의 그림(1-5)과 같다. 여기서 정의된 디렉토리는 시스템 환경변수나 Tmax 시스템 환경설정 파일의 많은 항목에서 참조된다.


1.1.4.1 디렉토리 구성도

그림 5 Tmax 시스템 디렉토리 구성도

1.1.4.2 디렉토리별 용도

디렉토리 용 도 시스템변수 환경항목

Tmax HOME

Tmax 시스템의 홈 디렉토리 TMAXDIR TMAXDIR

bin Tmax 시스템의 명령어/유틸리티를

포함하는 디렉토리


appbin 서버 프로세스가 위치하는 디렉토리 APPDIR

path 프로세스간 내부 통신을 위한 네임드

파이프(named pipe)가 생성될 디렉토리 PATHDIR

config 환경설정 파일이 저장될 디렉토리

license License 파일이 저장될 디렉토리

svct 서비스 테이블 파일이 저장될 디렉토리

lib Tmax Library 파일이 저장될 디렉토리

usrinc Tmax Header 파일이 저장될 디렉토리

slog 시스템 Log 파일이 저장될 디렉토리 SLOGDIR

ulog 사용자 Log 파일이 저장될 디렉토리 ULOGDIR

tlog 트랜잭션 정보가 저장될 디렉토리 TLOGDIR

bkappbin

(optional)

현재 사용중인 서버 프로세스를 새로운

프로세스로 변경하고자 할 때 새로운

프로세스가 설치될 디렉토리

TMAX_BKAPPDIR

sdl

(optional)

구조체에 관련된 파일이 저장될

디렉토리 SDLFILE

fdl

(optional) 필드키 관련 파일이 저장될 디렉토리 FDLFILE

sample client 와 server 샘플 프로그램들이

저장될 디렉토리

client client 용 샘플 프로그램들이 저장될

디렉토리


server server 용 샘플 프로그램들이 저장될

디렉토리

webt webt sample 프로그램들이 저장될

디렉토리

표 1 Tmax 디렉토리별 용도



2 환경설정

2.1 환경변수 등록

Tmax 시스템에서 사용하는 환경변수는 크게 두 가지로 나누어지는데, 첫번째는 Tmax 시스템에서 사용할 환경변수이고, 두 번째는 서버 프로세스에서 사용될 환경변수이다. 환경변수는 사용하는 시스템의 쉘 종류에 맞게 환경변수를 등록해야 한다. Tmax 시스템에서 사용하는 환경변수의 대부분은 Tmax 시스템에 접근하기 위한 변수로써 여기서 등록하는 환경변수는 다음 장에서 설명될 환경파일의 항목과 동일한 값을 입력해야 한다. 또한 이 환경변수는 해당 시스템에서 수행되는 모든 서버 프로세스에 동일하게 적용된다.

Tmax 시스템이 설치된 서버는 해당 쉘의 프로파일에 반드시 등록되어야 하나 클라이언트는 두 가지 방식으로 등록하여 사용할 수 있다. 첫번째 방법은 서버와 동일하게 프로파일에 등록하여 사용하는 방식이고, 두 번째 방법은 특정파일에 일정한 포맷으로 등록하여 사용할 수 있다.

Tmax 시스템과 함께 기동 되는 서버 프로세스에서 사용될 변수는 특정파일에 지정된 포맷으로 등록하고 환경파일의 ENVFILE 항목에 해당 파일을 등록하여 사용할 수 있다

2.1.1 Tmax 환경변수

Tmax 시스템이 설치된 서버와 클라이언트는 모두 동일한 환경변수를 사용하나 Tmax 시스템 에 설치된 노드의 모든 환경변수를 클라이언트에 등록할 필요는 없다.

서버에 등록할 각각의 환경변수는 다음과 같다.

환경변수 내용 환경파일 항목

TMAXDIR Tmax 시스템 홈 디렉토리 TMAXDIR


TMAX_BKAPPDIR 기존의 서버 프로세스 변경 시 새 프로세스가 위치할 디렉토리

-

TMAX_HOST_ADDR Tmax 시스템이 수행될 서버의 IP Address.

-

TMAX_HOST_PORT Tmax 시스템에 접속할 포트번호 TPORTNO

TMAX_BACKUP_ADDR Tmax 백업 서버의 IP Address -

TMAX_BACKUP_PORT Tmax 백업 서버의 Port 번호 -

TMAX_RAC_PORT

분산노드로 구성된 시스템에서 중앙

집중으로 관리하기 위한 포트번호

(racd 에 의해 사용)

RACPORT

TMAX_ERR_MSG 서버 콘솔창에 에러메시지를 표시할 것인지 결정

-

SDLFILE 구조체 정보가 저장된 파일을 지정

-

FDLFILE 필드키 정보가 저장된 파일을 지정

-

TMAX_PATHDIR tmdown 시에 참조할 환경파일의 경로

PATHDIR


TMAXHOME

install directory 와 work directory 를 분리하여 사용하고자 할 때 TMAXHOME 에 install directory(bin, lib, usrinc, tuxinc, topinc, cblinc)를 TMAXDIR 에 work directory(config, path, license, log, svct)를 지정

표 2 Tmax Server 환경 변수

클라이언트에 등록할 각각의 환경변수는 다음과 같다.

환경변수 내용 비고

TMAX_HOST_ADDR Tmax 서비스 서버의 IP Address -

TMAX_HOST_PORT Tmax 서비스 서버의 Port 번호 -

TMAX_CONNECT_TIMEOUT

Tmax 시스템 연결 시 Timeout 시간. 마이크로 초 단위 지정 가능(x.xxx 초)

-

SDLFILE

구조체 정보가 저장된 파일을 지정할

변수

-

FDLFILE

필드키 정보가 저장된 파일을 지정할

변수

-

ULOG(또는 ULOGPFX)

클라이언트측에 로그를 남기고자 하는 경로명을 설정한다. 이를 설정하지 않으면 Tmax 환경파일에 설정된 ULOGDIR 경로에 기록이 남는다.

-

표 3 Tmax Client 환경 변수


2.1.2 Tmax 환경변수의 설정 방법

서버에서 등록할 환경변수는 사용하는 쉘에 맞게 등록해야 한다. korn 쉘 및 bash 쉘의 경우는 .profile 및 .bash_profile 에, c 쉘의 경우 .cshrc 에 설정한다.

<주의> 환경 변수를 설정할 때 환경 변수명과 ‘=’사이에는 공백이 없어야 한다.

<<서버 측 Shell 환경파일(.profile / .bash_profile)>> export TMAXDIR = /home/tmax

export TMAX_BKAPPDIR = /home/tmax/bkappbin

export TMAX_HOST_ADDR = 192.168.0.1

export TMAX_HOST_PORT = 8888

export TMAX_RAC_PORT = 3333

export SDLFILE = /home/tmax/sample/sdl/tmax.sdl

export FDLFILE = /home/tmax/sample/sdl/tmax.fdl

export TMAX_PATHDIR = /home/tmax/path_new

<<서버 측 Shell 환경파일(.cshrc)>> setenv TMAXDIR /home/tmax

setenv TMAX_BKAPPDIR /home/tmax/bkappbin

setenv TMAX_HOST_ADDR 192.168.0.1

setenv TMAX_HOST_PORT 8888

setenv TMAX_RAC_PORT 3333

setenv SDLFILE /home/tmax/sample/sdl/tmax.sdl

setenv FDLFILE /home/tmax/sample/sdl/tmax.fdl

setenv TMAX_PATHDIR = /home/tmax/path_new

install.sh 를 이용해서 Tmax 를 설치하며 기본 환경변수들은 자동적으로 쉘 환경파일 끝에 등록된다.(예: .profile)

클라이언트의 환경변수 등록 시, 그 과정은 OS 에 따라 다르다. OS 가 Unix 이면 위 서버와 동일하게 프로파일에 등록한다. OS 가 DOS 나 Windows98, Windows NT/2000 일 경우 아래와 같이 autoexec.bat 파일에 등록하거나, 제어판의 시스템 등록 정보에서 환경변수를 등록한다.

<주의> 환경 변수를 설정할 때 환경 변수명과 ‘=’사이에는 공백이 없어야 한다.


<<클라이언트 측 환경파일(autoexe.bat)>> set TMAX_HOST_ADDR = 192.168.0.1

set TMAX_HOST_PORT = 8888

set TMAX_CONNECT_TIMEOUT = 3

set SDLFILE = /home/tmax/sample/sdl/tmax.sdl

set FDLFILE = /home/tmax/sample/sdl/tmax.fdl

클라이언트측의 환경변수는 아래와 같이 텍스트 파일로 등록했다가 필요할 때 해당 파일을 참조하여 사용할 수 있다. (Tmax Reference Manual 의 tmaxreadenv API 참조)

<<클라이언트 환경 텍스트 파일(tmax.env)>> [TEST]

TMAX_HOST_ADDR = 192.168.0.1

TMAX_HOST_PORT = 8888

TMAX_CONNECT_TIMEOUT = 3

SDLFILE = /home/tmax/sample/sdl/tmax.sdl

FDLFILE = /home/tmax/sample/sdl/tmax.fdl

ULOG = /home/tmax/testlog

[REAL]

TMAX_HOST_ADDR = 192.168.0.2

TMAX_HOST_PORT = 1234

TMAX_CONNECT_TIMEOUT = 3

SDLFILE = /home/tmax/sample/sdl/tmax.sdl

FDLFILE = /home/tmax/sample/sdl/tmax.fdl

export ULOG = /home/tmax/reallog

Tmax 시스템에서 서버에서 사용할 환경 변수들은 텍스트 파일로 만들어서 Tmax 환경파일 NODE 절 및 SVRGROUP 절의 ENVFILE 항목에 파일명을 등록하면 서버 프로세스에서 참조할 수 있다.

<<서버 환경 텍스트 파일>> LOGDIR = /tmp

USER_VARIABLE = test1

USER _VARIABLE = test2





2.2 환경파일 작성

2.2.1 개요

2.2.1.1 Tmax 환경파일이란?

그러면, Tmax 환경파일에는 어떤 내용들이 들어갈 것인가? Tmax 환경파일에는 먼저 하나의 Tmax 도메인(DOMAIN)에 대한 환경을 설정한다. 도메인이란, 여러 노드(machine)들로 이루어 질 수 있는 하나의 독립적인 Tmax 시스템을 말한다. 도메인 정보에는 시스템에 접속할 수 있는 최대 사용자 수라든가 트랜잭션 처리에 대한 시간 제한, 클라이언트의 서비스 처리시간 등의 내용이 포함된다.

다음으로 도메인을 구성하는 각 노드에 따라 개별적으로 환경을 설정할 수 있다. 노드에 접속할 수 있는 최대 사용자 수, 노드에 존재하는 Tmax 프로그램의 위치, 업무처리 서버프로그램의 위치 등의 내용을 포함한다.

또한 서버그룹에 대한 환경설정이 가능하다. 서버그룹은 서비스를 제공하는 업무처리 서버프로세스들의 모임으로, 여러 개의 서버프로세스들을 하나의 서버그룹으로 묶어 관리할 수 있도록 한다. 서버그룹에는 데이터베이스 접근 정보, 부하조절 및 장애대책 등의 환경을 설정할 수 있다.

실질적으로 서비스를 제공하는 업무처리인 서버 프로세스(SERVER)(명령어 라인 옵션이나 서버 개수)와 서비스(우선 순위와 처리 제한 시간), 라우팅(데이터의 형식(type)과 범위에 따라 서버그룹별로 분산 처리)에 대한 환경설정도 필요하다.

시스템 장애나 오류로 인하여 서비스를 더 이상 처리할 수 없을 경우를 대비해서 RQ 에 대한 환경설정을 할 수 있으며, 도메인간의 서비스를 처리할 수 있는 GATEWAY 환경도 설정할 수 있다.


그림 6 Tmax 환경파일을 구성하는 절들

환경파일은 총 8 개의 절로 구성된다.

DOMAIN, NODE, SVRGROUP, SERVER, SERVICE, GATEWAY, ROUTING, RQ.

이들 중 GATEWAY 절과 ROUTING 절, RQ 절을 제외한 나머지 절은 반드시 정의되어야 하며, 서로 트리(tree) 형태의 상관 관계를 가진다. 즉, Tmax 시스템 전체 환경에 대한 도메인이 존재하고, 도메인에는 하나 이상의 노드가, 각 노드에는 하나 이상의 서버그룹이, 서버그룹 안에는 하나 이상의 업무처리 서버프로세스들이, 그리고 각 업무처리 서버 프로세스에는 하나 이상의 서비스들이 포함되는 관계를 이루는 것이다.

그림 ax 환경파일을 구성하는 각 절들간 상호 연관 관계를 트리 형태로 나타낸 것이다.


그림 7 환경파일 구성요소 간의 상호 연관관계

2.2.1.2 환경파일의 형식

Tmax 환경파일은 DOMAIN 절, NODE 절, SVRGROUP 절, SERVER 절, SERVICE 절, GATEWAY 절, ROUTING 절, RQ 절로 구성되고, 이 중에서 GATEWAY 절, ROUTING 절, RQ 절을 제외한 나머지 5 개의 절은 반드시 정의되어야 한다. 각 절의 정의 형식은 다음과 같다.

*절

이름 항목 1 = .… , 항목 2 = .… , 항목 3 = ....

다음은 Tmax 환경파일의 간단한 예이다.

<<Tmax 환경 파일>> *DOMAIN

res1 SHMKEY = 77990, MINCLH = 1, MAXCLH = 3,

MAXUSER = 100, TPORTNO = 8888, BLOCKTIME = 100

*NODE


tmax1 TMAXDIR = “/home/tmax”,

APPDIR = “/home/tmax/appbin”,

PATHDIR = “/home/tmax/path”,

SLOGDIR = “/home/tmax/log/slog”,

TLOGDIR = “/home/tmax/log/tlog”,

ULOGDIR = “/home/tmax/log/ulog”

*SVRGROUP

svg1 NODENAME = tmax1, DBNAME = ORACLE,

OPENINFO = “Oracle_XA+Acc = P/tmax/tmax+SesTm = 60”

svg2 NODENAME = tmax1

*SERVER

svr1 SVGNAME = svg1, CLOPT =“-A -- -f aa -x bb”

svr2 SVGNAME = svg2

*SERVICE

SVC1 SVRNAME = svr1

SVC2 SVRNAME = svr2


절의 이름은 별표(*)로 시작되며 대문자를 사용한다.

절의 정의 순서는 고정되어 있지 않다. 따라서 어느 절이 먼저 정의되어도 관계없다.

하나의 절이 여러 번으로 나누어 한번 이상 정의될 수 있다. 예를 들어, 노드 별로 해당 서버그룹, 업무처리 서버 프로세스, 서비스 등을 분리하여 정의 할 수 있다. 단, 동일한 내용이 반복 정의 되어서는 안 된다.

<<Tmax 환경 파일의 형식>> * DOMAIN

tmaxsys

* NODE

nodel

........

* SVRGROUP

svg1

........

* SERVER

........

* SERVICE

........

* NODE

node2

........

* SVRGROUP

svg2

........

* SERVER

........

* SERVER

........

* SERVICE

........


각 절의 항목들은 ‘항목 이름 = 값’의 형태로 정의된다. 각 항목은 다음의 4 가지 형태 중 하나의 값으로 정의될 수 있으며, 항목 이름은 값으로 사용될 수 없다.

항목값

numeric

string

literal

Y / N

-

-

-

-

형태

숫자

abc 형태의 문자열

“abc” 형태의

문자열

Yes 또는 NO 형태

각 절의 항목들은 다음과 같은 형식으로 정의한다.

항목 = 형태 (default 값)

범위 또는 크기

내용

형태 - numeric, string, literal, Y/N

numeric 형태에 대해서는 범위를 정의하고, string 과 literal 형태에 대해서는 문자열 크기를 정의한다.

디폴트(default) 값이 있는 경우에는 괄호 안에 정의한다.

2.2.1.3 Tmax 환경파일 작성 시 주의사항

환경파일의 각 절과 항목은 다음과 같은 형식에 따라 작성되어야 한다.

절의 시작은 별표(*)로 시작하고 반드시 대문자 이어야 한다.

절명이나 절의 하위 개체명은 반드시 첫번째 칸에서 시작되어야 한다

절명이나 절의 하위 개체명 이외의 항목은 첫번째 칸에서 시작할 수 없다.

절의 각 항목간에는 콤마(,)로 구분되어야 한다. 콤마(,)가 없으면 해당절의 정의가 끝난 것으로 간주한다.


항목과 항목사이의 공백은 의미가 없다.

항목을 정의하지 않으면 디폴트 값으로 설정된다.


2.2.1.4 Tmax 환경파일 설정

Tmax 환경파일 작성은 Tmax 시스템 관리자가 해야 하는 가장 중요한 일이다. Tmax 시스템은 환경파일을 기초로 기동하고 종료된다. 그러므로 환경파일이 존재하지 않거나 올바르게 만들어지지 않는다면, Tmax 시스템은 동작할 수 없다.

Tmax 환경파일은 크게 일곱 부분으로 나누어진다.

기본 환경설정

Tmax 시스템을 구성하기 위해 기본적으로 필요한 환경설정 내용을 설명한다. Tmax 환경파일에 필수적으로 정의되어야 하는 DOMAIN 절, NODE 절, SVRGROUP 절, SERVER 절, SERVICE 절과 도메인간에 서비스를 처리할 수 있는 GATEWAY 절, 라우팅 환경설정을 위해 추가할 수 있는 ROUTING 절, 서비스의 신뢰성 보장을 위한 RQ 절 등 Tmax 환경파일의 전반적인 내용이 다루어진다. 데이터베이스, 트랜잭션, 부하조절, 장애대책, 보안관련 환경설정은 이 기본 환경설정을 바탕으로 이루어진다.

데이터베이스 환경설정

데이터베이스 정보를 등록하여 데이터베이스를 관리하기 위해 필요한 데이터베이스 관련 환경설정이 다루어 진다.

분산트랜잭션 환경설정

Tmax 시스템의 분산트랜잭션 처리(Distributed Transaction Processing) 기능을 제공받고자 할 때 필요한 트랜잭션 환경설정이 다루어 진다.

부하조절 환경설정

노드간의 부하조절을 위해서 필요한 환경설정을 설명한다. 선택적으로 정의할 수 있는 ROUTING 절에 대한 자세한 설명이 다루어진다.

신뢰성 큐 환경설정

장애로 인하여 시스템이 비 정상적으로 종료되어도 종료 전에 요구한 서비스는 시스템이 정상 booting 한 후에 계속


처리 가능하도록 환경을 설정하는 것으로 RQ 절에 대한 자세한 설명이 다루어진다.

장애대책 환경설정

노드 장애가 발생할 경우, 장애 노드의 서비스들이 다른 노드에서 제공 되도록 하기 위한 환경설정이 다루어진다.

보안 환경설정

Tmax 시스템의 보안 기능을 위한 환경설정을 설명한다.

멀티 도메인 환경설정

Tmax 시스템의 멀티 도메인 환경에서 도메인간의 라우팅 설정을 설명한다.

2.2.2 기본 환경설정

환경파일에 필수적으로 정의되는 5 개의 절, 즉 DOMAIN 절, NODE 절, SVRGROUP 절, SERVER 절, SERVICE 절과 멀티 도메인을 처리하기 위한 GATEWAY 절, 그 외에 ROUTING 절, RQ 절 등에 대해 알아보기로 한다.

2.2.2.1 DOMAIN 절

하나의 독립적인 Tmax 시스템 전체에 대한 환경을 설정한다. 멀티 도메인으로 시스템을 정의하였을 경우에는 GATEWAY 절을 이용하여 도메인간의 서비스를 처리할 수 있다. 이 절에는 기본적으로 다음과 같은 내용들을 설정할 수 있다.

공유 메모리(shared memory)의 key 값은 얼마로 설정할 것인가 ?

Tmax 프로세스(CLH)를 몇 개나 실행할 것인가 ?

최대 몇 명의 클라이언트가 접속할 수 있는가 ?

포트 번호는 어떻게 정할 것인가 ?

클라이언트가 서비스를 요청한 후, 최대 얼마동안 기다리도록 할 것인가 ?

이 절에 정의된 내용은 하나의 Tmax 시스템을 구성하는 모든 노드에 공통적으로 적용된다. 그러나 여기에 정의되어 있더라도 나머지 4 개


절에서 재정의 할 수 있는 항목들도 존재한다. 기본 정의사항과 재정의 내용이 서로 충돌할 경우 후자가 우선한다.

DOMAIN 절의 항목들은 필수 항목과 선택 항목으로 나누어진다.


DOMAIN 절의 기본 환경설정 형식은 다음과 같이 정의한다.

[DEFAULT : ]

도메인이름 SHMKEY=shared-memory-segment-key

[,MAXUSER=1 ~ ]

[,MINCLH=1 ~ 10]

[,MAXCLH=1 ~ 10]

[,TPORTNO=port-number]

[,RACPORT=port-number]

[,BLOCKTIME=timeout-value]

[,CPC=channel-number]

[,MAXFUNC=max-function-number]

[,LOGOUTSVC=“logout-service-name”]

[,CLICHKINT=interval-time-value]

[,IDLETIME=idle-time]

[,MAXSACALL=number]

[,MAXCACALL=number]

[,TXTIME=transaction-timeout-value]

[,NLIVEINQ=alive-check-interval]

[,NCLHCHKTIME= interval-time-value]

[,MAXCONV_NODE=number]

[,MAXCONV_SERVER=number]

[,SECURITY=security_policy]

[,OWNER=name]

[,IPCPERM=mask]

[,DOMAINID=number]

[,CMTRET=literal]

[,MAXNODE=number]

[,MAXSVG=number]

[,MAXSPR=number]

[,MAXSVR=number]

[,MAXSVC=number]

[,MAXCPC=number]

[,MAXTMS=number]

[,MAXROUT=number]

[,MAXROUTSVG=number]

[,MAXRQ=number]

[,MAXGW=number]

[,MAXCOUSIN=number]

[,MAXCOUSINSVG=number]

[,MAXBACKUP=number]


[,MAXBACKUPSVG=number]

[,MAXTOTALSVG=number]

[,MAXPROD=number]

필수항목

도메인 이름 = string

15 자 이내의 string 형식으로 정의한다. DOMAIN 절은 Tmax 시스템의 전반적인 환경에 대한 정의이다.

SHMKEY = numeric

범위 : 32768 ~ 262143

공유 메모리 세그먼트(shared memory segment)를 가리키는 값이다. Tmax 에는 전체적인 Tmax 관리자로써 다른 프로세스들을 관장하는 TMM(Tmax Manager), 데이터베이스 및 리소스를 관리하는 TMS(Transaction Management Server), 클라이언트의 연결을 관리하는 CLL(Client Listener), 클라이언트와 서버프로세스 사이에서 요청 및 응답을 처리하는 CLH(Client Handler)등 기능별로 크게 4 개의 프로세스가 존재한다. SHMKEY 에서 이러한 4 개의 프로세스들이 공유해야 할 정보들을 관리하기 위한 공유메모리 key 값을 정의한다. Tmax 시스템은 내부적으로 4 개의 공유 메모리가 사용되어 정의된 값부터 차례대로 4 개의 키 값(SHMKEY, SHMKEY+1, SHMKEY+2, SHMKEY+3) 을 사용한다.

주의점 : 공유메모리 key 값을 정의하기 전에 이 key 값들이 다른 업무에서 사용되는지 반드시 확인하여야 한다. 충돌을 막기 위해서 사용되지 않은 값을 정의해야 한다.

MAXUSER = numeric

범위 = 1 ~ MAX_INT

도메인에 동시에 접속할 수 있는 최대 클라이언트 수를 정의한다. 현재 MAXUSER 로 설정해 준 값 + 1 만큼의 클라이언트 접속을 허용하고 있다.

선택항목


DEFAULT:

Domain 절 뿐 아니라 Tmax 환경 파일의 모든 절에서 사용할 수 있는 항목으로 자세한 내용은 NODE 절을 참조한다.

MINCLH = numeric (1)

범위: 1 ~ 10

Tmax 시스템이 기동 될 때 작동하는 CLH 의 최소 개수를 정의한다. CLH 는 클라이언트 의 요구를 처리하는 프로세스이며 기본값은 1 이다.

CLH 는 클라이언트의 서비스 요청을 받아 업무처리 서버 프로세스에게 서비스를 요청하고 그 결과를 받아 다시 클라이언트에게 돌려주는 기능을 하는 Tmax 의 핵심 프로세스이다. CLH 는 모든 클라이언트와 연결이 이루어지는 프로세스로써, 시스템에 따라 하나의 CLH 에 연결될 수 있는 클라이언트의 수가 제한되어 있다. 그러므로 많은 클라이언트가 연결을 시도하는 대형 도메인의 경우, 하나 이상의 CLH 프로세스를 동작시켜야 한다. 그러기 위해서 적절한 MINCLH 값을 정의하여야 한다.

그림 8 MINCLH = 2

MAXCLH = numeric (10)

범위 : 1 ~ 10


CLH 의 최대 개수를 정의한다. 처음 Tmax 시스템이 기동 될 때, CLH 는 MINCLH 개수 만큼 기동 된다. MINCLH 에서 정의한 CLH 프로세스만으로는 감당할 수 없을 만큼 클라이언트의 요구가 증가하는 경우, CLH 프로세스를 추가적으로 기동시켜 원활하게 업무를 처리하도록 할 수 있다. CLH 프로세스의 개수는 이미 동작하고 있는 CLH 프로세스를 합쳐서 MAXCLH 개수를 초과하여 생성될 수 없다. 현재 클라이언트 요구 증가에 따라 CLH 프로세스의 개수가 늘어나는 기능은 제공되지 않고 있다.

TPORTNO = numeric (8888)

클라이언트가 서버에 연결할 때 사용하는 Tmax 시스템 포트번호를 정의한다. 정의된 값(TPORTNO)과 바로 다음 값(TPORTNO+1)이 포트번호로 사용된다. 처음 TPORTNO 값은 클라이언트가 서버에 연결할 때 사용하고, 다음 값(TPORTNO+1)은 노드간 통신을 위해 사용된다. 클라이언트/서버 환경 하에서 클라이언트는 서버의 주소(address)와 Tmax 시스템의 포트(port) 번호를 알아야 한다. Tmax 클라이언트 환경 하에서는 주소 (TMAX_HOST_ADDR)와 포트번호(TMAX_HOST_PORT)가 설정되어야 한다. 이 때, 설정되어야 할 포트번호가 TPORTNO 이다. 하지만 클라이언트와 서버가 같은 노드에 존재하는 경우에는 TCP/IP 소켓을 사용하지 않고 도메인 소켓을 사용하여 보다 효과적으로 처리를 할 수 있게 된다. 서버는 두 가지 형태의 클라이언트를 모두 수신할 수 있도록 설정되어 있는데 TCPIP 소켓을 위해서는 TPORTNO 로 listen 하고 있으며 도메인 소켓을 위해서는 PATHDIR 의 cllrcad 라는 스트림 파이프를 listen 하고 있다. 따라서 클라이언트와 서버가 같은 노드에 존재하는 경우에는 환경변수의 TMAX_HOST_PORT 항목에 TPORTNO 에서 사용한 port 번호 대신에 PATHDIR 을 지정하면 된다. 예 : .profile 또는 tmax.env 의 TMAX_HOST_PORT=/home/tmax/path TPORTNO+1 은 노드 간의 통신을 위한 또 하나의 포트번호로 사용된다. Tmax 시스템의 노드간 구성 방식은 peer-to-peer 형태로써 TPORTNO+1 값을 사용하여 환경파일에 등록된 순서대로 다음 노드를


체크한다. 시스템 영역에서는 1024 미만의 포트번호가 쓰이고 있으므로 관리자는 이 범위를 피해야 한다.

주의 : 이와 같이 클라이언트와 Tmax 시스템 또는 노드간 통신 시 TPORTNO 와 TPORTNO+1 값에 정의된 포트번호가 사용되기 때문에, 이 값들이 다른 곳에서 사용되고 있는지의 여부를 반드시 확인해야 한다. 또한, 멀티노드 설정 시 CLH 가 추가적인 포트를 사용하므로 CLH 개수 만큼의 포트 값이 유효한지도 확인해야 한다.

RACPORT = numeric (3333)

한 도메인 내에 여러 노드가 구성되어 있는 경우, 여러 노드를 중앙에서 관리하기 위해서 각각의 노드간에 통신을 위한 포트번호를 정의한다. 관리 프로세스 중의 하나인 racd 에서 사용하는 포트번호이다. 해당 포트번호는 환경변수인 TMAX_RAC_PORT 번호에 정의된 값과 동일해야 한다. 기본값으로 3333 번 포트가 사용된다. 시스템 영역에서는 1024 미만의 포트번호가 쓰이고 있으므로 관리자는 이 범위를 피해야 한다.

<주의> 이 절과 환경변수에서 값이 다를 경우 TMAX_RAC_PORT 를 사용한다. RACPORT 는 TPORTNO 에서 정의한 포트 번호보다 작은 포트 값을 사용할 것을 권장하며, 또한 RACPORT 의 Port number 도 다른 곳에서 사용되고 있는지의 여부를 반드시 확인해야 한다

BLOCKTIME = numeric (0)

범위: 1 ~ MAX_INT

서비스 요구에 대한 타임아웃(timeout) 시간을 결정한다. 즉, 클라이언트가 API 함수를 통해 서비스 요청 후 최대 BLOCKTIME 시간이 지나도록 응답이 없으면 클라이언트 자체적으로 타임아웃 처리된다. 그러나 서버 프로세스는 계속해서 서비스를 처리한다. 만약 서비스도 종료하고 싶으면 SERVICE 절의 SVCTIME 에 서비스 타임을 지정해야 한다. BLOCKTIME 의 단위는 초(second)이다.

주의 : BLOCKTIME 은 SVCTIME 과 깊이 연관되어있다. 만약 BLOCKTIME 이 SVCTIME 보다 길다면,


클라이언트 tpcall 의 타임아웃 시에 SVCTIME 이 적용된다. 반대로 SVCTIME 이 BLOCKTIME 보다 길다면, BLOCKTIME 이 적용된다. 이럴 경우, BLOCKTIME 은 클라이언트의 tpcall 을 위한 타임아웃이고, SVCTIME 은 서버 프로세스용이기 때문에 SVCTIME 타임아웃까지 tpcall 된 서비스가 수행된다. 일반적으로, BLOCKTIME 은 SVCTIME 보다 큰 값을 갖는다.

NLIVEINQ = numeric (30 초)

범위: 1 ~ MAX_INT

Tmax 시스템이 여러 노드로 구성되었을 경우, 노드간 감시 interval(초단위) 시간을 정하는 항목이다. Tmax 시스템은 양 옆의 노드간에 peer-to-peer 로 연결하여 환경파일에 등록된 순서대로 다음 노드를 감시함으로써 전체 노드가 원활히 통신할 수 있도록 구성되어 있다. NLIVEINQ 시간이 짧으면 양 노드간에 빈번한 감시로 노드의 이상 상태를 즉시 체크 할 수 있으나, 많은 통신량으로 인해 통신 부하가 발생할 수 있다. 반대로 NLIVEINQ 시간이 너무 길면 통신량은 적으나 노드의 이상 상태를 즉시 감시를 할 수 없다. 따라서 시스템 성능을 최적화하기 위하여 네트워크 부하량, 업무의 중요도 등을 고려하여 적절한 NLIVEINQ 값을 정하여야 한다.

CPC = numeric (1)

범위: 1 ~ 128

여러 노드로 구성된 Tmax 시스템에서 양 노드간 CLH 프로세스 사이의 채널 수를 결정하는 항목이다. 양 노드간 서비스 요청이 많거나, 또는 분산트랜잭션이 많을 경우 노드간에 채널 수가 너무 적으면 서비스 처리가 지연되어 전체적으로 시스템 성능이 저하 될 수 있다. 이처럼 전체 시스템의 성능을 높이려면 각 노드의 CLH 프로세스간에 적정 병렬 통신 채널 수를 지정해야 한다.

MAXFUNC = numeric (0)

범위: 1 ~ MAX_INT


TopEnd 시스템으로 구축된 시스템을 Tmax 시스템으로 전환할 때 TopEnd 시스템 에서 사용하는 함수를 Tmax 시스템에서 제공할 수 있도록 함수 테이블의 크기를 결정하는 항목이다.

MAXPROD = numeric(0)

범위: 1 ~ MAX_INT

TopEnd 시스템으로 구축된 시스템을 Tmax 시스템으로 전환할 때 사용하는 항목으로 지정할 수 있는 product name 의 최대 값을 의미한다. (Topend 용)

LOGOUTSVC = service-name

정상/비정상 상태에서 수행될 서비스를 Tmax 서버의 클라이언트 로그아웃 프로세스에 등록한다. LOGOUTSVC 는 시스템에서 클라이언트의 정상적인 로그아웃을 위해 서비스에 로그인이나 로그아웃 할 때 사용된다. LOGOUTSVC 는 설정된 시간(CLICHKINT, IDLETIME)이 지나서 클라이언트가 자동으로 로그아웃이 되는 경우 이를 처리한다. LOGOUTSVC 항목을 사용할 때 주의할 점은 반드시 Tmax 클라이언트인 경우에만 LOGOUTSVC 가 수행이 된다는 점이다. 일반 소켓 연결이 발생하는 상황에서는 수행되지 않는다. service name 을 서비스로 하는 프로그램에는 내부적으로 tpgetclid()를 호출하여 Client id 를 알 수 있고, logout 된 원인에 대한 내용은 tpsvcinfo 구조체 항목의 cd 를 참조한다.

TPNOAUTH (0): 클라이언트의 정상 logout

TPSYSAUTH(1): Tmax 가 인지한 logout (network 등)

TPAPPAUTH(2): 비정상 logout(데이터수신 장애 등)

CLICHKINT = numeric (0)

범위: 1 ~ MAX_INT

이 항목은 클라이언트 감시 시간 간격으로 클라이언트가 살았나 죽었나를 주어진 시간 간격으로 체크 하기 위한 항목이다. 이 항목은 단독으로 사용하는


것보다 다음 항목에 설명할 IDLETIME 항목과 조합해서 사용함으로써 클라이언트의 정확한 상태를 Tmax 엔진에서 감시하여 낭비되는 자원을 최소화 하기 위한 항목이다. 이 항목을 도메인 절에 정의하면 해당 도메인에 접속한 모든 클라이언트를 감시하고 노드절에 등록하면 해당 노드에 접속한 클라이언트만 감시한다.

IDLETIME = numeric (0)

범위: 1 ~ MAX_INT

클라이언트의 유휴시간(idle time)을 정의한다. CLICHKINT 를 5 로 설정하고 IDLETIM 을 30 으로 설정하였다면, 5 초 간격으로 클라이언트의 상태를 확인하고 30 초 이내에 요청이 들어오지 않으면 Tmax 엔진에서 그 클라이언트를 제거한다. IDLETIME 은 클라이언트로부터 tpstart 로 연결을 맺거나 tpcall/tpacall 요청이 있은 후부터 유효하다. 이 때, 값은 BLOCKTIME 이나 SVCTIME 보다 커야 한다. 만약 IDLETIME 값이 BLOCKTIME 과 SVCTIME 보다 더 작게 설정된다면 클라이언트가 응답을 받기 전에 자동 로그아웃 된다.

MAXSACALL = numeric (8)

범위 : 1 – 1024

서버 프로세스가 tpgetrply 없이 요청할 수 있는 tpacall 의 개수를 정의한다. 서버 라이브러리는 각각의 tpacall 을 따르기 때문에 테이블 크기를 설정하는 초기화 MAXSACALL 에 테이블을 작성한다.

MAXCACALL = numeric (16)

범위 : 1 – 1024

클라이언트 프로세스가 tpgetrply 없이 요청할 수 있는 tpacall 의 개수를 정의한다. 클라이언트 라이브러리는 각각의 tpacall 을 따르기 때문에 테이블 크기를 설정하는 초기화 MAXCACALL 에 테이블을 작성한다.

MAXCONV_NODE = numeric (16)


범위 : 1 – 2048

한 노드에서 동시에 대화형 모드로 지정할 수 있는 서버 프로세스의 수를 정의한다.

MAXCONV_SERVER = numeric (8)

범위 : 1 – 256

클라이언트나 서버 프로세스에서 실행 할 수 있는 대화의 수를 지정한다. MAXCONV_SERVER 에서는 대화형 모드에서 클라이언트나 서버 프로세스를 지정할 수 있다. 클라이언트가 대화형 모드로 접속할 수 있는 서버 프로세스의 개수를 정의한다. “서버 수”는 짝수로 정의 되어야 한다. 클라이언트는 MAXCONV_SERVER 에 정의된 수 까지만 서버 프로세스와 대화형 모드로 연결할 수 있다. 이 초기값은 8 이다. 값을 늘리기 위해서는 이 값과 MAXCONV_NODE 의 값을 조정해야 한다.

IPCPERM = numeric (0600)

범위 : 0600 – 0777

IPCPERM(inter-process communication permission mask) 는 공유 메모리 세그먼트와 $(TMAXDIR)/path 에 위치한 pipe 파일의 제어 단위를 설정하는데 쓰인다. 또한 시스템 로그파일($(TMAXDIR)/log/slog) 의 제어 단위도 설정한다. Unix 시스템 환경 하에서는 관리자가 개인이나 그룹, 기타에게 각각 파일 접속 제어(판독가능/기록가능/수행가능)를 지정 할 수 있다. 파일 접속 제어의 초기값은 IPCPERM 이 없을 때 600 이다. 사용자(개인)의 판독과 기록은 가능하지만 그룹과 기타는 불가능 하다. IPCPERM 필드는 다른 사용자 들에게 시작/종료 권한을 주기 위해 제어를 설정하는데 사용된다. IPCEPERM 이 없으면, 다른 사용자들은 서버 프로세스의 시동과 종료를 제어할 수 없다.

DOMAINID = numeric (0)

범위 : 0 – 255


여러 개의 도메인으로 작업을 할 때 특정 도메인을 나타내기 위한 키 값이 필요하다. 이 필드는 키 값을 정의하는 데 쓰인다. 이 필드는 멀티 도메인 환경 하에서는 반드시 설정되어 있어야 한다.

SECURITY = string (NONE)

자세한 것은 ‘보안 환경설정 ‘을 참조

OWNER = user_name

(“NO_SECURITY”) | ”DOMAIN_SEC” | ”USER_AUTH“ 등을 사용해 Tmax 시스템의 보안 설정에 쓰인다. Tmax 는 다양한 보안 기능을 제공한다. User_name 은 15 자 이내의 string 으로 지정한다. 자세한 설명은 ‘보안 환경설정 ‘에서 다루어진다.

TXTIME = numeric (0)

범위: 1 ~ MAX_INT

주어진 시간 내에 수행되지 않으면 트랜잭션 모드에서 요청한 서비스 처리를 취소한다. 단위는 초(second)이다.

NCLHCHKTIME = numeric (0)

범위: 1 ~ MAX_INT

각 NODE 의 CLH 프로세스가 일정시간 동안 데이터의 흐름 없이 지정한 시간이 되면 자동적으로 각 NODE 의 CLH 프로세스끼리 감시 신호를 보내는 역할을 담당한다. 단위는 초(second) 이다.

방화벽은 특정 시간 동안 데이터의 흐름이 없으면 사용 프로세스를 제거하는 기능이 있는데 이 때 Tmax 의 내부 CLH 프로세스도 영향을 받는다. 따라서 이 기능을 사용할 때는 세심한 주의가 필요하다.

CMTRET = (Y) / N

‘분산 트랜잭션 환경설정 ‘을 참조한다.

MAXNODE = numeric(32)


범위: 1 ~ MAX_INT

도메인내 모든 노드 합의 한계를 설정한다.

MAXSVG = numeric(32)

범위: 1 ~ MAX_INT

해당 노드에서 사용할 수 있는 서버 그룹 합의 한계를 설정한다.

MAXSPR = numeric(64)

범위: 1 ~ MAX_INT

한 노드에 최대로 기동할 수 있는 서버 프로세스의 개수로 각 서버 프로세스의 MAX 의 합으로 계산된다.

MAXSVR = numeric(64)

범위: 1 ~ MAX_INT

한 노드에 최대로 등록할 수 있는 서버 프로세스의 최대 개수를 의미한다. 즉 한 노드에 svr1, svr2, svr3 라는 세 개의 서버가 등록되어 있고 각 서버마다 MAX 의 값이 50 이라면 MAXSPR=150 이 되고 MAXSVR=3 이 된다.

MAXSVC = numeric(512)

범위: 1 ~ MAX_INT

한 서버에 최대로 등록 가능한 서비스의 개수를 지정한다.

MAXTMS = numeric(32)

범위: 1 ~ MAX_INT

해당 노드에서 기동 가능한 TMS 의 최대 개수를 설정한다.

MAXROUT = numeric(16)

범위: 1 ~ MAX_INT


서비스 중에서 ROUTING 이란 항목을 지정할 수 있는 서비스의 최대 개수를 의미한다. 예를 들어 30 개의 서비스가 있을 경우 그 중 10 개의 서비스만이 ROUTING 항목을 지정할 수 있다면 MAXROUT 는 10 이 된다.

MAXROUTSVG = numeric(32)

범위: 1 ~ MAX_INT

서비스 절의 ROUTING 항목에 지정한 routing 들의 총 합의 최대값을 의미한다. 예를 들어 MAXROUT 의 값이 10 이고 각각 ROUTING 항목에 두 개의 routing 을 지정할 수 있다면 MAXBACKUPSVG 의 값은 20 이 된다.

MAXRQ = numeric(2)

범위: 1 ~ MAX_INT

해당 노드에서 사용할 수 있는 최대 RQ 의 개수를 지정한다.

MAXGW = numeric(2)

범위: 1 ~ MAX_INT

해당 노드에서 사용할 수 있는 최대 Gateway 의 개수를 지정한다.

MAXCOUSIN = numeric(16)

범위: 1 ~ MAX_INT

서버 그룹 중에서 COUSIN 이란 항목을 지정할 수 있는 서버 그룹의 최대 개수를 의미한다. 예를 들어 30 개의 서버 그룹이 있을 경우 그 중 10 개의 서버 그룹만이 COUSIN 항목을 지정할 수 있다면 MAXCOUSIN 은 10 이 된다.

MAXCOUSINSVG = numeric(32)

범위: 1 ~ MAX_INT


서버 그룹절의 COUSIN 항목에 지정한 서버 그룹들의 총 합의 최대값을 의미한다. 예를 들어 MAXCOUSIN 의 값이 10 이고 COUSIN 항목에 두 개의 서버 그룹을 지정할 수 있다면 MAXCOUSINSVG 의 값은 20 이 된다.

MAXBACKUP = numeric(16)

범위: 1 ~ MAX_INT

서버 그룹 중에서 BACKUP 이란 항목을 지정할 수 있는 서버 그룹의 최대 개수를 의미한다. 예를 들어 30 개의 서버 그룹이 있을 경우 그 중 10 개의 서버 그룹만이 BACKUP 이란 항목을 지정할 수 있다면 MAXBACKUP 은 10 이 된다.

MAXBACKUPSVG = numeric(32)

범위: 1 ~ MAX_INT

서버 그룹절의 BACKUP 항목에 지정한 서버 그룹들의 총 합의 최대값을 의미한다. 예를 들어 MAXBACKUP 의 값이 10 이고 각각 BACKUP 항목에 두 개의 서버 그룹을 지정할 수 있다면 MAXBACKUPSVG 의 값은 20 이 된다.

MAXTOTALSVG = numeric(64)

범위: 1 ~ MAX_INT

지정할 수 있는 총 서버 그룹의 최대 값을 의미한다.

MAXCPC = numeric(32)

범위: 0 ~ 65535

CPC 의 최대값을 설정한다. 이 항목은 동적추가를 위한 항목으로 MAXCPC 에 정의한 갯수를 넘지 않는 범위내에서 CPC 의 갯수를 동적으로 추가할 수 있다. 동적으로 CPC 를 추가하는 API 는 현재 Tmax3.8 에서는 지원하지 않는다.

DOMAIN 절 사용의 예

*DOMAIN


res1 SHMKEY = 77990, MAXUSER = 300,

MINCLH = 2, MAXCLH = 3,

TPORTNO = 8889, RACPORT = 3334,

BLOCKTIME = 60, CLICHKINT = 5,

IDLETIME = 30, LOGOUTSVC = logout

2.2.2.2 NODE 절

DOMAIN 절에서 Tmax 시스템 전체에 대한 환경이 정의 되었다면, 다음으로 Tmax 시스템을 이루는 각 노드들에 대한 구체적인 환경설정이 필요하다.

NODE 절에는 다음과 같은 내용이 정의될 수 있다.

Tmax 시스템의 홈 디렉토리/ 작업 디렉토리

응용 서버프로그램의 실행 파일들을 포함하는 디렉토리

Tmax 프로세스간의 통신을 위한 디렉토리

시스템 메시지가 저장될 디렉토리

사용자 메시지가 저장될 디렉토리

트랜잭션에 대한 정보가 저장될 디렉토리

응용 서버프로그램 기동 시에 필요한 환경변수들이 정의된 환경파일

이 밖에 DOMAIN 절에서 정의한 다음 내용은 노드에 따라 새롭게 정의할 수 있다.

공유 메모리 key 값(SHMKEY)

최소 CLH 개수(MINCLH)

최대 CLH 개수(MAXCLH)

포트 번호(TPORTNO, RACPORT)

최대 사용자 수(MAXUSER)

클라이언트 감시 시간(CLICHKINT, IDLETIME)


Tmax 시스템을 기동 시키면 노드마다 TMM, CLL, CLH(데이터베이스 관련 시스템인 경우 TMS, 멀티 도메인인 경우 게이트웨이 프로세스 포함) 프로세스와 실제 서비스를 수행하는 서버프로세스들이 기동 된다. 이러한 프로세스들이 기동하기 위해서는 실행 파일들이 존재하는 위치(directory)를 알아야 한다. 또한 Tmax 프로세스간의 통신하는데 필요한 디렉토리와 Tmax 시스템이나 사용자가 내보내는 각종 error 와 경고 메시지를 저장하는 디렉토리도 지정할 수 있다. 이 밖에도 DOMAIN 절에서 이미 정의된 공유 메모리 key 값(SHMKEY), 최대 CLH 수(MAXCLH), 최소 CLH 수(MINCLH), 포트번호(TPORTNO, RACPORT), 최대 사용자 수(MAXUSER) 등을 노드에 따라 달리 재정의 할 수 있다.

NODE 절의 기본 환경설정 형식은 다음과 같이 정의한다.

[DEFAULT: ]

노드이름 TMAXDIR=“tmax-home-path “

APPDIR=“application-path “

[,HOSTNAME=“HOST_NAME”]

[,TMAXHOME=“tmax-home-path “]

[,NODETYPE=SHM_RACD|(SHM_USER)]

[,PATHDIR=“stream-pipe-path “]

[,SLOGDIR=“system-log-path “]

[,TLOGDIR=“transaction-log-path “]

[,ULOGDIR=“user-log-path “]

[,DOMAINNAME=domain-name]

[,CLHQTIMEOUT=1 - MAX_INT]

[,ENVFILE=“environment-file-name “]

[,SHMKEY=shared-memory-segment-key]

[,MAXUSER=1 -]

[,MINCLH=1 -10]

[,MAXCLH=1 - 10]

[,TPORTNO=port-number]

[,TPORTNO2=port-number]




[,RACPORT=port-number]

[,IPCPERM=mask]

[,IP=“IP address”]

[,CLICHKINT=interval-time-value]

[,IDLETIME=idle-time]


[,TMMOPT=“TMM-log-path]

[,CLHOPT=“CLH-log=path]

[,REALSVR=server-name]

[,RSCPC=1 – 128]

[,MAXSVG=1 – MAX_INT]

[,MAXSPR=1 – MAX_INT]

[,MAXSVR=1 – MAX_INT]

[,MAXTMS=1 – MAX_INT]

[,MAXCPC=0 – 128]

[,MAXGWSVR=1 – MAX_INT]

[,MAXRQSVR=1 – MAX_INT]

[,MAXGWCPC=1 – MAX_INT]

[,AUTOBACKUP=(Y)|N] [,LOGOUTSVC=“logout-service-name”]

[,TMAXPORT=“port num1, ..., port number5”]

[,CompressPort=“port num1, ..., port num5”]

[,CompressSize=compress_size]

[,RESTART=(Y)|N]

[,MAXRSTART=number]

[,GPERIOD=number]

필수항목

노드 이름= string

15 자 이내의 string 으로 정의한다.

노드의 물리적인 이름으로써, UNIX 의 “uname -n” 명령으로 확인된 이름을 정의한다. 또한 해당 노드명은 반드시 “/etc/hosts” 파일에 등록되어 있어야 한다. 하나의 도메인(DOMAIN)은 하나 이상의 노드로 이루어지므로, NODE 절에는 최소한 하나 이상의 노드 이름이 정의되어야 한다.

TMAXDIR = literal

크기 : 255 자 이내

Tmax 프로그램이 설치(install)되어 있는 홈 디렉토리의 절대 경로명이다. 경로명은 환경변수 TMAXDIR 과 동일한 값이 정의 되어야 한다. TMAXHOME 이 정의되지 않았을 경우 Tmax 관련 작업은 TMAXDIR 디렉토리 하에서 모두 이루어진다.


APPDIR = literal

크기: 255 자 이내

Tmax 를 이용하는 응용 프로그램의 실행 파일이 존재하는 디렉토리의 절대 경로명.

서버의 작업 디렉토리의 절대 경로명

Tmax 시스템에는 Tmax 자체 프로세스들 이외에도, 클라이언트 요구를 처리하는 응용 프로그램들이 있다. 이들은 Tmax 시스템이 기동 될 때 함께 기동 되고, 종료될 때도 함께 종료된다. 이러한 응용 프로그램의 실행 파일이 설치 되어 있는 디렉토리를 정의하는 항목이 APPDIR 이다. 또한 서버의 작업 디렉토리이기도 하며 서버 프로그램에서 발생하는 core 파일이 APPDIR 에서 발생한다.

선택 항목

DEFAULT: 항목 = 값, …

NODE 절 뿐만 아니라 Tmax 환경 파일의 모든 절에서 정의할 수 있는 Label 이다. NODE 절에서 이 Label 은 여러 노드로 구성된 경우 각 노드마다 같은 값을 가진 항목을 정의하려 할 때 유용하게 사용할 수 있다. Label 로 “DEFAULT:” 가 정의되면, 이 후 해당 절이 끝나거나 다른 “DEFAULT:”에 의해서 override 될 때까지 유효하다. “DEFAULT:”에 의해서 정의된 항목들이 NODE 절에 따로 정의되어 있지 않으면, “DEFAULT:”에 의해서 정의된 값들이 모든 노드에 공통적으로 적용된다. 재정의 되었으면, 해당 노드에 대해서는 NODE 절에서 정의된 새로운 값이 적용된다.

HOSTNAME = literal

크기 : 255 자 이내

이 항목은 실제 호스트와 환경 파일에 정의하는 노드의 이름이 다를 경우에도 동작하도록 하기 위한 항목으로 실제 호스트 이름을 지정한다. HOSTNAME 을 지정하였을 경우 한 머신 내에서 논리적인 멀티 노드를 사용할 수 있다. 즉 하나의 호스트 이름에 여러 개의


노드 이름을 사용할 수 있다. 이 항목은 NODE 절의 TMAXHOME, NODETYPE, RACPORT, TPORTNO, SHMKEY 항목이 반드시 함께 고려되어 정의되어야 한다. (각 항목 참조) 정의되지 않았을 경우, 노드 이름이 HOSTNAME 이 된다. 자세한 내용은 아래 노드 절의 사용 예를 통해 알아본다.

TMAXHOME = literal

크기 : 255 자 이내

Tmax install 디렉토리와 work 디렉토리를 분리하여 사용할 수 있도록 하기 위한 항목으로 Tmax 프로그램이 설치(install)되어 있는 홈 디렉토리의 절대 경로명을 정의한다. 이 경로명은 환경변수 TMAXHOME 과 동일한 값이 정의되어야 한다. TMAXHOME 항목이 정의되었을 경우 TMAXDIR 은 work directory 가 되며 정의되지 않았을 경우 TMAXDIR 이 install directory 와 work directory 가 된다. TMAX install 디렉토리와 work 디렉토리는 아래와 같이 구분된다. HOSTNAME 항목과 함께 설정이 된 경우는 각각의 TMAXDIR 이 하나의 논리 노드가 되며 TMAXHOME 은 각 논리 노드가 공유하는 Tmax install 디렉토리가 된다. 따라서 동일 노드 내의 논리 노드의 TMAXDIR 과 SHMKEY, TPORTNO 는 모두 다르게 설정해 주어야 한다.

- TMAXHOME : Install directory - bin, lib, usrinc, tuxinc, topinc, cblinc

- TMAXDIR : work directory – config, path, license, log, svct

NODETYPE = (SHM_RACD) | SHM_USER

이 항목은 HOSTNAME 을 지정하여 한 machine 내에 여러 LOGICAL NODE 를 정의하였을 경우, 각각의 LOGICAL NODE 를 관리하기 위한 방법을 결정하는 항목이다. SHM_RACD 가 지정되었을 경우에는 RACPORT 를 이용하여 각각의 논리 노드를


관리하겠다는 의미이며, SHM_USER 가 지정되었을 경우에는 RACPORT 를 사용하지 않고 각 논리 노드를 직접 관리하겠다는 의미이다. 이 때 한 machine 내의 LOGICAL NODE 의 RACPORT 는 반드시 달라야 한다. 따라서 2 이상의 LOGICAL NODE 를 사용할 경우, RACPORT 는 반드시 재정의 해야 한다. 중요한 점은 NODETYPE 항목은 반드시 tmboot/tmdown/tmadmin/cfl 을 수행하는 논리 노드와 같은 HOST 에 있는 노드들만을 관리할 때 사용한다는 것이다. 다른 HOST 에 있는 논리 노드들을 관리할 경우에는 NODETYPE 에 관계 없이 RACPORT 를 사용한다. 요약하여, NODETYPE 이 사용되는 경우는 다음과 같다.

- tmdown/tmadmin/cfl/tmboot 를 시작한 논리노드(node A)와 같은 host 에 존재하는 다른 논리노드(node B)가 있는 상황에서, 해당 노드(node B)의 tmdown/tmadmin/cfl/tmboot command 를 수행할 때 racd 를 통할 것인가, 아니면 직접 수행 할 것인 가를 결정할 경우

PATHDIR = literal ( TMAXDIR )/path

크기 : 255 자 이내

Tmax 시스템의 프로세스들이 통신하기 위한 네임드 스트림 파이프(named stream pipe) 경로명이다

프로세스간에는 파이프(pipe: unnamed pipe, named pipe), 메시지 큐(message queue), 공유메모리(shared memory)를 이용한 통신방법 등이 있다. Tmax 에서는 프로세스간에 정보를 주고받기 위해 공유메모리 (DOMAIN 절의 SHMKEY 항목 참조)와 더불어 스트림 파이프 (stream pipe) 방식을 사용한다. 이 스트림 파이프를 사용하기 위해서는 pathname 이 필요하다. PATHDIR 은 Tmax 관련 프로세스들이 스트림 파이프를 통하여 통신하는데 필요한 pathname 들이 만들어지는 디렉토리명이다. 즉, 이 디렉토리에 프로세스들이 통신할 수 있도록 네임드 파이프(named pipe)들이 만들어지는 것이다 이 항목이 정의되지 않은 경우에는 TMAXDIR 에서


지정한 디렉토리 밑의 path 디렉토리에 파이프들이 만들어진다.

PATHDIR 을 $TMAXDIR/path 이외의 디렉토리로 지정했을 경우 Tmax 시스템 종료 시 올바른 시스템 종료가 되지 않는 경우가 있다. 그 이유는 Tmax 시스템 종료 시에 시스템은 $TMAXDIR/path 디렉토리에 있는 스트림 파이프(named pipe)를 사용하기 때문이다. 이를 해결하기 위해 사용자는 환경 변수 TMAX_PATHDIR 에 사용자가 환경 파일에 설정해 준 PATHDIR 을 지정해 주면 된다. 이렇게 한 후 Tmax 시스템을 종료할 경우 Tmax 시스템은 환경변수로 지정해 준 TMAX_PATHDIR 을 참조하여 종료가 되기 때문에 올바르게 종료할 수 있다. (예 : export TMAX_PATHDIR =/home/tmax/path_new)

Tmax 시스템 기동 시에 config 디렉토리에 있는 이진 환경 파일이 환경파일에 설정해 놓은 PATHDIR 에 복사되는데 이는 Tmax 시스템이 기동한 후에 환경 파일이 수정되었을 경우 올바르게 종료가 되지 않는 점을 해결하기 위한 것으로 이 것 역시 환경 변수 TMAX_PATHDIR 에 변경 되기 전(Tmax 시스템이 기동 되었을 때 참조되었던 PATHDIR)의 PATHDIR 을 설정해 주면 이 디렉토리 밑에 이진 환경 파일이 생성되며 이 환경 파일은 Tmax 시스템이 기동된 후에 환경 파일이 수정되더라도 변경되지 않는다. 따라서 사용자가 Tmax 시스템 기동 후에 환경 파일을 수정하더라도 Tmax 시스템이 올바르게 종료되지 못하는 경우를 없앨 수 있다

SLOGDIR = literal (TMAXDIR)/log/slog

크기 : 255 자 이내

시스템 메시지가 기록(logging)될 디렉토리의 절대 경로명을 지정한다. 여기서 시스템 메시지란, TMM, TMS, CLL, CLH 등이 출력하는 메시지와 시스템 내부적으로 발생한 메시지들을 일컫는다. 지정된 SLOGDIR 디렉토리에는 날짜별로 ‘slog.날짜’ 파일이 만들어져, 각 파일에 일자별로 발생한 메시지가 기록된다. 이 항목이 정의되지 않은 경우에는 TMAXDIR 에서 지정한 디렉토리 밑의 log/slog 디렉토리에 기록된다.


<주의>지정된 경로는 사용중인 시스템에 존재해야 한다.

ULOGDIR = literal (TMAXDIR)/log/ulog

크기 : 255 자 이내.

사용자 메시지가 기록(logging)될 디렉토리의 절대 경로명을 지정한다.

사용자, 즉 Tmax 응용 프로그래머는 userlog() 함수(Tmax Application Development Guide 참조)를 이용하여 디버그용 메시지, 각종 에러 및 경고 메시지 등을 사용자에 따라 간편하게 로깅(logging)할 수 있다. 이렇게 프로그래머가 userlog() 함수를 통해 내보내는 메시지들이 저장될 디렉토리가 ULOGDIR 이다. 지정된 ULOGDIR 디렉토리에는 날짜별로 ‘ulog_날짜’ 파일이 만들어져, 각 파일에는 일자별로 발생한 메시지들이 기록된다. 이 항목이 정의되지 않은 경우에는 TMAXDIR 에서 지정한 디렉토리 밑의 log/ulog 디렉토리에 기록된다.


TLOGDIR = literal (TMAXDIR)/log/tlog

크기 : 255 자 이내

XA 를 이용한 트랜잭션 발생 시, 이에 대한 정보를 TXLOG 파일에 기록한다. 이떄 TXLOG 파일이 생성될 절대 경로명을 지정한다. Binary 이기 때문에 해독은 불가하며, Tmax Engine 에서 트랜잭션에 대한 정보관리를 위해 필요하다. TXLOG 파일은 파일 시스템으로 생성하며 Tmax 에서는 raw file 에 따라 이 파일의 기록을 지원하지 않는다. 이 항목이 정의되지 않은 경우에는 TMAXDIR 에서 지정한 디렉토리 밑의 log/tlog 디렉토리에 기록된다.


DOMAINNAME = string



하나의 환경파일에 여러 개의 도메인 정의가 가능함으로 해당 노드가 속한 도메인의 이름을 지정한다. 도메인 이름은 반드시 DOMAIN 절에서 정의한 이름이어야 한다.

CLHQTIMEOUT = numeric

범위: 1 ~ MAX_INT

큐에 지정된 시간 이상 대기상태에 있는 경우 시간이 경과된 메시지를 큐에서 제거하는 기능이다. 즉, 호스트 문제, 네트웍 문제 등으로 인하여 서버 큐에 계속 적체되는 현상이 발생하는 경우 무한정 큐에 적체 시키지 않고 클라이언트에게 현재 상황을 알려 적절한 대처를 유도하는 설정 값이다.

ENVFILE = literal

크기 : 255 자 이내

ENVFILE 은 응용 서버프로그램들을 실행하기 위해 필요한 특정 환경을 설정하기 위해 UNIX 환경변수들이 정의되어 있는 환경파일을 지정한다. 따라서 서버프로그램은 ENVFILE 에 지정된 환경 하에서 수행된다. 이 파일의 정의 방법은 앞장에서 설명된 방법으로 정의하면 된다.

TPORTNO[2-5] = numeric

클라이언트가 서버에 연결할 때 사용하는 Tmax 시스템 포트번호로서 TPORTNO 항목에서 정의한 포트 외에 다른 포트로 Tmax 시스템에 접속하기 위하여 지정한다.

TPORTNO2 부터 TPORTNO5 까지 모두 정의하면 Tmax 시스템에 접속할 수 있는 포트는 총 5 개 이다. 일반적으로 시스템 영역에서는 1024 이하의 포트 번호를 사용하므로 관리자는 이 범위를 피해야 한다.

<주의> TPORTNO 에서 정의한 포트번호와 그 다음 포트번호(TPORTNO+1)는 클라이언트와 Tmax 시스템 혹은 다른 노드들 사이의 통신에 사용되므로 이 외의 포트번호를 지정해야 한다. 또한 다른 곳에서 사용되고 있는지의 여부를 반드시 확인해야 한다.


TPORTNO 에서 지정한 포트번호는 앞의 네 개의 절에서 이미 지정한 포트 번호와 달라야 한다.

REALSVR = literal

RDP 타입의 서버 프로세스를 운영하고자 할 때 서버 프로세스의 이름을 설정한다.

리얼 서버는 한 노드에 유일해야 하며 해당 노드에 존재하는 모든 서비스는 RDP 서버 프로세스를 통해 클라이언트에게 직접 전달되게 된다. 이를 위해서 다른 서버 프로세스가 처리한 결과를 얻어오기 위한 채널의 수 RSCPC 값을 설정해 주어야 하며 CLH 와 RDP 서버 프로세스의 수는 일정하게 유지되어야 한다(즉 MIN 값과 MAX 값이 같아야 한다). 단 RDP 서버 프로세스는 CLH 보다 항상 많아야 하며 통상 2 배수로 설정한다.

RSCPC = numeric

범위: 1 ~ 128

RDP 서버 프로세스와 다른 서버간의 통신에 사용되는 채널의 수이다.

MAXSVG = numeric(32)

범위: 1 ~ 128

해당 노드에서 최대로 설정 가능한 서버 그룹의 개수를 의미한다

MAXTMS = numeric(32)

범위: 1 ~ 128

해당 노드에서 기동 가능한 TMS 의 최대 개수를 설정한다.

MAXGWSVR = numeric(2)

범위: 1 ~ 128


MAXGW 가 한 노드에서 사용할 수 있는 최대 Gateway 의 개수라면 MAXGWSVR 은 해당 노드에서 기동할 수 있는 Gateway 서버 프로세스의 최대 개수이다. 이들의 디폴트 값은 2 인데 이는 두 개의 Gateway 가 있는데 각각의 Gateway 는 하나의 Gateway 서버를 둘 수 있다는 의미이다.

MAXRQSVR = numeric(2)

범위: 1 ~ 128

해당 노드에서 기동할 수 있는 RQ 서버 프로세스의 최대 개수.

MAXGWSVR 참조

MAXGWCPC = numeric(8)

범위: 1 ~ 128

Gateway 서버와 CLH 간의 연결 개수를 지정한다.

이와 같은 서버와의 CPC 는 기본적으로 PAIR(input channel/output channel)로 구성이 되기 때문에 CPC=2 의 환경에서 게이트웨이 서버의 개수가 2 라면 8 개의 연결이 필요하게 되므로 MAXGWCPC 는 8 이상의 값을 설정해야 한다. 또한 MAXGWCPC 의 값의 합은 MAXCPC 의 값보다 작아야 한다. MAXGWCPC 의 값을 늘리는 경우에는 MAXCPC 의 값도 함께 증가시켜주어야 한다.

AUTOBACKUP = (Y) / N

백업 서버를 지정한 경우 메인 서버에 문제가 발생하였을 때 자동으로 백업 서버를 기동할 것인지를 설정한다. 디폴트는 Y 이다.

TMAXPORT = “port num1, … , port num5”

TPORTNO, TPORTNO[2-5]를 대체하기 위한 항목으로, 여러 개의 PORT 를 사용하는 경우 TPORTNO[2-5] 보다는 TMAXPORT 를 사용할 것을 권장한다.

CompressPort = “port num1, … , port num5”


Tmax 에서는 엔진과 클라이언트간의 데이터 압축을 통해서 통신할 수 있는 기능을 제공한다. client 가 압축 기능을 사용해서 통신하고자 할 때 접속해야 하는 port 번호를 지정한다. 지정하지 않으면 압축을 하지 않게 된다. 중요한 것은 이 port 번호는 현재 Tmax 가 Listen 하고 있는 포트 중에서 지정해야 한다는 것이다. 즉 NODE 절의 TMAXPORT 가 정의되어 있다면 TMAXPORT 에 지정되어 있는 포트들 중에서 지정해야 하며, TMAXPORT 가 정의되어 있지 않다면 DOMAIN 절의 TPORTNO 로 지정하여야 한다. 이렇게 지정하고 나면 해당 포트로 접속한 client 만이 압축 기능을 사용하게 된다.

하지만 일반적인 network 환경이라면 network 전송 delay 보다 압축하는 overhead 가 더 크기 때문에 압축 기능을 사용하지 않는 것이 좋다. 압축이 필요한 경우는 클라이언트와 서버 사이의 network 조건이 상당히 좋지 않은 환경에서 비교적 큰 데이터를 주고 받으려고 하는 경우이다. (예를 들어 모뎀을 통해서 접속하는 클라이언트가 수십 Kbyte 이상의 데이터를 주고 받으려고 하는 경우) 아래의 표는 클라이언트가 100Mbps Local LAN 과 56KB 모뎀을 사용하여 접속한 환경에서 1.5 MB 의 데이터를 받는 시간을 측정한 것이다. 테스트 결과에서 볼 수 있듯이 modem 으로 접속하는 클라이언트가 텍스트 형식의 큰 데이터를 주고 받는 경우에 압축 기능을 사용하는 것이 가장 효과적임을 알 수 있다.

- Local Network Client : mp3 데이터를 받는 경우

compress 한 경우 compress 하지 않은 경우

10 3

10 3

10 4

10 3


- Local Network Client : 텍스트 데이터를 받는 경우


8 1

8 0(0.85)

8 0(0.85)

8 0(0.85)

- Modem Client : mp3 데이터를 받는 경우


352 350

309 307

328 331

349 351

- Modem Client : 텍스트 데이터를 받는 경우


80 137

89 153

77 154

77 154


- 전송 데이터의 크기 mp3 : 실제 : 1,459,095byte, 압축 시 : 1,442,869 byte txt : 실제 : 1,445,184byte, 압축 시 : 313,057 byte

<주의> 압축 기능을 사용하기 위해서는 클라이언트 프로그램을 컴파일 할 때 반드시 libz.a(so)를 함께 링크시켜야 한다. 현재 압축 기능은 Real Server, node 간 데이터 전송, domain 간 데이터 전송에 있어서 지원하지 않는다.

CompressSize = numeric

압축 기능을 사용할 때 해당 항목에 지정한 크기 이상의 데이터만을 압축하도록 하는 항목으로 단위는 byte 이다. CompressSize 는 반드시 CompressPort 와 함께 지정되어야 한다. 아래와 같이 설정한 경우 Tmax 엔진은 9999 포트 번호로 접속한 클라이언트와 압축 기능을 사용하여 통신하게 된다. 통신 할 때 데이터의 크기가 10000 byte 이상의 메시지인 경우에만 압축을 하게 되고 데이터의 크기가 10000 byte 이하이거나, 클라이언트가 8888 포트 번호로 접속하였을 경우에는 압축을 사용하지 않고 통신을 하게 된다.

TPORTNO = “8888, 9999”,

CompressPort = “9999”

CompressSize = 10000

RESTART = (Y) | N

NODE 절에 지정하였을 경우 Tmax 엔진 프로세스 중 CLH 와 CAS 의 재기동 여부를 결정하는 항목으로 비정상적인 종료 시 재기동 시킨다.

MAXRSTART, GPERIOD

장애 대책에 사용되는 필드이다. 자세한 사항은 ‘장애대책 환경설정 ‘을 참조한다.

재정의 가능 항목

이미 DOMAIN 절에서 정의되었으나 각 노드에 따라 새롭게 정의할 수 있는 항목들이 있다. 이 항목들이


NODE 절에 정의되어 있지 않으면, DOMAIN 절에서 정의된 값들이 모든 노드에 공통적으로 적용된다. 재정의 되었으면, 해당 노드에 대해서는 NODE 절에서 정의된 새로운 값이 적용되며, 형식이나 내용은 DOMAIN 절과 동일하다.

SHMKEY

MINCLH

MAXCLH

TPORTNO

RACPORT

MAXUSER

IPCPERM

MAXSPR

MAXSVR

MAXCPC

LOGOUTSVC

= numeric

= numeric

= numeric

= numeric

= numeric

= numeric

= numeric

= numeric

= numeric

= numeric

= string

(1)

(10)

(8888)

(3333)

(0600)

(64)

(64)

(-1)

NODE 절의 사용 예 1 (물리 노드)

*NODE

DEFAULT:

MINCLH=2, MAXCLH=3

tmax1 TMAXDIR = “/home/tmax”,

APPDIR = “/home/tmax/appbin”,


SLOGDIR = “/home/tmax/log/slog”,

TLOGDIR = “/home/tmax/log/tlog”,

ULOGDIR = “/home/tmax/log/ulog”,

TMMOPT = “-o /home/tmax/log/slog/tmmo.log

–e /home/tmax/log/slog/tmme.log”,

CLHOPT = “-o /home/tmax/log/slog/clho.log

–e /home/tmax/log/slog/clhe.log”,

ENVFILE = “/home/tmax/server/start”,


TMAXPORT = “8850, 9000, 9001, 9002, 9003”,

CompressPort = “9000, 9001”,

CompressSize = 10240,

RESTART = Y, MAXRSTART = -1, GPERIOD = 100

NODE 절의 사용 예 2 (한 머신 내의 논리 노드)

*NODE

DEFAULT:

HOSTNAME = "tmaxs1",

TMAXHOME = "/user/starbj81/tmax",

NODETYPE = SHM_USER

tmaxs1 TMAXDIR = "/user/starbj81/tmax",

APPDIR = "/user/starbj81/tmax/appbin",

PATHDIR = "/user/starbj81/tmax/path",

TLOGDIR = "/user/starbj81/tmax/log/tlog",

ULOGDIR = /user/starbj81/tmax/log/ulog",

SLOGDIR = "/user/starbj81/tmax/log/slog"

NODE1 TMAXDIR = "/user/starbj81/proj1",

APPDIR = "/user/starbj81/proj1/appbin",

PATHDIR = "/user/starbj81/proj1/path",

TLOGDIR = "/user/starbj81/proj1/log/tlog",

ULOGDIR = "/user/starbj81/proj1/log/ulog",

SLOGDIR = "/user/starbj81/proj1/log/slog",

TPORTNO=8952, SHMKEY = 76995,

RACPORT = 3334

NODE2 TMAXDIR = "/user/starbj81/proj2",

APPDIR = "/user/starbj81/proj2/appbin",

PATHDIR = "/user/starbj81/proj2/path",

TLOGDIR = "/user/starbj81/proj2/log/tlog",

ULOGDIR = "/user/starbj81/proj2/log/ulog",

SLOGDIR = "/user/starbj81/proj2/log/slog",


RACPORT = 3335, NODETYPE=RACD

위의 경우를 보면 실제 HOSTNAME 은 tmaxs1 이며, 세 개의 논리 노드, 즉, tmaxs1, NODE1, NODE2 가 존재하여 멀티 노드 구성을 이룬다. TMAXHOME 은 세 개의 논리 노드가 공유하는 Tmax install


디렉토리(bin, lib, usrinc, tuxinc, topinc, cblinc)이며, TMAXDIR 은 각각 논리 노드의 작업 디렉토리(config, path, license, log, svct)가 된다. tmaxs1 논리 노드에서 tmboot 할 경우, NODE1 의 NODETYPE 이 SHM_USER 이므로 NODE1 에게는 RACD 를 통하지 않고 직접 tmboot/tmdown/tmadmin 을 수행하게 된다. NODE2 의 NODETYPE 이 SHM_RACD 이므로 NODE2 에게는 RACD 를 통하여 tmboot 등을 수행하게 된다. 각 논리 노드들은 현재의 환경파일을 읽어들이고 TMAXDIR 을 이용하여 자신의 노드 번호를 알아낸 후, 해당 tmm 에 접속하여 tmboot/tmdown/tmadmin/cfl/gst 를 하거나. 원하는 파일을 읽고 쓰는 작업을 수행하게 된다. 따라서, cfl 을 이용하여 환경 파일을 컴파일할 경우 현재의 환경 변수 $TMAXDIR 디렉토리의 config($TMAXDIR/config) 를 참조하여 컴파일하며, gst 시에도 $TMAXDIR/svct 를 참조하여, 로컬 노드에 자신에 해당하는 서비스 테이블을 생성한다.

NODE 절의 사용 예 2 (여러 머신 내의 논리 노드)

*NODE

DEFAULT:

HOSTNAME = "tmaxs1",

TMAXHOME = "/user2/starbj81/tmax32",

NODETYPE = SHM_USER

tmaxs1 TMAXDIR = "/user2/starbj81/tmax32",

APPDIR = "/user2/starbj81/tmax32/appbin",

PATHDIR = "/user2/starbj81/tmax32/path",

TLOGDIR = "/user2/starbj81/tmax32/log/tlog",

ULOGDIR = "/user2/starbj81/tmax32/log/ulog",

SLOGDIR = "/user2/starbj81/tmax32/log/slog"

NODE1 TMAXDIR = "/user2/starbj81/proj1",

APPDIR = "/user2/starbj81/proj1/appbin",

PATHDIR = "/user2/starbj81/proj1/path",

TLOGDIR = "/user2/starbj81/proj1/log/tlog",

ULOGDIR = "/user2/starbj81/proj1/log/ulog",

SLOGDIR = "/user2/starbj81/proj1/log/slog",


RACPORT = 4335


DEFAULT:

HOSTNAME = tmaxc1,

TMAXHOME = "oracle/starbj81/tmax",

NODETYPE = SHM_RACD

tmaxc1 TMAXDIR = "/oracle/starbj81/tmax",

APPDIR = "/oracle/starbj81/tmax/appbin",

PATHDIR = "/oracle/starbj81/tmax/path",

TLOGDIR = "/oracle/starbj81/tmax/log/tlog",

ULOGDIR = "/oracle/starbj81/tmax/log/ulog",

SLOGDIR = "/oracle/starbj81/tmax/log/slog",

TPORTNO = 8893, SHMKEY = 76980,

RACPORT=4335

NODE3 TMAXDIR = "/oracle/starbj81/proj1",

APPDIR = "/oracle/starbj81/proj1/appbin",

PATHDIR = "/oracle/starbj81/proj1/path",

TLOGDIR = "/oracle/starbj81/proj1/log/tlog",

ULOGDIR = "/oracle/starbj81/proj1/log/ulog",

SLOGDIR = "/oracle/starbj81/proj1/log/slog",

TPORTNO = 9984, SHMKEY = 76999,

RACPORT=4336

위의 경우를 보면 실제 HOSTNAME 은 tmaxs1 과 tmaxc1 이며, 네 개의 논리 노드, 즉, tmaxs1 호스트의 tmaxs1 과 NODE1, tmaxc1 HOST 의 tmaxc1 과 NODE3 이 존재하여 멀티 노드 구성을 이룬다. tmaxc1, NODE3 의 NODETYPE 이 SHM_RACD 이므로 tmaxc1 HOST 내에서 tmaxc1 과 NODE3 논리 노드간 RACD 를 사용하여 tmboot/tmdown/tmadmin 등을 수행하게 된다. 만약 tmboot 등을 수행하는 노드가 tmaxs1 HOST 의 NODE1 이라면 tmaxc1 HOST 내의 tmaxc1 과 NODE3 노드의 NODETYPE 은 의미가 없게 되며 무조건 RACD 를 이용하여 통신을 하게 된다. RACD 는 TMAXDIR 과 RACPORT 를 이용하여 뜨게 되는데, 사용자가 각 논리 노드의 RACD 를 띄우기 위해서 두 환경 변수를 매번 바꿔주는 것이 불편하기 때문에 racd 에 –i 옵션과 –l 옵션을 사용하여 어느 노드의 RACD 인지를 쉽게 구별할 수 있다. (Tmax Reference Manual 의 racd 부분 참조) 이는 NODETYPE 이 SHM_RACD 일 경우 각 논리 노드마다 모두 RACD 를 하나씩 띄워야 하기 때문이다.


2.2.2.3 SVRGROUP 절

Tmax 에서는 응용 서버프로세스들을 그룹 단위로 묶어서 관리한다. 서버들의 그룹화는 그 서버들이 어떤 노드에 존재하는지, 어떤 데이터베이스를 사용하는지, 또한 어떤 논리적인 연관성이 있는지 등에 따라 이루어진다. 서버그룹은 트랜잭션 처리, 부하조절, 장애대책, 라우팅이 이루어지는 기본 단위로써, 자세한 내용은 관련 부분에서 다룰 것이다.

SVRGROUP 절에는 다음과 같은 내용이 정의된다.

각 서버그룹이 속하는 노드

데이터베이스 관련 정보

분산트랜잭션 관련 정보

이 밖에 NODE 절에서 정의한 다음 내용은 서버그룹에 따라 새롭게 정의할 수 있다.

보안 환경설정(SECURITY, OWNER)

응용 서버프로그램의 실행 파일들이 존재하는 디렉토리


SVRGROUP 절의 기본 환경설정 형식은 다음과 같이 정의한다.

[DEFAULT :]

SVRGROUP 이름 NODENAME=node-name

[,APPDIR = path]

[,ULOGDIR = path]

[,SVGTYPE = TMAX | RQMGR]

[,COUSIN = group-name]

[,BACKUP = group-name]

[,LOAD = numeric]

[,DBNAME = name-of-database]

[,OPENINFO = string]

[,CLOSEINFO = string]

[,MINTMS = numeric]

[,MAXTMS = numeric]


[,TMSNAME = name-of-tms]

[,ENVFILE = path]

[,CPC=number]

[,RESTART=(Y)|N]

[,MAXRSTART=number]

[,GPERIOD=number]

필수 항목

서버그룹 이름= string

크기 : 15 자 이내

서버그룹에 대한 논리적인 이름으로써 SVRGROUP 절 내에서 유일한 이름이어야 한다. SVRGROUP 절 이름은 SERVER 절의 SVGNAME 항목에서 사용된다.

NODENAME = string


서버그룹이 존재하는 노드를 정의한다. 사용되는 NODENAME 은 NODE 절에서 정의한 노드 이름이어야 한다. 노드이름에 ‘-‘가 들어갈 경우 필히 큰따옴표로 묶어주어야 한다.

선택 항목


NODE 절의 DEFAULT LABEL 을 참조한다.

SVGTYPE = string

서버 그룹의 유형을 지정하는 항목이다.

유형에는 TMAX 와 RQMGR 이 있으며 디폴트는 TMAX 이다. RQMGR 이란 *RQ 절에 등록된 RQ 의 서버그룹을 의미한다.

COUSIN = literal

크기 : 8000 자 이내


이 항목은 그룹별로 서로 공유해야 할 프로세스가 있거나, 그룹간 ROUTING 이 필요한 경우 그룹이름을 지정 한다. 같은 노드이거나 다른 노드에 속한 그룹인 경우에도 그룹이름을 지정 할 수 있다. COUSIN 과 BACKUP 을 함께 지정할 수 있는데 이 경우 COUSIN, BACKUP 각각 다른 서버그룹이어야 한다. ROUTING 은 COUSIN 에 지정한 서버 그룹이 담당하며, 장애가 발생하였을 경우에는 BACKUP 에 지정한 서버 그룹이 담당한다.

BACKUP = literal

크기 : 8000 자 이내

이 항목은 장애대책 방안의 하나로 제공되어 지며, 백업 되어야 할 그룹 이름을 지정하면 장애 시 중단 없이 서비스를 지속적으로 수행 할 수 있다.

LOAD = numeric

-1 : Static routing 을 의미하며, 특정 노드에 접속한 클라이언트는 그 노드에 속하는 그룹에서 처리한다.

0 : Dynamic routing 이 수행된다. Tmax 엔진이 판단하여 제일 부하가 적은 그룹이 처리토록 함으로써 부하를 분산 한다.

1~ : Rule based routing 을 의미하며, 분산을 하고자 하는 그룹들에 대하여 각각 지정한 비율대로 부하를 분산할 수 있다

<주의> 이것은 COUSIN 필드에서 정의된 GROUP 에서만 수행된다.

DBNAME = string


TMS 로 설정이 되는 경우 지정한다. 데이터베이스 고유의 이름을 지정하면 된다.

OPENINFO = literal

크기 : 255 자 이내


이 항목은 데이터베이스와 연결을 하기위해 TMS 가 필요할 때 정의한다. 데이터 베이스로 연결을 초기화하고 각 데이터베이스에서 제공되는 문법으로 정의 한다.

OPENINFO 절의 내용의 암호화를 원할 경우 암호화를 원하는 부분을 ***** (별표 5 개)로 표시한다. 암호화가 설정된 부분에 대해서는 cfl 시에 암호를 입력 받게 된다.

부분 암호화 : OPENINFO=“ORACLE_XA+Acc=P/scott/*****+SesTm=100”

전체 암호화 : OPENINFO = “*****”

CLOSEINFO = literal

크기 : 255 자 이내

이 항목은 데이터베이스와 연동하는 그룹, 즉 TMS 가 설정이 되는 경우 지정한다. 데이터베이스와 연결을 끊기 위한 것으로 각 데이터베이스에서 제공되는 문법으로 정의 한다.

<주의> 대부분의 DBMS 는 이 항목이 필요 없으나, INFORMIX 의 경우는 반드시 지정해 주어야 한다.

TMSNAME = string


이 항목은 데이터베이스와 연동하는 그룹, 즉 TMS 가 설정이 되는 경우, 해당 서버그룹의 데이터베이스 관리를 담당할 TMS 프로세스 이름을 정의한다.

MINTMS = numeric (2)

크기:1~16

이 항목은 데이터베이스와 연동하는 그룹, 즉 TMS 가 설정이 되는 경우, 부팅 시 기동되는 TMS 프로세스 수를 지정한다.


MAXTMS = numeric (3)

크기:1~16

이 항목은 데이터베이스와 연동하는 그룹, 즉 TMS 가 설정이 되는 경우, 최대 기동 될 수 있는 TMS 프로세스 수를 지정한다.

CPC = numeric (1)

크기: 1 ~ 128

이 항목은 SVGTYPE 이 RQMGR 일 때만 유효하다. CLH 프로세스들을 가진 채널의 수를 정의한다. 자세한 내용은 ‘신뢰성 큐 환경설정’’을 참조한다.

ENVFILE = literal


이 항목은 이 그룹에 속한 서버들에게 환경변수로 값을 전달하고자 할 때나, 같은 노드에 복수개의 동종 데이터베이스와 연동이 필요한 경우 지정한다.

RESTART = (Y) | N

SVRGROUP 절에 지정하였을 경우 RQ 나 TMS 의 재기동 여부를 결정하는 항목으로 비정상적인 종료 시 재기동 시킨다. SVGTYPE 이 RQMGR 이거나 XA SVG 일 때만 유효하다.

MAXRSTART, GPERIOD


재정의 가능 항목

APPDIR = literal

크기 : 255 자 이내

서버 그룹에 속하는 응용 프로그램의 실행 파일이 설치되어 있는 디렉토리의 절대 경로명이다.


노드절에 등록된 APPDIR 은 해당 노드에서 실행되는 모든 응용 프로그램의 위치를 지정하는 항목이고, 이를 서버 그룹에 재지정하면 그룹별로 응용 프로그램 실행 파일의 위치를 지정할 수 있다.

ULOGDIR = literal

크기 : 255 자 이내

노드절에서 사용자 메시지가 기록(logging)될 디렉토리의 절대 경로명을 서버 그룹별로 재지정하기 위해서 사용하는 항목이다. 사용자 메시지 기록 방식은 노드절에서 설명한 내용과 동일하다.

<주의>지정된 경로는 사용중인 시스템에 존재해야 한다

SVRGROUP 절의 사용 예

*SVRGROUP

svg1 NODENAME = tmax, APPDIR = “/home/tmax/appbin”, ULOGDIR = “/home/tmax/appbin/svg1_log” svgora NODENAME = tmax, DBNAME = ORACLE, OPENINFO = “Oracle_XA+Acc=P/scott/tiger+SesTm = 60, DbgFl=0x01 + LogDir=/tmp”, TMSNAME = svg1_tms svginfx NODENAME=tmax, DBNAME=INFORMIX, OPENINFO=”stores7; USER={userid}; PASSWD={password}”,

TMSNAME=info_tms

예 설명 1) svgora 에서 LogDir 항목은 xa log 가 저장되는 경로명을 지정한다.

예 설명 2) INFORMIX 의 경우 Tmaxsystem 을 부팅하는 계정이 informix 에 로긴하는 계정과 같은 경우에는 OPENINFO=”stores7”과 같이 USER, PASSWD 를 생략할 수 있다.


2.2.2.4 SERVER 절

지금까지 살펴본 DOMAIN, NODE, SVRGROUP 절이 Tmax 시스템과 관련된 환경설정이었다면, 이제부터는 실질적으로 제공하는 서비스들을 등록하여야 한다. 즉, 작성된 응용 프로그램에서 제공하는 서비스 종류들을 등록하여, 제공되는 서비스와 서비스를 제공하는 응용 서버프로세스에 대한 정보를 알리는 것이다. Tmax 는 등록된 서비스만을 처리하기 때문에, 새로운 서버프로그램이나 서비스가 추가되는 경우에는 Tmax 환경파일의 SERVER 절이나 SERVICE 절에 추가내용을 반드시 등록하고 적용시켜야만 한다.

먼저 SERVER 절에 대해 알아보자.

SERVER 절에는 Tmax 가 관리하는 모든 응용 서버프로세스가 등록된다. 기본적으로 Tmax 시스템이 기동 될 때, 등록된 서버프로세스도 함께 기동 되어 동작하게 되며 Tmax 가 종료될 때, 서버 프로세스들도 함께 종료된다.

SERVER 절에는 다음과 같은 내용이 정의된다.

각 서버프로세스가 속하는 서버그룹

서버프로세스가 기동 될 때 필요한 명령어 라인 옵션

서버프로세스의 최소 개수와 최대 개수

동적 서버 프로세스 기동을 위한 큐 개수

대화형 모드 여부

재시작 가능 여부와 가능 횟수(장애대책 환경설정 참조)

이 밖에 SVRGROUP 절에서 정의한 다음 내용은 SERVER 절에 새롭게 정의할 수 있다.


SERVER 절의 기본 형식은 다음과 같다.

[DEFAULT : ]

Server 이름 SVGNAME=server-group-name

[,CLOPT=“literal“]


[,MIN=number]

[,MAX=number]

[,CONV=Y | N]

[,ASQCOUNT=number]

[,MAXQCOUNT=max-queue-count]

[,SVRTYPE=STD | UCS | UCS_LOAD |

TOPEND_STD | TOPEND_MGD | TOPEND_STDGW |

CUSTOM_GATEWAY |

REALSVR | REALSVR_MT |

CLIS | SYS_SVR ]


[,ULOGDIR=“user-log-path“]

[,RESTART=Y | N]

[,MAXRSTART=number]

[,GPERIOD=number]

[,TARGET=string]

[,AUTOTRAN= Y | (N)]

[,SCHEDULE = (FA)/RR]

필수 항목

서버이름= string


서버의 실행 파일 이름으로써, 일반적으로 서버 이름은 고유(unique)해야 한다. 즉, 하나의 서버 이름은 SERVER 절에 단 한번만 정의되어야 한다. 단, 멀티 도메인으로 구성할 경우에는 한 도메인 내에서 고유해야 한다.

SVGNAME = string


서버가 속해 있는 서버그룹을 정의한다.

여기에 사용되는 값은 반드시 SVRGROUP 절에서 정의된 서버그룹 이름이어야 한다. 서버와 SVRGROUP 절의 연결을 통해서 서버가 어떤 노드에서 동작할 것인지, 어떤 리소스 매니저(데이터 베이스)를 사용하는지 알 수 있으며, 해당 리소스 매니저를 열 때 필요한 파라미터를 넘겨 줄 수 있다.


XA 모드 하에서는 Tmax 가 모든 DB transaction 을 관리하고 two phase commit 을 보장한다. 위에서 설명 된 SVRGROUP 절은 OPENINFO 필드를 포함해서 정의되어야 한다. XA 모드의 Tmax 사용자는 각각 서버 프로세스의 DB 연결에 관여할 필요가 없다. 그러나 XA 모드가 아닌 경우에는, OPENINFO 를 포함하지 않은 SVRGROUP 절이 정의 되어야 하고 사용자는 DB 연결을 관리해야 한다.

선택 항목



CLOPT = literal

크기 : 255 자 이내

서버프로세스가 기동 될 때 그 서버프로세스로 전달되는 명령어 옵션들을 정의한다. 정의된 옵션들 중에 ‘--’이전에 지정된 옵션들은 시스템에서 사용하고, 그 이후에 지정된 옵션들은 사용자가 자유롭게 사용할 수 있다.

주로 사용되는 사용자 옵션들은 다음과 같다.

- l : 서버의 서비스 수행 결과를 log 로 남긴다. 로그는 $ULOGDIR svclog.mmddyyyy 라는 파일에 5 분 간격으로 저장된다. Tmax 는 로그내용을 분석하기 위한 svcrpt 라는 프로그램을 제공한다.

- -e : -e 파일명, standard error 를 저장한다 “서버프로세스명_파일명”의 파일이 생성되어 서버프로세스 동작 중에 발생하는 표준에러를 파일에 기록한다 표준에러는 fprintf(stderr, format, args) 함수를 사용하게 된다.

- -o : -o 파일명, standard output 을 저장한다. “서버프로세스명_파일명”의 파일이 생성되어 서버프로세스 동작 중에 발생하는 표준 출력을 파일에 기록한다.


표준출력은 일반적인 printf() 함수나 표준에러 출력과 마찬가지로 fprintf(stdout, format, args) 함수를 사용하면 된다.

MACRO Commands – 아래의 MACRO 를 지정했을 경우 파일 이름이 서버의 BOOT 시에 결정된다.

- $(SVR) – server name

- $(SVRI) – server index

- $(SPRI) – server process index

- $(SPRMIN) – MIN field of the server section

- $(SPRMAX) - MAX field of the server section

- $(SPRN) – server process sequential number( 0 - $(SPRMAX))

- $(DATE) – date of the MMDDYYYY format

- $(TIME) – time of the HHMMSS format

- $(PID) – process ID

예) CLOPT = “-e err1 –o out1 -- abc”

- ‘-e err1’ 은 서버프로세스(tpcals)가 동작하면서 발생한 표준 에러들을 ULOGDIR 디렉토리의 tpcals_err1 에 저장한다.

- ‘–o out1’ 은 서버프로세스(tpcals)가 동작하면서 발생한 표준 출력들을 ULOGDIR 디렉토리의 tpcals_out1 파일에 저장한다.

단, 표준 에러나 표준 줄력의 파일명을 다른 이름으로 하고자 할 경우에는 ‘-e /usr/tmax/log/ulog/test.log’ 형태로 절대 경로명을 지정하면 된다. ‘--’이후의 ‘abc’ 옵션은 사용자가 사용할 수 있도록 서버프로그램의 tpsvrinit() 함수에 argv[1]로 전달된다.

위에서 설명한 MACRO 는 다양한 종류의 로그파일(예:날짜별)을 작성하는데 사용한다. 예를 들어,


CLOPT=“-o $(SVR).$(DATE).out –e $(SVR).$(DATE).err” 는 [server name].03312001.out, [server name].03312001.err 의 ULOGDIR 필드에 정의된 디렉토리에 로그파일을 작성한다.

MIN = numeric (1)

범위: 1 ~ MAX_INT

기본적으로 기동 될 서버프로세스의 개수를 결정한다.

클라이언트 당 서버프로세스가 하나씩 기동 되는 일반적인 Client/Server 모델과 달리, Tmax 시스템에서는 서버프로세스의 수를 조절하여 일정하게 유지한다. CLH 프로세스는 클라이언트의 요청이 들어올 때마다 서버들의 상태를 확인하고, idle 상태인 서버 프로세스에게 일을 처리하도록 함으로써 시스템이 최대 성능을 발휘하도록 한다. MIN 항목은 이러한 서버프로세스의 개수를 조절하는 것으로써, 운영 경험을 통하여 적절한 개수 조정이 필요하다. 만약 아주 많은 서비스 요청이 들어오는 서비스에 대해 서버프로세스를 너무 적게 동작시킨다면 동작중인 서버프로세스 만으로는 즉각적인 서비스 처리가 어렵기 때문에 대기시간이 증가하는 등 시스템 성능이 떨어지게 된다. 반대로, 필요 이상으로 서버프로세스를 과다하게 기동 시켰다면, 단지 몇 개의 프로세스만이 서비스를 처리하고 나머지 프로세스는 idle 상태로 남게 되어 시스템 자원의 낭비와 더불어 성능 저하를 초래 할 수 있다. 따라서, 시스템 성능의 효율적 활용을 위하여 MIN 항목 값의 결정에 신중을 기해야 할 것이다.

MAX = numeric (1)

범위: 1 ~ MAX_INT

MIN 과 더불어 서버프로세스 개수를 결정하는 항목이다.

MIN 항목이 기본적으로 기동되는 서버프로세스 개수를 나타내고, MAX 항목은 MIN 값을 포함하여 추가적으로 기동시킬 수 있는 프로세스의 최대 개수이다. MAX 항목은 이미 동작 중인 개수를 포함하여 더 기동 시킬 수 있는 서버프로세스의 최대 개수를 의미한다. 다시


말해, 서버프로세스는 기본적으로 MIN 개수만큼 기동 되고, 갑자기 클라이언트의 요청이 집중되는 등의 부하가 많이 걸릴 경우, MAX 개수까지 서버프로세스가 기동 될 수 있다. MAX 항목도 MIN 항목과 같이 시스템의 성능에 영향을 주는 요인으로써 신중히 결정해야 한다. 포크 타입 서버 프로세스가 사용되었다면 MAX 값을 0으로 설정해야 한다.

CONV = Y / (N)

대화형 서버 여부를 나타낸다.

Tmax 에서 제공하는 통신 유형은 동기형, 비동기형, 대화형의 세가지가 존재한다. 대화형 통신을 제공하는 서비스는 해당 서버에 반드시 대화형 서버로 등록하여야 한다. 대화형 서버가 아닌 경우, 동기형이나 비동기형의 통신만을 제공하며 CONV 항목을 Y 로 정의함으로써 대화형 서버로 설정 된다.

ASQCOUNT = numeric (0)

범위: 1 ~ MAX_INT

자동으로 서버프로세스가 추가 기동 되기 위한 조건으로써 큐에 쌓여진 개수를 정의한다.

서비스 요청 건수가 큐에 ASQCOUNT 개수 이상 쌓이게 되면 MAX 개수 한도 내에서 서버프로세스가 자동으로 기동 된다. 지정되지 않은 경우, 큐에 쌓이는 것에 상관없이 서버프로세스는 자동으로 기동 되지 않는다. ASQCOUNT 로 증가된 서버 프로세스는 서비스 처리량을 검사하여 일정 시간 간격으로 사용하지 않는 프로세스를 내려 리소스 사용량을 줄인다. 이 항목은 서버 프로세스의 유형이 POD 일 경우에는 별 의미가 없기 때문에 사용하지 않는다.

MAXQCOUNT = numeric (0)

범위: 1 ~ MAX_INT

업무 폭주로 인하여 클라이언트의 요청이 큐에 적체되어 정상적인 서비스가 안되고 있는 경우, 계속되는 업무 요청을 무시할 때 설정하는 값이다


큐에 설정 값 이상의 업무가 요청된다면 해당 업무는 큐에 적체되지 않고 클라이언트에 즉시 에러(tperrno = 26)로 응답한다. 이 기능은 은행이나 관공서같이 특정 시간에 대량의 업무가 요청되는 곳에서 적체를 해소하기 위하여 적절하게 사용될 수 있다.

SVRTYPE = (STD) | UCS | UCS_LOAD | TOPEND_STD | TOPEND_MGD | TOPEND_STDGW | CUSTOM_GATEWAY | REALSVR | REALSVR_MT | CLIS | SYSSVR

서비스 프로세스의 타입을 지정하는 항목이다.

일반적인 모든 서비스 프로세스는 서비스 요청이 있을 시 관련 서비스 프로세스가 처리되어 결과를 전송하는 타입이나, UCS 타입의 서버 프로세스는 기본적으로 프로세스 내부에 Main() 부분이 존재하여 서비스 요청이 없어도 일방적으로 각 Client 에 맞는 데이터를 보낼 때 유용하게 사용할 수 있는 방식이다. 주식 시세 전망도 UCS 타입의 서버 프로세스의 한 예이다. UCS_LOAD 는 2 개 이상의 UCS 서버 프로세스가 구동 시, CLH 가 idle 한 프로세스를 먼저 수행하는 것이 아니라 SVRGROUP 절의 LOAD 항목에 설정한 대로 서버그룹 별로 부하를 조절하여 수행할 수 있도록 제어한다. REALSVR 는 지속적으로 변하는 데이터를 클라이언트에게 효율적이고 빠르게 전달하기 위해 UCS 타입의 프로세스를 커널 수준에서 개량한 RDP 타입의 서버 프로세스를 운용하고자 할 때 사용한다. 소량의 데이터를 다수의 클라이언트에게 자주 보낼 필요가 있을 때(초당 10 회 이상) 프로세스 점유율이나 처리 속도의 측면에서 UCS 에 비해 월등한 성능을 보인다. 한 노드에는 하나의 RDP 타입 서버만을 사용할 수 있다. 또한 multi threading 을 지원하는 REALSVR 이 REALSVR_MT 이다. TOPEND_STD, TOPEND_MGD, TOPEND_STDGW, CLIS 는 Topend 용이며, CUSTOM_GATEWAY 는 Hostlink 를 위한 것이고, SYS_SVR 은 RCA module 에서 사용하는 특별한 형식의 서버이다.

CPC = number (1)

범위: 1 ~ 128


UCS 서버프로세스와 CLH 프로세스 간의 병렬 통신 채널 수를 결정하는 항목이다. 서버프로세스의 처리량이 아주 많을 경우 CLH 프로세스와 하나의 채널로는 처리 속도가 저하될 때, 다중 채널을 두어 병렬통신으로 처리함으로써 처리속도를 증가 시킬 수 있다. CPC 는 UCS, CUSTOM_GATEWQY, REALSVR, REALSVR_MT 의 SVRTYPE 인 서버들에서만 유효하다.

RESTART = (Y) / N

서버프로세스의 재기동 여부를 결정하는 항목으로 비정상적인 종료 시 재기동 시킨다.

MAXRSTART, GPERIOD


TARGET = string

서버 이름은 서버 실행 파일의 이름인 데 비하여 TARGET 항목은 서버 프로세스의 이름을 재정의 하는 항목이다. 여기에서 말하는 서버 프로세스란 appdir 에 존재하는 서버 실행 파일들을 실행시킨 프로세스를 의미한다. 다음과 같이 TARGET 항목을 설정한 경우 tmadmin 은 실제 서버 이름을 확인하며 ps 를 통해 서버프로세스의 이름을 확인할 수 있다.

예) SVGNAME = svrgrp, MIN =1, MAX = 1, TARGET = svr2

/user1/starbj/tmax/sample/server> tmadmin

--- Welcome to Tmax Admin (Type "quit" to leave) --

-

$$1 tmaxs1 (tmadm): st -p

CLH 0:

---------------------------------------------------

svr_name svgname spr_no status count avg svc

---------------------------------------------------

SVR svrgrp 32 RDY 0 0 .00 -1

/user2/starbj/tmax/sample/server> ps

starbj 28702 1 0 11:13:03 pts/8 0:00 cll -b 28700

starbj 28704 1 0 11:13:03 pts/8 0:00 svr2


-b 28700 -S SVR -s SVR -d -1

starbj 28701 1 0 11:13:03 pts/8 0:00 tmm -b 28700

starbj 28703 1 0 11:13:03 pts/8 0:00 clh -b 28700

AUTOTRAN = Y / (N)

만약 mksvr 명령을 이용하여 서비스를 동적으로 추가하였을 경우 동적으로 추가된 서비스의 AUTOTRAN 은 디폴트 값인 N 으로 설정된다. 따라서 서버절의 AUTOTRAN 항목은 동적으로 추가된 서비스의 트랜잭션을 자동으로 시동할 수 있도록 하는 항목으로 서버의 AUTOTRAN 여부에 따라 동적으로 추가되는 서비스의 설정 값에 영향을 주게 된다. AUTOTRAN 항목은 서비스절 부분에서 자세하게 설명이 되어 있다. 만약 서버 절과 서비스 절 모두 AUTOTRAN 이 설정되어 있다면 서비스절의 AUTOTRAN 에 설정한 값이 적용된다.

SCHEDULE = (FA) / RR

SCHEDULE 항목은 MIN 값이 2 이상으로 지정된 경우 서버 프로세스 간의 처리 순서를 지정하기 위한 항목이다.

FA 는 First Available 의 약자로 번호가 우선하는 프로세스에 우선적으로 일을 할당한다. RR 은 Round-Robin 의 약자로, 모든 프로세스들이 고루 일을 처리하도록 한다.

SERVER 절의 사용 예

*SERVER

svr1 SVGNAME = svg1,

CLOPT = “-e err1 -o out1 -- svr1 1”,

MIN = 1,MAX= 10, CONV = N


CLOPT = “-e err1 -o out1 -- svr1 2”,

MIN = 1, MAX= 10,

CONV = N,

SVRTYPE = UCS,

CPC = 5


2.2.2.5 SERVICE 절

Tmax 시스템에서 제공하는 서비스를 등록하는 절이다.

서비스를 제공하는 서버프로세스가 동작 중이더라도 서비스가 환경파일에 등록되어 있지 않으면, 그 서비스는 처리될 수 없다. 따라서, 사용할 서비스는 반드시 SERVICE 절에 정의 되어야 한다.

각 서비스에 대해서는 다음과 같은 내용을 정의할 수 있다.

서비스가 제공되는 서버프로세스

서비스 우선순위

서비스 처리 제한 시간

라우팅 정보

SERVICE 절은 다음과 같은 형식으로 정의된다.

[DEFAULT : ]

서비스 이름 SVRNAME=server-process-name or gateway-name

[,PRIO=priority-value]

[,ROUTING = rout-name]

[,SVCTIME=timeout-value]

[,EXPORT= Y | N]

[,AUTOTRAN= Y | (N)]

필수 항목

서비스이름 = string

크기 : 15 자 이내의 string 으로 정의

서버프로그램 내의 함수 이름(서비스 루틴명)이 사용된다. 반드시 SERVICE 절 내에서 고유한(unique) 이름이어야 한다. 멀티 도메인 환경에서는 모든 도메인에서 unique 한게 좋다.

SVRNAME = string / literal


해당 서비스를 제공하는 서버프로세스를 지정한다.


해당 서비스 루틴을 가진 서버 프로그램의 실행파일 이름이 정의된다. 서버 프로세스는 SERVER 절에 정의되어 있어야 한다. 서버 프로세스에 특수문자가 있을 경우에는 “서버 프로세스명” 형태로 정의해야 한다. SERVICE 절에서 동일한 서버 프로세스명은 여러 번 나타날 수 있다. 즉 하나의 서버 프로세스에 여러 개의 서비스를 제공할 경우에는 각 서비스 마다 동일한 서버 프로세스명을 지정하는 경우이다. 멀티 도메인 환경설정 ‘을 참조한다

선택 항목



PRIO = priority-value (50)

범위: 1 ~ 100

클라이언트의 요구를 처리하는 우선순위 값이다.

각 서비스들 간의 우선순위를 나타내며, 높은 우선순위의 서비스를 낮은 우선순위의 서비스 보다 먼저 처리한다. 숫자가 클수록 높은 우선순위를 갖는다. 즉, 100 을 가장 먼저 처리한다.

ROUTING = route_name

이 필드는 데이터 관련 라우팅에 사용된다. 자세한 설명은 ‘부하조절 환경설정 ‘을 참조한다.

SVCTIME = numeric (0)

범위: 1 ~ MAX_INT

서비스 처리의 제한 시간이다.

각 서비스는 서비스 처리가 시작되는 순간부터 끝날 때까지 지정된 SVCTIME 시간 안에 처리되어야 한다. 만약, SVCTIME 이 초과하면 서버 프로세스는 서비스를 중지하고, 클라이언트에게 에러를 리턴한다. DOMAIN 절의 BLOCKTIME 항목이 클라이언트가


서비스를 요구하는 시점(tpcall()이나 tpacall()이 불려지는 시점)부터라면, SVCTIME 은 서버프로세스가 CLH 프로세스로부터 서비스 요청을 넘겨받아 서비스 루틴이 시작되는 시점부터 이다. 만일 이 값이 0 인 경우, 서비스 처리에 시간 제한이 없는 것으로 간주한다. <주의> SVCTIME 은 서버가 작동하고 있을 때에만 적용된다. 따라서 클라이언트가 요청한 서비스가 큐에 저장되어 있는 동안에는 SVCTIME 이 적용되지 않는다.

DB 세션을 사용중일 때 서비스 타임 아웃이 발생하는 경우 DB 와 연결된 세션을 일방적으로 완전히 끊을 수 없어 다음 서비스의 수행이 불가능해 지므로 Tmax 는 다른 방법을 사용하여 이 문제를 해결한다. 서비스 타임 아웃이 발생할 경우 사용자는 tpsvctimeout 루틴(Tmax Reference Manual 참조)에서 TPRETURN(TPEXIT, ...)를 이용하여 서버를 Reboot 해줄 수 있으며 이것은 SERVER 절에 정의한 MAXRSTART 횟수에 들어간다. 또한 윈도우 Tmax 는 XA 모드로 어플리케이션을 개발하는 것을 권장하며 non-XA 모드를 사용하는 경우는 이러한 일을 대비하여 RESTART 횟수를 충분히 해줄 필요가 있다.

EXPORT = (Y) | N

멀티 도메인 환경에서 게이트웨이를 통해 서비스를 요청 받았을 경우 서비스를 수행 할 것인지 여부를 정의한다.

EXPORT=N 으로 설정할 경우 다른 도메인에서 서비스를 요청하면 TPESECURITY 에러를 발생시킨다.

AUTOTX = Y | (N)

현재 버전에서는 사용되지 않는 옵션이다.

AUTOTRAN = Y | (N)

SERVICE 절에 속한 항목으로서 트랜잭션 모드가 아닌 상태에서 서비스가 요청 메시지를 받았을 때 트랜잭션을 자동으로 시동할지 여부를 정의한다.

Tmax 3.8.8 이전에 있던 AUTOTRAN 항목과는 약간의 차이점이 있다. 예전은 AUTOTRAN 을 설정하지


않더라도 기본적으로 AUTOTRAN=Y 로 설정되어 tx_begin 을 하지 않아도 트랜잭션을 시동하였으며 이 트랜잭션은 로컬 트랜잭션이었다. 그러나 Tmax3.8.8 에서 추가된 AUTOTRAN 은 이 항목이 설정되지 않은 경우 기본적으로 N 이 설정되어 트랜잭션을 자동으로 시동하지 않는다. 따라서 이 항목을 설정하지 않은 경우는 tx_begin 으로 트랜잭션을 명시적으로 시동시켜야 한다. 이 항목을 Y 로 설정한 경우 해당 서비스가 다른 서비스를 요청하면 이들은 모두 하나의 트랜잭션(글로벌 트랜잭션)으로 묶이게 된다. 이와 같이 Y 로 설정한 경우는 tx_begin 으로 트랜잭션을 명시적으로 시동시키면 에러(TPESVCERR)가 나게 된다.

다음은 환경 파일과 tmadmin 툴의 예제이다.

<< config.m>> *SVRGROUP

svg2 NODENAME = “tmax1”

### tms for Oracle ###

svg3 NODENAME = “tmax1”, DBNAME =

ORACLE,

OPENINFO =

“Oracle_XA+Acc=P/scott/tiger+SesTm=60”,

TMSNAME = tms_ora

*SERVER

svr2 SVGNAME = svg2

### servers for Oracle sample program###

fdltest SVGNAME = svg3

*SERVICE

### services for fdltest ###

FDLINS SVRNAME = fdltest

FDLSEL SVRNAME = fdltest

FDLUPT SVRNAME = fdltest

FDLDEL SVRNAME = fdltest

TOUPPER SVRNAME = svr2

<<tmadmin 툴의 예제>> tmax@tmax1;/user/tmax/tmax/config>tmadmin


--- Welcome to Tmax Admin (Type “quit” to leave) --

-

$$1 tmax1 (tmadm): cfg -s

-------------------------------------------------

svc_name prio(pr) autotran svctime(st)

routno svrname svgno

-------------------------------------------------

FDLINS 50 YES 0 -1

fdltest 2

FDLUPT 50 YES 0 -1

fdltest 2

FDLSEL 50 YES 0 -1

fdltest 2

FDLDEL 50 YES 0 -1 fdltest 2

TOUPPER 50 NO 0 -1 svr2 0

$$2 tmax1 (tmadm): q

ADM quit for node (tmax1)


서비스 절의 사용 예

* SERVICE

TOUPPER SVRNAME = svr1,

PRIO = 1,

SVCTIME = 60

TOLOWER SVRNAME = svr1,

PRIO = 2


2.2.2.6 GATEWAY 절

지금까지 소개된 DOMAIN 절, NODE 절, SVRGROUP 절, SERVER 절, SERVICE 절은 필수적인 절들이었으나 GATEWAY 절은 선택 절이다.

시스템이 수많은 노드로 구성되었을 경우, 모든 노드를 하나의 도메인으로 연결하였을 경우에는 전체 시스템의 관리가 어렵고, 노드간의 통신 트래픽이 심하여 시스템의 성능을 저하시킬 수 있다. 이러한 문제점을 해결하기 위하여 적정한 노드들을 하나의 도메인에 할당하고, 도메인간의 게이트웨이를 통하여 연결함으로써 시스템 성능을 향상시킬 수 있다.

즉, 클라이언트의 해당 서비스를 어떤 시스템이든 관계없이 처리할 수 있도록 등록하는 절이 바로 GATEWAY 절이다.

GATEWAY 절은 하나의 도메인에 여러 개를 지정하는 것이 가능하다. 그러나 하나의 노드에는 하나의 게이트웨이만을 지정할 수 있다.

GATEWAY 절은 필수적인 절은 아니며 필요에 따라 선택적으로 등록하는 절이다. 해당 절이 등록 되었을 경우에는 게이트웨이의 종류에 따라 적절한 프로세스가 수행된다.

GATEWAY 절에는 다음과 같은 내용이 정의된다.

게이트웨이 프로세스가 실행될 노드

게이트웨이간의 통신을 위한 TCP/IP 정보

게이트웨이 종류

GATEWAY 절의 기본 환경설정 형식은 다음과 같이 정의한다.

[DEFAULT : ]

Gateway 이름 NODENAME=“node-name”,

PORTNO=port-number,

RGWADDR=“remote-ip-addr”,

RGWPORTNO=remote-port-number,

GWTYPE={TMAX | TMAXNONTX | SNACICS | SNAIMS

| TCPCICS |TCPIMS | 1TUXEDO | OSITP | JEUS |

USER}

[,MAXINRGW=numeric(32)]



[,BACKUP=“gateway-name”]

[,BACKUP_RGWADDR=“remote-ip-addr”]

[,BACKUP_RGWPORTNO=remote-port-number]

[,TIMEOUT=second]

[,DIRECTION=(BIDIR) | IN | OUT]

[,CLOPT=string]

[,RESTART=Y|N]

[,MAXRSTART=number]

[,GPERIOD=number]

필수 항목

Gateway Name = string


게이트웨이에 대한 논리적인 이름으로써 GATEWAY 절 내에서 유일한 값이어야 한다.

NODENAME = literal


도메인내에서 게이트웨이 프로세스가 실행될 노드명을 지정하는 항목이다.

사용되는 NODENAME 은 NODE 절에서 정의한 노드 이름이어야 한다.

PORTNO = numeric

로컬 게이트웨이 프로세스가 사용하는 listen 포트번호이다. 이 포트번호는 리모트 게이트웨이 프로세스가 로컬 게이트웨이 프로세스와 연결할 때 사용한다. 이를 위해서 포트번호를 RGWPORTNO 항목에 등록해야 한다. 일반적으로 시스템영역에서는 1024 이내의 포트 번호를 사용하므로 관리자는 이 범위를 피해야 한다.

<주의> 포트번호는 게이트웨이 간의 통신에 사용되므로 이 값들이 다른 곳에서 사용되고 있는지의 여부를 반드시 확인해야 한다.


RGWADDR = literal


로컬 게이트웨이 프로세스가 접속하기를 원하는 리모트 게이트웨이의 프로세스가 실행되는 노드의 IP 주소나 노드명을 등록하는 항목이다.

노드명을 지정할 경우 그 노드명은 반드시 /etc/hosts 파일에 등록되어 있어야 한다. 로컬 게이트웨이 프로세스는 RGWADDR 항목의 IP 주소와 RGWPORTNO 항목의 포트번호를 이용하여 리모트 게이트웨이 프로세스와 접속한다.

RGWPORTNO = numeric

로컬 게이트웨이 프로세스가 리모트 게이트웨이 프로세스와 접속하기 위한 포트번호이다.

이 포트번호는 리모트 게이트웨이 프로세스에서 listen 하는 포트번호이다. 일반적으로 시스템영역에서는 1024 이내의 포트 번호를 사용하므로 관리자는 이 범위를 피해야 한다.

<주의> RGWPORTNO 는 게이트웨이 간의 통신에 사용되므로 이 값들의 사용 여부를 반드시 확인해야 한다.

GWTYPE = string

로컬 게이트웨이 프로세스가 접속할 리모트 게이트웨이의 종류를 지정하는 항목이다.

현재는 TMAX, TMAXNONTX, JEUS 의 세 가지만 지원하고 있다.

- TMAX : 리모트 시스템이 Tmax 시스템임을 지정한다.

- TMAXNONTX : 리모트 시스템이 Tmax 시스템이고 도메인간 트랜젹션을 사용하지 않을 경우 도메인간의 채널을 mulit-flexing 하여 CPC 의 효율을 증가시킨다. 하나의 요청이 결과를 받을 때


까지 채널을 점유하지 않으므로 응답시간의 향상과 리소스 사용량 감소등의 효과를 볼 수 있다.

- USER : entra gateway 를 위한 서버 타입

선택 항목



MAXINRGW = numeric (32)

범위: 1 ~ 128

멀티 도메인 환경에서 한 게이트웨이로 들어올 수 있는 채널의 개수를 지정한다.

TMAXNONTX 타입의 경우에만 사용 가능하며 이 항목을 정의하지 않으면 하나의 게이트웨이는 32 개의 도메인과 연결되어 서비스 요청을 받을 수 있다.

CPC = numeric (1)

범위: 1 ~ 128

게이트웨이 이용 시, 양 도메인의 CLH 프로세스 간 병렬통신 채널 수를 지정하는 항목 이다.

게이트웨이 프로세스가 처리량이 아주 많고 서비스의 소요시간이 길 경우 다중 채널을 두어 병렬통신으로 처리함으로써 처리속도를 증가 시킬 수 있다. TMAXNONTX 타입의 게이트웨이의 경우 2~3 개 이하의 CPC 로도 충분하다.

TIMEOUT = numeric (0)

범위: 1 ~ MAX_INT

도메인 간의 tpcall / tpacall 시 사용되는 timeout 값을 지정한다.

0(default)일 경우 TIMEOUT 에 제한이 없음을 나타내며 Gateway 는 다른 서버들과 달리 30 초 간격으로


타임아웃을 체크하므로 지연시간이 30 초 보다 작을 경우 TIMEOUT 항목이 적용 되지 않는다.

BACKUP = “gateway name”

범위: 7999 자 이내

주 게이트웨이의 문제 장애 시 백업 게이트웨이의 이름을 정의한다. 이 필드에 정의 된 값은 Tmax 환경파일의 GATEWAY 절에 정의된 값과 같아야 한다.

BACKUP_RGWADDR = “remote address”

범위: 255 자 이내

백업을 위해 로컬 게이트웨이 연결에 사용된 리모트 게이트웨이의 노드명이나 IP Address 를 정의한다.

IP address 대신 노드명이 정의되었다면 /etc/hosts 파일에도 정의되어있어야 한다.

BACKUP_RGWPORTNO = “remote-port-no”

백업을 위해 로컬 게이트웨이 연결에 사용된 리모트 게이트웨이의 포트번호를 정의한다.

이 것은 listening 하고 있는 리모트 게이트웨이의 포트번호이다. 일반적으로 시스템 영역에서는 1024 이내의 포트번호를 사용하므로 관리자는 이 범위는 피해야 한다.

<주의> BACKUP_RGWPORTNO 는 게이트웨이간의 통신에 사용되므로, 그 사용 여부가 먼저 확인 되어야 한다.

BACKUP, BACKUP_RGWADDR, BACKUP_RGWPORTNO 필드는 장애대책에 사용된다.

DIRECTION = (BIDIR) | IN | OUT

DIRECTION 은 GWTYPE 이 TMAX 와 TMAXNONTX 인 경우에만 유효한 항목으로 DIRECTION 이 BIDIR 일 경우 양방향 요청 처리가 모두 가능하며 IN 일 경우


상대편 Domain 에서 들어오는 요청만 처리가 가능하다. 자신의 Domain 에서 상대편 Domain 으로 나가는 요청에 대해서는 TPESECURITY 에러가 발생한다.

CLOPT = string

범위: 255 자 이내

Gateway 가 기동 될 때 그 Gateway 로 전달되는 명령어 옵션들을 정의한다.

정의된 옵션들 중에 ‘--’이전에 지정된 옵션들은 시스템에서 사용하고, 그 이후에 지정된 옵션들은 사용자가 자유롭게 사용할 수 있다.

주로 사용되는 사용자 옵션들은 다음과 같다.

- -r : -r Tmax Version Number 서로 다른 버전의 Tmax 시스템으로 이루어진 도메인 간의 연동이 가능하도록 하기 위해서 사용하는 옵션으로 상대방 도메인에 해당하는 Tmax 시스템의 엔진 버전을 xxyyzz 의 6 자리 형식으로 지정해준다. (ex – Tmax 3.8.15 : 030815) 이 옵션을 지정하게 되면 상대편 도메인에 해당하는 Tmax 시스템의 엔진버전에 따라서 Gateway 의 기능이 달라지게 된다. 현재 다음 각 분류별(Tmax 버전)로 XA 관련 동작이 다른데 상대편 도메인에 해당하는 Tmax 시스템의 엔진 버전이 현재 버전과 다른 부류에 속한다면 반드시 –r 옵션을 지정해야 한다.

분류 Tmax Version Number

1

2

3

2.0 ~ 3.8.7

3.8.8 ~ 3.8.13.

3.8.14 이후

- -L : -L logdir 로그 디렉토리를 지정하는 옵션으로 GWTYPE 이


JEUS 일 때만 사용 가능하다. 실제로 생성되는 로그 파일은 logdir/JTXLOG 이다.

- -l : -l logsize -L 옵션과 함께 사용되며 로그 파일의 최대 사이즈를 지정하며 단위는 KB 이다. 최대 2047 KB 까지 만들 수 있다.

RESTART = (Y) | N

GATEWAY 절에 지정하였을 경우 해당 GATEWAY 프로세스 재기동 여부를 결정하는 항목으로 비정상적인 종료 시 재기동 시킨다.

MAXRSTART, GPERIOD


GATEWAY 절의 사용 예

*GATEWAY

gw1 NODENAME = “tmax1”,

PORTNO = 2222,

RGWADDR = “192.168.23.1”,

RGWPORTNO = 2225,

GWTYPE = TMAX,

CPC = 10, CLOPT=”-r 030815”

2.2.2.7 ROUTING 절

ROUTING 절은 한 도메인 안에서 노드간에, 또는 멀티 도메인 환경에서 도메인간에 데이터에 따른 라우팅 환경을 설정하기 위해서 필요한 절로써, 이에 대한 내용은 ‘부하조절 환경설정’’의 ‘데이터에 따른 부하조절 ’부분에서 자세히 설명하기로 한다.

2.2.2.8 RQ 절

RQ 절도 ROUTING 절과 같이 선택적으로 정의하는 절로써 이에 대한 내용은 ‘신뢰성 큐 환경설정 ‘에서 자세히 설명하기로 한다.


2.2.2.9 기본 환경설정의 예

다음은 기본적인 Tmax 환경파일의 예이다:

*DOMAIN

res SHMKEY = 77990, MAXUSER = 300, MINCLH = 3,

MAXCLH = 5, TPORTNO = 8899, BLOCKTIME = 60

*NODE

tmax1 TMAXDIR=“/home/tmax”,

APPDIR=“/home/tmax/appbin”,

PATHDIR=“/home/tmax/path”,

SLOGDIR=“/home/tmax/slog”,

ULOGDIR=“/home/tmax/ulog”,

ENVFILE=svr_env

tmax2 TMAXDIR=“/system/tmax”,

APPDIR=“/system/tmax/server”,

SLOGDIR=“/system/tmax/slog”,

ULOGDIR=“/system/tmax/ulog”,

ENVFILE = app_env

*SVRGROUP



svg3 NODENAME = tmax2, cousin = svg4


*SERVER

svr1 SVGNAME = svg1, CLOPT=“-e err1 -- apple”, MIN=3,

MAX=5

svr2 SVGNAME = svg2, MIN=4, MAX=5


CLOPT = “-e $(SVR).$(DATE).err –o

$(SVR).$(DATE).out”

*SERVICE

svc1 SVRNAME = svr1, PRIO=100, SVCTIME=40

svc2 SVRNAME = svr2

svc3 SVRNAME = svr3


2.2.3 Database 환경설정

데이터베이스에 연관된 서비스를 제공하는 경우, 환경파일에 데이터베이스 정보를 등록할 수 있다.

데이터베이스 정보를 등록함으로써, 응용프로그램에서 처리하는 데이터베이스 Open/Close 등 리소스 매니저와의 연결 및 해제가 Tmax 시스템에 의해서 관리되며, 분산트랜잭션 처리도 가능하게 된다(‘분산트랜잭션 환경설정 ’ 참조) .

데이터베이스 환경설정에서 서버그룹은 중요한 의미를 갖는다. 서버프로세스들이 존재하는 노드도 서버그룹을 형성하는 요소가 되지만, 동일한 노드에 존재하는 서버프로세스일지라도 사용하는 데이터베이스의 종류에 따라 서버그룹이 구분된다.

한 서버그룹 내의 서버프로세스들은 반드시 동일한 데이터베이스(DBMS)를 사용해야 한다. 만일 사용하는 데이터베이스(DBMS)가 다르다면, 같은 서버그룹이 될 수 없다. 즉, 서버그룹은 데이터베이스 관리의 기본 단위가 된다.

이러한 데이터베이스 관리를 위해서는 TMS(Transaction Management Server)라는 Tmax 기능 프로세스가 필요하다. TMS 프로세스는 데이터베이스 관리가 필요할 경우, 서버그룹별로 기동 되어 각 서버그룹의 데이터베이스 관리와 다음 장에 설명될 트랜잭션 처리를 담당하는 서버프로세스이다.(그림 2-16)

트랜잭션 처리를 담당하는 TMS 프로세스의 기능에 대해서는 다음 장의 ‘분산트랜잭션 환경설정’에서 다루어진다.

이러한 데이터베이스 정보 등록을 위한 환경설정은 모두 SVRGROUP 절에서 다루어진다..


그림 9 데이터베이스 관리를 위한 TMS Process


Tmax 의 데이터베이스 관리 기능을 제공받기 위해서는 서버그룹이 사용하는 데이터베이스의 Open/Close 정보와 그 서버그룹과 관련된 TMS 프로세스에 대한 정보가 필요하다.

데이터베이스 환경설정과 관련하여 SVRGROUP 절에 정의하는 항목들은 다음과 같다:

Server Group Name [,DBNAME=DBMS-name]

[,OPENINFO=DBMS-open-information]

[,CLOSEINFO DBMS-close-information]

[,TMSNAME=TMS-process-name]

[,MINTMS=TMS-process-min-number]

[,MAXTMS= TMS-process-max-number]

SVRGROUP 절의 데이터베이스 환경 설정

DBNAME = string

크기:63 자 이내


사용하는 데이터베이스 명을 기술한다.

따라서 이 항목에 사용되는 값은 ORACLE, INFORMIX, SYBASE 등의 DBMS 이름이다.

OPENINFO = string


서버그룹과 관련된 데이터베이스 정보를 등록하는 항목이다.

앞에서도 언급했듯이, 같은 리소스 매니저 즉, 같은 데이터베이스를 사용하는 경우 한 서버그룹으로 관리함으로써 자원(resource)의 효율을 높이고 분산트랜잭션 처리를 가능하게 할 수 있다. OPENINFO 형식은 리소스 매니저를 제공하는 벤더, 즉 오라클이나 인포믹스등 데이터베이스의 종류에 따라 다르다.

- 오라클 데이터베이스(Oracle DBMS) OPENINFO=“Oracle_XA+Acc=P/scott/tiger+SesTm=60” “Oracle_XA”는 오라클 데이터베이스 XA 인터페이스를 의미하며, “Acc=P/scott/tiger”의 부분은 오라클 데이터베이스에 접근하기 위한 계정과 암호를 뜻한다.

- 인포믹스 데이터베이스(Informix DBMS) OPENINFO= Database Name 인포믹스 데이터베이스의 OPENINFO 의 값은 단순히 데이터베이스명만 요구하므로 오라클과 같이 복잡하지 않다.

- 그 외 다른 데이터베이스는 해당 데이터베이스의 매뉴얼을 참조하여 등록하여야 한다.

CLOSEINFO = literal (NULL)


CLOSEINFO 항목은 리소스 매니저가 데이터베이스를 닫을 때 필요한 정보를 지정한다.


보통 생략되거나 NULL 로 정의된다. 인포믹스 데이터베이스에서는 반드시 널 문자열(““)로 지정해야 하며, 오라클 데이터베이스에서는 생략해도 된다.

@ Examples of OPENINFO/CLOSEINFO

<<Oracle 을 사용하는 서버그룹의 예>> *SVRGROUP

svg1 NODENAME = tmax1,

DBNAME = ORACLE,

OPENINFO = “Oracle_XA+Acc =

P/scott/tiger+SesTm= 60”

<<Informix 를 사용하는 서버그룹의 예>>

*SVRGROUP

svg2 NODENAME = tmax2,

DBNAME = INFORMIX,

OPENINFO = “test”,

CLOSEINFO = ‘’’’

TMSNAME = string


TMSNAME 은 해당 서버그룹의 데이터베이스 관리를 담당할 TMS 프로세스 이름을 정의한다

데이터베이스의 open 정보(OPENINFO 항목)를 등록한 경우에는 반드시 TMSNAME 에 대한 정의가 필요하다. TMS 프로세스는 데이터베이스와 관련된 시스템에서 해당 서버그룹의 데이터베이스 관리를 담당하기 위하여 반드시 필요하다. 그러므로 Tmax 시스템에서 데이터베이스를 관리하도록 하기 위해서는 데이터베이스의 Open/Close 정보를 등록하고, 서버그룹별로 반드시 TMSNAME 을 정의하여 TMS 프로세스를 기동 시켜야 한다. TMS 프로세스는 데이터베이스와 연동하는 XA 로 업무(transaction)를 처리하는 트랜잭션 매니저이다. 이 프로세스는 $TMAXDIR/lib 에 있는 libtms.a 와 SVRGROUP 절에 있는 DBNAME 의 데이터베이스 라이브러리를 연결하여 생성된다.


MINTMS = numeric (2)

범위: 1 ~ 10

해당 서버그룹의 TMS 프로세스 기동 개수를 정의한다. TMS 개수는 데이터베이스 관리보다는 트랜잭션 관리에 영향을 주는 요소이다. Default 로는 서버그룹 당 2 개가 기동 되는데, 데이터베이스 관리만을 원할 경우 한두 개의 TMS 로 충분히 관리가 가능하다.

MAXTMS = numeric (3)

범위: 1 ~ 10

동적으로 더 기동 시킬 수 있는 TMS 프로세스 개수를 정의한다.

자세한 내용은 ‘분산트랜잭션 환경설정 ‘부분에서 설명하기로 한다.

2.2.3.2 Database 환경설정의 예

다음은 기본적인 환경설정에 데이터베이스 환경설정 내용이 추가된 Tmax 환경파일의 예이다.

*DOMAIN

res SHMKEY = 77990, MAXUSER = 300 , MINCLH = 3 ,

MAXCLH = 5 , TPORTNO = 8899, BLOCKTIME = 60

*NODE

tmax1 TMAXDIR = “/home/tmax” ,

APPDIR=“/home/tmax/appbin”,

PATHDIR=“/home/tmax/path”,

SLOGDIR=“/home/tmax/slog”,

ULOGDIR=“/home/tmax/ulog”,

TLOGDIR=“/home/tmax/tlog”

tmax2 TMAXDIR=“/system/tmax”,

APPDIR=“/system/tmax/server”,

SLOGDIR=“/system/tmax/slog”,

ULOGDIR=“/system/tmax/ulog”,

TLOGDIR=“/system/tmax/tlog”,

ENVFILE=app_env


*SVRGROUP

svg1 NODENAME=tmax1, DBNAME=ORACLE,

OPENINFO=“Oracle_XA+Acc=P/scott/tiger+SesTm=60”,

TMSNAME=ora_ tms, MINTMS=3, MAXTMS=5

svg2 NODENAME=tmax2, DBNAME=INFORMIX,

OPENINFO=“infodb”,TMSNAME=info_tms, CLOSEINFO=““

*SERVER

svr1 SVGNAME = svg1 , CLOPT=“-e err1 -- apple”, MIN=3,

MAX=5

svr2 SVGNAME = svg2 , MIN = 4 , MAX = 5


CLOPT = “-e $(SVR).$(DATE).err –o

$(SVR).$(DATE).out”

*SERVICE

svc1 SVRNAME = svr1 , PRIO=100, SVCTIME=40

svc2 SVRNAME = svr2

svc3 SVRNAME = svr3

2.2.4 분산트랜잭션 환경설정

분산트랜잭션 처리는 TP(Transaction Processing) 모니터의 주요기능 중의 하나이다.

분산트랜잭션 처리란, 하나 이상의 이기종 데이터베이스 시스템과 관련된 여러 개의 트랜잭션들을 하나의 전역트랜잭션(global transaction)으로 묶어서 처리하는 것을 말한다. 이러한 분산트랜잭션 기능을 제공받고자 할 경우 기본적으로 데이터베이스 환경설정이 필요하다. 분산트랜잭션 처리를 위해서는 각 서버그룹별로 TMS 프로세스가 기동 되어 다음과 같은 구조를 형성한다.


그림 10 분산 트랜잭션 관리를 위한 구조

CLH 는 분산트랜잭션과 관련된 서비스 요청을 받을 경우에는 서비스별로 하위 트랜잭션의 commit/rollback 여부를 관리한다. 따라서, 하나의 분산트랜잭션과 관련된 하위 트랜잭션들이 모두 commit 이 가능할 때 그 분산트랜잭션을 commit 처리하고, 하나라도 rollback 처리되는 경우 전체를 rollback 처리함으로써 분산트랜잭션을 지원한다. 실질적으로 데이터베이스를 갱신(update)하는 commit, rollback 처리는 각 서버그룹의 TMS 프로세스가 담당한다. 이러한 분산트랜잭션을 위한 환경설정은 DOMAIN, NODE, SVRGROUP 절을 통해 이루어진다.

2.2.4.1 DOMAIN 절

DOMAIN 절에는 분산트랜잭션과 관련하여 2PC(Two Phase Commit) 가능 여부와 트랜잭션 타임아웃(timeout) 시간을 설정할 수 있다.


데이터베이스 환경설정과 관련하여 DOMAIN 절에 정의하는 항목들은 다음과 같다.

도메인 이름 [,CMTRET=Y | N] [,TXTIME=transaction-timeout-value]

DOMAIN 절의 분산 트랜잭션 환경설정

CMTRET = (Y) | N

Two Phase Commit 여부를 결정한다

2PC 란, 준비(prepare)와 실행(commit/rollback)의 2 단계 트랜잭션 처리를 거치는 것을 말하며, Tmax 에서는 분산트랜잭션 구현을 위한 2PC 를 지원한다.

- 1 단계(preparation) : 하나의 트랜잭션과 관련하여 각각의 데이터의 관리 서버들에게 해당 트랜잭션의 정상 처리 여부(commit 또는 rollback)를 확인 한다

- 2 단계(commit/rollback) : 1 단계의 결과를 토대로 관련된 모든 트랜잭션이 정상 처리되면 commit 을, 하나라도 불가능하면 rollback 시킨다.

Tmax 에서는 2PC 에 대하여 두 가지 방법을 지원한다.

- 첫번째로는 1, 2 단계를 거쳐 commit 처리 하고 rollback 에 대한 완전한 로깅(logging)이 이루어진 후 서비스를 반환(complete return)하는 것이고, 두 번째는 보다 빠른 처리를 위하여 2 단계에서 commit/rollback 명령만 지시하고 서비스를 반환하는 것이며 시스템 환경에 따라 선택적으로 지정 가능하다. <그림 11 참조>

- CMTRET 항목은 이러한 complete return 에 대한 내용을 결정하는 것으로써, Y 는 complete return 을 의미하고 N 인 경우 빠른 처리를 위하여 commit/rollback 명령 후에 즉시 서비스를 반환하게 된다. 디폴트 값은 Y 이다.

TXTIME = numeric (0)

- 범위: 0 ~ MAX_INT


- 트랜잭션 처리 제한시간(timeout)을 결정한다. 즉, tx_begin()의 트랜잭션 시작에서부터 tx_commit()이나 tx_rollback()으로 트랜잭션이 끝날 때까지의 시간으로써, TXTIME 이 지나면 자동으로 rollback 처리된다.

그림 11 Two-phase-commit

2.2.4.2 NODE 절

NODE 절에서는 분산트랜잭션 환경설정과 관련하여, 각 노드의 트랜잭션 처리 기록(logging)에 사용되는 파일을 정의할 수 있다.

데이터베이스 환경설정과 관련하여 NODE 절에 정의하는 항목들은 다음과 같다.

노드이름 [,TLOGDIR=transaction-log-path]

NODE 절의 분산트랜잭션 환경설정

TLOGDIR = literal (TMAXDIR)



트랜잭션 처리 시, 장애가 발생하면 Recovery 를 위해 트랜잭션처리에 대한 로깅 (logging)이 필요하다. TLOGDIR 은 이러한 트랜잭션 정보가 저장될 파일을 지정한다.

로그 파일은 일반 파일로 저장된다. Tmax 는 로그 파일 저장 시 raw file 을 지원하지 않는다. 트랜잭션 처리가 많지 않은 경우에는 TLOGDIR 에 정의된 일반 파일을 사용하고, 이 때 TLOGDIR 에는 임의의 파일명을 정의한다. 반대로 트랜잭션 처리가 많은 경우에는 response time 을 단축시키기 위해 UNIX 파일 시스템을 거치지 않고, 정의된 raw 파일을 사용하여 TLOGDIR 에 device 명을 직접 디스크에 기록하며, 여기에 정의된 device 는 트랜잭션 로깅(logging)을 위해서만 사용한다.

<주의> 정의된 경로는 사용중인 시스템에 있는 것이어야 한다.

예 )

- TLOGDIR = “/home/tmax/log/tlog” TLOGDIR 경로의 로그 파일은 일반 사용자들이 읽지 못하는 바이너리(binary)형태로 저장되어있다. 트랜잭션과 관련된 데이터베이스 로그는 서버그룹 절의 OPENINFO 에 있는 trace flag 를 정의하여 저장할 수 있다.

- OPENINFO = “Oracle_XA+Acc=P/scott/tiger+SesTm = 60, DbgFl=0x01 + LogDir=/tmp” 위의 명령어는 /tmp 디렉토리에 xa_NULLmmdd.trc 파일을 작성할 것이다.


SVRGROUP 절에서는 데이터베이스에 대한 환경설정이 이루어진다. 관련된 항목들은 ‘데이터베이스 환경설정’(1.3 장 참조)에 자세히 설명되어 있다. 단, 이중에서 MINTMS 와 MAXTMS 는 트랜잭션 처리와 관련되어 주의를 요하는 항목들이다.

주요 항목


DBNAME = string

사용하는 데이터베이스명

OPENINFO = literal

데이터베이스의 open 정보 등록

CLOSEINFO = literal (NULL)

데이터베이스의 close 정보 등록

TMSNAME = string

TMS 프로세스의 이름

MINTMS = numeric

TMS 프로세스의 최소 개수

데이터베이스 관리만을 위해서는 TMS 프로세스 개수가 중요하지 않지만, 트랜잭션 처리 시에는 매우 중요하다. 단순히 한두 개로 TMS 프로세스 개수가 고정되어 있다면, 트랜잭션 처리량이 많은 서버그룹의 경우 commit/rollback 처리에 상당한 부하를 초래할 수 있다. 따라서 처리속도와 리소스 관리를 위해 적절한 개수의 TMS 를 기동 시키는 것이 중요하다.

MAXTMS = numeric

TMS 프로세스의 최대 개수

동적으로 더 기동 시킬 수 있는 TMS 프로세스의 개수를 정의한다. 트랜잭션 처리량이 많아질 경우, MAXTMS 개수가 넘지 않는 범위 내에서 TMS 프로세스를 더 기동 시킬 수 있다.

다음은 분산트랜잭션 환경설정과 관련된 Tmax 환경파일 예이다.

*DOMAIN

res SHMKEY = 77990, MAXUSER = 300 , MINCLH = 3 ,

MAXCLH = 5 , TPORTNO = 8899 , BLOCKTIME = 6 0 ,

CMTRET = N , TXTIME = 5 0


*NODE tmax1 TMAXDIR = “/home/tmax”, APPDIR= “/home/tmax/appbin”, PATHDIR = “/home/tmax/path”,

SLOGDIR=“/home/tmax/log/slog”, ULOGDIR=“/home/tmax/log/ulog”, TLOGDIR = “/home/tmax/log/tlog “

tmax2 TMAXDIR=“/system/tmax”, APPDIR=“/system/tmax/server”, SLOGDIR=“/system/tmax/slog”, ULOGDIR=“/system/tmax/ulog”, TLOGDIR=“/system/tmax/log/tlog”

*SVRGROUP svg1 NODENAME=tmax1, DBNAME=ORACLE , OPENINFO= “Oracle_XA+Acc=P/scott/tiger+SesTm=60, DbgFl=0x01 + LogDir=/tmp”, TMSNAME=ora_tms, MINTMS=3, MAXTMS=5

svg2 NODENAME=tmax2, DBNAME = INFORMIX, OPENINFO=“infodb”, CLOSEINFO=““, TMSNAME=info_tms, MINTMS=3, MAXTMS=5 svg3 NODENAME = tmax2 *SERVER svr1 SVGNAME = svg1, CLOPT=“-e err1 -- apple”, MIN=3, MAX=5 svr2 SVGNAME = svg2, MIN=4, MAX=5, CLOPT = “-e $(SVR).$(PID).err –o $(SVR).$(PID).out” svr3 SVGNAME = svg3 CLOPT = “-e $(SVR).$(DATE).err –o $(SVR).$(DATE).out” *SERVICE svc1 SVRNAME = svr1, PRIO=100, SVCTIME=40 svr2 SVRNAME = svr2 svc3 SVRNAME = svr3

2.2.5 부하조절 환경설정

클라이언트의 서비스 요구가 집중될 경우, 최적의 시스템 성능과 자원 활용을 보장할 수 있다. 부하조절에는 다음의 3 가지 방법이 있다.

시스템 성능에 따른 부하조절(System Load Management : SLM)


노드의 성능이나 시스템 상황에 따라 노드별로 서비스 처리량을 조절하는 것이다

데이터에 따른 부하조절(Data Dependent Routing : DDR)

데이터의 범위에 따라 노드별로 서비스를 나누어 처리하는 것이다.

동적 부하조절(Dynamic Load Balancing : DLM)

특정 노드에 부하가 집중되는 경우 부하를 분산하여 전체 시스템의 처리량을 극대화하는 것이다.

2.2.5.1 시스템 성능에 따른 부하조절

노드의 성능이나 시스템 상황에 따라 노드별로 서비스 처리량을 달리 하는 것이다.

이와 같은 부하조절이 가능하기 위해서는 한 서비스가 여러 노드에서 지원되어야 한다. 시스템 로드는 서버그룹별로 설정된다.

그림 12 시스템 로드에 따른 부하조절

SVRGROUP 절


시스템 성능에 따른 부하조절 환경설정과 관련하여 SVRGROUP 절에 정의하는 항목들은 다음과 같다.

SVRGROUP 이름 [,COUSIN=(“group-name”)]

[,LOAD=load-value]

SVRGROUP 절의 성능에 따른 부하조절 환경설정

COUSIN = literal


2 개 이상의 노드에서 부하조절 기능을 사용하는 경우에 서버그룹의 이름을 지정하는 항목이다

각 서버그룹의 이름은 SVRGROUP 절에 등록된 것이어야 한다. 기본적으로 Tmax 시스템의 부하조절 기능은 서버그룹 단위로 이루어 진다. 그러나 부하조절이 다수의 노드에 걸쳐 이루어지는 경우 해당 노드명은 각각의 서버그룹에 다르게 설정되어야 하며 이때 노드명은 반드시 환경파일의 NODE 절에 등록된 것이어야 한다. 멀티 노드로 부하조절을 하는 경우 원래의 서버그룹의 환경과 내용들은 COUSIN 절에 설정된 서버그룹의 노드들로 복사되며 이때 COUSIN 서버그룹들이 속하는 노드명은 각각 서로 달라야 한다. 다수의 서버그룹을 정의할 경우는 콤마(,)로 분리하여 정의한다. (각 노드의 APPDIR 에는 필요한 서버 프로그램이 존재해야 한다.)NODE 의 성능에 따라 부하조절을 할 필요가 있을 경우에는 각 서버그룹에 부하조절을 위한 로드값을 설정해야 한다(LOAD 항목 참조). 이렇게 복사된 서버그룹에서는 원본 서버그룹에서 제공하는 서버와 서비스들이 모두 제공된다. 복사 서버그룹의 서버그룹과 서버의 환경은, 기본적으로 원본 서버그룹의 서버그룹과 서버환경을 그대로 따른다. 만일 서버환경을 변경하고자 하는 경우 이와 관계된 서버그룹이나 서버의 모든 관련 항목들을 재정의 하여야 한다. 복사된 서버그룹 내의 서비스가 원본과 다른 독립적인 환경을 가질 수 없으며, 반드시 원본 서버그룹의 서비스와 동일한 환경을 갖게 된다. 서버그룹의 재정의 가능 항목은 다음과 같다 DBNAME, OPENINFO, CLOSEINFO, MINTMS, MAXTMS,


TMSNAME, SECURITY, OWNER 예를 통해 자세한 내용을 살펴보자 그림 13 은 서버그룹의 복사가 이루어진 DOMAIN 의 상황을 나타낸 것이고, 그림 14 은 이에 대한 환경파일 예이다. 이를 보면, 우선 NODE1 의 SVG1(원본 서버그룹)이 NODE2 와 NODE3 에 각각 복사되어 있다 (그림 2-23 의

). 또한 시스템 로드에 의한 부하조절을 위해 각각의 LOAD 값이 설정되어 있다. NODE2 와 NODE3 에서는 원본 서버그룹 SVG1 의 서비스 SVC_A, SVC_B(이상 서버 SVR1 제공), SVC_C(서버 SVR2 제공)가 모두 지원된다. NODE2 의 경우, NODENAME 과 LOAD 항목 이외는 정의되어 있지 않으므로(그림 14 의 ), 원본 서버그룹인 SVG1 의 DBNAME, OPENINFO, TMSNAME, MINTMS 항목에 설정된 내용이 동일하게 적용된다. 그러나 SVG3 을 보면 DBNAME, OPENINFO, CLOSEINFO 항목이 인포믹스 환경으로 정의되어 있고, TMS 프로세스의 이름도 다르다. (그림 14 의 )

.


그림 13 서버 그룹 복사

따라서 NODE3 은 원본 서버그룹의 DBNAME, OPENINFO, CLOSEINFO, TMSNAME 과 달리 자신만의 환경을 갖는다. 단, 생략되어 있는 MINTMS 값은 SVG1 처럼 3 이 적용된다.

LOAD = numeric (1)

범위: -1 ~ MAX_INT

서버그룹의 서비스 처리능력을 의미한다. 값이 클수록 처리능력이 높음을 나타낸다.

서비스 처리 능력이 탁월한 노드에 대해서는 LOAD 값을 크게 설정하며, 반대로 노드의 성능이 저하된다면 작은 LOAD 값을 설정해야 한다.


이와 같은 시스템 로드에 따른 부하조절을 원한다면, COUSIN 항목 설정으로 서버그룹을 복사한 후 각각의 서버그룹에 적절한 LOAD 값을 설정하면 된다. 만약, 노드별 분산처리를 원하지 않는다면 LOAD 값을 -1 로 설정하면 된다. 자동 부하분산은 LOAD 값을 설정하지 않거나 0 으로 설정하면 되며 시스템 부하에 따라 자동적으로 서비스 요청이 분산된다.

svrgroup 복사를 위한 Tmax 환경 파일 설정의 예

*DOMAIN

site1 SHMKEY = 77990, MAXUSER=400,

MAXCLH = 5, TPORTNO = 8899, BLOCKTIME = 60,

CMTRET = N, TXTIME = 50

*NODE

NODE1 TMAXDIR = “/home/tmax”,

APPDIR= “/home/tmax/appbin”,


SLOGDIR=“/home/tmax/log/slog”,

ULOGDIR=“/home/tmax/log/ulog”,

TLOGDIR = “/home/tmax/log/tlog “

NODE2 TMAXDIR=“/system/tmax”,

APPDIR=“/system/tmax/appbin”,

SLOGDIR=“/system/tmax/log/slog”,

ULOGDIR=“/system/tmax/log/ulog”,

TLOGDIR=“/system/tmax/log/tlog”

NODE3 TMAXDIR=“/system/tmax”,

APPDIR=“/system/tmax/appbin”,

SLOGDIR=“/system/tmax/log/slog”,

ULOGDIR=“/system/tmax/log/ulog”,

TLOGDIR=“/system/tmax/log/tlog”

*SVRGROUP

SVG1 NODENAME = NODE1, COUSIN=“SVG2,SVG3”……..①

LOAD = 3 , DBNAME=ORACLE,

OPENINFO=

“ORACLE_XA+Acc=P/scott/tiger+SesTm=60”,

TMSNAME=tms1, MINTMS=3

SVG2 NODENAME = NODE2, ……..②

LOAD = 2

SVG3 NODENAME = NODE3, ……..③

LOAD = 1, DBNAME=INFORMIX ,


OPENINFO=“infodb”, CLOSEINFO=““,

TMSNAME= tms2

......

*SERVER

SVR1 SVGNAME = SVG1, MIN=5 , MAX=10

SVR2 SVGNAME = SVG1

......

*SERVICE

SVC_A SVRNAME=SVR1

SVC_B SVRNAME=SVR1

SVC_C SVRNMAE=SVR2

그림 14 SVRGROUP 복사를 위한 멀티 노드에서의 Tmax 환경파일

*DOMAIN

site1 SHMKEY = 77990, MAXUSER=400,

MAXCLH = 5, TPORTNO = 8899, BLOCKTIME = 60,

CMTRET = N, TXTIME = 50

*NODE

NODE1 TMAXDIR = “/home/tmax”,

APPDIR= “/home/tmax/appbin”,


SLOGDIR=“/home/tmax/log/slog”,

ULOGDIR=“/home/tmax/log/ulog”,

TLOGDIR = “/home/tmax/log/tlog “

*SVRGROUP

SVG1 NODENAME = NODE1, COUSIN=“SVG2”

LOAD = 3 , DBNAME=ORACLE,

OPENINFO =

“ORACLE_XA+Acc=P/scott/tiger+SesTm=60”,

TMSNAME=tms1, MINTMS=3

SVG2 NODENAME = NODE1, LOAD = 2

......

*SERVER

SVR1 SVGNAME = SVG1, MIN=5 , MAX=10

SVR2 SVGNAME = SVG1

......

*SERVICE

SVC_A SVRNAME=SVR1

SVC_B SVRNAME=SVR1

SVC_C SVRNMAE=SVR2


그림 15 SVRGROUP 복사를 위한 단일 노드에서의 Tmax 환경파일

2.2.5.2 데이터값에 따른 부하조절

Tmax 시스템에서는 데이터 값에 따라 부하조절 기능을 제공한다. 데이터 값에 따른 부하조절(Data Dependent Routing: 이하 DDR 이라고 칭함)이란 데이터의 범위에 따라서 서비스가 처리될 서버그룹을 다르게 지정하여 분산처리 및 부하조절이 이루어지도록 하는 것이다. 라우팅은 STRUCT, X_C_TYPE, X_COMMON 형 버퍼나 필드버퍼를 사용하는 서비스에 대해서만 지정이 가능하다. 데이터값 의존형 라우팅을 하기 위해서는 SVRGROUP 절에 서버그룹 환경 복사에 대한 환경설정과 SERVICE 절과 ROUTING 절의 라우팅에 대한 환경설정이 필요하다.

SVRGROUP 절

DDR 환경설정과 관련하여 SVRGROUP 절에 정의하는 항목들은 다음과 같다.

SVRGROUP 이름 [,COUSIN=(“group-name”)]

COUSIN = literal


DDR 은 라우팅을 원하는 서비스가 다수의 서버그룹에서 제공되어야 한다. 따라서, COUSIN 항목의 설정에 따라 원래의 SVRGROUP 이 다른 노드로 복사 되어야 할 필요가 있다.

이에 대한 자세한 내용은 앞의 ‘시스템 성능에 따른 부하조절’에서 설명된 COUSIN 항목을 참조한다

SERVICE 절

DDR 환경설정과 관련하여 SERVICE 절에 정의하는 항목들은 다음과 같다.

SERVICE 이름 [,ROUTING=routing-name]

ROUTING = string



라우팅의 논리적 이름을 정의한다

SERVICE 절 내에서 유일해야 하며 이 이름은 아래 설명된 ROUTING 절에도 사용되는 것이다. DDR 을 특정 서비스에 응용하기 위해서는 ROUTING 이름이 정의되어야 하며 유형 버퍼의 이름과 라우팅을 원하는 필드 및 그 범위를 서버그룹 이름과 함께 정의해야 한다.

ROUTING 절

한 도메인 안에서 노드간, 또는 멀티 도메인 환경 하에서 도메인 간 DDR 은 ROUTING 절에 정의된 유형버퍼의 특정 필드값 혹은 멤버값에 의해 이루어진다. 한 도메인내의 노드간 DDR 의 경우 SERVICE 절에서 정의한 ROUTING Name 을 통하여 이루어지며 ROUTING 절에는 사용자가 원하는 조건을 상술하게 된다. ROUTING 절에는 ROUTING Name 과 더불어 STRUCT, X_C_TYPE 또는 X_COMMON 형 버퍼의 서브타입이나 필드 버퍼의 이름을 정의하고 그 버퍼에서 라우팅을 적용할 멤버 혹은 필드와 그 값의 범위를 이를 처리할 서버그룹명과 함께 병기한다. 멀티 도메인 환경의 DDR 의 경우 서버그룹명 대신 도메인의 GATEWAY name 을 지정하면 된다.

ROUTING 절의 형식은 다음과 같다

ROUTING Name SUBTYPE=buffer-name,

FIELD=field-name,

RANGES=“범위 1: Group1, 범위 2: Group 2, ....”,

OFFSET = num, FLDLEN = num

ROUTING Name = string


SERVICE 절의 ROUTING 항목에 정의한 이름이다.

데이터에 따른 부하조절은 서비스별로 부하조절이 이루어 지므로 반드시 SERVICE 절에 등록된 이름이어야 한다

SUBTYPE = string


데이터 의존형 라우팅을 적용할 서비스에 대해서, 그 서비스가 사용하는 STRUCT, X_C_TYPE 또는 X_COMMON 타입의 버퍼 이름을 설정한다.

STRUCT 형 버퍼는 사용자가 정의하는 C 구조체로써, X/Open 에 정의된 X_C_TYPE, X_COMMON 버퍼와 동일하다. 사용자는 미리 해당되는 구조체의 이름과 내용을 선언하여 절차에 따라 Tmax 시스템이 필요로 하는 파일을 제공해야 하며 이 항목에는 구조체의 이름을 설정하면 된다. Tmax 시스템은 환경변수 SDLFILE 을 참조하여 구조체의 내용을 식별한다. 필드 버퍼가 사용되었을 경우는 이 항목에 ”FIELD”를 입력한다. 사용자는 미리 필드버퍼의 필드 항목과 유형을 정의하여 절차에 따라 Tmax 시스템이 필요로 하는 파일을 제공하야 한다. Tmax 시스템은 환경변수 FDLFILE 을 참조하여 필드버퍼의 내용을 식별한다 3.8.15 버전부터는 CARRAY 와 STRING 타입의 데이터에 대해서도 데이터 의존형 라우팅을 적용할 수 있도록 지원하고 있다. SUBTYPE=”“, FIELD=”“ 라고 설정해 주면 STRING 과 CARRAY 타입에 대한 DDR(Data Dependence Routing)로 간주하게 된다. CARRAY 타입에는 이미지 같은 형태의 데이터가 입력될 수 있는데 반드시 프린트 가능한 형태의 데이터여야 한다. 데이터 의존형 라우팅(DDR)은 매칭 타입과 범위 타입의 두 가지 방식으로 나눌 수 있다. 매칭 타입과 범위 타입의 차이점은 아래의 예제를 통해서 살펴볼 수 있다.

자세한 내용은 Tmax Application Development Guide 및 Tmax Installation Guide 를 참조한다.

FIELD = string


SUBTYPE 에 구조체의 이름을 지정했을 경우 그 구조체의 멤버들중 실제로 라우팅을 적용할 멤버를 선택한다. 라우팅은 정수(integer) 타입의 멤버만 사용 가능하다.


필드 버퍼의 경우는 라우팅을 적용할 필드의 이름을 지정한다. STRUCT 형 버퍼와는 달리 정수(integer) 타입과 스트링(string) 타입을 모두 사용할 수 있다.

또한 위에서 설명한 바와 같이 SUBTYPE=”“, FIELD=”“라고 설정하였을 경우 STRING/CARRAY 타입에 대한 DDR(Data Dependence Routing)로 간주하게 된다.

RANGES = “범위: 그룹 1, 범위: 그룹 2, ....”

크기: 2047 자 이내

RANGES 항목은 FIELD 에서 정의한 항목의 값을 기준으로 어디로 라우팅 할 것인지에 대한 정보를 설정한다.

RANGES 항목의 값 지정 형식은 다음과 같다.

- 라우팅 필드는 정수(integer) 데이터 타입과 문자열(string) 타입이 지정될 수 있다.

- 정수인 경우 하나의 값, 또는 하한값과 상한값으로 이루어진 범위로 표현될 수 있다.

- 문자열인 경우 일치하느냐 안하느냐 만을 처리한다.

- 부호 (음수, 양수)를 표시할 수 있다.

- 최소값을 나타내는 MIN(해당 타입의 최소값), 최대값을 뜻하는 MAX(해당 타입의 최대값)라는 문자를 사용할 수 있다

- “A - B” 형식의 범위에서 A 는 B 보다 크지 않아야 한다.

- 별표(*)는 이전의 다른 범위들에 포함되지 않은 임의의 값을 대표하는 와일드 문자로 사용된다. 앞서 정의된 범위들 이외의 값이 올라올 경우를 고려하여 반드시 별표(*)에 대한 라우팅 서비스를 정의해야 한다. 단, MIN 과 MAX 를 모두 정의 하였다면 별표(*)에 대한 정의는 생략할 수 있다.


- 서버그룹명은 범위 뒤의 콜론(:) 다음에 지정된다 사용되는 서버그룹명은 *SVRGROUP 절의 COUSIN 항목에 정의된 서버그룹명 이어야 한다

- 전체 문자열은 큰따옴표(“) 로 묶여야 한다

- 도메인간의 라우팅은 서버그룹명 대신 도메인 게이트웨이명을 지정 하여야 한다

- 문자열로 라우팅을 할 경우 해당 값은 작은 따옴표(‘)로 묶여야 한다.

OFFSET = numeric(0)

전체 데이터 중 일정 부분만을 DDR 시에 사용하고자 할 때 사용하는 항목으로, 입력 데이터 중 DDR 시에 사용하고자 하는 부분의 처음 시작 위치를 나타낸다. OFFSET 는 FLDLEN 항목과 함께 지정되어야 하며 입력 데이터의 해당 OFFSET 부터 FLDLEN 만큼의 데이터만 DDR 시에 사용이 된다. 예를 들어 OFFSET=0, FLDLEN=4 이며, “Tmaxsoft” 라는 입력 데이터를 처리하고자 한다면, 0 번째 위치부터 4 byte 만큼인 “Tmax” 라는 문자열만이 DDR 의 비교 기준이 된다. 이 항목은 CARRAY / STRING 타입의 DDR 시에만 유효하다.

OFFSET 과 FLDLEN 을 사용할 때 주의할 점은 매칭 타입일 경우에는 사용해서는 안되며, 범위 타입일 경우에만 사용할 수 있다는 것이다. 이것은 OFFSET 과 FLDLEN 이 입력 데이터만을 대상으로 지정하는 항목이며 RANGES 항목에 지정하는 데이터와는 관계가 없기 때문이다. 아래와 같이 설정되어 있는 경우 “aaaaaaa” 라는 문자열의 0 OFFSET 부터 4byte 인 “aaaa” 라는 문자열만이 DDR 시의 비교 기준이 된다. 따라서 입력 데이터의 비교 기준인 “aaaa”와 RANGES 에 지정한 “aaaaaaa” 는 일치하지 않으므로 SVG2 에서 처리하게 된다. 따라서 이 경우 어떤 데이터가 들어오더라도 무조건 SVG2 에서 처리하게 되므로 사용자는 주의해야 한다.

ROUTE_1 SUBTYPE = “”, FIELD = “”,

RANGES = “aaaaaaa”:SVG1, *:SVG2,

OFFSET = 0, FLDLEN = 4


범위 타입으로 설정되어 있는 경우에는 OFFSET 과 FLDLEN 이 유효하다. 아래와 같이 설정되어 있는 환경에서 입력 데이터가 “aaaaaaa” 일 경우, 입력 데이터 중 0 OFFSET 부터 4byte 만큼의 “aaaa” 만이 비교 기준이 되며, “aaaa”라는 문자열은 SVG1 에서 지정한 범위보다 작게 되므로 SVG2 에서 처리한다. 입력 데이터가 “bbbb”일 경우 SVG1 에서 지정한 범위 안에 속하게 되므로 SVG1 에서 처리하게 된다.

ROUTE_1 SUBTYPE = “”, FIELD = “”,

RANGES = “aaaaaaa”-“ccccccc”:SVG1, *:SVG2,


FLDLEN = numeric

OFFSET 이 입력 데이터 중 DDR 시에 비교 기준으로 사용하고자 하는 부분의 처음 시작 위치를 나타낸다면 FLDLEN 은 OFFSET 위치부터 지정한 길이만큼을 비교 기준으로 사용하고자 할 때 지정하는 항목으로 반드시 OFFSET 항목과 함께 사용되어야 한다.

지정되지 않을 경우 NULL 을 만날 때까지 혹은 메시지의 끝까지 비교하게 된다.

예) 정수인 경우

ROUTE_1 SUBTYPE = student, FIELD = number,

RANGES = “MIN - 3 : SVG1, 4 - 6 :

SVG2, 7 - MAX : 1SVG3”

이경우 student 구조체의 number 멤버에 대해서 그 데이터 값이 음수부터 3 까지는 서버그룹 SVG1 으로, 4 ~ 6 까지는 SVG2 로, 7 부터는 모두 SVG3 으로 라우팅 한다는 의미이다.

ROUTE_1 SUBTYPE = student, FIELD = number,

RANGES = “MOD2 = 0 : SVG1, MOD2 =

1 : SVG2”

이경우 student 구조체의 number 멤버에 대해서 짝수는 서버그룹 SVG1 에서 처리되며 홀수는 SVG2 에서


처리된다. MOD 연산자를 통해 범위가 결정되므로 사용자의 폭이 훨씬 넓어질 수 있다.

예) 필드 버퍼인 경우

ROUTE_1 SUBTYPE = FIELD,

FIELD = INPUT,

RANGES = “‘STRING’ : SVG1, *: SVG2”

이 경우는 필드 버퍼의 INPUT 필드의 값이 ‘STRING’인 경우 서버그룹 SVG1 에서 처리되고 그 외의 경우에는 서버그룹 SVG2 에서 처리된다. 도메인간에 라우팅을 하는 경우에는 서버 그룹 명 대신 도메인 게이트웨이로 지정된 게이트웨이 이름을 지정해야 한다. 문자열인 경우는 반드시 ‘ ’으로 묶어서 표현해야 한다.

예) STRING, CARRAY 인 경우 (매칭 타입)

ROUTE_1 SUBTYPE = “ “,

FIELD = “ “,

RANGES = “‘aaa’ : SVG1, *: SVG2”

이 경우는 STRING 또는 CARRAY 의 값이 ‘aaa’일 경우에만 그룹 SVG1 에서 처리되고 그 외의 경우에는 서버그룹 SVG2 에서 처리된다는 의미이다. 매칭 타입의 경우 주의할 점은 유효한 데이터의 길이는 지정해 준 단어와 완전히 일치할 경우에만 해당 범위로 간주하게 된다는 것이다. 즉 SVG1 의 지정된 문자열이 ‘aaa’라면 aaa 외의 문자 즉 aaab, aaacc 등의 문자는 모두 SVG2 에서 처리하게 된다.

예) STRING, CARRAY 인 경우 (범위 타입)

ROUTE_1 SUBTYPE = “ “, FIELD = “ “,

RANGES = “‘aaa’-‘ccc’ : SVG1, *: SVG2”

이 경우는 STRING 또는 CARRAY 의 값이 ‘aaa’ 부터 ‘ccc’인 경우 서버그룹 SVG1 에서 처리되고 그 외의 경우에는 서버그룹 SVG2 에서 처리된다는 의미이다. 범위 타입의 데이터 의존형 라우팅(DDR)은 매칭 타입과는 달리 지정된 범위의 길이로 한정되지 않고 문자열의 끝까지 검사한다. 따라서 지정해 준 데이터의


길이와는 관계 없이 해당 문자열이 해당 범위 안에 속하는 지를 검사하게 된다.

예) STRING, CARRAY 인 경우 (범위 타입, DDR 비교 길이 설정)

ROUTE_1 SUBTYPE = “ “, FIELD = “ “,

RANGES = “‘aaaaaaa’-‘ccccccc’:SVG1,*:SVG2”,


이 경우는 입력 데이터 중 0 OFFSET 부터 4byte 인 “aaaa” 문자열만을 DDR 시에 비교 기준으로 사용하라는 의미이다. 예를 들어 입력 데이터가 “aaaaaaa”라는 문자열일 경우, “aaaa” 만이 비교 기준으로 사용된다. 이 때 “aaaa”는 SVG1 에서 지정한 범위보다 작으므로 SVG2 에서 처리하게 된다. 입력 데이터가 “bbbbbbb” 일 경우 “bbbb”라는 문자열은 SVG1 에서 지정한 범위에 속하게 되므로 SVG1 에서 처리하게 된다.

2.2.6 신뢰성 큐(RQ-Reliable Queue) 환경설정

클라이언트의 서비스 요구가 집중되어 요구된 서비스를 즉시 처리하지 못하고 내부 큐에 적체된 상태에서 시스템 오류로 인하여 시스템이 비정상적으로 종료되는 경우, 모든 서비스 요청 데이터는 삭제된다. 이러한 문제점을 보완하기 위하여 서비스 데이터를 메모리가 아닌 디스크 파일에 적재함으로써 시스템이 정상적으로 시작된 후에 처리를 계속 할 수 있도록 환경을 설정하는 절이 RQ 절이다. RQ 를 작동하기 위해 기본 환경설정(DOMAIN, NODE, SVRGROUP, SERVER, SERVICE 절) 외에 별도로 RQ 절을 설정해야 한다.

<주의> RQ 를 사용할 경우, 메모리가 아닌 디스크를 이용하기 때문에 서비스를 요구한 데이터는 안전하게 보관되나 RQ 를 사용하지 않을 때보다 속도는 저하될 수 있다.


RQ 환경설정에 따른 SVRGROUP 절에 정의하는 항목은 다음과 같다.

RQ SVRGROUP 이름 [,NODENAME=“node-name “]

[,CPC = channel-number]

[,SVGTYPE = RQMGR]


SVRGROUP 절의 신뢰성 큐 환경설정

CPC = number (4)

범위: 1 ~ 128

RQS 프로세스와 CLH 프로세스 사이의 병렬통신 채널 수를 지정하는 항목이다. 큐의 사용이 빈번할 경우에 다중의 채널을 유지함으로써 처리속도를 향상시킬 수 있다.

SVGTYPE = string

RQ 서버그룹의 타입을 정의하는 항목으로 RQMGR 이라 정의하면 된다.

2.2.6.2 RQ 절

하나의 서버그룹에 하나의 RQ 를 정의하며 여러 개를 그룹으로 지정할 수도 있다.

RQ 이름 SVGNAME=rq-svrgroup-name

[,QSIZE=size-number]

[,FILEPATH=file-path]

[,BOOT=WARM | COLD]

[,FSYNC=Y | N]

[,BUFFERING=Y | N]

필수 항목

RQ 이름 = string


RQ 절에 대한 논리적인 이름이다. RQ 절 내에서 여러 개의 RQ 정의가 가능하며, 각각의 RQ 이름은 유일한 값이어야 한다. 또한 한 노드에 두개 이상의 RQ 를 정의할 수 있다.

SVGNAME = string



RQ 를 사용하는 그룹을 지정한다. SVGNAME 은 SVRGROUP 절에 등록된 RQ 그룹 이름이어야 한다.

선택 항목

BOOT = WARM | (COLD)

BOOT 필드는 Tmax 시스템 재부팅 시, RQ 에 저장된 데이터를 조절한다.

BOOT 항목이 WARM 인 경우, 시스템 장애복구 후에 큐에 쌓였던 서비스의 복구(정상적 처리)가 가능하게 되며, COLD 로 설정되어 있으면, Tmax 시스템이 다시 기동 될 때 디스크에 저장된 서비스는 처리를 하지 않고 무시해 버린다

FSYNC = (Y) | N

각 디스크에 기록한 후에 fsync 의 호출 여부를 지정한다.

이 필드가 NO 이면 시스템 장애 발생 시 데이터를 잃을 가능성이 있지만 RQ 처리 속도는 빨라진다. 이 필드가 YES 일 때는 RQ 데이터가 메모리를 사용하지 않고 항상 디스크에 안전하게 저장되지만 NO 를 설정 했을 때보다 처리 속도가 늦어진다.

BUFFERING = (Y) | N

RQ 파일 내용을 메모리에 캐쉬(cache) 할지 여부를 지정한다.

N 으로 지정하면 RQ 처리가 상대적으로 느려지나 요구되는 메모리가 작아진다

QSIZE = size-number (16)

범위: 1 – 2047(Mbyte)

Enqueue 된 데이터를 저장하는 RQ 의 크기를 지정하여 사용할 수 있다.

기본값은 16Mbyte 이다.


RQ 의 크기는 자동으로 증가하지 않으므로 RQ 가 정의한 크기를 초과하여 에러가 발생할 것을 막기위해 적당한 크기로 설정할 것을 권한다. RQ 파일을 작성한 후에도 RQ 에 데이터가 저장되지 않으면 Tmax 가 종료될 때 파일이 자동으로 삭제된다

FILEPATH = literal


RQ 에서 사용되는 파일 위치를 지정한다

디폴트는 $(TMAXDIR)/path/rq-name 이다

이 필드는 RQ 데이터 파일을 생성하며 이는 전체 파일 이름과 디렉토리 이름으로 정의 되어야 한다.

2.2.7 장애대책 환경설정

Tmax 에서는 다음과 같은 장애대책 방법을 제공한다.

하드웨어적 장애 (노드나 네트워크 장애)

서비스 백업에 의한 장애대책

소프트웨어적 장애 (프로세스의 다운)

프로세스들의 재시작(restart)에 의한 장애대책

위와 같은 각 장애대책을 위한 환경설정법을 알아보기로 한다.

2.2.7.1 서비스 백업을 이용한 장애대책

장애로 인해 서비스가 불가능 시, 백업 서비스를 통해 계속적인 서비스를 제공하는 것이다.

서비스 백업은 SVRGROUP 절의 BACKUP 항목을 설정함으로 이루어진다.

SVRGROUP 절

SVRGROUP 이름 [,BACKUP=(“group-name”)

BACKUP = literal



백업 서버그룹을 지정한다

하나 이상의 백업서버그룹을 지정할 수 있으며, 둘 이상의 백업서버그룹을 지정할 때는 콤마(,)로 분리하여 나열한다. 여러 개의 백업서버를 지정한 경우, 원본 서버노드 장애 시 첫번째로 지정된 백업노드로 동작하게 되고, 그 백업노드도 이상이 생기면 두 번째로 지정된 백업노드가 동작하게 되는 다중 장애대책을 지원한다. 백업노드의 서버그룹 명은 반드시 SVGROUP 절에 등록하여야 한다. 또한 서버그룹과 서버의 환경 옵션들은 기본적으로 원본 서버그룹의 환경을 그대로 따르며, 환경 옵션을 변경하고자 하는 경우, 서버그룹이나 서버별로 관련 항목들을 재정의 할 수 있다. 다만, 서비스에 대한 환경 옵션은 이중복사 된 그룹별로 재정의 할 수 없으며, 반드시 원본 서버그룹과 동일한 환경을 갖는다 이에 대한 규칙들은 부하조절을 위해 이중 복사된 서버그룹과 동일하므로, ‘부하조절 환경설정 ’의 COUSIN 항목과 ‘그림 12 ’에 관련 내용이 자세히 설명되어 있다. 이들 백업노드들은 부하조절을 위해 복사된 서버그룹들과 달리, 원본 서버그룹 들처럼 Tmax 기동 시 동작하는 것이 아니라, 장애가 발생했을 경우에만 원본 서버그룹의 역할을 대신하여 동작하게 된다

2.2.7.2 프로세스의 재시작(restart)에 의한 장애대책

CLH, CAS 등의 Tmax 내부 프로세스가 비정상 종료되었을 경우, 프로세스가 자동적으로 재기동되어 계속 서비스를 제공하게 된다.

NODE 절

NODE 이름 [,RESTART=(Y) | N]

[,MAXRSTART=number]

[,GPERIOD=time-value]

RESTART = (Y) | N

Tmax 엔진 프로세스 중 CLH 와 CAS 의 재시작 가능 여부를 결정한다.


CLH 와 CAS 에 문제가 발생하여 비정상 종료(down) 되었을 경우, 재기동시키고자 한다면 RESTART 를 Y 로 설정한다.

MAXRSTART = number (-1)

범위: -11 ~ MAX_INT

Tmax 엔진 프로세스 중 CLH 와 CAS 프로세스의 최대 재시작 가능 횟수를 결정한다.

GPERIOD 항목과 함께 사용되며, 만약 RESTART 가 Y 라면 프로세스는 GPERIOD 시간 내에 최대 MAXRSTART 횟수까지 재시작 되며 ‘N’으로 설정되면 시스템은 이 값을 무시한다. MAXRSTART 가 –1 일 경우 프로세스의 최대 재시작 가능 횟수는 무한이 된다.

GPERIOD = numeric (86400)

범위: 1 ~ MAX_INT

MAXRSTART 횟수가 유효한 시간 주기이다

GPERIOD 시간 동안 MAXRSTART 횟수까지 프로세스가 재시작 된다. 그 시간이 경과하면 GPERIOD 시간동안 다시 MAXRSTART 횟수 만큼 재시작 된다. 디폴트 값은 86400 초, 즉 24 시간이다.

RQ 와 TMS 프로세스가 비정상 종료되었을 경우, 프로세스가 자동적으로 재기동 되어 계속 서비스를 제공하게 된다.

SVRGROUP

SVRGROUP 이름 [,RESTART=(Y) | N]

[,MAXRSTART=number]


RESTART, MAXRSTART, GPERIOD

SVGTYPE 이 RQMGR 의 경우에는 해당 RQ 의 restart 를, XA svg 의 경우에는 해당 tms 의 restart 를 조절한다.

위의 NODE 절을 참조한다.


서버 프로세스가 비정상 종료되었을 경우, 프로세스가 자동적으로 재기동 되어 계속 서비스를 제공하게 된다.

SERVER 절

SERVER 이름 [,RESTART=(Y) | N]

[,MAXRSTART=number]



서버프로세스의 재시작 가능 여부를 결정한다


Gateway 프로세스가 비정상 종료되었을 경우, 프로세스가 자동적으로 재기동 되어 계속 서비스를 제공하게 된다.

Gateway 절

GATEWAY 이름 [,RESTART=(Y) | N]

[,MAXRSTART=number]



Gateway 의 재시작 가능 여부를 결정한다.


2.2.8 보안 환경설정

Tmax 시스템은 자체적으로 다음과 같은 2 단계 보안을 지원한다.

단계 1: 시스템 접속 제어

Tmax 시스템에 접속하는 것을 제한한다.

단계 2: 사용자 인증

인증된 사용자만이 서비스를 요청할 수 있다.

보안의 각 단계는 이전 단계를 포함한다. 즉, 2 단계 사용자 인증보안이 설정된 경우에, 1 단계 시스템 접속제어 보안도 적용된다.


2.2.8.1 보안 설정

어느 단계의 보안을 설정할 것인지는 DOMAIN 절의 SECURITY 항목에서 결정한다. SECURITY 항목에 정의 가능한 값은 다음과 같다.

DOMAIN 절

Domain 이름 [,SECURITY=(“NO_SECURITY”)|

“DOMAIN_SEC”|”USER_AUTH”]

[,OWNER=user-name]

SECURITY = (“NO_SECURITY”)| “DOMAIN_SEC”| “USER_AUTH”

“NO_SECURITY” 는 어떠한 보안 설정도 하지 않겠다는 의미이다

“DOMAIN_SEC” 는 1 단계 보안인 시스템 접속제어에 대한 보안을 정의한다.

“USER_AUTH” 는 2 단계 보안인 사용자 인증을 정의한다.

시스템 접속 제어 : DOMAIN 의 SECURITY 항목에 “DOMAIN_SEC”를 정의한다. mkpw utility 를 이용해 Tmax 시스템에 대한 단일 패스워드를 설정하고 이 패스워드를 알고 있는 사용자에 한해서만 접속을 허락한다. 이 보안을 설정하고자 한다면 DOMAIN 절에 OWNER 항목을 정의하여야 한다.

OWNER = string


사용자는 Tmax 시스템에 접속 시에 TPSTART_T 구조체의 dompwd 항목에 이 계정의 패스워드를 입력하여 접속을 신청하여야 한다(Tmax Application Development Guide 의 tpstart()함수 참조). 패스워드가 등록되지 않았거나 틀린 경우에는 Tmax 시스템 접속에 실패하게 된다. 이 필드에서 정의된 사용자와 패스워드는 제공된 mkpw utility 로 작성할 수 있다.


사용자 인증 : 2 단계 보안으로 DOMAIN 의 SECURITY 항목에 “USER_AUTH”를 정의하는 경우에 해당한다. 사용자 계정과 패스워드를 관리하여 인증된 사용자에 한해서만 Tmax 서비스를 제공한다. 사용자와 패스워드는 mkpw utility 로 작성되어야 한다. 이 경우, 사용자는 Tmax 시스템에 접속 시에 TPSTART_T 구조체의 usrname 과 usrpwd 항목에 인증 가능한 사용자 계정과 패스워드를 등록하여 접속 신청을 하여야 한다. TPSTART_T 구조체에 관한 설명은, Tmax Application Development Guide 의 tpstart() 함수를 참조한다. 인증되지 않은 사용자는 Tmax 시스템에 접속할 수 없다.

보안 환경설정을 한 뒤에 패스워드 파일은 mkpw utility 로 작성되어야 한다. 이 파일은 각각의 사용자의 패스워드를 포함한다. 이 파일은 암호화 되어있어 패스워드의 노출이 방지된다. Tmax 보안 시스템을 정상적으로 작동하기 위해서는 Tmax 시스템이 설정되기 전에 패스워드 파일이 작성되어 있어야 한다. DOMAIN_SEC 의 경우, 패스워드가 tpstart() 안에 있는 TPSTART_T 구조체의 dompwd 필드의 것과 다르다면 그 클라이언트 프로그램은 서비스를 요청할 수 없다 이때 tperrno 는 TPESECURITY (25)로 설정된다. USER_AUTH 의 경우, TPSTART_T 구조체의 usrpwd 와 usrname 필드는 mkpw utility 로 작성한 패스워드 파일에 등록된 계정과 패스워드가 같아야 한다. 이 경우에, 2 단계는 1 단계를 포함하므로 dompwd 도 설정되어 있어 도메인 패스워드와 일치해야 한다. <주의> Tmax 시스템이 시동되기 전에 패스워드 파일이 작성되거나 갱신되어 있어야 한다.


2.2.9 멀티 도메인 환경설정

TMAX 에서는 멀티 도메인 환경 하에서 도메인간의 트랜잭션 처리기능을 제공 한다. 이는 사용자에게 글로벌 트랜잭션 처리가 더욱 확장된 형태로 제공 되어지고, 도메인간에 같은 어플리케이션으로 데이터값에 따른 라우팅을 지원 함으로써 개발에 대한 부담을 줄여 준다.

멀티 도메인 환경을 위해서는 도메인 게이트웨이절에 게이트웨이 정보를 등록하고, 라우팅절과 서비스 절에는 라우팅 정보를 등록 하여야 한다.

2.2.9.1 DOMAIN 절

각각의 DOMAIN 절에는 기본적인 내용(Shared Memory Key, Port number, MINCLH, MAXUSER 등)이 등록된다. 분산 트랜잭션과 관련하여 2PC(Two Phase Commit) 가능 여부와 트랜잭션 타임아웃(timeout) 시간을 설정할 수 있다.

*DOMAIN

site1 SHMKEY = 79990, MAXUSER = 100, MINCLH = 1,

MAXCLH = 3, TPORTNO = 8888,

CMTRET = Y, BLOCKTIME = 60,

DOMAINID=1

2.2.9.2 NODE 절

노드절에는 같은 각각의 도메인에 속해있는 노드들에 대한 정보를 모두 등록한다.

*NODE

tmax1 TMAXDIR = “/user3/tmax”,

APPDIR = “/user3/tmax/appbin”,

PATHDIR = “/user3/tmax/path”,

TLOGDIR = “/user3/tmax/log/tlog”,

ULOGDIR = “/user3/tmax/log/ulog”,

SLOGDIR = “/user3/tmax/log/slog”



멀티 도메인 환경 하에서 각각의 서버그룹절에서는 데이터베이스의 이용여부에 따라 그룹들을 구분하여 등록한다. 도메인간의 전역 트랜잭션 처리(Two Phase Commit)를 위해서는 반드시 XA 그룹으로 서버와 서비스가 묶여 있어야 한다.

*SVRGROUP

NXAGRP NODENAME = tmax1

XAGRP NODENAME = tmax1, DBNAME=ORACLE,

OPENINFO=“Oracle_XA+Acc=P/scott/tiger+SesTm=80+logdir=.”,

TMSNAME = XAGRP_tms, MINTMS=2, MAXTMS=5

2.2.9.4 SERVER 절

멀티 도메인 환경 하에서 각각의 서버절에서는 기본적인 내용을 등록한다.

*SERVER

SVG_X SVGNAME=XAGRP, MIN=1, MAX=2,

CLOPT=“-o $(SVR).$(DATE).log -- -u scott -p tiger”

SVG_NX SVGNAME=NXAGRP, MIN=1, MAX=2,

CLOPT=“-o $(SVR).$(DATE).log”

2.2.9.5 SERVICE 절

멀티 도메인 환경 하에서 각각의 서비스절에는 기본적인 내용과 라우팅이 필요한 경우 라우팅절의 라우팅 이름을 지정하여야 한다.

*SERVICE

SVC_X SVRNAME=SVG_X, ROUTING=XRID

SVC_NX SVRNAME=SVG_NX, ROUTING=NXRID

2.2.9.6 GATEWAY 절

멀티 도메인 환경하에서 라우팅이 필요한 경우, 각각의 게이트웨이 절을 반드시 등록하고 필요한 정보들을 기록하여야 한다. 이때 RGWADDR 와 RGWPORTNO 는 반드시 상대편 도메인 서버의 IP ADDRESS 와 PORT 번호가 되어야 하며 NODENAME 은 게이트웨이 프로세스가 수행되어야 할 서버 이름이다.


*GATEWAY

DOMAIN_GW1 GWTYPE=TMAX, PORTNO=5000,

RGWADDR=“192.168.63.133”,

RGWPORTNO = 5000,

NODENAME = tmax1

2.2.9.7 ROUTING 절

멀티 도메인 환경 하에서 라우팅이 필요한 경우 반드시 등록되어야 하며 여기에는 라우팅이름, 필드이름, SUBTYPE(BUFFER 유형)과 라우팅 범위(RANGES)가 반드시 등록 되어야 한다.

*ROUTING

XRID FIELD=ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6400’:XAGRP,‘6471’:DOMAIN_GW1”

NXRID FIELD=ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6400’:NXAGRP,‘6471’:DOMAIN_GW1”

2.2.9.8 멀티도메인 라우팅 환경파일 예제

<<Domain Site 의 환경파일 예제>> *DOMAIN

site1 SHMKEY=79990, MAXUSER=100, MINCLH=1, MAXCLH=3,

TPORTNO=8888, CMTRET=Y, BLOCKTIME=60,

DOMAINID=1

*NODE

tmax1 TMAXDIR=“/user3/tmax”,

APPDIR =“/user3/tmax/appbin”,





*SVRGROUP


XAGRP NODENAME = tmax1, DBNAME = ORACLE,

OPENINFO = “Oracle_XA+Acc=P/scott/tiger + SesTm =

80 + logdir = . ” ,


*SERVER

SVG_X SVGNAME = XAGRP, MIN=1, MAX=2,

CLOPT = “-o $(SVR).$(DATE).log -- -u scott –p


tiger”

SVG_NX SVGNAME = NXAGRP, MIN=1, MAX=2,


*SERVICE

SVC_X SVRNAME = SVG_X, ROUTING=XRID

SVC_NX SVRNAME = SVG_NX, ROUTING=NXRID

*GATEWAY

DOMAIN_GW1 GWTYPE = TMAX, PORTNO=5000,RGWADDR =

“192.168.63.133”

RGWPORTNO=5000,NODENAME = tmax1

*ROUTING

XRID FIELD = ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6400’:XAGRP, ‘6471’:DOMAIN_GW1”

NXRID FIELD = ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6400’:NXAGRP, ‘6471’:DOMAIN_GW1”


*DOMAIN


TPORTNO=8888, CMTRET=Y, BLOCKTIME=60,

DOMAINID=2

*NODE

tmax2 TMAXDIR=“/user3/tmax”,

APPDIR =“/user3/tmax/appbin”,





*SVRGROUP


XAGRP NODENAME = tmax2, DBNAME = ORACLE,


80 + logdir = . “ ,


*SERVER

SVG_X SVGNAME = XAGRP, MIN=1, MAX=2,

CLOPT = “-o $(SVR).$(DATE).log -- -u scott –p

tiger”

SVG_NX SVGNAME = NXAGRP, MIN=1, MAX=2,


*SERVICE

SVC_X SVRNAME = SVG_X, ROUTING=XRID

SVC_NX SVRNAME = SVG_NX, ROUTING=NXRID

*GATEWAY

DOMAIN_GW2 GWTYPE = TMAX, PORTNO=5000,RGWADDR =

“192.168.63.132”,

RGWPORTNO=5000,NODENAME = tmax2

*ROUTING

XRID FIELD = ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6471’:XAGRP, ‘6400’:DOMAIN_GW2”

NXRID FIELD = ROUTING_ID, SUBTYPE=FIELD,

RANGES = “‘6471’:NXAGRP, ‘6400’:DOMAIN_GW2”

<< TMAX 의 복합적인 기능을 이용한 환경파일 예제>>

*DOMAIN


TPORTNO=8888, CMTRET=Y, BLOCKTIME=30


*NODE

tmax1 TMAXDIR=“/tmax/tmax”,

APPDIR =“/tmax/tmax/appbin”,

PATHDIR = “/tmax/tmax/path”,

TLOGDIR = “/tmax/tmax/log/tlog”,

ULOGDIR = “/tmax/tmax/log/ulog”,

SLOGDIR = “/tmax/tmax/log/slog”

tmax2 TMAXDIR=“/tmax/tmax”,

APPDIR =“/tmax/tmax/appbin”,

PATHDIR = “/tmax/tmax/path”,

TLOGDIR = “/tmax/tmax/log/tlog”,

ULOGDIR = “/tmax/tmax/log/ulog”,

SLOGDIR = “/tmax/tmax/log/slog”

*SVRGROUP

SVGtmax1 NODENAME = tmax2, DBNAME = ORACLE,

COUSIN=“SVGtmax1”,


60+DbgFl=0x01”,

TMSNAME = svg1_tms, MINTMS=2, MAXTMS=5

SVGtmax2 NODENAME = tmax1, DBNAME = ORACLE,


60+DbgFl=0x01”,

TMSNAME = svg1_tms, MINTMS=2, MAXTMS=5

SVGtmax2NX NODENAME=tmax1

SVGRQ1 NODENAME=tmax1,

SVGTYPE=RQMGR, CPC=8,

COUSIN=“SVGRQ1”, LOAD=-1

*RQ

rq1 SVGNAME=SVGRQ, BOOT=COLD, FILEPATH=“/tmp/rq1”

QSIZE=24, FSYNC=Y, BUFFERING=N

*SERVER

svr1 SVGNAME = SVGtmax1, MIN=1, MAX=5

svr2 SVGNAME = SVGtmax2, MIN=1, MAX=5

svr3 SVGNAME = SVGtmax2NX, MIN=1, MAX=5

*SERVICE

svc1 SVRNAME = svr1, ROUTING=rout1

svc2 SVRNAME = svr2

svc3 SVRNAME = svr3


svc4 SVRNAME = GW2 #Gateway is directly defined on

the server name.

*GATEWAY

GW1 GWTYPE = TMAX, PORTNO=5001,NODENAME = “tmax1”,

RGWADDR = “GW1_MAIN”, RGWPORTNO=5001





*ROUTING

rout1 SUBTYPE=FIELD, FIELD = PLACE_CD,

RANGES = “‘00000’:SVGtmax1, ‘A0001’-‘A0006’:GW2,

‘A0007’-‘A4000’:GW3”

2.3 Tmax 환경파일 컴파일

보통 하나의 프로그램을 만드는 과정은 여러 단계를 거친다. 먼저 소스 프로그램을 작성하고 컴파일하여 에러들을 수정한 후에 올바른 실행 파일을 만들게 된다.

Tmax 환경파일도 실제 프로그램 작성 방법과 동일하다. Tmax 환경파일을 컴파일 함으로써 에러 없는 올바른 Tmax 환경파일을 만들 수 있게 된다.

Tmax 시스템은 기동 될 때, Tmax 환경파일을 토대로 환경을 설정하기 때문에, 에러가 존재하는 환경파일이라면 Tmax 시스템 동작 시 예상치 못한 오류가 생길 수 있다. Tmax 시스템은 올바른 환경파일 없이는 기동 될 수 없다. 따라서 Tmax 환경파일의 컴파일 작업을 통해 Tmax 가 정상적으로 동작할 수 있도록 올바른 Tmax 환경파일을 만들어 주어야 한다.

컴파일 작업은 cfl 명령에 의해 이루어 진다.

cfl -i config source file name [ -o config binary file name]

[-h] [-n node name] [-v num]

Options

-i : 환경 파일 이름

컴파일 대상이 되는 환경파일 이름을 지정한다


-o : 이진 환경 파일 이름

컴파일을 통해 만들어질 이진(binary) 환경파일 이름을 지정 한다. 디폴트 파일의 이름은 ‘tmconfig’이다.

여러 노드로 Tmax 시스템이 구축이 되어있는 경우, 특정 노드에서 중앙 관리를 하고자 하는 경우에는 각 노드에 racd(remote access control daemon)가 미리 기동 되어 있어야 한다. racd 는 환경파일 컴파일, Tmax 시스템 부팅, Tmax 시스템 다운, 동적환경 변경등을 특정 노드에서 한번의 명령어로 가능하게 한다. 특정 노드에서 환경파일 컴파일 작업을 수행하게 되면 모든 노드에 전달되며 모든 노드에 이진 Tmax 환경파일이 전달된다. 이진 Tmax 환경파일은 Tmax 시스템 기동과 종료, 서비스 테이블 생성등에 참조되며 하나의 환경파일로 모든 노드가 관리된다. 따라서 환경파일의 변경 작업에는 상당한 주의가 요구된다

-h : Online Help

-n : 노드명

멀티노드 환경에서 특정 노드의 환경파일만을 컴파일하고 싶은 경우에 사용하는 옵션이다.

-v : version

0 또는 1 을 사용할 수 있으며, 디폴트는 1 이다.

멀티노드를 구성하고 있는 노드가 모두 같은 종류이며(예를 들어 모두 SUN os2.6) 관리자가 각각의 노드별로 환경파일을 관리하고자 한다면 이 옵션을 0 으로 설정하고 컴파일한 이진 환경파일을 각각의 노드로 복사하여 시스템을 운영할 수 있다. 1 로 지정된 경우에는 racd 를 통해서 환경파일이 각각의 머신에서 자동적으로 컴파일이 된다 (Tmax 추천사항).

-V : 실행 파일의 버전을 확인할 수 있다.


2.4 서비스 테이블 생성

Tmax 시스템에서는 환경파일의 SERVICE 절에 등록된 서비스만 처리 가능하다. 그러나 하나의 서버프로세스가 여러 개의 서비스를 제공하는 것이 가능하므로 사용자는 서버 프로세스 내에서 제공하는 서비스의 종류를 Tmax system 에 제공하여야 한다. 이를 위해 환경파일로부터 서비스 테이블을 생성하는 과정이 필요하며 이는 서버프로그램의 컴파일 과정에서 반드시 함께 컴파일 되어야 한다.

서비스 테이블이란, 서버마다 제공되는 서비스 이름들이 나열되어 있는 파일로써 Tmax 환경파일에 등록된 서버와 서비스를 참조하여 생성된다. 서버프로그램을 만들 때, 서비스 테이블을 함께 컴파일하지 않으면 서비스 요청이 서버에게로 넘겨지더라도, 서버내에서 서비스 루틴의 위치를 알 수 없다.

서비스 테이블은 이진수 Tmax 환경설정 파일을 참조하여 gst 명령어를 이용해 작성된다.

gst [ -f binary configuration file ] {-n node name} [-h] {-V}

Options

-f : 이진 환경 파일 이름

컴파일 된 이진 환경파일 이름을 지정한다. 지정되지 않으면 디폴트로 ‘tmconfig’파일을 참조한다.

gst 명령은 컴파일된 이진 환경파일을 참조하여 Tmax 디렉토리 밑의 svct 디렉토리에 각 서버프로그램의 서비스 테이블을 생성한다. 따라서, gst 명령을 실행하기에 앞서 먼저 svct 디렉토리 존재 여부를 확인해야 한다. 다른 파일이름을 정의하지 않으면 tmconfig 파일을 참조한다. 명령 실행 후, svct 디렉토리에 서버별로 서버이름_svctab.c 의 서비스 테이블들이 생성되었는지 확인해 본다.

-h : Online Help

-V : 실행 파일의 버전을 확인할 수 있다

-n : 노드명


타 노드 서버 프로세스의 서비스 테이블을 현재 노드의 $TMAXDIR/svct 디렉토리에 생성 되도록 한다.


3 기동 및 종료

이제 Tmax 를 실행하기 위한 환경이 갖춰졌으며, 관리자는 Tmax 시스템을 기동(boot) 시킬 수 있다. Tmax 시스템이 기동 되면 시스템 소프트웨어의 특성상 아주 치명적인 원인(하드웨어 장애, 운영체제상의 오류 등 외부적인 요인) 이외에는 다운되지 않는다. 그러나 관리 측면에 있어서는 환경파일의 재작성, 외부요소에 의한 시스템 다운 등의 이유로 시스템을 종료 시키고 재기동해야 할 필요가 있다.

일반적으로 Tmax 시스템은 여러 노드로 구성되며 이에 대한 중앙관리가 필요하다. 중앙관리를 위해서 Tmax 시스템에서는 racd(remote access control daemon)를 사용한다. 즉, 각 노드에 racd 를 미리 설치해 둠으로써 한 노드에서 전체 Tmax 시스템을 관리할 수 있다. 즉, 환경파일 컴파일, Tmax 시스템 기동 및 종료, 동적 환경파일 변경 등의 동작을 한번의 명령으로 가능케 한다. 이 장에서는 이와 같은 다양한 환경에서 Tmax 시스템의 기동 (tmboot)과 종료(tmdown) 방법에 대하여 설명한다

3.1 Tmax 기동 (tmboot)

Tmax 시스템을 기동하기 위해서는 기본 환경설정이 잘 갖추어져 있어야 한다. 다음 사항들을 다시 한번 점검해 본다.

3.1.1 점검사항

이진 Tmax 환경파일이 존재하는가?

환경파일의 TMAXDIR 항목(*NODE 절)에 설정된 디렉토리에 Tmax 실행 프로그램들(tmm, cll, clh, tms, rqs 등)이 존재하는가?

환경파일의 APPDIR 항목(*NODE 절)에 설정된 디렉토리에 *SERVER 절에 등록된 서버프로그램들이 존재하는가?

중앙 관리를 위한 racd 가 각 노드에서 동작중인가?


위 사항들이 모두 점검되었으면 Tmax 시스템의 기동 준비가 끝난 것이다. 환경변수에 TMAX_RAC_PORT 가 정의되어 있어야 racd 가 기동 된다.

Tmax 시스템이 중앙관리에 사용된 racd 의 포트 번호를 정의하고 “racd –k”를 사용해 기동하면 Tmax 환경파일에서의 환경변수를 참조하지 않고 시스템을 기동할 수 있다.

3.1.2 racd

Command Option Argument

racd -k

-d

-f

-h

-V

None

Debug mode

config_file

None

None

racd 를 기동 시키기 위해서는 환경변수에 TMAX_RAC_PORT 또는 환경파일(.m)에 RAC_PORT 를 설정해 주어야 한다. 환경변수를 참조해서 부팅을 하기위해서는 “racd –k”를 환경파일(.m)을 참조해서 부팅을 하려면 옵션없이 “racd”를 실행 시키면 된다. 예를 들어 멀티 노드에서 리모트 호스트에 racd 를 실행할때는 “racd –k”를 사용해야 한다. 로컬에서 cfl 할때 리모트의 racd 를 통해서 tmconfg 파일이 전해지므로 리모트는 tmconfig 파일이 없는 상태에서 racd 를 띄워야 하므로 “racd –k”를 사용한다. 환경파일을 사용해야 하는 특수한 경우가 아닌한 일반적으로 “racd –k”를 사용한다.

3.1.3 tmboot

Tmax 시스템을 기동하기 위해서 tmboot 라는 프로그램이 제공된다.


tmboot -f

-T

-A

이진 Tmax 환경파일 이름

없음

없음


-S

-s

-n

-t

-g

-h

-b

-k

-o

-q

-d

-e

-V

서버 프로세스 이름

서버이름 –k 개수

노드이름

TMS 이름

서버그룹이름

Online Help

없음

개수

clopt_string

RQ svg_name

전체 서버 프로세스의 기동 시간(u sec)

CLH 또는 CAS

없음

3.1.3.1 Command

tmboot : Tmax 를 기동하기 위한 프로그램

3.1.3.2 Options

-f : ‘환경설정 ‘의 ‘환경파일 작성 ‘에서 이미 설명한 바와 같이 Tmax 는 Tmax 환경파일을 토대로 기동 된다. 따라서 참조할 이진 Tmax 환경파일명을 지정해 주어야 한다. 만약 파일명을 지정하지 않으면 디폴트로 ‘tmconfig’ 파일이 참조된다.

-T : Tmax 관리 프로세스들(TMM, CLL, CLH, TMS, RQS)만을 기동 시킨다.

-A : Tmax 환경파일 내의 SERVER 절에 정의된 모든 서버프로세스들을 기동 시킨다.

-S : 지정된 서버에 존재하는 서버프로세스들을 MIN 개수만큼 기동 시킨다.


-s : 지정된 서버프로세스만을 기동 시킨다. 서버프로세스 이름은 Tmax 환경파일 내의 SERVER 절에 미리 정의되어 있어야 한다. -k 옵션을 함께 사용하여 서버프로세스 개수를 지정할 수 있다. 서버프로세스 개수는 현재 기동 되어 있는 개수를 포함하여 SERVER 절의 MAX 항목에 정의된 개수를 넘어서는 안된 다. -k 옵션을 생략하면 서버프로세스는 1 개만 기동 된다.

-n : 지정된 노드에 존재하는 서버프로세스들을 기동 시킨다. 노드명은 Tmax 환경파일내의 NODE 절에 미리 정의되어 있어야 한다. (멀티 노드의 환경에서는 반드시 지정되어야 한다.)

-t : 지정된 노드에 존재하는 tms 프로세스를 MAX 값 이내에서 하나 더 기동 시킨다.

-g : 지정된 서버그룹에 존재하는 서버프로세스들을 기동 시킨다. 서버그룹명은 Tmax 환경파일내의 SVRGROUP 절에 미리 정의되어 있어야 한다.

-h : 명령어 도움말을 보여준다

-b : 백업서버도 기동한다

-k : -s, -t 와 같이 사용되어 기동 되는 서버의 개수를 지정한다.

-o : CLOPT string 을 추가한다

-q : RQS 가 기동한다

-w : 이 옵션이 없는 경우에는 등록된 서버 프로세스를 동시에 기동 시킨다. 이 경우 운영체제에 따라 동시에 리소스를 만들어내지 못해 서버 프로세스가 올바르게 기동되지 못하는 경우가 발생한다. 이런 문제를 없애기 위해 프로세스를 하나씩 기동 시켜 올바르게 기동 시키는 옵션이다.

-d : 한번에 많은 서버 프로세스를 기동시킬 때 CLH 로의 등록요구가 폭주하여 생기는 문제를 해결하기 위하여 서버 프로세스들이 기동하는데 걸리는 총 시간을 지정하여 등록간격을 조절할 수 있다. usec 단위로 지정한다.

-e : Tmax engine process 중 CLH 와 CAS 를 booting 하기

위한 옵션으로 tmboot 시에 문제가 발생했거나, kill 로

인하여 잘못하여 engine process 가 죽은 경우에 사용할 수


있도록 한다. 따라서 tmdown 에서는 이 옵션을 제공하지

않는다. 인자로 CLH 를 지정하였을 경우 CLH 를, CAS 를

지정하였을 경우 CAS 를 booting 시킨다.

-V : tmboot 실행 파일의 버전을 알 수 있다.

3.1.3.3 tmboot 의 예

$ tmboot

‘tmconfig’ 환경파일을 참조하여 Tmax 관리 프로세스와 응용 서버 프로세스들을 모두 기동 시킨다.

$ tmboot -T -f tmconfig2

‘tmconfig2’ 환경파일을 참조하여 Tmax 관리프로세스들만을 기동 시킨다.

$ tmboot -A

‘tmconfig’ 환경파일을 참조하여 응용 서버프로세스들 만을 기동 시킨다.

$ tmboot -S svr1

환경파일을 참조하여 svr1 프로세스를 MIN 개수만큼 기동 시킨다.

$ tmboot -s svr1 -k 5 -f tmconfig2

‘tmconfig2’ 환경파일을 참조하여 svr1 프로세스를 5 개 기동 시킨다.

Tmax 시스템을 기동 시키면, 먼저 이진 Tmax 환경파일의 내용이 공유 메모리에 적재되고, TMAXDIR/bin 디렉토리에 있는 Tmax 기능 프로세스(TMM, CLL, CLH)들이 기동된다. 만약 환경파일에 데이터베이스 정보(DBNAME, OPENINFO 등)가 등록되었다면, 관련 서버그룹별로 TMS 프로세스도 기동된다. 그 후, Tmax 환경파일에 APPDIR 디렉토리로 경로가 등록된 응용 서버프로세스들이 차례로 기동 된다. 또한 RQ 나 GATEWAY 관련정보가 등록되었다면 서버그룹당 하나의 RQS 프로세스와 GW 프로세스도 기동 된다. 그리고 tmboot 시에 참조되었던 config 디렉토리의 이진 환경 파일이 환경 변수인 TMAX_PATHDIR 디렉토리 밑에 생성된다. (NODE 절의 PATHDIR 참조)

Tmax 프로세스들의 기동 순서를 보면 다음과 같다.

1. TMM


2. CLL

3. CLH

4. (TMS)

5.응용 서버 프로세스들

6. (RQS)

7. (GW)

3.2 Tmax 종료 (tmdown)

Tmax 시스템 종료는 이진 Tmax 환경파일을 토대로 이루어 진다. 시스템에서 사용하던 공유메모리를 없애고, 기동 된 Tmax 프로세스들(tmm, tms, cll, clh, rqs)과 응용 서버프로세스들을 종료시킨다.

3.2.1 tmdown

Tmax 시스템을 종료 시키는 데 tmdown 이라는 명령을 사용한다. 사용되는 옵션들은 tmboot 명령과 유사하다.


tmdown -f

-A

-S

-s

-n

-t

-g

-p

-i

이진 Tmax 환경파일 이름

없음

서버 프로세스 이름

서버 이름 –k 개수

노드 이름

TMS 이름

서버 그룹 이름

서버 번호

없음


-h

-k

-q

-w

-V

Online Help

개수

RQ svg_이름

wait_sec

없음

3.2.1.1 Command

tmdown : Tmax 를 종료하기 위한 프로그램

3.2.1.2 Options

-f : tmboot 와 마찬가지로 시스템 종료 시 참조할 이진 Tmax 환경파일 이름을 지정해야 한다. 생략 시 ‘tmconfig’ 파일이 참조된다.

-A : 모든 응용 서버프로세스들을 종료 시킨다

-S : 현재 사용중인 해당 응용 서버프로세스들을 종료 시킨다.

-s : 해당 서버 프로세스를 종료 시킨다. tmboot 와 마찬가지로 관리자가 지정한 개수만큼 동작 중인 해당 서버 프로세스를 종료 시킨다(-k 옵션으로 프로세스 개수 지정).

-n : 해당 노드의 응용 서버프로세스들을 종료 시킨다. 사용되는 노드 이름은 Tmax 환경파일의 NODE 절에 정의되어야 한다. 멀티 노드의 환경에서는 반드시 지정되어야 한다.

-t : 해당 tms 를 종료 시킨다

-g : 해당 서버그룹의 서버프로세스들을 종료 시킨다. 사용되는 그룹이름은 Tmax 환경파일의 SVRGROUP 절에 정의된 것과 같아야 한다.

-p : 특정 서버프로세스를 종료 시킨다. s 옵션에 의한 종료와 달리 tmadmin 에서 “st –p” 명령으로 확인할 수 있는 프로세스 번호(spr_no)를 사용하여 특정 프로세스를 종료 시킬 수 있다.

-i : tmdown 명령을 즉시 수행한다. 기본적으로 tmdown 명령은 해당 업무를 모두 종료하고 수행되지만 i(immediately) 옵션에


의한 종료는 현재 수행중인 업무를 무조건 중단하기 때문에 신중하게 사용해야 한다.

-k : -s, -t 와 함께 사용되며, 프로세스의 개수를 지정한다.

-q : RQS 를 종료한다.

-w : 지정해준 시간(초) 후에 종료한다.

-V : tmdown 실행 파일의 버전을 알 수 있다.


4 Tmax 관리

Tmax 시스템이 동작하고 있다면, 현재 환경설정에 대한 정보를 확인해 보고 이를 동적으로 변경한다든지, 서버 프로그램에 서비스를 추가하는 등의 시스템에 대한 관리가 필요하다. 또한 제공되는 서비스들 중 특정 서비스에 대하여 현재 처리 상태 즉, 몇 건의 서비스를 처리해 왔으며, 평균 처리 시간이 얼마나 되며, 몇 건의 요청이 대기하고 있는지, 그 서비스를 제공받기 위해서는 얼마나 기다려야 하는지 등의 정보를 확인할 필요가 있다.

이 정보에 따라 서버프로세스를 더 기동 시켜 준다든지 아니면 종료 시키는 등의 조치도 필요하다.

Tmax 시스템은 tmadmin 을 제공하여 command interpreter 형태의 명령어를 이용하여 동적인 시스템 관리를 할 수 있다.

4.1 Tmax 어드민 툴

tmadmin 프로그램은 UNIX 환경의 shell 과 비슷한 Command Interpreter 이다. 즉, 항상 프롬프트 상태로 대기중이다가 입력되는 명령어를 해석하여 이를 실행하게 된다.

여러 노드를 한 도메인으로 사용하는 경우 tmadmin 으로 전체에 대한 중앙 관리가 가능하며, 각각의 노드별로 로컬에서 관리가 가능하다. tmadmin 의 내용은 아래 표와 같다.

Command Option Description

tmadmin -l

-s

-m

-h

자신의 노드만 로컬로 관리.

read-only 모드로 관리. (기본값)

master 모드로 관리

옵션을 보여줌


-f [Config File]

-n [Node Name]

-v

-p

지정해준 이진파일 관리

특정 노드만 관리

tmax 의 버전을 보여줌

st –p, st –s, si, ci, cfg 의 명령어

수행 시 화면 단위로

출력하도록 함 (more 기능)

4.1.1 Command

tmadmin : Tmax system 관리를 위한 프로그램

4.1.2 Options

-l : racd 를 통하여 여러 노드로 구성된 시스템들이 중앙에서 집중 관리될 경우에, 로컬 노드만을 관리하기 위해서 사용하는 옵션이다. 각각의 노드들은 이 옵션으로 자신의 시스템 만을 관리할 수 있게 된다.

-s : 읽기 전용 모드로 각각의 tmadmin 툴을 10 개까지 띄울 수 있는 옵션이다. 이 옵션을 사용하면 환경을 동적으로 변경시킬 수 없다.

-m : 마스터 모드로 동적으로 환경을 변경할 수 있다. 한 명의 사용자만이 마스터 모드를 사용할 것을 권장한다. 한 명 이상의 사용자가 환경 변경을 할 경우 심각한 시스템 문제가 발생할 수 있다. 환경파일은 변경하지 않고 정해진 매뉴얼을 따른다.

-f : 환경파일을 디폴트(tmconfig)가 아닌 다른 파일명으로 이진 파일을 생성한 경우 tmadmin 기동 시 이 이진 파일명을 지정해 주는 것이다.

-n : 특정 노드에 대한 모니터링이 가능하도록 한다. 즉, 멀티 노드 환경에서 tmadmin 을 구동 시키는 경우, -n <nodename>을 설정하면 지정된 노드에 대한 정보만을 확인함으로써 보다 편리하게 시스템을 관리할 수 있다.

-v : Tmax 의 version 을 확인할 수 있게 한다. -v 옵션을 사용하면, Tmax 기동과 상관없이 어느 위치에서나 version 확인이 가능하다.


-p : st –p, st –s, si, ci, cfg 의 명령어 수행 시 결과가 화면 단위로 출력되도록 하는 옵션이다.

4.1.3 인터프리터 형태의 시스템 관리

tmadmin 프로그램은 다음과 같이 실행한다.

$tmadmin

아래와 같은 메시지와 함께 프롬프트(prompt)가 나타난다. 이것은 tmadmin 프로그램 실행 상태임을 나타낸다.

--- Welcome to Tmax Admin (Type “quit” to leave) ---

$$1 tmax1 (tmadm):

tmadmin 에서 사용 가능한 명령어들은 다음의 표와 같아.

명령어 내용

tmaxinfo(ti)

cliinfo(ci)

svrinfo(si)

txquery(txq)

history(hist)

!

config(cfg)

stat(st)

suspend(sp)

resume(rs)

qpurge(qp)

set

cfgadd(ca)

Tmax 시스템 정보 확인.

접속 클라이언트 확인.

서버 정보확인.

트랜잭션 처리 정보 확인.

이전에 저장된 명령어 보기.

직전 명령어 반복.

환경설정 내용 조회.

프로세스 및 서비스 상태 통계.

동작 중인 서버 프로세스중지.

중지된 서버 프로세스 재개.

큐에 적재된 업무 삭제.

현재 설정된 환경 값을 동적으로 변경.

동적으로 서비스 추가.


rebootsvr(rbs)

discon(ds)

logstart(logs)

logend(loge)

repeat(r)

rqstat(rqs)

quit(q)

help(h)

nodeset(ns)

nodeunset(nus)

tmd

restat

서버 프로그램교체.

접속 중인 클라이언트 강제로 해제.

Logging 시작.

Logging 종료.

Command 반복.

RQ 의 상태

tmadmin 종료

사용가능한 옵션 리스트

멀티노드환경에서 특정 노드에 대한 정보만을

얻고자 하는 경우에 사용.

멀티노드환경에서 특정 노드에 대한 정보를

얻고자 set 한것을 해제.

가상의 클라이언트 애뮬레이터로서 서비스

프로그램의 유효성을 검토하는 경우 클라이언트

프로그램을 별도로 작성하지 않고 이

유틸리티를 이용

특정 서버 프로세스 혹은 모든 프로세스의

통계정보를 리셋시킴

tmadmin 툴에서는 이러한 명령어들을 통하여 Tmax 시스템을 기동 시키거나 종료 시킬 수 있으며, 현재 동작중인 시스템의 환경설정 내용을 조회 및 수정할 수 있다. 또한 각 서버프로세스의 상태와 서비스의 처리상태 등을 확인할 수 있다.

tmadmin 툴을 끝내기 위해서는 ‘quit’이나 ‘q’ 명령이 사용된다

$$1 tmax1 (tmadm):quit

4.2 정보 출력

tmadmin 프로그램의 명령어들은 용도에 따라 크게 다음과 같이 나눌 수 있다.


정보 출력

ti, ci, si, txq, rqs, history, !, config, stat, restat

동작 관리

suspend, resume

rbs (reboot server),

cfgadd (configuration add),

set,

qp (queue purge),

logstart, logend

repeat

st, si 의 명령어에서 Wild card 를 사용할 수 있다.

4.2.1 환경정보

4.2.1.1 tmaxinfo (ti)

현재 접속된 Tmax 시스템의 환경정보를 알려 준다. 시스템 버전(version), 최대 사용자수(maxuser) 등을 확인할 수 있다.

Tmax System Info: REAL version 3.8.5:

maxuser = UNLIMITED,

domaincount = 1,

nodecount = 1,

svgrpcount = 3,

svrcount = 14, svccount = 20

rout_groupcount = 0, rout_elemcount = 0

cousin_groupcount = 0, cousin_elemcount = 0

backup_groupcount = 0, backup_elemcount = 0

Tmax All Node Info: nodecount = 1:

----------------------------------------------------------------

no name portno racport shmkey shmsize minclh maxclh

----------------------------------------------------------------


0 tmaxs1 8844 3443 79970 19548 1 2

4.2.1.2 clientinfo(ci)

현재 접속된 클라이언트의 환경정보를 알려 준다. 현재 상태(status), 접속 IP Address, 처리건수(count)와 같은 클라이언트의 제반 정보를 확인할 수 있다. –s 옵션으로 연결된 총 클라이언트의 개수를 파악할 수 있다.

$$1 tmax1 (tmadm): ci

CLH 0:

----------------------------------------------------------------

cli_id status count lastin_time ipaddr usrname

----------------------------------------------------------------

0 RDY 0 20 61.77.153.1

1 RDY 2 10 61.77.153.1 tmax

2 RDY 4 123 61.77.153.1

----------------------------------------------------------------

Total Connected Clients = 1

----------------------------------------------------------------

4.2.1.3 svrinfo(si)

현재 동작 중인 각 서버의 정보를 알려 준다. 즉, 현재 상태(status), 처리 건수(count), 큐잉 건수(qcount), 큐에서 삭제된 건수(qpcount), 최대 큐잉 건수(maxqcount)를 초과하여 반환된 건수(emcount) 등을 확인할 수 있다.

$$5 tmaxs1 (tmadm): si

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

clh svrname (svri) status count qcount qpcount emcount

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

0 scoresdl ( 0) NRDY 0 0 0 0

0 bank2 ( 1) RDY 0 0 0 0

0 svr1 ( 2) RDY 0 0 0 0

0 svr2 ( 2) RDY 0 0 0 0

0 svr3 ( 2) NRDY 0 0 0 0

0 api ( 2) RDY 0 0 0 0

0 syncrtn ( 2) RDY 0 0 0 0

0 ucs ( 2) NRDY 0 0 0 0

0 ucssvr ( 2) RDY 0 0 0 0

0 broad ( 2) NRDY 0 0 0 0

0 selins ( 2) NRDY 0 0 0 0


4.2.1.4 txquery (txq)

현재 처리 중인 트랜잭션 정보를 알려 준다. 현재 접속되어 처리중인 클라이언트 식별 번호(cli_id)와 트랜잭션 처리 시작 시간(txstime), 현재 트랜잭션 큐에 쌓여 있는 트랜잭션 큐잉 건수(txqcount), 트랜잭션 처리 건수(txrcount), 트랜잭션 식별 번호(XID), 트랜잭션의 처리 상태(txstate TXBEGIN, TXCOMMIT, TXROLLBACK), 통신 프로토콜 처리 상태(xastate) 등 다양한 정보를 확인할 수 있다.

$$14 tmax1 (tmadm): txq

CLH0:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cli_id txstime txqcount txrcount XID txstate xastate

- - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - -

c0023 8:33:34 1 0 000:000:00022 TXBEGIN TX_OK

c0024 18:33:34 1 0 000:000:00023 TXBEGIN TX_OK

c0025 18:33:34 1 0 000:000:00024 TXBEGIN TX_OK

c0026 18:33:34 1 0 000:000:00025 TXBEGIN TX_OK

c0027 18:33:34 1 0 000:000:00026 TXBEGIN TX_OK

c0028 18:33:34 1 0 000:000:00027 TXBEGIN TX_OK

c0029 18:33:34 1 0 000:000:00028 TXBEGIN TX_OK

c0030 18:33:34 1 0 000:000:00029 TXBEGIN TX_OK

c0031 18:33:34 1 0 000:000:00030 TXBEGIN TX_OK

4.2.1.5 rqstat (rqs)

현재 사용 가능한 RQ 의 상태를 보여주거나 디스크 큐에 쌓여있는 서비스를 사용자가 처리할 수 있다.

-f 옵션과 -c 옵션을 사용하여 RQ 를 처리하기 위해서는 tmadmin -m 옵션을 사용하여 마스터 모드로 들어가야 한다.

-l : 사용 가능한 rq 를 보여준다.

$$15 tmax1 (tmadm): rqs -l

list of available RQs:

rq1 rq2

-s rqname : 해당 rq 의 상태를 보여준다.

$$15 tmax1 (tmadm): rqs -s rq1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Number of queue entries

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -


request 0

reply 0

fail 0

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Accumulated queue activities

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

request enqueued 0

request dequeued 0

reply enqueued 10

reply dequeued 0

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-f rqname : rq 내에 쌓여있는 서비스를 처리한다.

$$15 tmax1 (tmadm): rqs -f rq2

RQ(rq2) flushed

-c rqname :정체된 RQ 를 제거한다

$$15 tmax1 (tmadm): rqs -c rq2

RQ(rq2) statics cleared

4.2.1.6 history

shell 에서와 같이 명령어를 기억함으로써 편리하게 사용할 수 있다.

$$15 tmax1 (tmadm): history

5 : si

4 : txq

3 : ci

2 : st -p

1 : st -s

0 : ci

! 로 직전 명령어를 반복 할 수 있으며 history 에서 출력된 번호를 사용하여 명령을 재실행 할 수도 있다.

$$21 tmax 1 (tmadm): !5

si

----------------------------------------------------------------

clh svri status count qcount qpcount emcount

----------------------------------------------------------------

0 0 RDY 2 0 0 0

0 1 RDY 0 0 0 0


0 2 RDY 0 0 0 0

0 3 RDY 45 0 0 0

$$21 tmax 1 (tmadm): !

si

----------------------------------------------------------------

clh svri status count qcount qpcount emcount

----------------------------------------------------------------

0 0 RDY 2 0 0 0

0 1 RDY 0 0 0 0

0 2 RDY 0 0 0 0

0 3 RDY 45 0 0 0

4.2.1.7 config (cfg)

현재 동작 중인 시스템의 환경정보를 알려 준다. 즉, 환경파일에서 정의된 도메인, 노드, 서버그룹, 서버, 서비스별로 디폴트 값까지 포함한 모든 환경정보를 확인할 수 있다.

config 명령어에는 다음과 같은 옵션이 있다.

Options Description

-d

-n

-g [Server Group Name]

-v [Server Name]

-s [Service Name]

-f

-pr

-r

-b

Domain

All Node

Server group

Server

Service

Topend’s function

Topend’s product

Routing

Backup


4.2.1.8 도메인에 대한 환경정보

도메인에 대한 환경정보를 확인하기 위해서는 ‘-d’옵션을 사용한다. 이를 이용하면 환경파일의 DOMAIN 절과 관련된 모든 항목 내용과 도메인에 존재하는 노드 개수(nodecount), 서버그룹 개수(svgcount), 부하조절을 위한 복사 서버그룹의 개수(cousin_gcount, cousin_count), 라우팅 개수(routcount, relem_count), 노드간 장애를 감지하는 시간간격 등의 정보를 확인할 수 있다.

<참고> cousin_gcount는 COUSIN항목이 정의된 그룹 개수 즉, 복사가 이루어진 그룹 개수이고 cousin_count는 모든 복사본 서버그룹들의 개수이다. 또한 routcount는 ROUTING절에 정의된 라우팅 개체의 개수이고, relem_count는 각 라우팅 개체의 범위항목에 정의된 각 범위별 라우팅 단위 개수이다 $$4 tmax1 (tmadm): cfg -d

domain_name = tmax1,

shmkey = 79990,

minclh = 1,

maxclh = 3,


portno = 8850,

racport = 3333,

cmtret = YES,

blocktime(bt) = 30,

txtime(tt) = 0,

nliveinq(ni) = 30,

security = NONE,

cpc = 1,

maxfunc = 0,

clichkint = 0,

idletime = 0,

node_count = 1,

svg_count = 4,

svr_count = 10,

cousin_count = 0,

cousin_gcount = 0,

backup_count = 0,

backup_gcount = 0,

rout_count = 0,

rout_gcount = 0,

maxsacall = 8,


maxcacall = 16,

nclhchkint = -1,

maxconv_node = 16,

maxconv_server = 8,

maxnode = 32,

relem_count = 0

maxsvg = 32,

maxspr = 64,

maxsvr = 64,

maxsvc = 512,

maxcpc = 32,

maxtms = 32,

maxrout = 16,

maxroutsvg = 32,

maxrq = 2,

maxgw = 2,

maxcousin = 16,

maxcousinsvg = 32,

maxbackup = 16,

maxbackupsvg = 32,

maxtotalsvg = 64,

maxprod = 0

4.2.1.9 전체 노드에 대한 환경정보

전체 노드에 대한 환경정보를 확인하기 위해서는 ‘-n’옵션이 사용된다. 이를 이용하면 환경파일의 NODE 절과 관련된 모든 항목 내용과 시스템에서 내부적으로 정의된 노드 번호(node_no), 노드내에 존재하는 서버그룹 개수(svgcount)와 서버 개수(svrcount), 서비스 개수(svccount), 노드에서 동작중인 CLH 프로세스 개수(curclh), 동작 가능한 최대 서버프로세스들의 개수(maxsprs) 와 최대 TMS 프로세스 개수(maxtms)등의 정보를 확인할 수 있다

$$2 tmax1 (tmadm): cfg -n

node_name = tmaxs1, lnid = tmaxs1, node_no = 0

load = 0,

shmkey = 79990,

minclh = 1,

maxclh = 3,

clhqtimeout(hqt) = 0,



portno = 8850,

racport = 3333,

tmaxdir = /user2/starbj81/tmax3816/,

appdir = /user2/starbj81/tmax3816/appbin/,

pathdir = /user2/starbj81/tmax3816/path/,

tlogdir = /user2/starbj81/tmax3816/log/tlog/,

slogdir = /user2/starbj81/tmax3816/log/slog/,

ulogdir = /user2/starbj81/tmax3816/log/ulog/,

envfile = ,

svgcount = 4,

svrcount = 10,

svccount = 15,

curclh = 1,

ipcperm = 1c0,

clichkint = 0,

idletime = 0,

tmmopt = ,

clhopt = ,

realsvr = ,

rscpc = 4,

maxsvg = 32,

maxsprs = 64,

maxsvr = 64,

maxtmss = 32,

maxcpc = 32,

maxgwsvr = 2,

maxrqsvr = 2,

maxgwcpc = 8,

autobackup = YES,

logoutsvc =

4.2.1.10 서버 그룹에 대한 환경정보

서버그룹에 대한 환경정보를 확인하기 위해서는 ‘-g’옵션이 사용된다. 서버그룹 이름을 지정하면 그 서버그룹에 대한 정보만을, 이름을 지정하지 않으면 모든 서버그룹에 대한 정보를 출력한다.

이를 이용하면 서버그룹별로 각 서버그룹에 대하여 환경파일의 SVRGROUP 절과 관련된 모든 항목 내용을 확인할 수 있다

$$1 tmax1 (tmadm): cfg -g svg2


svg_name = svg2, svg_no = 1

dbname = ORACLE,

openinfo = ORACLE_XA+Acc=P/scott/tiger+SesTm = 60,

closeinfo = ,

appdir = ,

ulogdir = ,

svgtype = TMAX,

envfile = ,

tmsname = svg1_tms,

mintms = 2,

maxtms = 3,

load(ld) = -1,

tms starti = 0,

tms endi = 2,

4.2.1.11 서버에 대한 환경정보

서버에 대한 환경정보를 확인하기 위해서는 ‘-v’옵션이 사용된다. 서버이름을 지정하면 그 서버에 대한 정보만을, 이름을 지정하지 않으면 모든 서버에 대한 정보를 출력한다.

이를 이용하면 서버별로 각 서버에 대하여 환경파일의 SERVER 절과 관련된 모든 항목 내용과 내부적으로 정의된 서버 번호(svr_no), 서버와 관련된 데이터 의존형 라우팅 정보(ddri)를 확인 할 수 있다.

$$3 tmax1 (tmadm): cfg -v kapi1

svr_name = kapi1, svr_no = 0

svgno = 0,

cursvr = 1,

clopt = ,

seq = -1,

minsvr = 5,

maxsvr = 10,

ulogdir = ,

maxqcount(mq) = -1,

asqcount(aq) = -1,

conv = NO,

ddri = DDR_NO_ROUT,

restart(rs) = YES,

maxrstart(mr) = 5,

gperiod(gp) = 86400,


svrtype = TMAX_STD,

schedule = FA,

cpc = 1

4.2.1.12 서비스에 대한 환경정보

서비스에 대한 환경정보를 확인하기 위해서는 ‘-s’옵션이 사용된다. 서비스 이름을 지정하면 그 서비스에 대한 정보만을, 이름을 지정하지 않으면 모든 서비스에 대한 정보를 출력한다.

이를 이용하면 서비스별로 각 서비스에 대하여 환경파일의 SERVICE 절과 관련된 모든 항목 내용을 확인할 수 있다.

$$4 tmax1 (tmadm): cfg –s

- - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - -

svc_name prio(pr) autotran svctime(st) routno svrname svgno

- - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - -

SDLSEL 50 YES 0 –1 sdlsel 1

SSYNC 50 NO 0 –1 kapi 10

SYNC 50 NO 0 –1 kapi 10


4.2.2 동작 상태 정보

시스템 동작 상태를 볼 수 있는 “st”등의 명령으로 나타나는 결과에서 status 열에 다음과 같은 상태 정보가 있습니다.

Status 설명

RDY

NRDY

RUN

Unregisted

Ready 상태

Non-Ready 상태

실행 중

등록되지 않은 상태

NRDY : NRDY 인 경우는 tpstart 하고 client 가 socket 으로 연결이 맺어진 상태에서 server 로 부터의 data 전송이 안되는 경우에 발생할 수 있는 status 입니다. 예를 들면, network 상태가 좋지 않을 경우에 발생 할 수 있습니다.

Unregisted : client 에서 tpend 직후에 잠시 나왔다가 status 가 변경이 됨.

4.2.2.1 stat (st)

실질적인 시스템 동작 상태를 나타내며, 동작중인 서버프로세스와 서비스에 대한 정보를 알 수 있다. 즉 서버프로세스의 현재 상태, 처리중인 서비스 이름, 처리한 서비스 개수, 서비스에 대한 상태, 서비스 큐에 존재하는 서비스 요청 개수등과 같은 동적인 정보를 확인할 수 있다.

stat 명령어의 약어는 ‘st’이며, 다음과 같은 옵션들이 제공된다:

옵션 내용

-p [서버 프로세스 이름] 서버 프로세스에 대한 정보를 보여준다.

-s [서비스 이름] Service 에 대한 정보를 보여준다.


-t [tms 이름] tms 에 대한 정보를 보여준다.

-v [서버 프로세스 이름] 서버 프로세스에 대한 정보를 보여준다. (si 와 동일)

-o [sort 할 조건] st(-s, -p) 명령어로 정보를 출력할 때

원하는 조건에 따라 sort 하여 출력할 수

있다.

-n [출력되는 메시지

라인] sort 되어 출력되는 메시지 라인을

지정할 수 있다.

-x st(-s, -p) 명령어로 정보를 출력할 때 더

세세한 결과를 볼 수 있다. (최소/최대

서비스 수행 시간, fail count, error count)

4.2.2.2 서버 프로세스에 대한 정보 (–p)

Tmax 시스템에서 동작하는 개별적인 서버프로세스에 대한 정보를 알 수 있다. Tmax 환경파일에 등록된 서버는 MIN 과 MAX 항목을 사용하여 여러 개 동작할 수 있는데, 이들 각각의 동작 상황을 확인할 수 있다. 즉, 각 서버별 프로세스의 id(spr_no), 서버프로세스가 속해있는 서버그룹이름(svgname), 현재 상태(status), 처리한 서비스 개수(count), 프로세스 평균처리시간(avg), 처리중인 서비스 이름(svc)등이 출력된다.

‘-p’옵션을 사용하여 서버 이름을 지정하면 해당 서버이름의 서버프로세스들에 관한 정보들이 출력되고, 그렇지 않으면 동작중인 모든 서버프로세스들에 대한 정보가 출력된다.

또한 st –p 명령의 마지막 라인에 총 처리 건수, 전체 평균 처리 시간, 현재 수행 중인 총 서비스 개수 통계 정보를 출력하여 한 눈에 개괄적인 시스템 처리 현황을 파악할 수 있다.

$$7 (tmadm): st –p

CLH 0 :

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -



- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svr1 svg1 1 RDY 1 0.001 -1

svr2 svg1 2 RDY 1 0.001 -1

svr3 svg1 3 RDY 1 0.001 -1

syncrtn svg1 4 RDY 1 0.001 -1


ucs svg1 6 RDY 1 0.001 -1

ucs svg1 7 RDY 1 0.001 -1

ucs svg1 8 RDY 1 0.001 -1

_rqsvg rqsvg1 9 RDY 1 0.001 -1

_rqsvg rqsvg1 10 RDY 1 0.001 -1

TOTAL COUNT = 1

TOTAL AVG = 0.001

TOTAL RUNNING COUNT = 0

wild card 사용도 가능하다. st –p s*하면 s 로 시작하는 svr_name 에 관한 정보만을 보여준다.

$$7 (tmadm): st –p s*

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svr1 svg1 1 RDY 0 0.000 -1

svr2 svg1 2 RDY 0 0.000 -1

svr3 svg1 3 RDY 0 0.000 -1



또한 ‘-t’옵션을 사용하면 tms 서버 프로세스들에 대한 정보가 출력된다.

$$7 (tmadm): st –t

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svr_name svgname spr_no status count avg

- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

tms_ora svg1 1 RDY 0 0.000

tms_ora svg1 1 RDY 0 0.000

4.2.2.3 서비스에 대한 정보 (–s)

Tmax 시스템에서 제공하는 서비스에 대한 동적정보를 알려 준다. 즉, 해당 서비스를 관리하는 CLH 정보(clh), 서비스 처리 건수(count), 평균


처리시간(avg), 현재 대기중인 서비스 요청 건수(cq_count), 잠시라도 대기 했던 총 서비스 요청 건수(aq_count), 평균대기시간(q_avg), 서비스의 현재 상태등이다.

‘-s’옵션을 사용하며, 서비스 이름을 지정하면 해당 서비스에 관한 정보만 출력되고, 지정하지 않으면 제공되는 모든 서비스에 관한 정보들이 출력된다.

$$7 (tmadm): st –s

CLH 0:

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svc_name svr_name count avg cq_count aq_count q_avg status

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

FORW svr1 0 0.000 0 0 0.000 RDY

COMVER svr1 3 0.670 0 0 0.000 RDY

REGIST svr1 0 0.000 0 0 0.000 RDY

VIEW svr1 0 0.000 0 0 0.000 RDY

SYNC svr1 10 0.000 0 0 0.000 RDY

ASYNC svr1 0 0.000 0 0 0.000 RDY

CONVER_R svr1 0 0.000 0 0 0.000 RDY

wild card (st -s *W)를 사용하여 W 자로 끝나는 서비스에 대한 정보만을 볼 수 있다.

$$7 (tmadm): st –s *W

CLH 0:

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

FORW svr1 0 0.000 0 0 0.000 RDY

VIEW svr1 0 0.000 0 0 0.000 RDY

4.2.2.4 결과를 조건별로 sort 하여 출력 (–o)

Tmax 시스템에서 제공하는 서버 프로세스와 서비스에 대한 동적 정보를 보고자 할 때 특정 조건을 바탕으로 소트하여 원하는 정보를 볼 수 있도록 한다.

sort 할 조건으로는 다음과 같은 것들이 있다.

내림 차순으로 sort


조건 설명

ca

aa

cq

aq

qa

ce

ae

처리한 건수(count)

평균 처리 시간(avg)

현재 큐잉 건수(cq_count)

평균 큐잉 건수(aq_count)

평균 큐잉 시간(q_avg)

각 서버별 처리 건수를 기준으로

서버별로 sort

각 서버별 평균 처리 시간을

기준으로 서버별로 sort

오름 차순으로 sort

조건 설명

ca-

aa-

cq-

aq-

qa-

ce-

ae-

처리한 건수(count)

평균 처리 시간(avg)

현재 큐잉 건수(cq_count)

평균 큐잉 건수(aq_count)

평균 큐잉 시간(q_avg)

각 서버별 처리 건수를 기준으로

서버별로 sort

각 서버별 평균 처리 시간을

기준으로 서버별로 sort

결과를 특정 조건을 기준으로 sort 되어 출력하기 위한 –o 옵션은 반드시 –p 옵션이나 –s 옵션과 함께 사용되어야 한다.

$$7 (tmadm): st –p –o ca


CLH 0 :

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svr2 svg1 37 RDY 10 0.000 -1

svr1 svg1 36 RDY 6 0.000 -1

svr3 svg1 38 RDY 2 0.000 -1

TOTAL COUNT = 18

TOTAL AVG = 0.000


$$7 (tmadm): st –s –o ca

CLH 0:

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

TOUPPER svr2 10 0.000 0 0 0.000 RDY

SDLTOUPPER svr1 5 0.000 0 0 0.000 RDY

FDLTOUPPER svr3 2 0.000 0 0 0.000 RDY

SDLTOLOWER svr1 1 0.000 0 0 0.000 RDY

FDLTOLOWER svr3 0 0.000 0 0 0.000 RDY

TOLOWER svr2 0 0.000 0 0 0.000 RDY

4.2.2.5 출력되는 메시지의 라인 수 지정 (-n)

-n 옵션은 sort 되어 출력되는 메시지 라인(서버 프로세스 또는 서비스의 개수) 을 지정할 수 있도록 하는 옵션으로써 반드시 –o 옵션과 함께 사용되어야 한다.

$$7 (tmadm): st –p –o ca –n 2

CLH 0 :

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

svr2 svg1 37 RDY 10 0.000 -1

svr1 svg1 36 RDY 6 0.000 -1

TOTAL COUNT = 18

TOTAL AVG = 0.000



$$7 (tmadm): st –s –o ca –n 3

CLH 0:

- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -


- -- - - - - - - - - - - - -- - - - - - - - - - - - - - - - - -

TOUPPER svr2 10 0.000 0 0 0.000 RDY

SDLTOUPPER svr1 5 0.000 0 0 0.000 RDY

FDLTOUPPER svr3 2 0.000 0 0 0.000 RDY

4.2.2.6 결과에 대한 더 자세한 정보 보기 (-x)

-x 옵션은 ‘st –p’ 또는 ‘st –s’ 명령어를 이용하여 서버 프로세스나 서비스의 상태를 조회할 때 최소/최대 서비스 수행 시간인 mintime 과 maxtime, TPESVCFAIL 이 발생한 경우인 fail_cnt, 서버가 TPESVCFAIL 이외의 다른 에러를 넘겨준 경우인 err_cnt 등의 정보를 추가적으로 조회할 수 있도록 해 주는 명령어로 반드시 –s 옵션이나 –p 옵션과 함께 사용되어야 한다.

$$1 tmaxh2 (tmadm): st -s -x

CLH 0:

----------------------------------------------------------------

svc_name svr_name count cq_cnt aq_cnt q_avg avg status

fail_cnt err_cnt mintime maxtime

----------------------------------------------------------------

SVC01011 svr01011 1200 0 0 0.000 0.004 RDY

5 6 0.000 0.013

$$1 tmaxh2 (tmadm): st -p -x

CLH 0:

----------------------------------------------------------------


PID fail_cnt err_cnt min_time max_time

----------------------------------------------------------------

svr01011 svg1 36 RDY 1200 0.004 -1

18375 5 6 0.000 0.013

----------------------------------------------------------------

TOTAL COUNT = 1200

TOTAL SVCFAIL COUNT = 5


TOTAL ERROR COUNT = 6

TOTAL AVG = 0.004


4.2.3 상태 정보 반복 표시 기능

4.2.3.1 repeat (Repeat Mode)

이런 방식으로도 사용될 수도 있다..

$$1 tmax1 (tmadm): r -k 30 -i 5 st -s

$$1 tmax1 (tmadm): r -k 30 -i 5 st -p

첫번째 명령어는 5 초간의 간격을 두고 ‘st -s’를 30 번 수행하는 것을 반복하라는 의미이며 두 번째 명령어는 5 초간의 간격을 두고 ‘st -p’를 30 초간 수행하는 것을 반복하라는 의미이다. 반복적인 명령어 수행은 상태 정보를 모니터링 할 뿐 아니라 업무수행에 대한 디버깅에도 많은 도움을 줄 수 있다.

4.3 운용 관리

4.3.1 서버 프로세스 운용 및 재개

4.3.1.1 suspend (sp)

응용 서버프로그램 오류 등으로 더 이상의 업무 처리가 불가능하여 이를 해결하기 위해 동작중인 서버 프로세스를 중지시킬 때 사용하는 기능이다.

명령어가 실행되면, 중지된 서버프로세스가 현재 처리중인 서비스를 정상 완료한 후 더 이상의 동작은 중지하고, 큐에 있는 서비스들은 대기 상태가 된다. 이 때 계속적으로 요청되는 서비스들은 모두 큐에 적체된다.

Suspend 명령어의 약어는 ‘sp’이며, 다음과 같은 옵션들이 제공된다:

옵션 내용

-v [서버 프로세스 이름] 서버 프로세스의 스케줄링을 막는 옵션


-s [서비스 이름] 서비스의 스케줄링을 막는 옵션

4.3.1.2 Resume (rs)

동작 중지된 서버프로세스의 활동을 재개 시킨다. 활동이 재개된 서버 프로세스는 큐에 대기중이던 서비스를 처리하기 시작하며 요청되는 서비스에 대해 처리 가능 상태가 된다.

resume 명령어의 약어는 ‘rs’이며, 다음과 같은 옵션들이 제공된다:

옵션 내용

-v [서버 프로세스 이름] 서버 프로세스의 스케줄링을 재개하는 옵션

-s [서비스 이름] 서비스의 스케줄링을 재개하는 옵션

4.3.2 프로세스 통계 정보 내용을 리셋

4.3.2.1 Restat

특정 서버 프로세스 혹은 모든 서버 프로세스의 통계정보를 리셋한다. 마스터 모드로 사용할 때만 가능하다..

옵션 내용

- v [서버 프로세스 이름] 지정된 서버 프로세스의 통계정보를 리셋

- a 모든 서버 프로세스의 통계정보를 리셋

4.3.3 서버 프로세스 변경

4.3.3.1 rbs (Reboot Server Process)

현재 사용중인 서버프로세스를 새로운 프로세스로 변경한다. TMAX_BKAPPDIR 를 .profile 의 환경변수에 지정하고 새로운 프로그램의 실행파일을 지정된 디렉토리


(예:$TMAXDIR/bkappbin)에 옮기고 다음의 명령어를 수행한다.

$$1 tmax1 (tmadm): rbs new_file old_file

new_file: 새 파일명

old_file : 사용중인 파일명

해당 이름의 서버 프로세스가 둘 이상일 경우, (예를 들어 MIN=2) 해당 프로세스를 모두 down 시키고 새로운 프로세스를 boot 시켜 처리를 하게 되면 업무의 공백상태가 발생하게 된다. 따라서 이 경우 서버 프로세스를 하나씩 down 시키면서 boot 된다. 예를 들어 svr1 서버의 MIN=2 인 상황에서 rbs 를 실행시켰을 경우, svr1 1 down -> bk_appbin 디렉토리에 임시파일(_rbs00_svr1)로 복사 -> boot -> svr1 2 down -> bk_appbin 디렉토리에 임시파일(_rbs00_svr1)로 복사 -> boot -> 와 같은 순서로 rbs 가 수행된다.

다음은 rbs 수행 과정이다.

.profile 에 아래와 같이 환경 변수를 추가한다.

export TMAX_BKAPPDIR=/data2/starbj81/tmax64/bk_appbin

환경 변수에 설정해준 것과 동일한 위치에 bk_appbin 디렉토리를 만든다

$mkdir bk_appbin

appbin 디렉토리에 있는 실행 파일을 bk_appbin 디렉토리로 복사한다.

$cp appbin/svr2 bkappbin/

tmadmin -m 을 실행한 후 rbs 를 실행시킨다.

현재 3 개의 svr2 서버 프로세스가 기동되어 있을 경우

$$1 tmaxh2 (tmadm): rbs svr2 svr2

TMBOOT for node(tmaxh2) is starting:

TMBOOT: SVR(svrname: svr2, execname:

_rbs00_svr2) is starting: Fri Dec 19 11:21:06 2003








>> 3 servers booted using tmp execfile _rbs01_svr2

>> reboot svr /data2/starbj81/tmax64/appbin/svr2

finished


$$1 tmaxh2 (tmadm): rbs svr2 svr2

>> suspend ok

>> down ok

>> cp ok

>> boot ok

>> resume ok

>> reboot svr /data2/starbj81/tmax64/appbin/svr2

finished

ps 를 이용하여 서버 프로세스가 정상적으로 boot 되었는지 확인한다.


$ps –ef | grep svr2

starbj81 21710 1 0 11:46:32 pts/ts 0:00

_rbs00_svr2 -b -21709 -S svr2 -s svr2 -d -1 -v 21689

starbj81 21713 1 0 11:46:32 pts/ts 0:00


starbj81 21716 1 0 11:46:32 pts/ts 0:00



$ps –ef | grep svr2

starbj81 21607 1 0 11:43:46 pts/ts 0:00 svr2 -s

svr2 -g 2

4.3.4 서비스 동적 추가

4.3.4.1 cfgadd (ca)

$$1 tmax1 (tmadm) : cfgadd (ca) - i cfgfile


Tmax 운영 도중, 특정 서버프로그램에 서비스가 추가될 때에 해당 서버만 다운 시킨 후 이 명령을 사용하여 동적으로 서비스를 추가 시킬 수 있다. 적용 순서는 다음과 같다.

해당 환경파일의 이름을 다른 이름으로 복사한다.

$cp tmconfig.m tmchg.m

새로 복사한 환경파일에 서비스명을 추가하고, cfl 로 –o 옵션을 주어 다른 이름의 바이너리 환경파일을 만든다.

$cfl -i tmchg.m -o tmchg

gst 로 서비스 테이블을 생성한다

$gst -f tmchg

해당 서버프로세스를 다운 시킨다.

$tmdown -S svr1

“tmadmin –m” 을 수행하고, cfgadd(ca)를 이용하여 서비스를 추가 시킨다.

$cfgadd -i tmchg

해당 서버프로그램을 컴파일 한다

$compile c svr1

해당 서버프로세스를 기동 시킨다.

$tmboot –S svr1

4.3.5 서버 동적 추가

4.3.5.1 cfgadd (ca)

새로운 서버 추가 환경화일 tmchg.m 파일을 만든 후 추가 환경만 등록시킨다.

<<tmchg.m>> *SERVER hello SVGNAME=svg1 *SERVICE

HELLO SVRNAME=hello

환경 파일을 컴파일한다.


cfl -i tmconfig.m -a tmchg.m -o tmchg

tmconfig.m 기존의 환경화일

tmchg.m 서버 추가 환경화일

서비스 테이블을 생성한다.

gst -f tmchg

cfgadd -i 로 환경 파일 추가하기.

tmaxi1@dhjang ./config > tmadmin -m

$$3 tmaxi1 (tmadm): si

-------------------------------------------------------------


-------------------------------------------------------------

0 tmaxgw ( 0) RDY 0 0 0 0

0 toupper ( 18) RDY 0 0 0 0

$$4 tmaxi1 (tmadm): cfgadd -i tmchg

config is successfully added


-------------------------------------------------------------


-------------------------------------------------------------

0 tmaxgw ( 0) RDY 0 0 0 0

0 toupper ( 18) RDY 0 0 0 0

0 hello ( 19) NRDY 0 0 0 0

아직 hello 서버는 NRDY 상태이다.

tmboot -S hello -f tmchg 하기

tmaxi1@dhjang ./config > tmboot -S hello -f tmchg

TMBOOT for node(tmaxi1) is starting:

Welcome to Tmax demo system: it will expire 2002/8/31

Today: 2002/8/19


TMBOOT: SVR(hello) is starting: Mon Aug 19

15:37:44 2002

tmadmin 에서 hello 서버가 RDY 상테인가 보기


-------------------------------------------------------------


-------------------------------------------------------------

0 tmaxgw ( 0) RDY 0 0 0 0

0 toupper ( 18) RDY 0 0 0 0

0 hello ( 19) RDY 0 0 0 0

추가 명령어 설명.

tmboot -f tmchg

tmdown -f tmchg

4.3.6 서버 그룹 동적 추가

4.3.6.1 cfgadd (ca)

방법은 새로운 추가 환경화일 만 조금 다르고, 3.6 서버 동적 추가 와 동일 합니다.

<tmchg.m> *SVRGROUP

svg2 NODENAME = "aix5l"

*SERVER

svr3 SVGNAME = svg2, MIN = 1, MAX = 10

*SERVICE

FDLTOUPPER SVRNAME = svr3

FDLTOLOWER SVRNAME = svr3

위 의 예처럼 새로 등록되는 서버그룹과 서버와 서비스를 추가 환경파일로 만든다.

이하 는 3.6 서버 동적 추가와 동일하다.


4.3.7 환경설정 값 동적 변경

4.3.7.1 set

현재 설정되어 있는 환경파일의 설정 값을 동적으로 변경할 수 있는 명령어이다. 변경 가능항목은 tmadmin 에서 cfg 명령어를 통해서 확인할 수 있다. 각 항목 중에서 괄호로서 약어를 표시한 항목이 동적으로 변경 가능한 항목이다.

$set -d[g, v, s] 도메인[서버 그룹, 서버, 서비스]명 항목 값

$$1 tmax1 (tmadm): set -d res1 bt 100

$$1 tmax1 (tmadm): set -g svg1 ld 5

$$1 tmax1 (tmadm): set -v kfdl1 mq 1000

$$1 tmax1 (tmadm): set -s SYNC pr 100

4.3.8 적체 해소

4.3.8.1 qp (Queue Purge)

업무의 폭주 현상이 발생하여 많은 업무가 적체되어 정상적으로 거래를 처리하지 못하는 경우, 현재 큐에 적체되어 있는 서비스 요청을 삭제하는 기능이다. 하루에도 수십만 건의 업무를 처리하는 은행이나 관공서에서 유용하게 사용될 수 있는 기능이다. 삭제된 업무는 클라이언트의 재요청을 통하여 다시 처리될 수 있다. Tmax 에서는 서버프로세스별로 큐를 관리함으로써 관리자는 특정 서버별로 큐를 삭제할 수 있어 타 업무의 효과적인 수행에도 도움을 준다.

-s 옵션을 사용해 큐에 쌓여있는 특정 서비스에 대한 요청을 삭제할 수도 있다.

$$1 tmax1 (tmadm): qp -v sdlsel

$$1 tmax1 (tmadm): qp -s TOUPPER

Queue Purge 명령어의 약어는 ‘qp’이며, 다음과 같은 옵션들이 제공된다:

옵션 내용

-v [서버 프로세스 이름] 큐에 쌓여있는 특정서버에 대한 요청


삭제

-s [서비스 이름] 큐에 쌓여있는 특정 서비스에 대한 요청

삭제

qp 를 통해 삭제된 서비스는 클라이언트에게 TPEQPURGE(tperrno = 27)를 반환하게 된다. 따라서 클라이언트는 이에 맞게 적절한 대처를 할 수 있다.

qp 의 내역과 이때 지워진 클라이언트의 id 는 slog 에 함께 기록된다.

4.3.9 클라이언트 연결해제

4.3.9.1 ds (Disconnect Session)

현재 접속되어 있으나 아무 일도 수행하지 않는 클라이언트를 강제 연결해제 한다. 클라이언트 정보를 얻을 수 있는 ‘ci’ 명령어로 확인 후 사용한다.

ds [-h clhno] [-f] {-a | -n | -i idle_time | -c clid}

Options Description

-h [CLH 번호]

-a

-n

-i [idle time]

-c [client ID]

-f

해당 CLH 에 연결된 클라이언트

접속해제.

모든 클라이언트 접속해제.

정확한 정보가 없는 클라이언트와의

연결해제.

(예. “tpalloc “로 할당된 버퍼는 사용하지

않는다.)

지정된 시간(초 단위)을 초과한 세션의

클라이언트

와의접속해제.

클라이언트에게 부여한 ID 번호로

접속해제.

클라이언트와의 접속을 즉시 해제하라는


옵션.

4.3.10 Logging 관리

4.3.10.1 logstart filename

4.3.10.2 logend

관리자는 tmadmin tool 을 사용하여 여러 가지 실시간 정보를 살펴볼 수 있다. 따라서 주어진 상황에 맞는 즉각적이고 효과적인 조치를 취할 수 있다. 또한 tmadmin tool 에서는 통계적 정보 분석을 위해 administrator 데이터를 로그로 남길 수 있다. Logging 파일은 현재 디렉토리에 만들어진다.

로그 데이터를 통해 업무 폭주 시간, 불필요한 서버프로세스, 큐잉 상태 등을 확인하여 전반적인 시스템 분석이 가능하다. 명령어 사용은 다음과 같다.

$$1 tmax1 (tmadm): logstart filename

$$1 tmax1 (tmadm): logend

logstart 명령어를 통해서 log 처리를 시작할 수 있으며 logend 명령어를 통해 끝낸다.

Documents

복사본 1 Tmax Administration Guide · 2019. 4. 9. · 135-708 서울시 강남구 대치동 946-1 글라스타워 18층 Tel: +82-2-6288-2114, 2006 Fax: +82-2-6288-2115 E-Mail: