WebSphere 애플리케이션 서버가 클러스터되고 IBM MQ 큐 관리자가 클러스터될 때 상호 운용
IBM MQ 큐 관리자는 일반적으로 메시지 워크로드를 분산시키기 위해 그리고 한 큐 관리자가 실패하면 다른 큐 관리자가 계속해서 실행할 수 있기 때문에 클러스터됩니다.
참고: 이 주제에서 "애플리케이션 서버"는 WebSphere® Application Server에서
실행 중인 애플리케이션 서버를 가리키고,
"큐 관리자"는 IBM MQ에서
실행 중인 큐 관리자를 가리킵니다.
다음과 같은 두 가지 토폴로지 옵션이 있습니다.
- 큐 관리자가 애플리케이션 서버와 다른 호스트에서 실행됨
- 큐 관리자가 애플리케이션 서버와 동일한 호스트에서 실행됨
큐 관리자가 애플리케이션 서버와 다른 호스트에서 실행됨
다음 그림에서,
- 애플리케이션 서버 1, 2 및 3은 WebSphere Application Server 클러스터에서 클러스터됩니다.
- 애플리케이션 서버 1 및 3은 호스트 1에서 실행 중입니다.
- 애플리케이션 서버 2는 호스트 2에서 실행 중입니다.
- 큐 관리자 1, 2 및 3은 동일한 IBM MQ 클러스터의 일부입니다.
- 큐 관리자 1은 호스트 3에서 실행 중입니다.
- 큐 관리자 2는 호스트 4에서 실행 중입니다.
- 큐 관리자 3은 호스트 5에서 실행 중입니다.
- 큐 관리자 3은 워크로드 밸런싱이 조절되도록 클러스터 큐에 메시지를 분산시켜야 합니다.
- "클라이언트" 연결은 애플리케이션 서버 및 큐 관리자가 서로 다른 호스트에서 실행 중인 경우에
사용됩니다. 이는 큐 관리자와 통신하기 위해 사용되는 TCP/IP 네트워크 연결입니다. 클라이언트 연결을
"소켓 접속"이라고도 합니다.
- 애플리케이션 서버 1 및 2는 클라이언트 모드에서 큐 관리자 1에 접속합니다.
- 애플리케이션 서버 3은 클라이언트 모드에서 큐 관리자 2에 접속합니다.
그림 1. WebSphere Application Server 클러스터링: 큐 관리자에 대한
클라이언트 모드 접속

- 애플리케이션 서버 1이 실패하는 경우:
- 애플리케이션 서버 2는 두 워크로드가 모두 큐 관리자 1에 접속되어 있으므로 해당 워크로드를 인계할 수 있습니다.
- 애플리케이션 서버 2가 실패하는 경우:
- 애플리케이션 서버 1은 두 워크로드가 모두 큐 관리자 1에 접속되어 있으므로 해당 워크로드를 인계할 수 있습니다.
- 애플리케이션 서버 3이 실패하는 경우:
- 다음과 같은 이유로 가능하면 이 서버를 빨리 다시 시작해야 합니다.
- 클러스터의 기타 애플리케이션 서버가 외부 워크로드를 인계할 수 있지만, 큐 관리자 2에 접속된 다른 애플리케이션 서버가 없기 때문에 다른 애플리케이션 서버가 IBM MQ 워크로드를 인계할 수 없습니다. 애플리케이션 서버 3에서 생성된 워크로드가 중지됩니다.
- 큐 관리자 3은 큐 관리자 2에 도착하는 워크로드를 애플리케이션 서버 1 또는 2에서 처리할 수 없는 경우에도 큐 관리자 1과 큐 관리자 2 간에 작업을 계속 분배합니다.
참고: 다시 시작하지 않도록 선택하는 경우, 메시지 넣기 기능이 금지되도록 큐 관리자 2에 Q1을 수동으로 구성하여 이 상황을 완화시킬 수 있습니다. 그러면 큐 관리자 1에 모든 메시지가 전송되어 기타 애플리케이션 서버에서 메시지를 처리합니다. - 큐 관리자 1이 실패하는 경우:
- 다음과 같은 이유로 가능하면 이 서버를 빨리 다시 시작해야 합니다.
- 큐 관리자 1이 실패하면 여기에 있는 메시지는 큐 관리자 1을 다시 시작할 때까지 처리되지 않습니다.
- IBM MQ 애플리케이션의 새 메시지가 큐 관리자 1에 전송되지 않고, 대신 새 메시지가 큐 관리자 2에 전송되어 애플리케이션 서버 3에서 이용됩니다.
- 애플리케이션 서버 1과 2는 큐 관리자 2에 접속되지 않았기 때문에 이 워크로드를 인수할 수 없습니다.
- 애플리케이션 서버 1, 2 및 3이 동일한 WebSphere Application Server 클러스터에 있기 때문에, 큐 관리자 1이 실패해서 애플리케이션 서버 1 및 2가 IBM MQ를 사용할 수 없어도 비IBM MQ 워크로드가 이러한 서버에 계속해서 분배됩니다.
이 네트워킹 토폴로지가 가용성 및 확장성을 제공하기는 하지만, 여러 다른 큐 관리자 및 큐 관리자가 연결된 애플리케이션 서버의 워크로드 간 관계는 복잡합니다. IBM® 담당자에게 전문가 권고를 문의하십시오.
큐 관리자가 애플리케이션 서버와 동일한 호스트에서 실행됨
다음 그림에서,
- 애플리케이션 서버 1, 2 및 3은 동일한 WebSphere Application Server 클러스터의 일부입니다.
- 애플리케이션 서버 1 및 3은 호스트 1에서 실행 중입니다.
- 애플리케이션 서버 2는 호스트 2에서 실행 중입니다.
- 큐 관리자 1, 2 및 3은 동일한 IBM MQ 클러스터의 일부입니다.
- 큐 관리자 1은 호스트 1에서 실행 중입니다.
- 큐 관리자 2는 호스트 2에서 실행 중입니다.
- 큐 관리자 3은 호스트 3에서 실행 중입니다.
- 큐 관리자 3은 워크로드 밸런싱이 조절되도록 클러스터 큐에 메시지를 분산시켜야 합니다.
- 연결에 대한 전송 유형이 "바인딩"으로 지정됩니다.
"바인딩" 연결은 애플리케이션 서버 및 큐 관리자가 동일한 호스트에서 실행 중인 경우에
사용됩니다. 이는 큐 관리자와 통신하기 위해 사용되는 메모리 간 연결입니다. 바인딩
연결을 "호출 접속"이라고도 합니다.
- 애플리케이션 서버 1 및 3은 바인딩 모드에서 큐 관리자 1에 접속합니다.
- 애플리케이션 서버 2는 바인딩 모드에서 큐 관리자 2에 접속합니다.
그림 2. WebSphere Application Server 클러스터링: 큐 관리자에 대한
바인딩 모드 접속

- 애플리케이션 서버 1이 실패하는 경우:
- 애플리케이션 서버 3은 두 워크로드가 모두 큐 관리자 1에 접속되어 있으므로 해당 워크로드를 인계할 수 있습니다.
- 애플리케이션 서버 3이 실패하는 경우:
- 애플리케이션 서버 1은 두 워크로드가 모두 큐 관리자 1에 접속되어 있으므로 해당 워크로드를 인계할 수 있습니다.
- 애플리케이션 서버 2가 실패하는 경우:
- 다음과 같은 이유로 가능하면 이 서버를 빨리 다시 시작해야 합니다.
- 큐 관리자 2에 접속한 다른 애플리케이션 서버가 없기 때문에 다른 애플리케이션 서버가 IBM MQ 워크로드를 인수할 수 없습니다. 애플리케이션 서버 2에서 생성된 워크로드가 중지됩니다. 그러나 클러스터의 다른 애플리케이션 서버가 외부 워크로드를 인수할 수 있습니다.
- 큐 관리자 3은 큐 관리자 2에 도착하는 워크로드를 애플리케이션 서버 2에서 수행할 수 없는 경우에도
큐 관리자 1과 큐 관리자 2 간에 작업을 계속 분배합니다. 참고: 다시 시작하지 않도록 선택하는 경우, 메시지 넣기 기능이 금지되도록 큐 관리자 2에 Q1을 수동으로 구성하여 이 상황을 완화시킬 수 있습니다. 그러면 큐 관리자 1에 모든 메시지가 전송되어 기타 애플리케이션 서버에서 메시지를 처리합니다.
- 큐 관리자 1이 실패하는 경우:
- 다음과 같은 이유로 가능하면 이 서버를 빨리 다시 시작해야 합니다.
- 큐 관리자 1이 실패하면 여기에 있는 메시지는 큐 관리자 1을 다시 시작할 때까지 처리되지 않습니다.
- 애플리케이션 서버 1과 3은 큐 관리자 2에 접속되지 않았기 때문에 이 워크로드를 인수할 수 없습니다.
- IBM MQ 애플리케이션의 새 메시지가 큐 관리자 1에 전송되지 않고, 대신 새 메시지가 큐 관리자 2에 전송되어 애플리케이션 서버 2에서 이용됩니다.
- 애플리케이션 서버 1, 2 및 3이 동일한 WebSphere Application Server 클러스터에 있기 때문에, 큐 관리자 1이 실패해서 애플리케이션 서버 1 및 3이 IBM MQ를 사용할 수 없어도 비IBM MQ 워크로드가 이러한 서버에 계속해서 분배됩니다.
이 네트워킹 토폴로지가 가용성과 확장성을 제공하기는 하지만 여러 다른 큐 관리자 및 큐 관리자가 연결된 애플리케이션 서버의 워크로드 간 관계는 복잡합니다. IBM 담당자에게 전문가 권고를 문의하십시오.