대규모 IBM® WebSphere® Application Server
클러스터는
클러스터 중심으로 요청을 전달하는 로드 밸런서와 함께
프론트 엔드 HTTP 서버 및 프록시 서버로 구성됩니다.
제한사항: 애플리케이션 서버의 클러스터를 작성 및 사용하려면
IBM WebSphere Application Server
ND(Network
Deployment)(IBM Rational® Asset Manager에서
번들로 제공되지 않음)가 있어야 합니다.
수평 및 수직으로 WebSphere Application Server를
확장할 수 있습니다. 전용 데이터베이스 서버 및 파일 서버를
사용합니다. WebSphere Application Server의 확장 범위와
사용할 수 있는 서버 수는 자산 수 및 서버 요청의 유형과 규모에 따라
달라집니다.
- IBM HTTP Server
- 첫 번째 티어는 HTTP 서버로,
웹 클라이언트의 요청을 처리하고 애플리케이션 서버의
정적 컨텐츠 지원을 완화시킵니다. 여기에서는
IBM Rational Asset Manager
애플리케이션, Rational Asset Manager
도움말 애플리케이션 및 Rational Asset Manager Asset
Based Development 애플리케이션과 같은 부수적인 애플리케이션을 포괄하는
논리 URL을 제공합니다. 대규모 구성에서 캐시 서버는 HTTP 서버 전면에 배치됩니다.
- 로드 밸런서
- 로드 밸런서는 여러 시스템에서 로드를 분배합니다. HTTP 서버가
둘 이상인 경우 로드 밸런서를 사용해야 합니다.
보통 크기의 배치에서는 소프트웨어 기반 로드 밸런서(예:
에지 컴포넌트)를 사용합니다. 더 많은 동시 사용자를
지원하는 더 큰 배치에서는 하드웨어 기반 로드 밸런서를 사용합니다.
- 캐시 프록시
- 캐싱 전달 프록시 시스템은 캐시에 클라이언트에 대한 애플리케이션 데이터를
저장하고 다른 서버 시스템에서 로드를 완화시킵니다. Rational Asset Manager
서버가 보통 수준의 동시 사용자를 지원하는 경우 하나의 전달 프록시 시스템만 필요합니다. Rational Asset Manager 서버가
많은 동시 사용자를 지원하는 경우 여러 프록시 시스템이 필요할 수도 있습니다.
- 애플리케이션 서버
- Rational Asset Manager EAR
파일은 두 개의 WAR 파일(저장소와 웹 애플리케이션 파일 및 웹 서비스 파일)로
구성됩니다. Rational Asset Manager EAR
파일을 클러스터의 모든
WebSphere Application Server
인스턴스에 배치합니다. 또한
Rational Asset Manager는
도움말 및 IBM
RUP(Rational Unified Process)
WAR 파일도 포함합니다. 이 WAR 파일은 배치하지 않아도
됩니다. 도움말 및 RUP
지원 기능에 대해 고가용성이 필요하지 않는 경우 단일
WebSphere Application Server
인스턴스 또는 외부 WebSphere Application Server
컨테이너에 배치합니다.
- Rational Asset Manager 애플리케이션
- Rational Asset Manager
저장소는 데이터 검색, 아티팩트 찾아보기 및 자산 다운로드를 효율적으로
수행하는 방식으로 데이터를 저장하도록
데이터 검색에 맞게 정규화되었습니다. 이를 수행하기 위해 모든 Rational Asset Manager
서버 인스턴스는 자산에 대한 로컬 색인 및 아티팩트에 대한 로컬 색인을
빌드합니다.
이를 통해 검색 성능을 최적화하고 데이터베이스 로드를 완화시키고
클러스터된 환경에서 확장성을 강화합니다. 로컬 색인 디렉토리는
노드에서 공유되는 색인보다 성능이 더 나을 수 있습니다.
- 데이터베이스 서버
- 데이터베이스 하드웨어 선택 시 가장 중요한 고려사항은
시스템에서 사용하는 RAID 스키마와 시스템에 있는 디스크 수입니다. RAID
어레이는 모든 프로세서에서 적어도 6 - 10개의 드라이브를 포함해야
합니다. 메모리가 중요하지만 1,000명의 사용자와 50,000개 자산에 대해
4GB 및 8GB 메모리를 포함하는 데이터베이스 서버 구성 사이에는 큰 차이가 없습니다.
- 데이터베이스 디스크 공간 요구사항은 자산 수,
각 자산에 대한 아티팩트 수, 팀 공간 수, 역할 수, 검토 수, 자산 유형 수,
사용자 수, 서버에서 트랜잭션 크기(사용자 메트릭) 및 포럼 논의 수량과 같은
많은 요인에 의해 달라집니다.
- 파일 서버
- 자산은 WebSphere Application Server
인스턴스에서 공유되어야 합니다.
동시에 액세스되는 파일 시스템을 사용합니다. Rational Asset Manager에서는
업로드, 다운로드, 아티팩트 색인 작성, 자산 Manifest 업데이트가 필요한
Rational Asset Manager
모델의 대규모 변경 중에만 이 파일에 액세스합니다.
클러스터링 토폴로지
클러스터링은
하나의 시스템처럼 참조할 수 있는 논리 엔티티로 시스템 그룹을 결합하는
작업입니다. 이 절에서는 다양한 클러스터 구성과 각각의
기본적인 장점과 단점을 설명합니다.
- 수평 클러스터링
- 수평 클러스터링(용량 확장)은
클러스터 풀의 용량 또는 성능을 향상시키기 위한 실제 시스템 추가를
말합니다. 일반적으로 수평적 확장은 유지보수 비용이 늘어난 대신,
클러스터된 애플리케이션의 가용성을 향상시킵니다.
수평 클러스터링은 클러스터된 애플리케이션에 용량 및 늘어난 처리량을
추가할 수 있습니다. 대부분의 인스턴스에서는 이 유형의 클러스터링을 사용합니다.
- 수직 클러스터링
- 수직 클러스터링(규모 확장)은 동일한 시스템에
WebSphere Application Server
인스턴스 추가를 말합니다. 수직적 확장은
대형 SMP 서버에서 사용하지 않는 자원을 이용하려는 경우에
유용합니다. 수직 클러스터링을 사용하여
사용 가능한 처리 능력 모두를 함께 사용할 수 있는
다중 JVM 프로세스를 작성할 수 있습니다.
- 하이브리드 수평 및 수직 클러스터링
- 하이브리드 클러스터링은 수평과 수직 클러스터링이 결합된
형태입니다. 이 구성에서 별도의 하드웨어 구성이
동일한 클러스터의 멤버입니다. 더 많은 용량을 보유한 더 큰 시스템은
여러 WebSphere Application Server
인스턴스를 포함할 수 있습니다. 더 작은 시스템은
수평으로 클러스터될 수 있으며 하나의
WebSphere Application Server
인스턴스만 포함할 수 있습니다.
- 수직 클러스터링을 사용하는 경우 신중해야 합니다. 환경 및
애플리케이션에 올바른 형태를 결정하는 유일한 방법은
처리량 및 성능에 대해 애플리케이션 서버의 단일 인스턴스를 조정하고
이를 클러스터에 추가하고 추가 클러스터 멤버를 계속 추가하는
것입니다. 각 멤버가 클러스터에 추가될 때
성능과 처리량을 테스트합니다. 수직적 확장 토폴로지를 구성하는 경우
항상 메모리 사용량을 모니터합니다. 시스템에서 사용 가능한 실제 메모리 크기 또는
주소 지정 가능한 사용자 공간의 크기를 초과하지 마십시오.
확장성
확장성은 사이트를 얼마나 쉽게 확장할 수
있는가를 나타냅니다. 증가하는 로드를 지원하려면
지정된
Rational Asset Manager
설치에서 사용자, 자산 및 커뮤니티 수를 확장할 수 있어야 합니다. 증가하는
로드의 원인은 다양합니다(예: 추가 팀 또는 부서를
Rational Asset Manager
사용자 세트에 추가하거나, 히스토리 자산의 대규모 세트를
Rational Asset Manager에 가져오기).
확장성은 아키텍처 디자인을 유도하는 설계상의 고려사항입니다.
시스템에 하드웨어를 더 추가하여 확장성을 향상시킬 수 있지만,
성능과 처리량은 향상되지 않을 수 있습니다.
보통 용량 확장(수평
클러스터링)과 규모 확장(수직 클러스터링) 사이의 선택은
사용자 환경의 특징, 비용 및 선호도에 따라 결정됩니다. 그러나
애플리케이션 유연성 문제로 환경 설정이 변경될 수 있습니다.
- 규모 확장은 주소 지정 가능한 사용자 공간 메모리가 크고 프로세스가 많은,
소수의 시스템에서 수직적 확장을 구현합니다.
이 경우 환경은 더 적은 수의 큰 시스템으로 구성되므로 이는
중요한 SPOF(Single Points of Failure)를 나타낼 수 있습니다.
- 용량 확장은 더 작은 시스템을 더 많이 사용합니다. 이 시나리오에서
하나의 작은 서버에서 장애가 발생할 경우 전체 애플리케이션 가동이
중단되는 일은 거의 발생하지 않습니다. 그러나 용량 확장은 더 많은 유지보수 요구를
생성합니다.
가용성
또한 결함 허용 또는 유연성이라고도 하는
가용성은 컴포넌트 및 시스템에서 장애가 발생했지만, 운영의 지속성을 제공하는
기능을 말합니다.
수평 대 수직 확장과 백업 로드 밸런서(즉, 디스패처) 사용과 같은
설계상의 의사결정은 Rational Asset Manager
애플리케이션의 가용성에 영향을 줄 수 있습니다.
Rational Asset Manager
환경을 구성하는 모든 공유 자원, 네트워크 및 디스크 저장 공간 시스템의
가용성을 고려합니다.
결함 허용 설계에서 애플리케이션 또는 서버 장애가 발생한 경우
클러스터의 다른 멤버가 클라이언트를 계속 지원할 수 있습니다.
장애 복구에는
두 가지 카테고리가 있습니다(서버 장애 복구 및 세션 장애 복구).
서버 장애 복구가 발생하면 장애가 발생한 클러스터 멤버의 세션이 유실되지만(사용자가
다시 로그인해야 함), 서비스는 계속 클라이언트에서 사용 가능합니다. 세션
장애 복구의 경우 클러스터 멤버에서 장애가 발생하지 않은 것처럼
기존 세션은 클러스터의 다른 멤버에 의해 재개됩니다(마지막 트랜잭션은 유실될 수 있음).
서버 장애 복구를 지원하도록 중복 인프라가 구성된 경우
Rational Asset Manager에서 이를 지원합니다.