소개: 클러스터

클러스터는 함께 관리되며 워크로드 관리에 참여하는 서버의 그룹입니다. 클러스터에는 노드 또는 개별 애플리케이션 서버가 포함될 수 있습니다. 노드는 일반적으로 하나 이상의 애플리케이션 서버를 실행하는 고유한 호스트 IP 주소를 갖는 물리적 컴퓨터 시스템입니다. 클러스터는 셀 구성 아래에 그룹화될 수 있는데, 이렇게 하여 관리자의 판단과 조직 환경에 따라 여러 서버 및 클러스터를 서로 다른 구성 및 애플리케이션과 논리적으로 연관시킵니다.

클러스터는 서버 간 워크로드 밸런싱을 수행합니다. 클러스터의 일부인 서버를 클러스터 멤버라고 합니다. 클러스터에 애플리케이션을 설치할 때 애플리케이션은 각 클러스터 멤버에 자동으로 설치됩니다. 애플리케이션 서버의 메시지 구동 Bean 또는 서비스 통합에 워크로드 밸런싱을 제공하도록 클러스터를 구성할 수 있습니다.

[AIX Solaris HP-UX Linux Windows]각 클러스터 멤버는 동일한 애플리케이션을 포함하므로, 각 서버에 가중치를 지정하여 서로 다른 시스템의 용량에 따라 분산 플랫폼에서 클라이언트 태스크를 분배할 수 있습니다.

[AIX Solaris HP-UX Linux Windows]분산 플랫폼에서 클러스터의 서버에 가중치를 지정하면 성능과 장애 조치(failover)가 향상됩니다. 태스크는 태스크 조작을 수행하는 용량이 있는 서버에 지정됩니다. 태스크를 수행하는 데 한 서버를 사용할 수 없으면 태스크는 다른 클러스터 멤버에 지정됩니다. 이 재지정 기능은 특히 요청이 너무 많은 경우 과부하될 수 있는 단일 애플리케이션 서버 실행 시 효율적입니다.

클러스터 시작 프로세스 옵션

서버가 시작되는 동안 정상적인 런타임 처리 중에 모든 서버 컴포넌트가 자동으로 시작됩니다. 이러한 처리는 클러스터에 속하는 서버를 비롯한 모든 서버에 적용됩니다. 하지만 서버가 시작되는 동안 클러스터 멤버인 서버를 비롯하여 일부 서버 컴포넌트가 시작되지 않도록 서버를 구성할 수 있습니다. 이 기능을 통해 서버는 필요에 따라 자원을 이용할 수 있으므로 관리 풋프린트를 유연하게 제공하여 성능을 향상시킵니다.

클러스터 또는 특정 클러스터 멤버가 시작될 때 일부 클러스터 멤버가 시작되지 않도록 클러스터 멤버를 구성하면, 클러스터 멤버는 필요에 따라 동적으로 시작됩니다. 예를 들어, 특정 서버 컴포넌트가 필요한 애플리케이션 모듈이 시작되면 해당 컴포넌트가 동적으로 시작됩니다.

클러스터 및 노드 그룹

클러스터에 설치하는 애플리케이션은 해당 클러스터의 멤버인 애플리케이션 서버에서 실행할 수 있어야 합니다. 노드 그룹은 클러스터의 경계를 형성하므로 클러스터의 모든 멤버는 동일한 노드 그룹의 멤버여야 합니다. 따라서 실행하기 위해 배치하는 애플리케이션의 경우, 클러스터의 모든 멤버는 해당 애플리케이션의 요구사항을 충족시키는 노드에 있어야 합니다.

많은 다른 서버 구성이 있는 셀에서는 애플리케이션을 호스트할 성능이 있는 노드를 판별하기 어렵습니다. 노드 그룹을 사용하면 해당 클러스터의 멤버를 호스트할 공통 노드 그룹을 정의할 수 있습니다. 클러스터의 모든 클러스터 멤버는 동일한 노드 그룹에 있어야 합니다.

모든 노드는 최소 하나의 노드 그룹의 멤버입니다. 클러스터를 작성하는 경우, 클러스터에 추가하는 첫 번째 애플리케이션 서버는 다른 클러스터 멤버가 상주해야 하는 노드 그룹을 정의합니다. 클러스터에 추가하는 모든 기타 클러스터 멤버는 이 동일한 노드 그룹의 멤버인 노드에만 있을 수 있습니다. 관리 콘솔에서 새 클러스터 멤버를 작성하는 경우, 해당 클러스터의 노드 그룹 멤버인 노드에서만 애플리케이션 서버를 작성할 수 있습니다.

노드는 여러 노드 그룹의 멤버일 수 있습니다. 클러스터에 추가하는 첫 번째 클러스터 멤버에 여러 노드 그룹이 정의된 경우, 시스템은 자동적으로 해당 클러스터와 연결되는 노드 그룹을 선택합니다. 클러스터 설정을 수정하여 노드 그룹을 변경할 수 있습니다. 서버 클러스터 설정 페이지에서 노드 그룹을 변경할 수 있습니다.

클러스터 및 코어 그룹

고가용성 환경에서 클러스터 그룹은 코어 그룹으로 정의될 수 있습니다. 코어 그룹에 포함된 클러스터 중 하나의 멤버로 정의된 애플리케이션 서버는 자동적으로 해당 코어 그룹의 멤버가 됩니다. 클러스터의 멤버가 아닌 개별 애플리케이션 서버도 코어 그룹의 멤버로 정의할 수 있습니다. 코어 그룹을 사용하여 WebSphere® Application Server는 최종 사용자가 항상 사용해야 하는 고가용성의 애플리케이션을 제공합니다. 코어 그룹 브릿지를 사용하여 코어 그룹이 서로 통신하도록 구성할 수 있습니다. 코어 그룹은 같은 셀 내에서나 셀 사이에서 통신할 수 있습니다.

클러스터 멤버

각 클러스터 멤버를 구성한 경우 시스템 성능을 개선할 수 있습니다. 예를 들어, 클러스터 멤버가 시작될 때 이러한 모든 컴포넌트를 자동으로 시작하도록 하는 대신에 필요에 따라 각각의 컴포넌트를 동적으로 시작할 수 있습니다. 이 옵션을 선택하면 클러스터 시작 시간을 개선하고 클러스터 멤버의 메모리 풋프린트를 줄일 수 있습니다. 필요에 따라 컴포넌트를 시작하는 방법은 클러스터에 배치된 모든 애플리케이션이 동일한 유형인 경우 가장 효율적입니다. 예를 들어, 모든 애플리케이션이 서블릿 및 JSP(JavaServer Pages)를 사용하는 웹 애플리케이션인 경우 이 옵션을 사용하면 작업 성능이 높아집니다. 이 옵션은 애플리케이션이 서블릿, JSP 및 EJB(Enterprise JavaBeans)를 사용하는 경우에는 덜 효율적입니다.

문제점 방지 문제점 방지: 다음 환경에서 실행 중인 클라이언트가 있을 경우:
  • Java™ 씬 클라이언트를 포함하며,
  • 여러 셀 간에 요청이 라우트되고 있는 중이거나
  • 이전 버전 제품의 노드를 포함하는 단일 셀 내에서 요청이 라우트되고 있는 환경
대상 클러스터의 클러스터 멤버에 대한 포트 정보의 시간이 경과되는(stale) 상황이 발생할 수 있습니다.

이러한 상황은 모든 클러스터 멤버에 동적 포트가 있으며 전송된 요청이 없는 동안 이 클러스터 멤버가 다시 시작될 때 가장 흔히 발생합니다. 이 상태의 클라이언트 프로세스는 결국 클러스터 멤버에 대한 새 포트 데이터를 받기 위해 노드 에이전트로 경로를 지정하려 시도한 후, 새 포트 데이터를 사용하여 클러스터의 멤버로 다시 경로를 지정합니다.

클라이언트와 노드 에이전트의 통신을 방해하거나 클러스터 멤버와 노드 에이전트 간의 새 포트 데이터 전파를 차단하는 문제가 일어날 경우 클라이언트에서 요청 실패가 발생할 수 있습니다. 일부 경우 이러한 실패는 일시적입니다. 그렇지 않은 경우에는 하나 이상의 프로세스를 다시 시작하여 실패를 해결해야 합니다.

이러한 경우에 발생할 수 있는 클라이언트 라우팅 문제를 피하기 위해 클러스터 멤버에 정적 포트를 구성할 수 있습니다. 정적 포트를 사용하면 클라이언트 프로세스가 클러스터 멤버에 대한 정보를 가져올 때 포트 데이터가 변경되지 않습니다. 클러스터 멤버가 다시 시작되거나, 프로세스 간에 통신 또는 데이터 전파 문제가 있더라도 클라이언트가 보유한 포트 데이터는 여전히 유효합니다. 이러한 우회 방식이 근본적인 통신 또는 데이터 전파 문제를 해결하는 것은 아니지만 예상치 못하거나 불규칙한 클라이언트 라우팅 의사결정 증상은 제거할 수 있습니다.

gotcha

주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=welcclusters
파일 이름:welcclusters.html