ISA Load Balancing decisions

More copy and paste from documentation.

 

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.

 

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 http://*/status.htm as the URL, two connectivity verifiers will be created: http://A/status.htm and http://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 http://*: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.

 

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.

 

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.

 

To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP, use the Exchange Web Client Access Publishing Rule Wizard.

 

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.

 

 

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.

 

 

 

Adding this just due to the fact that this is something that could easily be forgotten. In the interest of reducing overhead, clear text (port 80) traffic could be employed between the ISA and the CAS server. However, if Basic authentication is used, this results in clear text passwords being transmitted across DMZ and internal LAN networks.

To publish a farm of Outlook Web Access servers or Outlook RPC-over-HTTP, use the Exchange Web Client Access Publishing Rule Wizard.

Interesting bits from ISA documentation

Pulled some items worth review from the ISA documentation. Here are some sizing parameters and other random pieces that jumped out today:

 

Using the /3GB Boot.ini Switch

For large systems with over 2 GB of memory, Windows Server 2003 and Windows 2000 Advanced Server offer the 4GT RAM tuning feature. This feature divides a process memory space into 3 GB for application memory and 1 GB for system memory. This feature enables processes to benefit from more than 2-GB RAM in user space, and is enabled by adding the switch /3GB to the Boot.ini file. (For details, see article Q171793, "Information on Application Use of 4GT RAM Tuning," in the Microsoft Knowledge Base.)

This feature may be beneficial for ISA Server, especially for reverse caching hosting a large Web site. However, using this feature reduces the maximum size of the nonpaged pool (to 128 MB instead of 256 MB), hence the maximum number of concurrent TCP connections.

 

MSDE logging vs. File logging

In comparing the two methods, MSDE has more features, but it uses more system resources. Specifically, you can expect an overall 10 to 20 percent improvement in processor utilization when switching to file logging from MSDE.

 

Connections and some virtual stats

Measurements of a remote procedure call (RPC) over Secure HTTP (HTTPS) publishing scenario on a dual-core, dual-processor 2.2 GHz server with 8 GB of RAM showed the following:

•		A single installation of ISA Server on a host computer handled 40000 concurrent connections with approximately 2 GB of virtual memory.
•		Three ISA Server computers installed on three virtual operating systems handled 60000 concurrent connections with only 1.3 GB used by each virtual computer. This model could be scaled out to more virtual computers (for example, four, eight, and so on) depending on the amount of RAM and the processing power of the hosting server. The tests were run on three computers.
•		CPU utilization in both cases was almost the same.

 

Scaling Out ISA Server - Using Windows Network Load Balancing

NLB is implemented at the operating system level. It provides evenly distributed load balancing and supports fault tolerance. (Other servers in the cluster can detect a failing server and distribute its load between them.) However, it requires CPU processing overhead (approximately 10 to 15 percent for common ISA Server scenarios), and has a limit to the number of members in the cluster (approximately 8 computers as the recommended maximum).

 

NLB requires 15 percent performance overhead when enabled. An NLB array with a single member will perform 15 percent less than the same array with NLB disabled. Therefore, when estimating capacity with NLB scale-out, it is necessary first to factor down the throughput values for a single computer by 15 percent, and then apply the scale factors.

 

Guitar Hero junkie

Okay, so the wife buys me Guitar Hero 2 (my first Guitar Hero game) and a Playstation. I am already busy, but I now have to squeeze in five to ten songs on Guitar Hero every night now as well. I have had the game for a week and a half at this point. I have beaten the Easy and Medium levels of Guitar Hero 2.

It seems wrong that there are three other games for Guitar Hero, not to mention an Aerosmith version coming out this year. Maybe I should just give up on sleep all together.

Rain, Rain go away

I have been fighting rain all night. All of Texas is under a flash flood watch, but we were actually flash flooding. The water got all the way up to the back door. It did not come in and I has now dropped considerably in the past two hours.

I now have to stay home tomorrow to assess what washed away, what washed in, and then get the wife and kiddos back home.

RTFM

First, let me state that I hate meetings. Add to that a meeting that has no point/value and I am already starting to show the small bubbles. You know, the ones right before a pot goes into full boil.

For instance, I received a meeting invite today from a colleague that has blocked out one hour of my schedule this week to discuss Exchange 2007 'remote' servers with me and a few others in our group. Reviewing the meeting request, I see that the total attendee count is seven. So seven hours of man-time carved out to discuss:

…to determine how to handle Remote Exchange 2007 Sites especially as it pertains to Remote Access and Server Roles.

What About Client Access Role? Should we use the DFW CAS servers to support them?

I have multiple layers of frustration on this. The person calling the meeting was the first on our team to tackle an Exchange 2007 migration and was instructed to document his process through this migration. As a result we would all have base documentation to customize and continue building out over the next few months. So far I don't believe there has been one document produced as part of this effort. So now as I sit working on an Exchange 2007 deployment, I am being required to generate documents from scratch that I should have been able to just customize from stock documents.

But back to the real point here… Instead of wasting time in a meeting, lets read paragraph 3 from the Microsoft online documentation for Exchange 2007. That paragraph states:

You must have the Client Access server role installed in every Active Directory site within your organization that contains an Exchange 2007 server that has the Mailbox server role installed.

Sounds like "RTFM" is definitely in order for this one. Reading (and comprehending) that line could be worth seven man-hours this week.

-----------------------------

Update: I sent an e-mail copying and pasting verbiage from Microsoft documentation showing that this was a question specifically answered in readily available product documentation.

This morning I received the following response:

That is the kind of input I wanted

Ugh! you mean you wanted someone to copy and paste documentation and send it to you? And the meeting still hasn't been cancelled.

First go ‘round

I'll give this a shot. I have been been looking for a good place to rant and place information I found to be useful. Good luck making sense out of my ramblings, but if you find it helpful... Then good.