We have too many algorithms for loadbalancing , which one is generally recommended. Or does the service provider which provides this facility take care of it. How do we determine that. Or does the devops team handle this
I think most commonly used is round-robin algorithm where system administrators use servers of equal power (thus not needed to account for the weight of the server).
Hi Vivek, thanks for providing this brief yet quality content about load balancing. However though i have this dumb question is reverse proxy and load balancer are essentially the same?
I have one doubt : How are we going to handle Single point of failure at Load Balancer level ? as if my load balancer goes down, automatically no servers will get any request and my system will be dead.
to avoid this problem of Load balancer acting as a single point of failure, we can deploy load balancers in a cluster where backup load balancer would takeover in case the primary load balancer is not able to serve the live traffic. This can be done using health checks on the primary load balancer.
Hey Rohith, that's a very broad question. To be honest, I haven't worked in infra, so take my suggestions with a pinch of salt.
1. Traffic: Look for where is your majority of the traffic coming from. You might want to consider keeping a load balancer there, so that your network latency for majority clients is as less as possible. But this also assumes that your application instances are distributed uniformly across all regions.
2. Cost: look for cost benefit analysis in different regions you mentioned
If you don't have as such major traffic and cost issues, my suggestion would be to consider a central region like EU to save on latency as much as possible to cater all US,EU and IND traffic.
We have too many algorithms for loadbalancing , which one is generally recommended. Or does the service provider which provides this facility take care of it. How do we determine that. Or does the devops team handle this
I think most commonly used is round-robin algorithm where system administrators use servers of equal power (thus not needed to account for the weight of the server).
Usually service provider allows you to configure your load balancer so that you can use different algorithms to try on. For example: in AWS, you can configure the routing algorithm. Study about it here: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm
Yes, most of the times in decent size companies, dedicated devops team might be handling this configuration.
Hi Vivek, thanks for providing this brief yet quality content about load balancing. However though i have this dumb question is reverse proxy and load balancer are essentially the same?
Hi Vivek, First of all great article :)
I have one doubt : How are we going to handle Single point of failure at Load Balancer level ? as if my load balancer goes down, automatically no servers will get any request and my system will be dead.
Hi Adarsh, great question.
to avoid this problem of Load balancer acting as a single point of failure, we can deploy load balancers in a cluster where backup load balancer would takeover in case the primary load balancer is not able to serve the live traffic. This can be done using health checks on the primary load balancer.
Hi Vivek, I have few doubts, in which region should I keep the load balancer, if I have my servers in US, EU, IND ?
Hey Rohith, that's a very broad question. To be honest, I haven't worked in infra, so take my suggestions with a pinch of salt.
1. Traffic: Look for where is your majority of the traffic coming from. You might want to consider keeping a load balancer there, so that your network latency for majority clients is as less as possible. But this also assumes that your application instances are distributed uniformly across all regions.
2. Cost: look for cost benefit analysis in different regions you mentioned
If you don't have as such major traffic and cost issues, my suggestion would be to consider a central region like EU to save on latency as much as possible to cater all US,EU and IND traffic.