[13] UCP 기반의 FCF (Fast Connection Failover) 설명

이번 시간에는 UCP (Universal Connection Pool) 기반의 FCF (Fast Connection Failover)의 동작 방식에 대해서 설명하도록 하겠습니다.

 

13-1. FCF (Fast Connection Failover)란?


FCF는 말 그대로 빠른 커넥션 페일오버를 제공하는 기능입니다. UCP 기반의 FCF는 다음과 같이 동작합니다.

  1. 빠른 DB 장애 인지를 위해 ONS (Oracle Notification Service) 기반의 FAN 메세지를 이용한 push 방식을 통해 “INSTANCE down” 메세지를 전송 받습니다. (polling 방식이 아니므로 pooling interval 만큼의 delay도 발생하지 않습니다)
  2. 톰캣 서버는 “INSTANCE down” 메세지를 전송 받은 후, 기존 커넥션을 정리하고 Failover 노드에 신규 커넥션을 연결합니다.
  3. 톰캣 서버는 “INSTANCE Up” 메세지를 전송 받은 후 일정 시간이 지나면, Failover 노드의 커넥션을 정리하고 기존 노드로 신규 커넥션을 연결합니다.

동작원리를 통해 알 수 있듯이 UCP 기반의 FCF는 JDBC Connection Pool에 비해 2가지 장점을 가집니다.

  • Failover 노드로의 커넥션 연결을 “Instance down” 메시지를 받은 즉시 수행 (JDBC Connection Pool은 사용자 요청 시점에 수행)
  • DB가 정상화된 후에 커넥션 자동 원복 (JDBC Connection Pool은 사용자의 수동 재시작 필요)

13-2. FCF 동작 원리


그림을 통해 FCF의 동작원리를 살펴보도록 하겠습니다.

<?xml version=’1.0′ encoding=’utf-8′?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Manager pathname=”” />
<Valve className=”org.apache.catalina.valves.CometConnectionManagerValve” />
<Resource
name=”jdbc/oow_ucp”
auth=”Container”
factory=”oracle.ucp.jdbc.PoolDataSourceImpl”
type=”oracle.ucp.jdbc.PoolDataSource”
description=”UCP Pool in Tomcat”
connectionFactoryClassName=”oracle.jdbc.pool.OracleDataSource”
minPoolSize=”3″
maxPoolSize=”20″
initialPoolSize=”3″
autoCommit=”false”
inactiveConnectionTimeout=”600″
fastConnectionFailoverEnabled=”true”
user=”scott”
password=”tiger”
url=”jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=OFF)(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.230)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.56.231)(PORT = 1521))
)
(CONNECT_DATA=(SERVICE_NAME=RAC)))”
connectionPoolName=”UCPPool”
validateConnectionOnBorrow=”true”
sqlForValidateConnection=”SELECT 1 FROM DUAL” />
</Context>

UCP로 첫 번째 요청이 처리된 이후에는 “그림-1″과 같이 minPoolSize 파라미터에 지정된 3개의 커넥션이 RAC1 인스턴스에 연결된 상태가 됩니다.

그림-1

13-1

Note
UCP에서 FCF를 사용하기 위해서는 fastConnectionFailoverEnabled 파라미터를 true로 설정하면 됩니다.  

RAC1 인스턴스의 장애가 발생하면 다음과 같은 일련의 일들이 발생합니다. (그림-2 참조)

  • RAC1에 연결된 세션 비정상 종료
  • RAC1 세션에 연결된 UCP 커넥션 객체들 상태가 Stale로 변경
  • RAC1 노드의 ONS 프로세스는 “INSTANCE down” FAN 메세지를 톰캣 서버로 전달

그림-2

13-2

 

FAN 메세지를 전달받은 톰캣 서버는 다음과 같은 일들을 수행합니다. (그림-3 참조)

  • Stale 커넥션 클린업
  • Failover노드로 minPoolSize에 정의된 개수만큼 커넥션 연결

그림-3

13-3

RAC1 인스턴스가 복구된 직후에, ONS는 “INSTANCE up” FAN 메세지를 톰캣 서버로 전달합니다 (그림-4 참조)

그림-4

13-4

“INSTANCE up” FAN 메세지를 전달 받은 톰캣 서버는 inactiveConnectionTimeout 설정 시간 이후에 2번 노드의 idle 커넥션을 종료한 후, 1번 노드로 커넥션을 연결합니다. (그림-5 참조)

그림-5

13-5

13-3. inactiveConnectionTimeout 파라미터 동작 방식


테스트 결과, UCP는 inactiveConnectionTimeout 주기 마다 idle 커넥션을 종료하고 다시 커넥션을 생성하는 것으로 확인되었습니다. 예를 들어, inactiveConnectionTimeout=60, minPoolSize=10 으로 설정했고, 60초동안 아무 일도 없다면 10개의 커넥션이 Close된 후에 다시 생성됩니다. 주의할 점은, 이때 10개의 DB 세션 또한 릴리즈 된 후에 다시 생성(fork)된다는 점입니다. 이러한 동작 방식은 V$SESSION.LOGON_TIME의 변화 및 V$SYSSTATlogon cumulative 지표의 증가를 통해서 관찰할 수 있습니다. 따라서 UCP를 사용할 경우에는 시스템의 워크로드에 맞게 inactiveConnectionTimeout, minPoolSize 값을 적절히 설정해야 합니다.

 

참고 사이트


http://www.hhutzler.de/blog/testing-ucp-connections-with-fcf-against-a-rac-12-1-0-2-database/

 

글을 마치며


이 글을 끝으로 로드 밸런싱과 Failover에 대한 기본적인 설명은 마무리가 된 것 같습니다. 다음 시간에는 RAC 아키텍처 중에서 가장 중요한 부분 중의 하나인 ASM에 대해서 다룰 예정입니다.

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