03. RAC 기반에서의 Load Balancing 과 Application Failover

1. RAC Load Balancing

Load Balancing 이란 용어  자체가  의미하는  것처럼  Load (서버에  걸리는  업무량)  을 

Balancing (균형이 맞게 배분) 하는 것을 의미

Load Balancing  을  구현하는  방법은  Client (주로  접속하는  PC)  쪽에서  설정하는  방식이 

있고  Server 쪽에서 설정하는 방법이 있음

1) Client 기반의 Load Balancing 설정하기

먼저 본인의 RAC 서버의 IP내역은 아래와 같음

아래 화면은 본인의 pc에 있는 tnsnames.ora 파일의 내용
아래의 HOST 부분은 RAC 서버의 VIP IP

위 화면은 Load Balancing 설정이 안되어 있는 상황의 화면
이럴 경우 접속요청을 받은 Client 는 tnsnames.ora 파일에서 Address_list 에 적혀있는 목록 중 접속 가능한 서버를 임의로 선택 한 후 서버에 접속을 하게 됨. 아래의 화면으로 확인

위 테스트의 결과에서 알 수 있듯이 시간을 다르게 해서 계속 다른 창에서 접속을 해도 분산이 안 되는 것을 알 수 있음. 접속되는 서버는 임의로 선택

이번에는 tnsnames.ora 파일에 LOAD_BALNCE = YES 라는 설정을 추가 한 후 접속 테스트를 해 봄

본인의 테스트에서는 위 그림처럼 분산이 되어 접속이 되었지만 실제 환경에서는 이렇게 분산이 안 될 경우가 있음

2) Server 기반의 Load Balancing 설정하기

Server 쪽의 listener.ora 파일을 수정해서 Load Balancing 을 구현

이 방법은 접속 요청을 받은 Listener 가 다른 서버에 있는 Listener 의 업무부하를 보고 자신보다 한가하면 지금 접속 요청 된 Client 에서 다른 Listener 를 찾아가라고 안내(Re-Direct)를 해 주는 것

먼저 Dynamic Register 기법을 이해해야 함

(1) Dynamic Register

Oracle 8i 이전 버전까지 Listener 가 서비스를 해 주는 instance 정보는 관리자가 수동(Static)으로 listener.ora 파일에 등록을 해야 했음. 그러나 8i 버전부터는 PMON 프로세스가 listener 에게 instance 들의 정보들을 자동(Dynamic)으로 알려줄 수 있도록 변경됨

이 기능을 사용하려면 초기화 파라미터 파일(pfilr 이나 spfile) 에 SERVER_NAMES 파라미터를 사용하여 서비스 하고 싶은 이름을 명시적으로 등록하면 되고 만약 이 설정이 없으면 자동으로 설치 시 지정한 DB_NAME을 사용하게 됨, 아래 과정은 RAC로 자동 설정되어 있음

그리고 local listener 파라미터를 설정

[oracle@rac1 admin]$ lsnrctl services 

위의 출력을 보면 별도의 설정이 없어서 기본값으로 서비스가 진행되고 있음을 알수 있음 Port=1521

그러나 실제 서비스에는 보안등의 이유로 기본으로 설정되어 있는 1521 번 Port를 사용하지 않고 Port를 다르게 변경하는 경우도 많으므로 여기서는 Dynamic Listener 설정을 하면서 RAC 서비스를 하는 Port 를 9001 번으로 변경하는 것을 하겠습니다.

Step 1. 현재 운영중인 서버의  spfile 에  LOCAL_LISTENER 값을 확인 후 새로운 이름으로 변경합

니다. ( 이 과정에서는 새로운  listener 이름을  LOCAL 로 했습니다.)

이것을 port 를  9001 로 지정한  "LOCAL" 이라는 이름의  listener 를 사용하도록 변경하고, 

이  예와  같이  Listener  이름을  변경하거나  사용하는  Port  를  변경하려면  반드시  서버의 

listener.ora 파일에 내용을 변경해 주어야 하며  local_listener 설정값을 지정해 주어야 함

SQL> alter system set local_listener=local scope=spfile; 

System altered. 

Step 2. 재 시작 후부터 적용이 되기 때문에  crs 전체를 중단합니다. 

[oracle@rac2 ~]$ crs_stop -all 

Attempting to stop `ora.rac1.gsd` on member `rac1` 

Attempting to stop `ora.rac2.gsd` on member `rac2` 

Attempting to stop `ora.rac2.ons` on member `rac2` 

Attempting to stop `ora.rac.db` on member `rac2` 

( 중간 생략 ) 

Step 3. RAC1 서버의  listener.ora 파일의 내용에 아래의 내용을 변경합니다. (prot = 9001)

Step 4. RAC1 서버의  tnsnames.ora 파일의 내용에 기존의 내용 아래에 다음 내용을 추가합니다. 

Step 5. RAC2 서버의  listener.ora 파일의 내용에 아래의 내용을 변경합니다. 

Step 6. RAC2 서버의  tnsnames.ora 파일의 내용에 기존의 내용 아래에 다음 내용을 추가합니다. 

Step 7. CRS 를 재 시작하여 확인합니다. 

[root@rac2 ~]# crs_start -all 

Attempting to start `ora.rac1.vip` on member `rac1` 

Attempting to start `ora.rac2.vip` on member `rac2` 

Attempting to start `ora.rac.rac1.inst` on member `rac1` 

Attempting to start `ora.rac.rac2.inst` on member `rac2` 

Start of `ora.rac2.vip` on member `rac2` succeeded. 

Start of `ora.rac1.vip` on member `rac1` succeeded. 

( 중간 결과는 생략 ) 

[oracle@rac2 admin]$ lsnrctl services 

Step 8. 접속 테스트를 할 클라이언트의  tnsnames.ora 파일을 아래와 같이 수정합니다. 

위 그림에서 Port 부분이  9001 로 설정

Client 에서 아래와 같이  rac 에 접속을 시도

위와 같은 방법으로 기본 Listener 가 아닌 관리자가 새로 생성한 local 이라는 이름의 Listener 를 사용하게 되고 여러 설정들을 변경할 수 있음

2. Application Failover 설정하기 

장애 상황을 대비한 RAC의 탁월한 기능 Application Failover 기능인 Transparent Application Failover ( TAF ) 와 Connection Time Failover ( CTF ) 가 있음을 숙지할 것

TAF : 인스턴스가 비정상 종료되어도 RAC1 에서 작업을 하던 사용자의 작업이 RAC2 로 그대로 넘어가서 사용자는 끊임없는 작업을 지속 할 수 있는것, 단 이 작업은 조회하는 ( SELECT ) 작업에만 적용됨

관련된 파라미터 : FAILOVER , FAILOVER_MODE

FAILOVER 는 FAILOVER 를 사용할 것인가를 설정하는 파라미터이며 ON / OFF 또는 YES / NO 의 값을 설정할 수 있고 기본값은 OFF

FAILOVER_MODE 는 TYPE 과 METHOD 의 세부 항복을 가지고 있음

* TYPE

- SESSION : 이 방식은 Client 가 select 를 수행하고 있는 도중에 해당 인스턴스가 장애 나서 중
단 될 경우 수행되던 SELECT 문은 에러가 발생하고 중단. 그리고 문제가 없는 다른 서버로 자동으로 재 접속이 됨  

- SELECT : 이 방식은 위의 SESSION 보다 발전한 방법으로 기존 서버에서 수행 중이던  SELECT 
문장을 새로운 서버에 접속 한 후 계속 수행해서 오류 없이 결과를 만들어 주는 방법

* METHODD

- BASIC : 장애가 발생할 경우 다른 서버를 찾아서 접속을 시도하는 방식

- PRECONNECT : 처음 접속을 할 때 장애를 대비해서 두 개의 접속을 미리 수행하는 방식. 즉  RAC1 에 접속할 때 장애를 대비해서  RAC2 에 미리 접속을 해 두었다가 장애가 발생했을 때 새로운 서버를 찾아 접속하는 시간을 줄이는 방식입니다. 이 방식은 만일의 경우를 위해 현재 사용하지 않는 세션을 하나 더 연결해서 리소스를 낭비 할 수 있으므로 주의해야 함