소개: 클러스터
클러스터는 함께 관리되어 워크로드 관리에 참여되는 서버의 그룹입니다. 클러스터는 노드 또는 개별 애플리케이션 서버를 포함할 수 있습니다. 노드는 일반적으로 하나 이상의 애플리케이션 서버에서 실행 중인 고유 호스트 IP 주소가 있는 물리적 컴퓨터 시스템입니다. 클러스터는 셀의 구성 하에서 그룹화될 수 있으며, 논리적으로 여러 서버와 클러스터를 다른 구성과 연관시키며 관리자의 판단 및 조직 환경에서 타당한 내용에 따라 애플리케이션과 서로를 연관시킵니다.
클러스터는 서버 간 워크로드 밸런싱을 수행합니다. 클러스터의 일부인 서버를 멤버라고 합니다. 애플리케이션을 클러스터에 설치하면, 애플리케이션은 자동으로 각 클러스터 멤버에 설치됩니다. 애플리케이션 서버에서 서비스 통합 또는 메시지 구동 Bean으로 워크로드 균형화를 제공하도록 클러스터를 구성할 수 있습니다.
![[AIX Solaris HP-UX Linux Windows]](../images/ngdist.svg)
각 클러스터 멤버가 동일한 애플리케이션을 포함하기 때문에, 가중치를 각 서버에 지정하여 다른 시스템의 용량에 따라 분산 플랫폼에서
클라이언트 태스크를 분배할 수 있습니다.
분산 플랫폼에서, 클러스터에서 가중치를 서버에 지정하면 성능과 장애 복구를 개선합니다. 태스크는
태스크 작동을 수행할 수 있는 능력이 있는 서버에 지정됩니다. 하나의 서버가 태스크를 수행할 수 없는 경우
다른 클러스터 멤버에 지정됩니다. 이 재지정 기능은 너무 많은 요청이 작성된 경우 과부하될 수 있는 단일 애플리케이션 서버에서의
실행에 대한 분명한 이점이 있습니다.
클러스터 시작 프로세스 옵션
보통 런타임 처리는 서버 시작 프로세스 중 자동으로 모든 서버 컴포넌트를 시작합니다. 이 처리는 클러스터의 일부인 서버를 포함한 모든 서버에 적용됩니다. 그러나 서버 시작 프로세스 중 모든 서버 컴포넌트가 시작되지 않도록 클러스터 멤버인 서버를 포함한 서버를 구성할 수 있습니다. 이 기능을 사용하면 서버가 필요한 경우 자원을 이용할 수 있으므로 관리 가능한 더 작은 공간을 제공하여 일반적으로 성능이 개선됩니다.
클러스터나 특정 클러스터 멤버가 시작될 때 모든 클러스터 멤버 컴포넌트가 시작되지 않도록 클러스터 멤버를 구성하면, 클러스터 멤버 컴포넌트는 필요할 경우 동적으로 시작됩니다. 예를 들어, 특정 서버 컴포넌트를 요구하는 애플리케이션 모듈이 시작되면 해당 컴포넌트는 동적으로 시작됩니다.
클러스터 및 노드 그룹
클러스터에 설치하는 애플리케이션은 해당 클러스터의 멤버인 애플리케이션 서버에서 실행할 수 있어야 합니다. 노드 그룹이 클러스터의 경계를 형성하기 때문에 클러스터의 모든 멤버들이 동일 노드 그룹의 멤버여야 합니다. 그러므로 배치된 애플리케이션이 성공적으로 실행되려면, 클러스터의 모든 멤버가 해당 애플리케이션의 요구사항을 충족하는 노드에 위치해야 합니다.
여러 다른 서버 구성이 있는 셀에서, 애플리케이션을 호스트하는 기능이 있는 노드를 판별하기 어려울 수 있습니다. 노드 그룹은 제공된 클러스터의 멤버를 호스트하기 위해 공통으로 가지는 노드의 그룹을 정의하는데 사용될 수 있습니다. 클러스터의 모든 클러스터 멤버는 동일 노드 그룹에 있어야 합니다.
모든 노드는 하나 이상의 노드 그룹의 멤버입니다. 클러스터 작성 시, 클러스터에 추가하는 첫 번째 애플리케이션 서버는 다른 모든 클러스터 멤버가 상주해야 하는 노드 그룹을 정의합니다. 클러스터에 추가한 모든 기타 클러스터 멤버는 이 동일 노드 그룹의 멤버인 노드에만 있을 수 있습니다. 관리 콘솔에서 새 클러스터 멤버를 작성하면, 해당 클러스터만에 대한 노드 그룹의 멤버인 노드에서 애플리케이션 서버를 작성할 수 있습니다.
노드는 다중 노드 그룹의 멤버일 수 있습니다. 클러스터에 추가된 첫 번째 클러스터 멤버에 다중 노드 그룹이 정의된 경우, 시스템은 클러스터에 바인드된 노드 그룹을 자동으로 선택합니다. 클러스터 설정을 수정하여 노드 그룹을 변경할 수 있습니다. 노드 그룹을 변경하려면 서버 클러스터 설정 페이지를 사용하십시오.
클러스터 및 코어 그룹
고가용성 환경에서 클러스터 그룹은 코어 그룹으로 정의될 수 있습니다. 코어 그룹에 포함된 클러스터 중 하나의 멤버로 정의된 모든 애플리케이션 서버는 자동으로 해당 코어 그룹의 멤버입니다. 클러스터의 멤버가 아닌 개별 애플리케이션 서버는 코어 그룹의 멤버로 정의될 수도 있습니다. 코어 그룹을 사용하면 WebSphere® Application Server 가 일반 사용자가 항상 사용할 수 있어야 하는 애플리케이션에 고가용성을 제공할 수 있습니다. 코어 그룹 브릿지를 사용하여 서로 통신하도록 코어 그룹을 구성할 수도 있습니다. 코어 그룹은 동일 셀 내 또는 셀 전체에서 통신할 수 있습니다.
클러스터 멤버
클러스터 멤버가 시작될 때 이 컴포넌트의 모두가 자동으로 시작되도록 하는 대신 필요한 경우 각 컴포넌트가 동적으로 시작되도록, 각 클러스터 멤버를 구성하는 경우 시스템 성능을 개선할 수 있습니다. 이 옵션을 선택하면 클러스터 시작 시간을 개선하고 클러스터 멤버의 메모리 풋프린트를 감소시킬 수 있습니다. 필요에 따라 컴포넌트를 시작하는 방법은 클러스터에 배치된 모든 애플리케이션이 동일한 유형인 경우 가장 효율적입니다. 예를 들어, 모든 애플리케이션이 서블릿 및 JSP(JavaServer Pages)를 사용하는 웹 애플리케이션인 경우 이 옵션을 사용하면 작업 성능이 높아집니다. 이 옵션은 애플리케이션이 서블릿, JSP및 EJB (Enterprise JavaBeans ) 를 사용하는 경우 덜 효율적으로 작동합니다.
- 여기에는 Java™ 씬 클라이언트가 포함됩니다.
- 여기서 요청은 다중 셀 사이에서 라우트되거나, 또는
- 여기서 요청은 이전 버전의 제품에서 노드를 포함하는 단일 셀 내에서 라우팅되며,
클러스터 멤버 모두에 동적 포트가 있고 요청이 전송되지 않는 기간 동안 다시 시작된 경우 이 상황이 가장 일반적으로 발생합니다. 이 상태의 클라이언트 프로세스는 결국 노드 에이전트로 라우팅되어 클러스터 멤버에 대한 새 포트 데이터를 수신한 다음, 새 포트 데이터를 사용하여 클러스터의 멤버로 다시 라우팅됩니다.
클라이언트가 노드 에이전트와 통신하지 않거나 새 포트 데이터가 클러스터 멤버와 노드 에이전트 사이에서 전파되지 않게 하는 문제가 발생하면, 요청 장애가 클라이언트에서 발생할 수 있습니다. 일부 경우 이 장애는 일시적입니다. 다른 경우에 하나 이상의 프로세스를 다시 시작하여 장애를 해결해야 합니다.
이 경우 발생할 수 있는 클라이언트 라우팅 문제를 우회하기 위해 클러스터 멤버에서 정적 포트를 구성할 수 있습니다. 정적 포트에서, 클라이언트 프로세스가 클러스터 멤버에 대한 정보를 가져오기 때문에 포트 데이터는 변경되지 않습니다. 클러스터 멤버가 다시 시작되거나 프로세스 사이에 통신이나 데이터 전파 문제가 있더라도, 클라이언트가 보유하는 포트 데이터는 여전히 유효합니다. 이 후회는 기본 통신이나 데이터 전파 문제를 해결하는데 필수가 아니지만 예상되지 않거나 고르지 못한 클라이언트 라우팅 의사결정을 제거합니다.