주식회사 누리아이티

정보자산의 보안강화를 위한 다계층 인증SW (BaroPAM) 전문기업.

▶ Tuxedo/기술자료

TUXEDO 응용 시스템 장애대처 방안

누리아이티 2013. 4. 4. 11:08

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