본문 바로가기 주메뉴 바로가기

최신IT소식

RAC 유무와 관계없이 오라클 환경 고가용성 확보하기 - 2부

관리자 2019-03-13 조회수 40



RAC 유무와 관계없이 오라클 환경 고가용성 확보하기 - 2부- 

 

이전 블로그 포스팅에서는 오라클 데이터베이스를 위한 고가용성 환경을 구축할 떄 생각해야 할 몇 가지 질문에 대해 살펴봤습니다. 가장 중요한 질문 중 하나는 “어느 정도의 가용성이면 충분한가?”입니다.

 

이번 포스팅에서는 퀘스트(Quest) 쉐어플렉스(SharePlex)오라클 RAC의 복잡함 없이 어떻게 고가용성 시스템을 위한 기반을 제공할 수 있는지에 대해 알아보겠습니다. 이 가용성은 많은 사용 사례에서 “딱 적당한” 정도의 가용성을 제공할 수 있습니다. 참고로 이 글의 주제는 쉐어플렉스 자체가 아닌 데이터베이스를 위한 고가용성 제공입니다.

 

이미 RAC를 사용 중인 환경에서 쉐어플렉스를 활용해 데이터베이스가 단일 장애 지점이 되는 경우를 방지하고 쉐어플렉스를 위한 고가용성을 제공하는 방법에 대해서는 향후 포스팅에서 다루겠습니다.

 

쉐어플렉스의 주요 기능 중 하나는 ‘논리적’ 또는 SQL 트랜잭션 수준에서 데이터베이스 복제를 수행한다는 점입니다. 따라서 낮은 수준에서의 복제, 그리고 ‘대기’ 또는 복제 데이터베이스를 사용하기에 앞서 데이터베이스 복구를 수행할 필요가 없습니다. 쉐어플렉스 타겟 데이터베이스는 전체 읽기/쓰기 모드로 항상 가용합니다.

 

고가용성에 쉐어플렉스를 사용할 경우 얻는 또 다른 이점은 단일 장애 지점을 손쉽게 방지할 수 있다는 것입니다. 데이터베이스 또는 물리적 스토리지가 공유되는 오라클 RAC와 달리 쉐어플렉스는 완전히 별개의 타겟 데이터베이스에 복제하므로 공유 스토리지 사용을 피할 수 있습니다.

 

고가용성을 위한 쉐어플렉스 구성

쉐어플렉스를 사용할 때 퀘스트는 ‘주’ 또는 ‘보조’ 데이터베이스 대신 ‘소스’와 ‘타겟’이라는 용어를 사용합니다. 쉐어플렉스 복제 환경의 모든 데이터베이스는 개방되어 있고 읽기/쓰기 모드로 실행되기 때문입니다. 이 포스팅에서 ‘소스’는 ‘주’ 또는 ‘정상’ 데이터베이스를 가리키고, ‘타겟’은 고가용성을 지원하게 될 데이터베이스를 가리킵니다.

 

고가용성을 위해 쉐어플렉스 타겟을 사용할 떄 고려해야 할 점은 다음과 같습니다.

 

● 데이터베이스에 BEQUEATH 연결 대신 TNS 별칭을 사용합니다. 이렇게 하면 장애조치와 역방향 복제가 조금 더 간편하게 됩니다.

 

● 소스 데이터베이스에는 1단계에서 만든 별칭, 가상 IP 또는 호스트 이름과 다른 TNS 별칭을 사용합니다. 이 별칭은 애플리케이션에서 소스에

서 타겟으로의 장애조치를 원활하게 하기 위해 사용합니다.

 

● 타겟에서 소스로의 ‘역방향’ 복제를 설정하는 것이 좋습니다. 역방향 복제를 설정하면 장애조치 후 타겟에 적용된 트랜잭션을 캡처하고, 데이터

손실 없이 소스로 ‘장애복구’할 수 있습니다.

 

● 실제 장애조치 프로세스를 자동화하는 데 도움이 되도록 하드웨어 또는 소프트웨어 ‘로드 밸런서’를 사용하면 좋습니다.

 

모든 쉐어플렉스 복제에서 첫 번째 단계는 소스에 포함된 것과 정확히 동일한 데이터를 사용해 타겟을 인스턴스화하는 것입니다. ‘쉐어플렉스 관리자 가이드’에서 RMAN과 같은 오라클 툴 또는 기타 툴을 사용하는 데 따르는 다운타임 없이 이 과정을 완료하기 위한 권장 사항을 볼 수 있습니다.

 

타겟 데이터베이스를 인스턴스화했거나, 인스턴스화 과정의 일부로 ‘현재 다운타임’ 인스턴스화를 수행하는 경우 구성 파일을 작성해야 합니다. 전체 스키마를 복제하는 경우 와일드카드 ‘expand’ 함수를 사용해서 한 라인에서 각 스키마를 복제할 수 있습니다. 예를 들어, GL 스키마를 복제하려는 경우의 구성 파일은 다음과 같습니다.

 

EXPAND               GL.% GL.% <Target HostName>@o.<TargetDB TNS ALIAS>

 

구성 파일을 확인하고 활성화한 후 트랜잭션이 소스에서 타겟으로 흐르고, 타겟은 사용 가능한 상태가 됩니다.

 

시스템과 애플리케이션에서 장애조치 구성

위에 언급했듯이 소스와 타겟 데이터베이스에 모두 TNS 별칭을 사용하는 것이 좋습니다. 또한, 소스와 타겟 서버/데이터베이스 사이를 ‘흐르는’ ‘가상’ TNS 별칭과 IP 주소를 설정해야 합니다. 이 세 번쨰 별칭은 애플리케이션을 가리키는 별칭입니다.

 

하트비트/ 장애 감지

타겟의 스크립트 또는 프로그램이 소스의 장애를 감지할 수 있도록 ‘하트비트’ 또는 장애 감지가 필요합니다. 네트워크 핑, ‘tnsping’ 또는 원격 데이터베이스 액세스 등의 형태가 될 수 있습니다.

 

장애조치

타겟이 장애를 감지하면 스크립트는 소스를 종료하고(네트워크 충돌 방지를 위해) 가상 별칭을 타겟을 가리키도록 변경하고, 설정된 경우 타겟에서 소스로의 역방향 복제를 시작해야 합니다. 또한, 이메일을 전송하거나 일종의 경보를 발령해야 할 수 있습니다.

 

로드 밸런서 사용

노드 중 하나가 다운된 것을 감지한 다음 정상 가동하는 노드로만 트래픽을 라우팅하는 하드웨어 또는 소프트웨어 로드 밸런서를 사용하면 장애조치에 필요한 코딩이 대폭 감소됩니다. 애플리케이션이 복수의 마스터 데이터베이스를 지원하도록 작성됐거나 지원하도록 애플리케이션을 수정할 수 있다면 로드 밸선서를 사용해서 두 노드로 모두 트래픽을 유도할 수도 있습니다. 이 사용 사례에 대해서는 향후 포스팅에서 다루겠습니다.

 

장애가 발생하면 한 데이터베이스에서의 연결이 끊어졌음을 인지하고 다시 연결하도록 애플리케이션을 코딩해야 합니다. 장애조치 스크립트는 일반적으로 1초 미만의 짧은 시간 내에 장애를 인지하고 데이터베이스의 가상 IP/별칭을 변경합니다. 또한 두 개의 개별 데이터베이스가 사용되고, 쉐어플렉스는 비동기 복제를 사용하므로 일부 장애조치 시나리오에서 커밋된 트랜잭션이 일부 손실될 가능성이 있습니다. 그러나 이러한 손실이 발생했는지 여부를 쉐어플렉스에 쿼리할 수 있으며 원래의 소스 데이터베이스가 복원되면 다시 동기화할 수 있습니다. 더 짧은 복구 시간이 필요하거나 더 높은 투명성이 필요한 경우 RAC를 사용하면서 쉐어플렉스로 보완하는 것이 좋습니다. 이에 대해서는 다음 포스팅에서 다룰 예정입니다.

테스트, 또 테스트

백업의 품질은 전적으로 마지막 복원에 따라 좌우된다는 말이 있습니다. 고가용성 시스템의 경우도 마찬가지입니다. “실제” 환경에서 테스트를 거치기 전까지는 계획대로 일이 진행될지 여부를 확신할 수 없습니다. 따라서 구현 계획의 마지막 단계로 장애조치를 최소한 한 번, 가능하면 두 번 이상 테스트해야 합니다. 장애조치를 테스트했다면 쉐어플렉스를 통해 협의된 서비스 수준을 충족하거나 초과 충족할 수 있다는 확신을 갖고 편히 쉬어도 됩니다.

 

쉐어플렉스에 대해서 더 자세히 알고 싶으시면 쉐어플렉스 제품 소개 페이지를 참고하시고, 궁금한 점이 있으시다면 언제든 퀘스트 소프트웨어 코리아로 연락 주시기 바랍니다.

 

 

 

 

 

  • 등록된 댓글이 없습니다.