[10] CLB, RLB를 위한 서비스 매트릭스 정보의 흐름

똘똘님! 이전 포스팅을 통해 CLB와 RLB의 기본 개념은 쉽게 이해했습니다. 이번 시간에는 로드 밸런싱을 위한 “서비스 매트릭스” 정보의 흐름에 대해서 알고 싶습니다.

네 궁금님. 말씀하신 것처럼 오라클은 로드 밸런싱을 위해 “서비스 매트릭스” 정보를 이용합니다. 테스트를 통해서 살펴보겠습니다.

10-1. 리스너 설정


로드 밸런싱을 위해서는 로컬 리스너와 리모트 리스너를 설정해야 합니다. 리스너는 대부분 설치 시에 자동으로 설정되므로 설정 내용만 확인하면 될 것입니다. 제 경우에는 SCAN IP를 사용하므로 remote_listener 설정 값이 rac-scan:1521로 나타납니다. SCAN을 사용하지 않는 환경에서는 상대 노드(들)의 리스너 주소가 출력되면 됩니다.

1번 노드> show parameter _listener 
NAME                 VALUE
-------------------- --------------------------------------------
local_listener       (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.81)(PORT=1521))
remote_listener      rac-scan:1521

2번 노드> show parameter _listener 
NAME                 VALUE
-------------------- --------------------------------------------
local_listener       (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.82)(PORT=1521))
remote_listener      rac-scan:1521

10-2. 서비스 생성


CLB 옵션 (LONG, SHORT)의 차이를 확인하기 위해 2개의 서비스 (LONG_SRV, SHORT_SRV)를 생성합니다. 또한, UCP (Universal Connection Pool) 환경에서만 RLB가 동작하는 것을 검증하기 위해 2개의 서비스 (ONLINE_DBCP, ONLINE_UCP)를 생성합니다. (표-1. 참조)

표-1. 동작 차이 확인을 위한 4개의 서비스 목록

 서비스 명  CLB_GOAL  RLB_GOAL  사용할 커넥션 풀
 LONG_SRV  LONG  n/a  DBCP
 SHORT_SRV  SHORT  NONE  DBCP
 ONLINE_DBCP  SHORT  SERVICE_TIME  DBCP
 ONLINE_UCP  SHORT  SERVICE_TIME  UCP

서비스 생성

srvctl add service -db ORA12C -service LONG_SRV    -preferred ORA12C1,ORA12C2 -clbgoal LONG -notification true
srvctl add service -db ORA12C -service SHORT_SRV   -preferred ORA12C1,ORA12C2 -clbgoal SHORT -rlbgoal NONE
srvctl add service -db ORA12C -service ONLINE_DBCP -preferred ORA12C1,ORA12C2 -clbgoal SHORT -rlbgoal SERVICE_TIME
srvctl add service -db ORA12C -service ONLINE_UCP  -preferred ORA12C1,ORA12C2 -clbgoal SHORT -rlbgoal SERVICE_TIME;

Note
RLB_GOAL이 THROUGHPUT인 경우는 테스트 대상에서 제외했습니다. 제 테스트 환경에서는 RLB_GOAL이 SERVICE_TIME인 경우와 THROUGHPUT인 경우의 차이점을 발견하지 못했기 때문입니다. 약간의 차이는 있지만, 두 개의 옵션 모두 “Call당 처리 시간” 기준으로 커넥션이 이전되었습니다.

서비스 시작

srvctl start service -db ORA12C -service LONG_SRV
srvctl start service -db ORA12C -service SHORT_SRV
srvctl start service -db ORA12C -service ONLINE_DBCP
srvctl start service -db ORA12C -service ONLINE_UCP

서비스 확인

srvctl status service -db ORA12C 

Service LONG_SRV is running on instance(s) ORA12C1,ORA12C2
Service ONLINE_DBCP is running on instance(s) ORA12C1,ORA12C2
Service ONLINE_UCP is running on instance(s) ORA12C1,ORA12C2
Service SHORT_SRV is running on instance(s) ORA12C1,ORA12C2

10-3. 로드 밸런싱과 관련된 MMON, MMNL, LREG, 리스너 동작 방식


몇 가지 테스트를 통해 분석한 MMON, MMNL, LREG, 리스너의 동작 방식은 다음과 같습니다. (그림-1. 참조)

  1. MMON은 30초에 1번씩 RLB로 설정된 서비스들의 서비스 매트릭스 정보를 SYS.SYS$SERVICE_METRICS_TAB에 저장합니다.
  2. 각 노드의 MMNL은 5초에 1번씩 모든 서비스들의 서비스 매트릭스 정보를 V$SERVICEMETRIC에 저장합니다.
  3. LREG (11g까지는 PMON)는 서비스 매트릭스 정보를 리스너들에게 전달합니다.
  4. 리스너들은 LREG로부터 서비스 메트릭스 정보를 전달 받습니다.

그림-1. 서비스 매트릭스 전달 방식

10-01

10-4. 검증 방법 상세


사실, 이 부분은 엔지니어 적인 호기심으로 트레이싱을 해본 내용들입니다. 그냥 스킵해도 무방하며, 트레이스 방법에 대해서만 가볍게 리뷰하셔도 좋을 것 같습니다.


10-3의 1번 항목 검증


select to_char(ENQ_TIME, 'YYYY-MM-DD: HH:MI:SS') Enq_time, user_data
from   SYS.SYS$SERVICE_METRICS_TAB
order  by 1; 

2016-07-08: 09:45:11  SYS$RLBTYP('ONLINE_UCP', 'VERSION=1.0 database=ORA12C servic
                      e=ONLINE_UCP { {instance=ORA12C1 percent=100 flag=UNKNOWN af
                      f=FALSE} } timestamp=2016-07-08 18:45:11')
2016-07-08: 09:45:11  SYS$RLBTYP('ONLINE_DBCP', 'VERSION=1.0 database=ORA12C servi
                      ce=ONLINE_DBCP { {instance=ORA12C1 percent=100 flag=UNKNOWN
                      aff=FALSE} } timestamp=2016-07-08 18:45:11')
2016-07-08: 09:45:41  SYS$RLBTYP('ONLINE_UCP', 'VERSION=1.0 database=ORA12C servic
                      e=ONLINE_UCP { {instance=ORA12C1 percent=100 flag=UNKNOWN af
                      f=FALSE} } timestamp=2016-07-08 18:45:41')
2016-07-08: 09:45:41  SYS$RLBTYP('ONLINE_DBCP', 'VERSION=1.0 database=ORA12C servi
                      ce=ONLINE_DBCP { {instance=ORA12C1 percent=100 flag=UNKNOWN
                      aff=FALSE} } timestamp=2016-07-08 18:45:41')

Note
SYS$SERVICE_METRICS_TAB 테이블에는 RLB와 관련된 서비스의 서비스 메트릭스 정보만 30초마다 저장됩니다. 해당 테이블에는 CLB 관련 서비스의 정보는 저장되지 않습니다.

다음과 같이, kill -stop 명령어로 MMON 프로세스를 STOP 시킨 후에는 SYS$SERVICE_METRICS_TAB 테이블에 서비스 매트릭스 정보가 입력되지 않는 것을 알 수 있습니다.

[oracle@rac2 SS]$ ps -ef | grep mmon 
oracle    8474     1  0 18:43 ?        00:00:01 ora_mmon_ORA12C2
[oracle@rac2 SS]$ kill -stop 8474
[oracle@rac2 SS]$ su root
[root@rac2 SS]# strace -p 8474
Process 8474 attached
--- stopped by SIGSTOP ---

10-3의 2번 항목 검증


1번과 동일한 방법으로 MMNL 프로세스를 STOP 시키면 V$SERVICEMETRIC 테이블에 서비스 매트릭스 정보가 입력되지 않는 것을 알 수 있습니다.


10-3의 3번 항목 검증


10257 트레이스를 이용하면 됩니다. 해당 트레이스를 활성화시키면 PMON 및 LREG의 수행 내용을 확인할 수 있습니다.

SQL> alter system set events '10257 trace name context forever, level 16'; --트레이스 on
SQL> alter system set events '10257 trace name context off'; -- 트레이스 off

예시-1. LREG 프로세스 트레이스 결과

*** 2016-07-08 19:13:34.357
kmlwait: status: succ=4, wait=0, fail=0
kmmlrl: update for process drop delta: 107 106 72 74 299
kmmlrl: 72 processes
kmmlrl: node load 445
kmmlrl: instance load 4
kmmgdnu: LONG_SRV
         goodness=0, delta=1, pdb=1,
         flags=0x104:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu: ONLINE_DBCP
         goodness=100, delta=100, pdb=1,
         flags=0x104:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu: ONLINE_UCP
         goodness=100, delta=100, pdb=1,
         flags=0x104:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu: SHORT_SRV
         goodness=0, delta=100, pdb=1,
         flags=0x104:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu: ORA12CXDB
         goodness=0, delta=1, pdb=0,
         flags=0x105:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu: ORA12C
         goodness=0, delta=1, pdb=0,
         flags=0x104:unblocked/not overloaded, update=0x6:G/D/-

10-3의 4번 항목 검증


리스너 트레이스를 이용하면 됩니다.

  • 로컬 리스너 트레이스 방법: lsnrctl trace user
  • 스캔 리스너 트레이스 방법: lsnrctl trace user LISTENER_SCAN1

예시-2. 리스너 프로세스 트레이스 결과

2016-07-08 19:13:34.358201 : nsglgrDoRegister:service:ONLINE_UCP what:4 value:100
2016-07-08 19:13:34.358209 : nsglgrDoRegister:service:ONLINE_UCP what:2 value:100
2016-07-08 19:13:34.358216 : nsglgrDoRegister:service:ONLINE_DBCP what:4 value:100
2016-07-08 19:13:34.358223 : nsglgrDoRegister:service:ONLINE_DBCP what:2 value:100
2016-07-08 19:13:34.358230 : nsglgrDoRegister:service:SHORT_SRV what:4 value:100
2016-07-08 19:13:34.358237 : nsglgrDoRegister:service:SHORT_SRV what:2 value:0
2016-07-08 19:13:34.358245 : nsglgrDoRegister:service:LONG_SRV what:4 value:1
2016-07-08 19:13:34.358253 : nsglgrDoRegister:service:LONG_SRV what:2 value:0
2016-07-08 19:13:34.358261 : nsglgrDoRegister:service:ORA12C what:4 value:1
2016-07-08 19:13:34.358269 : nsglgrDoRegister:service:ORA12C what:2 value:0

Note
두 개의 트레이스 파일을 비교함으로써 리스너 프로세스의 what:4=delta, what:2=goodness 임을 알 수 있습니다. 해당 값들은 V$SERVICEMETRIC의 DELTA 및 GOODNESS 칼럼 값과 동일합니다.

참고 문헌


http://www.slideshare.net/fullscreen/alexgorbachev/demistifying-oracle-rac-workload-management-by-alex-gorbachev-nocoug-2010-spring-conference/1

글을 마치며


이번 시간에는 RLB, CLB 서비스 생성 방법 및 로드 밸런싱을 위한 “서비스 매트릭스” 정보들이 흐름을 살펴보았습니다.

[11] 톰캣 서버에 UCP (Universal Connection Pool) 구성 및 JSP 샘플 코드 작성 바로가기

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s