BizTalk, Configuration

My BizTalk infrastructure design baseline

How should I design my environment? What OS version? SQL Edition? BizTalk license? Etc. Etc. I get these questions frequently.

The only one true answer to this question is the architects favorite – “it depends”. And once you know the requirements – some of the things on which it depends – it will still be closely followed by its companion: “We need to test to know”.

Still, I think everyone has their favorite configuration – that they then add or deduct from based on the requirements. I do. This is how it goes.

Servers

Four. Two SQL, Two BizTalk.
Why? High availability for SQL and BizTalk. Load balancing on BizTalk machines.

OS

Windows Server 2008 (R2) Enterprise, on all machines.
Why? Clustering. Plain and simple.

SQL Edition

SQL Server 2008 (R2) Standard, on the SQL boxes.
Why? Off the BizTalk environments I have worked with they have only very seldom gone beyond two machines which is the only real limitation with Standard that I care about. I know of limitations to RTA in BAM and of performance gains with Enterprise, and sometimes that may be required – but not as a baseline.

SQL Instances

Four SQL Server Instances: BizTalkMgmt, DTA, BAM, MsgBox.
Why? Prepare for and maximize scale-out possibility. Simplify IO division. Help with memory reservation.

SQL IO

Three disks per instance: Data, Log and TempDb. Baseline is 40, 20, 15 GB. Varies with requirements.
SAN if available.
Why? Disks are un-expensive. IO is core to SQL. SQL is core to BizTalk.

BizTalk Edition

BizTalk Server 2009/2010 Enterprise
Why? Number one reason – you want to be able to go beyond a single server: Because you want load balancing and high availability.

Virtualization

Not in my baseline.
Why? Could be a requirement with certain customers and it certainly works, but I would recommend physical machines because I think it gives more bang for the buck. BizTalk can many times be a processor, memory and IO intensive application.

Processor

Quad cores for sure, Hexa or Octo if availability permits. One proc per server is enough with this amount of cores as a baseline. Requirements like high throughput messaging and processing may cause it to rise.
Why? Same as above. Higher ROI with multi-core.

Memory

4 GB minimum for a 64-bit OS, preferably 8GB or more total memory on BizTalk Servers.
At least 16GB on the SQL machines.
Why? Memory is a cheap commodity right now. Not the right place to be cheap.

Summary

The above is in no way thorough. It wasn’t meant to be. There is no “One Truth”. I stress that I call it a Baseline. It was meant to be a brief overview. It’s based on the most common questions and the most common requirements for my customers. Consider your own requirements. Mine might not match yours. “It depends”…

Input

What’s your baseline? Where does it differ? Where have you drawn the same conclusions?

1 thought on “My BizTalk infrastructure design baseline”

  1. Just a short comment on that. SQL Server Standard is max 2 node, but those two nodes can both be active. I am sure you know this, just the way you phrased it might make someone believe otherwise.

    The latest environments I’ve seen setup has hexa or even two octo core procs and up to 128GB of RAM on the SQL machine. With this SQL configuration dedicated to a single BizTalk Group, together with a correctly configured SAN to back it up, it takes a while before you’d need to go above two machines.

    As for the performance improvements in Enterprise above Standard, I’ve always heard that’s the case but I haven’t devled deep enough to know what they are and how they affect BizTalk.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s