An application distribution topology defines the type, number, and configuration of server machines your application will run on. Usually, MTS-based application packages are developed in such a way that they can be deployed on any server machine. This location transparency is key to building scalable, reliable applications. Location-transparent packages can run on multiple server machines to handle additional load with no loss in performance. Packages can also be replicated across a cluster, to provide better reliability if a server machine fails. A cluster is a group of physical machines that acts as a single logical machine.
A topology is selected based on the existing corporate computing infrastructure and policies, results of performance tuning, and any implementation-specific constraints on location transparency. When choosing a topology, you need to consider the placement of system servers such as Microsoft SQL Server, Microsoft Message Queue Server (MSMQ), and Microsoft Internet Information Server (IIS), in addition to the placement of your application packages.
Most distributed applications will be deployed into an existing computing infrastructure, so certain aspects of the topology might be predetermined. For example, an application might use an existing database running on a dedicated database server machine. Corporate policy might dictate that applications cannot be installed on the database server machine. Therefore, you will need to deploy the application to another machine—and ensure that the appropriate communications protocols are in place, that connectivity exists between the machines, that the application can access the remote database with appropriate security credentials, and so on.
Corporate computing policies can also have a big impact when you are deploying applications that will be accessible to external users over the Internet. Typically, most server machines will run behind a firewall to prevent random external users from accessing confidential information. There might be multiple levels of firewalls, each with different restrictions on who can penetrate the firewall and what type of communication is permitted. You might be required to deploy Web servers, applications, and database servers behind different firewalls. And again, you'll need to ensure that appropriate communications protocols, physical connectivity, and security credentials are available between the machines.
If you are deploying an application that was developed in-house, integration issues like these should be documented in the application requirements, as discussed in Chapter 7, since these issues can have a substantial impact on the application's design. The application's physical design documentation might also contain suggestions for deploying the application based on known integration issues. If there are any implementation-specific constraints on how the application is deployed, these should also be documented in the physical design documentation, as discussed in Chapter 10.
Although the existing computing infrastructure and policies might impose some constraints on how you deploy your application, you will probably still have some leeway in defining the application distribution topology. The results of performance testing and tuning, as discussed in Chapter 13, can help you further refine your topology. For example, you might be able to meet your performance goals with a single server, as long as the server machine meets minimum processor speed, memory, and disk access speed requirements, or if the DBMS is configured in a particular way. Alternatively, during performance testing you might have found that you could meet your performance goals by scaling out—that is, running the application and database on separate machines, running the application on multiple machines, or even partitioning the database across multiple machines.
In this section, we'll look at some of the most common deployment configurations for MTS applications that use IIS and SQL Server. Most of the considerations mentioned here also apply to applications that do not use IIS.
In the first configuration, shown in Figure 14-1, IIS, SQL Server, and the MTS application are all installed on a single server machine, or node. All clients communicate with that server machine. This configuration is the most straightforward to deploy and administer. You have no special security issues or firewalls to worry about since the entire server application runs on the same machine.
Figure 14-1. Deploying the application to a single node.
Because there are no cross-machine calls between IIS, MTS, and SQL Server, performance will be good for individual clients. If the MTS application is configured to run in-process, performance will be even better. The trade-off is that in-process MTS applications do not participate in role-based security.
An additional trade-off is that this configuration can support only a limited number of users. Adding memory, high-performance storage devices, or processors to the machine will let you support more users, but at some point you will reach the limit of available hardware. Once this limit is reached, you will need to deploy the application on multiple machines in order to support additional users. Thus, the single-node configuration is most useful for applications with a small user load.
In the second configuration, IIS runs on one server machine and SQL Server and the MTS application run on a second server machine. Web clients communicate with the IIS server machine. This has the advantage of providing faster response for static pages and simple ASPs, since more machine resources can be dedicated to IIS. With two machines, the application can scale to larger numbers of users than in the single-machine case. And since MTS and SQL Server are running on the same machine, performance of data objects and business objects that use data objects should also be good.
This approach has some drawbacks, however. Calls from ASPs to MTS components are cross-machine calls, which are inherently slower than local calls and can cause performance bottlenecks. You might also run into difficulties if your server machines are on opposite sides of a firewall. Depending on the type of firewall separating the machines and on corporate policies regarding traffic through the firewall, configuring DCOM to work through the firewall can range from simple to impossible. You will have the most success with packet-filtering firewalls that permit you to specify which TCP ports should be opened.
Configuration 2 is useful for applications that consist primarily of static Web pages and simple ASPs, with limited use of MTS components and SQL Server databases. If the IIS server machine is not able to support the user load, the IIS site can be replicated to multiple machines and Domain Name Service (DNS) round-robin load balancing can be used to distribute client requests across the replicated server machines, as shown in Figure 14-2.
Figure 14-2. Using DNS round-robin load balancing to determine which IIS machine receives each client request.
DNS round-robin load balancing is an Internet standard that lets you use a single server name to refer to multiple physical machines. When a server name is referenced, the name is sent to a DNS name server for resolution into an IP address for one of the physical machines. The name server cycles through the list of physical machine IP addresses as resolution requests are received, thus balancing requests over all the machines.
A problem with this configuration is that all the IIS machines will be communicating with a single MTS/SQL Server machine, which will become a performance bottleneck as user load increases. Also, applications that store per-client state in ASP session variables will not work with DNS round-robin load balancing, since requests from one client machine are not guaranteed to be handled by the same server machine.
In the third configuration, IIS and the MTS application run on one server machine and SQL Server runs on a second server machine. Clients communicate with the IIS/MTS machine. Since there are no cross-machine calls between IIS and MTS, response time for Web pages and the components they use will be good. If security and process isolation are not required and the MTS application is configured to run in process, performance will be even better. The application can scale to support more clients than in the single-node configuration.
The drawback, of course, is that all calls to SQL Server are cross-machine calls. Since database calls typically involve a lot of disk I/O and data processing on the SQL Server machine, these calls will be fairly slow anyway (compared to a component method call), so the extra cost of making the call cross-machine might not cause any problems. You should verify that the cross-machine calls do not cause a bottleneck that prevents your application from achieving its performance requirements. You might also need to adjust the ODBC connection pool time-out to account for the longer connection setup time over the network.
As with configuration 2, you might run into difficulties if your server machines are on opposite sides of a firewall. As discussed in Chapter 13, you will see better performance by using TCP as the communications protocol for SQL Server. Here too, depending on the type of firewall separating the machines and on corporate policies regarding traffic through the firewall, configuring access to SQL Server through the firewall over TCP can range from simple to impossible. You will have the most success with packet-filtering firewalls that permit you to specify which TCP ports should be opened.
Configuration 3 is useful for applications with low to moderate user load that access existing databases running on dedicated servers or databases that must be isolated from the Internet. Applications that need to support higher user load might be able to use a variation of this configuration in which the IIS/MTS server is replicated on multiple server machines and DNS round-robin load balancing is used to distribute client requests across the replicated machines. Applications that maintain per-client state in ASP session variables or the MTS Shared Property Manager (SPM) will not work with DNS round-robin load balancing. In addition, since all database requests are directed to a single SQL Server machine, you will eventually reach a limit on the user load that can be supported.
Another variation of this configuration uses static load balancing. In this variation, the IIS/MTS server is replicated to multiple server machines, but instead of using DNS round-robin load balancing to select an arbitrary machine to handle each client request, each server machine has a unique name. Each client machine is configured to use a specific server machine for all its requests, as shown in Figure 14-3. This variation can become difficult to administer as the number of users increases because the system administrator must determine which server machine each client machine should use. However, it will work with applications that maintain per-client state in ASP session variables or the SPM.
Figure 14-3. Using static load balancing with SQL Server on a separate node.
At some point, any configuration that places your application or the databases it uses on a single server machine will not be able to handle all user requests with acceptable performance. To support higher user load, the application and databases might need to be partitioned.
You can use several techniques to partition your application and databases. In configuration 4, multiple server machines host the SQL Server databases used by your application, as shown in Figure 14-4. Each server machine hosts one or more of the databases, with each database hosted on exactly one machine. MTS application packages are installed on the server machines closest to the data they use. This partitioning complicates deployment a little, since each machine that makes calls to components needs to know where the MTS components it uses are deployed. This configuration is compatible with replicating the IIS server and using DNS round-robin load balancing to handle client requests; it should be most useful for applications with moderate user loads that access multiple databases.
Figure 14-4. Placing SQL Server databases on separate nodes.
If you are using transactions and your transactions access multiple databases, a high percentage of the transactions might be distributed in this configuration. Distributed transactions are slower than transactions on a single machine, since the Microsoft Distributed Transaction Coordinator (MS DTC) must communicate with all the machines to coordinate the transaction. However, the increase in the time to complete one transaction is usually an acceptable trade-off, as the average time per transaction for large user loads is likely to decrease.
Similarly, since IIS and MTS/SQL Server are running on separate machines, you will encounter the performance and firewall issues mentioned earlier for configuration 2. Again, the increase in the time to complete a single method call or the administrative complexities of passing through a firewall are usually acceptable, since larger user loads can be supported. You should carefully test potential topologies to ensure that the application's performance requirements will be met.
If your application uses a single database and you cannot restructure its tables into multiple databases or the application uses multiple databases but can't meet performance goals with each database on a separate server machine, the situation is a little more complicated. In these instances, you might need to create multiple copies of a single logical database, with each copy installed on a separate server machine. You can use SQL Server replication to propagate changes from one copy to another.
Configuration 5 is useful when a clear mapping exists between application users and subsets of the data values stored in the database. For example, all the users at a particular geographical location might update a local copy of the database. Periodically, these updates can be replicated to a master database at company headquarters so that users who perform operations across geographical locations have access to all the data they need. A portion of the database key value (the value used to identify a specific record) would depend on the geographical location to prevent collisions between updates from different sites.
In one variation of this configuration, the database is partitioned but the application is not. The MTS application packages are installed on a single machine. The components must contain code to determine which database server to use for any particular operation. This variation isn't particularly useful for most situations since any changes to the database configuration are likely to require changes to the components too.
In another variation, the MTS application is replicated to each database server machine. The components might use configuration information about the server machine to determine what data values are valid inputs for the machine. (Otherwise, you would need to code customized versions of the components for each machine.) Client machines or IIS servers are configured to point to particular database server machines. For example, all client machines at a particular site might point to a local IIS server that in turn points to a specific server machine with the MTS application and SQL Server database installed, as shown in Figure 14-5. This variation can be quite useful for geographically distributed deployments.
Figure 14-5. Using a specific IIS server to access a geographically partitioned database.
In addition to partitioning the database, you might need to partition your application. Each MTS package in the application might be deployed to a different database. The most common way to partition applications is by functionality. For example, as shown in Figure 14-6, the business objects might be installed on the IIS machine while the data objects are installed near the data they access. Performance with this configuration should be quite good, as the calls from ASPs to business objects and the calls from data objects to SQL Server databases are local calls. Only the calls between business objects and data objects are cross-machine calls.
Figure 14-6. Partitioning your application.
Of course, this configuration has many possible variations, combining many of the features of our earlier configurations. As you add database partitioning, replication, load balancing, and so on to the configuration, deployment and administration become increasingly complex. The benefit is that your application should be able to support a very large user load. When you elect to use complex configurations, you should use the performance testing methods from Chapter 13 to verify that your application's performance requirements are met.
If your application has stringent reliability or availability requirements, you might choose to deploy the application packages on a cluster. Recall that a cluster is a group of physical machines that acts as a single logical machine. At any given time, one physical machine is on line, providing services to clients. If that machine fails, another machine automatically takes over. Microsoft Cluster Server (MSCS) provides the services for coordinating actions within a cluster. Currently, MSCS supports clusters consisting of two machines.
MTS can be configured to work with MSCS (as can IIS and SQL Server). The physical machines in the cluster must have exactly the same MTS packages installed. The MTS Replication utility, MTXREPL.EXE, is used to replicate MTS catalog information across the cluster machines.
The topic "Using MTS Replication" in the MTS Administrator's Guide explains how to configure a cluster with one or more MTS applications.