Sun Java System Application Server 9.1 배포 계획 설명서

3장 토폴로지 선택

1 장, 제품 개념의 설명대로 성능 관련 요소를 예측한 후 Application Server. 토폴로지는 시스템, Application Server 인스턴스 및 HADB 노드의 배열이자 이들 간의 통신 흐름입니다.

두 개의 기본적인 배포 토폴로지가 있습니다. 두 토폴로지에는 모두 공통 빌딩 블록인 클러스터에 포함된 여러 Application Server 인스턴스, 미러된 HADB 노드 집합 및 HADB 예비 노드가 있습니다. 두 토폴로지는 모두 공통 구성 설정 세트가 있어야 제대로 작동할 수 있습니다.

이 장은 다음 내용으로 구성됩니다.

두 토폴로지에 대한 공통 요구 사항
두 토폴로지:
- 공존 토폴로지 - Application Server 인스턴스와 HADB 노드가 동일한 시스템에 있습니다.
- 개별 계층 토폴로지 - Application Server 인스턴스와 HADB 노드가 서로 다른 시스템에 있습니다.
사용할 토폴로지 결정

공통 요구 사항

이 절에서는 두 토폴로지의 공통적인 요구 사항에 대해 설명합니다.

일반 요구 사항

두 토폴로지 모두 다음 일반 요구 사항을 충족해야 합니다.

HADB 노드를 호스팅하는 시스템은 쌍으로 존재해야 합니다. 즉, 시스템 수가 짝수여야 합니다.
각 DRU(Data Redundancy Unit)에는 같은 수의 시스템이 있어야 합니다. 미러된(쌍을 이룬) 노드를 기본 노드와 다른 DRU에 배치하여 HADB 데이터베이스를 만듭니다.
HADB를 호스팅하는 각 시스템에는 모든 영구 정보를 HADB에 저장하기 위해 사용되는 로컬 디스크 저장소가 있어야 합니다.
HADB 노드를 호스팅하는 시스템에서는 동일한 운영 체제를 실행해야 합니다. 구성 및 성능이 동일하거나 거의 비슷한 시스템을 사용하는 것이 좋습니다.
HTTP 및 SFSB 세션 정보를 HADB에 영구 저장하려면 Application Server 인스턴스가 클러스터에 있어야 하고 모든 관련 요구 사항을 충족해야 합니다. 클러스터 구성에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 6 장, Application Server 클러스터 사용을 참조하십시오.
Application Server 인스턴스를 호스팅하는 시스템은 구성 및 성능이 가능한 한 동일해야 합니다. 이는 로드 밸런서 플러그인이 로드 균형 조정에 대한 라운드 로빈 정책을 사용하기 때문이며 여러 클래스의 시스템에서 인스턴스를 호스팅할 경우에는 최적의 방식으로 로드 균형이 조정되지 않습니다.
각 DRU에 대해 별도의 UPS(무정전 전원 공급 장치)를 사용하는 것이 좋습니다.

HADB 노드 및 시스템

각 DRU는 HADB의 전체 데이터 복사본을 포함하므로 다른 DRU를 사용할 수 없게 되는 경우 요청을 계속 처리할 수 있습니다. 그러나 한 DRU의 노드와 다른 DRU에 있는 해당 미러가 동시에 실패하면 일부 데이터가 손실됩니다. 이러한 이유에서 정전이나 디스크 오류와 같은 단일 오류로 두 DRU가 모두 영향을 받지 않도록 시스템을 설정하는 것이 중요합니다.

주 –

각 DRU는 완전히 독립적인 중복 시스템에서 실행되어야 합니다.

HADB 노드와 시스템을 설정할 때 다음 지침을 따릅니다.

용량과 처리량을 늘리려면 DRU당 한 노드씩 노드를 쌍으로 추가합니다.
예비 노드 수가 각 시스템에서 실행되는 노드 수와 같아지도록 각 DRU를 설정합니다. 이는 구성의 각 시스템에서 n개의 데이터 노드를 실행하는 경우 단일 시스템 오류가 발생했을 때 n개 노드가 다운되기 때문입니다.
모든 시스템에서 같은 수의 HADB 노드를 실행하여 가능한 균일하게 로드 균형을 조정합니다.

주의 –

같은 시스템의 서로 다른 DRU에서 노드를 실행하지 마십시오. 같은 시스템의 서로 다른 DRU에서 노드를 실행해야 할 경우에는 시스템에서 단일 오류 지점(디스크, 메모리, CPU, 전원, 운영 체제 충돌 등과 관련된 오류)을 처리할 수 있는지 확인합니다.

로드 밸런서 구성

두 토폴로지 모두 클러스터에 Application Server 인스턴스가 있습니다. 이러한 인스턴스는 세션 정보를 HADB에 영구 저장합니다. 클러스터의 모든 Application Server 인스턴스에 대한 구성 정보를 포함하도록 로드 밸런서를 구성합니다.

클러스터 설정 및 클러스터에 Application Server 인스턴스를 추가하는 방법에 대한 자세한 내용은 Sun Java System Application Server 9.1 고가용성 관리 설명서의 6 장, Application Server 클러스터 사용을 참조하십시오.

공존 토폴로지

공존 토폴로지에서 Application Server 인스턴스와 HADB 노드는 같은 시스템에 있습니다(이하 공존). 이 토폴로지에는 개별 계층 토폴로지보다 필요한 시스템 수가 적습니다. 공존 토폴로지에서는 CPU를 보다 효율적으로 사용합니다. Application Server 인스턴스와 HADB 노드가 한 시스템을 공유하고 시스템 간에 프로세스가 균일하게 분산됩니다.

이 토폴로지에는 최소한 두 개의 시스템이 필요합니다. 처리량을 향상시키려면 시스템을 쌍으로 추가합니다.

주 –

시스템의 처리 능력을 완전히 활용할 수 있으므로 공존 토폴로지는 대규모 SMP(대칭적 다중 처리) 시스템에 적합합니다.

구성 예

다음 그림은 공존 토폴로지 구성의 예를 보여줍니다.

그림 3–1 공존 토폴로지 예

시스템 SYS0은 Application Server 인스턴스 A를, 시스템 SYS1은 Application Server 인스턴스 B를, 시스템 SYS2는 Application Server 인스턴스 C를, 시스템 SYS3은 Application Server 인스턴스 D를 각각 호스팅합니다.

이러한 4개 인스턴스가 정보를 두 개의 DRU에 영구 저장하는 클러스터를 구성합니다.

DRU0은 두 개의 시스템 SYS0 및 SYS2로 구성됩니다. 활성 0 HADB 노드는 시스템 SYS0에 있습니다. 예비 2 HADB 노드는 시스템 SYS2에 있습니다.
DRU1은 두 개의 시스템 SYS1 및 SYS3으로 구성됩니다. 활성 1 HADB 노드는 시스템 SYS1에 있습니다. 예비 3 HADB 노드는 시스템 SYS3에 있습니다.

공존 토폴로지 변형

확장성과 처리량을 향상시키려면 시스템을 추가하여 Application Server 인스턴스와 HADB 노드 수를 증가시킵니다. 예를 들어 각각 하나의 Application Server 인스턴스와 하나의 HADB 노드를 포함하는 두 개의 시스템을 추가할 수 있습니다. 각 DRU에 하나의 노드를 할당하여 HADB 노드를 쌍으로 추가해야 합니다. 공존 토폴로지 변형에서는 이 구성에 대해 설명합니다.

그림 3–2 공존 토폴로지 변형

이 변형에서는 시스템 SYS4 및 SYS5가 구성 예에 설명된 공존 토폴로지에 추가되었습니다.

Application Server 인스턴스는 다음과 같이 호스팅됩니다.

시스템 SYS0이 인스턴스 A를 호스팅합니다.
시스템 SYS1이 인스턴스 B를 호스팅합니다.
시스템 SYS2가 인스턴스 C를 호스팅합니다.
시스템 SYS3이 인스턴스 D를 호스팅합니다.
시스템 SYS4가 인스턴스 E를 호스팅합니다.
시스템 SYS5가 인스턴스 F를 호스팅합니다.

이러한 인스턴스가 정보를 두 개의 DRU에 영구 저장하는 클러스터를 구성합니다.

DRU0은 시스템 SYS0, SYS2 및 SYS4로 구성됩니다. 활성 0 HADB 노드는 시스템 SYS0에 있습니다. 활성 2 HADB 노드는 시스템 SYS2에 있습니다. 예비 4 HADB 노드는 시스템 SYS4에 있습니다.
DRU1은 시스템 SYS1, SYS3 및 SYS5로 구성됩니다. 활성 1 HADB 노드는 시스템 SYS1에 있습니다. 활성 3 HADB 노드는 시스템 SYS3에 있습니다. 예비 5 HADB 노드는 시스템 SYS5에 있습니다.

개별 계층 토폴로지

이 토폴로지에서 Application Server 인스턴스와 HADB 노드는 서로 다른 시스템(이하 개별 계층)에 있습니다.

이 토폴로지에는 공존 토폴로지보다 큰 하드웨어가 필요합니다. 이 토폴로지는 다양한 유형의 시스템이 있는 경우 적합할 수 있습니다. 한 시스템 집합은 Application Server 인스턴스를 호스팅하도록 할당하고 다른 집합은 HADB 노드를 호스팅하도록 할당할 수 있습니다. 예를 들어 Application Server 인스턴스에는 더 강력한 시스템을 사용하고 HADB에는 상대적으로 성능이 낮은 시스템을 사용할 수 있습니다.

구성 예

다음 그림은 개별 계층 토폴로지를 보여줍니다.

그림 3–3 개별 계층 토폴로지 예

이 토폴로지에서 시스템 SYS0은 Application Server 인스턴스 A를 호스팅하고 시스템 SYS1은 Application Server 인스턴스 B를 호스팅합니다. 이러한 두 인스턴스가 두 개의 DRU에 세션 정보를 영구 저장하는 클러스터를 구성합니다.

DRU0은 두 개의 시스템 SYS2 및 SYS4로 구성됩니다. 활성 0 HADB 노드는 시스템 SYS2에 있고 예비 2 HADB 노드는 시스템 SYS4에 있습니다.
DRU1은 두 개의 시스템 SYS3 및 SYS5로 구성됩니다. 활성 1 HADB 노드는 시스템 SYS3에 있고 예비 3 HADB 노드는 시스템 SYS5에 있습니다.

DRU의 모든 노드는 서로 다른 시스템에 있으므로 한 시스템에 오류가 발생해도 DRU의 전체 데이터를 다른 시스템에서 계속 사용할 수 있습니다.

개별 계층 토폴로지 변형

개별 계층 토폴로지의 변형은 구성에 같은 수준의 시스템을 추가하여 Application Server 인스턴스 수를 증가시킵니다. 예를 들어 새 Application Server 인스턴스를 만들어 다른 시스템을 구성 예에 추가합니다. 마찬가지로 HADB 노드를 호스팅하는 시스템을 추가하여 HADB 노드 수를 증가시킵니다. 각 DRU에 한 노드씩 쌍으로 HADB 노드를 추가해야 합니다.

개별 계층 토폴로지 변형에서는 이 구성에 대해 설명합니다.

그림 3–4 개별 계층 토폴로지 변형

이 구성에서 Application Server 인스턴스를 호스팅하는 각 시스템에는 두 개의 인스턴스가 있습니다. 따라서 클러스터에 총 6개의 Application Server 인스턴스가 있습니다.

HADB 노드는 시스템 SYS3, SYS4, SYS5 및 SYS6에 있습니다.

DRU0은 두 개의 시스템으로 구성됩니다.

활성 0 HADB 노드 및 활성 2 HADB 노드를 호스팅하는 SYS3
예비 4 HADB 노드 및 예비 6 HADB 노드가 있는 SYS5

DRU1은 두 개의 시스템으로 구성됩니다.

활성 1 HADB 노드 및 활성 3 HADB 노드를 호스팅하는 SYS4
예비 5 HADB 노드 및 예비 7 HADB 노드를 호스팅하는 SYS6

HADB 노드를 호스팅하는 각 시스템에서는 두 개의 노드를 호스팅합니다. 따라서 총 8개의 HADB 노드인 활성 노드 4개와 예비 노드 4개가 있습니다.

사용할 토폴로지 결정

성능 및 가용성 요구 사항에 가장 잘 맞는 토폴로지(또는 변형)를 결정하려면 토폴로지를 테스트하고 여러 시스템 및 CPU 조합으로 시험합니다.

목표를 달성하는 데 필요한 절충 조건을 결정합니다. 예를 들어 간편한 유지 보수가 중요한 경우에는 개별 계층 토폴로지가 더 적합합니다. 절충 조건은 토폴로지에 공존 토폴로지보다 많은 시스템이 필요하다는 것입니다.

토폴로지 선택에 있어 중요한 요소는 사용 가능한 시스템 유형입니다. 시스템에 대규모 SMP(대칭적 다중 처리) 시스템이 있는 경우에는 이러한 시스템의 처리 능력을 최대한 활용할 수 있기 때문에 공존 토폴로지가 적합합니다. 시스템에 다양한 시스템 유형이 있는 경우에는 Application Server 계층과 HADB 계층에 서로 다른 시스템 집합을 할당할 수 있기 때문에 개별 계층 토폴로지가 더 유리할 수 있습니다. 예를 들어 Application Server 계층에 가장 강력한 시스템을 사용하고 HADB 계층에 상대적으로 성능이 낮은 시스템을 사용할 수 있습니다.

토폴로지 비교

다음은 공존 토폴로지와 개별 계층 토폴로지를 비교한 표입니다. 왼쪽 열에는 토폴로지 이름, 중간 열에는 토폴로지의 장점, 그리고 오른쪽 열에는 토폴로지의 단점이 각각 나열되어 있습니다.

표 3–1 토폴로지 비교


토폴로지	장점	단점
공존 토폴로지	더 적은 시스템 필요. HADB 노드와 Application Server 인스턴스가 같은 계층에 있으므로 각 예비 노드에 Application Server 인스턴스를 만들어 추가 로드를 처리할 수 있습니다. 향상된 CPU 사용률. 하나의 시스템을 공유하는 Application Server 인스턴스와 HADB 노드 사이에 프로세스가 균일하게 분산됩니다. 처리 능력을 완전히 활용하기 때문에 대규모 SMP(대칭적 다중 처리) 시스템에 유용합니다.	유지 보수 복잡성 증가. 예를 들어 유지 보수를 수행하기 위해 HADB 노드를 호스팅하는 시스템을 종료해야 할 경우 해당 시스템의 Application Server 인스턴스도 사용할 수 없게 됩니다.
개별 계층 토폴로지	간편한 유지 보수. 예를 들어 HADB 노드를 중단할 필요 없이 Application Server 인스턴스를 호스팅하는 시스템에 대한 유지 보수를 수행할 수 있습니다. 시스템 유형이 다양할 경우 유리. Application Server 계층과 HADB 계층에 서로 다른 시스템 집합을 할당할 수 있습니다. 예를 들어 Application Server 계층에 더 강력한 시스템을 사용하고 HADB 계층에 상대적으로 성능이 낮은 시스템을 사용할 수 있습니다.	공존 토폴로지보다 많은 시스템 필요. Application Server 인스턴스와 HADB 노드가 각각 개별 계층에 있기 때문에 Application Server 인스턴스가 HADB 예비 노드를 호스팅하는 시스템에 존재할 수 없습니다. CPU 사용률 감소. Application Server 계층과 HADB 계층의 로드가 균일하지 않을 수 있습니다. 이러한 단점은 시스템 수가 적은 경우(4 - 6개) 영향이 더 큽니다.