When you start deploying BizTalk in your organization, you’ll probably be deploying more than just one BizTalk server. Deploying multiple BizTalk servers allows you to create redundancy as well as increase processing power. However, deploying multiple BizTalk servers needn’t add to your administrative burdens. All you have to do is create BizTalk server groups.
How groups work
BizTalk Server stores documents in a common Shared Queue SQL Server database until they are processed. For example, an incoming purchase order would be placed in the Shared Queue database until BizTalk Server could process it. BizTalk Server also maintains a Tracking database that it uses to track document and interchange activity. Both of these databases are core components for their target solution.
BizTalk Server supports server groups to simplify management and provide a measure of failover capability without clustering. A BizTalk server group is a group of servers that share the Shared Queue and Tracking databases, as well as common configuration information. A server group also shares receive functions that you've defined for the solution as well as other components that are required to route and process documents.
Because they share a common dataset, servers in a server group can all be active and processing documents from the queue. If a server in a group goes offline, the remaining servers can continue processing the queue. This structure provides failover capability without the installation of clustering solutions. As I'll discuss later, however, there is a place for clustering in BizTalk Server deployments.
Servers in a BizTalk server group share the same BizTalk Messaging Management database. However, you're not restricted to a single database-per-group relationship. A Messaging Management database can serve multiple BizTalk Server groups. This structure enables the servers in a group to share configuration information, and enables remote management of multiple groups from the management console.
A single server can reside in only one group, and must be running the same version and language of BizTalk Server. Servers in a group are not restricted to performing the same functions. For example, in a simple group you might dedicate one BizTalk Server to receiving documents and dedicate others in the group to processing documents. Distributing the load in this way provides for efficient processing, distributes workload, and offers flexibility for server configuration.
What to consider during the planning phase
When you start looking at server group design for your deployment, begin by examining the tasks that BizTalk Server needs to perform within the scope of your integration project. Which functions would best be served by a single group? Which functions need to be handled by multiple groups? Do you need to dedicate a group to one or more key partners? Answering these questions and diagramming your solution will help you discover where the best group boundaries lie.
As you move through the server and group planning stage, remember to take clustering and your databases into account. SQL Server databases are crucial to your BizTalk Server solution. If a database becomes unavailable, your solution will likely be dead in the water. For example, if the queue database goes offline, there will be no place to store new documents and the servers will be unable to process the existing documents. So, carefully consider the impact that a database server failure will have on your solution.
If you can afford to have your system down for several hours while you restore the database server and don't want the added expense or management overhead of clustering, a single, unclustered server will suffice. If high availability is a necessity, however, clustering your database servers is a key step in providing that availability.
As you consider database design in light of clustering and load balancing, consider locating the Shared Queue database and Tracking database on separate servers to distribute the load. Make sure to cluster both SQL servers for failover capability of both, as they are equally important.
Would you like a cluster with that?
A final design consideration is whether to cluster BizTalk Servers in a group. As I already explained, multiple servers in a group can process documents from the shared queue, so that if one server goes down, the rest can continue to process the queue. However, key servers within a group should also be clustered in any scenario where you need to ensure high availability. You should also cluster non-BizTalk Servers in some situations to provide failover capability. For example, file servers or Exchange Servers that serve as key players in your BizTalk solution should be clustered, as well. See “What to consider before deploying BizTalk Server 2002” for a more detailed discussion of BizTalk clustering.