The obvious resource is MSDN. There is a section called High Activity Planning that covers most of the concepts and gives you the right terminology to then search for other resources on the Internet. As with many Microsoft server products, MSDN also has many white papers on specific BizTalk scenarios.
BizTalk's best books also have a section on load balancing concepts (such as Professional BizTalk Server 2006).
In addition, there are several key concepts that may prove useful, especially regarding the use of terminology (some of the use of BizTalk may be misleading).
Load balancing
BizTalk Server is a load balanced architecture. This means that if you have multiple BizTalk hosts connecting to the MessageBox database, the messages in the database will be evenly distributed between the nodes participating in the BizTalk group. (with reservations about the fact that BizTalk Processess has been configured to run on each host).
There is also the concept of network load balancing, which is Microsoft's network load balancing service or any equivalent service. In BizTalk, this is used at the web level to accept adapters using the HTTP protocol (for example, an HTTP adapter, a SOAP adapter, and WCF HTTP adapters). This load balancing is not really a BizTalk service, but a load balancing layer that is provided in addition to the BizTalk stand-alone adapters to ensure high availability of web resources. It is configured just like any other NLB service.
Clustering
When clustering is mentioned in BizTalk, it is used to indicate one of two things - SQL-level clustering to provide high availability and fault tolerance and clustering of BizTalk clusters.
SQL Clustering is a simple (although not easy to do, just say) issue of providing a cluster of SQL Server that runs BizTalk databases, which enables database fault tolerance. This is not a specific BizTalk technology.
BizTalk Host clustering - in this case, the BizTalk Server is marked as clustered when it is created inside BizTalk. This is a special BizTalk parameter, which essentially states that one and only one host instance will run at a time, and that by extension all the resources of this host will also have only one instance. It is primarily intended for use by adapters, such as FTP and MSMQ adapters, which behave incorrectly when more than what is allowed to run at the same time.
This change refers to the OP comment, which contains additional information. Hope this makes things clearer. If you have additional questions about the features, I can answer them, but that pretty much exhausts my theoretical knowledge about the configuration of the high availability configuration. I am primarily a BizTalk developer and solution designer, when it comes to network subtleties, there are people I work for who fill out the detailed details and implementation of these projects.
Network Load Balancing for HTTP Adapters
The key point I tried to express here was that network load balancing in the BizTalk context is no different for any other network load balancing scenario.
BizTalk has two types of hosts: In Process and Isolated. Process hosts have separate BizTalk services running on servers (with one host instance per server). Individual nodes are actually delegated to a Web server (IIS) that processes all HTTP adapters (HTTP adapter and SOAP adapter plus specific configurations for the WCF adapter).
When you introduce network load balancing in the BizTalk environment, what you do is intoducing at the web server level for isolated host adapters hosted on the hosting.
Here is the MSDN page for introducing MSDN documentation , with a specific FTP adapter.
For most integrated BizTalk adapters, high availability can be achieved by creating multiple handler adapters to run instances on the BizTalk node on different BizTalk servers in the BizTalk group. FTP adapter receivers should not, however, be configured to operate on multiple BizTalk site Nodes at the same time. This recommendation is made because the FTP receive adapter uses the FTP protocol to extract files from the target system and the FTP protocol does not block files so that multiple copies of the same file are not extracted at the same time when starting multiple FTP instances we accept the adapter.
As the saying goes, the FTP adapter uses the FTP protocol, which does not block files. Since BizTalk is initially a highly parallel system, if you allowed multiple BizTalk hosts to host an instance of an FTP adapter, you will receive multiple copies of the same FTP message received on your BizTalk system. This BizTalk clustering ensures that any BizTalk clustered host will run on host node 1 and only 1 . By placing the FTP receive handler inside the clusterd host, you will verify that:
- you will always have an FTP adapter running if the BizTalk host is running
- You will never have more than one FTP adapter running.
Additionally, you can use the BizTalk cluster node to reduce system load. For example, the BizTalk SQL adapter receives the location configured for polling, will poll all host instances. Although this does not necessarily lead to multiple instances of messages, it may overload the SQL server that you polled, or even create deadlock scripts depending on the design of the called stored procedure, so clustering the SQL adapter receive handler may be a good idea.