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.
Create the cluster. To create a cluster, right-click the Application Center snap-in in the left pane of the Application Center console and select Connect. Enter BIGSERVER1 (or the server's DNS name or IP address) as the server name and, in the resulting Connect to Server dialog box, use an administrative account to connect to the server. (You can use localhost as the server name if you're using the console on server BIGSERVER1 to create the cluster.) After you select the Create a new cluster option in the New Server dialog box, Application Center will start the New Cluster Wizard. You must provide a cluster name, such as WebCluster; select a cluster type, such as Web cluster, and select a load-balancing type, such as NLB or third-party load balancing. If you use NLB, be sure that you have bound two static IP addresses to the front-end network interface before you create the cluster—the second IP address is the virtual IP address of the Web site. Application Center then creates the cluster and adds BIGSERVER1 to the cluster as the cluster controller.
To add BIGSERVER2 to the cluster, right-click the Members node under WebCluster in the Application Center console and select the Add cluster member option from the All Tasks drop-down menu. The Add Cluster Member Wizard will then prompt you to provide the server name, administrator account, and cluster controller name. After you input this information, you've created a two-node Web cluster. The WebCluster node in the Application Center snap-in, which Figure 4 shows, displays this cluster in the left pane.
Prepare the cluster controller. After you create the cluster, you must configure the Web server, install the COM+ application on the cluster controller (BIGSERVER1 in the example), and add a new application for the cluster. To do so, you first create a subdirectory, such as OrderWeb, in the wwwroot directory of IIS in the file system. The default wwwroot directory is C:\Inetput\wwwroot. You store the online order Web pages and related files in the OrderWeb subdirectory. You can use the Internet Information Services snap-in in the Application Center console to create a virtual directory, such as OnlineOrder, and point the virtual directory to the subdirectory path in the file system.
Next, in the Component Services snap-in, you create a COM+ application (e.g., called Online Order) in the COM+ application folder of BIGSERVER1 and import into Online Order the necessary COM components that you have registered in BIGSERVER1. For each component in Online Order, you need to enable the Components support dynamic load balancing option on the Activation tab of the components properties window. This setting ensures that the component will support CLB.
Now you can add a new application through the Applications node of WebCluster in the Application Center snap-in. In our example, this new application contains all the resources for the online order Web site and the COM+ application. To create a new application for WebCluster, click the New button on the menu bar of the top right pane, which Figure 5 shows, and give the cluster a name, such as Online Order App. When you highlight this application in the right pane, you can define the resources that the application uses in the bottom right pane. In this example, the resources include Online Order App as the COM+ application, C:\Inetput\wwwroot\OrderWeb as the file-system directory path, and Default Web Site/Root/OrderWeb as the IIS virtual directory.
Synchronize the application. By default, Application Center automatically replicates from the cluster controller to the cluster members all of an application's resources, such as the IIS virtual directory and contents, except the COM+ application. To perform this replication, Application Center uses two types of automatic synchronization: incremental and full. The incremental synchronization copies changes from the cluster controller to members only when a change occurs. The full synchronization replicates all of an application's contents and configuration settings from the cluster controller to members periodically at an interval that you define (the default is 60 minutes). You can enable or disable the automatic synchronization and set the full synchronization period in the properties of the cluster controller node in the Application Center snap-in. In this snap-in, you can also enable or disable a specific cluster member so that Application Center doesn't synchronize that member with the cluster controller.
In addition to automatic synchronization, Application Center lets you manually push an application's contents and configuration settings from the cluster controller to members. To do so, you simply right-click the cluster controller node in the Application Center snap-in and select the Synchronize Cluster option. You can also manually pull content and configuration settings from the cluster controller to a specific member by right-clicking the cluster member node in the Application Center snap-in and selecting the Synchronize Member option. However, you can't manually synchronize COM+ applications.
Deploy the application. After testing the COM+ application on the cluster controller, you can deploy the application to cluster members. When you deploy the COM+ application to a target server, the Web service on the server must be shut down. For this reason, Microsoft suggests that you deploy the COM+ application to one server at a time.
To deploy Online Order App from BIGSERVER1 to BIGSERVER2, right-click the Applications node under WebCluster in the Application Center snap-in. The New Deployment Wizard will guide you through the deployment steps. First, you must name the deployment. By default, the wizard uses the current date and time to name the deployment. Next, select BIGSERVER2 from the list of available target servers in the cluster, select Online Order App from the list of available applications, and specify COM+ application as the deployment option. Application Center will replicate the necessary components from BIGSERVER1 to BIGSERVER2. You can check a deployment's status in the Application Center console. A check mark next to the deployment in the right pane of the console means that the deployment completed successfully.
Application Center's deployment functionality lets you simultaneously deploy multiple applications and copy an entire server image from the cluster controller to one or more members. Application Center can even deploy applications from a server that isn't in the cluster to the current cluster. This feature lets you maintain a staging server outside the production cluster for application development and testing before you deploy an application to the cluster.
After Application Center successfully deploys an application, you must enable the servers that are supporting the COM+ application so that they can participate in CLB in the cluster. To enable the servers, go to the Component Services tab of the cluster's properties and add the servers to the list of Component servers. After you bring the servers back online, WebCluster is ready to accept client requests and perform load balancing for the Web servers and the COM+ application.
Cluster Monitoring
When your Application Center cluster is working, one of your ongoing maintenance tasks is to monitor the cluster's health and performance. Application Center's monitoring features make this task easy. You can use Application Center to track a cluster's health, performance, and availability and you can view the results in the console.
Application Center provides a performance monitor that includes 20 useful counters that let you monitor processors, memory, file systems, IIS, HTTP requests, and COM+ applications. To use Application Center's performance monitor, click a server or cluster in the Application Center snap-in. (If you click a cluster, the performance monitor serves as the cluster controller.) In the right pane, you can add necessary counters depending on what you want to monitor. For example, to see how busy the server CPU is, add the Processor Utilization counter. As Figure 4 illustrates, BIGSERVER1's CPU utilization averaged 45 percent in a 15-minute period.
Application Center includes Health Monitor 2.1, which is a more recent version of this monitoring tool than BackOffice 2000 and Systems Management Server (SMS) 2.0 include. Microsoft preconfigured Application Center's Health Monitor to watch application synchronization, request forwarding, the IIS Web service, processor workload, and home page availability on a server. Figure 6, page 66, shows the Health Monitor node expanded. When you select a monitored item in the Health Monitor snap-in, you can view alerts and statistics regarding that item in the top right pane. You can add new monitors to Health Monitor based on your needs, and you can configure this tool to take the server offline and online and to send email alert messages to you when specified events occur. Application Center also provides an event viewer that lets you view events that Application Center and Health Monitor log.
Each Application Center server stores its health and performance data in a local Microsoft Data Engine (MSDE) database, which is a SQL Server 2000 Runtime database. This setup means that you can use all of SQL Server's tools to retrieve and archive data from each server and generate custom reports about a cluster's health and performance.
Application Center also supports Windows Management Instrumentation (WMI), which is Microsoft's implementation of Web-Based Enterprise Management (WBEM), an industry standard for accessing management information in an enterprise environment. WMI is a central place in which applications store and retrieve events and management data in Win2K. Application Center provides its generated events to WMI, so a third-party management tool that supports WMI can obtain and use Application Center events.
Simplify Your Life
In mid-2000, Microsoft introduced Microsoft .NET, a computing and communications concept that lets organizations create distributed Web services and integrate customers, partners, business processes, and applications on the Internet. Application Center is one of the Microsoft .NET products for Web site management. Application Center lets you implement high-availability and high-performance Web sites and automate load balancing, synchronization, and deployment of Web content and applications. Application Center's alerting and monitoring functions let you measure your Web site and applications' performance and troubleshoot to prevent failure on your site. Application Center will simplify Web management and make your life easier.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. SHAWN WILDERMUTH "Scale Your Web Site," August 2000, Web Exclusive, InstantDoc ID 8908 TAO ZHOU "Web Server Load Balancers," April 2000, InstantDoc ID 8254 "Microsoft's Load-Balancing Services," April 2000, InstantDoc ID 8253 |
