Identifying Applications or Services That Require Custom Port Rules
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
As previously mentioned, the default port rule is sufficient for some applications and services. However, many applications running on IIS 6.0 or custom applications that are developed by your organization might require customized port rules.
These applications and services can require customized port rules to influence how load is directed to hosts in the cluster. In addition, the applications and services might require a virtual cluster when the same client traffic must be handled differently for the same or different applications and services. With virtual clusters, you can use different port rules for different Web sites or applications hosted on the cluster, provided each Web site or application has a different virtual IP address.
Identifying Applications and Services That Need Persistent Sessions
The applications and services that run on Network Load Balancing include stateful applications (those that maintain session state) and stateless applications. Maintaining session state means that the application or service collects information when first connecting to a cluster host and then retains the information for subsequent requests. During a user session, the same server must handle all the requests from the user in order to access that information. Applications and services that are stateless maintain no user or communication information for subsequent connections.
With a single server, maintaining session state presents no difficulty, because the user always connects to the same server. However, when client requests are load balanced within a cluster, without some type of persistence, the client might not be directed to the same cluster host for a series of client requests.
In Network Load Balancing, you maintain session state with a port rule affinity between the client and a specific cluster host. Port rule affinity directs all client requests from the same IP address to the same cluster host. You can use port rules to specify the port rule affinity between clients and cluster hosts. For more information about specifying port rule affinity between clients and cluster hosts, see "Specifying the Affinity and Load-Balancing Behavior of the Custom Port Rule" later in this chapter.
Port rule affinity might be required by the following:
An application or service running on the cluster
Session-oriented protocols that are used by the application or service running on the cluster if the session lifetime extends across multiple TCP connections
Identifying applications that require affinity
Applications and services require persistent sessions when the application or service retains information established in a client request that is used in subsequent client requests. In some instances, the application or service is aware that load balancing is occurring, and it uses an application-specific method, such as client-side cookies, for maintaining session state. In other instances, the application or service is unaware that load balancing is occurring, and it requires Network Load Balancing to maintain affinity between the client and specific cluster hosts.
An example of an application that maintains session state is a Web application that requires a user to log on to buy products through a shopping cart application. After the application authenticates the user, the user’s information, including shipping information, billing information, and items in the shopping cart, is retained for subsequent requests. The session state is maintained until the user completes or cancels the purchase.
Table 8.7 lists common Web application types and their requirements for affinity provided by cluster port rules.
Table 8.7 Web Applications and Their Requirements for Port Rule Affinity
| Web Application | Description | Requires Port Rule Affinity |
|---|---|---|
Static, HTML-based applications |
Application maintains no user information. |
|
Static, HTML-based applications with CGI |
CGI portion of the application might retain user information. |
.gif "Table Bullet") |
Web application that uses client-side cookies |
Application sends a cookie to the client when the application session is initiated. On subsequent requests, the client sends the cookie along as part of the request. The instance of the application running on individual cluster hosts is capable of retrieving application session state by using the cookie in the request. |
|
ASP.NET applications with session state persistence |
ASP.NET applications support a method for maintaining session state on a centralized session state server or on a server running SQL Server 2000. Because the session state is managed centrally, any cluster host can recover session state information, and affinity is not required. For more information about ASP.NET application session state, see "Deploying ASP.NET Applications in IIS 6.0" in Deploying Internet Information Services (IIS) 6.0, or see "Deploying ASP .NET Applications in IIS 6.0" at the Microsoft Web site. |
|
ASP applications and ASP.NET applications without session state |
These applications create session information when the user first starts the application. The session information is managed by the instance of the ASP or ASP.NET dynamic-link libraries (DLLs) running on the cluster host. On subsequent requests, the session state is maintained for the application on that specific cluster host. No session state information is shared among cluster hosts. |
|
For applications that are written by your organization, consult with the application developers to determine if, or how, any session information is retained. When your applications run on Terminal Services, port rule affinity is required.
Identifying session-oriented protocols that require affinity
Even when the application or service is stateless, the protocol required by the application or service might be session-oriented. For example, an application might be based on static HTML, but it might use SSL to provide security.
However, other session-oriented protocols, such as SSL, can operate correctly without affinity, but they incur a significant decrease in performance. When an SSL session is established with a cluster host, an SSL session ID is exchanged between the cluster host and the client. If the client makes a subsequent request to the same cluster host, the same session ID can be used.
If the client makes a subsequent request to a different cluster host, a new session ID must be obtained. The overhead for obtaining a new SSL session ID is five times more than for reusing a session ID. By using port rule affinity, SSL session IDs are reused whenever possible.
Compensating for Differences in System Resources
During the IT life cycle of your cluster, new cluster hosts might be added to the cluster. These new cluster hosts are typically new computers with improved system resources, such as processor speed, number of processors, or memory. Because of the improved system resources, the new cluster hosts are capable of servicing more clients.
The default port rule, created during the installation of Network Load Balancing, evenly distributes network requests among cluster hosts, regardless of the available system resources on individual cluster hosts. Cluster hosts with inadequate system resources can provide slower response times to clients than other cluster hosts with adequate system resources. You can compensate for differences in available system resources on individual cluster hosts by directing a higher percentage of client requests to the cluster hosts with adequate system resources.
The method of compensating for the differences in system resources is based on the filter mode in the port rule. Only the Multiple Hosts port filter mode supports compensating for differences in cluster host resources. For more information about port rule filter modes and, specifically, the Multiple Hosts port filter mode, see "Specifying the Affinity and Load-Balancing Behavior of the Custom Port Rule" later in this chapter.
Deciding to Include Virtual Clusters
In some instances, you might want a cluster to appear logically as multiple Network Load Balancing clusters. In Network Load Balancing, you can define virtual clusters that allow you to apply a unique set of port rules to each virtual cluster.
Include virtual clusters in the following situations:
An application or service running on a cluster must exhibit different affinity behavior.
For example, you might have an FTP site hosted on multiple servers running IIS 6.0. You want FTP downloads to be load balanced across all cluster hosts. However, you want FTP uploads to be sent only to one cluster host. You can create a virtual cluster that supports FTP downloads with no affinity and another virtual cluster that directs FTP uploads to a specific cluster host.
Multiple applications or services running on the same cluster require different affinity behaviors for the same client traffic type (same TCP/UDP port number).
For example, you might have two Web applications hosted on the same cluster running IIS 6.0. Both applications use HTTP (TCP port 80), but one application maintains session state while the other application does not. You can create a virtual cluster that supports the application that maintains session state with affinity and another virtual cluster that supports the stateless application without affinity.
The maintenance and operations of an application or service must be independent of other applications and services running on the cluster.
For example, you might have two applications hosted on the same cluster. For ease of maintenance, upgrade, or other operations tasks, you can create a virtual cluster for the application. You can stop client communication with the virtual cluster and then perform application maintenance without affecting other applications running on the cluster.
Tip
- You can stop client communications with a virtual cluster by using the drain parameter from Nlb.exe or Network Load Balancing Manager, both of which are a part of Windows Server 2003.
Virtual clusters are specialized port rules that require a virtual IP address, which is assigned to the virtual cluster. You define a virtual cluster by specifying one or more port rules that share the same virtual IP address. As with regular port rules, the port rules that define the virtual cluster must be the same for all cluster hosts in the cluster. For more information about port rule specifications, see "Specifying Client Traffic To Be Affected by the Custom Port Rule" later in this chapter.