BizTalk Server 2006 - Enterprise Production Considerations - Part 2 - Host and Host Instances

  • Article

I've seen one too many BizTalk groups with poorly configured Host/Host Instances. So I've decided to create a BASIC post on the subject. This is a pretty sophisticated topic having to do with scaling, high availability, resource management etc. so please don't assume that what I'm about to say is universally appropriate. I'll give a few suggestions and more importantly, I'll give the reasons behind those suggestions which should give you the background you need to create your own configuration wisely.

Suggested Starting Point

  1. Enable "Allow host tracking" on the default in-process BizTalk Application Host
    1. Do NOT enable "Allow host tracking" on any other Host
      Confirm with the BTS docs if you like, but only one host has to have this enabled
    2. Do not use this host for any ports or orchestrations, this is dedicated for host tracking
  2. Create at least 3 in-process hosts for each logical application that you have. (Use at least 2 hosts if you are not using any orchestrations)
    1. One for Send Operations [Bind your send points to this host]
    2. One for Receive Operations [Bind your receive ports to this host, except HTTP or SOAP]
    3. One for Processing [Bind your orchestrations to this host, if you have any]
    4. A case by case examination can be made here for additional hosts, usually for:
      1. High volume orchestrations or those you wish to have granular control over. These get a dedicated host
      2. Out of process hosts for HTTP/SOAP/Custom protocols . These get additional Hosts/Instances

Application Isolation
Having separate hosts for your applications allows you to restart the host instances for that application (perhaps because of a re-deployment) without interrupting the other apps.

Scaling Out
Having a host for Send/Receive/Process allows you to distribute your application accross several servers in your BizTalk group in a flexible manner. You can increase the number of host instances running to "beef up" any combination of these three types of operations as required.

Memory Utilization
As you well know, 32 bit systems have limits regarding how much memory can be used by a single host (process). A single host on a 32GB system will really only use about 1.8GB - 2GB or so. If you want to take full advantage of all of that juicy memory you'll have to create more host instances and let each of them take their 2GB bites out of it. (As a rule of thumb, be sure to leave 4GB for the OS). This is not universally true (i.e. 64bit systems are different)

High Availability
Have at least two host instances running for every host that you have. This way, any single node can fail and the other node will continue to operate. This can become more complicated for Receive nodes so check the HA configuration for whatever adapter types you have running. For instance, FTP does not support locking so having two host instances reading from it can cause duplicate messages. This has to have just one host instance reading from with (which I tend to call a "Singleton" adapter configuration). In this case there is one host that is clustered for high availability

Security
You may also need to create additional hosts so that you can use different credentials to access different systems. The security context is determined by the Host/Instance which can be very helpful in scenarios that are using AD to authenticate your requested operations. (i.e. File Adapter, SQL Adapter, and I believe the MS CRM adapter, among others)

Some Caveats

  1. Too many hosts.
    1. My BizTalk groups seldom have more than 22 hosts or so (7 apps + default host for tracking) So if you begin to experience problems with Groups having more hosts than that I recommend you consider too many hosts as a possible cause. There could be RAM availability issues at these levels.
    2. Configurations in BTSNTsvc.exe.config may give you weird results because you may be assuming that they apply to the whole group, when really they apply to the host instances
    3. Again, in the BTSNTsvc.exe.config, the changes in this file are picked up when the host instance restarts. You may have changed the configurations, restarted only a handful of your hosts. Later down the road, you restart other host instances that then begin to have problems because of the contents of the BTSNTsvc.exe.config. This is VERY hard to trouble shoot and I have two recommendations.
      1. Don't change BTSNTsvc.exe.config unless you absolutely MUST.
      2. If you change BTSNTsvc.exe.config restart ALL of your host instances immediately so you can quantify the affect of the changes immediately.
  2. Single Box groups
    1. If you're running BizTalk all on one box then it hardly helps you to be able to partition out the operations. In this case, I would just create one host per application so you can still have Application Isolation, without worrying about the scale out features or HA (which you can't really use with just one box anyways)

Agree, Disagree, Don't Care? Please comment below