2. 데이터베이스 클러스터

데이터를 통합할 때, 성능 향상과 가용성을 높이기 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링을 이용한다.

- 파티션 사이의 병렬 처리를 통한 빠른 데이터 검색 및 처리
-성능의 선형적인 증가 효과
-고가용성(특정 파티션에서 장애 발생시에도 서비스가 중단되지 않음)

시스템 구성
- 단일 서버 내의 파티셔닝
-다중 서버 사이의 파티셔닝

리소스 공유 관점
- 공유 디스크(Shared Disk)
- 무공유 디스트(Shared Nothing)


1) 무공유(Shared Nothing) 클러스터
각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 노드 간에 공유하지 않는다.
각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유권을 갖고 있는 인스턴스가 처리한다. 한 노드가 데이터 처리 요청을 받으면, 해당 노드는 처리할 데이터를 갖고 있는 노드에 신호를 보내 데이터 처리를 요청한다.
장점- 노드 확장에 제한이 없다.
단점- 장애 발생시 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성 필요
Oracle RAC(Real Application Cluster)를 제외한 대부분의 데이터베이스 클러스터가 무공유 방식을 사용.

2)공유 디스크(Shared Disk) 클러스터
데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들 과 공유, 각 인스턴스는 모든 데이터에 접근할 수 있다. 데이터를 공유하려면 SAN(Storage Area Network)과 같은 공유 디스크가 반드시 있어야 하며, 모든 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널이 필요하다.
장점- 높은 수준의 폴트톨러런스 제공(클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스가 가능)
단점- 클러스터가 커지면 디스크 영역에서 병목현상 발생 (Oracle RAC가 공유디스크 방식을 이용)

가. Oracle RAC 데이터베이스 서버
_________________________________________________

그림은 일반적인 4노드 RAC 구성모델.
Oracle RAC 데이터베이스 서브는 클러스터의 모든 노드에서 실행되며, 데이터는 공유 스토리지에 저장된다.
클러스터의 모든 노드는 데이터베이스의 모든 테이블에 동등하게 액세스하며, 특정 노드가 데이터를 '소유'하는 개념이 없다. 따라서 데이터를 파티셔닝할 필요가 없지만, 성능 향상을 위해 빈번하게 파티셔닝 된다. 응용 프로그램은 클러스터의 특정 노드가 아니라 RAC  클러스터에 연결하며, RAC는 클러스터의 모든 노드에 로드를 고르게 분산한다.

-가용성
클러스터의 한 노드가 어떤 이유로 장애를 일으키면 Oracle RAC는 나머지 노드에서 계속 실행된다. 장애가 발생한 노드에 연결됐던 모든 응용 프로그램(사용자)은 투명하게 다시 연결되어 클러스터의 나머지 노드에 분산된다.

-확장성
추가 처리 성능이 필요하면 응용 프로그램이나 데이터베이스를 수정할 필요 없이 새 노드를 클러스터에 쉽게 추가할 수 있다. 클러스터의 모든 노드 간에 균형이 유지되도록 로드가 다시 분산된다. Oracle 10g R2 RAC 는 클러스터 내에 최대 100개의 노드를 지원한다.

-비용 절감
RAC는 표준화된 소규모(CPU 4개 미만)저가형 사용 하드웨어의 클러스터에서도 고가의 SMP 시스템만큼 효율적으로 응용 프로그램을 실행함으로써 하드웨어 비용을 절감한다. 예를 들어 4CPU의 16노드 클러스터를 사용하면 동급 성능의 64CPU SMP 시스템에 대해 비용을 크게 절감할 수 있다.
Oracle RAC는 여러 장점을 갖고 있지만 일반적으로 4노드 이상 잘 구성하지 않는다. 도입 비용 때문에 확장성이 중요한 데이터보다는 고가용성을 요구하는 데이터에 많이 사용한다.

나. IBM DB2 ICE(Integrated Cluster Environment)
DB2는 CPU.메모리.디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링을 지원한다. 애플리케이션은 여러 파티션에 분산된 데이터베이스를 하나의 데이터베이스(Single View Database)로 보게되고, 데이터가 어느 파티션에 존재하고 있는지 알 필요가 없다. 따라서 데이터와 사용자가 증가하면 애플리케이션의 수정 없이 기존 시스템에 노드를 추가하고 데이터를 재분배함으로써 시스템의 성능과 용량을 일정하게 유지할 수 있다.
하지만 각 노드로 분산되는 파티셔닝을 어떻게 구성하느냐에 따라 성능의 차이가 많이 발생할 수 있으며 하나의 노드에 장애가 발생할 경우, 해당 노드에서 서비스하는 데이터에 대한 별도의 페일오버(failover)메커니즘이 필요하게 된다. 따라서 DB2를 이용하여 클러스터를 구성할 때에도 가용성을 보장하기 위해 공유 디스크 방식을 이용한다. 공유 디스크에 저장된 데이터 파일에 대해 특정 시점에서는 특정 노드에 의해 서비스 되지만 장애 상항이 발생하게 되면 다른 노드가 해당 데이터에 대한 서비스를 처리하는 방식으로 가용성을 보장한다.

다. 마이크로소프트 SQL Server
연합(Federated) 데이터베이스 형태로 여러 노드로 확장할 수 있는 기증을 제공
연합데이터베이스는 디스크 등을 공유하지 않는 독립된 서버에서 실행되는 서로 다른 데이터베이스들 간의 논리적인 결합이며, 네트워크를 이용하여 연결된다.
데이터는 관련된 서버들로 수평적으로 분할된다. 테이블을 논리적으로 분리해 물리적으로는 분산된 각노드에 생성하고, 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNIO ALL 을 이용해 논리적인 뷰(VIEW)를 구성하는 방식으로 분산된 환경의 데이터에 대한 싱글 뷰를 제공한다.
SQL Server 에서는 이런 뷰를 DVP(Distributed Partitioned View)라고 한다.

DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 시키마(Global schema)정보가 없기 때문에 질의 수행을 의해 모든 노드를 액세스해야 한다는 점.
노의가 많아지거나 노드의 추가/삭제가 발생하는 경우 파티션을 새로 해야 하는 문제
페일오버에 대해서는 별도로 구성.
SQL Server에서도 페일오버 메커니즘을 제공하지만, Active-Activie가 아닌 Active-Standy 방법을 사용

라. MySQL 크러스터
무공유 구조에서 메모리(최근에는 디스크도 제공)기반 데이터베이스의 클러스터링을 지원
특정한 하드웨어 및 소프트웨어를 요구하지 않고 병렬 서버구조로 확장이 가능.
-관리 노드(Management Node):클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여한다.
-데이터 노드(NDB Node):클러스터의 데이터를 저장하는 노드
-MySQL 노드: 클러스터 데이터에 접근을 지원하는 노드

MySQL 클러스터는 데이터의 가용성을 높이기 휘해 데이터를 다른 노드에 복제시키며, 특정 노드에 장애가 발생하더라도 지속적인 데이터 서비스가 가능하다. 장애가 났던 노드가 복구되어 클러스터에 투입된경우에도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동으로 수행된다. 데이터는 동기화 방식으로 복제되며, 이런 작업을 위해 일반적으로 데이터 노드 간에는 별도의 네트워크를 구성한다.
MySQL의 최근 버전(5.1.6 이상)에서는 디스크 기반의 클러스터링을 제공한다. 디스크 기반 클러스터링에서는 인덱스가 생성된 칼럼은 기존과 동일하게 메모리에 유지되지만, 인텍스를 생성하지 않은 칼럼은 디스크에 저장된다. 따라서 디스크에 저장된 데이터는 모두 인덱스가 없는 데이터다. 이 경우 디스크에 저장된 데이터와 JOIN 연산을 수행할 경우 성능이 좋지 않기 때문에 애플리케이션 개발 시 주의해야 한다. 또한 디스크 기반이라 하더라도인텍스로 구성된 컬럼은 메모리에 있기 때문에 데이터의 크기와 메모리 크기를 고려하여 인덱스 생성과 클러스터의 참여하는 장비의 메모리르 산정해야 한다.

제한사항
- 파티셔닝은 LINEAR KEY 파티셔닝만 사용 가능하다.
- 클러스터에 참여하는 노드(SQL 노드, 데이터노드, 메니저를 포함)수는 255로 제한한다. 데이터 노드는 최대 48개까지만 가능하다.
- 트랜잭션 수행 중에 롤백을 지원하지 않으므로 작업 수행 중에 문제가 발생하였다면, 전체 트랜잭션 이전으로 롤백해야 한다.
- 하나의 트랜잭션에 많은 데이터를 처리하는 경우 메모리 부족 문제가 발생할 수 있으며, 여러 개의 트랜잭션으로 분리해 처리하는 것이 좋다(예:Delete from .. LIMIT ...).
- 칼럼명 길이는 31자, 데이터베이스와 테이블명 길이는 122자까지로 제한된다. 데이터베이스 테이블, 시스템 테이블, 블롭(BLOB) 인덱스를 포함한 메타데이터(속성정보)는 2만 320개까지만 가능하다.
- 클러스터에서 생성할 수 있는 데이블 수는 최대 2만 320개다. 한 로우(row)의 최대 크기는 8KB다(BLOB를 포함하지 않는 경우), 테이블의 키는 32개가 최대다.
- 모든 클러스터의 기종은 동일해야 한다. 기종에 따른 비트 저장방식이 다르면 문제가 발생할 수 있다.
- 운영 중에 노드를 추가/삭제할 수 없다.
- 디스크 기반 클러스터인 경우 tablespace의 개수는 2^32(4294967296), tablespace당 데이터 파일의 개수는 2^16(65535), 데이터 파일의 크기는 32GB까지 가능하다.