[Source: http://geekswithblogs.net/EltonStoneman]
Our ESB Guidance project is nearing code-completion and we're running System Test on an infrastructure which is suitable for production use. Designed for performance, reliability and scalability, we use servers in a combination of NLB farms, Windows clusters and SQL clusters. Shown below is a modified version of the layout, focusing on the BizTalk landscape:
A few of the design decisions are worth looking at:
- Coordination Services run a host for Scheduled Task and FTP adapters, building itinerary requests from received messages. Both adapters are unable to flag an incoming message as being in-process, so are not safe on multiple instances – we have two servers in an active/passive Windows cluster to provide redundancy;
- Itinerary Services run a host for incoming itinerary requests from the SOAP adapter. This is instance-safe, so we have two servers configured in a farm for redundancy and performance;
- Itinerary Processing runs a host for the custom orchestration we have for handling calls to WCF service providers (not shown in this diagram, but running on a separate Web farm and SQL instance). All BizTalk servers run instances of this host, so any with capacity can service calls;
- Enterprise Single Sign-On is located it on the Windows cluster with the Coordination Services, as it cannot run under an NLB farm. The Coordination Service is expected to have spare capacity, so hosting SSO shouldn't impact performance;
- UDDI Services run on the BizTalk NLB farm with the Itinerary Services. A small compromise here from the ideal of having a separate UDDI host, but resolver calls will all be made during Itinerary Processing and we use a custom UDDI resolver which holds the cache indefinitely (until manually invalidated when a change is promoted to the UDDI Service), so after the initial warm-up, UDDI Services will have negligible usage;
-
UDDI Database runs on the same SQL instance as the BizTalk databases. The second small compromise – breaking the cardinal rule that BizTalk should have a dedicated SQL instance with dedicated hardware… As UDDI calls will be minimal, this is a worthwhile performance trade to get the redundancy of having UDDI on the SQL cluster.
The design is intended to cope with a relatively low initial throughput – 250,000 messages in the first year, 98% of which will be a few kilobytes, 2% running into megabytes. BizTalk servers all running Enterprise Edition in a Group, with just Microsoft.Practices.ESB and our custom application installed. Currently the BizTalk servers are running single quad-core CPUs with 4Gb RAM.
Our next task is to run some simulated load through the setup and modify the host layout or physical capacity if necessary. I'll cover the load testing results in a future post.