A tool to SIMPLIFY Web site management
When you're planning to launch a major Web site, a key consideration is how to ensure the site's availability and performance. Hardware scaling and software scaling are strategies that you can use to address availability and performance concerns. With hardware scaling, you set up one robust, scalable multiprocessor system, such as an 8-way server with redundant hardware components, to be the Web server. Alternatively, you can use software scaling to mirror Web content on multiple Web servers, which form a cluster. Servers in a cluster can have different hardware configurations; you can combine old and new systems and slow and fast systems. As the site gets busier, you can add machines to the cluster. To implement software scaling, you can use a Web server load balancer (aka IP load balancer), software that directs a client to the least busy or most appropriate Web server among several servers that contain mirrored contents. For example, to balance and fail over client traffic to a Web server, you can use products such as Microsoft's Network Load Balancing (NLB) service for Windows 2000 or Windows NT Load Balancing Service (WLBS), Cisco Systems' Web switch, or Nortel's Web switch. (For more information about Web server load balancers, see "Related Articles in Previous Issues," page 62.)
Although software scaling is easier to adopt and provides more flexibility for Web applications than hardware scaling does, managing Web content and applications across multiple servers isn't easy. You must deploy all content and application component changes to all the servers. If the servers' content isn't mirrored, customers will get different results from different servers at the same Web site. When servers in a cluster fail, a Web server load balancer can redirect client requests to healthy servers. However, you still need a tool to monitor the servers' health and performance.
To ease Web site and application management, Microsoft developed Application Center 2000. Application Center can synchronize Web content and deploy COM+ applications across multiple servers in a cluster. It can monitor and notify you about server and cluster health and performance. In addition to using NLB to load balance Web servers, Application Center supports the Component Load Balancing (CLB) service, which Microsoft withdrew from Win2K after Win2K beta 3 Release Candidate 1 (RC1). The CLB service can load balance the middle tier (i.e., the business-logic tier) of multi-tiered Windows applications. Let's explore how to set up and take advantage of Application Center's ability to cluster, load-balance, and monitor the health and performance of your Web servers.
Clustering
Application Center runs on Win2K Server with Service Pack 1 (SP1), Win2K Advanced Server with SP1, and Win2K Datacenter Server with SP1. You can group two or more servers running Application Center into an Application Center cluster. The first server that you configure for a cluster is the cluster controller. Servers that you add to this cluster are cluster members. Although Microsoft documentation doesn't specify a limit to the number of members an Application Center cluster can support, the maximum number of servers that NLB supports in a cluster is 32. The relationship between a cluster controller and its members is similar to that of an NT PDC and its BDCs. When you make a change on the cluster controller (e.g., you publish Web content), the controller replicates the change to cluster members. When a change occurs, Application Center can automatically synchronize the Microsoft IIS configuration, including the configuration of virtual sites and directories, Web roots, content, server certificates, registry keys, network settings, NLB settings, and system Data Source Names (DSNs) between the cluster controller and the cluster members. However, you must manually replicate COM+ components and Internet Server API (ISAPI) filters from one server to another or throughout the cluster. Microsoft calls this process deployment. The manual deployment of these components gives you control over COM+ application updates and cluster integrity because these changes require you to restart the Web service on the server. You can promote a cluster member to a controller if the original controller fails, or you can demote a controller to a member.
Application Center clustering is different from clustering with Microsoft Cluster Service (MSCS), which NT Server 4.0, Enterprise Edition (NTS/E) includes, and Cluster services, which Win2K AS and Datacenter include. In MSCS, two nodes in a cluster (as many as four nodes in Datacenter) use a shared storage system to work in a failover or active-passive (aka active-backup) mode. Only one active server answers client requests, and the backup server doesn't answer client requests unless the primary server fails. In Application Center, mirrored servers in a cluster are all active servers that handle client requests that the load-balancing service distributes. If you run the same application (e.g., IIS) on a two-node MSCS cluster and a two-node Application Center cluster, the Application Center cluster will handle almost twice as many requests as the MSCS cluster. However, Application Center doesn't replace MSCS; Application Center provides clustering for only Web servers and COM+ applications. For back-office application clustering, you need to use MSCS.
Three types of Application Center clusters exist: Web clusters, COM+ application clusters, and COM+ routing clusters. A Web cluster hosts IIS Web sites mirrored across multiple servers in the cluster. A Web cluster can also host local COM+ applications. This cluster type uses NLB for IIS Web server load balancing (alternatively, you can use a third-party load balancer) and CLB for COM+ application load balancing. In a simple Application Center Web cluster, which Figure 1 shows, the cluster's front-end (i.e., Internet-facing) network interfaces support load balancing for external user access, and the back-end (i.e., intranet-facing) network interfaces fulfill cluster synchronization and provide internal user access, such as cluster maintenance and management.
Application Center's COM+ application cluster hosts only COM+ applications to which other Web sites, such as Application Center Web clusters, or Windows applications refer. For example, in Figure 2, page 64, a COM+ application sits in the middle of a multi-tiered application and implements business logic, which offloads the processing of COM+ objects from Web servers and improves performance. The top tier is dedicated to an Application Center Web cluster that hosts Web servers that receive client requests. The bottom tier is a BackOffice application cluster (e.g., Microsoft SQL Server on MSCS) that maintains business data.
Application Center also provides a COM+ routing cluster. This cluster simply routes requests to a COM+ application in the COM+ application cluster.
Load Balancing
Application Center uses NLB to load balance Web servers in a cluster. NLB isn't a part of Application Center but is a service that comes with Win2K AS and Datacenter. However, Application Center simplifies NLB configuration by automatically configuring NLB when you select it as the load balancer during Application Center configuration. From Application Center's management console, you can optimize NLB configuration for a specific server (e.g., increase the server's priority) and edit the NLB configuration for all servers (e.g., add a new virtual IP address for a new Web site). To use NLB for Application Center, you must install Application Center on a Win2K AS or Datacenter system with two NICs in each server. If you use a third-party load balancer, you can run Application Center on Win2K Server and use one NIC in each server. (However, if you use a third-party load balancer, Application Center doesn't automatically configure NLB.)
To load balance a cluster, NLB sends a client request to the top-priority, least-busy Web server in the cluster. Depending on a client's IP address or Class C network address, NLB supports client affinity (aka sticky or persistent connections) for applications that need to maintain the client's session state (e.g., an online shopping basket application) and associate the client with a specific server. However, NLB can send a client's request to the wrong server when NLB has created the client state information on a different server in an early part of the client's session. For example, if the client's network uses proxy servers for Web traffic, the network might originate the client's requests from different proxy servers, which might cause NLB to relay the client's requests to different Web servers.
To tackle this problem, Application Center offers session coherency (aka request forwarding), which is a cookie-based persistent connection. When a client first visits an Application Center Web site, Application Center can send the client a cookie that identifies the first server that handles the client's request. If NLB or a third-party load balancer redirects a subsequent request from that client to a different server, the server forwards the request to the original server based on the information in the cookie. If the client's original server is unavailable, the forwarding request will fail. To enable this functionality, select the Enable session coherency option in the Advanced Load Balancing Options dialog box, which Figure 3 shows, during Web server configuration. You can enable session coherency for only ASP sites or for all sites. To optimize performance, you can configure Application Center not to forward requests for certain content types, such as static pages and graphics. By default, Application Center doesn't forward requests for HTML, HTM, JPEG, JPG, GIF, PNG, and TXT content types.
Application Center also provides a draining option that lets you take a server offline (i.e., the server won't provide services in the cluster) for the amount of time that you specify (20 minutes by default). During the draining, the server completes its assigned requests without accepting new ones. This feature is useful for server maintenance (e.g., installing a new COM+ application) during production hours. Some third-party load balancers call this functionality a grace shutdown.
Application Center also supports CLB, which dynamically balances the workload of COM+ applications in a Web or COM+ cluster. Since its birth, COM has provided an object activation service called Service Control Manager (SCM), which creates new objects when a client request arrives. SCM hides the details about where the new objects live, locates and loads the appropriate DLL or executable file on the server, and gives the client an interface pointer to the raw object or proxy as needed. In NT 4.0, SCM forwards creation requests to SCMs on other computers according to a client process or a configuration setting in the client's registry. When SCM in an NT 4.0 system receives a forwarded creation request from a remote computer, SCM handles the request locally. CLB in Application Center simply extends this functionality. CLB in Application Center can locally process a forwarded creation request from a remote computer or forward the request to one of a collection of servers depending on the current workload of the servers. You can group several or all servers in a Web or COM+ cluster into a collection and load balance components among the servers in the collection.
Installation and Configuration
After you're familiar with Application Center's clustering and load balancing functionality, you can begin the installation and configuration process for your Web site and COM+ applications. Installation is straightforward; you simply load Application Center on each of the Win2K servers that you want to include in an Application Center cluster. Application Center requires IIS 5.0 to be preinstalled on the servers, but the servers don't have to be in an Active Directory (AD) domain because Application Center doesn't use AD. Microsoft recommends that you install Application Center on a system that has at least 256MB of RAM, but you might want more memory to improve a system's performance.
To manage Application Center clusters, IIS servers, and COM+ applications, Application Center provides one administrative console, which Figure 4 shows, that contains four Microsoft Management Console (MMC) snap-ins: Application Center, Internet Information Services, Health Monitor, and Component Services. You can run this console on Application Center servers and remote Win2K and NT 4.0 SP6 and later machines.
In addition, Application Center provides a Web interface that looks similar to the GUI console but has limited functionality. This Web interface is enabled after you install Application Center, and it uses port 4242. In addition to these two interfaces, Application Center includes a command prompt window, called AC, for cluster management.
After you've loaded Application Center on each server and you can access the GUI console, you're ready to configure clusters. For example, suppose you need to set up a cluster that contains two servers, BIGSERVER1 and BIGSERVER2. This cluster will host an online-order Web site and a COM+ application. You can use the following steps to configure this Application Center Web cluster.
Previous
