Understanding load balancing and port usage

For the portals to function correctly in a production environment, your load balancer must have session affinity, or "sticky sessions." This enables the load balancer to bind a user’s session to a specific machine, so all requests made during that session are sent to the same machine. For the IPF portals, the load balancer must be configured to use the ASP.NET_SessionId HTTP cookie for tracking the user’s machine for each request.

If you are using the standard IPF reverse proxy, then the load balancer is used twice. The request first hits the load balancer for the original request URL; for example, https://portal.acme.com/IPFSitePages/OrderStatus.aspx. In this case, the load balancer does not have to be sticky and can send the request to any machine in the farm when going to the IPFReverseProxy.

Next, the IPFReverseProxy handles the URL rewrite using the host name that load balances all servers in the farm. This rewrite host name is specified on the Load Balancers tab in the Farm Manager and is used to generate the rewrite IDs for each IPF instance.

The rewrite host name can be the same as the host name. For example, if portal.acme.com is the host name, the rewritten URL can be: http://portal.acme.com:14300/https/portal.acme.com.443/IPFSitePages/OrderStatus.aspx. In this case, the load balancer must be sticky on the ASP.NET_SessionId HTTP cookie when the port is 14300. In addition, the load balancer may require configuration to ensure that traffic on port 14300 is forwarded.

If there are multiple IPFinstances in the farm, IPF uses 14301, 14302, 14303, and so on for each IPF instance that is running concurrently. Each of these ports may need to be set up in your load balancer with sticky sessions.

The following diagrams show ports and web traffic flows. You can use this information for setting up your production environment if you must open traffic on specific ports.