1. Tuxedo 어플리케이션 시스템 장애 대처
Tuxedo 시스템에서 제공되는 장애 대처를 위한 기능은 아래와 같이 정리 할 수 있고 각 방법을 어플리케이션의 구성이나 시스템 구성에 따라 적용 할 수 있다.
l 데이터 의존 라우팅 (Data-Dependent-Routing)을 이용한 장애 대처
l Replicated Server Process들간의 부하 분산을 이용한 장애 대처
l 그룹 마이그레이션 을 이용한 장애 대처
l 상황별 장애 대처
이 후에 기술된 각 장애 대처 방안을 확인 하고 어플리케이션 시스템에 적용 가능한 장애 대처 방안을 적용한다. 이러한 장애 대처 방안 적용을 위한 절차는 아래와 같이 요약 할 수 있다.
① Tuxedo 시스템에서 제공되는 장애대처 방안 검토한다.
② 어플리케이션 시스템에 적용가능 여부 확인한다.
③ 어플리케이션 구성 방안에 따른 각 시스템별로 서버를 확정한다.
④ 어플리케이션 장애 대처 시나리오를 작성한다.
⑤ 위의 시나리오 적용을 위한 스크립트를 작성한다.
⑥ 장애 대처 시나리오에 의한 테스트 방안을 마련한다.
⑦ 장애 대처 테스트를 진행한다.
⑧ 장애대처 방안을 확정 적용한다.
2. 데이터 의존 라우팅을 이용한 장애 대처
어플리케이션 시스템에 ‘데이터 의존 라우팅’을 설정해서 사용하는 경우 2 차 라우팅 포인트를 설정해서 만일의 서버 장애에 대처한다. 이러한 ‘데이터 의존 라우팅에 의한 장애 대처’는 아래와 같은 조건에서 사용 가능하다.
l Oracle의 OPS를 사용하는 경우와 같이 각 시스템이 각자의 데이터베이스를 가지면서 타 시스템의 데이터베이스를 액세스할 수 있다.
l 각 지역 서버의 데이터를 본사 서버에도 두는 경우와 같이 노드 별로 데이터의 복사본을 가지고 있다.
‘데이터 의존 라우팅에 의한 장애 대처’를 위한 설정은 각 시스템 별 서비스의 라우팅을 정해 놓고 장애 시를 대비하여 2차 (필요한 경우 3차 이상) 라우팅 포인트를 정해준다. 이 경우 장애가 발생하면 첫번 라우팅이 실패 하면 다음 라우팅 포인트의 서비스가 수행된다.
위 그림과 같은 구성을 위해 아래와 같이 2차 데이터 의존 라우팅 포인트를 아래와 같이Tuxedo 환경 설정 파일에 설정한다.
|
…. *SERVICES DEFAULT : TRANTIME=30 AUTOTRAN=Y
WITHDRAWAL ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
TRANSFER ROUTING=ACCOUNT_ID
INQUIRY ROUTING=ACCOUNT_ID
*ROUTING ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE="FML" RANGES="10000-59999:GROUP1, ->1차 라우팅 10000-59999:GROUP2, ->2차 라우팅 60000-109999:GROUP2, ->1차 라우팅 60000-109999:GROUP1" ->2차 라우팅 …. |
3. Replicated Server Process들간의 부하 분산을 이용한 장애 대처
부하 분산을 위해 같은 서버를 다른 하드웨어 시스템에 업 로드 해서 운영하는 경우 하나의 시스템의 장애 시 다른 시스템의 어플리케이션 서버에 의해 장애 대처가 가능하다. 아래와 같은 구성을 위해 Tuxedo 환경 설정 파일은 아래와 같이 설정한다.
|
…. *SERVERS DEFAULT : CLOPT="-A -r" RESTART=Y MAXGEN=5
TLR SRVGRP=GROUP1 SRVID=1 MIN=1 MAX=5 RQADDR="tlr1"
TLR SRVGRP=GROUP2 SRVID=6 MIN=1 MAX=5 RQADDR="tlr2"
WSL SRVGRP=WSGRP1 SRVID=70 CLOPT="-A -- -n 0x0002a003dffefe0f -w WSH -m 1 -M 4 -x 10"
WSL SRVGRP=WSGRP2 SRVID=71 CLOPT="-A -- -n 0x0002b003dffefe01 -w WSH -m 1 -M 4 -x 10" …. |
4. 그룹 마이그레이션 을 이용한 장애 대처
장애 발생시 아래 그림과 같이 장애 시스템에서 운영되던 Tuxedo 어플리케이션 서버를 다른 시스템으로 그룹 마이그레이션으로 장애 시스템에서 운영되던 Tuxedo 어플리케이션 서버의 서비스가 계속 되도록 한다. 이 설정을 위한 Tuxedo 환경 설정 파일 설정은 아래와 같이 그룹 섹션에 대한 설정에서 로지컬 머신 아이디에 대한 설정을 2개로 설정한다.
|
…. *GROUPS
GROUP1 LMID=SITE1, SITE2 GRPNO=1 TMSNAME=TMS_ORACLE7 TMSCOUNT=2 OPENINFO=”Oracle_XA:Oracle_XA+Acc=P/tuxedo/tuxedo+SesTm=60”
GROUP2 LMID=SITE2, SITE1 GRPNO=2 TMSNAME=TMS_ORACLE7 TMSCOUNT=2 OPENINFO=”Oracle_XA:Oracle_XA+Acc=P/tuxedo/tuxedo+SesTm=60” …. |
그룹 마이그레이션을 위한 설정 후에 장애 발생 시 그룹 마이그래이션을 위한 스크립트를 작성해서 수행 하거나 자동 실행되도록 설정한다.
5. 네트워크 파티션 대처
네트워크 파티션
Tuxedo 어플리케이션 시스템에서 파티션은 하나 또는 그 이상의 원격 노드가 마스터 노드에 있는 프로세스에 접근하지 못하는 것을 의미한다. 네트워크 파티션의 확인은 아래와 같은 방법으로 가능하다.
l Tuxedo 프로세스는 파티션 상태를 유저로그 파일에 기록하기 떄문에 파일명
l 'ULOG.MMDDYY'로 생성되는 유저로그 파일에서 확인 할 수 있다.
l 관리 툴 'tmadmin'에서 명령어 'printnet'로 파티션(Partition)된 노드를 확인 할 수 있다.
l 관리 툴 'tmadmin'에서 'printservice'를 수행 했을때 특정 노드의 모든 서비스가 파티션 상태를 확인 할 수 있다.
관리 툴 'tmadmin'에서 'printnet’또는 ‘printservice’를 수행하였을 때 하나 이상의 노드가 파티션 되어 있다면 이것은 LAN의 문제이므로 LAN 상태를 확인 한다. 네트워크 파티션은 대개 다음과 같이 세가지 원인을 가진다.
l 노드 오류
l LAN 오류
l BRIDGE 프로세스 오류
노드 오류 시 대처 방안
노드 오류는 Tuxedo 어플리케이션 시스템이 운영되는 특정 시스템의 오류를 의미하고 이러한 오류 대처를 위해 마스터 노드 장애 시에는 아래 절차와 같이 마스터 머신의 기능을 백업 머신으로 이전한다.
① 백업 머신을 마스터 노드로 전환한다. (‘tmadmin’의 ‘master’ 명령어 사용)
② 장애가 난 마스터에 Tuxedo 관련 프로세스가 남아 있으면 메모리에서 다운 로드한다
③ 장애가 복구된 후 마스터에 Tuxedo 관련 프로세스들을 띄운다. (마스터에서 ‘tmboot’ 명령의 –B와 –L 옵션을 이용한다.)
④ 마스터 노드를 원래의 마스터 머신으로 전환한다. (원래의 마스터 머신에서 ‘tmadmin’의 ‘master’ 명령어를 사용한다.)
슬레이브 노드에서 노드 오류가 발생 했을 경우에는 아래와 같은 순서로 오류를 복구한다.
① 장애가 발생한 슬레이브 노드에 Tuxedo 프로세스가 남아 있으면 메모리에서 다운 로드한다
② 마스터 머신에서 ‘tmadmin’의 ‘pclean’ 명령어를 수행 해서 장애가 발생한 슬레이브 머신의 정보를 지운다.
③ 장애가 복구된 후 마스터 머신에서 ‘tmboot’ 명령어를 옵션 –B와 –L을 사용해서 해당 머신의 Tuxedo 프로세스를 띄운다.
LAN 오류 시 대처 방안
하드웨어 또는 OS 네트워크 관련 에러를 의미하고 순간 장애 시에는 Tuxedo 의 ‘BRIDGE’프로세스가 자동 재 접속 시도로 복구 되지만 심각한 오류 발생 시에는 아래와 같은 절차로 복구한다.
l 관리자가 접근 불가능한 머신을 제거한다.
l 트랜잭션 사용을 금지 시킨다.
l Replicated 서버 사용으로 머신 접근 불가시 가용 머신으로 자동 분기 하도록 한다.
l 이후에 복구 절차는 노드 장애 시와 동일하다.
‘BRIDGE’ 프로세스 오류 일 경우 ‘BRIDGE’프로세스는 이후에 계속 같은 시도를 반복하고 ‘BRIDGE’프로세스자체 오류 일 경우에는 Tuxedo 시스템에서 ‘BRIDGE’ 프로세스를 다시 업로드 시킨다.
6. 상황별 장애 대처
데이터베이스 트랜잭션 장애 시
트랜잭션 실패 시 어플리케이션에서 관련 데이터베이스에 자동적으로 롤백을 요구 해서 복구한다.
BRIDGE 프로세스 장애 시
BRIDGE 프로세스는 Tuxedo 시스템에서 시스템간의 통신을 위한 프로세스로서 이 프로세스는 BBL 프로세스에 의해 관리된다. 이 슬래이브 노드의 BRIDGE프로세스의 장애 상황 발생 시에는 아래와 같은 로그를 출력하고 자동 재 부팅 후 재접속된다.
|
…. 151952.budbil3!BRIDGE.16935:CMDTUX_CAT:1373:ERROR: Abnormal disconnect from budbil4 152002.budbil3!BRIDGE.16935:CMDTUX_CAT:4488:INFO:Connecting to budbil4 at //172.200.3.15:12495 152002.budbil3!BRIDGE.16935:CMDTUX_CAT:1373:ERROR: Abnormal disconnect from budbil4 152002.budbil3!BRIDGE.16935:CMDTUX_CAT:1371:INFO: Connection received from budbil4 …. |
DBBL 프로세스 장애 시
DBBL 프로세스는 Tuxedo 시스템을 2개 이상의 하드웨어 시스템으로 구성 할 경우 전체 시스템을 관리하는 프로세스로 마스터노드에 위치하는 프로세스로 ‘DBBL’ 프로세스의 장애 시에는 슬레이브 노드로 ‘DBBL’프로세스를 옮겨야 한다.
BBL 프로세스 장애 시
BBL 프로세스는 각 노드에서 Tuxedo 어플리케이션 시스템을 관리하는 프로세스이다.
|
…. SCANUNIT 10 DBBLWAIT 1 BBLQUERY 2 …. |
위와 같이 Tuxedo 환경 설정 파일을 설정 했을 경우 SCANUNIT (10) * BBLQUERY(2) = 20 마다 BBL 프로세스를 확인 해서 SCANUNIT (10) * BBLWAIT(1) = 10 초 안에 응답이 오지 않으면 아래 로그를 출력 하고 ‘BBL’프로세스를 다시 부팅 된다.
|
114526.budbil3!DBBL.30145: CMDTUX_CAT:1395: WARN: Slow BBL response, machine= SITE2 114536.budbil3!DBBL.30145: CMDTUX_CAT:1394: ERROR: BBL partitioned, machine= SITE2 114536.budbil3!DBBL.30145: CMDTUX_CAT:4350: INFO: BBL started on SITE2 - Release 6400 114537.budbil3!DBBL.30145: CMDTUX_CAT:668: WARN: Stale message received from BBL on machine SITE2 |
7. 장애 대처 방안 적용 (고려대학교 의료원 의료정보 시스템)
시스템 구성
Tuxedo 어플리케이션 시스템 구성은 아래와 같이 3개의 하드웨어 시스템으로 구성되고 3개의 시스템을 MP 모델로 구성한다. 구성시스템은 노드 명과 각 시스템 별 기능은 다음과 같다.
l kumca1 : 진료
l kumca2 : 진료지원, 원무
l kumca3 : 청구
Tuxedo 어플리케이션을 구성하는 Tuxedo 서버 그룹은 8개로 구성된다.
|
업무 구분 |
업무 |
서버 그룹 |
비고 |
|
진료 |
진료 |
MNXAGRP |
XA 인터페이스 사용 안함 |
|
|
|
MXAGRP |
XA 인터페이스 사용 |
|
진료지원, 원무 |
진료지원 |
SNXAGRP |
|
|
|
|
SXAGRP |
|
|
|
원무 |
ANXAGRP |
|
|
|
|
AXAGRP |
|
|
청구 |
기반 |
CNXAGRP |
|
|
|
|
CXAGRP |
|
시스템 구성 확인이 필요한 사항
l WSL 프로세스의 위치
l WSL 프로세스의 전이 위치
l 하드웨어 시스템의 사이징
l 어플리케이션 리스트
시스템 장애 시나리오 정의 전 확인이 필요한 사항
l HA 연계 방안
l HA 담당자와 사전 미팅 필요
l HA 설정 시 RIP 설정 정책
l 'Replicated Server Process에 의한 장애 대처 방안' 또는'그룹 마이그레이션을 이용한 장애 대처 방안' 적용 여부 결정
l 장애 대처 상황 종료 후 원래 시스템으로 복귀하는 절차 정의가 필요하다.
시스템 장애 시나리오
시스템 장애는 장애 발생 시스템에 따라 대처 방안이 다르다. 따라서 각 장애 사항을 아래와 같이 3가지로 나눌 수 있다.
l 시스템 ‘kumca1’이 장애가 발생 했을 경우
l 시스템 ‘kumca2’이 장애가 발생 했을 경우
l 시스템 ‘kumca3’이 장애가 발생 했을 경우
각 상황별 대처 방안은 아래와 같이 정리됩니다.
시스템 kumca1 장애
시스템 kumca1은 마스터 노드로 장애 대처 방안은 크게 마스터 노드 장애와 슬래이브 노드 장애 시 대처방안을 구분 할 수 있습니다. 마스터노드 장애 시 아래와 같은 절차로 장애에 대처합니다.
① 노드 kumca1 의 서버를 shutdown 시킨다.
② 노드 kumca1 의 RIP가 노드 kumca2로 마이그레이션된다.
③ 노드 kumca2를 마스터 노드로 변경한다.
④ 노드 kumca1의 Tuxedo 어플리케이션 서버를 노드 kumca2로 마이그레이션 한다.
⑤ 마이그레이션된 Tuxedo 서버를 재가동한다.
⑥ 노드 kumca1의 노드 정보를 크린한다.
⑦ 노드 kumca1와 접속되어 있던 클라이언트 어플리케이션을 재 가동 한다.
시스템 kumca2 장애
시스템 kumca2 노드 장애는 슬래이브 노드 장애로 아래와 같은 절차로 장애에 대처 시나리오가 정리 됩니다.
① 노드 kumca2 의 서버를 shutdown 시킨다.
② 노드 kumca2 의 RIP가 노드 kumca3로 마이그레이션된다.
③ 노드 kumca2의 Tuxedo 어플리케이션 서버를 노드 kumca3로 마이그레이션 한다.
④ 마이그레이션된 Tuxedo 서버를 재가동한다.
⑤ 노드 kumca2의 노드 정보를 크린한다.
⑥ 노드 kumca2와 접속되어 있던 클라이언트 어플리케이션을 재 가동 한다.
시스템 kumca3 장애
시스템 kumca3 노드 장애도 슬래이브 노드 장애로 시스템 kumca3 노드 장애와 같은 절차로 장애에 대처 시나리오가 정리 됩니다.
① 노드 kumca3 의 서버를 shutdown 시킨다.
② 노드 kumca3 의 RIP가 노드 kumca2로 마이그레이션된다.
③ 노드 kumca3의 Tuxedo 어플리케이션 서버를 노드 kumca2로 마이그레이션 한다.
④ 마이그레이션된 Tuxedo 서버를 재가동한다.
⑤ 노드 kumca3의 노드 정보를 크린한다.
⑥ 노드 kumca3와 접속되어 있던 클라이언트 어플리케이션을 재 가동 한다.
8. 장애 테스트
장애 테스트의 목적
Tuxedo 시스템 프로세스 장애 시 자동 복구 여부를 확인하거나 업무관련 어플리케이션 프로세스의 장애 복구 방안의 적용 결과를 확인하기 위한 장애 테스트의 목적은 아래와 같이 요약 된다.
l Tuxedo 시스템 프로세스 및 어플리케이션의 가능한 유형별 장애시의 증상 및 해결 방안을 검증한다.
l 실 환경에서 장애발생에 따른 시스템 서비스의 중단을 배제하고 대처방안을 확인한다.
l 통합시험 차원에서 Tuxedo 와 관련된 어플리케이션 프로그램의 안정성을 확인한다.
l 테스트 대상은 Tuxedo 시스템관 관련된 어플리케이션의 장애 관련 요소로 한다.
장애 테스트 절차
장애 대처방안 검증을 위한 테스트는 아래와 같은 절차로 진행한다.
① 시스템 구성을 확정 한다.
② 장애 항목을 정의 한다.
③ 장애 대처 시나리오를 정의한다.
④ 장애 대처 방안을 위한 스크립트를 작성한다.
⑤ 장애 대처 방안을 위한 스크립트를 테스트 한다.
9. 장애 테스트 시나리오
Node ‘kumca1’ Failover
|
순서 |
내용 |
확인 |
|
0. |
유저 'tuxadm'으로 로그인 한다. |
|
|
0. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca2에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
0. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ?? |
|
|
0. |
Tuxedo 시스템 서버를 노드별로 확인한다.
echo "psr" | tmadmin -r 2> /dev/null | grep -E "BBL|BRIDGE|WSL"
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. BBL 30003.00000 SITE2 0 - - ( - ) BBL 30002.00000 SITE1 0 - - ( - ) DBBL 123456 SITE1 0 0 0 ( IDLE ) BRIDGE 647744 SITE2 1 - - ( - ) BRIDGE 385600 SITE1 1 - - ( - ) WSL 00901.00100 WSGRP1 100 - - ( - ) WSL 00902.00110 WSGRP2 110 - - ( - ) |
|
|
1. |
유저 'tuxadm'으로 로그인 한다. |
|
|
2. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca2에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
3. |
Tuxedo 서버 프로세스 'DBBL'이 노드 'kumca2'으로 마이그레이션 되었는지 확인한다.
- 노드 kumca2에서 아래와 같은 명령어를 수행한다. echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep -E "DBBL|Prog Name|\-\-"
수행 결과로 'Grp Name' 항목이 'SITE2'로 되었는지 확인한다. Prog Name Queue Name Grp Name ID RqDone Load Done Current Service --------- ---------- -------- -- ------ --------- --------------- DBBL 123456 SITE2 0 0 0 ( IDLE ) . |
|
|
4. |
서버 WSL이 노드 'kumca2'으로 마이그레이션 되었는지 확인한다
- 노드 kumca2에서 아래와 같은 명령어를 수행한다. echo "pg -g WSGRP1" | tmadmin -r 2> /dev/null | grep -E "Name|Current"; \ echo "pg -g WSGRP2" | tmadmin -r 2> /dev/null | grep -E "Name|Current";
수행 결과로 'Grp Name' 항목이 모두'SITE2'로 되었는지 확인한다. Group Name: WSGRP1 Current Machine: SITE2 Group Name: WSGRP2 Current Machine: SITE2 |
|
|
5. |
Tuxedo 어플리케이션 그룹이 마이그레이션 되었는지 확인한다.
echo "pg" | tmadmin -r 2> /dev/null | grep -E "Name|Current"
수행 결과로 아래와 같이 모든 그룹이 'Current Machine' 항목이 'SITE2'로 되었는지 확인한다.
Group Name: SXAGRP Current Machine: SITE2 Group Name: WSGRP1 Current Machine: SITE2 Group Name: AXAGRP Current Machine: SITE2 Group Name: SNXAGRP Current Machine: SITE2 Group Name: MXAGRP Current Machine: SITE2 Group Name: CNXAGRP Current Machine: SITE2 Group Name: WSGRP2 Current Machine: SITE2 Group Name: CXAGRP Current Machine: SITE2 Group Name: ANXAGRP Current Machine: SITE2 Group Name: MNXAGRP Current Machine: SITE2 |
|
|
6. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ??
|
|
Node ‘kumca1’ Failback
|
순서 |
내용 |
확인 |
|
1. |
유저 'tuxadm'으로 로그인 한다. |
|
|
2. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
3. |
Tuxedo 서버 프로세스 'DBBL'이 노드 'kumca1'으로 마이그레이션 되었는지 확인한다.
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep -E "DBBL|Prog Name|\-\-"
수행 결과로 'Grp Name' 항목이 'SITE1'로 되었는지 확인한다. Prog Name Queue Name Grp Name ID RqDone Load Done Current Service --------- ---------- -------- -- ------ --------- --------------- DBBL 123456 SITE1 0 0 0 ( IDLE )
서버 WSL이 노드 'kumca2'으로 마이그레이션 되었는지 확인한다. |
|
|
4. |
Tuxedo 어플리케이션 그룹이 마이그레이션 되었는지 확인한다.
echo "pg" | tmadmin -r 2> /dev/null | grep -E "Name|Current"
수행 결과로 아래와 같이 그룹 WSGRP1, MNXAGRP, MXAGRP, SNXAGRP과 SXAGRP 의 'Current Machine' 항목이 'SITE1'로 되었는지 확인한다.
Group Name: SXAGRP Current Machine: SITE1 Group Name: WSGRP1 Current Machine: SITE1 Group Name: AXAGRP Current Machine: SITE2 Group Name: SNXAGRP Current Machine: SITE1 Group Name: MXAGRP Current Machine: SITE1 Group Name: CNXAGRP Current Machine: SITE2 Group Name: WSGRP2 Current Machine: SITE2 Group Name: CXAGRP Current Machine: SITE2 Group Name: ANXAGRP Current Machine: SITE2 Group Name: MNXAGRP Current Machine: SITE1 |
|
|
5. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ??
위 결과에서 항목0 에서 확인 한 노드 별 서버 수와 일치 한지 확인한다. |
|
Node ‘kumca2’ Failover
|
순서 |
내용 |
확인 |
|
0. |
유저 'tuxadm'으로 로그인 한다. |
|
|
0. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
0. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ?? |
|
|
0. |
Tuxedo 시스템 서버를 노드별로 확인한다.
echo "psr" | tmadmin -r 2> /dev/null | grep -E "BBL|BRIDGE|WSL"
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. BBL 30003.00000 SITE2 0 - - ( - ) BBL 30002.00000 SITE1 0 - - ( - ) DBBL 123456 SITE1 0 0 0 ( IDLE ) BRIDGE 647744 SITE2 1 - - ( - ) BRIDGE 385600 SITE1 1 - - ( - ) WSL 00901.00100 WSGRP1 100 - - ( - ) WSL 00902.00110 WSGRP2 110 - - ( - ) |
|
|
1. |
유저 'tuxadm'으로 로그인 한다. |
|
|
2. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
3. |
서버 WSL이 노드 'kumca1'으로 마이그레이션 되었는지 확인한다
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. echo "pg -g WSGRP1" | tmadmin -r 2> /dev/null | grep -E "Name|Current"; \ echo "pg -g WSGRP2" | tmadmin -r 2> /dev/null | grep -E "Name|Current";
수행 결과로 'Grp Name' 항목이 모두'SITE2'로 되었는지 확인한다. Group Name: WSGRP1 Current Machine: SITE1 Group Name: WSGRP2 Current Machine: SITE1 |
|
|
4. |
Tuxedo 어플리케이션 그룹이 마이그레이션 되었는지 확인한다.
echo "pg" | tmadmin -r 2> /dev/null | grep -E "Name|Current"
수행 결과로 아래와 같이 모든 그룹이 'Current Machine' 항목이 'SITE1'로 되었는지 확인한다.
Group Name: SXAGRP Current Machine: SITE1 Group Name: WSGRP1 Current Machine: SITE1 Group Name: AXAGRP Current Machine: SITE1 Group Name: SNXAGRP Current Machine: SITE1 Group Name: MXAGRP Current Machine: SITE1 Group Name: CNXAGRP Current Machine: SITE1 Group Name: WSGRP2 Current Machine: SITE1 Group Name: CXAGRP Current Machine: SITE1 Group Name: ANXAGRP Current Machine: SITE1 Group Name: MNXAGRP Current Machine: SITE1 |
|
|
5. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ??
|
|
Node ‘kumca2’ Failback
|
순서 |
내용 |
확인 |
|
1. |
유저 'tuxadm'으로 로그인 한다. |
|
|
2. |
환경 변수 'TUXCONFIG'가 아래와 같이 설정 되었는지 확인 한다.
- 노드 kumca1에서 아래와 같은 명령어를 수행한다. set | grep TUXCONFIG
수행 결과로 아래와 같은 내용이 출력 되는지 확인한다. TUXCONFIG=/his/env/tuxconfig |
|
|
3. |
Tuxedo 어플리케이션 그룹이 마이그레이션 되었는지 확인한다.
echo "pg" | tmadmin -r 2> /dev/null | grep -E "Name|Current"
수행 결과로 아래와 같이 그룹 WSGRP2, AXAGRP, ANXAGRP, CXAGRP과 CNXAGRP의 'Current Machine' 항목이 'SITE2'로 되었는지 확인한다.
Group Name: SXAGRP Current Machine: SITE1 Group Name: WSGRP1 Current Machine: SITE1 Group Name: AXAGRP Current Machine: SITE2 Group Name: SNXAGRP Current Machine: SITE1 Group Name: MXAGRP Current Machine: SITE1 Group Name: CNXAGRP Current Machine: SITE2 Group Name: WSGRP2 Current Machine: SITE2 Group Name: CXAGRP Current Machine: SITE2 Group Name: ANXAGRP Current Machine: SITE2 Group Name: MNXAGRP Current Machine: SITE1 |
|
|
4. |
전체 노드별 서버 수를 확인한다.
echo "SITE1 : \c" ; echo "psr -m SITE1" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc -l echo "SITE2 : \c" ; echo "psr -m SITE2" | tmadmin -r 2> /dev/null | grep [a-zA-Z] | grep -v Prog | wc –l
아래와 같이 출력된 결과에서 노드 별 서버 수를 확인한다. SITE1 : ?? SITE2 : ??
위 결과에서 항목0 에서 확인 한 노드 별 서버 수와 일치 한지 확인한다. |
|
'▶ Tuxedo > 기술자료' 카테고리의 다른 글
| Tuxedo UCS 기능 구현 방안 (0) | 2018.10.10 |
|---|---|
| Linux Tuxedo 튜닝 (0) | 2018.02.27 |
| Tuxedo 설치를 위한 Kernel Parameter Setting (0) | 2013.04.04 |
| Tuxedo 서비스의 DB 인터페이스 (0) | 2013.04.04 |
| TUXEDO Administration 관련 정보 (0) | 2012.03.16 |