Scaling the Production Environment

In this section, we look at some of the most common deployment configurations for applications that use IIS for the front-end user interface, MTS for business objects, and SQL Server for the database server. Most of our discussion also applies to applications that are not Web-based using IIS.

Configuration #1: Single Node

In the first configuration, shown in Figure 10.8, IIS, SQL Server, and the MTS application are all installed on a single server, or node. All clients communicate with that node. This configuration is the most straightforward one to deploy and administer. There are no special security issues or firewalls to worry about because the entire server application runs on one computer.

Figure 10.8 Deploying the application to a single node

Because there are no cross-server calls between IIS, MTS, and SQL Server, performance is good for individual clients. If the MTS application is configured to run in-process, performance is even better. The tradeoff is that in-process MTS applications do not participate in role-based security.

An additional tradeoff is that this configuration can support only a limited number of users. Adding memory, high-performance storage devices, or processors to the node allows more users to be supported, but at some point the limit of available hardware will be reached. Then the application will need to be deployed on multiple servers in order to support additional users. Thus, the single-node configuration is most useful for applications with a small user load.

Configuration #2: IIS on a Separate Node

In the second configuration, IIS runs on one server and SQL Server and the MTS application run on a second server. Web clients communicate with the IIS server. This configuration provides faster response for static pages and simple ASP, because more computer resources can be dedicated to IIS. Because MTS and SQL Server are running on the same machine, performance of data objects and the business objects that use them should also be good. Another advantage is that with two servers, the application can scale to larger numbers of users than with a single node.

This approach does have some drawbacks. Calls from ASP-based Web pages to MTS components are cross-server calls, which are inherently slower than local calls and can cause performance bottlenecks. Having the two servers on opposite sides of a firewall can also cause difficulties, depending on the type of firewall separating the servers and on corporate policies regarding traffic through the firewall.

Configuration #2 is useful for applications that consist primarily of static Web pages and simple ASP, with limited use of MTS components and SQL Server databases. If the IIS server is not able to support the user load, the IIS site can be replicated to multiple computers and Windows Load Balancing Service can be used to distribute client requests across the replicated servers.

A disadvantage of this configuration is that all the IIS servers communicate with a single MTS/SQL Server computer, which can become a performance bottleneck as user load increases.

Configuration #3: SQL Server on a Separate Node

In the third configuration, IIS and the MTS application run on one server and SQL Server runs on a second server, as shown in Figure 10.9. Clients communicate with the IIS/MTS server. Because there are no cross-server calls between IIS and MTS, response time for Web pages and the components they use is good. If security and process isolation are not required and the MTS application is configured to run in-process, performance is even better. The application can scale to support more clients than in the single-node configuration.

Figure 10.9 Using Windows Load Balancing Service to distribute client requests

The disadvantage is that all calls to SQL Server are cross-server calls. Because database calls typically involve a lot of disk I/O and data processing on the SQL Server computer, these calls are fairly slow anyway (compared to a component method call), so the extra cost of cross-server calls might not cause any problems. However, it is important to verify that cross-server calls do not cause a bottleneck that prevents the application from achieving its performance requirements. The ODBC connection pool time-out might need to be adjusted to account for the longer connection setup time over the network.

As with Configuration #2, Configuration #3 might run into difficulties if the servers are on opposite sides of a firewall. Additionally, better performance might be attained by using TCP/IP as the communications protocol for SQL Server. Depending on the type of firewall separating the servers and on corporate policies regarding traffic through the firewall, configuring access to SQL Server through the firewall over TCP/IP can range from simple to impossible. Packet-filtering firewalls that allow specification of the TCP/IP ports to be opened might be the most successful solution.

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 Windows Load Balancing Service is used to distribute client requests across the replicated servers. In addition, because all database requests are directed to a single SQL Server computer, the limit on the user load that can be supported will eventually be reached.

Configuration #4: Each Database on a Separate Node

At some point, any configuration that places an application or the databases it uses on a single server 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.

Several techniques can be used to partition the application and databases. In Configuration #4, the SQL Server databases used by the application are hosted on multiple servers, as shown in Figure 10.10. Each server can host one or more of the databases, but each database is hosted on only one server. MTS application packages are installed on the servers closest to the data they use. This partitioning complicates deployment a little, because each computer that makes calls to components needs to know where the MTS components it uses are deployed.

Figure 10.10 Placing SQL Server databases on separate nodes

If the application uses transactions that access multiple databases, a high percentage of the transactions might be distributed in this configuration. Distributed transactions are slower than transactions on a single computer, because the MS DTC must communicate with all the computers to coordinate the transaction. However, the increase in the completion time per transaction is usually an acceptable tradeoff, because the average time per transaction for large user loads is likely to decrease. Additionally, because IIS is running on a separate computer from MTS/SQL Server, the performance and firewall issues mentioned earlier for Configuration #2 will be of concern for this configuration. Again, the increase in the time to complete a single method call or the administrative complexities of passing through a firewall are usually acceptable because larger user loads can be supported. Potential topologies should be carefully tested to ensure that the application's performance requirements are met.

Configuration #5: Partitioned Database

If the application uses a single database and its tables can't be restructured into multiple databases, or if the application uses multiple databases but can't meet performance goals with each database on a separate server, the situation is more complicated. In these instances, multiple copies of a single logical database might need to be created, with each copy installed on a separate server. SQL Server replication can be used 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 users in 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 server, and the components contain code to determine which database server to use for any particular operation. For most situations, this variation isn't particularly useful because any changes to the database configuration are likely to require changes to the components.

In another variation, the MTS application is replicated to each database server. The components use configuration information about the server to determine what data values are valid inputs for that computer. (Otherwise, each server would need customized versions of the components.) Client computers or IIS servers are configured to point to particular database servers. For example, all client computers at a particular site might point to a local IIS server that in turn points to a specific server that has the MTS application and SQL Server database installed. This variation, which is shown in Figure 10.11, can be useful for geographically distributed deployments.

Figure 10.11 Using a specific IIS server to access a geographically partitioned database

Configuration #6: Partitioned Application

The application might need to be partitioned in addition to the database. With this configuration, each MTS application package is deployed to a different database. The most common way to partition applications is by functionality. For example, Figure 10.12 shows the business objects installed on the IIS server and the data objects installed near the data they access. Performance with this configuration should be quite good, as the calls from ASP pages to business objects and the calls from data objects to SQL Server databases are local. Only the calls between business objects and data objects are cross-server calls.

Figure 10.12 Partitioning an application

This configuration has many possible variations that are combinations of features discussed for other configurations. As database partitioning, replication, load balancing, and so on are added to the configuration, deployment and administration become increasingly complex. The benefit is that the application can support a very large user load. When complex configurations are used, application performance must be tested using the methods described in Chapter 13 to ensure that performance requirements are met.

Fault Tolerance

If an application has stringent reliability or availability requirements, the application packages can be deployed on a cluster (a group of physical computers that acts as a single logical computer). One physical computer is online, at any given time, providing services to clients. If that computer fails, another automatically takes over. Microsoft Cluster Server (MSCS) provides the services for coordinating actions within a cluster consisting of two computers.