In this blog post, App Dev Managers Anand Shukla and Sash Kavalaparambil share some tips on configuring a load balancer for web applications.

Sometimes the way a web application needs to manage state can have a profound impact on scalability and the load balancing configuration.  There are many different options (both software and hardware) to provide load balancing solutions, but they all share some core concepts.  Generally, you start by considering the application requirements for session persistence:

1. Sticky persistence: If the session data is maintained on the Web Server itself (typically in the memory – e.g. Inproc session state in ASP.NET), you would want to configure your load balancer in a way that the requests from same Client is directed to the same web server. Sticky sessions can also be used when you are dependent on local Web Server resources (such as file system).
2. Non-Sticky persistence: If the session data is maintained in a database or distributed caching system (shared by all the web servers), it does not matter which Web Server the request is routed to as all the servers will have access to the shared session store.

Load Balancers can be configured primarily in the following ways for SSL scenarios

1. SSL offloading (or SSL termination): In this configuration, the load balancer receives https request from the client (e.g. a browser), decrypts the requests and creates a new request (http or https) and sends it to the web server. Web Server sends the response back to the load balancer which in turn sends the response back to the browser. In this case, the SSL certificate needs to installed at the Load Balancer (LB) as it handles the encryption / decryption.
   It is lot easier to configure sticky persistence in SSL offloading since the LB can decrypt the request and use the underlying session cookies to route traffic to a specific Web Server. Load Balancers maintain a route table and use that to determine which request with specific session cookie goes to what backend Web Server. You can use other parameters such as Client IP etc. to determine the stickiness but using session cookie is probably the best idea.
2. Pass through: In a pass through, Load Balancer just redirects traffic coming from Client to the Web Servers. If it is an https requests, load balancer’s cannot see what is inside the request.
   In this case, there is Client IP is the most useful information that can be used to maintain stickiness. This may work primarily in a controlled Intranet environment, however, this is not optimal as many clients may have same IP (hidden behind a single IP), or Clients can change the IP during a session or sometimes a single client can use multiple IP addresses.

Ideally, you want to design applications for non-sticky persistence which adheres to rest principles and more easily scales to handle high capacity demands. In this case, it does not matter which server the request goes to and load balancers can effectively route the request to web servers using the load balancing algorithms best suited for your scenarios.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.