브로커 도메인 설계

WebSphere Message Broker 도메인 계획 시 우선 자원 이름 지정 규칙과 WebSphere MQ 인프라스트럭처의 설계 및 성능 문제를 고려해야 합니다. 다음 주제에서는 이러한 고려사항에 대해 설명합니다.

브로커 도메인을 설계할 때 다음 요소를 고려하십시오.

  1. 브로커: 도메인에 필요한 브로커 수는 다음 요인에 따라 다릅니다.
    1. 성능: 필요한 메시지 처리량 (메시지 플로우 처리량 최적화 참조). 처리 중인 메시지 크기. 메시지가 클수록 처리 시간이 오래 걸립니다. 적은 수의 브로커가 많은 메시지를 처리할 경우, 브로커 도메인의 성능에 영향을 미칠 수 있습니다. 도메인의 성능 고려를 참조하십시오.
    2. 응용프로그램 간의 분리. 인사 담당 및 금융 부서와 같이 서로 다른 기능을 수행하는 응용프로그램을 분리하기를 원할 수 있습니다.
    3. 브로커의 publish/subscribe 처리 필요 여부 publish/subscribe 응용프로그램 개발을 참조하십시오.
  2. 사용자 이름 서버: 브로커 도메인에 사용자 이름 서버가 있는 경우, 다음을 고려하십시오.
    1. 성능: 브로커 도메인에 브로커 수가 많은 경우, 사용자 이름 서버가 둘 이상 있으면 브로커가 사용자 이름 서버로 송신하는 요청을 더 신속하게 처리할 수 있습니다. 브로커 도메인이 복잡한 경우 네트워크 트래픽 측면에서 둘 이상의 사용자 이름 서버도 유용할 수 있습니다.
    2. 복원력: WebSphere Message Broker가 대기 메커니즘을 제공하지는 않지만, 첫 번째 사용자 이름 서버의 시스템에서 시스템 오류가 발생하는 경우, 두 번째 사용자 이름 서버로 요청을 재전송하길 원할 수 있습니다.
  3. 구성 관리자: 도메인 및 Workbench에서 구성 저장소와 브로커 세트 간의 인터페이스로 수행됩니다. WebSphere MQ 메시지를 사용하여 브로커와 통신하므로, 브로커 도메인에 브로커가 많으면(바람직하지 않게 설계됨) 구성 관리자가 복잡해질 수 있습니다. 이 문제를 해결하기 위해 브로커를 관련 브로커가 함께 보관되는 둘 이상의 도메인으로 나누십시오. 그러면 각 도메인에 연결할 수 있습니다(도메인 연결 작성 참조).
관련 개념
브로커
브로커 도메인
구성 관리자
사용자 이름 서버
관련 태스크
publish/subscribe 응용프로그램 개발
Workbench에서 브로커 도메인 구성
브로커 도메인 구성요소 구성
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
ae03250_