[TroubleShooting] WAS 장애복구 기능

본 포스팅은 WAS의 장애복구과정을 설명합니다.

---

장애가 발생하면 스스로 복구되는 과정은 사이트를 운영하는데 있어서 매우 중요한 부분입니다. 

이에 WAS의 장애복구 기능을 설명보고자 합니다.

 

먼저 장애 시 자동 복구 방안입니다.

서버 장애 자동 관리 메커니즘은 다음과 같습니다.

- JEUS  Manager에 의한 시스템의 Container 및 어플리케이션 감지 기능으로 Container 및 어플리케이션을 자동으로 재 시작 시키게 됩니다.

- 웹서버와 JEUS의 시스템간 통신으로 장애에 대한 감지 기능 제공으로 JEUS 서버 장애 시 정상적으로 작동하는 JEUS 서버로 서비스합니다.

- 동일 서버간 클러스터링 지원으로 무정지 서비스를 제공합니다.

 

관리 정책에 따른 Active Management 설정방법은 다음과 같습니다.

- Thread Block 허용치를 설정합니다.

- Block 최대 허용치를 설정합니다.

- 통보용 관리자 E-Mail을 등록합니다.

Application에 의한 Hangup 감지를 수행합니다.

Web, EJB 작동상태를 확인합니다.

설정된 Active Management가 작동하여 오류정책에 의한 검사를 수행합니다.

관리자에게 E-Mail을 발송합니다.

장애 발생 Container를 재시작합니다.

서비스 정상화를 확인합니다.

서비스를 계속 수행하도록 합니다.

 

다음으로 프로세스 복구 기능을 지원합니다.

- JEUS는 서버의 Hangup이나 비정상적인 작동에 대해 Active Management 설정으로 Thread Hangup을 자동복구 합니다. 설정된 Thread 관리 정책보다 Thread Hangup 수치가 높으면, 관리자에게 메일을 보내고, 컨테이너를 재시작 함으로써 장애를 자동 관리 합니다.

 

다음으로 장애 대응을 위한 자동 라우팅을 지원합니다.

- JEUS는 클러스터링을 통해 장애발생에도, 자동 라우팅을 통하여 효율적이고 안정적인 가용성을 지원하고 있습니다.

JEUS 노드간 Session Clustering을 구성하여, 장애발생 시에도 Session유실을 완벽하게 방지할 수 있습니다.

 

그밖의 다양한 기타 장애 대응사항에 대해 알아보겟습니다.

JEUS는 하나 이상의 어플리케이션 혹은, 플랫폼 컴포넌트, 라인, 노드, 머신 등이 다운될 경우에도 서비스를 지속적으로 제공합니다.

어플리케이션 혹은 플랫폼 컴포넌트가 다운될 경우, JEUS Manager가 자동으로 재시작(Restart)합니다.  라인, 노드, 머신이 다운될 경우 백업 노드에서 서비스 제공합니다.

"Single point of Failure"에 대한 종속성 제거합니다.

세션/서비스 클러스터링을 통해 지원합니다.  장애가 발생한 WAS 인스턴스에 대한 자동 재시작(Restart) 기능을 통해 지원합니다.

고가용성(High Availability) 서비스 접근 방식 제공합니다.

WAS 인스턴스 클러스터링을 통해 컴포넌트 복제 기능 제공합니다.  백업 서버 설정으로  "백업 인스턴스에 대한 서비스 자동 Fail-Over" 기능을 제공합니다.  Session 클러스터링을 통해 Session 데이터 복제 기능 제공합니다.

Sateless/Stateful Component, Persistent Component에 대한 Fail-Over를 수행합니다.

JEUS Service 및 J2EE Specification을 제공합니다.

마지막으로 장애 복구 기능 시연을 알아보겠습니다.

아래는 WAS 인스턴스 장애 시 복구 평가항목입니다.

- 테스트 Scenario입니다.

순서	세부 절차
1	• WAS간 클러스터링 설정을 수행합니다.
2	• WAS 1 의 Container 프로세스 강제 종료 후, Test page call 합니다.
3	• WAS 1의 Container 프로세스 자동복구를 확인합니다.
4	• WAS 2 의 Container 프로세스 강제 종료 후, Test page call 합니다.

- 체크 사항입니다.

항목	확인 방법
강제 종료된 Container 프로세스가, 자동으로 정상복구 되었는지 확인합니다.	로그를 확인한다. Unix는 ps –ef 명령어로 확인합니다.
Container 종료시 페이지 요청은 정상처리 되었는지 확인합니다.	Page call 후 정상응답 확인합니다.

장애 시 정상 복구 및 정상 서비스 여부를 판단하기 위해 Session ID 가 동일한지 테스트를 수행합니다.

(1) 현재 세션 ID 확인 비교를 위해 정상 서비스 중인 세션 ID 확인합니다.

(2) 인스턴스1 비정상종료 인스턴스를 강제로 종료를 수행합니다.(Kill)

(3) 인스턴스1 자동 Restart 자동 복구를 수행하는 인스턴스 확인합니다.

(4) 세션 ID 확인 세션ID 값 변화 없이 정상 서비스 되는지 확인다.

장애 시 정상 복구 및 정상 서비스 여부를 판단하기 위해 Session ID 가 동일한지 테스트 를 수행합니다.

(1) 현재 세션 ID 확인 비교를 위해 정상 서비스 중인 세션 ID 확인합니다.

(2) 인스턴스2 비정상종료 인스턴스를 강제로 종료를 수행합니다.(Kill)

(3) 인스턴스2 자동 Restart 자동 복구를 수행하는 인스턴스 확인합니다.

(4) 세션 ID 확인 세션ID 값 변화 없이 정상 서비스 되는지 확인합니다.

 

추가로 DB 장애 시 복구 방법에 대해 살펴 보고 포스팅을 마치도록 하겠습니다.

복구 방법에 앞서 Chek-query에 대해 간단히 살펴보고 테스트를 수행해 보도록 하겠습니다.

Check-query, Check-query-Period 란 무엇인지부터 알아보겠습니다.

• check-query는 DBconnectionPool 을 사용하기 전에 해당 connection에 대한 상태를 알아보기 위해서 간단한 Query를 해당 Connection에 보내는 기능입니다. 그러나 이 기능은 connection에 대하여 매번 checkquery에 설정된 Query가 수행되므로 performance에 영향이 있을수 있습니다.

• check-query-period는 설정한 시간마다 check query를 실행해주는 옵션으로 단위는 millisecond입니다.

장애 발생 시점 WAS - DB 구간을 점검하는 용도로 사용됩니다. 이를 통해 DB 서버의 장애 발생 시 Connection을 단절하고 DBPool Failover 또는 Failback을 수행하게 됩니다.

•테스트 방법은 DB장애시 DBConnectionPool 동작방식을 확인합니다.

네트워크 장애는 DB서버의 LAN선을 뽑아서 네트워크장애를 발생시킵니다. 네트워크장애 발생후 Netstat / dbpooladmin에 대한 정보를 확인한후 AP를 실행후 결과를 확인합니다. 그 이후에 네트워크장애를 복구한후 다시 AP를 실행한후 결과를 확인합니다.

 

실제 Test Case를 들어 살펴보겠습니다.

1번) check-query, check-query-period, max-use-count를 설정하지 않고 네트워크 장애에 대한 Test를 수행한다.

- 네트워크 장애 발생후 AP를 실행하면 AP Hang상태가 나타난다. 그리고 네트워크 복구후 AP를 실행하면 로그에 java.sql.SQLException: IO 예외사항 : Connection reset이란 로그가 발생한다.

2번) max-use-count만 설정후 네트워크 장애에 대한 Test를 수행한다.

- 위의 Test Case 1번과 같은 결과가 나온다.

3번) Check-query 설정후 네트워크 장애에 대한 Test를 수행한다.

- 에러가 발생하지 않는다.

4번) Check-query 및 check-query-period 설정후 네트워크 장애에 대한 Test를 수행한다.

- connection들이 오류가 발생하고 정상적으로 connection을 맺거나 check-qurey-period 설정시간이 지난후에 정상적으로 다시 connection을 생성한다.

 

장애복구 시나리오에 대해 알아봤습니다.

장애 발생 시 일정 시간안에 자동 복구가 될수 있도록 조치하는 것은 매우 중요한일입니다. 인력의 힘으로 복구를 하는 것은 매우 제한적인 일이기 때문입니다.

장애 발생 시 문제가 발생하였음을 인지하는 Health Check 주기에 대해 명확한 사이트 기준을 두고 이를 각 파트 (WEB / WAS / DB / OS / Network 등 다수)에 반영하여 관리하도록 해야 할 것입니다. 

자 그럼 다음시간에는 세션클러스터링 시연에 대해 알아보겠습니다.

고맙습니다.