DB2 9.5로 고가용성 구현하기

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 초급

Monty Wright, DB2 전문가, IBM Advanced Technical Support

2008 년 9 월 30 일

데이터의 고가용성은 중요한 데이터베이스 시스템에 있어 필수적인 요구 사항입니다. 이 글에서는 DB2 9.5에서 이러한 기능을 제공하는 기능을 요약해 봅니다. 또한 현재 환경에 어떤 방법이 가장 적합한지 결정할 수 있도록 다른 솔루션에 대한 장단점을 알아봅니다.

소개

고가용성은 데이터베이스 애플리케이션에 있어 필수적인 요구 사항이다. IBM DB2 9.5에서는 이러한 요구 사항을 충족하는 여러 기능을 제공한다. 분산 플랫폼에서 DB2를 처음 사용하거나 한동안 사용해본 적이 있는 경우에도 가용성을 다루는 여러 기능 때문에 혼란스러울 수 있다. 예를 들어 어떤 기능을 언제 사용할 것인가 또는 해당 작업을 수행함으로써 얻을 수 있는 것은 무엇인가와 같은 문제가 여기에 해당된다.

이 글의 목적은 이러한 기능을 요약하고 가용성이 높은 데이터베이스 시스템을 구축하는 데 DB2 기술을 사용하는 방법을 안내하는 것이다. 또한 각 솔루션에 대한 비용과 이점을 설명한다.

본론으로 들어가기 전에 고가용성(High Availability - HA)이라는 용어가 무엇을 의미하는지 정의해 보자. HA는 종속 애플리케이션에서 필요할 때마다 데이터를 사용할 수 있도록 하는 요구 사항이다. HA의 목적은 가동 중지 시간(downtime)을 없애거나 최소화하는 데 있다. HA와 관련된 것으로 재해 복구(Disaster Recovery - DR)가 있다. DR은 HA와 달리 재난으로 인한 오류로 발생하는 데이터 손실로부터 데이터를 보호하는 것을 목적으로 한다.

용어 및 클라이언트/서버 데이터베이스 아키텍처

고가용성에 대해 이야기할 때 이해해야 하는 중요한 용어와 개념 몇 가지에 대해 먼저 이야기해 보겠다.

데이터베이스 솔루션에는 다음 세 개의 소프트웨어가 있다.

• 사용자 애플리케이션
• 클라이언트 소프트웨어
• 데이터베이스 엔진

또한 소프트웨어에는 솔루션을 작동하는 데 반드시 올바로 수행되어야 하는 다음과 같은 자원이 있다.

• 서버 소프트웨어
• 네트워크 연결
• 디스크 저장소
• 운영체제

HA 솔루션을 디자인할 때는 이러한 측면을 모두 고려해야 한다. 단순히 데이터베이스 엔진의 가용성을 높이기 위해 HA 솔루션을 만들 필요는 없다. HA 솔루션 디자인은 단지 기술적인 문제만이 아니라 솔루션의 비용, 기술 요구 사항과 같은 요소이며 관리 요구에도 무게를 두어야 한다.

데이터베이스 애플리케이션은 클라이언트/서버를 기반으로 한다. 애플리케이션이 단일한 결과를 낼 수 있는지 여부는 데이터베이스 소프트웨어 통합에 달려있다. 따라서 솔루션을 선택하고 설계할 때 이러한 통합을 수행하는 방법을 이해하는 것이 중요하다.

SQL 트랜잭션은 두 개의 기본 유형, 즉 읽기(read)와 쓰기(write)로 나뉜다. 읽기 트랜잭션은 삽입(insert), 업데이트(update) 또는 삭제(delete) 작업이 필요 없는 select 문이다. 반면 쓰기 트랜잭션은 적어도 한 개의 데이터베이스를 변경한다. 읽기 트랜잭션에는 데이터의 일관된 뷰가 필요하다. 즉 두 개의 읽기 트랜잭션이 동시에 제출되었는데 두 트랜잭션이 같은 데이터 범위를 선택하는 경우 단일한 결과를 생성해야 한다. 쓰기 트랜잭션의 경우 트랜잭션이 실패한 경우에도 커밋된 데이터베이스 변경이 지속되어야 한다. 비즈니스 요구 사항은 어떤 HA 솔루션을 사용할 수 있는지 또는 가장 적합한지를 결정하는 데 영향을 준다. 일반적으로 HA 솔루션 디자인은 두 요소, 즉 가동 시간(uptime) 요구 사항과 트랜잭션의 일관성에 기반을 둔다. 비즈니스에서 가용성은 많이 요구되지만 읽기 일관성은 중요하지 않다면 비동기 옵션이 비용 효율이 더 높은 접근 방법이 될 것이다. 이와 달리 트랜잭션의 일관성이 필수 요구 사항이라면 동기화 옵션이 좀 더 요구된다. 트랜잭션의 일관성과 가용성이 모두 필요한 경우라면 선택의 폭이 더 좁아질 것이다.

위로

고가용성

선택할 수 있는 고가용성 유형은 연속적 가용성(continuous availability)과 페일오버 가용성(failover availability) 두 가지가 있다.

연속적 가용성

연속적 가용성을 사용하면 가동 중지 시간이 느껴지지 않을 정도로 데이터베이스 엔진이 처리를 계속할 수 있어야 한다. 이 시나리오에서 가동 중지 시간은 아예 존재하지 않거나 1초의 몇 분의 1, 또는 많아야 몇 초 정도에 불과하다. 이러한 유형의 가용성은 예전부터 가장 중요한 애플리케이션에서만 구현되어 왔다. 이 목표를 달성하려면 중복성의 정도가 대단히 높아야 한다.

이러한 시스템 유형에 대한 기본 디자인은 프로그램적(programmatic), 공유(shared), 여러 복사본(multiple copy)의 세 가지가 있다.

프로그램적(programmatic)

프로그램적 디자인은 기본적으로 데이터베이스 레벨이 아니라 사용자 애플리케이션 레벨에서 구현되는 사용자 프로그래밍 솔루션이다. 애플리케이션은 SQL 트랜잭션을 여러 시스템에서 구현한다. 한 시스템에 오류가 발생해도 상대 시스템에서 처리 중인 트랜잭션에 방해가 되지 않는다. 애플리케이션 논리로 인해 데이터베이스 시스템 중 하나에 오류가 발생해도 애플리케이션은 계속 작업을 수행할 수 있다.

이 시스템 유형은 유연성은 가장 좋지만 제대로 구현하려면 아주 많은 노력을 기울여야 한다. DB2는 작업의 분산 유닛과 트랜잭션 모니터를 지원하기 때문에 이러한 유형의 환경을 코딩할 때 도움을 주지만 애플리케이션 개발 팀에서 더 많은 작업을 해야 한다. 모든 애플리케이션에서 이러한 디자인을 지원하도록 코딩해야 한다. 최신 애플리케이션의 경우 사용자 환경을 이해하지 못할 것이다. 그 외 해결해야 할 몇 가지 문제는 다음과 같다.

1. 데이터베이스 시스템을 동기 상태로 유지
2. 비결정적(non-deterministic) 함수 사용
3. non-atomic 저장 프로시저 사용

비결정적 함수는 어디서 실행되는지에 따라 다른 결과를 생성할 수 있는 함수다. 예를 들어 DB2 특수 레지스터 CURRENT TIMESTAMP는 시스템 시계들이 서로 동기화되지 않은 특성 또는 여러 시스템에 문(statement)이 정확히 같은 시간에 도달하는 것이 불가능하다는 사실 때문에 다른 시스템에서 다른 결과를 생성한다.

non-atomic 저장 프로시저는 기본적으로 커밋되지 않았거나 전체적으로 롤백되지 않은 저장 프로시저다. 저장 프로시저 내부에 있는 트랜잭션은 실행될 때의 조건에 따라 다른 결과를 생성할 수 있다.

공유(Shared)

공유 디자인은 주요 자원을 공유하는 동안 중복되는 시스템의 사용을 결합한다. 이러한 공유 디자인은 두 대 이상의 시스템이 활성화되어 작업을 수행하다가 그 중 한 대에 오류가 발생하는 경우에도 다른 시스템이 계속 작업을 수행할 수 있는 방식으로 작동된다. 멤버들이 완전히 독립적이지 않으며 작업 수행을 위해 메커니즘이나 데이터를 공유해야 한다.

가장 일반적인 공유 자원은 물리적 데이터 저장소다. 그림 1에서는 어떻게 데이터가 중앙 저장소 시스템에 저장되고 세 멤버에 의해 접근되는지를 나타낸다.

이 아키텍처를 올바로 작동하기 위해 공유해야 하는 유일한 자원으로 공유 저장소만 있는 것은 아니다. 각 시스템이 작업을 수행하려면 일부 유형의 잠금(locking) 및 시계(clock) 메커니즘을 공유해야 한다. 잠금 메커니즘은 각 시스템에서 다른 멤버가 수행 중인 작업을 방해할 만한 어떠한 활동도 수행하지 않고 데이터를 공유할 수 있게 한다. 예를 들어 한 멤버가 행을 업데이트하고 있을 때 다른 멤버가 커밋되지 않은 읽기 이외의 고립 레벨(isolation level)을 사용하여 해당 행을 읽지 않아야 한다. 이러한 이벤트를 방지하려면 멤버간에 잠금 메커니즘을 공유해야 한다. 일관된 뷰 시간을 확인하려면 공유 시계 메커니즘을 구현해야 한다.

이 아키텍처의 특성은 상당히 복잡하며 하드웨어와 소프트웨어의 통합의 정도가 높아야 한다. 해결해야 하는 몇 가지 문제는 잠금 메커니즘, 시스템 타이머 통합, 데이터 버퍼 공유 또는 비공유 및 로깅 메커니즘이다. 이러한 메커니즘은 구현하는 방법에 따라 성능과 가용성에 큰 영향을 미친다. 멤버가 데이터 버퍼를 공유하지 않으면 각 멤버가 똑같은 데이터를 버퍼링할 가능성이 있다. 멤버간에 데이터 소유권이 분할되어 있으면 데이터 버퍼링은 높아지지만 트랜잭션 라우팅에 문제가 생길 수 있다. 업데이트를 처리해야 하고 해당 데이터 부분을 소유하지 않은 멤버가 수신하는 경우 다른 멤버에게 라우팅되어야 한다. 일반적으로 이러한 유형의 라우팅은 성능에 영향을 미치며 올바른 멤버에게 트랜잭션을 라우팅하도록 애플리케이션에 코드를 구현해야 할 수도 있다. 멤버가 실패하는 경우 작업을 계속하려면 다른 멤버가 작업을 처리해야 하므로 가용성에도 영향을 줄 수 있다. 가장 이상적인 것은 어떠한 추가 작업도 할 필요가 없고 나머지 멤버에게 영향을 주지 않으면서 작업이 계속되는 것이다. 하지만 일부 공유 디자인에서는 모든 트랜잭션을 일시 중단하거나 중지해야 하며 캐싱과 잠금 메커니즘을 다시 만들어야 한다. 따라서 기본적으로 이러한 작업을 완료할 때까지 가동 중지 시간이 생긴다.

데이터 공유 환경에서 DB2 for zOS는 공유 아키텍처의 이상적인 목표를 보여 준다. 이 환경의 기초는 sysplex 타이머와 커플링 기능을 제공하는 z Parallel Sysplex다. 커플링 기능은 고도로 통합된 구성 요소로서 잠금 기능과 버퍼 풀 같은 공유 자원을 생성할 수 있게 한다. 또한 멤버간 통신 기술이 대단히 효율적이다. 한 멤버의 실패가 다른 멤버의 트랜잭션 워크로드에 영향을 주지 않는다. 또한 가용성이 높아져 용량 향상과 워크로드 밸런싱을 획득할 수 있다. 이 솔루션을 효율적으로 사용하도록 애플리케이션을 변경할 필요가 없다.

zOS가 아닌 DB2 플랫폼에서는 이러한 유형의 아키텍처를 지원하지 않는다.

공유 가용성에 대한 자세한 정보는 참고자료에서 참조할 수 있다.

여러 복사본

여러 복사본 디자인에서는 워크로드를 복사본 간에 분산함으로써 데이터베이스의 여러 복사본을 활용한다. 복사본에 오류가 발생해도 다른 데이터베이스 복사본에서 워크로드가 계속 실행된다. 해결해야 하는 가장 큰 문제는 어떻게 데이터베이스의 여러 복사본을 사용하면서 복사본을 동기 상태로 유지하는지와 어떻게 복사본 간에 일관된 쿼리 결과를 생성하는가 하는 문제다. 이러한 복사본을 만들고 동기화하는 가장 간단한 방법으로 일부 복제 솔루션 유형이 있다. 하지만 전통적인 복제 솔루션에는 고유한 비동기 특성이 있기 때문에 페일오버(failover) 절에서 이 시나리오를 설명하겠다.

xkoto의 Gridscale은 세련된 동기화 프로세스뿐 아니라 로드 밸런싱까지 갖춘 또 다른 여러 데이터베이스 복사본 솔루션을 제공한다. 그림 3은 Gridscale 솔루션의 기본 아키텍처를 보여준다.

Gridscale은 데이터베이스 솔루션에서 트랜잭션 계층의 역할을 수행한다. 즉 트랜잭션 작업을 가용성, 시스템 활용 또는 동기화 상태를 기준으로 하여 다른 데이터베이스 복사본에 보낼 수 있다. 복사본을 사용할 수 없으면 작업을 다른 복사본으로 이동하기만 하면 된다. 이렇게 하면 워크로드가 복사본의 시스템 로드를 기준으로 다른 복사본에 이동한다.

쓰기 트랜잭션(삽입, 업데이트, 삭제)은 동시에 모든 복사본으로 보내진다. Gridscale은 복사본이 쓰기 트랜잭션에 응답할 때 동기화되는지 추적한다. 복사본이 쓰기 트랜잭션에 응답하면 복사본이 그 이후의 읽기 트랜잭션(select)에 적합해진다. 이러한 메커니즘은 트랜잭션 작업이 항상 일관된 결과를 생성할 수 있게 한다.

실패 시점(failure point)을 만들지 않기 위해 Gridscale 시스템을 클러스터링할 수 있다. Gridscale은 고유의 캐싱 및 트랜잭션 로깅을 구현하여 여러 상황에서 사용될 수 있다. 읽기 트랜잭션이 실패한 복사본에 지정되거나 적합한 시간 내에 반환되지 않으면 트랜잭션이 다른 복사본으로 라우팅될 수 있다. 이러한 프로세스는 애플리케이션에 있어 완전히 투명하다. 어떤 유형의 실패 또는 유지 관리 이유로 인해 복사본이 중단되면 Gridscale 트랜잭션 로그를 사용하여 동기화할 수 있다. 또한 프로세스가 완료되면 분산 워크로드 작업 수행을 시작할 수 있다. 확장성 향상을 위해 다른 복사본을 추가하는 것은 복사본 중 하나에서 백업을 복원하거나 Gridscale이 새 시스템을 다른 복사본과 동기화하도록 하는 것만큼이나 간단하다.

DB2와 Gridscale 솔루션의 구현과 관리는 매우 간단하다. Gridscale 관리 도구를 사용하여 복사본을 생성하거나 동기화할 수 있다. Gridscale 도구를 통해 시스템 워크로드를 전체적으로 또는 각 개별 복사본에서 평가할 수 있다. 새 복사본을 추가할 수 있을 뿐 아니라 작업을 이동하여 다른 복사본을 해제할 수 있다. 이러한 유연성으로 인해 롤링 시스템 유지 관리를 수행할 수 있다. 모든 복사본이 같은 수정 또는 릴리스 레벨에서 수행될 필요는 없다. 복사본을 오프라인으로 하여 다른 소프트웨어 또는 하드웨어 유지 관리를 수행한 다음 Gridscale을 사용하여 시스템을 동기화하고 다시 사용 가능하게 할 수 있다.

또한 Gridscale은 분산 복사본에서 발생하는 다른 많은 문제를 해결한다. 예를 들어 가능한 경우 비결정적 기능을 Gridscale 서버에서 구현한다. 대부분의 시나리오에서 Gridscale은 클라이언트 애플리케이션을 변경할 필요가 없다. 클라이언트 쪽에서는 DB2 드라이버가 Gridscale 드라이버로 교체되어 Gridscale에 관련된 추가 기능을 수행한다. Gridscale 드라이버는 자바, DB2 CLI뿐 아니라 .NET 애플리케이션에도 있다. 애플리케이션은 Gridscale이나 트랜잭션 계층과 관계가 없다.

솔루션의 전반적인 효과는 개별 또는 여러 시스템의 손실로 인한 가동 중지 시간이 없으며 확장성 향상과 비용 절감에 있다. 더욱 강력한 시스템 또는 더 비싼 저장소 시스템을 구입할 필요 없이 일반 하드웨어를 사용할 수 있으므로 비용을 줄일 수 있다.

여러 복사본 가용성에 대한 자세한 정보는 참고자료에서 참조할 수 있다.

페일오버 가용성(Failover availability)

페일오버 가용성은 비록 짧지만 일정 기간 동안 트랜잭션 프로세싱에 데이터베이스 엔진을 사용할 수 없기 때문에 연속적인 가용성과 다르다. 이러한 유형의 솔루션의 필수 요소는 다음과 같다.

• 주(primary) 및 보조(secondary) 시스템
• 실패 감지(failure detection)
• 데이터 소스 이동

두 시스템에 데이터베이스 데이터의 복사본이 있거나 두 시스템 모두 단일 복사본에 접근할 수 있어 실패를 감지하면 페일오버가 수행된다. 페일오버가 진행되는 동안 데이터 소스는 주 시스템에서 보조 시스템으로 이동한다.

페일오버 가용성에는 동기와 비동기의 두 유형이 있다. 동기 가용성은 주 시스템과 보조 시스템에 있는 데이터 소스가 동일하고 페일오버 이후에 데이터 연속성이 완전하게 유지됨을 보장한다. 비동기 가용성은 주 시스템과 보조 시스템의 데이터베이스가 완전히 동기화되는 것을 보장하지 않는다. 주 시스템에서 보조 시스템으로 데이터베이스의 변경 내용을 이동하는 방법은 다양하다. 하지만 한 시스템에서 다른 시스템으로 어떤 데이터가 마이그레이션되지 않으면 프로세스에서 창(window)을 내보낸다. 데이터의 양이 매우 적어 창이 짧을 수 있지만 솔루션을 결정할 때는 이점을 고려해야 한다.

이제 동기 또는 비동기 페일오버 가용성을 선택하기 위한 옵션을 살펴보자.

동기 페일오버 가용성에는 특수 HA 소프트웨어와 동기 복제의 두 종류가 있다.

특수 HA 소프트웨어(Specialized HA Software)

동기 방법은 특수 HA 소프트웨어를 사용하여 데이터베이스 소프트웨어를 통합함으로써 HA 클러스터를 생성한다. HA 소프트웨어 지원은 운영체제 플랫폼에 따라 다르다. 일반적으로 사용할 수 있는 HA 솔루션은 다음과 같다.

Tivoli® System Automation(TSA) - 리눅스, AIX

Veritas Cluster Server - 윈도(Windows®), AIX, 리눅스

High Availability Cluster Multiprocessing(HACMP - AIX)

Microsoft Cluster Server(MSCS) - 윈도

Sun Cluster - 썬

Steeleye Lifekeeper - 리눅스, 윈도

위에 나열된 옵션은 해당 플랫폼에 대해 가장 일반적인 옵션이다. 기타 HA 소프트웨어 솔루션도 사용 가능하다.

이러한 모든 솔루션은 기본적으로 같은 방법으로 수행된다. 실패가 발생하면 데이터베이스 서버가 한 시스템에서 백업 시스템으로 이동할 수 있다. 이 작업을 수행하기 위해 HA 소프트웨어가 필요한 모든 자원을 보조 시스템으로 이동한다. 이러한 자원에는 물리적 데이터베이스의 디스크 자원, 네트워크 자원, 데이터베이스 서버 자원이 포함된다.

HA 클러스터 솔루션에서 물리적 데이터베이스의 단일 복사본이 공유 저장소 시스템에 저장된다. DB2 환경에서는 한 번에 한 시스템만 저장소 배열을 소유할 수 있다. 실패를 감지하면 저장소에 대한 소유권이 주 시스템에서 보조 시스템으로 이동된다. 네트워크 자원도 이동된다. 마지막으로 데이터베이스 서버 자원이 보조 시스템에서 시작되면 데이터베이스를 사용할 수 있다.

실패 감지는 서버간의 "하트비트(heartbeat)" 연결로 수행된다. 이 "하트비트"는 HA 소프트웨어 기능으로 하드웨어와 소프트웨어 실패를 모두 감지한다.

데이터베이스에 복사본이 하나만 있기 때문에 항상 동기 상태에 있다. 페일오버와 데이터베이스 엔진의 재시작 시간은 다음과 같은 여러 요소에 따라 다르다.

• 실패 감지에 필요한 시간
• 데이터베이스 자원 종속성(저장소 배열, 네트워킹 자원 등)을 이동하는 데 필요한 시간
• DB2 엔진이 크래시 복구를 수행하는 데 필요한 시간

DB2는 데이터베이스가 올바로 종료되지 않으면 항상 크래시 복구를 수행한다. 크래시 복구는 로그 파일을 처리하여 커밋된 모든 트랜잭션이 디스크에 쓰여지도록 하며 커밋되지 않은 트랜잭션은 롤백한다. 이 작업을 수행하는 데 필요한 시간은 실패 시점에 데이터베이스 로그에 "열린" 상태로 있던 작업의 양에 따라 다르다. 전체 페일오버에 몇 초가 걸릴 수도 있으며 로그 파일에 처리해야 할 워크로드가 많은 경우 더 길어질 수도 있다.

이 유형의 가용성 솔루션의 이점은 애플리케이션 또는 클라이언트 구성 디렉터리를 변경할 필요가 없다는 것이다. HA 소프트웨어는 데이터베이스 연결 시 가상 IP 자원을 제공한다. 실패가 감지되면 IP 주소가 페일오버되어 애플리케이션이 이전에 사용했던 것과 같은 연결 문을 사용할 수 있다. 페일오버가 수행되면 모든 애플리케이션의 연결이 해제되고 클라이언트가 통신 오류 조건을 애플리케이션에 반환한다. 일단 데이터베이스 서버가 보조 시스템에서 실행되면 애플리케이션에서 간단히 연결 문을 다시 내보내 이전처럼 작업을 계속 처리할 수 있다. 클라이언트의 자동 재라우팅(reroute) 기술은 이후 절에서 다시 설명하겠다.

페일오버를 대기하는 동안 보조 시스템이 유휴 상태로 남아 있을 필요는 없다. 양쪽 서버가 모두 다른 데이터베이스를 호스팅하는 상호 인계 구성(mutual takeover configuration)으로 시스템을 구성할 수도 있다. 실패가 발생하는 경우 각 시스템은 상대 시스템의 워크로드를 인계할 준비가 되어 있다. 그림 3은 HA 소프트웨어 솔루션의 예다.

동기 복제는 디스크 저장소 복제 및 DB2 HADR(High Availability Disaster Recovery) 구현 방법 모두에서 사용할 수 있다.

디스크 저장소 복제

디스크 저장소 복제는 특수 저장소 하드웨어 및/또는 소프트웨어를 사용하여 보조 위치에서 주 DB2 서버의 동기 디스크 쓰기를 수행한다. 주 위치에서 실패가 발생하면 데이터베이스 리소스가 보조 위치에서 시작된다. 저장소 하드웨어/소프트웨어는 양쪽 위치 모두에서 동기 디스크 블록 쓰기를 수행해야 한다. 그렇지 않으면 대기(standby) 위치가 주 위치와 동기 상태에 있지 않을 수 있다. IBM PPRC(Peer to Peer Remote Copy)를 사용하는 디자인에서 이러한 유형의 예가 그림 4에 표시되어 있다. 모든 데이터 저장소 쓰기가 양쪽 위치에서 동기적으로 수행되어야 하기 때문에 솔루션을 디자인할 때는 주 사이트와 보조 사이트 사이에 필요한 IO 대역폭을 고려해야 한다.

DB2 HADR과 DB2 HA 기능

DB2 HADR(High Availability Disaster Recovery)은 DB2 로깅 기술을 기반으로 한 고성능 데이터베이스 복제 시스템이다. DB2 HADR 시나리오는 주 시스템과 대기 시스템의 두 DB2 시스템으로 구성된다. 주 시스템에서 모든 트랜잭션 작업이 수행되며 모든 데이터베이스 변경 사항이 대기 시스템에 복제된다. 실패가 발생하면 단일 명령을 사용하여 대기 시스템의 역할을 주 시스템으로 전환할 수 있다.

HADR은 로그된 모든 DB2 작업의 동기 복제를 제공한다. DB2 HADR 쌍에서 작업을 수행하는 두 DB2 시스템에 대한 기본 요구 사항은 TCP/IP로 연결되어 있어야 한다는 것이다. HADR 설정과 관리는 매우 간단하며 DB2에서는 이 작업 수행을 위해 마법사를 제공한다.

HADR이 데이터를 복제하는 기본 방법은 DB2 로그 쓰기(log write)를 로컬 디스크와 대기 시스템에 동시에 보내는 것이다. 대기 시스템이 로그 쓰기를 받으면 주 시스템에 수신 확인(acknowledgement)을 보낸다. 주 시스템은 대기 시스템에서 로컬 쓰기 IO와 수신 확인을 받으면 트랜잭션이 커밋된 것으로 간주한다. 클라이언트나 애플리케이션에서는 이러한 작업을 알 필요가 없다. 시스템 간에 보내져야 하는 데이터의 양은 로그되는 작업에만 제한된다. 데이터 저장소 페이지에 대한 실제 변경 내용은 양쪽 시스템에서 독립적으로 수행된다. 따라서 필요한 실제 대역폭이 현저하게 감소한다.

실행 중인 HADR의 오버헤드는 아주 작다. 기본 복제 방법(다른 방법 사용 가능)에서 필요한 것은 주 시스템에 수신 확인을 반환하기 전에 대기 시스템의 메모리에 로그 쓰기가 수신되어야 한다는 것뿐이다. 동시에 로컬 쓰기 IO를 수행하는 작업이 TCP/IP를 통해 대기 시스템에 데이터를 전송하는 것보다 많은 경우가 있다. 데이터 변경 사항만 복제되어야 하기 때문에 읽기 트랜잭션은 HADR 구현에 영향을 주지 않는다. 이러한 상황에서는 실행 중인 HADR의 영향이 거의 없다. 로그되는 트랜잭션을 많이 수행하는 상황에서는 HADR의 영향이 시스템간 네트워크 대역폭과 대기 시간에 의해 결정된다. 네트워크 대역폭이 예상 로깅 활동보다 큰 경우 성능에 큰 영향을 주지 않는다.

쌍의 연결이 끊어지는 경우 HADR에 대한 타임아웃 기간을 설정하여 끌 수 있다. HADR이 꺼진 후에도 주 시스템은 트랜잭션을 계속 정상으로 처리할 수 있다. 연결이 복원되면 HADR을 다시 켤 수 있다. 이렇게 하면 대기 시스템이 주 시스템과 통신하여 동기화된 상태가 될 때까지 "따라잡기(catch-up)" 작업을 수행한다. 그림 5에서는 HADR이 주 시스템과 대기 시스템의 동기화 프로세스를 보여준다.

HADR의 페일오버 작업은 HA 소프트웨어를 사용하여 자동화할 수 있다. AIX와 리눅스용 DB2 9.5에는 DB2 HA(High Availability) 기능이 포함되어 있다.

DB2 HA 기능은 TSA와 DB2 클러스터 매니저 애플리케이션 프로그래밍 인터페이스(API)가 고도로 통합된 구현이다. AIX 또는 리눅스에 DB2를 설치할 때 이 기능을 설치하기 위한 옵션이 있으며 이 옵션을 선택하면 TSA를 자동으로 설치한다. TSA와 DB2의 구성은 DB2 High Availability Configuration Utility(db2haicu)를 통해 구현된다. 이 유틸리티를 사용하면 HA 클러스터 구성이 매우 단순해진다. HA 기능의 또 다른 중요한 이점은 클러스터 매니저 API를 구현한다는 것이다. 클러스터 매니저 API를 사용하면 DB2가 클러스터를 인식할 수 있다. 클러스터가 DB2 시스템의 변경 사항을 인식하면 HA 클러스터가 이를 자동으로 처리하게 한다(예: DB2 엔진 중지). DB2는 관리자가 엔진을 중지시킨다는 것을 HA 클러스터에게 인식시키기 때문에 중지 이벤트로 인해 리소스를 다시 시작하거나 전송하는 조치를 취할 필요가 없다.

또한 DB2 HADR은 롤링 업그레이드를 수행할 수 있게 하여 가용성을 높인다. 주 및 대기 역할은 시스템이 동기화 상태에 있기만 하면 언제든지 서로 전환될 수 있다. 시스템 유지 관리 작업, 업그레이드 또는 DB2 픽스 설치와 같은 작업을 수행하려는 경우 HADR을 끌 수 있다. 대기 시스템에서 유지 관리 작업을 수행하는 동안에 주 시스템은 평소와 같이 작업을 계속 수행할 수 있다. 유지 관리 작업을 완료하여 HADR을 다시 켜면 시스템이 자동으로 다시 동기화되고 필요한 경우 유지 관리 작업을 원래의 주 시스템에서 수행하도록 역할을 전환할 수 있다.

DB2 복제

DB2 복제는 전통적인(traditional) 복제와 큐 기반(queue-based) 복제의 두 스타일로 제공된다. 복제 옵션은 기본적으로 비슷하지만 각 솔루션 간에 차이를 만들고 고유의 장점을 유지할 수 있도록 복제 도구가 사용된다.

복제는 비동기 프로세스이므로 페일오버 동안 복사본 간에 모든 데이터가 일관됨을 보장하지 못한다. 복제는 구성이 가능하지만 기본적으로 데이터베이스 테이블의 변경 사항을 한 위치에서 다른 위치로 복제하는 것을 기반으로 한다. 복제의 구성 가능한 특성으로 인해 여러 옵션을 사용할 수 있는데, 여기에는 복제를 위한 테이블 및/또는 데이터 범위의 서브셋만 선택, 복제하는 동안 데이터 변형 및 여러 복제 대상 설정 등이 있다. 네트워크 대역폭이 고객 요구를 충족할 만큼 충분하다면 거리는 문제가 되지 않는다.

복제는 시스템이 OS 플랫폼을 달리 하여 호스팅되거나 데이터베이스 관리 시스템을 다르게 사용할 수 있게 한다. 복제 소스와 대상은 "살아 있는" 것처럼 각 시스템에서 동시에 작업이 수행될 수 있다. 예를 들면 한 시스템에서 트랜잭션을 처리하는 동안 보조 시스템이 보고서를 만들거나 백업을 수행하는 데 사용될 수 있다. 복제는 사용자 정의 테이블에 제한된다. 시스템 카탈로그에 대한 변경 사항은 복제될 수 없다. 예를 들어 테이블 권한에 대한 변경 사항의 경우 복제가 이러한 변경 사항을 복제할 수 없기 때문에 모든 시스템에서 수행되어야 한다.

DB2의 전통적인 복제 방식(SQL 복제라고도 함)은 통합된 DB2 기능이다. 이 기능은 캡처(capture)와 적용(apply)의 두 부분으로 이루어져 있다. 복제 관리자는 테이블을 복제될 수 있는 복제 소스로 지정한 다음 이전 단계에서 가져온 복제 소스를 해당 소스로 사용하여 보조 시스템의 대상 데이터베이스에 복제 구독(subscription)을 만든다. 캡처 프로세스는 트랜잭션 스테이징(staging) 테이블을 모니터링하여 시간 간격을 두고 구독 대상에 변경 사항을 이동한다.

전통적인 복제의 실행과 관련하여 오버헤드가 일부 있다. 추가 작업의 양은 소스 테이블에서 수행하는 삽입, 업데이트, 삭제 작업의 양에 따라 다르다. 복제는 로그 파일만 분석하고 기본(base) 테이블은 분석하지 않기 때문에 기본 테이블에 대한 추가 잠금은 필요 없다. 하지만 스테이징 테이블을 채우고(테이블 변경) 이러한 트랜잭션을 로그하는 데 데이터베이스 자원이 필요하다. 그림 6에서는 전통적인 복제 시나리오의 기본을 보여 준다.

DB2 큐 복제는 전통적인 복제와 비슷하다. 하지만 스테이징 테이블이 없으며 대신 변경 사항이 메시지 큐에 직접 배치된다. 큐는 Websphere® Replication Server에서 제공하여 개별 서버나 주 또는 보조 데이터베이스 서버에서 생성할 수 있다. 큐는 대상에 고속의 확실한 전달 메커니즘을 제공한다. DB2 큐 복제에는 전통적인 복제의 오버헤드가 없으며 높은 처리량을 제공한다. 또한 큐 구현으로 인한 추가 중복성을 제공한다.

위로

자동 클라이언트 재라우팅

데이터베이스 서버에서 실패가 발생하면 클라이언트 연결이 해제된다. 자동 클라이언트 재라우팅(ACR)을 사용하면 DB2 클라이언트가 자동으로 원래 또는 대체 서버와 다시 연결함으로써 클라이언트의 가동 중지 시간을 최소화한다. ACR에서 대체 서버 정보는 데이터베이스 서버에 지정된 매개 변수다. 대체 서버 정보는 데이터베이스 서버에 처음 연결된 후 서버 쪽 매개 변수에서 정보를 가져와서 클라이언트에 캐시된다. 통신 실패가 감지되면 ACR은 원래 서버와 대체 서버에 대해 번갈아 연결을 시도한다. ACR은 실행 중인 트랜잭션을 다시 실행하지 않는다. 일단 클라이언트가 연결되면 커밋되지 않은 작업이 모두 수행되어야 한다. ACR은 ACR을 사용하여 애플리케이션에서 필요한 다른 작업을 수행할 수 있도록 모든 애플리케이션에 경고 메시지를 생성한다. 그림 8에서는 애플리케이션 서버를 포함하여 여러 클라이언트에서 할 수 있는 ACR 작업을 보여 준다.

WebSphere 미들웨어와 같은 제품은 ACR을 인식한다. 이로 인해 복잡성을 줄이고 애플리케이션의 가용성을 높인다. ACR에 대한 자세한 내용은 참고자료 절에서 참조할 수 있다.

위로

맺음말

제대로 수행되고 가용성이 높은 DB2 솔루션을 만들기 위한 옵션은 여러 가지가 있다. 이 글에서 다룬 내용은 자신의 환경에 가장 적합한 솔루션을 선택하기 위한 지침을 제공할 것이다.

참고자료

• DB2 for z/OS: Data Sharing in a Nutshell 레드북: 공유 가용성 시스템에 대한 자세한 내용을 참조할 수 있다.
  
  
• xkoto 페이지: 여러 복사본 가용성과 데이터 가시화에 대한 자세한 내용을 학습할 수 있다.
  
  
• Building a high availability database environment using WebSphere middleware 기사: WebSphere 애플리케이션 서버에서 DB2 HA 재해 복구를 사용하는 방법을 학습할 수 있다.
  
  
• IBM DB2 9.5 Information Center: 자동 클라이언트 재라우팅 설명과 설정에 대해 자세한 내용을 학습할 수 있다.
  
  
• developerWorks Information Management 존: 정보 관리에 대해 기술 문서 찾기, 사용 방법에 대한 문서, 교육, 다운로드, 제품 정보 등을 학습할 수 있다.
  
  
• developerWorks 기술 행사와 웹 캐스트: 정보를 최신 상태로 유지할 수 있다.
  
  

• IBM 시험판 소프트웨어를 사용하여 다음 개발 프로젝트를 구축한다. 이 소프트웨어는 developerWorks에서 직접 다운로드할 수 있다.
  
  

• developerWorks 블로그에 참여하고 developerWorks 커뮤니티에서 활동할 수 있다.

필자소개

		Monty Wright는 10년간 DB2 제품을 지원해 왔다. 그는 DB2 분산 주제에 대한 여러 기사를 발표했다. IBM Techworks 팀의 일원으로서 여러 고객과의 계약과 벤치마크에 참여했다. 전문 영역은 XML 통합, 데이터베이스 압축, 파티셔닝, 고가용성이다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로