As described on the
Microsoft BizTalk Server Overview page, “BizTalk Server is Microsoft’s Integration and connectivity server solution.” BizTalk Server provides a wide range of features designed to more easily connect disparate systems both inside and across organizations.
Because BizTalk Server is able to accommodate a vast array of integration and connectivity scenarios, and because the resultant solution(s) are very often deemed “mission critical”, it is of the utmost importance that sufficient time and resources are devoted
to planning the installation and deployment of your BizTalk Server solution. This document provides IT Professionals and Developers with advanced information for installing and deploying BizTalk Server including the following information:
The following users should read this guide:
This guide assumes that the reader is familiar with and understands the core concepts of BizTalk Server (version 2004 or later).
This document contains the following high level sections:
The following tasks should be completed to determine with edition of BizTalk Server is appropriate for meeting your business requirements. This section is divided into the following sub-sections:
Have all stakeholders agree upon and document a broad mission statement and detailed goals for the BizTalk solution. Business goals for a BizTalk Server solution can range from something as simple as
automating invoice processing between one or more trading partners to something as complex as developing an entire online banking system. For example, the following mission statement and business goals might summarize an online banking solution that is built
with BizTalk Server:
Provide clients with a secure web based banking system that allows clients to access their accounts and perform banking transactions such as transferring money between accounts, paying bills, and accessing
detailed account histories.
A mission statement and business requirements are invaluable for ensuring that the development, testing, and deployment of the BizTalk Server solution stay on task.
An architecture diagram should provide a graphical summary of message flows through the BizTalk Server solution including all components and features required to meet the solution goals. The architecture
diagram will be critical for evaluating which edition of BizTalk Server is appropriate for meeting your goals. The architecture diagram can include (but is not limited to) the following:
After determining the message flow and software components used by the solution, a diagram of the solution architecture should be created as a reference point.
Figure 1 – Example high level architecture diagram
A hardware diagram should provide a graphical summary of all hardware resources required for your BizTalk Server solution and should take into account the hardware necessary for achieving fault tolerance, high availability, scale up / scale out, security
boundaries, virtualization, and other factors that may be relevant to the solution. A high level hardware diagram illustrates the physical infrastructure that will be required for the solution. To help determine the hardware that will be required by the solution
consider the following:
Document processing throughput requirements - What are the document processing requirements of the BizTalk Server solution today and what will the processing requirements be in the future? If you anticipate adding additional trading partners,
or that your BizTalk Server application will be used to service additional clients (in a traditional client-server request-response architecture), then the Maximum Sustainable Throughput (MST) of the solution should be determined so that sufficient hardware
resources are available to meet peak load requirements. This is of particular significance if a Service Level Agreement for the BizTalk Server solution is in place. For more information about Maximum Sustainable Throughput of a BizTalk Server solution see
Engine Performance Characteristics (http://go.microsoft.com/fwlink/?LinkID=155771) in the BizTalk Server documentation.
Document tracking processing throughput requirements - The level of document tracking required by the solution can have a significant impact on the throughput of the solution. For example, some applications may require full message body
tracking, others may require only message property tracking, and yet others may require no tracking. For information about Planning for Tracking see
Planning for Tracking (http://go.microsoft.com/fwlink/?LinkId=186352) in the BizTalk Server 2009 Operations guide. Once the level of document tracking required by the solution is determined, the Maximum Sustainable Throughput with Tracking should also be
determined. For more information about Maximum Sustainable Throughput with Tracking see
Tracking Performance Characteristics (http://go.microsoft.com/fwlink/?LinkId=186346) in the BizTalk Server documentation.
Document processing availability requirements -
What are the availability requirements of the BizTalk Server solution? Does the solution require disaster recovery and / or high availability? Disaster recovery for the BizTalk Server databases can be accomplished using BizTalk log shipping. High
availability can be provided for the BizTalk Server databases, the Enterprise Single Sign-On Master Secret Server and BizTalk Server hosts with Windows Server failover clustering. High availability can also be provided for BizTalk Server Hosts by simply adding
additional BizTalk Servers to a BizTalk Server group and then configuring instances of BizTalk Server hosts to run on multiple BizTalk Servers.
Note: BizTalk host cluster support is available to provide high availability for particular BizTalk adapters for which running multiple instances of the adapter simultaneously is not feasible. Host cluster support
is also available to provide high availability for running a single instance of an adapter for purposes of ordered delivery. For more information about why you would want to run certain BizTalk Server adapters in a clustered host see
Considerations for Running Adapter Handlers within a Clustered Host (http://go.microsoft.com/fwlink/?LinkID=151284). For more information about BizTalk Server availability requirements see Determine High Availability and Fault Tolerance requirements below.
Determine if virtualization is a viable platform for the BizTalk Server solution -
Deployment onto a Windows Server Hyper-V virtualized environment offers many advantages but does exact a performance penalty. Running BizTalk Server on virtual machines in a Windows Server Hyper-V environment is fully supported for production and may
be worth consideration for your BizTalk Server solution. For information about deploying your BizTalk Server solution into a Hyper-V environment see
Considerations for deploying BizTalk Server into a Hyper-V environment.
After determining the throughput requirements, availability requirements, and whether or not virtualization will be used for the solution, a diagram of the physical infrastructure should be created as a reference point.
Figure 2 – Example high level hardware diagram
Once the high level architecture and hardware diagrams are created then it is a fairly straightforward task to determine which edition of BizTalk Server is appropriate for your BizTalk Server environment. The table below summarizes the primary scenarios
for each of the available BizTalk Server editions:
Designed for customers with enterprise level requirements for high volume, reliability, and availability. Enterprise Edition supports the following functionality:
Designed for businesses with moderate volume and deployment scale requirements.
Note: BizTalk Standard Edition is not supported for native 64-bit execution.
Standard Edition supports BizTalk Server database disaster recovery using BizTalk Server Log Shipping but does not support other enterprise-level features available with BizTalk Server Enterprise Edition such as:
Specialty version of BizTalk Server designed for hub and spoke deployment scenarios including RFID.
For more information about the capabilities of the various editions of BizTalk Server see
Microsoft BizTalk Server Editions (http://go.microsoft.com/fwlink/?LinkID=185239) and the
Microsoft BizTalk Server Pricing and Licensing FAQ (http://go.microsoft.com/fwlink/?LinkId=187281).
High availability is implemented in a BizTalk Server environment by providing redundancy for key functional components. The key functional components of a BizTalk Server environment for which redundancy can be implemented include:
BizTalk Server Hosts
Redundancy for BizTalk Server hosts can be accomplished using either of the following methods:
Unless your architecture requires high availability for certain adapter send or receive handlers it is recommended that redundancy for BizTalk Server hosts is accomplished by configuring instances of a host to run on more than one BizTalk Server in the group
as opposed to clustering the hosts. The reasons for this approach are:
Therefore, the only times that BizTalk Server hosts should be clustered are:
Note: While this article focuses on BizTalk Server 2006, the same concepts apply to subsequent versions of BizTalk Server, including BizTalk Server 2006 R2, BizTalk Server 2009, and BizTalk Server 2010.
BizTalk SQL Server databases
Disaster Recovery and / or High Availability for the BizTalk Server databases in SQL Server can be accomplished as follows:
Enterprise Single Sign-On Service
High availability for the Enterprise Single Sign-On Service is provided through Windows Server 2008 failover clustering. For more information about providing high availability for the Enterprise Single Sign-On Service see
How to Cluster the Master Secret Server (http://go.microsoft.com/fwlink/?LinkID=184009) and the
Improving Fault Tolerance in BizTalk Server by Using a Windows Server Cluster (http://go.microsoft.com/fwlink/?LinkID=144722) whitepaper.
Because BizTalk Server solution requirements can vary greatly depending on the business requirements of the solution there is no simple answer for establishing sizing guidelines. The best way to determine sizing requirements is to:
It is important to have a clear and concise record of milestones for installing, developing, testing and deploying the solution. Setting specific milestones will increase the likelihood that the project will be completed in a timely manner. Consider creating
a Visio timeline to visually represent dates, milestones, and tasks associated with the BizTalk Server solution. Keep the timeline simple enough to be easily understood yet detailed enough to communicate milestones effectively. The actual milestones should
be agreed upon by all stakeholders and reviewed regularly. A sample Visio timeline is displayed below:
Figure 3 – Example Visio timeline
Important: This example timeline will very likely not be representative of a given BizTalk Server installation and deployment. For very simple, small scale/single server scenarios a BizTalk Server solution may be
installed and deployed in one or two days whereas complex, large scale/multi server scenarios with custom code may require several weeks.
Note: For more information about how to create a timeline using Visio 2007, see the article
Create project timelines in Visio 2007 (http://go.microsoft.com/fwlink/?LinkId=119395).
BizTalk Server is an extremely database-intensive application that may require the creation of up to 13 databases in SQL Server. Because one of the primary design goals of BizTalk Server is to ensure that no messages are lost, BizTalk Server persists data
to disk with great frequency and furthermore, does so within the context of an MSDTC transaction. Therefore, database performance is paramount to the overall performance of any BizTalk Server solution. To ensure that the SQL Server instance used to house the
BizTalk Server databases provides optimal performance, consider performing the following steps:
Note: If you configure multiple MessageBox databases in your environment you should create a minimum of three MessageBox databases for your BizTalk Server group and you should disable message publication on the
master MessageBox database. This recommendation is made because adding additional MessageBox databases incurs overhead by the master MessageBox database for routing messages between the MessageBox databases. If you only configure two MessageBox databases then
most of the benefit gained by the additional MessageBox database is offset by the overhead consumed by the master MessageBox database for message routing.
BizTalk Server solutions are developed using Visual Studio 2008, which provides integration with the BizTalk project system to create all or part of a BizTalk Server application. BizTalk projects are comprised of one or more of the following BizTalk artifacts:
By using virtualization to host the BizTalk Server developer environment, a preconfigured BizTalk Server development environment can be prepared on a virtual hard disk and sent to each developer. Then the developers can simply rename the virtual machine
and perform the final BizTalk configuration steps to be up and running in significantly less time than if they had to install BizTalk Server prerequisites and BizTalk Server from scratch. For more information about using virtualization to host the BizTalk
Server developer environment see
Using virtualization to Host the BizTalk Server Developer Environment (http://go.microsoft.com/fwlink/?LinkId=187981). The “Sysprep a BizTalk Server VHD” SDK sample can be used to sysprep a BizTalk Server image as described in the BizTalk Server documentation
at Sysprep a BizTalk Server VHD (BizTalk Server Sample) (http://go.microsoft.com/fwlink/?LinkId=187984).
In addition to the BizTalk Server Development documentation (http://go.microsoft.com/fwlink/?LinkId=187992), the following references are excellent resources that should be utilized when developing
a BizTalk Server solution:
All too often, testing of a BizTalk Server solution is thought of as unnecessary overhead or is almost treated as an afterthought, which can have disastrous consequences. Because BizTalk Server solutions are frequently deployed in mission-critical scenarios,
it is of paramount importance that sufficient time is allocated for build verification testing, functional testing, and automated load testing. To ensure that testing is performed accurately, it is highly recommended that automated testing of the solution
is implemented whenever possible. For specific information about implementing automated testing of a BizTalk Server solution using BizUnit 3.0, see
Implementing Automated Testing (http://go.microsoft.com/fwlink/?LinkId=187990) in the Microsoft BizTalk Server 2009 Performance Optimizations Guide.
For information about load testing a BizTalk Server solution see
BizTalk Server Performance Testing Methodology (http://go.microsoft.com/fwlink/?LinkId=187858) in the BizTalk Server 2009 Performance Optimizations guide. To quickly determine the performance characteristics of your BizTalk Server solution consider downloading
the BizTalk Benchmark Wizard (http://go.microsoft.com/fwlink/?LinkId=186347) and running it against your BizTalk Server environment. The BizTalk Benchmark Wizard tool is an excellent tool for quickly
determining if your BizTalk Server environment can handle a “production” load so that you can make the necessary adjustments to your environment before putting the system into production.
Hardware advancements such as multi-core processors and AMD-V / Intel VT provide enhanced support for virtualization technology and Microsoft Hyper-V is designed to take full advantage of these hardware advancements. As a result, the performance gap between
virtual machines and physical hardware is quickly closing and an increasing number of companies are deploying software solutions into production on virtual machines.
Deploying your BizTalk Server solution to run on a Hyper-V virtualized environment provides the following flexibility and functionality:
For detailed information about whether or not deploying your BizTalk Server solution into a Hyper-V environment is a viable option see the
BizTalk Server 2009 Hyper-V Guide (http://go.microsoft.com/fwlink/?LinkID=151834). The BizTalk Server 2009 Hyper-V Guide includes lab testing results that compare the performance of a BizTalk Server
application running on physical hardware to the performance of the same application running on Hyper-V virtual machines.
For a comprehensive listing of tasks that relate to maintaining a production BizTalk Server environment see
Maintaining BizTalk Server (http://go.microsoft.com/fwlink/?LinkId=188017) in the Microsoft BizTalk Server 2009 Operations Guide or
Microsoft BizTalk Server 2010 Operations Guide. Managing BizTalk can be done with the out of the box
Administration Console, which focuses on BizTalk Group itself, managing applications, adapters, etcetera and for troubleshooting purposes. For monitoring
System Center Operation Manager or alternative solutions mentioned in
BizTalk Monitoring Tools.
For information about scaling a BizTalk Server solution see
Scaling Your Solutions (http://go.microsoft.com/fwlink/?LinkID=158078) in the BizTalk Server 2009 core documentation.
Adding an anchor tag to an entire subtitle (or any highlighted text) seems to turn it into a "go nowhere" link.
Great article wished I read it earlier.
Trace, I updated some of content towards 2010.
Great article Trace, you seem to have covered prretty much everything, very good! Thumbs up!
I am impressed. I can use this as my reference for my next project implementation.
Just one word: Wow!
Great article1 For the Sizing Guidelines, does anyone have any established metrics based on the factors listed in the guidelines? For example, what size of virtual server (CPU, memory) is required if there are 100 large (200 mb) messages running concurrently?