클러스터된 환경에서 WS-Notification
WebSphere® Application Server에서는 서버를 클러스터로 그룹화하는 기능을 제공하여 애플리케이션이 단일 서버 장애에서 보호(고가용성) 또는 애플리케이션 워크로드가 몇 개의 동등 서버로 분산(워크로드 밸런싱) 가능하도록 할 수 있습니다. 서비스 통합 버스는 고가용성, 워크로드 관리 또는 둘 다를 위해 클러스터링하는지에 따라 다양한 구성으로 애플리케이션 서버 클러스터 내에서도 구성 가능합니다. 예를 들어, 클러스터에 구성되는 메시징 엔진 수(한 개에서 최대 클러스터의 서버 수)를 선택하고 제공된 메시징 엔진이 기본 서버가 실패하는 경우 장애 복구하는 서버(있는 경우)를 선택할 수 있습니다.
한 개의 공통 패턴은 클러스터에 한 개의 메시징 엔진만 있고 메시징 엔진은 해당 호스트 서버가 실패하는 경우 클러스터의 다른 서버로 이동할 수 있는 메시징 엔진에 대해 N 중 하나 코어 그룹 정책을 구성하는 것입니다. 그러면 메시징 엔진과 연관된 상태(예를 들어 이벤트 알림 및 등록)는 특정 하드웨어 장치가 실패해도 애플리케이션에서 사용 가능합니다.
로드 밸런스된 토폴로지
이 토폴로지에서 관리자는 특정 서버를 과부하시키지 않으면서 셀 내의 다중 서버에서 클라이언트 애플리케이션 요청을 공유하고자 합니다. 그러려면 WS-Notification 서비스의 모든 WS-Notification 서비스 위치가 동일하게 고려될 수 있으며 특히 모든 토픽 네임스페이스가 브로커의 모든 WS-Notification 서비스 위치에서 사용 가능합니다.
프록시에서 WebSphere Application Server 특정 WS-Addressing 지원을 사용하여 특정 메시징 엔진과 유사성이 있는 웹 서비스 요청(예: 등록 플로우 재개 또는 영구 삭제)이 메시징 엔진이 있는 서버로 다시 라우팅되도록 합니다.
다음 그림은 로드 밸런스에 대해 구성된 클러스터된 환경 구성을 보여줍니다. 세 개의 다른 클라이언트 애플리케이션에서의 요청은 WebSphere Application Server 프록시 서버에서 수신되고 각 요청은 다른 단일 애플리케이션 서버로 전달됩니다. 요청에 대한 정보는 별도의 데이터베이스에서 각 메시징 엔진이 저장합니다. 프록시에서 WebSphere Application Server 특정 WS-Addressing 코드는 각 요청을 수신한 서버를 기록하고 각 후속 요청을 올바른 애플리케이션 서버로 라우팅합니다.

고가용성 토폴로지
이 토폴로지에서 관리자는 메시징 엔진이 포함된 서버가 실패하는 경우 관리하는 자원(등록, 이벤트 알림)이 원격 애플리케이션에서 계속 사용 가능하도록 단일 메시징 엔진 및 WS-Notification 서비스 위치가 포함되는 서버의 클러스터를 작성합니다. 메시징 엔진은 고가용성 조작을 제공하기 위해 클러스터의 다양한 서버 사이에서 장애 복구되도록 구성됩니다.
WS-Notification 서비스 위치는 클러스터의 모든 서버로 배치됩니다. 메시징 엔진이 현재 실행 중인 서버에 대한 연결을 서비스 위치가 작성하는 요청을 실행하기 위해 자원(등록, 공개자 등록 및 풀 위치)은 메시징 엔진에서 유지보수됩니다.
WebSphere Application Server 프록시 서버는 엔터프라이즈에 대한 요청의 입력 초기 위치를 제공하는 애플리케이션 서버의 특수 유형입니다. WS-Notification에 대해 프록시 서버는 가장 자주 사용되는 애플리케이션 서버 클러스터의 프론트 엔드이며 이는 클러스터의 서버 사이의 초기 요청(예: 이벤트 알림)의 로드 밸런싱에 대해 작업하는 위치입니다. 일부 WS-Notification 요청(예: 등록 작성)은 특정 메시징 엔진과의 유사성을 작성하고 해당 자원에 연관된 후속 요청이 프록시 서버에서 수신되면 서버가 자원 작성 후에 장애로 인해 변경된 경우에도 관련 메시징 엔진을 현재 호스트 중인 서버로 라우팅합니다.
프록시에서 WebSphere Application Server 특정 WS-Addressing 지원을 사용하여 특정 메시징 엔진과 유사성이 있는 웹 서비스 요청(예: 등록 플로우 재개 또는 영구 삭제)이 메시징 엔진이 있는 서버로 다시 라우팅되도록 합니다.
다음 그림은 고가용성에 대해 구성된 클러스터된 환경 구성을 보여줍니다. 클라이언트 애플리케이션에서의 요청은 WebSphere Application Server 프록시 서버에서 수신되고 클러스터 내의 애플리케이션 서버로 전달됩니다. 프록시에서 WebSphere Application Server 특정 WS-Addressing 코드는 요청을 수신한 서버를 기록합니다. 요청에 대한 정보는 클러스터의 메시징 엔진이 데이터베이스에 저장합니다. 애플리케이션 서버가 실패하면 해당 위치는 클러스터의 다른 서버가 사용합니다. 프록시의 WS-Addressing 코드는 대체 애플리케이션 서버에 대한 후속 요청을 다시 라우팅합니다.

로드 밸런스된 고가용성 토폴로지
이 토폴로지는 로드 밸런싱된 토폴로지 및 고가용성 토폴로지의 조합입니다. 이 토폴로지에서 클러스터에는 둘 이상의 메시징 엔진이 있습니다(메시징 엔진 수가 서버 수보다 적거나 같음). 프록시 서버에서 수신된 초기 요청은 WS-Notification 서비스 위치를 호스트하는 서버에 대해 클러스터에서 로드 밸런싱됩니다. 해당 요청으로 작성되는 자원에 대한 후속 요청은 클러스터의 다른 서버에서도 실패했을 수도 있는 아핀 메시징 엔진으로 다시 라우팅됩니다.
이는 클러스터에서 둘 이상의 메시징 엔진이 현재 장애 복구의 결과로 한 개 서버에 있는 상황을 포함합니다. 이런 경우, 서비스 위치가 올바른 메시징 엔진에 연결되는 것이 중요합니다.
다음 그림은 고가용성 및 로드 밸런스에 대해 구성된 클러스터된 환경 구성을 보여줍니다. 이 클러스터에는 세 개의 애플리케이션 서버가 있습니다. 이 서버 중 두개는 동일한 메시징 엔진을 사용하고 세 번째는 다른 메시징 엔진을 사용합니다. 클라이언트 애플리케이션의 요청은 WebSphere Application Server 프록시 서버에서 수신되고 메시징 엔진을 공유하는 애플리케이션 서버 중 하나로 전달됩니다. 프록시에서 WebSphere Application Server 특정 WS-Addressing 코드는 요청을 수신한 서버를 기록합니다. 애플리케이션 서버가 실패하고 해당 위치는 다른 두 서버가 사용합니다. 프록시의 WS-Addressing 코드는 초기 요청으로 작성된 자원에 대한 후속 요청(즉, 등록)을 동일한 메시징 엔진을 사용하는 남아있는 애플리케이션 서버로 라우팅합니다.
