multi data source는 fail-back: 성공

대부분의 애플리케이션은 데이터베이스를 참조하고 있는데, 애플리케이션 서버가 정상 서비스를 한다 할지라도 데이터베이스에 장애가 발생한다면 이는 곧 애플리케이션 가용성의 문제가 된다. 이런 DB로인한 가용성 문제를 해결하기 위해 RAC 솔루션을 사용하게 되는데, 이 경우에도 애플리케이션 서버에서 RAC DB 인스턴스 각각에 커넥션을 맺고 있는 풀을 유지하고 있다면, 해당 RAC DB 인스턴스에 장애가 발생했을 때, 이미 연결되어있던 커넥션들을 정리하고 새롭게 또 다른 RAC DB 인스턴스로의 커넥션을 생성해 주어야만 한다는 문제가 존재한다.

이를위해 오라클은 MultiPool이라는 기능을 제공하는데, 데이터소스에 연결된 커넥션풀을 다수로 설정할 수 있는 기능으로, 각각의 커넥션풀이 각기 다른 RAC DB 인스턴스를 바라보도록 구성한다. 따라서 하나의 DB 인스턴스에 장애가 발생하더라도 다른 커넥션풀을 통해 계속적인 서비스를 받을 수 있게되고, 장애노드가 정상화되었을 경우 자동Failback이된다. 이 기능은 Failover를 위해서 뿐만 아니라, 여러DB 인스턴스에 부하를 분산하기 위한 용도로도 활용될 수 있다.

1) DB Fail-Over는 특정 DB를 바라보고 있는 WAS가 해당 DB가 Down되었을 때 가용한 다른 DB로 전환하여

 지속적으로 서비스하는 기능을 일컫습니다.

 웹스피어에서 이 기능은 웹스피어 자체가 제공하지는 않습니다. 앞선 글에서 언급되었듯이 오라클 RAC의

 경우는 JDBC URL을 그 처럼 LOAD_BALANCE=OFF/ON을 통해 active-standby 혹은 active/active 모드로 운영할

 수 있으며, DB2의 경우는 DB2 Connect의 로드발란싱 및 Fail-Over기능을 이용하게 됩니다.

 경우에 따라, 약간 더 응용하여 여러대의 WAS서버, 여러개의 WAS인스턴스로 구성되어 있을 경우는

 Cell단위에 DataSource 하나를 정의하고, 정의시 JDBC URL상에 ip address 대신 머신명에 대한 alias를 등록하여

 이 alias를 기술한 후, /etc/hosts 파일에선 해당 alias에 매칭되는 물리적인 IP를 각각의 WAS서버마다

 적절히 각각의 DB를 바라보게 설정할 수 있습니다. 물론 이 경우도 나눠 주었다는 것 뿐, DB Fail-Over는

 오라클 JDBC URL이나 DB2 Connect기능을 활용해야만 합니다.

2) DB Fail-Back은 일단 한번 다른 DB로 Fail-Over되었던 상황에서 장애가 발생했던 DB가 다시 살아났을 때,

 Fail-Over되었던 연결들은 가급적 다시 원복되어 서비스 되는 기능을 일컫습니다. 그렇지 않으면, 죽었던

 첫번째 DB가 다시 살아나도, 계속 두번째 DB로만 서비스되므로, 이는 궁극적으로 이상적이지 않기 때문입니다.

 웹스피어에서 이러한 DB Fail-back을 관장하는 파라메터는 웹스피어 관리콘솔에서 해당 JDBC DataSource설정시

 해당 connection의 life time을 지정하는 파라메터(aged timeout)를 조정함으로 가능합니다.

 즉, 특정 connection이 일정 시간 이상 서비스 한 후에는 다시 새로 connection을 맺게 되는데, 이 때 새롭게

 Fail-back된 DB로 연결이 일어나는 것이지요.

 단점으로는, 각 개별 연결이 대부분 비슷한 시간에 맺어지므로, 대부분 비슷한 시간에 Fail-Back이 되는 것

 까지는 좋은데, 정상적인 연결상태에서도 울컥울컥하며 life-time 근방에서 새롭게 맺어지는 단점이

 있습니다.

PS: 개념적으로 미흡함이 있으나, 원하는 기능은 제대로 동작하더군요. 웹스피어 5.x는 그러했는데,

 웹스피어 6.x에서 다양한 개선사항이 있길 기대해 봅니다.

자바서비스넷 이원영

Phone: 010-6239-6498

E-mail: NOSPAM_lwy@javaservice.com

MSN: NOSPAM_javaservice@hanmail.net

장애유형

multi data source 사용시 XA error

현재 설정을 보면...
co32Domain 
  - MDS : ora10g_XA
  - DS : ora10g_dcor2, ora10g_dcor3

co42Domain
  - MDS : ora10g_XA
  - DS : ora10g_dcor2, ora10g_dcor3

위와같이 이름은 동일합니다. 여기서 MDS 를 이용했을 경우에만 이슈가 발생을 하고 있으며 DS 를 직접 lookup 해서 사용하는 경우는 XA 가 정상적으로 동작을 합니다.
그러나 debug 에는 exception 관련 stackTrace 가 나오는데 왜 나오는지 궁금하긴 합니다.
뭔가 정상이 아니라는 생각이 들어서요.

이름이 동일하면 일단 안됩니다.
무조건 limitation 이라서 MDS 든 아니든 모두 따라야만 합니다.
지금 당장 단일 DS 에서 문제가 없다고 해서 향후 운영에 들어가도
문제가 없으리란 보장을 할 수가 없습니다.