BizTalk Server 계층 확장
BizTalk 계층을 확장하려면 기존 토폴로지에 하드웨어를 추가합니다. 다음과 같은 시나리오에서 하드웨어를 추가하는 것이 좋습니다.
BizTalk Server에 병목 상태가 발생합니다. 병목 상태 자체는 다음 문제 중 하나로 인해 발생할 수 있습니다.
CPU: CPU를 많이 사용하는 파이프라인, 맵 또는 오케스트레이션을 사용하는 경우 BizTalk Server에 CPU 여유 리소스가 남지 않게 됩니다.
메모리 및 I/O: 기존 컴퓨터가 메모리 및 IO에 대한 최대 한도에 도달한 경우 리소스를 추가하는 유일한 방법은 다른 물리적 컴퓨터를 추가하는 것입니다.
업그레이드 비용이 많이 듭니다. 예를 들어 하나 있는 BizTalk Server 토폴로지에서 BizTalk CPU가 최대 용량에 도달한 경우 이중 프로세서를 4중 프로세서로 업그레이드하는 비용보다 별도의 이중 프로세서 컴퓨터를 추가하는 비용이 더 적게 들면 컴퓨터를 추가하는 것이 좋습니다.
업그레이드해도 병목 상태가 해결되지 않습니다. 다음과 같은 경우 시스템을 업그레이드해도 병목 상태가 해결되지 않을 수 있습니다.
BizTalk 컴퓨터에서 IO가 최대 수준에 도달하여 IO를 확장하기 위해 다른 컴퓨터가 필요합니다.
메모리가 운영 체제에서 허용되는 최대 수준에 도달했습니다. 이 시나리오에서 시스템을 확장하는 유일한 방법은 토폴로지에 별도의 BizTalk 컴퓨터를 추가하는 것입니다.
일부 시나리오에서는 메시지 수신, 메시지 전송 및 메시지 처리 전용 서버가 필요할 수 있습니다. 전용 서버가 있는 경우 다른 컴퓨터에 영향을 주지 않고 한 컴퓨터에서 쉽게 문제를 격리하여 유지 관리를 수행할 수 있습니다. BizTalk 계층을 확장하여 이러한 컴퓨터를 추가할 수 있습니다.
BizTalk 계층을 확장할 수 없는 경우
MessageBox 데이터베이스가 병목 상태에 있습니다.
어댑터에 병목 상태가 발생합니다. 예를 들어 SQL 어댑터를 사용하는 경우 BizTalk 수신기 수를 늘리면 BizTalk SQL 어댑터가 데이터를 가져오는 SQL 데이터베이스에서 잠금 충돌이 증가합니다. 따라서 SQL 어댑터를 확장하기 어려워집니다.
다음 그림은 BizTalk 계층을 확장할 수 있는 방법에 대한 예를 보여 줍니다.
이 그림은 확장된 BizTalk 토폴로지(하나의 BizTalk Server에서 두 개의 BizTalk Server로 확장)를 보여 줍니다. 하나의 BizTalk Server가 있는 토폴로지에서는 세 개의 호스트 인스턴스가 BizTalk 컴퓨터 리소스를 공유합니다. 두 개의 BizTalk Server가 있는 토폴로지에서는 전송 호스트가 다른 서버로 분리되어 처리량이 높아집니다.
BizTalk 계층 확장 시 고려 사항
다른 BizTalk Server 컴퓨터를 추가하기 전에는 다음을 고려해 보아야 합니다.
BizTalk 계층 확장 시 시스템의 로드 균형 조정 및 내결함성 구성 방법
로드 균형 조정 및 내결함성 기술에 대한 선택은 시나리오에서 사용하는 어댑터에 따라 달라집니다. SOAP 및 HTTP 어댑터의 경우 NLB를 사용하는 것이 좋습니다. 자세한 내용은 NLB 설명서를 참조하십시오.
호스트 인스턴스 리팩터링 방법
BizTalk 계층 확장 시 호스트 인스턴스를 리팩터링하는 방법을 결정하는 단일 규칙은 없습니다. 호스트 인스턴스를 팩터링하는 시기는 시나리오 복잡성에 따라 달라집니다. 다음은 호스트 인스턴스를 팩터링하는 방법에 대한 몇 가지 예입니다.
시나리오 1
단일 BizTalk Server 구성으로 수신 호스트 인스턴스와 전송 호스트 인스턴스가 동일한 컴퓨터에 있습니다.
CPU 병목 상태가 있다고 가정합니다. 확장을 위해 그룹에 동일한 BizTalk 컴퓨터를 하나 더 추가하여 다음 두 가지 방법으로 호스트 인스턴스를 팩터링할 수 있습니다.
이 문제에 대한 두 가지 솔루션은 다음과 같습니다.
해결 방법 1: 이 시나리오에서 팩터링하는 가장 쉬운 방법은 호스트 instance 첫 번째 컴퓨터에서 두 번째 컴퓨터로 팩터링을 복제하는 것입니다. 이에 따라 두 번째 컴퓨터는 기능면에서 첫 번째 컴퓨터와 똑같은 복사본이 되며 송수신 호스트를 모두 가질 수도 있습니다. 병목 상태가 없는 경우에도 CPU 리소스가 두 배가 되므로 배율 인수 2를 얻을 수 있습니다.
해결 방법 2: 호스트 인스턴스를 팩터하는 또 다른 방법은 수신 및 보내기 함수를 다른 컴퓨터로 격리하는 것입니다. 즉, BizTalk Server 중 하나는 수신 전용이 되고 다른 하나는 송신 전용이 됩니다.
솔루션 1과 솔루션 2 비교
솔루션 1의 경우 호스트 인스턴스 수가 1 BTS 구성의 두 배가 됩니다. 따라서 SQL 서버에서의 잠금 충돌이 증가합니다. 잠금 충돌의 증가량에 따라 배율 인수가 달라집니다. 잠금 충돌이 병목 상태를 발생시킬 만큼 많지 않은 경우 배율 인수는 2가 됩니다.
솔루션 2의 장점은 호스트 인스턴스가 두 개뿐이므로 SQL Server의 잠금 경합이 솔루션 1에 비해 적어야 한다는 것입니다. 그러나 크기 조정 요소는 수신 및 송신 호스트 인스턴스의 복잡성에 완전히 따라 달라집니다. 솔루션 2에서 다음 경우를 고려해 보십시오.
하나의 BizTalk Server가 있는 토폴로지에서 수신 호스트 인스턴스와 전송 호스트 인스턴스가 모두 CPU를 많이 사용하며 각각 CPU를 50%씩 사용한다고 가정합니다. 두 개의 BizTalk Server가 있는 토폴로지에서 전송 호스트 인스턴스를 다른 컴퓨터로 이동하면 수신 인스턴스와 전송 인스턴스의 리소스가 모두 두 배로 늘어납니다. 따라서 병목 상태가 없는 경우 배율 인수가 2가 됩니다. 이 경우 호스트 인스턴스가 두 개뿐이어서 잠금 충돌이 적기 때문에 솔루션 1보다 낫습니다.
하나의 BizTalk Server가 있는 토폴로지에서 전송 인스턴스가 수신 인스턴스보다 CPU를 더 많이 사용하여 CPU 리소스를 80% 사용한다고 가정합니다. 이때 전송 호스트 인스턴스를 다른 컴퓨터로 이동하면 CPU 리소스가 20%만 늘어나 최대 배율 인수가 1.2가 됩니다. 또한 수신 호스트 인스턴스가 있는 컴퓨터에서는 20-30%의 CPU 리소스만 사용하므로 확장을 통한 이점이 훨씬 적습니다.
네 대의 BizTalk Server가 있는 다음 그림을 살펴 보십시오. 각 컴퓨터는 수신자 및 발신자이며 각 유형의 총 4개의 호스트 인스턴스(수신 및 전송)를 제공합니다.
이는 최상의 토폴로지가 아닐 수 있으며 시나리오의 복잡성에 따라 다른 팩터링 순열도 테스트해 보아야 합니다. 예:
수신용 컴퓨터 2대와 전송용 컴퓨터 2대를 바칩니다. 이렇게 하면 수신 인스턴스와 전송 인스턴스의 CPU 사용률이 동일한 경우 최상의 배율을 얻을 수 있습니다.
수신 인스턴스에서 전송 인스턴스보다 CPU를 많이 사용하는 경우 수신 전용 컴퓨터 세 대와 전송 전용 컴퓨터 한 대를 지정합니다.
전송 인스턴스에서 수신 인스턴스보다 CPU를 많이 사용하는 경우 수신 전용 컴퓨터 한 대와 전송 전용 컴퓨터 세 대를 지정합니다.
모든 시나리오에서 MessageBox 데이터베이스에서의 충돌을 줄이는 동시에 컴퓨터 리소스가 최대로 사용되도록 각 호스트의 호스트 인스턴스 수를 최소화하는 것이 좋습니다. 최상의 팩터링 순열은 시나리오의 복잡성 및 병목 상태의 유형에 따라 달라집니다. 순열을 결정하기 전에는 항상 팩터링을 테스트해 보아야 합니다.
참고 항목
BizTalk Server 계층 업그레이드
SQL Server 계층 업그레이드
SQL Server 계층 확장
확장된 수신 호스트
확장된 처리 호스트
확장된 송신 호스트
Windows Server 클러스터를 사용하여 BizTalk Server 호스트에 고가용성 제공2
확장된 데이터베이스
BizTalk Server 데이터베이스 클러스터링