Grouping BizTalk Servers for Performance
In addition to using separate database server machines, you can further increase the performance of a BizTalk installation by using multiple BizTalk Server machines, organized into a server group. All the machines in a server group share the same Messaging Management database and can share the processing workload for the same types of documents, through the same channels and ports. Also, to maximize the total throughput of a BizTalk server group, some servers can be configured to execute receive functions only (doing no document processing), whereas other servers can be configured exclusively for document processing.
BizTalk Server Groups
How are individual BizTalk servers combined into a server group, and how does each server know to which group it belongs? To begin with, a BizTalk Messaging Management database stores server group properties and membership—in addition to its function of defining organizations, ports, channels, and other BizTalk Messaging objects. Actually, one Messaging Management database can be used by more than one server group. However, keep in mind that there is only one namespace for the BizTalk Messaging objects defined in a Messaging Management database. Therefore, if you share a database among server groups, you must take care to avoid name collisions between objects used by different server groups.
The binding between BizTalk servers and databases—and vice versa—is by name, not by SID, GUID, or some other immutable identifier. Hence the bindings are easy to recon-figure. A Messaging Management database contains the names of one or more BizTalk server groups, and the names of the member servers of each group. Conversely, when a server is added to a server group (whether during installation or afterward), values under the registry key HKEY_LOCAL_MACHINESOFTWAREMicrosoftBizTalk Server1.0 Administrationare set to tell the BizTalk server how to connect to its Messaging Management database. Thus there is a two-way linkage between individual servers and the Messaging Management database that defines its server group.
The registry linkage is also the reason that you can run BizTalk Server Administration on any server in the group and see the same server groups, servers, and configuration properties. If you start BizTalk Server Administration, right-click Microsoft BizTalk Server 2002, and choose Properties, you will see the server name and database name (from the Administration registry key) that connect the BizTalk server to its Messaging Management database. All other properties of the server and of its server group are contained within the database, not in the registry. We'll now examine the relationship of server groups and individual servers, and see how the grouped servers cooperate to increase the performance of BizTalk Server document processing.
Creating BizTalk Server Groups
For the first BizTalk server you install, you must create a new Messaging Management database and a new server group (see Figure 21.1). During subsequent installations on the same network, you have the option of creating a new server group or joining an existing group. The first step to joining a group of servers is to choose the existing Messaging Management database (see Figure 21.2). Then you have the chance to join an existing server group at a later stage in the installation.
Figure 21.1. Creating a new server group during installation.
Figure 21.2. Choosing an existing database during installation.
It is also possible to add a BizTalk server to a server group after installation. Simply open BizTalk Server Administration; expand to the desired server group; right-click; and choose New, Server. Type in the name of the server to add (see Figure 21.3); sorry, there is no drop-down list of available servers.BizTalk Server must already be installed, and the BizTalk Messaging Service must be running, to add an existing server to a server group.
Figure 21.3. Adding a BizTalk server to a server group.
When you want to remove a BizTalk server from a server group, you must first right-click the server name and choose Stop to stop the BizTalk Messaging service on that machine. Then, to return any unfinished documents to the Work Queue so that another server in the group can process them, again right-click the name of the stopped server and choose All Tasks, Free Interchanges. You can then Delete the stopped server from the server group.
Properties of a BizTalk Server Group
In Figure 21.4, we open BizTalk Server Administration to examine the properties of the server group. Notice that all servers in the group use the same SMTP server and the same reply-URL for reliable messaging.Also, the refresh interval for Messaging Management objects is configured here for all servers in the group. If you are in production and are making only infrequent changes to Messaging Management, you could reduce the database load slightly by increasing the refresh interval to 5 or 10 minutes.
Figure 21.4. Server group properties, General tab.
In Figure 21.5 you see, as already noted, that the Tracking and Shared Queue databases are configured for the entire server group, not for individual servers. Therefore, all documents processed by servers in the server group are tracked in a single database.Even more important for performance scaling, any BizTalk server in the group can process documents stored in the Shared Queue database. In effect, grouping provides a simple form of load balancing across all the BizTalk servers in the group because each server will query for more documents to process whenever it becomes idle. This is an effective way to increase the total capacity of a BizTalk installation and is perhaps the most important reason for the existence of BizTalk server groups.
Figure 21.5. Server group properties, Connection tab.
Figure 21.6 illustrates the server group properties Tracking tab. On a production server in a high-traffic installation, you can disable all document tracking for the server group to improve database and network performance. If possible, you may want to use the Document Tracking database to troubleshoot messaging and processing problems. If necessary, host the tracking database on a dedicated SQL server and upgrade the server's processor, memory, disk, and network hardware as needed to achieve the required performance.
Figure 21.6. Server group properties, Tracking tab.
Figure 21.7 is the server group properties Parsers tab. Recall that BizTalk attempts to identify a document whose specification is not declared by the submission method. To do so, BizTalk must attempt to parse the document according to one of the known formats: XML, EDIFACT, ANSI X12, or flat file. To minimize time spent parsing unknown documents (and therefore improving performance), the call sequence on this tab should be configured to reflect the expected proportion of received document formats.
Figure 21.7. Server group properties, Parsers tab.
In a large-scale BizTalk installation, such as a national government department receiving documents from millions of submitters, it may make sense to create a separate server group for each parser type, placing that parser first in the call sequence for its dedicated server group.
Properties of an Individual BizTalk Server
The Properties dialog for an individual BizTalk server (see Figure 21.8) is far simpler than that for a server group. The more important properties are the check box for work-item processing and the number of worker threads per processor. Oddly, the default number of worker threads is 4, but the recommended number is from 15 to 20. Hence this is one property you should be sure to manually configure on all BizTalk servers.
Figure 21.8. Properties of an individual BizTalk server.
If you have several BizTalk servers in the server group, you have the option to separate the servers into document-receive servers and document-processing servers. Any individual server for which you uncheck the Participate in Work-Item Processing box will not query the Shared Queue database for documents and can dedicate all its resources to executing receive functions. Conversely, you can configure all the receive functions for the server group to run on document-receive BizTalk servers, so no resources on document-processing servers are used for initially receiving documents.
Easy to miss, but very important, is that each defined receive function runs on only one server in the BizTalk server group. The choice of server is specified on the Advanced tab on the Properties dialog of each receive function. Receive functions should be carefully distributed among the servers in the group. If there are document-receive servers in the group, they will fulfill the majority of the receive function workload. But some receive functions can still be configured to run on document-processing servers if it makes sense to do so. The performance monitoring techniques detailed in “Monitoring BizTalk Server for Performance” later in this chapter, will help you determine the optimal distribution of servers to execute receive functions.
The less-important properties of an individual BizTalk server are the number of receive function threads and the Shared Queue polling interval. Leave both these at their default values unless you have definite evidence (from performance monitoring) of delays that might be cured by changing their values.