My Books

My Slides

rss 아이콘 이미지

서비스를 이용해서 워크로드를 관리해보니 로드 밸런싱과 Failover 부분은 아주 좋은 것 같습니다. 그런데 문제점이 하나 있습니다. 노드가 복구된 후에도 Failover된 서비스들이 원래 노드로 이동하지 않습니다. 현재는 수동으로 서비스 stop/start를 수행해서 재배치를 하고 있습니다만 자동으로 서비스 재배치가 가능할까요?



네! 가능합니다. FAN 콜아웃 (Callouts)을 이용하면 서비스 자동 재배치가 가능합니다. 그럼 한번 살펴볼까요?




5-1. FAN 이벤트란?



Fast Application Notification (FAN)은 오라클 10g부터 제공되는 기능으로써 가용성을 향상시킬 목적으로 도입된 기능입니다. 가용성을 향상시키기 위해서는 클러스터 노드 내에 문제가 발생했는 때 아주 빠르게 문제 상황을 전파할 필요가 있습니다. 오라클은 이러한 문제가 발생했을 때 FAN 메시지를 클러스터 내에 신속하게 전파함으로써 문제 상황을 빠르게 응대할 수 있도록 합니다. FAN 메시지의 유형은 크게 3가지로 구분됩니다.


  1. 서비스 (애플리케이션, 인스턴스) up/down 관련 이벤트
  2. 노드 up/down 관련 이벤트
  3. 로드 밸런싱 관련 이벤트

이번 포스팅에서 다룰 내용은 인스턴스 up/down시에 발생하는 FAN 메시지를 활용한 콜아웃 수행 방법입니다.



5-2. FAN 콜아웃 (Callouts)이란?



이름이 다소 생소할 수 있는 FAN 콜아웃은 클러스터 내에서 FAN 메시지가 발생했을 때, 자동으로 수행되는 사용자 정의 스크립트 (및 프로그램)를 의미합니다. 콜아웃은 Shell 프로그램, Perl 프로그램, C Executable등, 실행할 수 있는 형태의 파일이면 모두 가능합니다. 콜아웃은 $GRID_HOME/racg/usrco 디렉토리에 저장하면 됩니다.



5-3. FAN 콜아웃은 누가 수행할까요?



테스트 결과, FAN 콜아웃은 oraagent.bin 프로세스가 수행합니다. (검증 방법은 테스트-1 참조)


테스트-1. FAN 콜아웃 수행 프로세스 확인방법

[oracle@racnode01h ~]$ cd /u01/app/12.1.0/grid/racg/usrco
[oracle@racnode01h usrco]$ vi sleep.sh
#!/bin/bash
sleep 120
exit
[oracle@racnode01h usrco]$ chmod 700 sleep.sh

[oracle@racnode01h usrco]$ ps -ef | grep pmon
oracle    1681     1  0 06:28 ?        00:00:00 asm_pmon_+ASM1
oracle    3359     1  0 06:35 ?        00:00:00 ora_pmon_OOW1


[oracle@racnode01h usrco]$ kill -9 3359


[oracle@racnode01h usrco]$ ps -ef | grep sleep
oracle    4404  1323  0 06:56 ?        00:00:00 /bin/bash /u01/app/12.1.0/grid/racg/usrco//sleep.sh INSTANCE VERSION=1.0 service=oow database=oow instance=OOW1 host=racnode01h status=up reason=USER timestamp=2016-06-26 09:56:28 timezone=-04:00 db_domain=
[oracle@racnode01h usrco]$ ps -ef | grep 1323
oracle    1323     1  0 06:27 ?        00:00:11 /u01/app/12.1.0/grid/bin/oraagent.bin



Note
참고로, FAN 메시지는 Oracle Notification Service (ONS)가 청취하는 것으로 알려져 있으나, 테스트 결과 ONS 데몬을 다운시킨 상태에서도 FAN 메시지는 oraagent.bin에게 전달되는 것을 확인했습니다. 이것이 "그림-1"에 ONS와 oraagent.bin 간의 관계를 "?"로 한 이유입니다.


그림-1. FAN 콜아웃 수행 구조도



5-4. FAN 메시지 구성 요소



FAN 메시지는 7개의 구성요소로 이루어집니다. FAN 메시지 유형 중에서 애플리케이션 up/down 및 인스턴스 up/down과 관련된 메시지는 다음과 같습니다.


예시-1. ONLINE_SRV 서비스가 up된 경우의 FAN 메시지 
아규먼트[0] SERVICE
아규먼트[1] VERSION=1.0
아규먼트[2] service=ONLINE_SRV
아규먼트[3] database=oow
아규먼트[4] instance=OOW2
아규먼트[5] host=racnode02h
아규먼트[6] status=up

아규먼트[0] SERVICEMEMBER
아규먼트[1] VERSION=1.0
아규먼트[2] service=ONLINE_SRV
아규먼트[3] database=oow
아규먼트[4] instance=OOW3
아규먼트[5] host=racnode03h
아규먼트[6] status=up


예시-2. OOW1 인스턴스가 up된 경우의 FAN 메시지
아규먼트[0] INSTANCE
아규먼트[1] VERSION=1.0
아규먼트[2] service=oow
아규먼트[3] database=oow
아규먼트[4] instance=OOW1
아규먼트[5] host=racnode01h
아규먼트[6] status=up



5-5. FAN 메시지를 이용한 자동 재배치(Auto Rebalancing) 콜아웃 설정



인스턴스가 기동 된 직후에 "예시-2"와 같은 FAN 메시지를 제공받게 되므로, 해당 FAN 메시지를 이용해서 자동 재배치 기능을 구현할 수 있습니다. 자동 재배치를 위한 auto_rebalance.sh를 $GRID_HOME/racg/usrco 에 저장한 후 파일 퍼미션을 700으로 변경합니다.


[oracle@racnode01h usrco]$ vi auto_rebalance.sh

#!/bin/bash
export LANG=C
export LOG=/u01/app/12.1.0/grid/racg/log/auto_rebalance.log
export ORACLE_HOME=/u01/app/12.1.0/grid/
export PATH=$PATH:$ORACLE_HOME/bin
export HOST=`hostname | cut -f 1 -d .`

touch $LOG

if [ "$1" = "INSTANCE" ]; then
argmts=($*)
INSTANCE_NAME=`echo ${argmts[4]}|cut -d '=' -f 2`
HOST_NAME=`echo ${argmts[5]}|cut -d '=' -f 2`
INSTANCE_STATUS=`echo ${argmts[6]}|cut -d '=' -f 2`

if [[ "$INSTANCE_STATUS" = "up" && "$HOST_NAME" = "$HOST" ]]; then
echo "[`date`] Starting the rebalance of services on Node $INSTANCE_NAME" >> $LOG

services=`srvctl config service -d OOW | egrep '(Service name|Preferred)' | awk '{print $NF}'| paste -s -d",\n" | grep $INSTANCE_NAME | cut -d ',' -f1`

for i in $services
do
echo $i
srvctl stop  service -s $i -d OOW
srvctl start service -s $i -d OOW
done

echo -e "The following services have been relocated to $INSTANCE_NAME:\n$services " >> $LOG
fi
fi

[oracle@racnode01h usrco]$ chmod 700 auto_rebalance.sh


Note
쉘 프로그램 출처: http://www.learnoracledba.com/auto-services-rebalancing-using-fan-cluster-callouts



5-6. 자동 재배치 콜아웃 설정 후 테스트 수행



자동 재배치 콜아웃 테스트 결과, OOW1 인스턴스가 시작한 직후에 3번 노드로 Failover된 ONLINE_SRV 서비스가 1번 노드로 자동으로 재배치 된 것을 확인할 수 있습니다. 이와 같이, FAN 콜아웃을 이용하면 자동 재배치 뿐 아니라, FAN 관련 이벤트에 대한 다양한 처리를 할 수 있습니다. RAC 운영 시에 한번쯤 생각해보면 좋은 기능인 것 같습니다.


[oracle@racnode01h usrco]$ srvctl status service -d OOW
Service BATCH_SRV  is running on instance(s) OOW3
Service ONLINE_SRV is running on instance(s) OOW2,OOW3

[oracle@racnode01h usrco]$ ps -ef | grep pmon
oracle    1681     1  0 06:28 ?        00:00:00 asm_pmon_+ASM1
oracle    1980     1  0 06:29 ?        00:00:00 ora_pmon_OOW1

[oracle@racnode01h usrco]$ kill -9 1980

[oracle@racnode01h usrco]$ srvctl status service -d OOW
Service BATCH_SRV  is running on instance(s) OOW3
Service ONLINE_SRV is running on instance(s) OOW2,OOW3

-- OOW1 인스턴스 up 직후에 ONLINE_SRV 서비스가 자동으로 재배치됨
[oracle@racnode01h usrco]$ ps -ef | grep pmon
oracle    1681     1  0 06:28 ?        00:00:00 asm_pmon_+ASM1
oracle    3359     1  0 06:35 ?        00:00:00 ora_pmon_OOW1

[oracle@racnode01h usrco]$ srvctl status service -d OOW
Service BATCH_SRV  is running on instance(s) OOW3
Service ONLINE_SRV is running on instance(s) OOW1,OOW2


글을 마치며


오라클 서비스를 이용한 워크로드 관리를 설명하다가 FAN 콜아웃까지 설명을 하게 되었습니다. 필드에서 "서비스"를 범용적으로 사용하는지는 잘 모르겠으나 꽤 좋은 기능인 것만은 확실합니다. "서비스"에 대한 학습을 한 김에 다음 포스팅은 "서비스"를 이용한 성능관리 방안에 대해서 정리할 예정입니다.


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

리눅스 관련된 자료를 찾다가 “열씨미와 게을러의 리눅스 개발 노하우 탐험기”란 책의 일부 내용을 접하게 됐습니다. 각 주제의 도입부가 문답법으로 진행되는 방식인데, 아주 재미있게 읽었습니다. 저도 이번 포스팅부터는 "궁금이"와 "똘똘이" 캐릭터를 이용해서 묻고 답하기 형태를 접목시켜 보려고 합니다. :)


똘똘님! 제가 이번에 RAC 3 노드 구축 프로젝트에 참여하게 됐습니다. :) 이번 구축 프로젝트에서 가장 중요하게 생각하는 부분 중의 하나는 워크로드 관리라고 할 수 있습니다. 온라인 서비스는 RAC 1, 2번 노드를 이용해서 골고루 부하를 분산 시키고 싶고, RAC 3번 노드는 배치 서비스용으로 사용하고 싶습니다. 배치 서비스는 대부분 새벽 시간대에만 수행되므로 업무 시간 (9~6)에는 Idle한 편입니다. 따라서, 만일 RAC 1 또는 2번 노드에 장애가 발생할 경우에는 온라인 서비스를 RAC 3번 노드로 Failover하고 싶고, RAC 3번 노드의 장애가 발생할 경우에는 배치 서비스를 RAC 1 또는 2번 노드로 Failover 하고 싶습니다. 어떻게 하면 좋을까요?


 


궁금님! 말씀하신 부분은 "서비스"를 이용하면 됩니다. 자! 그럼 "서비스"에 대해서 세부적으로 알아보도록 하겠습니다.



4-1. 서비스 사용 목적



서비스는 오라클 10g부터 제공되는 기능으로써, 크게 2가지 목적으로 사용됩니다.


  1. 효과적인 워크로드 관리를 위해 사용됩니다. 이를 위해, 서비스 별로 실행 가능한 노드를 설정하고, Failover 노드를 설정하고, 로드 밸런싱 설정등을 할 수 있는 기능을 제공합니다.
  2. 서비스 별 성능관리를 위해서 사용됩니다. (별도 포스팅 예정)


4-2. 서비스 생성 및 확인 방법



서비스는 DBMS_SERVICE 패키지, SRVCTL, EM을 이용해서 생성할 수 있습니다. 싱글 인스턴스에서는 DBMS_SERVICE 패키지를 이용해도 되지만, RAC 환경에서는 EM 또는 SRVCTL을 이용해서 생성해야 합니다. 우리는 SRVCTL을 이용해서 온라인 서비스 (ONLINE_SRV)와 배치 서비스 (BATCH_SRV)를 생성하도록 하겠습니다. (테스트 환경은 “[01] LAB 실 – 3 노드 RAC 설치하기” 참고)


SRVCTL을 이용한 서비스 생성

srvctl add service -d OOW -service ONLINE_SRV -preferred OOW1,OOW2 -available OOW3 -failovermethod BASIC
srvctl add service -d OOW -service BATCH_SRV  -preferred OOW3 -available OOW1,OOW2 -failovermethod BASIC


옵션 중에 주목해야할 부분은 preferredavailable입니다.


  • preferred: 서비스 시작 시, 해당 서비스가 수행되는 노드를 지정
  • available: 서비스가 Failover되는 노드를 지정

서비스 시작

srvctl start service -d OOW -s ONLINE_SRV
srvctl start service -d OOW -s BATCH_SRV


GV$ACTIVE_SERVICES 뷰를 이용한 서비스 확인

select inst_id, name
from gv$active_services
where name like '%SRV%'
order by 1,2;

   INST_ID NAME
---------- --------------------
         1 ONLINE_SRV
         2 ONLINE_SRV
         3 BATCH_SRV


SRVCTL를 이용한 서비스 확인

srvctl status service -d OOW

Service BATCH_SRV  is running on instance(s) OOW3
Service ONLINE_SRV is running on instance(s) OOW1,OOW2


서비스 시작 후의 상태를 확인해보면, ONLINE_SRV 서비스는 1, 2번 노드에서 수행되고 있고, BATCH_SRV 서비스는 3번 노드에서만 수행되고 있다는 것을 알 수 있습니다. (그림-1. 참조)


그림-1. 서비스 시작 후의 구성도




4-3. 클라이언트에서 서비스로 접속하는 방법



그렇다면 클라이언트에서는 어떻게 해당 서비스로 접속하는 것일까요? 이에 대한 답은 오라클 10g부터 변경된 TNSNAMES.ORA 파일의 내용에서 찾을 수 있습니다. 오라클 10g부터는 SID 대신 SERVICE_NAME을 사용합니다. (물론, SID도 사용 가능합니다) DB가 생성되면 DB명과 동일한 서비스가 생성되고, 해당 서비스명을 이용해서 DB에 접속할 수 있게 됩니다. 따라서, DB 생성 이후에 lsnrctl service 명령어를 수행하면 아래와 같은 결과를 확인할 수 있습니다.


[oracle@racnode01h dbs]$ lsnrctl service

LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 25-JUN-2016 08:28:12
Copyright (c) 1991, 2014, Oracle.  All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER
Service "OOW" has 1 instance(s).
  Instance "OOW1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER
Service "OOWXDB" has 1 instance(s).
  Instance "OOW1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "D000" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: racnode01h, pid: 10243>
         (ADDRESS=(PROTOCOL=tcp)(HOST=racnode01h.oow.local)(PORT=35560))
The command completed successfully


Note
서비스 등록 및 시작 후에는 다음과 같은 결과가 출력됩니다. 즉, OOW1번 노드의 로컬 리스너는 OOW (기본 서비스) 및 ONLINE_SRV 서비스에 대한 접속을 관리하게 됩니다.


[oracle@racnode01h dbs]$ lsnrctl service

LSNRCTL for Linux: Version 12.1.0.2.0 - Production on 25-JUN-2016 08:35:48
Copyright (c) 1991, 2014, Oracle.  All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER
Service "ONLINE_SRV" has 1 instance(s).
  Instance "OOW1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER
Service "OOW" has 1 instance(s).
  Instance "OOW1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0 state:ready
         LOCAL SERVER
Service "OOWXDB" has 1 instance(s).
  Instance "OOW1", status READY, has 1 handler(s) for this service...
    Handler(s):
      "D000" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: racnode01h, pid: 10243>
         (ADDRESS=(PROTOCOL=tcp)(HOST=racnode01h.oow.local)(PORT=35560))
The command completed successfully


클라이언트의 TNSNAMEA.ORA 설정 방법은 다음과 같습니다.

ONLINE_SRV =
  (DESCRIPTION =  
   (LOAD_BALANCE=ON)
    (FAILOVER=ON)
    (ADDRESS_LIST=
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode01h-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode02h-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode03h-vip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ONLINE_SRV)
    )
  )
BATCH_SRV =
  (DESCRIPTION =
   (LOAD_BALANCE=OFF)
    (FAILOVER=ON)
    (ADDRESS_LIST=
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode01h-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode02h-vip)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = racnode03h-vip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = BATCH_SRV)
    )



4-4. 서비스 Failover 동작 방식 테스트



1번 노드에 장애가 발생할 경우에, 1번 노드에서 수행 중인 ONLINE_SRV 서비스가 정상적으로 3번 노드로 Failover 되는지를 확인해 보도록 하겠습니다.


1번 노드 장애 발생 후 서비스 Failover 결과 확인

[oracle@racnode01h dbs]$ ps -ef | grep pmon
oracle   10177     1  0 08:23 ?        00:00:00 ora_pmon_OOW1
oracle   25979     1  0 Jun24 ?        00:00:05 asm_pmon_+ASM1

[oracle@racnode01h dbs]$ kill -9 10177

[oracle@racnode01h dbs]$ srvctl status service -d OOW

Service BATCH_SRV  is running on instance(s) OOW3
Service ONLINE_SRV is running on instance(s) OOW2, OOW3


Note
1번 노드의 장애 발생 직후에, ONLINE_SRV 서비스는 3번 노드로 Failover 된 것을 알 수 있습니다. (그림-2 참조)


그림-2. ONLINE_SRV 서비스 Failover 후의 구성도



1번 노드의 장애가 복구된 후에는 어떻게 될까요?


3번 노드로 Failover된 ONLINE_SRV 서비스는 1번 노드의 장애가 복구된 후에도 여전히 3번 노드에 존재하게 됩니다. (그림-3. 참조) 오라클은 “서비스”에 대해서는 자동 재배치 (Auto Rebalancing) 기능을 제공하지 않기 때문입니다.


그림-3. 1번 노드 장애 복구 후의 구성도



그렇다면, "자동 재배치 기능은 어떻게 구현할 수 있을까?" 하는 의문이 생깁니다.

만일, 자동 재배치를 수동으로 해야한다면 "서비스"를 업무에 적용하기에는 현실적인 어려움이 따르기 때문입니다. 이 문제를 해결하기 위해 오라클은 "FAN (Fast Application Notification) Callouts"을 이용한 자동 재배치 기능을 제공하고 있습니다. 


해당 내용에 대해서는 다음 포스팅에서 다루도록 하겠습니다.


"[05] FAN 콜아웃 (Callouts)을 이용한 서비스 자동 재배치 방법" 으로바로가기


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

[03] SCAN (Single Client Access Network) 동작원리

RAC 2016.06.22 16:57 Posted by 시연아카데미

오라클 12c RAC로 DB 서버를 신규 구축하려고 합니다. SCAN을 사용하는 것이 좋을까요?”


위와 같은 질문을 받았다고 가정해보겠습니다. 이에 대한 대답은 크게 3가지 정도로 나뉠 것 같습니다.


  1. 새로운 기능은 위험 부담이 있습니다. 기존처럼 VIP를 사용하는 것이 좋습니다
  2. SCAN이 좋다고 하던데, 한번 적용해 볼까요?
  3. SCAN의 특성은 이러합니다. 또한 SCAN의 장단점은 이러합니다. 따라서 우리 환경의 특성을 고려해볼 때 SCAN을 적용하는 것은 무리가 있을 것 같습니다. (또는, SCAN의 특성 상 우리 환경에 적합해 보입니다. 테스트 환경을 구축해서 검증해보도록 하겠습니다)  

아마 1번과 같은 답변이 꽤 많을 것 같습니다. 왜냐하면, IT가 최첨단의 기술을 접목시키는 분야이기도 하지만, 인프라가 잘 운영(또는 고착)되고 있는 상황에서는 어느 정도의 보수성을 가지기 때문입니다. 2번과 같은 반응은 두말할 나위 없이 위험합니다. 우리가 공부를 하는 이유는 3번과 같은 답을 위해서 입니다.


제가 며칠동안 SCAN을 학습하면서 내린 나름의 결론은 “SCAN은 고수준의 자동 로드 밸런싱이 필요한 환경에서만 적용하는 것이 좋다”입니다. 좀 더 풀어서 말하면


  • RAC 노드들이 꽤 많고
  • 애플리케이션 로드 밸런싱을 수행하며
  • 노드들의 추가 또는 삭제가 자주 발생하는 환경을 의미합니다.

(이런 환경이 많이 있을지 의문이 들긴 합니다)


조금 더 세부적인 이야기는 SCAN의 동작원리를 설명하면서 진행하도록 하겠습니다.


3. SCAN (Single Client Access Network) 동작원리


3-1. SCAN이란?


SCAN은 11gR2부터 제공되며, 하나의 이름으로 RAC의 모든 노드를 액세스할 수 있는 기능입니다. 기존에는 클라이언트마다 커넥션 스트링을 관리한 반면, SCAN을 사용하게 되면 DNS 레벨에서 중앙 집중적으로 커넥션 스트링을 관리할 수 있게 됩니다. SCAN을 이용한 TNS 설정 방법은 “예시-1”을 참고하시면 됩니다.


예시-1. TNSNAMES.ORA 예제

-- SCAN을 이용한 설정
ORA12C_SCAN =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORA12C)
    )
)
-- VIP를 이용한 설정 (기존 방식)
ORA12C_VIP =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORA12C)
    )
  )


위의 예시에서 rac-scan이 SCAN 명이고 해당 명칭은 DNS에서 인식이 가능해야 합니다.


Note
테스트를 위해 DNS 서버를 구성하려는 분들은 “Dnsmasq를 이용해서 간단한 DNS 서버를 구성하는 방법”을 참고하세요.



3-2. SCAN의 장점


SCAN의 장점은 크게 2가지로 요약할 수 있습니다.


  1. 클라이언트마다 수행하던 커넥션 스트링 관리를 DNS 레벨에서 관리
  2. SCAN 리스너를 이용하여 기존보다 정확한 로드 밸런싱 수행

기존 방식을 사용할 경우에는 RAC 노드가 추가 또는 삭제될 경우에 클라이언트마다 커넥션 스트링 (TNSNAMES.ORA 및 JDBC Connection String)을 변경할 필요가 있습니다. 하지만 SCAN을 사용할 경우에는 DNS 서버에서 커넥션 스트링을 관리하므로 클라이언트들은 별도의 변경 작업이 필요 없다는 장점이 있습니다.


또한, 기존의 VIP 리스너는 워크로드를 정확하게 계산하지 못하므로 최적의 로드 밸런싱을 수행하지 못했던 문제가 존재했으나,, SCAN 리스너는 최적의 로드 밸런싱을 수행한다고 합니다.

이러한 2가지 장점이 큰 이득이 되는 환경에서는 SCAN 적용을 검토할 필요가 있습니다. 만일 그렇지 않다면 VIP를 이용하는 것이 좋습니다.



3-3. SCAN 구성도


SCAN 명은 DNS에서 관리되고, SCAN IP는 최대 3개를 사용합니다. SCAN IP 마다 1개의 SCAN 리스너가 할당되므로 SCAN 리스너 역시 최대 3개입니다. SCAN 리스너의 역할은 클라이언트의 접속 요청이 있는 경우에, DB 서버들의 부하를 체크한 후 최적의 노드를 선택하고 해당 노드의 Local 리스너에게 접속 요청을 전달하는 것입니다.


즉, 가벼운 역할 (부하 체크 & Local 리스너에게 접속 요청 재전송)만을 수행하므로 RAC 노드 수와 무관하게 (RAC 노드 수가 수십 개라도) 최대 3개만 제공합니다. SCAN를 적용한 RAC 구성도는 “그림-1”과 같습니다.


그림-1. SCAN을 적용한 RAC 구성도


Note
RAC 2 노드 환경에서 3개의 SCAN IP를 설정했다면 1개의 서버에 2개의 SCAN IP가 할당되고 나머지 1개의 서버에 1개의 SCAN IP가 할당됩니다.



3-4. Connection Pool 환경에서 SCAN 사용 시 주의 사항


WAS 환경에서는 일반적으로 Connection Pool을 사용하며, Connection Pool 별로 서로 다른 서비스를 제공합니다. “그림-2”는 VIP 환경에서 2개의 Connection Pool을 이용해서 2개의 서비스를 제공하는 예입니다.


그림-2. VIP 환경에서의 Connection Pool 예시



이러한 환경에서, “서비스” 설정 없이 SCAN을 사용할 경우에는 “그림-3”과 같은 문제가 발생하게 됩니다. 즉, 동일한 서비스에 대한 커넥션이 서로 다른 노드에 접속할 가능성이 높고, 이로 인해 불필요한 Interconnect 전송이 발생함으로써 성능 저하가 발생할 수 있습니다.


그림-3. SCAN 환경에서의 Connection Pool 예시



따라서, SCAN을 적용할 때는 커넥션 관리 부분을 신경 써야하고, 이를 위해서는 반드시 “서비스”를 적용하는 것이 좋습니다. “서비스”에 대해서는 다음 연재에서 다루도록 하겠습니다.


참고문헌


Expert Oracle RAC 12c [Apress – Syed Jaffar Hussain외 3명]
Oracle Single Client Access Network (SCAN) [June 2013 – An Oracle White Paper]



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

[02] 하드웨어 관점에서의 RAC 아키텍처

RAC 2016.06.16 02:39 Posted by 시연아카데미

RAC 아키텍처를 정확히 이해하기 위해서는 하드웨어 (및 OS)에 대한 지식이 필요합니다. 아키텍처와 관련된 자료들을 보면 NIC, VIP, Private Network, Interconnect Switch, NIC Bonding, SAN, Multipath IO, HBA 등의 용어들을 자주 접하게 됩니다. 영문으로 될 글을 읽을 때 단어를 잘 모르면 전반적인 맥락은 이해하더라도 정확한 해석이 힘든 것과 마찬가지로, RAC를 이해함에 있어서 이러한 용어들에 대한 이해는 반드시 필요하다고 할 수 있습니다. 하드웨어 관련된 구성에 있어서는 문외한에 가깝지만, 며칠 동안 여러가지 자료를 이용해서 학습한 내용을 바탕으로 하드웨어 관점에서의 RAC 아키텍처를 정리하도록 하겠습니다.


 

2. 하드웨어 관점에서의 RAC 아키텍처


2-1. 기본 구성도



엔터프라이즈 환경에서 단순하게(이중화 구성 없이) RAC를 구성하는 방법은 “그림-1”과 같습니다. 즉, 하드웨어 관점에서의 RAC 아키텍처는 2개의 DB 서버, 이더넷 스위치 1개, Gigabit 스위치 1개, SAN 스위치 1개, 공유 디스크용 스토리지 1개로 구성됩니다.


그림-1. RAC 기본 구성도





다음은 기본 구성도와 관련된 용어 설명입니다.


  • NIC (Network Interface Card): DB 서버를 이더넷 스위치에 연결하기 위한 케이블을 꼽는 장치
  • HBA (Host Bus Adapter): DB 서버를 SAN 스위치에 연결하기 위한 케이블을 꼽는 장치
  • Fast Ethernet 스위치: 초당 100 Mbps (12.5Mbyte)의 대여폭을 제공하는 스위치
  • Gigabit 스위치: 초당 1000 Mbps (125 Mbyte) 이상의 대여폭을 제공하는 스위치
  • SAN 스위치: SAN (Storage Arrary Network)에 액세스하기 위한 스위치



2.2 Public IP, Private IP, SCAN IP, VIP의 차이점



  • Public IP: 외부에서 접속 가능한 IP입니다. 주로 DBA 또는 시스템 관리자가 관리 목적으로 DB 서버에 접속할 때 사용합니다.
  • Private IP: DB 서버 간의 Interconnect 통신만을 위해서 사용되는 IP입니다.
  • VIP: DB 서버 장애 발생 시, Fail-Over 목적으로 사용되는 가상 IP입니다. Public IP가 할당된 NIC에 설정됩니다. Public IP가 할당된 NIC가 eth0이라면, VIP는 eth0:1로 설정됩니다.
  • SCAN (Single Client Access Name): VIP를 이용해서 클라이언트 쪽의 TNANAMES.ORA 파일을 설정하면, RAC 노드를 추가하거나 삭제할 때 마다 TNSNAMES.ORA 파일을 수정해야하는 문제점을 가지고 있었습니다. SCAN은 이러한 문제를 해결하기 위해서 11gR2부터 제공되는 기능이며, SCAN IP는 VIP와 마찬가지로 Public IP가 할당된 NIC에 설정됩니다. 


2.3 DB 서버 장애 시 VIP, SCAN IP Fail-Over



DB 서버(#1)에 장애가 발생할 경우, SCAN IP(1), SCAN IP(2) 및 VIP는 DB 서버(#2)의 NIC 0에 설정됩니다. 즉, "그림-2"와 같이 설정됩니다.


그림-2. DB 서버 장애 시, IP Fail-Over





이때 DB 서버(#2)에서 ifconfig 명령어를 수행하면 다음과 같은 결과가 출력됩니다.

# ifconfig
eth0      Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.72  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe15:d5d0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17574 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8014 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16092152 (15.3 MiB)  TX bytes:4412947 (4.2 MiB)
eth0:1    Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.82  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth0:2    Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.91  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth0:3    Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.81  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth0:4    Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.92  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth0:5    Link encap:Ethernet  HWaddr 08:00:27:15:D5:D0
          inet addr:192.168.56.93  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth1      Link encap:Ethernet  HWaddr 08:00:27:27:95:03
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe27:9503/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:432318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:522063 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:250003557 (238.4 MiB)  TX bytes:380719952 (363.0 MiB)
eth1:1    Link encap:Ethernet  HWaddr 08:00:27:27:95:03
          inet addr:169.254.240.162  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth2      Link encap:Ethernet  HWaddr 08:00:27:0C:B7:19
          inet addr:10.0.4.15  Bcast:10.0.4.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe0c:b719/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8652 (8.4 KiB)  TX bytes:17465 (17.0 KiB)


참고로 /etc/hosts 파일의 내용은 다음과 같습니다.

# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain
::1         localhost localhost.localdomain <
#public
192.168.56.71   rac1        rac1.dbaora.com
192.168.56.72   rac2        rac2.dbaora.com
#private
192.168.10.1    rac1-priv   rac1-priv.dbaora.com
192.168.10.2    rac2-priv   rac2-priv.dbaora.com
#virtual
192.168.56.81   rac1-vip    rac1-vip.dbaora.com
192.168.56.82   rac2-vip    rac2-vip.dbaora.com
#scan
192.168.56.91   rac-scan    rac-scan.dbaora.com
192.168.56.92   rac-scan    rac-scan.dbaora.com
192.168.56.93   rac-scan    rac-scan.dbaora.com




2-4. 가용성을 높이기 위한 이중화 구성도



높은 가용성 (Availability)을 위해서는 SPOF (Single Point Of Failure)를 최대한 제거해야만 합니다.


SPOF란?
시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소를 의미합니다. (위키백과)
https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%9E%A5%EC%95%A0%EC%A0%90


SPOF를 제거하기 위해서는 이중화가 필수적입니다. RAC에서의 이중화 방법은 “그림-3”과 같습니다. 즉, 스위치 장애를 대비하기 위해서 스위치를 이중화하고, 네트워크 케이블 불량에 대비하기 위해서 “NIC Bonding”을 구성하고, IO 채널 불량에 대비하기 위해서 “Multipath IO”를 구성합니다.


그림-3. 이중화를 적용한 RAC 구성도




NIC Bonding이란?
2개 이상의 NIC를 하나의 디바이스로 인식하게 하는 방법입니다. 대여폭을 확장하거나 Active / Standby 형태로 구성할 수 있습니다.


Multipath IO (MPIO)란?
공유 디스크용 스토리지를 액세스하기 위한 경로가 2개 이상인 것을 의미합니다. IO 채널 불량에 대한 fault-tolerance 및 로드 밸런싱을 통한 성능 향상을 목적으로 합니다.



글을 마치며



하드웨어 구성을 정리하다 보니, SCAN에 대해서 조금 더 자세히 정리할 필요성을 느꼈습니다. “RAC 연재”의 다음 주제는 “SCAN”으로 찾아 뵙겠습니다.



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

[01] LAB실 - 3 노드 RAC 설치하기

RAC 2016.06.08 15:24 Posted by 시연아카데미

1. LAB실 - 3 노드 RAC 설치하기



RAC 연재에 앞서, 3 노드 RAC 환경을 구축하기로 마음 먹었습니다. 2 노드 RAC 설치, EXADATA 설치 등, 설치로 인한 피로감이 있긴 하지만 제대로 된 3-Way 통신 테스트를 위해서는 3 노드 RAC 환경을 구축하는 것이 필요하기 때문입니다.


3 노드 RAC 설치를 위해 구글링한 결과, 오라클에서는 이미 OOW 행사 시의 LAB실 진행을 위해 3 노드 및 4 노드 RAC 생성을 위한 템플릿을 제공하고 있습니다. 해당 템플릿을 이용하면 3 노드, 4 노드 뿐 아니라 Flex ASM & Cluster 환경도 구성이 가능합니다. 


이번 LAB실은 표준 모드로 RAC 3 노드를 구축할 예정입니다. (Flex ASM & Cluster 환경 구성은 향후 진행 예정입니다). 대부분의 내용은 오라클에서 제공하는 문서대로 진행하시면 됩니다. 영문으로 된 문서이긴 하지만 정리가 잘되어 있으므로 문서대로만 따라하시면 설치가 완료될 것으로 확신합니다. 몇 가지 주의 사항은 아래 내용을 참고하세요.


  • 3 노드 RAC 환경 구축을 위해서는 최소 16 GB RAM이 필요합니다.
  • 16 GB RAM 인 경우에도, VM 메모리 설정을 적절히 잘 해야합니다. ("그림1" 참고)
  • Deploy시에는 Manager Server의 root 유저 홈 디렉토리에 있는 DBRACOVM-Deploycluster3-tool_HOL10471.zip을 이용하시면 됩니다.
  • 오라클에서 제공하는 템플릿은 Flex ASM & Cluster 환경 (2 HUB 노드, 1 LEAF 노드)이므로, 템플릿을 약간 수정해야 합니다 ("표1" 참고)

1-1. 오라클 설치 가이드 및 VM 이미지 다운로드 위치


아래의 사이트에서 2개의 ova (ovmm10471.oow.local.ova, ovs10471.oow.local.ova)를 다운로드하고 "Read the tab instructions here"를 클릭해서 설치 매뉴얼을 다운로드합니다.

http://www.oracle.com/technetwork/server-storage/vm/downloads/hol-oraclevm-2368799.html



1-2. VM 및 RAC 노드 메모리 설정


16 GB RAM 환경이더라도, PC에서 사용하는 기본 메모리등을 고려했을때 "그림1"과 같이 설정하는 것이 좋습니다.


  • OVMM10471.OOW.LOCAL VM 메모리는 3 GB로 설정 (기본 설정은 4 GB이므로, VM 환경 설정에서 변경)
  • OVS10471.OOW.LOCAL VM 메모리는 8 GB로 설정 (기본 설정은 9 GB이므로, VM 환경 설정에서 변경)
  • RACNODE0.1/0.2/0.3 3개의 RAC 노드의 메모리는 2400 MB로 설정 (기본 설정은 3 GB임. 변경 방법은 설치 매뉴얼 참고)

그림1. 3 노드 RAC 구성도



1-3. 빌드 스크립트 변경


Manager Server (192.168.56.30)의 /root/deploycluster3/utils/netconfig12cRAC3node.ini 파일 내용을 "표1" 내용으로 변경합니다.(##으로 된 부분이 표준 RAC 모드 설치를 위해 주석 처리한 부분입니다)


표1. 표준 모드 RAC 생성용 스크립트

# Node specific information
NODE1=racnode01h
NODE1IP=192.168.56.120
NODE1PRIV=racnode01h-priv
NODE1PRIVIP=10.10.10.230
NODE1VIP=racnode01h-vip
NODE1VIPIP=192.168.56.230
##NODE1ROLE=HUB
NODE2=racnode02h
NODE2IP=192.168.56.121
NODE2PRIV=racnode02h-priv
NODE2PRIVIP=10.10.10.231
NODE2VIP=racnode02h-vip
NODE2VIPIP=192.168.56.231
##NODE2ROLE=HUB
NODE3=racnode03h
NODE3IP=192.168.56.122
NODE3PRIV=racnode03h-priv
NODE3PRIVIP=10.10.10.232
NODE3VIP=racnode03h-vip
NODE3VIPIP=192.168.56.232
##NODE3ROLE=LEAF
# Common data
PUBADAP=eth0
PUBMASK=255.255.255.0
PUBGW=192.168.56.1
PRIVADAP=eth1
PRIVMASK=255.255.255.0
RACCLUSTERNAME=oow12c
DOMAINNAME=oow.local  # May be blank
DNSIP=  # Starting from 2013 Templates allows multi value
# Device used to transfer network information to second node
# in interview mode
##NETCONFIG_DEV=/dev/xvdc
# 11gR2 specific data
SCANNAME=oow12c-scan
SCANIP=192.168.56.235
##GNS_ADDRESS=192.168.56.236
# 12c Flex parameters (uncomment to take effect)
##FLEX_CLUSTER=yes  # If 'yes' implies Flex ASM as well
##FLEX_ASM=yes
##FLEX_ASM=yes
##ASMADAP=eth2  # Must be different than private/public
##ASMMASK=255.255.255.0
##NODE1ASMIP=10.11.0.230
##NODE2ASMIP=10.11.0.231
##NODE3ASMIP=10.11.0.232
# Single Instance (description in params.ini)
# CLONE_SINGLEINSTANCE=yes  # Setup Single Instance
#CLONE_SINGLEINSTANCE_HA=yes  # Setup Single Instance/HA (Oracnodele Restart)



마치며


"RAC 연재"의 다음 주제는 "그리드 인프라스트럭처에 대한 이해" "RAC 아키텍처" 입니다. 설치 환경을 기반으로 연구 및 테스트 후에 포스팅 예정입니다.




저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

누구나 쉽게 따라할 수 있는 Oracle 12c RAC 설치 가이드

RAC 2016.05.10 20:14 Posted by 시연아카데미

누구나 쉽게 따라할 수 있는 Oracle 12c RAC (12.1.0.2) 설치 가이드입니다.


설치 시에는 입력해야 할 명령어 및 설정 내용들이 많이 있습니다. 따라서, 실제 설치 시에는

"슬라이드 보기"을 누른 후에 pdf 파일을 다운로드 받아서 진행하시는 것이 좋습니다.

 


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License


 

티스토리 툴바