Managing a Web Farm with Application Center 2000

Downloads
16468.zip

Editor's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month's column examines Microsoft Application Center 2000—a Microsoft .NET server that handles the management and deployment of servers in a Web farm.

Application Center is a set of tools and services that lets you manage a farm of IIS Web servers as if they were one machine. This concept of grouping servers to facilitate managing them as a whole is called an Application Center server cluster. With Application Center, you can create clusters or add member servers to and remove them from existing clusters. When you've defined an Application Center server cluster, you can automatically deploy new content to the cluster group as a whole, configure load balancing, and monitor cluster performance.

Application Center Installation and Configuration
The recommended server configuration for Application Center is a Pentium-class 400MHz or faster processor, 256MB of RAM, and ample disk space (Application Center requires about 100MB plus hosted data files). If you want to take advantage of Network Load Balancing (NLB), you need to run Windows 2000 Advanced Server and have two NICs per server.

At the time of publication, Application Center is in beta 2, and the installation and configuration procedures are likely to change. In addition, Microsoft has yet to document the installation procedures that involve NLB.

NLB is one of the Win2K clustering features and is available only in Win2K AS and Win2K Datacenter Server. NLB uses one virtual IP address to cluster applications on multiple servers, which lets you create port rules based on application port numbers and load balancing based on an evenly distributed load (the default setting) or a manually configured distribution matrix. Running NLB with Application Center requires two NICs per server—one NIC for the client-to-cluster traffic and a dedicated NIC for traffic specific to the computer. Configure only one adapter per server with NLB. Here are a few hints to make NLB configuration as painless as possible:

• Install NICs on separate subnets to minimize network traffic.
• Add the virtual IP address as an additional address in the NICs' Internet Protocol (TCP/IP) properties.
• Set Cluster Parameters and Port Rules identically on all cluster hosts, but make the Host Parameters unique for each server.
• Ensure that all ports for a given application are open in Port Rules (e.g., FTP uses ports 20, 21, and 1024 through 65535).
• Follow the NLB Best Practices sheet in Win2K AS Help.

When NLB is up and running, Application Center installation is easy. The beta 2 installation requires four steps that Microsoft will most likely incorporate into the release to manufacturing (RTM) version. These four installation steps are

• Service Pack 1 (SP1)
• Pre-SP2 hotfixes
• Application Center components
• Microsoft Health Monitor 2.1 components

When you've installed Application Center on each server that's to be a cluster member, you need to set up the cluster. Follow these steps to configure the Application Center cluster for Web site clustering:

1. Open the Microsoft Management Console (MMC) Application Center snap-in, right-click Application Center, and select Connect As.
2. On the Connect to Server dialog box, enter the name of the server you want to be the controller for the cluster. Select the Manage cluster for this server option.
3. On the New Server dialog box, select the Create a new cluster option, then click OK to start the New Cluster Wizard. Click Next.
4. The wizard analyzes your server configuration. When analysis is complete, click Next.
5. Enter the cluster name and a description (optional). Click Next.
6. Select the type of cluster you want to deploy. Select the Web cluster option, as Figure 1 shows, then click Next.
7. The wizard now detects your NLB settings. You can let the wizard set the optimal NLB settings, or you can use the existing settings. Microsoft recommends that you let Application Center reconfigure your NLB settings, but this reconfiguration could break NLB if you have anything other than the default configuration (e.g., if you use Multicast). Select the option that best fits your needs, then click Next.
8. On the Monitoring Notifications screen of the wizard, which Figure 2 shows, enter the email address and mail server name that Application Center will use to notify you if the cluster encounters a failure. Click Next, then click Finish. Application Center will create the cluster.

When Application Center has created the cluster, you can add additional cluster members. To add cluster members, follow these steps:

1. Open the Application Center snap-in, right-click Members under the cluster you just created, then select All Tasks, Add Cluster Member. On the opening screen of the Add Cluster Member Wizard, click Next.
2. On the wizard's Name and Credentials screen, which Figure 3 shows, enter the server name and administrative credentials for the server you want to add, then click Next.
3. On the wizard's Controller Name screen, enter the name of the controller for the cluster, then click Next.
4. On the wizard's Load Balancing Options screen, which Figure 4 shows, configure load balancing for the cluster. You need to select which NIC is for NLB and whether to bring the server online after initial synchronization. When you've entered this information, click Next. The wizard now adds the server to the cluster, and the server appears in the Application Center snap-in under Application Center, ClusterName, Members, as Figure 5 shows.

Application Center Request Forwarding
One of Application Center's most exciting features is request forwarding, which is also one of the most difficult features to conceptualize. In contrast to programming Windows (or Win32) applications, Web programming is challenging because it's difficult for Web developers to maintain coherency, or session state, between pages. Session state is a temporary store for user session information, such as user preferences, shopping baskets, and other user-specific information.

Because TCP/IP is a stateless protocol, a Web developer can't automatically make the value in variables set in one Active Server Pages (ASP) file available in the next ASP file (as they are automatically between forms in a Win32 application). The Web programmer can use many tactics to retain session state, but such a discussion is certainly beyond the scope of this article.

In a load-balanced, multiserver environment, managing and resolving session state for individual clients is even more complex. Hardware and software load-balancing solutions include features to ensure that a client remain "sticky" to the server from which that client requested a file (i.e., to retain server affinity). For example, in large ISPs, a user makes a page request on the Internet, and a server serves that page from a New York data center. A user makes another page request, and a server serves that page from a Los Angeles data center. These load balancers can't retain server affinity if they don't know exactly where the client request is coming from. The load balancer assumes that a new client is connecting and that the balancer load-balanced that client to the most available server and created a new session.

Microsoft designed Request Forwarder to resolve these session-state problems when Application Center handles HTTP client requests. Request forwarding lets you cluster applications and preserve session state, in most cases without modifications. Application Center Request Forwarder is

• Transparent to clients—Clients aren't aware of request forwarding beyond the requirement that they accept cookies.
• Transparent to server applications—IIS applications are unaware of any request-handling problems that request forwarding solves.
• Format generic—Application Center applies generic policies to specific HTTP verbs and parts of the URL namespace so that applications requiring session coherency or single-server execution can use request forwarding.
• Easy to configure—No configuration is required to use request forwarding.
• Distributed—Processing on the forwarding server is minimized; the bulk of the processing takes place on the original server that handles the client request.

Request Forwarder sits between the HTTP client and server applications (e.g., between ASP and Internet Server API—ISAPI). The tool stores information that identifies the sticky server in an HTTP cookie, then returns this cookie to the client on its first trip. On subsequent client requests, Application Center checks the cookie to see which server first handled the client during a session. If a load balancer sends the request to a server other than the original, Request Forwarder reroutes the request automatically to the sticky server, thereby handling the problem of server affinity.

Now, here's the best part. In the case of a catastrophic failure, such as a network board dying in one of the Web servers in your farm (i.e., your Application Center cluster), Application Center automatically senses a dead server and Request Forwarder automatically forwards requests from the dead server to another capable server in the farm.

Application Center in Action
The best way to realize the power of request forwarding is with a "pull the plug" demonstration. We set up two IIS 5.0 Web servers running NLB and Application Center, as Figure 6 shows, and used a client on the outside segment to connect to AppCenter.interknowlogy.com. We configured our DNS server to resolve AppCenter.interknowlogy.com to 10.11.100.200 (our NLB virtual IP address). The default Web page on both machines in our server cluster is a simple ASP file, which Listing 1 shows, that displays the SessionID and Server Name of the Web server servicing our requests.

We requested the default page from AppCenter.interknowlogy.com and, through NLB, AppCenter02 answered our request. We simulated a front-end NIC failure by disconnecting the network cable, then we made an additional Web request from our client machine. Application Center, aware of the network failure, forwarded the request to AppCenter01. AppCenter01 used the dedicated NIC to pull session-state information from AppCenter02 and responded to the client's request. AppCenter01 handled all subsequent requests.

The amazing thing about request forwarding is that the client machine never knew it was talking to a different machine. Besides the SessionID staying the same during the failure, the Server Name also remained the same. The client machine believed that it was talking to AppCenter02 throughout the entire session, which it verified by requesting the default.asp page when making additional requests after the simulated failure.

Because the Application Center 2000 installation had installed additional counters in Microsoft Performance Monitor, during the failure, we monitored Total Forwarded Requests in Performance Monitor, as Figure 7 shows. The monitor showed the Total Forwarded Requests counter increment each time we requested default.asp from AppCenter.interknowlogy.com.

Request-Forwarding Considerations
Request forwarding in Application Center is an incredible enhancement to server clustering, but it has limitations. The dedicated NIC must be up and functional, or session state can't be transferred to the healthy server. If session state can't be transferred to a healthy server in the Application Center cluster, it will be lost. In addition, NLB must be configured and running properly for Application Center to use the dedicated intracluster transmissions.