이 절은 다음 내용으로 구성되어 있습니다.
J2EE 응용 프로그램의 세션 지속성에 대한 필요성은 이전에 세션 지속성에서 설명했습니다. Application Server는 가용성이 높은 세션 저장소로 HADB(고가용성 데이터베이스)를 사용합니다. HADB는 Application Server Enterprise Edition에 포함되어 있지만 별도의 호스트에 배포하여 실행할 수 있습니다. HADB는 HTTP 세션 및 Stateful Session Bean 데이터를 위한 가용성이 높은 데이터 저장소를 제공합니다.
이러한 분리된 구조의 이점은 다음과 같습니다.
고가용성 클러스터의 서버 인스턴스는 느슨하게 결합되고 고성능 J2EE 컨테이너 역할을 합니다.
서버 인스턴스의 중지 및 시작이 다른 서버 또는 이러한 서버의 가용성에 영향을 주지 않습니다.
HADB를 다른 저비용 시스템 집합에서 실행할 수 있습니다(예: 단일 또는 이중 프로세서 사용). 여러 클러스터가 이러한 시스템을 공유할 수 있습니다. 배포 요구 사항에 따라 Application Server와 동일한 시스템(공존)이나 다른 시스템(개별 계층)에서 HADB를 실행할 수 있습니다. 두 가지 옵션에 대한 자세한 내용은 공존 토폴로지를 참조하십시오.
상태 관리 요구 사항이 변경되면 기존 클러스터나 클러스터의 응용 프로그램에 영향을 주지 않고 HADB 시스템에 자원을 추가할 수 있습니다.
HADB는 Application Server용으로 최적화된 데이터베이스로서, 응용 프로그램에서 일반 데이터베이스로 사용하도록 개발되지 않았습니다.
HADB 하드웨어 및 네트워크 시스템 요구 사항을 보려면 Sun Java System Application Server 9.1 릴리스 노트의 하드웨어 및 소프트웨어 요구 사항을 참조하십시오. HADB에 필요한 추가 시스템 구성 단계를 보려면 Sun Java System Application Server 9.1 고가용성 관리 설명서의 2 장, 고가용성 데이터베이스 설치 및 설정을 참조하십시오.
HADB 호스트에 대한 시스템 요구 사항은 다음과 같습니다.
HADB 노드당 CPU 1개 이상
노드당 메모리 512MB 이상
네트워크 구성 요구 사항을 보려면 Sun Java System Application Server 9.1 고가용성 관리 설명서의 2 장, 고가용성 데이터베이스 설치 및 설정을 참조하십시오. 고가용성을 위한 추가 요구 사항을 보려면 이중 오류 완화를 참조하십시오.
HADB는 노드 쌍으로 구성된 분산 시스템입니다. 노드는 두 개의 DRU(Data Redundancy Units)로 구분되는데, DRU(Data Redundancy Units)의 설명처럼 각 DRU에는 각 노드 쌍의 한 노드가 포함됩니다.
각 노드를 구성하는 요소는 다음과 같습니다.
트랜잭션 상태 복제를 위한 프로세스 모음
프로세스 간 통신에 사용되는 전용 공유 메모리 영역
보조 저장 장치(디스크) 1개 이상
한 개의 HADB 노드 세트는 하나 이상의 세션 데이터베이스를 호스팅할 수 있습니다. 세션 데이터베이스는 각각 다른 Application Server 클러스터와 연결됩니다. 클러스터를 삭제하면 연결된 세션 데이터베이스도 삭제됩니다.
HADB 하드웨어 요구 사항을 보려면 Sun Java System Application Server 9.1 릴리스 노트의 하드웨어 및 소프트웨어 요구 사항을 참조하십시오.
HADB 노드에는 두 가지 유형이 있습니다.
처음에는 데이터를 포함하지 않지만 활성 노드가 사용할 수 없는 상태가 되었을 때 활성 노드로 작동하는 예비 노드예비 노드는 선택 사항이지만 고가용성을 향상시키려는 경우 유용합니다.
각 노드에는 한 개의 부모 프로세스와 여러 개의 자식 프로세스가 있습니다. NSUP(노드 수퍼바이저)라고 하는 부모 프로세스는 관리 에이전트에 의해 시작되며, 자식 프로세스를 만들어 실행 상태를 유지하는 작업을 수행합니다.
자식 프로세스는 다음과 같습니다.
분산 노드에서 트랜잭션를 조정하고 데이터 저장소를 관리하는 트랜잭션 서버 프로세스(TRANS)
정렬 및 결합과 같은 복합 관계 대수 쿼리를 조정 및 실행하는 관계 대수 서버 프로세스(RELALG)
SQL 사전 캐시를 유지하는 SQL 공유 메모리 서버 프로세스(SQLSHM)
클라이언트 쿼리를 수신하여 로컬 HADB 명령으로 컴파일한 후 TRANS로 전송하고, 결과를 수신하여 클라이언트로 전달하는 SQL 서버 프로세스(SQLC). 각 노드에는 클라이언트 연결별로 주 SQL 서버 한 대와 하위 서버 한 대가 있습니다.
관리 에이전트가 hadbm 관리 클라이언트에서 지시한 관리 명령을 실행하기 위해 사용하는 노드 관리자 서버 프로세스(NOMAN)
앞에서 설명한 대로 HADB 인스턴스에는 한 쌍의 DRU가 포함되어 있습니다. 각 DRU는 쌍을 이루는 다른 DRU와 동일한 수의 활성 노드와 예비 노드를 갖습니다. 한 DRU의 각 활성 노드에는 다른 DRU의 미러 노드가 있습니다. 각 DRU에는 미러링으로 인해 전체 데이터베이스의 복사본이 포함되어 있습니다.
다음 그림은 활성 노드 4개와 예비 노드 두 개로 구성된 6개의 노드가 있는 HADB 구조 예를 보여줍니다. 노드 0과 노드 1은 하나의 미러 쌍이고 노드 2와 노드 3도 미러 쌍입니다. 이 예에서 각 호스트에는 하나의 노드가 있습니다. 일반적으로, 시스템 자원이 충분할 경우 호스트에 둘 이상의 노드가 있을 수 있습니다( 시스템 요구 사항 참조).
각 DRU에 한 시스템씩 HADB 노드를 쌍으로 호스팅하는 시스템을 추가해야 합니다.
HADB는 데이터와 서비스를 복제하여 고가용성을 달성합니다. 미러 노드의 데이터 복제본은 기본 복제본과 상시 대기 복제본으로 지정됩니다. 기본 복제본은 삽입, 삭제, 업데이트 및 읽기와 같은 작업을 수행합니다. 상시 대기 복제본은 기본 복제본 작업의 로그 레코드를 수신하여 트랜잭션 수명 내에서 재실행합니다. 읽기 작업은 기본 노드에 의해서만 수행되므로 기록되지 않습니다. 각 노드는 기본 복제본과 상시 대기 복제본을 모두 포함하고 두 역할을 모두 수행합니다. 데이터베이스는 단편화되어 DRU의 활성 노드에 분산됩니다. 미러 쌍의 각 노드는 동일한 데이터 단편 집합을 포함합니다. 미러 노드의 데이터 중복화를 복제라고 합니다. 복제를 사용하면 HADB에서 고가용성을 제공할 수 있습니다. 노드에 오류가 발생하면 미러 노드가 몇 초 내로 거의 즉시 인계를 받습니다. 복제는 가용성을 확보하고 데이터나 서비스 손실 없이 노드 오류 또는 DRU 오류를 마스크합니다.
오류 발생 노드의 기능을 인계 받은 미러 노드는 자체 작업과 함께 오류 발생 노드의 작업까지 이중 작업을 수행해야 합니다. 미러 노드의 자원이 부족한 경우 오버로드로 인해 성능이 저하되고 오류 가능성이 높아집니다. 노드에 오류가 발생하면 HADB는 노드를 다시 시작하려고 시도합니다. 하드웨어 장애 등으로 인해 오류 발생 노드가 다시 시작되지 않으면 시스템은 계속 작동하지만 가용성이 감소합니다.
HADB는 노드 하나, 전체 DRU 또는 여러 노드의 오류를 허용하지만 노드와 해당 미러에 모두 오류가 발생하는 "이중 오류"는 허용하지 않습니다. 이중 오류 가능성을 줄이는 방법에 대한 자세한 내용은 이중 오류 완화를 참조하십시오.
노드에 오류가 발생하면 해당 미러 노드가 작업을 인계 받습니다. 오류 노드에 예비 노드가 없으면 이 때 오류 노드에 미러가 없습니다. 예비 노드는 오류 발생 노드의 미러를 자동으로 복제합니다. 예비 노드가 있으면 시스템이 미러 노드 없이 작동하는 시간이 감소합니다.
예비 노드는 일반적으로 데이터를 포함하지 않지만 DRU의 활성 노드에 오류가 있는지 지속적으로 모니터합니다. 한 노드에 오류가 발생하고 지정된 시간 초과 기간 내에 복구되지 않으면 예비 노드가 미러 노드에서 데이터를 복사하여 동기화합니다. 이 작업에 소요되는 시간은 복사되는 데이터 양과 시스템 및 네트워크 용량에 따라 달라집니다. 동기화한 후 예비 노드가 수동 개입 없이 미러 노드를 자동으로 대체하므로 미러 노드가 오버로드에서 해제되어 미러의 로드 균형이 조정됩니다. 이 작업은 페일백 또는 자체 복구라고도 합니다.
하드웨어를 바꾸거나 소프트웨어를 업그레이드하여 오류 발생 호스트가 복구 및 다시 시작되면 원래 예비 노드가 현재 활성 상태이므로 호스트에서 실행 중인 노드가 예비 노드로 시스템에 참가합니다.
예비 노드가 필수 항목은 아니지만 이를 사용하여 시스템에 오류가 발생한 경우에도 시스템의 전체 서비스 수준을 유지할 수 있습니다. 또한 예비 노드를 사용하면 활성 노드를 호스팅하는 시스템에서 계획된 유지 보수를 손쉽게 수행할 수 있습니다. 시스템 중 하나에 오류가 발생할 경우 HADB 시스템이 성능과 가용성에 악영향을 주지 않고 계속 작동하도록 DRU에 예비 시스템 역할을 수행할 시스템을 각각 하나씩 할당합니다.
일반적으로 사용할 수 없게 되는 시스템을 대체할 만큼 Application Server 인스턴스 및 HADB 노드가 충분한 예비 시스템을 사용합니다.
다음 예는 HADB 배포에서 예비 노드의 사용을 보여줍니다. 가능한 두 가지 배포 토폴로지로 HADB 및 Application Server가 동일한 호스트에 상주하는 공존 토폴로지와 각각 다른 호스트에 상주하는 개별 계층 토폴로지가 있습니다. 배포 토폴로지에 대한 자세한 내용은 3 장, 토폴로지 선택을 참조하십시오.
예비 노드 구성 예로서 각 서버에 Application Server 인스턴스 하나와 HADB 데이터 노드 둘이 있는 4대의 Sun FireTM V480 서버로 구성된 공존 토폴로지가 있다고 가정합니다.
예비 노드로 두 대의 서버를 추가로 할당합니다(DRU당 시스템 한 대). 각 예비 시스템은 Application Server 인스턴스 하나와 예비 HADB 노드 둘을 실행합니다.
HADB 계층에 서버당 두 개의 HADB 데이터 노드를 실행하는 두 대의 Sun FireTM 280R 서버가 있는 개별 계층 토폴로지가 있다고 가정합니다. 이 시스템에서 시스템 한 대가 사용할 수 없게 된 경우에도 성능을 유지하려면 Application Server 인스턴스 계층과 HADB 계층에 사용할 예비 시스템을 각각 하나씩 구성합니다.
Application Server 인스턴스 계층용 예비 시스템에는 Application Server 인스턴스 계층의 다른 시스템과 동일한 수의 인스턴스가 있어야 합니다. 마찬가지로 HADB 계층용 예비 시스템에도 HADB 계층의 다른 시스템과 동일한 수의 HADB 노드가 있어야 합니다.
HADB의 기본 제공 데이터 복제를 사용하여 단일 노드 또는 전체 DRU의 오류를 허용하도록 할 수 있습니다. 기본적으로 HADB는 미러 노드 쌍이나 양쪽 DRU에 모두 오류가 발생하는 이중 오류를 허용하지 않습니다. 이 경우 HADB를 사용할 수 없게 됩니다.
이전 절의 설명대로 예비 노드를 사용하고 다음 단계를 수행하면 이중 오류 발생 가능성을 최소화할 수 있습니다.
독립 전원 공급 장치 제공: 내결함성을 최적화하려면 하나의 DRU를 지원하는 서버에 무정전 전원 공급 장치를 통한 독립 전원, 처리 장치 및 저장소가 있어야 합니다. 한 쪽 DRU에서 전원 오류가 발생할 경우 전원이 회복될 때까지 다른 DRU의 노드에서 요청이 처리됩니다.
이중 상호 연결 제공: 단일 네트워크 오류를 허용하려면 DRU 간에 라인과 스위치를 복제합니다.
이 단계는 선택 사항이지만 HADB 인스턴스의 전반적인 가용성을 높여줍니다.
HADB 관리 시스템은 기본 제공 보안 기능이 포함되어 있으며 다중 플랫폼 관리를 용이하게 합니다. 아래의 그림에서 보여주는 것처럼 HADB 관리 구조는 다음 구성 요소로 구성됩니다.
그림과 같이 HADB 서비스를 실행하는 모든 시스템에서는 HADB 관리 에이전트가 실행됩니다. 각 시스템은 대개 하나 이상의 HADB 노드를 호스팅합니다. HADB 관리 도메인에는 Application Server 도메인처럼 여러 시스템이 포함되어 있습니다. 데이터베이스가 내결함성을 갖도록 구성하려면 도메인에 두 대 이상의 시스템이 필요하고 일반적으로 DRU 쌍을 형성할 수 있도록 시스템이 짝수로 존재해야 합니다. 따라서 도메인에 많은 관리 에이전트가 포함됩니다.
그림과 같이 도메인은 하나 이상의 데이터베이스 인스턴스를 포함할 수 있습니다. 시스템 한 대에는 하나 이상의 데이터베이스 인스턴스에 속한 하나 이상의 노드가 포함될 수 있습니다.
HADB 관리 클라이언트는 HADB 도메인과 해당 데이터베이스 인스턴스를 관리하기 위한 명령줄 유틸리티 hadbm입니다. 연결된 Application Server 클러스터가 중지된 경우에도 HADB 서비스는 계속 실행될 수 있지만 삭제하려는 경우에는 조심스럽게 종료해야 합니다. hadbm 사용에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 3 장, 고가용성 데이터베이스 관리를 참조하십시오.
asadmin 명령줄 유틸리티를 사용하여 가용성이 높은 클러스터와 연결된 HADB 인스턴스를 만들거나 삭제할 수 있습니다. 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 9 장, 고가용성 세션 지속성 및 페일오버 구성을 참조하십시오.
관리 에이전트는 호스트의 자원에 액세스할 수 있는 ma라는 서버 프로세스로서, 장치를 만들거나 데이터베이스 프로세스를 시작하는 등의 작업을 수행할 수 있습니다. 관리 에이전트는 데이터베이스 인스턴스 시작 또는 중지와 같은 관리 클라이언트 명령을 조정 및 수행합니다.
관리 클라이언트는 에이전트의 주소와 포트 번호를 지정하여 관리 에이전트에 연결합니다. 연결된 후 관리 클라이언트는 관리 에이전트를 통해 HADB에 명령을 보내고 에이전트는 요청을 수신하여 실행합니다. 따라서 관리 에이전트는 hadbm 관리 명령을 호스트에 지시하기 전에 해당 호스트에서 실행 중이어야 합니다. 관리 에이전트는 자동으로 시작되는 시스템 서비스로 구성할 수 있습니다.
관리 에이전트 프로세스는 HADB 노드 수퍼바이저 프로세스가 실패한 경우 프로세스를 다시 시작하여 HADB의 가용성을 보장합니다. 따라서 배포 시 HADB의 전체적인 가용성을 유지하려면 ma 프로세스의 가용성을 보장해야 합니다. 다시 시작한 후 관리 에이전트는 도메인의 다른 에이전트에서 도메인 및 데이터베이스 구성 데이터를 복구합니다.
호스트 운영 체제(OS)를 사용하여 관리 에이전트의 가용성을 보장합니다. Solaris나 Linux의 경우 init.d를 사용하여 프로세스 오류와 운영 체제 재부트 이후 ma 프로세스의 가용성을 보장할 수 있습니다. Windows의 경우 관리 에이전트가 Windows 서비스로 실행됩니다. 따라서 에이전트에 오류가 발생하거나 OS가 재부트될 경우 OS에서 관리 에이전트를 다시 시작합니다.
HADB 관리 도메인은 각기 동일한 포트 번호에서 실행되는 관리 에이전트가 있는 호스트의 집합입니다. 도메인의 호스트는 하나 이상의 HADB 데이터베이스 인스턴스를 포함할 수 있습니다. 관리 도메인은 에이전트가 사용하는 공통 포트 번호 및 도메인을 만들거나 도메인에 에이전트를 추가할 때 생성되는 도메인 키라는 식별자로 정의됩니다. 도메인 키는 도메인의 고유 식별자로서 관리 에이전트가 멀티캐스트를 사용하여 통신하기 때문에 중요한 역할을 합니다. Application Server 도메인과 일치하는 HADB 관리 도메인을 설정할 수 있습니다.
한 도메인에 데이터베이스 인스턴스가 여러 개 있으면 여러 개발자 그룹에서 각각 전용 데이터베이스 인스턴스를 사용할 수 있기 때문에 개발 환경에서 유용할 수 있으며 프로덕션 환경에서도 경우에 따라 유용할 수 있습니다.
도메인에 속한 모든 에이전트는 해당 관리 작업을 조정합니다. hadbm 명령을 통해 데이터베이스 구성을 변경하면 모든 에이전트가 이에 따라 구성을 변경합니다. 노드의 호스트에서 관리 에이전트가 실행되고 있지 않으면 해당 노드를 중지하거나 다시 시작할 수 없습니다. 그러나 일부 에이전트를 사용할 수 없는 경우에도 HADB 상태 또는 구성 변수 값을 읽는 hadbm 명령을 실행할 수 있습니다.
다음 관리 클라이언트 명령을 사용하여 관리 도메인 작업을 수행합니다.
hadbm createdomain: 지정된 호스트를 사용하여 관리 도메인을 만듭니다.
hadbm extenddomain: 호스트를 기존 관리 도메인에 추가합니다.
hadbm deletedomain: 관리 도메인을 제거합니다.
hadbm reducedomain: 관리 도메인에서 호스트를 제거합니다.
hadbm listdomain: 관리 도메인에 정의된 모든 호스트를 나열합니다.
관리 에이전트는 데이터베이스 구성을 저장소에 저장합니다. 저장소는 모든 관리 에이전트에서 복제되기 때문에 내결함성이 우수합니다. 서버에서 구성을 유지하면 관리 클라이언트가 설치된 모든 컴퓨터에서 관리 작업을 수행할 수 있습니다.
저장소 내용을 변경하려면 도메인에 속한 대부분의 관리 에이전트가 실행 중이어야 합니다. 따라서 도메인에 M개의 에이전트가 있는 경우 저장소 내용을 변경하려면 에이전트가 M/2+1개(정수로 절사) 이상 실행 중이어야 합니다.
하드웨어 장애 등으로 인해 도메인의 일부 호스트를 사용할 수 없는 상태에서 쿼럼이 없기 때문에 일부 관리 명령을 수행할 수 없는 경우 hadbm disablehost 명령을 사용하여 도메인에서 오류 발생 호스트를 제거합니다.