Providing High Availability for BizTalk Hosts

BizTalk Server provides great flexibility for addressing high availability because you can strategically dedicate logical hosts to run specific areas of functionality such as receiving messages, sending messages or processing orchestrations.

A BizTalk host is a logical container within a BizTalk Server group that can house BizTalk Server items such as adapter handlers, receive locations (including pipelines), and orchestrations. You typically group items that have similar scaling requirements into a particular host. For example, you would group receive locations into a “receive” host, send ports into a “send” host, and orchestrations into an “processing” host.

After you create a host (a logical container), you can configure instances of the host to run on physical BizTalk Server computers in the BizTalk Server group. A host instance runs as a Windows Service on the designated BizTalk Server computer(s). Although it is not possible to run multiple instances of the same host on a given BizTalk Server computer, you can run multiple instances of a particular host by configuring instances of the host on separate BizTalk Server computers in a BizTalk Server group. You can also run multiple instances of different hosts on a single BizTalk Server computer.

Items that are contained in BizTalk hosts can perform the following functions:

• Receiving These items do the initial processing of messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location or pipeline, it acts as a security boundary, and the message decoding and decrypting occurs in a pipeline within the host.

• Sending These items do the final processing of messages before they are sent out to the send port. When a host contains a sending item, such as a send port or pipeline, the host acts as a security boundary, and the message signing and encryption occurs in a pipeline within the host.

• Processing These items process messages based on the instructions in an orchestration.

  Although a single BizTalk Host can contain items that receive, send, and process messages, it is considered a best practice to create different hosts for each function to create security boundaries and for easier management and scalability. In particular, we recommend that you use different hosts for processing and for receive/send operations, and that you separate trusted and non-trusted items.

  For example, if you receive one message, run an orchestration, and send ten messages, you want to separate the receive and send functionality into two separate hosts because the send items will have ten times more traffic than the receive items. If you receive one message, run an orchestration, and send one message, you can think of these items as a unit of work and group them into one single host. Alternatively, you can separate them into three different hosts to increase performance and flexibility.

  BizTalk hosts are one of two types, In-process or Isolated. In-process hosts run inside of the BizTalk Server runtime process whereas Isolated hosts do not run in the BizTalk Server runtime process. The following table lists the items that each of these host types may contain.

For more information about hosts and host instances, see Managing BizTalk Hosts and Host Instances.

To provide high availability for BizTalk hosts, you must have two or more host instances for each host in your environment (on two or more BizTalk Server computers). By having more than one host instance for each host you ensure that if one host instance becomes unavailable, the other computers that are running instances of that host can resume the functions of the problematic or failed host instance, and that the overall system can continue performing with minimal disruption.

Message Persistence

BizTalk Server relies heavily on SQL Server for high availability because every host involved in BizTalk Server persists messages to the BizTalk MessageBox database. For example, when BizTalk Server receives an incoming message, the receive host persists it to the MessageBox database before other hosts retrieve the message for orchestration processing and sending.

If your BizTalk Server solution involves orchestration, BizTalk Server routes the message to the host that executes the business process (processing host), and saves the message to the MessageBox database after the orchestration finishes. The sending host then retrieves the message from the MessageBox database before sending it to the external application through the appropriate send adapter.

Separating the Host and Database Functions

Because BizTalk Server separates the data from the hosts that process the data, one step that you can take to create a highly available environment is to separate the host functions (sending, receiving, and processing) that occur in BizTalk Server from the database functions that occur in SQL Server. By separating these functions, you can independently scale the processing, sending, and receiving hosts and the databases that store the data. The runtime and database layers are related, that is, if you increase the number of BizTalk Server computers you will likely need to increase the number of computers that are running SQL Server to handle the additional load. However, there is no direct relationship between the database layer and the BizTalk layer. They are two independent layers and you can scale them out separately.

What you must do to make the hosts highly available is different from what you must do to make the databases highly available. The following sections explain what you must do to make the receiving, sending, and processing hosts highly available. For more information about how to make the database layer highly available, see Providing High Availability for BizTalk Server Databases.

For deployments where BizTalk Server processes more than SQL Server processes, you can configure multiple BizTalk Server computers that use the same computer that is running SQL Server. This configuration uses the resources available on each computer. For example, if CPU or memory use runs high (more than 75 percent) on the BizTalk Server computer but runs low (less than 25 percent) on the computer that is running SQL Server, you can include additional BizTalk Server computers to distribute the workload while raising the resource utilization on the computer that is running SQL Server.

In This Section

• Scaled-Out Receiving Hosts

• Scaled-Out Processing Hosts

• Scaled-Out Sending Hosts

• Using Windows Server Cluster to Provide High Availability for BizTalk Server Hosts2

See Also

Providing High Availability for BizTalk Server Databases
High Availability for Enterprise Single Sign-On