Host:

The BizTalk Host object represents a logical set of zero or more runtime processes in which you can deploy services e.g. adapters, pipelines, and other artifacts. The Host object also represents a collection of runtime instances (zero or more) where the deployed items physically run.

After you create a host (a logical container), you can add physical BizTalk servers (BizTalk host instances) to the host.

Items—such as adapter handlers, receive locations (including pipelines), and orchestrations—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.

There are following two types of default BizTalk Host as below:

1.      In-process Hosts

In-process hosts represent service instances that an administrator creates, deletes, and fully controls with Windows Management Instrumentation (WMI) and the BizTalk Administration Console.

Windows Management Instrumentation (WMI) is the infrastructure for management data and operations on Windows-based operating systems.

In-process hosts have the following characteristics:

• You can enlist any orchestration into an in-process host.
• An in-process host can host any send handler.
• An in-process host can host any of the receive handlers except for SOAP and HTTP:
• The first in-process host you create in a BizTalk Server deployment is the default host and you cannot delete it. The BizTalk Message Queuing adapter uses the default host for static handler configuration. Adding an adapter automatically creates receive and send ports for the default host.

2.      Isolated Hosts

Isolated hosts represent service instances that a solutions developer programmatically creates, deletes, and controls. An administrator uses WMI and the BizTalk Administration Console to configure these hosts (for example, to configure the host service account and authentication trust).

Isolated hosts primarily host adapters that must run outside of the normal BizTalk Server runtime process. For example, you use isolated hosts to host adapters for external processes such as ISAPI extensions and ASP.NET.

Isolated hosts have the following characteristics:

• You cannot enlist orchestrations into an isolated host.
• An isolated host cannot host send handlers.
• An isolated host can host only the receive handlers associated with HTTP/S and SOAP adapters (the isolated-type adapters).
• An isolated host cannot host tracking.
• An isolated host cannot be the default host.
• The status of an isolated host is always Status Unavailable. BizTalk Server does not access the status information for external processes.

3.Trusted and Untrusted Hosts

BizTalk Server enables hosts identified as authentication trusted to indicate that the sender of a message that the trusted host is queuing to the MessageBox database is an entity other than the trusted host itself. The primary purposes of authentication trust are to enable pipelines to resolve to a Product ID (PID) and pass that PID along to consuming services for use in authorization and outbound party resolution, and to enable the transmission of the sender Windows Security ID (SSID) along to consuming services for use in orchestration action authorization.

Host Architecture

The hosts are set in the database and creates corresponding tables and rows in the BizTalk databases so the host instances can process data. For the servers you create host instances, these instances perform jobs, either orchestrating, receiving files or sending them out. A host instance also performs the job to moves tracking data from the message box to the tracking database.

A host serves two functions: one is logically grouping the BizTalk Server items so these items can be assigned to different BizTalk Server processes, and the other is controlling security. You need to specify a Windows group for a host. Only the users in this group can send documents to the adapters hosted by the host instances assigned to this host.

Hosts have the following characteristics:

• Hosts are the logical containers of BizTalk Server objects.
• Only one instance of a specific host can exist on each server.
• You can map one host to multiple servers.

Host instances have the following characteristics:

• BizTalk Host instances are the physical containers of BizTalk Server objects.
• You create a host instance when you map a server to a host.
• Multiple host instances (of different hosts) can exist on a server when load balancing or for failover.
• The following figure shows the relationship between servers, hosts, and host instances.

Best practice for creating Hosts

One BizTalk Host can contain items that receive, send, and process messages. It is recommended that you create different hosts for each function to create security boundaries and facilitate management. It is recommended that you use different hosts for processing and for receive/send, and that you separate trusted and non-trusted items. You can increase number of hosts based on requirement and applications. But at least below four BizTalk hosts should be minimum configure as per best practices.

1.      Send Hosts

Create BizTalk host for Send adapters only.  Dedicated send hosts are hosts primarily dedicated to sending out information from BizTalk. By creating dedicated send hosts, you can easily filter these from the host instances. Limiting or granting extra usage of server resources if this host send out many files after a de-batch etc. This host should NOT have the option “Allow host tracking” turned on, since this host should not move tracking data from the message box to the tracking database. Send Host example as below.

2.      Receive Host

The same goes for the dedicated receive hosts. Create BizTalk host for Receive adapters only.  By limiting this host to only receive information for BizTalk you can also change the throttling settings and threshold for this host to fit it better for traffic going through it. This host should NOT have the option “Allow host tracking” turned on, since this host should not move tracking data from the message box to the tracking database. Receive Host example as below.

3.      Orchestration Host

Create BizTalk host for Orchestrations only. Dedicated orchestration host should only be run for orchestration. Same goes for this one as for the two above. Altering settings and setting thresholds dedicated for this host and its purpose. This host should NOT have the option “Allow host tracking” turned on, since this host should not move tracking data from the message box to the tracking database. Orchestration Host example as below

4.      Tracking Host

This host however is maybe one of the more important once. It is the host dedicated to move tracking data from the message box to the tracking database. This host however should have the option “Allow host tracking” checked. And should never run any receive location, orchestration or send ports. It should primarily only move tracking from the message box to the tracking database. You can use default BizTalk host for the same. No need to create separate BizTalk host for tracking. But while using BizTalk default host for tracking , so be caution for set up for receive handler , send handler & Orchestration host should not be this host.

Host Instances

A host instance is the physical installation of a host in a BizTalk Server. An administrator uses Windows Management Instrumentation (WMI) or the BizTalk Administration Console to install host instances. A BizTalk Server can support multiple host instances.

The BizTalk Host is a logical process and security boundary within BizTalk Server that represents a logical set of zero or more run-time processes in which you can deploy BizTalk Server services and artifacts (such as adapter handlers, receive locations, and orchestrations). Each host has a security group assigned to it and may contain multiple host instances, each on an individual machine, that perform the work of the host.

In another hand, a host instance is the physical instance of a host on a computer running BizTalk Server. Each host instance belongs to exactly one host, and the service account of the host instance belongs to the security group of the host. The security group may be used to grant permissions to physical resources such as databases for use by any host instances in the host.

How to Create a BizTalk Server Hosting Environment

Before you create your BizTalk Server hosting environment, consider the following recommendations:

1.      Use SQL Server clustering

To provide high availability of the BizTalk Server databases, we recommend that you cluster the SQL servers where the BizTalk Server databases are stored. This will help minimize downtime if one of the databases or SQL Server fails. 

2.      Limit the database and log size in the BizTalk Server databases

The BizTalk MessageBox databases and the BizTalk Tracking database grow much faster than the other BizTalk Server databases. As part of your backup and maintenance program, you should update these databases frequently.

By default, the tables in the BizTalk Server databases do not have a log size limit. As part of your backup and maintenance program, we recommend that you limit the log size to prevent the logs from becoming too large and potentially using all the disk space. For information about managing the size of tracking database, see Archiving and Purging the BizTalk Tracking Database.

3.      Use different hosts for trusted and non-trusted orchestrations and receive handlers

Any items running in a host (for example, orchestrations, pipelines, receive and send handlers) run under the same identity, and have access to the work and suspended queues for that host.

If a message cannot be delivered to an orchestration due to permission errors, the message is placed in the suspended queue of the host where the sending process (a receive pipeline or another orchestration) is running. However, if the orchestration and the sending process (for example, a receive pipeline) are running in the same host, the orchestration can still access the message in the suspended queue. This could potentially compromise your system if a non-trusted orchestration is running in a trusted host.

We recommend that you run non-trusted orchestrations in a separate host, with a different service account than the trusted hosts in your BizTalk group. For information about designating a host as trusted, see How to Modify Host Properties.

Benefit & best practices for configuring multiple BizTalk hosts/host instances

A good Host separation policy recommend using separate hosts for processing, receiving, and sending messages, and use separate hosts for trusted and non-trusted items to facilitate implementing security measures and to improve manageability of the hosts. You can install only one instance of a host per BizTalk server. it is recommended to start any BizTalk environment with at least four hosts.

1. Receiving
2. Orchestrations
3. Sending
4. Tracking

Benefits:

• it will be easier to configure scalability and easier to control the behavior such as stopping all receives to enable an environment drain.
• host separation technique is to have a dedicated tracking host, since tracking is a low priority sub-service if you have tracking in a very busy host it might start accumulating tracking information on the BizTalk Message Box.
• Isolating artifacts with different security requirements are also reason for host separation, you can assign different Windows Groups, Users and certificates to each host creating security boundaries which will reduce the risk of running them in the same environment as other artifacts which increases the return on investment you have done in BizTalk.
• You can also separate hosts for security and reliability reasons, since each host has its own set of dedicated resources such as database tables and windows services you can separate artifacts or applications that have high performance requirements that will benefit from these additional resources
• If you have some unreliable artifact you can also use host separation for reducing the impact of such component (Custom Adapter, Pipeline, etc.) since if that host instance crashes it won’t affect anything else.

Disadvantages of Additional Hosts

While there are benefits of creating additional host instances, there are also potential drawbacks if too many host instances are created. Each host instance is a Windows service (BTSNTSvc.exe or BTSNTSvc64.exe), which generates additional load against the MessageBox database and consumes computer resources, such as CPU, memory, and threads. Other than these, you have the following reasons for not configuring too many additional host instances:

• Several performance counters are reported per host with too much granularity. This affects the usability for the administrator who would need to traverse through a lot of data. This has a negative impact on the overall view the administrator has.
• Each host consumes considerable amount of memory that might lead to a situation of throttling and reduced performance.
• If the hosts have received adapters that continuously perform polling, each host will poll the database at short intervals, thereby resulting in degraded performance.

References:

• Create a New Host: https://docs.microsoft.com/en-us/biztalk/core/how-to-create-a-new-host
• https://www.biztalk360.com/blog/biztalk-server-tip-2-efficient-host-separation/
• https://docs.microsoft.com/en-us/biztalk/technical-guides/high-availability-for-biztalk-hosts
• https://social.technet.microsoft.com/wiki/contents/articles/7027.biztalk-server-host-architecture.aspx
• https://docs.microsoft.com/en-us/biztalk/core/managing-biztalk-hosts-and-host-instances

How to create multiple host instances on different servers?