Web Server Farm Load Balancing in ISA Server 2006

  • Article

Web server farm load balancing enables administrators of Microsoft® Internet Security and Acceleration (ISA) Server 2006 to publish a farm of Web servers performing the same role, or hosting the same content, to do the following:

  • Implement load balancing to distribute requests evenly among available servers.
  • Detect offline servers and implement consistent failover.
  • Allow draining, removing, and adding server farms without disrupting current connections.

Although you can publish a hardware load balancing device to balance traffic to Web servers, ISA Server Web farm load balancing provides a number of advantages:

  • Hardware load balancing devices may use source IP addresses to balance requests, and this may not be viable when balancing requests from clients situated behind network address translation (NAT) devices. For Web publishing requests, if ISA Server is not configured to forward the original client IP address to a published server, the source IP address for requests will be that of the ISA Server computer.
  • Although one solution to the source IP issue is to configure ISA Server to forward the original client IP address, this may be difficult to scale. It requires the ISA Server computer to be configured as a default gateway on published servers, so that the published server uses the ISA Server computer for responses to the Internet.
  • The Web farm load balancing feature eliminates the need to purchase a load balancing hardware device, thus saving costs.

Web server farms

ISA Server allows you to group Web servers that share the following characteristics:

  • All servers in the farm contain the same information, for example, mirrored servers.
  • All servers in the farm perform the same function, for example, published Microsoft Outlook® Web Access servers.

Web servers are grouped into a farm by creating a server farm object. ISA Server treats all the Web servers in the farm as a single entity. When you create a Web server farm, you specify the following:

  • The computer names or IP addresses of Web servers to be included in the farm. Computer names must be resolvable to IP addresses.
  • A method for monitoring connectivity to each server in the farm. Methods include a URL request, a PING request, or a TCP request to a specific port. Based on the method you choose, ISA Server automatically creates a connectivity verifier for each server in the farm. All servers in the farm use the same type of connectivity verifier. A connectivity verification request is sent every 30 seconds to each Web farm member, and the response time is compared with a default time-out response threshold of 5,000 milliseconds. ISA Server uses the response to determine the state of servers in the farm. Note the following limitations when selecting a URL request as the connectivity method for Web farm monitoring:
    • URL requests are supported for Web servers whose names contain English characters only.
    • The URL you specify should be prefixed with an asterisk (*). ISA Server will replace the asterisk with the name of each server in the farm. For example, if you have a farm with servers A and B, and you specify https://*/status.htm as the URL, two connectivity verifiers will be created: https://A/status.htm and https://B/status.htm.
    • In most cases, you must enable the system policy rule Allow HTTP/HTTPS requests from ISA Server to selected servers for connectivity verifiers. However, if you specify a nonstandard port in the URL (for example https://*:88/status.htm), the predefined system policy rule cannot be used. Instead, you must create a custom access rule to allow HTTP and HTTPS traffic from ISA Server to the Web farm on the custom port.
    • When configuring a URL request, you can specify a custom host header to be included in the connectivity verification request. This is useful if a Web application published by the farm requires a specific host header.

After creating the server farm object using the New Server Farm Wizard, you can configure the following additional properties in the property pages of the server farm object:

  • Modify the time-out response for the connectivity verifier. By default, ISA Server sets the time-out response threshold to 5,000 milliseconds.
  • For monitoring purposes, you can specify that an alert should be triggered if a response is not received within the time threshold specified.

Load Balancing Affinity

ISA Server can use session affinity (cookie-based load balancing) or IP affinity (source IP-based load balancing) to implement the load balancing algorithm.

Session affinity

The aim of session affinity is to evenly spread client sessions (where a session is a number of consecutive Web requests that share the same TCP connection) among Web farm members. Session affinity does not support an uneven distribution of requests (for example, 50 percent of traffic to Server 1 in the farm, 20 percent of traffic to Server 2, and so on). Instead, session affinity uses a round-robin mechanism to ensure that browser sessions with a Web application serviced by a Web farm are distributed fairly among farm members that are online.

All replies to HTTP requests originating from a client browser session are sent to the original client. We recommend that you use session affinity when possible, because it provides more reliable client affinity when a Web server is restarted. This is sometimes referred to as client stickiness. Stickiness is ensured using a cookie inserted by ISA Server in the response to client requests. The cookie is sent by the client’s browser in further requests and indicates to ISA Server which server in the farm to connect to.

Session affinity is suited to publishing Outlook Web Access servers and Microsoft Windows® SharePoint® Services sites. It is not useful in Exchange RPC-over-HTTP publishing, where the client application is an instance of Outlook rather than a Web browser, and cannot handle cookies.

IP affinity

The aim of IP affinity is to evenly spread requests from different IP addresses among Web farm members. The even spread is preserved during failover. For failover, servers that are not responding are detected, and load distributed among available servers. ISA Server administrators can remove a server from a farm in a two-step process without disconnecting existing client requests.

IP affinity should not be used when remote clients are located behind a NAT device, or if ISA Server functions as an upstream server, and sees only the IP address of the downstream ISA Server computer. In this case, you should use session affinity only.

IP affinity is particularly useful in an Exchange RPC-over-HTTP scenario, where session affinity cannot be used because cookies are not supported by the Outlook client application.

Monitoring Web Farm Status

The connectivity verifiers created automatically when you create the server farm are used to detect the state of each server farm member. The state of each server can be any of the following:

  • Active   This is the normal state of a server added to the farm. It indicates that the server can accept requests to the farm.
  • Out-of-service   This state indicates that the connectivity verifier for the server farm member did not receive a response within the specified time-out (5,000 milliseconds by default). No requests are sent to this farm member.
  • Draining   This status indicates that the server is in the process of being drained. It is finishing requests in process, but no new requests will be sent to this server.
  • Removed   This indicates that the server has been removed from the farm, and is not accepting requests.
  • Unable to verify   This indicates that the server state cannot be verified.

Requests are balanced between servers that are online. When an offline server comes back online and is detected by the connectivity verifier, it is added back to the load balancing algorithm.

You can check the status of farm members in the Connectivity Verifiers tab on the Monitoring node of ISA Server Management. A green check mark icon indicates that the response time from the Web farm member is less than the time-out response threshold. A red error icon indicates that the connectivity verifier did not receive a response within the time threshold. The actual response time is shown in the Threshold column, and the status is shown in the Result column.

Draining and Removing Servers

Prior to taking down a server for maintenance, you should set the state of a Web farm member to Drained. For session affinity, the server will continue to handle current client sessions, but will not accept new ones. When offline servers come online again, they are again included in the round-robin algorithm. For IP affinity, a drained server stops receiving requests, but existing connections to that server are maintained. After draining a server, you can perform the required maintenance and then resume the server in the array, or remove it from the farm.

Publishing a Web farm

You publish a Web farm in the same way that you publish a single Web server, using the ISA Server publishing wizards, as follows:

  • To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP, use the Exchange Web Client Access Publishing Rule Wizard.
  • To publish a farm of servers running SharePoint Portal Server, use the SharePoint Site Publishing Rule Wizard.
  • To publish a Web site farm, use the Web Site Publishing Rule Wizard.

When you run any of these wizards, you must specify the following values:

  • Specify a name for the rule.
  • In the case of Outlook Web Access publishing, specify the mail services that you want to publish.
  • Select to publish a server farm of load balanced servers.
  • Specify an HTTP or HTTPS connection between ISA Server and the Web farm. If client credentials are sent by ISA Server to the published Web server, an HTTPS connection ensures that credentials are protected.
  • Specify an internal site name. When publishing a single Web server, the internal site name is used by ISA Server to locate the published server. When you publish a Web server farm, the internal name is not used by ISA Server in this way. Instead, it is used as follows:
    • The internal name may be used for link translation. Web pages returned by a published Web server may include links to internal computer names and sites that cannot be resolved by external clients. To avoid broken links, the ISA Server Link Translation filter uses mapping to translate these internal links to publicly resolvable names. For each Web publishing rule, ISA Server automatically maps the internal name specified in the rule to the public name specified in the rule. For the internal name in the Web farm rule, you should specify the name that internal users will use to access the farm, and the internal name with which the Web farm might be referenced on Web pages and e-mail messages that external users may receive. If an application uses absolute links to itself, the internal site name should be the host name in those links.
    • When a browser application generates a request, it includes a host header that identifies the host specified by the user in the URL. By default, when ISA Server receives the request, it changes this host header to the internal name, and will use the internal site name you specified as the host header when connecting to Web servers in the farm. If you choose to use the original client host header instead of the ISA Server default setting, the internal name is not used.
    • When you configure a Web farm in an HTTPS-to-HTTPS bridging scenario, you can deploy a unique certificate on each server farm member, or use a single certificate for the Web farm object. If you use a single certificate, you must use the internal name specified in the publishing rule as the common name when creating the certificate.
    • Even if you do not need to make a Web farm available internally or account for link translation, the ISA Server rules engine needs to resolve the internal site name. In this case, we recommend that you set the internal name to the Domain Name System (DNS) name of one of the servers in the farm.
  • Select the server farm you want to publish. If you have not previously created a server farm object, you can create it in the publishing wizard.
  • Specify the public name that external users will type into the browser to access the published Web farm.
  • Specify a Web listener to be used for the rule. The Web listener object specifies whether clients will connect to the ISA Server computer over HTTP or HTTPS, the network on which the listener listens for client requests, compression of content if requested by clients, the IP addresses on which the listener listens for requests, client authentication requirements, and the certificate for the listener if an HTTPS connection is used. You can select a single certificate for the Web listener, or a certificate for a specific IP address. You cannot bind multiple certificates to a single IP address.
  • Specify the authentication method ISA Server will use to authenticate to the published server, and user authentication requirements for the rule.

Load Balancing in Secure Publishing Scenarios

When load balancing HTTPS requests for Web farm resources, note the following:

  • Load balancing is not supported for Secure Sockets Layer (SSL) connections tunneled through ISA Server (server publishing). It is only supported in Web publishing, when the HTTPS connection is terminated on the ISA Server computer, and then forwarded over HTTP or HTTPS to the Web farm (HTTPS bridging).
  • For HTTPS bridging scenarios, both IP affinity (source IP-based) and session affinity (cookie-based) are supported.
  • In an HTTPS-to-HTTPS bridging scenario, the servers in the Web farm authenticate to the ISA Server computer with a server certificate. You can deploy these certificates as follows:
    • Deploy a server certificate on each server in the Web farm. For example, if the server farm consists of Server1.internal.net, Server2.internal.net, and Server3.internal.net, you must acquire a unique certificate for each server, with the name of the farm member as it appears in the server farm object.
    • Alternatively, deploy a server certificate for the Web farm object. In this case, you acquire a certificate with the internal name you specified for the Web publishing rule for the farm, and deploy the certificate on each server in the Web farm.