클러스터 및 워크로드 관리
클러스터는 함께 관리되며 워크로드 관리에 참여하는 서버의 세트입니다. 클러스터는 엔터프라이즈 애플리케이션을 단일 애플리케이션 서버에서 확보할 수 있는 처리량 이상으로 확장할 때 사용할 수 있습니다. 클러스터를 사용하면 또한 장애 발생 시 요청이 실행 서버로 자동 라우트되므로 엔터프라이즈 애플리케이션의 가용성을 높일 수 있습니다. 클러스터의 멤버인 서버는 다른 호스트 시스템에 있을 수 있습니다. 반면, 동일한 노드의 일부인 서버는 동일한 호스트 시스템에 있어야 합니다. 셀은 클러스터(단일 클러스터 또는 복수 클러스터)를 포함할 수 있습니다.
클러스터에 속한 서버는 해당 클러스터 세트의 멤버이며, 클러스터에 배치된 동일 애플리케이션 컴포넌트가 모두 있어야 합니다. 서버에서 실행하도록 구성된 애플리케이션 이외에, 클러스터 멤버는 다른 구성 데이터를 공유할 필요가 없습니다. 한 클러스터 멤버가 대형 멀티프로세서 엔터프라이즈 서버 시스템에서 실행되고 있는 동안 동일한 클러스터의 다른 멤버가 더 작은 시스템에서 실행될 수 있습니다. 이러한 두 클러스터 멤버 각각에 대한 서버 구성 설정은 이들 멤버에 지정된 애플리케이션 컴포넌트 영역을 제외하면 매우 다릅니다. 구성 영역에서 이들 멤버는 동일합니다. 이를 통해 모든 워크로드를 단일 애플리케이션 서버에서 처리하는 대신에 클라이언트 작업을 클러스터의 모든 멤버에 대해 분배할 수 있습니다.
클러스터를 작성할 때 기존 애플리케이션 서버의 템플리트 사본을 작성합니다. 템플리트는 이전에 구성한 애플리케이션 서버와 같습니다. 해당 서버를 클러스터의 멤버로 만드는 옵션이 제공됩니다. 그러나 클러스터 멤버를 제거하는 유일한 방법이 애플리케이션 서버를 삭제하는 것이므로, 서버는 템플리트로만 사용 가능하도록 유지하는 것이 좋습니다. 클러스터를 삭제할 때 해당 클러스터의 멤버였던 애플리케이션 서버도 삭제합니다. 클러스터 멤버를 보존할 방법은 없습니다. 템플리트를 원래대로 유지하면 구성을 재빌드해야 하는 경우 템플리트를 다시 사용할 수 있습니다.
세로 클러스터에는 동일한 노드 또는 실제 시스템의 클러스터 멤버가 있습니다. 가로 클러스터에는 셀의 여러 시스템에 있는 여러 노드의 클러스터 멤버가 있습니다. 클러스터 유형을 구성하거나 수직 및 수평 클러스터 조합을 보유할 수 있습니다.
웹 컨테이너를 호스트하는 애플리케이션 서버를
클러스터화하면 애플리케이션 서버와 이 서버가 호스트하는 서블릿에 자동으로
플러그인 워크로드 관리를 사용할 수 있습니다. 서블릿 요청은 HTTP 전송
또는 HTTP 전송 채널을 사용하여 클러스터된 애플리케이션 서버와
웹 서버 플러그인 사이에 라우트됩니다.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

이 라우팅은 클러스터 멤버와
연관된 가중치를 기반으로 합니다. 모든 클러스터 멤버의 가중치가
동일한 경우 플러그인은 강력한 선호도가 없는 것으로 가정하여 모든
클러스터 멤버에게 동일한 요청을 전송합니다. 가중치가 1 - 20의
범위 내에서 차등 적용되는 경우 플러그인은 일반적으로 가중치가 높은
클러스터 멤버에게 요청을 라우트합니다.
관리 콘솔을 사용하여 클러스터 멤버의 가중치를 지정할 수 있습니다. 클러스터 멤버에 지정한 가중치는 작업을 수행하는 대략의 비례적 기능에 기반해야 합니다. 특정 멤버에게 지정된 가중치 값은 클러스터 내의 다른 멤버에 대해 지정하는 가중치 컨텍스트에서만 의미가 있습니다. 가중치 값은 절대적인 성능을 나타내지는 않습니다. 클러스터 멤버가 사용 불가능할 경우, 웹 서버 플러그인은 일시적으로 해당 클러스터 멤버 주위에 요청을 라우트합니다.
예를 들어, 두 개의 멤버로 구성된 클러스터가 있을 경우, 가중치 1 및 2를 지정하면 첫 번째 멤버가 워크로드의 약 1/3을 담당하고 두 번째 멤버가 워크로드의 약 2/3를 담당합니다. 그러나 세 번째 멤버를 클러스터에 추가하고 새 멤버에게 가중치 1을 지정할 경우, 이제 약 1/4의 워크로드가 첫 번째 멤버에게 할당되고 약 1/2의 워크로드가 두 번째 멤버에게 할당되며 약 1/4의 워크로드가 세 번째 멤버에게 할당됩니다. 첫 번째 클러스터 멤버가 사용 불가능할 경우, 두 번째 멤버가 약 2/3의 워크로드를 담당하고 세 번째 멤버가 약 1/3의 워크로드를 담당합니다.
가중치 값은 로드 밸런스 목표의 근사치이며, 특정 요청이 전송되는 위치를 또한 판별하는 요소인 스레드 동시성, 로컬 설정 환경 설정, 선호도 및 자원 가용성과 같은 그밖의 애플리케이션 종속성이 존재합니다. 따라서 특정 클러스터 멤버의 가중치 할당을 판별하는 데 정확한 요청 패턴을 사용하지 마십시오.
EJB 컨테이너에 대한 워크로드 관리는 웹 컨테이너와 EJB 컨테이너를 개별 애플리케이션 서버에 구성하여 수행할 수 있습니다. 여러 애플리케이션 서버는 EJB 컨테이너와 함께 클러스터될 수 있으며 다른 애플리케이션 서버에서 EJB 컨테이너 간 엔터프라이즈 Bean 요청의 분배를 사용 가능하게 합니다.

이 구성에서는 연관된 서버 가중치에 따른 라운드 로빙 방식으로 EJB 클라이언트 요청을 사용 가능한 EJB 컨테이너로 라우트합니다. EJB 클라이언트는 웹 컨테이너에서 작동하는 서블릿, RMI/IIOP를 사용하는 독립형 Java™ 프로그램 또는 기타 EJB입니다.
서버 가중치 라운드 로빙 라우팅 정책을 통해 클러스터 멤버에게 지정된 서버 가중치 세트에 따라 라우팅을 고르게 분배할 수 있습니다. 예를 들어, 클러스터 내 모든 서버의 가중치가 동일한 경우 클러스터에 대한 예상 분배의 한 예는 모든 서버가 동일한 수의 요청을 수신하는 것입니다. 서버 가중치가 서로 다른 경우 분배 메커니즘은 가중치가 낮은 서버보다 가중치가 높은 서버에 보다 많은 요청을 전송합니다. 이 정책은 클러스터 멤버에게 지정되는 가중치를 기반으로 사용자가 원하는 분배를 보장합니다.
서로 다른 클러스터 간에 태스크의
균형을 맞추기 위해 워크로드 관리를 설정할 수 있습니다.
클라이언트가 상주하는 노드로 원하는 라우팅으로서 요청을 전송할 수 있습니다. 이 경우 라운드 로빙 가중치 메소드를 사용하여 해당 노드의 클러스터 멤버만 선택됩니다. 원격 노드의 클러스터 멤버는 로컬 서버를 사용할 수 없는 경우에만 선택됩니다.
동일한 클라이언트 요청을 서비스할 수 있는 다중 서버는 장애 조치(failover) 지원의 기초를 형성합니다. 클라이언트 요청 처리 시 서버가 실패하는 경우, 실패한 요청은 임의의 나머지 클러스터 멤버로 라우트될 수 있습니다. 일부 서버가 실패하더라도 하나 이상의 클러스터 멤버가 실행되는 한, 클라이언트 요청을 계속 처리할 수 있습니다.
기본 클러스터의 모든
멤버를 사용할 수 없더라도 백업 클러스터는 여전히 작동합니다.