About server farms

  • Article

Server farm load balancing enables administrators of Microsoft Forefront Threat Management Gateway to publish a farm of Web servers that perform the same role or host the same content to do the following:

  • Implement load balancing to distribute requests evenly among available Web servers.
  • Detect offline servers and implement consistent failover.
  • Allow the draining, removal, and addition of servers without disrupting current connections.

Although you can publish a hardware load balancing device to balance traffic to Web servers, Forefront TMG server 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 Forefront TMG is not configured to forward the original client IP address to the published server, the source IP address for requests will be that of the Forefront TMG computer.
  • Although one solution to the source IP address issue is to configure Forefront TMG to forward the original client IP address, this may be difficult to scale. It requires the Forefront TMG computer to be configured as the default gateway on published servers, so that the published server directs responses to the Internet to the Forefront TMG computer.
  • The server farm load balancing feature eliminates the need to purchase a load balancing hardware device, thus saving costs.

Creating server farms

Forefront TMG 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. Forefront TMG treats all the Web servers in the farm as a single entity. When you create a server farm, you specify the following:

  • The computer names or IP addresses of the 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. The possible methods include sending an HTTP GET request, a PING request, or a request to establish a TCP connection to a specific port. Based on the method you choose, Forefront TMG automatically creates a connectivity verifier for testing connectivity to all the servers in the farm. A connectivity verification request is sent every 30 seconds to each farm member, and the response time is compared with a default time-out response threshold of 5,000 milliseconds. Forefront TMG uses the response to determine the state of servers in the farm. Note the following limitations when you select sending an HTTP GET request as the connectivity verification method for server farm monitoring:
    • Sending HTTP GET requests is supported only for servers whose names do not contain non-English characters.
    • The host name in the URL that you specify should be an asterisk (*). Forefront TMG will replace the asterisk with the name of each server in the farm. For example, if you have a farm with the servers A and B, and you specify https://*/status.htm as the URL, Forefront TMG will use the URLs https://A/status.htm and https://B/status.htm for checking connectivity.
    • In most cases, you must enable the Allow HTTP/HTTPS Requests from Forefront TMG to Selected Servers for Connectivity Verifiers system policy rule. However, if you specify a non-standard 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 Forefront TMG to the server farm on the custom port.
    • When you select sending an HTTP GET request as the connectivity verification method, 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 server farm requires a specific Host header.

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

  • Modify the time-out response threshold of the connectivity verifier. By default, Forefront TMG 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 period specified.

For instruction for creating server farms, see Creating network objects.

Load balancing and client affinity

Forefront TMG can use session affinity (cookie-based load balancing) or IP address affinity (source IP address-based load balancing) to implement the load balancing algorithm.

Session affinity

Session affinity uses a cookie to identify the client and to maintain its affinity with a specific Web server. This function requires a browser that can accept HTTP cookies. Cookies are supported by all HTTP 1.1-compliant browsers and by some versions of HTTP 1.0 browsers. Session affinity is maintained until the browser is closed on the client computer.

The aim of session affinity is to evenly disperse client sessions (where a session is a number of consecutive Web requests that share the same TCP connection) among 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 server farm are distributed evenly among farm members that are online.

When session affinity is used, if a Web server, such as Web Server 1, goes out of service, the clients that are associated with it will be directed by Forefront TMG to another server, such as Web Server 2. The context of the Web session is lost when this happens. When Web Server 1 becomes available again, client affinity is maintained with Web Server 2 until the session ends.

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 Forefront TMG in the response to client requests. The cookie is sent by the client’s browser in further requests and indicates the server in the farm to which Forefront TMG should connect.

Session affinity is suited to publishing Outlook Web Access servers and SharePoint 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 it cannot handle cookies.

IP address affinity

With IP address affinity, when Forefront TMG receives a request, it determines which Web server in the farm should handle it, based on the client's IP address. Every request from that IP address will be sent to the same Web server, so affinity is maintained.

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

When IP address-based affinity is used, if a Web server goes out of service, the clients that are associated with it will be directed by Forefront TMG to another server. The context of the Web session is lost when this happens. Similarly, when that Web server is restarted, requests from those clients are directed to the original Web server, and the context is lost again.

IP address-based affinity has an advantage over session affinity in that it supports clients that are not fully compliant with HTTP 1.1 (clients that do not support HTTP cookies), such as some mobile devices.

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

IP address 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 server farm status

The connectivity verifier that is created automatically when you create a server farm is used to detect the state of each 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 sent to the farm.
  • Out-of-service. This state indicates that the connectivity verifier for the server farm did not receive a response from the server within the specified time-out period (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. The server will continue to process requests already sent to it, 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 on the Connectivity Verifiers tab on the Monitoring node of Forefront TMG Management. A green check mark icon indicates that the response time from the 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-out period. 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 server 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 address 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 server farm

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

  • To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP servers, use the Exchange Web Client Access Publishing Rule Wizard.
  • To publish a SharePoint site in a server farm, 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 do the following:

  • 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 Forefront TMG and the server farm. If client credentials are sent by Forefront TMG to the published Web server, they are encrypted when an HTTPS connection is selected.
  • Specify an internal site name. When publishing a single Web server, the internal site name can be used by Forefront TMG to obtain the IP address of the published server with which to establish a connection. When you publish a server farm, Forefront TMG does not use the internal site name in this way. The internal site name specified for a server farm is used only as follows:
    • When a browser application generates a request, it includes a Host header that identifies the host in the URL specified by the user. By default, when Forefront TMG receives the request, it changes the host name in this Host header and uses the internal site name as the host name in HTTP request messages sent to Web servers in the farm. If you choose to use the original client Host header instead of the Forefront TMG default setting, the internal site name is not used.
    • If the Web publishing rule requires a Secure Sockets Layer (SSL) connection between the Forefront TMG computer and a member of the published server farm, you can deploy a unique certificate on each farm member, or you can install copies of a single certificate on all the farm members. You must use the internal site name specified in the Web publishing rule as the common name when creating the certificate.
    • The internal site 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 Link Translation Filter uses mappings to translate these internal links to publicly resolvable names. For each Web publishing rule, Forefront TMG automatically maps the internal site name specified in the rule to the public name specified in the rule. For the internal site name in the server farm rule, you should specify the name that internal users will use to access the farm or the internal site name used to reference the server farm 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.
    • Even if you do not need to make a server farm available internally or account for link translation, the Forefront TMG rules engine needs to resolve the internal site name. In this case, we recommend that you set the internal site 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 did not previously create a server farm, you can create it in the publishing wizard.
  • Specify the public name that external users will type into the browser to access the published server farm.
  • Specify a Web listener to be used for the rule. The Web listener specifies whether clients will connect to the Forefront TMG 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 SSL 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 that Forefront TMG will use to authenticate to the published server.

Load balancing in secure publishing scenarios

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

  • Load balancing is not supported for SSL connections tunneled through Forefront TMG (server publishing). It is only supported in Web publishing, when the HTTPS connection is terminated on the Forefront TMG computer and then forwarded over HTTP or HTTPS to the server farm (HTTPS-to-HTTP and HTTPS-to-HTTPS bridging).
  • For HTTPS bridging scenarios, both IP address (source IP address-based) affinity and session (cookie-based) affinity are supported.
  • In an HTTPS-to-HTTPS bridging scenario, the servers in the server farm authenticate to the Forefront TMG computer with a server certificate. You can deploy these certificates as follows:
    • Deploy a server certificate on each server in the server 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.
    • Alternatively, deploy a server certificate for the server farm. In this case, you acquire a certificate with the internal site name you specified for the Web publishing rule for the farm, and deploy the certificate on each server in the server farm.