BizTalk Server 2006 – Enterprise Production Considerations – Part 1 – Production Server Topology


Introduction:


This post is the first in a series of posts that will describe a number of production considerations for Enterprise customers (“Enterprise” loosely defined as those with moderately complex BizTalk implementations)


This is in response to a great deal of confusion that I have encountered in the field and hopefully I can kill about 500 birds with 1 stone by publishing these findings (no offence to bird enthusiasts J ).


Today’s Topic – Starting the Production Infrastructure


BizTalk Server 2006 has a dizzying array of scalability options, but many options can mean complexity.  This post will specifically discuss the most common “starting points” for production enterprise BizTalk systems and compare/contrast them so you can hopefully figure out which one best suits your needs.


The X + Y notation means:


X Dedicated BizTalk boxes
Y SQL Server Nodes


Server Configurations


Before we get started here, I have to emphasize that these are all common STARTING configurations.  Configurations can (and do) scale out and up depending on your requirements.


Also, all of these configurations have some notion of high availability, no single node failure will kill the infrastructure.  Way more options are available if you sacrifice High Availability (but that’s pretty unusual in the Enterprise isn’t it? J )


 





























 


 



This configuration has the minimal number of servers involved but it does present some complexity problems because the BizTalk hosts must be clustered if you are running the ENTSSO service as a clustered service.  You either cluster the hosts or live with having an un-clustered Enterprise Single Sign- on Master Secret Server. Either option could be best depending on your requirements.


 


 



This configuration is a pretty good starting point for the cost-sensitive enterprise.   This allows separation of BizTalk from SQL (a good thing) while maintaining redundancy by having two BizTalk nodes that can “cover for each other” in case one of them goes down.  The ENTSSO MSS can be installed as a clustered service on the SQL cluster without creating complications for the BizTalk hosts (i.e. they don’t have to be clustered, which is also a good thing in many cases)


This is probably my favorite starting point.  It is the lowest cost, and scaling out with more BizTalk servers is really easy.  If you’re not sure which one to pick, take this one.


 


 



This configuration is an improvement on the 2+2 configuration because it really allows the orchestrations and business logic to become intensive without having much of an impact on the Send/Receive operations (even though the Send/Receive operations can still interfere with each other).  This is for enterprise applications with moderate Send/Receive activity and fairly intensive business logic.


 


 



Of the configurations being considered in this article, this is the most capable (and most expensive).  This allows full separation between BizTalk and SQL, and also between the Send/Receive/Process operations within BizTalk. This configuration is for Enterprises with intensive Send/Receive/Process requirements.


Notice the additional SQL server, a pretty good rule of thumb is a ratio of 3:1 for BizTalk:SQL servers. Although this one is 3:1 with only 2 SQL servers, a failure of one node would change that ratio to 6:1. Seeing as how this configuration is for high volume scenarios, that would be bad.  Invest a couple of bucks and have a passive node in the wings to keep things running if a SQL node goes down!


Comparison Chart

































































 


0+2


2+2


4+2


6+3


High Availability


Yes


Yes


Yes


Yes


Performance


Lowest


Medium


Medium


Best


Cost (# Servers)


Lowest


Medium


Medium


Highest


Ease of clustering SSO MSS


Hard


Easy


Easy


Easy


Separation of SQL and BizTalk


No


Yes


Yes


Yes


Dedicated Receive Nodes


No


No


No


Yes


Dedicated Send Nodes


No


No


No


Yes


Dedicated Process Nodes


No


No


Yes


Yes


Easy to Scale out


Complex


Yes


Yes


Yes


 


 Call to Action


 I know what I want to write about, but this blog isn't for me!  What topics do you want to see in the next article? Drop in a request in the comments section below and I'll review before I start writing the next article (I promise)




  • Configuration


  • SAN/Storage


  • Troubleshooting/Debugging


  • High Availability


  • other....

Comments (4)

  1. Jim Allen says:

    Interesting article. What are your views on seperating out the MessageBox DB from the rest of the BizTalk DBs for increased performance, and how would that fit in the above?

    Jim

  2. neilth says:

    Great Question!!

    Thats almost deserving of a whole other posting. I’ll give a breif summation here…

    In any kind of medium to high load scenario, I definitely believe that the MessageBox should be isolated. Specifically, it should have no less than two LUNS (Drives) dedicated to it (data/log), which it does not share with other databases (especially not the Tracking DB). In high performance scenarios there are 4 data LUNS and 1 Log LUN presented from the SAN used solely by the MsgBox.

    At the SQL Service level, I think that separating the MsgBox onto it’s own SQL instance is also a good idea.  

    These Disk and SQL instance isolation strategies are compatible with any of the scenarios above.  So long as there are sufficient LUNS cut from the SAN, the disk partition is is possible.  If the SQL Cluster is Active/Active it would allow futher separation of the MsgBox out into its own SQL instance, with all the other DB’s on the other instance(s).

    As a final thought on this, creating multiple MsgBox databases is almost too easy. As a result we race ahead to that option and scale "out" to have more messagebox dbs when perhaps scaling "up" with Disk or SQL instance isolation would have been far more practical and equally effective for a given load.

  3. testersuper says:

    Regarding Master SSO deployment options, I read your previous blog posting with the fairly clear opinion that the Master SSO should be clustered, my question is whether you could explain in more detail how the Master SSO benefits from being clustered vs having something like MOM/SCOM handle this?  My opinion (which is based on no experience at all hence why I’m asking) is that enabling SCOM to handle this would provide a more reliable option and remove the overhead of deploying SSO.  In my particular current situation I’m dealing with a small but critical deployment where clustering SSO = doubling the amount of hardware and I want to ensure there is a real benefit.

    Thanks for any input/experience you may have with this.

    Mike

  4. bna0s0k says:

    Can I install ENT SSO MSS and SSODB on SQL cluster where other BizTalk Server database are installed?

    Thanks,

    Sam

Skip to main content