Lesson 2: Planning Application Center Clusters

Application Center allows you to build multitiered clusters that can use various load balancing techniques to provide high availability, scalability, and robustness. Application Center supports NLB and CLB. A typical Application Center cluster topology is based on an n-tier solution that includes a Web-tier cluster for serving content to the client. It’s the Web-tier cluster that uses IIS and NLB to satisfy incoming IP requests. The topology might also include an additional tier to support a COM+ application cluster, which would rely on CLB to respond to COM+ requests. When implementing an Application Center cluster, you must consider a number of factors as you plan how to set up the clusters in your organization. For example, you must select a cluster type and determine how session state will be managed. This lesson describes each step that you should follow when planning Application Center clusters in your organization.

After this lesson, you will be able to

• Plan server configurations and determine IP addresses
• Select a cluster type and, where appropriate, a load balancing configuration
• Determine how session state will be maintained

Estimated lesson time: 25 minutes

Planning for Application Center 2000

You should consider a number of steps when planning an Application Center cluster. This section discusses many of those steps.

Planning Server Configurations

Before attempting to set up a cluster controller and create a cluster, you have to assess the processing capabilities of the servers that you plan to use in your cluster. The servers must have enough resources to comfortably run Windows 2000 Server, Advanced Server, or Datacenter Server; Application Center; Application Center Event and Performance Logging (optional); IIS 5.0; and the applications running on the cluster—whether they’re Web-based or COM+ applications.

Memory

The official minimum memory for running Application Center on Windows 2000 Advanced Server is 256 MB of RAM on a 400 MHz system. However, you must consider several factors when determining a server’s memory requirements. For example, Windows 2000 Server and IIS require at least 256 MB of RAM, although between 512 MB and 1 GB is recommended. You should consider the high end of the range if the site is hosting an e-commerce application, contains a large amount of content, uses dynamic pages extensively, uses COM+ applications, or has a high volume of traffic. Remember that the IIS cache size defaults to half the available amount of real memory.

Fixed Disk

The disk partition must contain adequate space for all the installed programs, paging file space, and site content. You also have to factor in the space required for content replication. Because the replication engine copies all the content to a temporary directory on the destination server and then moves these files to the appropriate folders during synchronization, the required disk space is approximately double the volume of the content to be replicated.

The Synchronization Service uses a two-phase commit process to ensure data integrity, which is why the replication engine uses a temporary directory on a target.

Finally, you should allow enough free space to support disk defragmentation. A minimum of 15 percent of the disk should be free to support effective defragmentation. (A higher percentage of free disk space will improve disk defragmentation.)

Network Adapters

Each system should have at least two network adapters if it’s part of a load- balanced cluster and must have at least two if you’re going to use NLB. The front-end adapter (also called the load-balanced adapter) is used for front-end traffic such as NLB heartbeats, convergence, and load balancing. The back- end adapter, also called the management-traffic adapter, is used for back-end traffic generated by different cluster activities, notably content replication and synchronization.

You need two network adapters for two reasons. First, this enables NLB to bypass a loopback condition that occurs when using unicast mode. Second, the replication engine that Application Center provides uses COM calls extensively, and replication will fail if a connection gets dropped or reset. IP address changes or deletions can cause connection drops or resets, which is why using the front-end network adapter for the high-volume data transfers that typify content replication is risky. This issue isn’t exclusive to replication but includes other Application Center features, such as cluster services and monitoring.

Hardware

Although Application Center will run on any server that meets the minimum requirements, homogenous hardware is recommended. This is the best way to ensure balanced and consistent performance across a cluster and to make it easier for you to tune your servers for optimum performance.

If you’re using NLB or one of the compatible third-party load balancers, you can adjust load-balancing weights to compensate to some extent for performance differences between servers. However, remember that each cluster member is synchronized to the controller. As a result, there’s little leeway in customizing individual configurations, especially IIS.

You can use multiple disk partitions, but the idea of homogeneity extends to the file system structure on a disk partition. Identical file system structures are required (System Root, Program Files path, Application Center path), and it’s strongly recommended that you use Microsoft NT file system (NTFS) rather than file allocation table (FAT) 32.

The main factors in selecting homogenous systems for a cluster are the number of CPUs, CPU speed, disk partitioning/formatting, and memory on each server.

Determining IP Addresses

Application Center supports several IP address binding scenarios for the front-end and back-end adapters. In most cases a single Dynamic Host Configuration Protocol (DHCP)–assigned address is bound to the back-end adapter. For the front-end adapters, IP addressing is a little more complicated.

After installing Application Center you should verify that NetBIOS over TCP/IP is enabled for each IP address.

For the Controller

If your cluster uses NLB, the controller requires a minimum of one static IP address bound to the front-end adapter. This single IP address serves as the cluster IP address for the adapter and there’s no dedicated IP address, which is restrictive from a network management perspective. For example, you can’t ping the front-end adapter on a specific server by using the IP address because the address is common to all the cluster members in a load-balanced cluster.

For a Member

In an NLB cluster, the front-end adapter requires a minimum of one IP address, which can be either static or assigned by DHCP. When the member is added to the cluster, Application Center binds the cluster IP address to the adapter. Once again, network management considerations should determine whether you want to use one or two IP addresses on the front-end adapter.

Figure 6.5 illustrates a server configuration for an Application Center cluster member that’s using NLB. In this example there are two static IP addresses bound to the front-end network adapter. The first is a dedicated IP address that enables you to communicate directly with the front-end adapter. The second is the cluster IP address that carries the load-balanced cluster traffic.

Subnets

In the configuration shown in Figure 6.5, the front-end and back-end adapters are on separate subnets. There are two reasons for this. First, using separate subnets provides a more secure implementation by isolating the back-end (internal) traffic from the front-end (external) traffic. (Another technique for isolating network traffic is to use network segments.) Second, using separate subnets improves traffic distribution over the network adapters when you’re using NLB. This has to do with the way Application Center configures adapter interface metrics and the way NLB routes traffic. If you create a cluster that uses NLB, Application Center sets the interface metric for the load-balanced adapter to be one higher than the interface metric for other cards on the same computer.

For example, assume that you have a server configured with two adapters, both of which are on the same subnet. If the interface metric for the back-end adapter is 1, Application Center sets the interface metric for the load-balanced adapter (the front end) at 2. When a response is sent to the client, NLB routes it to the adapter on the same subnet that has the lowest interface metric. In this scenario, outgoing traffic is routed to the back-end adapter, which is where Application Center transmits all cluster management and synchronization traffic. Depending on the amount of traffic on the back end, this could have an adverse impact on services, such as the Synchronization Service.

Separate subnets aren’t mandatory; however, they’re supported if you decide to use them for your clusters.

Figure 6.5 - Cluster member configuration

Selecting the Cluster Type

Cluster type refers to the primary role of your cluster. The type is determined, for the most part, by the type of content and applications that are hosted. The following three options are available when setting up a cluster:

• General/Web cluster This cluster hosts Web sites and local COM+ applications or is used for general-purpose activities, such as server management or staging applications. (A fairly common server configuration is one that has COM+ components running on the same computer but out-of-process in their own COM+ processes.)

  If NLB is detected during the Application Center configuration analysis, the only available option is General/Web cluster. In order to use the other options, unbind NLB and restart the cluster setup process.

• COM+ application cluster This cluster hosts only COM+ applications that can be referenced by other servers in a General/Web cluster or COM+ routing cluster or by Windows-based applications.

  If you choose the COM+ Application cluster option, you must identify one of two sources for client calls. The first option is applications running on other servers, such as Web servers running ASP and CLB. The second option is desktop COM client applications, which are typically written in a Win32 development environment such as Microsoft Visual Basic. In the case of Win32-based applications, two network adapters are required on each cluster member because NLB is used as the load-balancing technology. In scenarios where the clients are Web or routing clusters, you can use CLB.

• COM+ routing cluster This cluster’s primary role is routing requests to a COM+ application cluster, although it can also function as a Web server cluster.

  A COM+ routing cluster uses CLB to route activation requests for COM+ components from clients to a COM+ application cluster. A COM+ routing cluster is essentially a load balancer for COM+ components that are on a COM+ application cluster. COM+ routing clusters are useful when requests for COM+ applications come from a combination of Web-based and Windows-based applications. For most cases you don’t need to create a separate COM+ routing cluster; you can create Web clusters that perform CLB.

Selecting a Load Balancing Configuration

If you plan to choose either a General/Web cluster or a COM+ routing cluster as the cluster type, you must also decide which load balancing configuration you’ll use in your cluster. Application Center supports three load balancing options:

• NLB
• Non-NLB solutions
• No load balancing

NLB is selected by default unless the server analysis indicates that only one network adapter is present or that DHCP is enabled on both network adapters. If either of these conditions exists, NLB is disabled and the only available options are third-party load balancing or no load balancing.

Network Load Balancing

Application Center allows you to set up and configure NLB quickly without any manual configuration tasks. If the default settings applied by the wizard aren’t sufficient, you can modify the settings by using the Application Center user interface or by using the Properties dialog box for the appropriate network adapter. Application Center also provides seamless integration with NLB so that you can use the Application Center user interface to complete common administrative tasks, such as setting members online and offline.

If you configured NLB prior to creating a cluster in Application Center, you can reconfigure those settings or use the existing setting and replicate them to members. If you want to modify any settings, you should do so before adding any members. By doing so, the members that you add acquire the proper settings. If you modify settings after adding members, you might disrupt the cluster.

Non-NLB Solutions

To distribute incoming client requests, Application Center provides integration with NLB and also supports other load balancers. You can monitor and manage these third-party load balancing devices through Application Center to provide a complete cluster administration solution. With third-party load balancing integration, Application Center monitors cluster member status, sets members online and offline, and synchronizes content and configuration for all Web sites, including IP addresses bound to Web sites. To integrate these devices with Application Center, you must configure communication between the device and Application Center.

Because all members are synchronized with the cluster controller, you should ensure that all content and configuration exist on the controller before adding any members. Unpredictable behavior might result if content or configuration on members is different from the controller.

The Microsoft Application Center 2000 Resource Kit provides tools for third-party load balancing integration, including a WMI provider that you can use to monitor your device. This provider allows your device to indicate member status, such as online and offline status or if a member encounters errors. With this provider you can view member status from the Application Center user interface rather than from the device. This capability allows you to view all aspects of the cluster from within Application Center; you don’t need to view some aspects (such as synchronization status) from Application Center and other aspects (such as member status) from your load-balancing device.

No Load Balancing

You might decide that you don’t need or want to use load balancing. For example, load balancing isn’t necessary for application testing and staging.

Maintaining Session State

In load-balanced environments, all client requests are subject to load balancing. Clients who have established session state must also have their requests processed by particular members. Otherwise, clients can experience disruption in their sessions if their requests are load balanced to a member on which the session information doesn’t exist.

To forward Hypertext Transfer Protocol (HTTP) requests to particular members in load-balanced environments, Application Center provides the request forwarder. The request forwarder ensures that the following types of requests are forwarded to the controller:

• IIS administration requests
• Microsoft FrontPage publishing
• Web Distributed Authoring and Versioning (WebDAV) publishing
• Web-based administration requests

Maintaining Session State

The request forwarder provides generic support for maintaining session state by using cookies to associate clients with particular members. Subsequent requests containing the cookie are forwarded to the appropriate member.

For example, if a client creates a session on member A, subsequent requests might be load balanced to member B. Because member B might not have the appropriate session information (thus disrupting the session), the request forwarder sends subsequent requests to member A by using information supplied in a cookie.

By default, request forwarding is enabled only for sites that use ASP session state. These sites have session state enabled as an option under Application Configuration in IIS. The alternative is to enable request forwarding for all Web sites.

Request forwarding might affect performance because the request forwarder processes requests after they’ve been load balanced; it doesn’t eliminate load balancing for any requests.

Generally, you achieve the best performance by preventing the Web cluster from having any involvement with session state. For example, you can keep session information in a SQL Server database while state is maintained in a client’s cookie. Because the Web cluster doesn’t manage session state, you can disable or remove the request forwarder.

Optimizing Performance

Request forwarding imposes minimal overhead as it forwards requests. To minimize performance degradation, you can disable request forwarding for certain file types. You may also want to disable or remove the request forwarder to optimize Web clusters that don’t use ASP session state.

Making a Decision

The process for planning an Application Center cluster includes a number of steps. In each one you must make decisions about hardware and software configurations. Table 6.4 describes many of the issues that you should consider for each step.

Table 6.4 Planning an Application Center Cluster

Step	Description
Planning server configurations	When planning server configuration, you must ensure that each computer has enough resources to run all the necessary applications. You must take into account the amount of memory and disk space and the number of network adapters on each server. You must also consider whether you’ll use homogenous hardware when setting up your servers.
Determining IP addresses	For each server in the cluster, at least one IP address must be bound to the back-end adapter and one to the front-end adapter. The IP address bound to the front-end adapter serves as the cluster IP address. In addition, front-end and back-end adapters can be on separate subnets.
Determining cluster type	When you set up an Application Center cluster, you can choose one of three cluster types: General/Web cluster, COM+ application cluster, or COM+ routing cluster.
Selecting a load balancing configuration	For General/Web clusters and COM+ routing clusters, you must select which load balancing configuration you’ll use for the cluster. You can select Network Load Balancing, other load balancing, or no load balancing.
Maintaining session state	When setting up a cluster, you must determine whether the cluster will maintain session state or whether you want to use another method for managing session state.

Recommendations

When planning an Application Center cluster, you should adhere to the following guidelines:

• Use enough memory in each system to adequately support all applications that will run on that system, including Application Center, the Windows 2000 operating system, IIS, and any other services running on the cluster.
• The disk partition must contain adequate space for all installed programs, paging files, site content, replication, and defragmentation.
• You should configure each server in the cluster with at least two network adapters.
• You should use homogenous hardware to ensure balanced and consistent performance across the cluster.
• You should configure the back-end network adapter with one IP address, preferably a DHCP-assigned address. You should configure the front-end adapter with two static IP addresses, one that’s common to all cluster members and one that’s unique to the individual server. The front-end and back-end adapters should be on separate subnets.
• You should select the cluster type appropriate to the cluster being configured. The General/Web cluster is the type used for your basic Web cluster. You use the COM+ application type only when implementing a separate tier to support COM+ applications.
• When planning a General/Web cluster or COM+ routing cluster, it’s recommended that you use NLB rather than another type of load balancing. NLB is inexpensive to implement and requires less administration.
• You should generally try to avoid having your Web cluster involved with session state.

Example: An Application Center Cluster

An example of an Application Center cluster deployment infrastructure is illustrated in Figure 6.6. In this example there are two Application Center clusters, each running in its own Windows domain. As an additional management and security measure, you can establish organizational units within each domain. By positioning these clusters between the two firewalls that demarcate the perimeter network, you can create a highly secure cluster environment. Notice that each uses a different type of load-balancing configuration. The left cluster uses a third-party load-balancing device, and the right cluster uses NLB.

The infrastructure illustrated in Figure 6.6 is meant only to serve as a starting point for designing and implementing a robust and secure cluster topology. Your business needs will dictate the requirements for back-end database servers or clusters, component servers or clusters, and multilevel testing/staging configurations.

Figure 6.6 - Application Center deployment infrastructure

Lesson Summary

You should consider a number of steps when planning an Application Center cluster. The first step is to plan the server configuration. You must take into account the amount of memory and disk space. In addition, each cluster member should have at least two network adapters. It’s also recommended that you use homogenous hardware. You should configure the front-end network adapters with at least one IP address, which is the cluster IP address. In most cases a single DHCP- assigned address is bound to the back-end adapter. When setting up a cluster, you can choose from one of three cluster types: General/Web cluster, COM+ application cluster, and COM+ routing cluster. If you select the General/Web cluster option or the COM+ routing cluster option, you must also select one of the three load-balancing configurations supported by Application Center: NLB, non-NLB solutions, or no load balancing. Clients who have established session state must also have their requests processed by particular members. To forward HTTP requests to particular members in load-balanced environments, Application Center provides the request forwarder. Generally, you’ll achieve the best performance by preventing the Web cluster from having any involvement with session state.