[Web Server] Tmax5 장애진단 가이드

본 포스팅은 Tmax5 장애진단 가이드입니다.

---

본 포스팅에서는 Tmax 시스템 운영중에 발생 할수 있는 장애에 대비한 방안에 대해 살펴보겠습니다.

Tmax Trouble Shooting 을 위한 단계는 다음과 같습니다.

먼저 현상을 파악합니다.

다음으로 Tmax System의 구성을 확인합니다.

다음으로 Tmax 환경 확인 및 분석을 수행합니다.

문제가 발생한 시점의 각종 로그를 확인합니다.

필요에 의해 관련 소스를 분석합니다.

장애 재현 및 테스트를 수행합니다.

분석 취합 및 결과를 도출합니다.

마지막으로 결과를 정리하고 문서화합니다.

Trouble Shooting의 단계를 하나씩 상세하게 살펴보겠습니다.

먼저 현상 파악입니다.

정확한 현상을 파악 하여 장애 상황에 대한 범위를 최소화 합니다.

두번째로 Tmax System의 구성을 확인합니다.

정확한 장애 상황의 파악을 위한 전체 구성을 확인합니다.

구간별(DB, AP, Tmax, Network, OS, etc)로 나누어 정확한 어떤 부분에서 장애가 유발되었는지 확인합니다.

각 구간에 따라 발생할 수 있는 장애 현상이 다르므로 각각의 단계에 대한 확인이 필요합니다.

세번째로 Tmax 환경 확인 및 분석을 수행합니다.

현재 Tmax System이 어떤 환경으로 동작하고 있는지 Tmax Config File을 확인합니다.

$TMAXDIR/config/환경파일.m을 확인합니다.

Server, Client 단의 Tmax 환경변수를 확인합니다.

tmadmin 툴을 사용하여 운영상의 장애를 확인합니다.

환경 설정 실수나 거래의 부하 현상으로 인한 장애인지 확인합니다.

 

네번째로 문제 발생 시점의 각종 로그를 확인합니다.

Tmax상에서 발생한 로그를 확인 하여 장애의 원인이 된 부분을 파악합니다.

Tmax에서 제공하는 각종 로그(slog,ulog,tlog,xalog,etc)를 확인합니다.

Tmax system상의 문제일 경우 slog를 확인합니다.

XA transaction 문제일 경우 xalog를 확인합니다.

Application상의 문제일 경우 ulog를 확인합니다.

 

다섯번째로 관련 소스를 분석합니다.

Application상의 문제일 경우 source에 debug log를 추가, 또는 문제가 되는 line의 확인을 통해 원인을 파악 합니다.

Looping(CPU), Memory Leak 현상, 비정상 종료의 Case인지를 확인한후 OS 명령어 gdb, dbx, truss 및 유틸을 이용해 원인분석을 합니다. 

여섯번째로 장애 재현 및 테스트를 수행합니다.

장애의 재현이 가능한 경우에는 동일한 환경에서 테스트를 통하여 원인을 파악합니다.

일곱번째로 분석결과 취합 및 결과를 도출합니다.

전의 과정에서 분석한 내용을 바탕으로 어느 구간에서 어떤 원인으로 인해 어떤 장애가 발생했는지 파악합니다.

마지막으로 결과를 정리하고 문서화합니다.

장애의 원인과 장애를 해결할 수 있는 방안을 마련합니다.

해결 과정까지의 내용을 문서화하여 정리합니다.

지금부터는 다양한 장애유형에 따른 Trouble Shooting의 예를 들어 보면서 해결해 나가는 과정에 대해 알아 보겠습니다.

먼저 Tmax 엔진 booting 실패에 따른 Trouble Shooting 방법입니다.

이미 Tmax가 기동되어있는 경우의 대처 방안은 다음과 같습니다.

먼저 부팅이 되어있는지 Shared Memory를 통해 확인합니다.

Ipcs 명령어를 통해 현재 할당되어 있는 Shared Memory를 확인할 수 있습니다.

사용하고 있을 경우 이미 부팅이 되어 있는 경우입니다. 

Tmax엔진을Down시키 거나 Shared Memory 영역을 변경하고 기동합니다.

이미 shared memory를 사용하고 있는 경우 대처 방안은 다음과 같습니다.

Shared Memory에는 있고 관리프로세스가 없는 경우 Shared Memory를 삭제합니다.

Ipcs -m으로 현재 할당되어 있는 Shared Memory의 ID로 제거를 수행합니다.

삭제 전 사용 중이었던 Process가 무엇이었는지 반드시 확인 후 작업을 수행합니다.

엔진 process가 기동되어 있는 경우 대처 방안은 다음과 같습니다.

관리프로세스는 있고 Shared Memory는 없는경우, 관리프로세스를 제거합니다.

ps 명령어로 확인해야 하는 Process는 tmm, clh, cll입니다.

다음으로 Tmax 엔진 down 실패에 따른 Trouble Shooting 방법입니다.

이미 Tmax가 다운되어 있는 경우의 대처 방안은 다음과 같습니다.

먼저 기동과 마찬가지로 Shared Memory를 통해 현재 프로세스의 기동여부를 확인합니다.

현재 수행중인 서버가 존재하는 경우 대처 방안은 다음과 같습니다.

tmdown -i 옵션으로 강제 종료를 수행합니다.

Shared Memory가 남아 있는 경우 대처 방안은 다음과 같습니다.

기동과 마찬가지로 ipcs -m으로 남아있는 Shared Memory를 제거합니다.

Server Process가 비정상적으로 남아 있는 경우의 대처 방안은 다음과 같습니다.

기동과 마찬가지로 관리프로세스는 있고 Shared Memory는 없는경우, 관리프로세스를 제거합니다.

ps 명령어로 확인해야 하는 Process는 tmm, clh, cll입니다.

다음으로 Server AP booting 실패에 따른 Trouble Shooting 방법입니다.

먼저 서버가 이미 부팅되어 있는 경우입니다.

이미 부팅된 서버가 있는지 tmadmin -n 명령어로 확인을 수행합니다.

이미 부팅된 서버가 있을 경우 tmadmin -S serverName으로 다운을 수행합니다.

다음으로 서버가 이미 MAX개까지 기동이 되어 있는 경우의 대처방안입니다.

Configuration File의 Server 개수를 조절할 수 있는 maxsvr을 늘려줍니다.

Domain의 MAXSPR 개수까지 서버가 기동된 경우의 대처방안입니다.

Configuraton File의 maxspr을 늘려 줍니다.

OS의 FD갯수 limit 제한을 넘어가는 경우 대처방안입니다.

System File Descriptor 수를 확인합니다.

ulimit –n을 통해 확인이 가능하며 No Files 또는 Open Files로 확인이 가능합니다. 해당 설정은 프로세스 하나 당 열수 있는 소켓 개수이며, 성능에 영향을 줄 수 있는 Point입니다. 일반적으로 8192를 권고합니다.

마지막으로 서버 business logic상 에러가 있는 경우 대처방안입니다.

응용서버 Log를 확인해 봅니다. 특정 서버의 경우 tpsvrinit()에서 DB와 연결 등의 사전 로직을 타는 경우가 있습니다.

tpsvrinit()에서 -1을 return 하는 경우 서버는 기동시 에러를 발생하며 closed 하게 됩니다.

다음으로 Server AP down 실패, XA error가 발생했을 경우 Trouble Shooting 방법입니다.

먼저 Tmax server process가 tmdown되지 않을 경우입니다.

서버 프로세서가 기동 중인 경우 응용서버가 수행중인지 확인합니다.

수행중인 응용서버 강제 종료옵션(-i)을 이용하여 강제종료합니다.

XA 응용서버의 tx_begin, tx_commit, tx_rollback error가 발생한 경우입니다.

tx_ 함수에서 에러가 발생하는 경우 Database가 정상 기동되었는 지를 확인합니다.

서버에서 DML은 정상으로 이루어지지만 xa_ 함수에서 에러가 발생하는 경우 tms서버의 상태를 체크합니다.
tms서버가 비활성화 되어 있다면 tmboot -t 명령어로 가동합니다.

다음으로 XA 관련 처리지연, 폭주가 발생했을 경우 Trouble Shooting 방법입니다.

특정 서비스에 큐잉이 되는 경우입니다.

먼저 트랜잭션이 몰리는 서버를 추가 기동합니다. 해당 서버의 큐잉건수를 체크하고, 이후 서버를 추가로 기동합니다.

XA로그상에서 prepare, commit이 지연되는 경우입니다.
먼저 tms서버를 추가 기동합니다. 이후 Transaction 정보를 확인합니다. 현재 처리중인 트랜잭션 정보 출력하기 위해 tmadmin -n node명을 입력하면 xastate를 통해 확인이 가능합니다.

다음으로 Server AP error case를 살펴보고 Trouble Shooting 하는 방법입니다.

먼저 응용서버의 메모리 증가현상입니다.

해당 프로세스의 메모리 사용량을 확인합니다. 메모리를 확인할 수 있는 다양한 명령어가 있으니 주로 사용하는 명령어를 통해 확인을 수행합니다.
서비스를 반복 호출 후, 응용서버의 메모리 사용량을 재 확인합니다.
문제가 발생한 위치를 확인하고(tpfree()), 해당 응용서버를 수정합니다.

다음으로 서비스 수행중 비정상 종료(core발생) 현상입니다.
먼저 에러코드(tperrno)를 확인합니다.
TPESVRDOWN(tperrno=29)이 발생하는지, slog 상에 CLH2058이 발생하는지 확인합니다.
컴파일시CFLAGS=-g 를 추가하여 컴파일후SIGSEGV가 발생하는 경우 core를 dbx(or gdb)로 분석합니다.
문제 발생 위치가 확인되었으면 프로그램을 수정합니다.

다음으로 서비스 수행중 Timeout이 발생한 경우입니다.
먼저 에러코드(tperrno)를 확인합니다.
클라이언트에서 TPETIME(tperrno=13)이 발생하는지 확인합니다.
debug 로그로 timeout을 유발하는 부분을 찾은후 프로그램을 수정합니다.

다음으로 존재하지 않는 서비스를 호출한 경우입니다.
마찬가지로 에러코드(tperrno)를 확인합니다.
클라이언트에서 TPNOENT(tperrno=6)이 발생하는지 확인합니다.
Tmax환경파일을 확인하여 소스를 수정합니다.

다음으로 비활성 서비스를 호출한 경우입니다.
에러코드(tperrno)를 먼저 확인합니다.
클라이언트에서 TPNOREADY(tperrno=24)이 발생하는지 확인합니다.
확인되면 해당 서버를 기동시킵니다.

다음으로 tpalloc하지 않은 버퍼를 사용할 경우입니다.
에러코드(tperrno)를 확인합니다.
클라이언트에서 TPEOTYPE(tperrno=18)이 발생하는지 확인합니다.
tpcall()시 사용하는 buffer를 tpcalloc을 하도록 소스를 수정합니다.

마지막으로 응용서버의 루핑이 발생한 경우입니다.
먼저 해당 프로세스의 CPU 사용량을 확인합니다.
다음으로 응용서버의 CPU 과점유상황시 system call trace를 수집하고 확인합니다.

Trace Log를 생성하기 위해서는 OS 별로 약간 씩 다른점이 있습니다. AIX, SunOS의 경우 truss -p PID, HP의 경우 tusc -i PID, LINUX의 경우 strace -p PIDd입니다. ulog와 system call trace를 분석 후 해당 응용서버를 수정합니다.

 

마지막으로 Server AP 처리시간이 지연되는 경우 Trouble Shooting 하는 방법입니다.
먼저 요청이 폭주하는 서버를 추가 기동하는 경우입니다.

먼저 해당 서버의 큐잉건수를 체크합니다.
서버를 추가 기동 합니다.
Tmax환경파일상에서 큐잉되는 서버의 환경에 MIN, MAX, ASQCOUNT를 수정합니다.

다음으로 큐잉되어 있는 요청을 purge하는 경우입니다.
현재 큐에 적체되어 있는 서비스 요청을 삭제합니다.
이후 해당 서버의 큐잉건수를 체크합니다.

본 시간에서는 Tmax5의 Trouble Shooting을 위한 다양한 Case를 살펴보았습니다. 많은 도움이 되셨기를 부탁드립니다.

고맙습니다.