I came across the "source" load balancing algorithm in HAProxy, which ensures that a user will connect to the same server, by choosing server based on a hash of the source IP.
Why and when is it important for a user to connect to the same server? I cannot think of a reason, assuming that all candidate servers serve identical content.
Furthermore, if there was the need for a user to always connect to the same server, then wouldn't load balancing be completely irrelevant for this user?
It is important for a user to connect to the same server if we want to achieve session persistence.
For example, when talking about a HTTP session, there are information/variables (think about a shopping cart) specific to the session in question.
This dynamic information is not shared by the candidate servers in case they are not configured to do so and it is simpler to deal with it at the load-balancing level.
The preferred way to deal with this in HAProxy is by using cookies, but this only works in HTTP mode. HAProxy offers the source load balancing algorithm, in case cookies can't be used. This can be used in TCP mode or with HTTP clients that refuse cookies.
Load balancing will be irrelevant for the user in question right, until the cookie expires. But we generally need load balancing when dealing with many users so that they can be served by multiple servers with each user sticking with one of them.
Related
I heard that to alleviate the web server of the burden of performing the SSL Termination, it is moved to load balancers and then HTTP connection is made from the LB to the web server. However, in order to ensure security, an accepted practice is to re encrypt the data on the LB and then transmit it to the web server. If we are eventually sending the encrypted data to the web servers, what is the purpose of having a LB terminate SSL in the first place ?
A load balancer will spread the load over multiple backend servers so that each backend server takes only a part of the load. This balancing of the load can be done in a variety of ways, also depending on the requirements of the web application:
If the application is fully stateless (like only serving static content) each TCP connection can be send to an arbitrary server. In this case no SSL inspection would be needed since the decision does not depend on the content of the traffic.
If the application is instead stateful the decision which backend to use might be done based on the session cookie, so that requests end up at the same server as the previous requests for the session. Since the session cookie is part of the encrypted content SSL inspection is needed. Note that in this case often a simpler approach can be used, like basing the decision on the clients source IP address and thus avoiding the costly SSL inspection.
Sometimes load balancers also do more than just balance the load. They might incorporate security features, like a Web Application Firewall, they might sanitize the traffic or similar. These features work on the content so SSL inspection is needed.
I am trying to understand how reverse proxy and load balancing are different from each other. When its useful to use reverse proxy over load balancing.
Both promise to improve efficiency and sits in between client and server. They nearly look the same when we try to understand them, but still their functionality differs.
Load balancing: Is hardware or a software unit that distributes the total load on a website by distributing it to multiple servers.
The algorithms used by load balancing should be chosen as such it makes the best use of each servers’ capacity and can provide the result as fast as possible.
Load balancers are of three categories: DNS Round Robin, L3/L4 Load Balancer [ works on IP and TCP layer ], and L7 Load Balancer [ works on application layer].
The different kinds of algorithms used by load balancer for distributing load are IP Hash, Least connection, Round robin, Least traffic, etc.
Reverse Proxy: They act as a face of website or we can say they serve as a gateway that web traffic has to pass. The main role of a reverse proxy is:
Security: They act as a wall to your backend server. Protecting the backend from direct interactions and thus improving the security of the overall system.
Web acceleration: It also provides features like caching, SSL encryption, and Compression to reduce the time to provide responses to clients.
Flexibility: The changes in backend architecture become more flexible as the client can only access the reverse proxy.
A reverse proxy can even be relevant even when there is only one server in your system. In such cases there is no requirement of load balancers but still the reverse proxy can be useful providing security, flexibility and web acceleration.
According to this link,
A reverse proxy accepts a request from a client, forwards it to a server that can fulfill it, and returns the server’s response to the client. In other words, Reverse proxies act as such for HTTP traffic and application programming interfaces.
A load balancer distributes incoming client requests among a group of servers, in each case returning the response from the selected server to the appropriate client. Load balancers can deal with multiple protocols — HTTP as well as Domain Name System protocol, Simple Message Transfer Protocol and Internet Message Access Protocol. A load balancer receives and routes client requests for application, text, image or video data to any server in a pool that is capable of fulfilling them and then returns the server’s response to the client.
Suppose we have two servers serving requests through a load balancer. Is it necessary to have web server in both of our servers to process the requests. Can load balancer itself act as a web server. Suppose we are using apache web server and HAProxy. So does that mean that web server(Apache) should be installed in both the server and load balancer in any one of the server. Why can't we have load balancer in both of our server machine that will be receiving the request and talking to each other to process the requests.
At the very basic, you want to have Webservers fulfill requests for static contents, while Application servers handle business logics, i.e. handle requests for dynamic contents.
But Web servers can do many other things as well such as authenticate and validate requests, logging metrics. Also, the important part of Webserver is putting the Content it gets from Application servers with a View for client to represent.
You want to have LB sitting in front of both Web and App servers if you have more than one server. Also, there's nothing preventing you from putting both Web and App server in one.
The load balancer is in front of your webserver(s) to redirect requests according to number of sessions, a hash of source IP and destination IP, requested URL or other criteria. Additionally, it will check availability of the backend servers to ensure requests get answered even if one server fails.
It's not installed on every webserver - you only need one instance. It could be a hardware appliance, or a software (like HAproxy) which may or may not be installed on one of the webservers. Although this would not be prudent, as this webserver could fail and then the proxy would not be able to redirect traffic to the remaining server.
There are several different scenarios for this. One is load balancing requests to 2 webservers which serve the same HTML content, to provide redundancy.
Another would be to provide multiple websites using just one public address, i.e. applying destination NAT according to the requested URL. For this, the software has to determine the URL in the HTML request and redirect traffic to the backend webserver servicing this site. This sometimes is called 'reverse proxy' as it hides the internal server addresses from the outside.
what's the best way to achieve high availability for a dynamic website? If I create a second copy on another server and do not wish to use a load balancer since it will mess up user sessions, what are the best alternatives?
You can store session data in a database instead, which gets around that problem, then you can round-robin the requests to the application servers.
(Good) Load Balancers can be configured to be "sticky" which means they send requests from the same IP to the same server each time.
Even if you have a load balancer sitting infront of two backend webservers, you just move the single point of failure onto the load balancer instead of the webserver. So your application would still not be highly available.
I highly recommend using a load balancer and at least a pair of web servers. At work, we use HA Proxy, which is fully capable of ensuring sessions are 'sticky', and are sent to the same web server unless it goes down, where it will fail over.
To make your load balancer highly available, you can set up two load balancing servers which are a mirror image of each other. Assign a single virtual IP to both of your load balancers. Write a script that will poll the other server to check if it's down; if it's down, have that script pick up that virtual IP address. The script should be running on both servers.
This link describes one way of managing a virtual IP address. Similar articles have been written for a large number of linux distros, but they are all based on the same method.
Loadbalancers. They should be configured in such a way that they can handle the sessions. Maybe by sending the same ip to the same backend every time. Or store them inside a database, or some shared memory if it needs to be really fast for some reason i haven't thought of.
From what I understand, if you have multiple web servers, then you need some kind of load balancer that will split the traffic amongst your web servers.
Does this mean that the load balancer is the main connecting point on the network? ie. the load balancer has the IP address of the domain name?
If this is the case, it makes it really easy to add new hardware since you don't have to wait for any dns propogation right?
There are several solutions to this "problem".
You could round-robin at the DNS-level. I.e. have www.yourdomain.com point to several IP-addresses (well all your servers).
This doesn't give you any intelligence in the load balancing, but the load will be more or less randomly distributed, but you wouldn't be resilient to hardware failures as they would still require changes to DNS.
On the other hand you could use a proxy or a loadbalancing proxy that has a single IP but then distributes the traffic to several back-end boxes. This gives you a single point of failure (the proxy, you could of course have several proxies to defeat that problem) and would also give you the added bonus of being able to use some metric to divide the load more evenly and intelligently than with just round-robin dns.
This setup can also handle hardware failure in the back-end pretty seamlessly. The end user never sees the back-end, just the front-end.
There are other issues to think about as well, if your page uses sessions or other smart logic, you can run into synchronisation problems when your user (potentially) hits different servers on every access.
It does (in general). It depends on what server OS and software you are using, but in general, you'll hit the load balancer for each request, and the load balancer will then farm out the work according to the scheme you have in place (round robin, least busy, session controlled, application controlled, etc...)
andy has part of the answer, but for true load balancing and high availability you would want to use a pair of hardware load balancers like F5 bigips in an active passive configuration.
Yes your domain IP would be hosted on these devices and traffic would connect firstly to those devices. Bigips offer a lot of added functionality including multiple ways of load balancing and some great url rewriting, ssl acceleration, etc. It also allows you to run your web servers on a seperate non routable address scheme and even run multiple sites on different ports with the F5's handling the translations.
Once you introduce load balancing you may have some other considerations to take into account for your application(s) like sticky sessions and session state but that is a different subject