server side의 TUXEDO install은 매우매우매우매우 간단합니다.
대충 다음과 같은 과정으로 볼 수 있습니다.
1) Product 설치
2) license key 설치
3) 언어설정 (optional)
4) 사용 DB에 따른 RM 섹션 구성하기
5) TMS building
대충 여기까지가 설치단계이고,
5) ubbconfig (구성파일) 구성 및 환경변수 세팅
요것은 운용단계에 속하는 얘기가 되겠습니다. 그럼 하나하나 보죠.
1) product 설치
TUXEDO 설치는 Oracle 등의 product와는 달리, 매우매우 간단합니다.
설치할 곳은 보통 /tuxedo 로 잡아주는데, 이 곳이 raw device건 filesystem이건 심지어는 mounting된 disk이건 아니건 거의 아무 생각 없습니다. -_-; (그게 그거란 소립니다;) 그냥 /tuxedo 아래에 tar 파일만 복사해다가 풀어버리면 모든게 끝나는 것이지요.
(install.sh 실행시키면 하는게 그겁니다. -_-)
TMAX의 경우는 engine 복사하는 user.. 즉 owner가 TMAX 시스템의 admin 이어야만 합니다만, TUXEDO는 그나마 이런 제한도 없습니다. 그래서 보통 tuxedo 라는 user로 engine을 설치하고, system admin user는 알아서 만들고.. 뭐 이렇게 하죠.
TUXEDO를 설치할 디렉토리는 두가지 조건만 만족하면 됩니다.
- 디스크에 공간이 있어야 한다. (200MB 정도의 공간이면 충분합니다.)
- Tuxedo admin user에게 r/w/x 권한을 줄 수 있어야 한다.
여기서 tuxedo를 설치한 디렉토리를 TUXDIR 이라는 환경변수로 지정하면 됩니다.
이렇게 해서 저 shell script가 다 돌았으면 설치 끝입니다.
TUXEDO의 uninstall은 TUXDIR에 해당하는 디렉토리를 날려주면 그걸로 끝입니다.
간단하지요? ^^;
2) license 설치하기
먼저, license가 두가지가 있다는 것을 알아야겠죠?
하나는 RTK.. 이것은 운용용 라이센스입니다. 이 라이센스 하에서는 컴파일이 불가능합니다. 만들어져있는 AP를 구동하는 것은 가능하지만 말이죠...
또 하나는 SDK. 이건 개발용 라이센스입니다. RTK에 비해 라이센스 값이 비쌉니다만, compile이 가능하므로 개발을 하고자 하면 반드시 SDK라이센스를 보유해야 하겠습니다.
license file은 보통 Floppy 디스크로 제공하지요. 하지만 뭐 그냥 인터넷으로 날려주는 경우도 있습니다. (linux용 버전의 evaluation license의 경우가 그렇죠? ^^) 좌우당간, 그 라이센스를 $TUXDIR/udataobj/lic.txt 라는 이름으로 넣어만 주면 끝입니다.
제가 대충 본 결과, 6.4 라이센스와 6.5 라이센스는 호환이 되는데, 이후 버전은 어떨지 모르겠습니다. ^^; 그리고 license 파일은 CPU의 종류나 machine의 이름이나 뭐 이런 것을 따로 필요로 하지도 않습니다. (TMAX의 경우는 machine 명과 license가 관련이 있습니다.) 아.. 7.1도 되던가? -_-; 테스트 해 본 것 같네요.. ^^;; 6.5 라이센스로 7.1도 돌아갔던 것으로 기억됩니다..
license가 잘 설치되었는지는 tmadmin -v 를 실행시켜보시면 됩니다.
css16-tuxadmin]/tuxedo> tmadmin -v
INFO: TUXEDO(r) System Release 6.5
INFO: Serial #: 1115165, Expiration NONE, Maxusers 900
INFO: Licensed to: Hanaro Telecom
이런 식으로 나옵니다.
3) 언어설정과 password 설정
먼저, 언어설정은 해도 그만 안해도 그만입니다만, TUXEDO에서는 locale을 'C'만을 지원합니다 하지만, 우리가 unix 또는 linux를 쓸 때엔 C 로케일보다는 ko나 뭐 ko_KR.eucKR 같은 로케일을 씁니다. 한글도 찍고 해야 하니까... ^^;
그래서, 보통은 LANG = C 라고 설정을 하도록 권유하는 것이 일반적이지만, 뭐 턱시도 하나 쓰겠다고 시스템 메시지나 뭐 이딴 것들을 한글로 보는 것을 포기할 필요야 없겠지요?
만일 사용하시는 로케일이 ko 다.... 그러면 이렇게 하시면 되겠습니다.
TUXEDO를 설치한 디렉토리 (TUXDIR) 로 가셔서....
cd locale
ln -s C ko
다름이 아니라, 심볼릭 링크를 만드는 겁니다. 이렇게 하시면 ko 밑으로 내려가도 C 아래에 있는 각종 메시지 파일들이 나오게 되지요. 그러면 이제부터 TUXEDO는 LANG=ko 로 되어있는 사용자들에게도 정상적으로 작동할 것입니다. 다른 LANG도 마찬가지입니다.
password 설정은, 멀티노드 도메인에서 도메인간의 통신을 통해 admin 명령들이 오갈 수 있게 해 주는 것이라고 보면 됩니다. 여기엔 총 20개의 패스워드를 등록할 수 있는데 다음 파일에 등록하면 됩니다.
$TUXDIR/udataobj/tlisten.pw
일단 한 도메인에서는 모든 노드가 같은 패스워드를 갖게 하면 무리없이 돌아갈 것입니다.
자세한 것은 TUXEDO 보안 얘기할 때 하지요.
4) RM 만들기
RM섹션은 DB에 접근하는 TUXEDO application을 만들고 실행시키는데에 있어서는 필수입니다.
처음 RM을 열어보면 이 정도로 되어있습니다.
TUXEDO/D:tuxd_switch:-lrms -lfs
TUXEDO/SQL:tuxsql_switch:-lsql -lusort -lrms -lfs
NONE:tmnull_switch:
TUXEDO/QM:tuxq_switch:-lqm -ltmib
맨 앞에 적혀있는 것이 RM section name 입니다.
이걸 만들기 위해서는.. 일단 DB를 먼저 설치를 해야 합니다.
그리고, Oracle의 경우라면 제가 예전에 이 게시판에 적어놓은 "RM 섹션 만들기"라는 글을 참고하시면 되겠습니다.
Oracle8이면 아마 대충 이렇게 나올겁니다.
Oracle8_XA:xaosw:-L/oracle8/app/oracle/product/8.1.7/lib -lclntsh
이렇게 만든 RM section 명이 나중에 ubbconfig 파일을 만들 때에 *GROUPS 절의 XA 그룹 TMS openinfo string에서 사용됩니다.
5) TMS 만들기
RM섹션까지 만들었으면 이제...
buildtms -r Oracle8_XA -o TMS_ORACLE8
이런 식으로 TMS를 만듭니다. (TMS_ORACLE8이 TMS의 이름입니다. 뭐 이름은 자유롭게 만들고 싶은대로 만들면 됩니다. ^^) TMS binary가 생성되었으면 이것을 TUXDIR의 bin 이라는 디렉토리로 옮깁니다.
cp TMS_ORACLE8 $TUXDIR/bin
뭐 이런식으로 말이죠.. ^^ 이제 TUXEDO 구동을 위한 최소한의 준비가 된겁니다.
아래 내용은 꼭 tuxedo engine owner ID로 하실 필요는 없습니다. TUXDIR만 설정해 주시고 TUXDIR에 대한 read / 실행 권한만 있으면 어느 아이디건간에 TUXEDO admin이 될 수 있습니다.
6) 환경구성법
몇가지 환경을 구성해야 합니다. 먼저...
우리가 /tuxedo에 TUXEDO를 설치했다고 가정하면..
TUXDIR = /tuxedo
LD_LIBRARY_PATH = $TUXDIR/lib:$LD_LIBRARY_PATH
(HP에서는 SHLIB_PATH 라는 이름으로 만듭니다.)
PATH = $TUXDIR/bin:$PATH
TUXCONFIG = tuxconfig를 생성시키기 원하는 full path filename
TUXCONFIG는 나중에 ubbconfig 파일.. 즉, TUXEDO 구성파일을 만든 다음에 tmloadcf로 생성시킵니다. 맨바닥에서 이 TUXEDO 구성파일을 만드는 법은, 샘플 하나 잡아다가 고쳐서 하시는 것이 좋을 것입니다. 물론 거기에 대해서도 자세하게 거론해야 한다면 거론하도록 하겠습니다. ^^
TLOGDEVICE = TLOG file이 만들어질 full path file name
TLOG file은 우리가 읽을 수 있는 내용의 DATA가 아닌 XA transaction log가 쌓입니다.
XA interface를 사용할 때, TMS에서 transaction 상태를 log에 xid 별로 기록을 하고 있다가 그걸 처리한다는 얘기가 workshop의 "Transaction Models" 절에 보면 나옵니다. 바로 그 짓을 할 log가 위치할 곳입니다. (즉, 사람 보라고 만드는 log 파일이 아니라, TMS에서 사용할 log device 명입니다.) 그걸 full path로 적어줍니다.
TLOG device는 tmadmin의 crdl 명령으로 수행합니다. 일단 TLOGDEVICE 환경변수를 갖고 있어야 이 작업이 가능할 것입니다.
ULOGPFX : ulog가 위치할 파일의 PATH와 ULOG파일의 이름 앞부분을 정의합니다.
만일 이것을 /var/log/ulog/ULOG 라고 지었다면, 이 시스템의 userlog() 함수의 output은 /var/log/ulog 디렉토리 아래에 ULOG.301002 (일/년/월 순서) 라는 식의 이름으로 생성될 것입니다.
FSCONFIG : TLOGDEVICE와 같은 값을 넣어줍니다.
APPDIR : 이건 application이 위치할 디렉토리입니다.
만일, 서버 프로그램을 하나 만들어서 띄우려고 한다면, 그 서버프로그램의 binary가 위치한 특정 디렉토리가 있겠지요? 바로 그곳입니다.
이 APPDIR 이라는 곳의 역할은 또 있습니다.
모든 process는 working directory라는 곳이 있지요. 현재 프로세스가 떠 있는 디렉토리입니다. TMAX는 이것이 "tmboot를 실행한 디렉토리"로 지정됩니다. -_-; 이것은 나름대로 꽤 황당한 결과를 가져옵니다. AP의 core가 아무데나 생긴다는 얘기가 되고, AP가 file I/O를 필요로 할 때, path를 지정하지 않은 것은 어디서 생성될지 모른다는 소리입니다. tmboot를 정해진 곳에서 수행하게 만드는 수 밖에는 없는 것이지요.
게다가, Oracle의 transaction 관련 log인 NULL_{날짜}.trc 파일이 역시 여기저기에 마구 생긴다는 것을 의미하기도 합니다. (물론 이거야 openinfo string에 directory를 지정해주면 됩니다만)
TUXEDO에서는 이 디렉토리가 APPDIR이라고 보시면 됩니다. 즉, 어느 위치에서 tmboot 명령을 주었건간에, 모든 AP는 start 되면 APPDIR로 이동합니다. 당연히 core도 이 곳에 생기지요..
또 있습니다.
TUXEDO에서 queue transfer가 여의치 않으면 file transfer를 시도합니다. 또한 reliable queue 개념에서도 filesystem을 활용하는 방법이 등장하지요? 즉, TMAX에서는 pathdir 이라는 곳에 named pipe를 생성하는 방식을 쓰는데, TUXEDO에서는 pipe를 쓰지는 않지만, Queue 전송이 여의치 않으면 file 전송으로 대체할 경우가 있습니다. 이때 쓰는 directory가 APPDIR 입니다.
다시 말하면 APPDIR이 위치하는 디스크는 항상 어느정도의 여유공간이 있어야 한다는 것을 뜻하기도 하네요. ^^;
대강 이정도면 TUXEDO를 설치하고 사용하기 위한 준비는 된 것이지요?
( ^^)/~
