Weblogic Datasource

Datasource

Weblogic은 Datasource를 통해 인스턴스가 DB와 통신하도록 한다. 이때 Weblogic에는 3가지 Datasource가 존재한다.

1. Generic Datasource
   가장 기본적인 Datasource. JNDI를 통한 lookup 및 Connection Pool 관리 기능 등을 수행한다.
2. Multi Datasource
   Datasource 그룹의 추상화. JNDI를 통해 n개의 Datasource를 조회 가능.
3. Grid Datasource
   RAC Database와 Weblogic 서버 간 연동 제공. ONS를 바탕으로 RAC의 상태변화에 능동적으로 대응 가능하다.

테스트 개요

서버 구성

1개의 웹로직 서버를 Datasource를 통해 2중화 되어있는 RAC Database와 연동하였다.

구성 케이스

1. Generic DS & ScanIP
2. Generic DS & VIP
3. Multi DS & VIP

테스트 케이스

1. node에 부하가 존재시, connection pool 생성 테스트
   • RAC node2 부하 증가 후, Weblogic 기동
   • RAC node2 부하 종료
2. Weblogic 기동 후, RAC node 종료/재기동 테스트
   • Weblogic 기동 후, RAC node1 종료
   • RAC node1 기동

확인 명령어

DB 세션 확인

select inst_id, sid, serial#, username, status, machine,
program, last_call_et 
from gv$session
where username='SYSTEM' and MACHINE='waslan'
order by 1,6;

Weblogic TCP 확인

netstat -po|grep node|grep [PID]|sort -k5|nl

JMeter 과부하

exec DBMS_SESSION.sleep(600);

테스트

Generic DS & SCAN IP (TEST 01)

RAC node2 과부하 후, Weblogic 기동

node1: 35개, node2: 5개
oracle database scan에서 리소스에 따라 자동으로 loadbalancing을 해준다. 그렇기 때문에 WAS 기동시 node1을 통해 connection pool이 더 많이 생성됨을 알 수 있다.

참고

이때 scan이 load balance를 하는 기준은 OS의 resource가 아닌, >DB의 상태이다. stress 명령어를 통하여 DB가 아닌 OS 자체에 부하를 줬을 경우, 아무런 이상 없이 20개씩 분산되나, long query를 통하여 DB에 부하를 주면 위와 같은 결과가 나타난다.

RAC node2 부하 종료

node1: 35개, node2: 5개
node2의 쿼리가 종료, 정상적인 상태가 되었으나, connection pool 개수에 변화가 없음을 알 수 있다. 이 현상을 해결하기 위해 WAS 재기동이 필요하다.

Generic DS & SCAN IP (TEST 02)

Weblogic 기동 후, RAC node1 종료

node1: 0개, node2: 40개
node1을 다운하자, node2로만 connection이 생성되었다.

RAC node1 기동

node1: 0개, node2: 40개
node1을 기동하였지만, node1로 connection이 생성되지 않는다.
이 경우에도, 정상적으로 connection pool을 나누기 위해서 Weblogic을 재기동을 해야 한다.

Generic DS & VIP (TEST 01)

RAC node2 과부하 후 Weblogic 기동

node1: 13개, node2: 27개

node1: 23개, node2: 17개

node1: 21개, node2: 19개

3번의 테스트 결과, node2에 부하를 줬음에도 node1에 더 적은 session이 생성되기도 하는 등, connection pool이 무작위로 생성되었다.

Generic DS & VIP (TEST 02)

Weblogic 기동 후 RAC node1 종료

node1: 0개, node2: 40개
RAC node2로 40개의 connection pool이 생성되었다.

RAC node1 기동

node1: 0개, node2: 40개

RAC node1이 정상적으로 기동되었으나, connection pool 에는 변화가 없다. 다시 connection pool을 분산시키기 위해서는 Weblogic 재기동이 필요하다.

Multi DS & VIP (TEST 01)

RAC node2 과부하 후, Weblogic 기동

node1: 20개, node2: 20개

Multi DS는 기본적으로 n개의 Generic DS를 그룹화 시켜 사용한다. 그렇기에, MaxCapacity(최대 Connection Pool 크기)를 20으로 설정한 2개의 Generic DS를 하나의 Multi DS로 그룹화 하였기 때문에, RAC node당 20개씩, 총 40개의 Connection Pool이 생성된다.

RAC node2 부하 종료

node1: 20개, node2: 20개

부하를 해제 후에도 기존 connection 상태에서 변화가 없음을 알 수 있다.

Multi DS & VIP (TEST 02)

Weblogic 기동 후, RAC node1 종료

node1: 0개, node2: 20개
RAC node1 기동

node1: 20개, node2: 20개

node1을 기동시키자, 정상적으로 node1의 connection pool이 정상적으로 20개 생성됨을 알 수 있다.

결론