OPS의 TAF (TRANSPARENT APPLICATION FAILOVER) 개념 및 구성

Question

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
OPS의 TAF (TRANSPARENT APPLICATION FAILOVER) 개념 및 구성 (8.1이상)
===================================================================
PURPOSE
Oracle8 부터는 OPS node 간의 TAF (Transparent Application Fail-over)가
제공된다. 즉 OPS의 한쪽 node에 fail이 발생하여도 해당 node로 접속하여
사용하던 모든 session이 사용하던 session을 잃지 않고 자동으로 정상적인
node로의 재접속이 이루어저 작업이 계속 진행하도록 하는 것이다.
이 문서에는 이 TAF에 대해서 간단히 살펴보고 실제 configuration을 기술한다.
SCOPE
Transparent Application Failover(TAF) Feature는
8i~10g Standard Edition에서는 지원하지 않는다.
Explanation
TAF가 cover하는 fail의 형태에 대한 설명과, TAF 시 지정하는 fail over의
type과 method에 대해서 설명한다.
(1) fail의 형태:
TAF는 다음과 같은 fail에 대해서 모두 TAF가 정상적으로 수행되게 된다.
단 MTS mode에 대해서는 전혀 문제가 없지만, dedicated mode의 경우는
반드시 dynamic registration형태로 구현이 되어야 정상적으로 TAF가 가능하다.
instance fail: mts의 경우는 문제가 없지만 dedicated mode의 경우는 반드시
dynamic registration 형태로 구성되어야 한다.
fail된 instance 측의 listener가 정상적이라 하더라도,
dynamic registration에 의해서 instance가 fail되면
listener로부터 deregistration되게 되어 listener 정보
를 확인 후 다른 node의 listener로 접속을 시도하게 된다.
그러나 dynamic registration을 사용하지 않게 되면 fail
된 instance 쪽의 listener는 fail된 instance 정보를
services로 보여주게 되고 해당 instance와 연결을 시도하
면서 ORA-1034: Oracle not available 오류가 발생하게 되
는 것이다.
instance & listener down: listener까지 down되게 되면 문제 발생 후
재접속 시도 시 fail된 쪽의 listener 접속이 실패하게 되고,
다른 node의 listener로 접속이 이루어지게 된다.
node down: node 자체가 down되는 경우에도 TAF는 이루어진다. 단 clinet
에 적정한 TCP configuration parameter인 keepalive 의 설정
이 요구되어진다.
node fail시 client와 server간의 작업이 진행중이라면
문제가 없지만 만약 server쪽에서 수행되는 작업이 없는
상태라면 cleint가 node가 down이 되어도 바로 인지할 수가
없다. client에서 다음 server로의 요청이 이루어지는
순간에 client가 더이상 존재하지 않는 TCP end point쪽으로
TCP packet을 보내게 되고, server node가 더이상 살아있지
않다는것을 확인하게 되는데 일반적으로 2,3분이 걸릴수
있다. node가 fail이 된경우 network에 대한 write() function
call이 오류를 return하게 되고, 이것을 client가 받은후
failover기능을 호출하게 되는 것이다.
client에서 idle한 상태에서도 server node가 down되었는지를
학인하려면 TCP keepalive를 설정해야 하며, 이 keepalive를
오라클의 connection에서 사용하려면 TNS service name에서
ENABLE=BROKEN절을 지정해 주어야한다.
DESCRIPTION절에 포함되는 이 ENABLE=BROKEN절에 대한 예제는
아래 구성 예제의 (3)번 tnsnames.ora 구성 부분에서 참조할
수 있다.
이렇게 ENABLE=BROKEN을 지정하면 network쪽 configuration인
keepalive 설정을 이용하게 되는데 이것이 일반적으로는
2 ~ 3시간으로 설정되어 있기 때문에 이값이 적당히 짧아야
TAF에서 의미가 있을 수 있다.
단 이 keepalive time이 너무 짧으면, 그리고 idle한
session이 많은 편이라면 network부하가 매우 증가할 수
있으므로 이 지정에 대해서는 os나 network administrator와
충분히 상의하여야 한다.
이 keepalive 대한 자세한 내용과 설정 방법은 <bulletin:11323:
SQL*NET DCD(DEAD CONNECTION DETECTION)과 KEEPALIVE의 관계>를
          참조한다.
(2) type: session vs. select
session은 유지하고 수행중이던 SQL문장은 모두 fail되는 session type과
DML문장은 rollback되고 select문장은 유지되는 select type이 제공된다.
select type의 경우도 fail된 instance에서만 얻을 수 있는 정보의 경우는
조회수행 도중 다음과 같은 오류를 발생시키고 중단될 수 있다.
예를 들어 해당 instance에 대한 gv$session으로부터의 조회와 같은것이 그
예이다.
ORA-25401: can not continue fetches
(3) method: basic vs. backup
fail발생시 다른 node로 session을 연결하는 basic method와,
미리 다른 node로 backup session을 연결해 두었다가 fail발생시 사용하는
backup method가 존재한다.
Example
TAF설정을 위해서는 init.ora, listener.ora, tnsnames.ora에 설정이 필요하다.
MTS mode에서는 문제가 없기 때문에 여기서는 반드시 dynamic registration으로
설정해야 하는 dedicated방식을 예로 들었다.
test는 Oracle 8.1.7.4/Sun solaris 2.8에서 수행되었다.
A/B 두 node를 가정한다.
(1)initSID.ora에서
- A node의 initSID.ora
service_names=INS1, DB1
local_listener="(address=(protocol=TCP)(host=krtest1)(port=1521))"
- B node의 initSID.ora
service_names=INS2, DB1
local_listener="(address=(protocol=TCP)(host=krtest2)(port=1521))"
service_names는 여러개를 지정가능한데, 중요한것은 두 node가 공통으로
사용할 service name한가지는 반드시 지정하여야 한다.
일반적으로 db_name을 지정하면 된다.
host=부분은 hostname이나 ip address를 지정하면 된다.
(2) listener.ora
LISTENER =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = tcp)
(HOST = krtest1)(PORT= 1521)))
B node에서는 krtest1대신 b node의 hostname혹은 ip address를 지정하면
된다
(3) tnsnames.ora은 지정하는 방법이 두가지입니다.
아래에 basic method와 backup method 두 가지 방법에 대한 예를 모두 기술한다.
이중 한가지를 사용하면 되며 backup method의 fail-over시 미리 연결된
session을 사용하므로 시간이 적게 걸릴수 있으나 반대 node에 사용안하는
session을 미리 맺어놓는것에 대한 부하가 있어 서로 장단점이 있을 수 있다.
두 설정 모두 TAF뿐 아니라 connect time fail-over도 가능한 설정이다.
즉 A node가 fail시 같은 tns service name을 이용하여서 (여기서는 opsbasic
또는 ops1) B node로 접속이 이루어진다.
address=로 정의된 address절이 위쪽을 먼저 시도하므로 정상적인 상태에서
B node로 접속을 원하는 경우는 opsbasic의 경우 krtest2를 위쪽에 적고,
ops1/ops2의 경우는 ops2를 사용하도록 한다.
여기에서 (enable=broken)설정이 되어 있는데 이것은 client machine에 설정되어
있는 TCP keepalive를 이용하는 것으로 network부하를 고려하여 설정을 제거할
수 있다.
a. basic method
krtest1의 tnsnames.ora에서는 opsbasic과 ops2에 대해서 설정해두고,
krtest2 node에서는 opsbasic과 ops1을 설정한 후, backup=ops2를
backup=ops1으로 수정하면 된다.
opsbasic =
(description=
(address_list=
     (enable=broken)
     (load_balance=off)
     (failover=on)
     (address= (protocol=tcp) (host=krtest1) (port=1521))
     (address= (protocol=tcp) (host=krtest2) (port=1521))
(connect_data =
          (service_name=DB1)
     (failover_mode=
     (type=select)
     (method=basic)
(backup=ops2))))
ops1 =
     (description =
     (enable=broken)
     (load_balance=off)
     (failover=on)
     (address=(protocol=tcp)(host=krtest1) (port=1521))
(connect_data = (service_name = DB1)))
ops2 =
     (description =
     (enable=broken)
     (load_balance=off)
     (failover=on)
(address=(protocol=tcp)(host=krtest2) (port=1521))
(connect_data = (service_name = DB1)))
b. preconnect method
아래 예제의 ops1, ops2가 모두 같은 tnsnames.ora에 정의되어 있어야 하며,
ops1을 이용하여 접속하여 krtest1을 사용시에도 미리 backup session을
krtest2에 맺어둔 상태에서 작업하게 된다.
ops1 =
(description =
(address_list =     
(enable=broken)
     (load_balance=off)
     (failover=on)
     (address=(protocol=tcp)(host=krtest1) (port=1521))
     (address=(protocol=tcp)(host=krtest2) (port=1521))
(connect_data = (service_name = DB1)
(failover_mode=
     (backup=ops2)
     (type=select)
     (method=preconnect))))
ops2 =
(description =
(address_list=
     (enable=broken)
     (load_balance=off)
     (failover=on)
(address=(protocol=tcp)(host=krtest2) (port=1521))
(address=(protocol=tcp)(host=krtest1) (port=1521))
(connect_data = (service_name = DB1)
(failover_mode=
     (backup=ops1)
     (type=select)
     (method=preconnect))))
Reference Documents
-------------------

Answer 1