클러스터를 사용하는 Business Process Choreographer 시나리오의 서로 다른 구성 옵션 및 고려사항을 설명합니다.
Business Process Choreographer 인스턴스용 WebSphere® Process Server 클러스터를 사용함으로써 나타나는 주요 장점은 다음과 같습니다.
여러 다른 방법으로 Business Process Choreographer를 구성할 수 있기 때문에 일반적으로 클러스터 구성은 매우 복잡합니다. 다음은 Application Server를 작성하기 전에 고려해야 할 주요 옵션을 설명합니다.
서로 다른 Business Process Choreographer 인스턴스 사이에서 워크로드를 분배하려면 각 Application Server의 비즈니스 프로세스 컨테이너에 의해 사용되는 대기열 관리자가 동일한 WebSphere MQ 클러스터의 구성원이어야 합니다. 이 구성은 실패복구를 제공하지 않으며 일반적으로 권장되지 않습니다.
클러스터 유형: 이 주제는 두 개의 서로 다른 클러스터 유형을 참조합니다. WebSphere 클러스터는 Application Server를 함께 그룹화하여 워크로드를 공유하고 서비스 가용성을 향상합니다. 이전에 MQSeries®로 알려진 WebSphere MQ 클러스터는 WebSphere MQ 대기열 관리자와 함께 그룹화하고 프로세스내 워크로드의 균형을 맞추는데 사용할 수 있습니다.
Business Process Choreographer 서비스의 고가용성을 획득하려면 다음 항목을 고려하십시오.
성능을 향상하려면 Business Process Choreographer에서 사용 가능한 시스템 자원을 사용할 수 있도록 동일한 노드에서 여러 Application Server를 작성해야할 수 있습니다.
대기열을 호스트하지 않는 대기열 관리자에 보호 설정만되는 경우 메시지가 클러스터의 모든 get 대기열 관리자에 걸쳐 고루 분배됩니다. 설치 마법사를 사용하여 클러스터에 비즈니스 프로세스 컨테이너를 설치 및 구성한 후, Application Server당 두 개의 연결 팩토리를 수동으로 변경하여 get 및 put 대기열 관리자를 가리키도록 해야 합니다.
전용 서버의 데이터베이스(가급적 상시 대기 상태인)를 호스트할 것을 권장합니다. WebSphere 셀의 외부에 있는 서버에 데이터베이스가 있을 수 있지만 Deployment Manager에 액세스 권한이 있어야 합니다.
데이터베이스 계획 시 다음을 고려하십시오.
Business Process Choreographer는 클러스터링, 워크로드 관리 및 실패복구를 지원하는 WebSphere 기본 메시징을 사용할 수 있습니다.
기본 메시징을 사용할 때 적용되는 고려사항에 대한 자세한 정보는 Creating a clustered environment를 참조하십시오.
Business Process Choreographer는 요청 수신 및 응답 전송에 WebSphere MQ 대기열을 사용할 수 있습니다. 클러스터 시나리오를 사용하는 경우 JMS 프로바이더로 WebSphere MQ를 권장하지 않습니다. WebSphere MQ를 사용하는 경우, Business Process Choreographer가 인바운드 및 아웃바운드 서비스 호출에 사용하는 SCA(Service Component Architecture)의 기본 메시징을 계속 구성해야 합니다. Business Process Choreographer를 호스트하는 각 Application Server는 다음 옵션 중 하나를 요청합니다.
중앙 대기열 관리자
모든 대기열에 중앙 대기열 관리자를 사용하면 관리가 수월해집니다. 휴먼 타스크 및 비즈니스 프로세스에서 하나의 대기열 관리자는 복제된 모든 컨테이너에 의해 사용됩니다. 그러나, 중앙 대기열 관리자를 사용하면 고가용성 시스템에서 호스트되어야 하는 단일 장애 위치를 작성합니다.
다음 그림은 다른 서버의 단일 중앙 대기열 관리자를 사용하여 WebSphere 클러스터의 모든 Application Server를 보여줍니다. 비즈니스 프로세스 컨테이너가 표시된 모든 Application Server는 휴먼 타스크 컨테이너도 있어야 합니다.
WebSphere MQ 클러스터링이 없는 로컬 대기열 관리자
다음 예제는 표준, 독립형 Business Process Choreographer 구성을 나타냅니다. 각 비즈니스 프로세스 컨테이너에는 하나의 로컬 대기열 관리자가 있습니다. 이 접근은 프로세스내 워크로드 공유 또는 실패복구 서비스 가용성을 제공하지 않습니다.
WebSphere MQ 클러스터링
이 복합 기술은 권장되지 않습니다. WebSphere 클러스터에 있는 Business Process Choreographer의 프로세스내 워크로드 공유를 지원합니다. 클러스터의 비즈니스 프로세스는 모두 UNIX® 전용 또는 Windows® 워크스테이션 전용에서만 실행되어야 합니다. UNIX 및 Windows 서버의 조합은 작동하지 않습니다.
각 Application Server는 put 및 get 메시지에 하나씩 두 개의 로컬 대기열 관리자가 필요합니다. 모든 대기열 관리자는 동일한 WebSphere MQ 클러스터의 구성원이 됩니다. Windows 시스템에서 모든 대기열 관리자는 동일한 바인딩 프로토콜을 사용해야 합니다. UNIX 시스템에서 put 및 get 대기열 관리자는 서로 다른 프로토콜을 사용해야 합니다. 예를 들어, 모든 put 대기열 관리자가 바인딩 프로토콜(프로세스간 통신)을 사용하고 모든 get 대기열 관리자가 기본, 클라이언트(TCP/IP) 프로토콜을 사용하도록 대기열 연결 팩토리를 수정할 수 있습니다.
Windows 및 UNIX 시스템에서 로컬 바인딩 전송 유형이 클라이언트 전송 유형을 사용하는 경우에 비해 5% 정도 속도가 더 빠르지만 로컬 WebSphere MQ 대기열 관리자를 중지하려면 전체 Application Server를 중지해야 합니다.
WebSphere 클러스터의 각 비즈니스 프로세스 컨테이너는 고유 대기열 관리자를 반영하도록 사용자 정의해야 합니다.
WebSphere MQ 클러스터에서 하나 이상의 대기열 관리자를 클러스터 저장소로 작성하는 것이 좋습니다.
다음 그림은 Application Server에서 사용되는 대기열 관리자가 WebSphere MQ 클러스터에서 함께 그룹화되는 방법을 보여줍니다. 대기열 관리자의 WebSphere MQ 클러스터는 Application Server의 WebSphere 클러스터에 병렬입니다. 클러스터의 get 대기열에 걸쳐 요청이 공유됩니다.
Business Process Choreographer 클러스터 작성 시 여러 다른 순서를 사용할 수 있습니다. 다음 순서가 권장됩니다.
(c) Copyright IBM Corporation 2005, 2006.
이 Information Center는 Eclipse 기술을 기반으로 합니다. (http://www.eclipse.org)