BizTalk health check part 2

Posted: September 20, 2011  |  Categories: Biztalk BizTalk Adminsitration Uncategorized Useful tips
Tags:
In my first post you could read about the health check around network and updates provided by Microsoft and other manufactures, IBM, HP Dell and so on.
You can download the entire article as a PDF document.
BizTalk Health Check.
This part is more related to how to health check BizTalk itself. How to set it up correctly.

The Host separation policy
BizTalk solutions typically consist of executable artifacts – receive locations, pipelines, orchestrations, send ports, and so on. BizTalk hosts provides a way to logically group these artifacts and allow you to instance each host on one or more BizTalk Servers. A Host instance represents a physical run time windows service or process running on a BizTalk. This gives you a very flexible solution to host BizTalk application components, there are many factors which should be taken into account when distributing your applications across hosts.

 

-Performance

  • When you create a new host a set of dedicated databases tables is provisioned in the BizTalk databases. In the BizTalkMsgBoxDB they act as the work queues for that host. This can help to gain low latency situations by creating multiple queues for different workloads, thus presenting messages with low latency requirements getting delayed behind large batches of none “time-critical messages”.
  • Each host instance has its own set of system resources such as memory threads and handles in the .NET thread pool. Instead of hosting all executable artifacts in a single host i can be beneficial to spread the load across multiple hosts.

 

  • BizTalk throttling is implemented on the host level. You may experience that you need to set a specific throttling parameter in order to control individual artifacts. If you need to do this I would recommend you to separate artifacts across different hosts so that you don’t apply unnecessary throttling to all artifacts.

– Functionality

Its recommended to separate reviving, orchestration, sending and tracking functionality into separate hosts. This will help you to manage and scale each type of processing independently. IF you want to stop all reviving or all orchestration processing. Or adding additional servers to the BizTalk group to handle dedicated orchestration processing only.

You should also have hosts for application that only can run on one server, POP3, FTP, MSMQ receive. These hosts should be grouped and clustered in the BizTalk console· All others can remain in hosts which supports multiple running host instances.

Separation application processing across hosts ultimately leads to a multiple runtime processes hosting you applications. As BizTalk can host custom written components (all custom components you have), host separation can be used to provide process isolation and protection. If you experience instability in any custom components, you should isolate them into their own BizTalk host. This should be done to prevent the instability to affect other applications.

– Security
Each BizTalk host is assigned to a windows group which is used to give the host permission to specific tables in the BizTalk database. This is important when dealing with highly sensitive data.

Certificates can be utilized in BizTalk for message signing and encryption. This settings is assigned in the host level and therefore you may need to separate hosts in order to represent different identities.

All host instances are assigned wit ha service account to run under. Access to external systems is often a requirement for this account in order to process outbound messages through the adapters.

You can download the entire article as a PDF document.
BizTalk Health Check.

Set up a dedicated tracking host
Any hosts that hosts tracking is responsible for moving the DTA and BAM tracking data from the MessageBox database to the BizTalk Tracking (DTA) and BAM Primary Import databases. The moment of tracking data has an impact on the performances of other BizTalk artifacts running on the same host that is hosting tracking. Therefor you should have a dedicated host that does nothing but tracking.

To use a dedicated host for tracking also allows you to stop other hosts without interfering with the BizTalk server tracking. The movement of tracking data out of the MessageBox database is critical for healthy systems. IF the BizTalk host is responsible for moving the tracking data in the BizTalk group is stopped, the Tracking data decode service will not run. Impacts of this is:

HAT tracking data will not be moved from the MessageBox to the BizTalk Tracking database. Same goes for BAM tracking data, this will not be moved to BAM Primary Import database.

  • Because data is not moved, it cannot be deleted from the BizTalkMsgBoxDb.
  • When the tracking data decode service is stopped, tracking interceptors will still write tracking data to the MessageBox database. IF the data is not moved, this will cause the MessageBox database to become enormous. which will impact performance over time.
  • It is also important for security to have a dedicated tracking host, since the tracking host has access to all the messages across the message box database.
  • Turn of tracking on all other hosts, they will still write tracking but they wont have read access.

Isolated Adapter per Application Pool
An application pool which hosts an isolated adapter represents the physical implementation of an isolated host instance. This means that the application pool (w3wp.exe process) becomes an instance of BizTalk because the isolated adapter loads the BizTalk runtime components into the process to perform message processing. BizTalk only supports a single isolated adapter per application pool.

Remove unnecessary BizTalk items, components and settings
It is important to keep a clean environment. Remove old receive locations, send ports and applications that are no longer in use. Artifacts which only were used during testing and development should be removed. The output from the BizTalk Documenter tool can be used for this.

The BizTalk configuration file
BizTalk runtime process is like other .NET applications and have configuration files that can be used to control certain application behaviors. They control runtime validation, orchestration dehydration and provide custom application settings for custom .NET components hosted in BizTalk

BizTalk Registry Key Validation
BizTalk stores a variety of configuration data in the windows registry. This data can have an impact on the behavior of the BizTalk runtime processes and associated services. There is one specific area area which is recommended to tune for the default registry values and these control the .NET thread pool used by BizTalk. You can find the values here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname\CLR Hosting

I will add more information in part 3 to 5. There is a lot to go trough and as said earlier, I don’t want to spoil it all by giving away everything immediately (plus there is a lot to read).

Read “BizTalk Health Check Part:” [1] [2] [3] [4] [5]

You can download the entire article as a PDF document.
BizTalk Health Check.
  • Steve Culshaw

    Excellent series of posts on BizTalk health

    Re. the host separation policy …
    – Ok, split over receiving, sending, etc.
    – but would you split further over each application?, i.e. different receive hosts for app1, app2, etc., send host for app1, app2, etc.

    I’m conscious that each host uses a chunk of memory, is accessing the SQL db, etc.

    Cheers,
    SteveC.

    PS. where can I get some of the reviving functionality “…to separate reviving …” 🙂

    • Tord Glad Nordahl

      So this is more like the best practice, in some cases things are done differently. So yeah, in some cases you might want to split more, but try to stay below 25 hosts in total (not host instances).

  • sumathi

    what is the calculation of server setup for biztalk large message process.
    ex. i want to process 1 GB of file.

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top