You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.223.0.0/16 has been blocked (disabled) by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 23:54, 31 July 2024.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:57, 18 August 2022
- Expiry of block: 13:57, 18 November 2024
Your current IP address is 44.223.83.3. The blocked range is 44.223.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((short description|Set of techniques to improve the distribution of workloads across multiple computing resources))
[[File:Elasticsearch Cluster August 2014.png|thumb|Diagram illustrating user requests to an [[Elasticsearch]] cluster being distributed by a load balancer. (Example for [[Wikipedia]].)]]

In [[computing]], '''load balancing''' is the process of distributing a set of [[Task (computing)|tasks]] over a set of [[System resource|resources]] (computing units), with the aim of making their overall processing more efficient. Load balancing can optimize the response time and avoid unevenly overloading some compute nodes while other compute nodes are left idle.

Load balancing is the subject of research in the field of [[parallel computers]]. Two main approaches exist: static algorithms, which do not take into account the state of the different machines, and dynamic algorithms, which are usually more general and more efficient but require exchanges of information between the different computing units, at the risk of a loss of efficiency.

==Problem overview==
A load-balancing algorithm always tries to answer a specific problem. Among other things, the nature of the tasks, the algorithmic [[Computational complexity|complexity]], the hardware architecture on which the algorithms will run as well as required [[error tolerance]], must be taken into account. Therefore compromise must be found to best meet application-specific requirements.

===Nature of tasks===
The efficiency of load balancing algorithms critically depends on the nature of the tasks. Therefore, the more information about the tasks is available at the time of decision making, the greater the potential for optimization.

====Size of tasks====
Perfect knowledge of the [[execution time]] of each of the tasks allows to reach an optimal load distribution (see algorithm of [[prefix sum]]).<ref name="Sequential and parallel algorithms">((cite book |last1=Sanders |first1=Peter |last2=Mehlhorn |first2=Kurt |last3=Dietzfelbinger |first3=Martin |last4=Dementiev |first4=Roman |title=Sequential and parallel algorithms and data structures : the basic toolbox |date=11 September 2019 |publisher=Springer |isbn=978-3-030-25208-3))</ref> Unfortunately, this is in fact an idealized case. Knowing the exact [[execution time]] of each task is an extremely rare situation.

For this reason, there are several techniques to get an idea of the different execution times. First of all, in the fortunate scenario of having tasks of relatively homogeneous size, it is possible to consider that each of them will require approximately the average execution time. If, on the other hand, the execution time is very irregular, more sophisticated techniques must be used. One technique is to add some [[metadata]] to each task. Depending on the previous execution time for similar metadata, it is possible to make inferences for a future task based on statistics.<ref>((cite journal |last1=Liu |first1=Qi |last2=Cai |first2=Weidong |last3=Jin |first3=Dandan |last4=Shen |first4=Jian |last5=Fu |first5=Zhangjie |last6=Liu |first6=Xiaodong |last7=Linge |first7=Nigel |title=Estimation Accuracy on Execution Time of Run-Time Tasks in a Heterogeneous Distributed Environment |journal=Sensors |date=30 August 2016 |volume=16 |issue=9 |pages=1386 |doi=10.3390/s16091386|pmid=27589753 |pmc=5038664 |bibcode=2016Senso..16.1386L |s2cid=391429 |doi-access=free ))</ref>

====Dependencies====
In some cases, tasks depend on each other. These interdependencies can be illustrated by a [[directed acyclic graph]]. Intuitively, some tasks cannot begin until others are completed.

Assuming that the required time for each of the tasks is known in advance, an optimal execution order must lead to the minimization of the total execution time. Although this is an [[NP-hard]] problem and therefore can be difficult to be solved exactly. There are algorithms, like [[job scheduler]], that calculate optimal task distributions using [[metaheuristic]] methods.

====Segregation of tasks====
Another feature of the tasks critical for the design of a load balancing algorithm is their ability to be broken down into subtasks during execution. The "Tree-Shaped Computation" algorithm presented later takes great advantage of this specificity.

===Static and dynamic algorithms===

====Static====
A load balancing algorithm is "static" when it does not take into account the state of the system for the distribution of tasks. Thereby, the system state includes measures such as the [[Load (computing)|load level]] (and sometimes even overload) of certain processors. Instead, assumptions about the overall system are made beforehand, such as the arrival times and resource requirements of incoming tasks. In addition, the number of processors, their respective power and communication speeds are known. Therefore, static load balancing aims to associate a known set of tasks with the available processors in order to minimize a certain performance function. The trick lies in the concept of this performance function.

Static load balancing techniques are commonly centralized around a router, or [[Master/slave (technology)|Master]], which distributes the loads and optimizes the performance function. This minimization can take into account information related to the tasks to be distributed, and derive an expected execution time.

The advantage of static algorithms is that they are easy to set up and extremely efficient in the case of fairly regular tasks (such as processing [[HTTP]] requests from a website). However, there is still some statistical variance in the assignment of tasks which can lead to the overloading of some computing units.

====Dynamic====
Unlike static load distribution algorithms, dynamic algorithms take into account the current load of each of the computing units (also called nodes) in the system. In this approach, tasks can be moved dynamically from an overloaded node to an underloaded node in order to receive faster processing. While these algorithms are much more complicated to design, they can produce excellent results, in particular, when the execution time varies greatly from one task to another.

Dynamic load balancing architecture can be more [[Modular design|modular]] since it is not mandatory to have a specific node dedicated to the distribution of work. When tasks are uniquely assigned to a processor according to their state at a given moment, it is a unique assignment. If, on the other hand, the tasks can be permanently redistributed according to the state of the system and its evolution, this is called dynamic assignment.<ref>((cite journal |last1=Alakeel |first1=Ali |title=A Guide to Dynamic Load Balancing in Distributed Computer Systems |journal=International Journal of Computer Science and Network Security (IJCSNS) |date=November 2009 |volume=10 |url=https://www.researchgate.net/publication/268200851))</ref> Obviously, a load balancing algorithm that requires too much communication in order to reach its decisions runs the risk of slowing down the resolution of the overall problem.

===Hardware architecture===
====Heterogenous machines====
[[Parallel computing]] infrastructures are often composed of units of different [[computing power]], which should be taken into account for the load distribution.

For example, lower-powered units may receive requests that require a smaller amount of computation, or, in the case of homogeneous or unknown request sizes, receive fewer requests than larger units.

====Shared and distributed memory====
Parallel computers are often divided into two broad categories: those where all processors share a single common memory on which they read and write in parallel ([[Parallel random-access machine|PRAM]] model), and those where each computing unit has its own memory ([[distributed memory]] model), and where information is exchanged by messages.

For [[shared-memory]] computers, managing write conflicts greatly slows down the speed of individual execution of each computing unit. However, they can work perfectly well in parallel. Conversely, in the case of message exchange, each of the processors can work at full speed. On the other hand, when it comes to collective message exchange, all processors are forced to wait for the slowest processors to start the communication phase.
 
In reality, few systems fall into exactly one of the categories. In general, the processors each have an internal memory to store the data needed for the next calculations and are organized in successive [[Computer cluster|clusters]]. Often, these processing elements are then coordinated through [[distributed memory]] and [[message passing]]. Therefore, the load balancing algorithm should be uniquely adapted to a parallel architecture. Otherwise, there is a risk that the efficiency of parallel problem solving will be greatly reduced.

====Hierarchy====
Adapting to the hardware structures seen above, there are two main categories of load balancing algorithms. On the one hand, the one where tasks are assigned by “master” and executed by “workers” who keep the master informed of the progress of their work, and the master can then take charge of assigning or reassigning the workload in case of the dynamic algorithm. The literature refers to this as [[Master/slave (technology)|"Master-Worker"]] architecture. On the other hand, the control can be distributed between the different nodes. The load balancing algorithm is then executed on each of them and the responsibility for assigning tasks (as well as re-assigning and splitting as appropriate) is shared. The last category assumes a dynamic load balancing algorithm.

Since the design of each load balancing algorithm is unique, the previous distinction must be qualified. Thus, it is also possible to have an intermediate strategy, with, for example, "master" nodes for each sub-cluster, which are themselves subject to a global "master". There are also multi-level organizations, with an alternation between master-slave and distributed control strategies. The latter strategies quickly become complex and are rarely encountered. Designers prefer algorithms that are easier to control.

====Adaptation to larger architectures (scalability)====
In the context of algorithms that run over the very long term (servers, cloud...), the computer architecture evolves over time. However, it is preferable not to have to design a new algorithm each time.

An extremely important parameter of a load balancing algorithm is therefore its ability to adapt to scalable hardware architecture. This is called the [[scalability]] of the algorithm. An algorithm is called scalable for an input parameter when its performance remains relatively independent of the size of that parameter.

When the algorithm is capable of adapting to a varying number of computing units, but the number of computing units must be fixed before execution, it is called moldable. If, on the other hand, the algorithm is capable of dealing with a fluctuating amount of processors during its execution, the algorithm is said to be malleable. Most load balancing algorithms are at least moldable.<ref>((cite book |last1=Asghar |first1=Sajjad |last2=Aubanel |first2=Eric |last3=Bremner |first3=David |title=2013 42nd International Conference on Parallel Processing |chapter=A Dynamic Moldable Job Scheduling Based Parallel SAT Solver |date=October 2013 |pages=110–119 |doi=10.1109/ICPP.2013.20 |isbn=978-0-7695-5117-3 |s2cid=15124201 ))</ref>

===Fault tolerance===
Especially in large-scale [[computing cluster]]s, it is not tolerable to execute a parallel algorithm that cannot withstand the failure of one single component. Therefore, [[fault tolerant]] algorithms are being developed which can detect outages of processors and recover the computation.<ref>((cite book |last1=Punetha Sarmila |first1=G. |last2=Gnanambigai |first2=N. |last3=Dinadayalan |first3=P. |title=2015 2nd International Conference on Electronics and Communication Systems (ICECS) |chapter=Survey on fault tolerant &mdash; Load balancing algorithmsin cloud computing |date=2015 |pages=1715–1720 |doi=10.1109/ECS.2015.7124879 |isbn=978-1-4799-7225-8 |s2cid=30175022 ))</ref>

==Approaches==

===Static distribution with full knowledge of the tasks: [[prefix sum]]===
If the tasks are independent of each other, and if their respective execution time and the tasks can be subdivided, there is a simple and optimal algorithm.

[[File:Load_Balancing_divisible_tasks.png|thumb|Load balancing algorithm depending on divisibility of tasks]]

By dividing the tasks in such a way as to give the same amount of computation to each processor, all that remains to be done is to group the results together. Using a [[prefix sum]] algorithm, this division can be calculated in [[logarithmic time]] with respect to the number of processors.((fact|date=October 2022))

If, however, the tasks cannot be subdivided (i.e., they are [[Linearizability|atomic]]), although optimizing task assignment is a difficult problem, it is still possible to approximate a relatively fair distribution of tasks, provided that the size of each of them is much smaller than the total computation performed by each of the nodes.<ref name="Sequential and parallel algorithms"/>

Most of the time, the execution time of a task is unknown and only rough approximations are available. This algorithm, although particularly efficient, is not viable for these scenarios.

===Static load distribution without prior knowledge===
Even if the execution time is not known in advance at all, static load distribution is always possible.

====[[Round-robin scheduling]]====
In a round-robin algorithm, the first request is sent to the first server, then the next to the second, and so on down to the last. Then it is started again, assigning the next request to the first server, and so on.

This algorithm can be weighted such that the most powerful units receive the largest number of requests and receive them first.

====Randomized static====
Randomized static load balancing is simply a matter of randomly assigning tasks to the different servers. This method works quite well. If, on the other hand, the number of tasks is known in advance, it is even more efficient to calculate a random permutation in advance. This avoids communication costs for each assignment. There is no longer a need for a distribution master because every processor knows what task is assigned to it. Even if the number of tasks is unknown, it is still possible to avoid communication with a pseudo-random assignment generation known to all processors.

The performance of this strategy (measured in total execution time for a given fixed set of tasks) decreases with the maximum size of the tasks.

====Others====
Of course, there are other methods of assignment as well: 
* Less work: Assign more tasks to the servers by performing less((clarify|date=November 2022)) (the method can also be weighted).
* Hash: allocates queries according to a [[hash table]].
* Power of Two Choices: pick two servers at random and choose the better of the two options.<ref>((cite web |title=NGINX and the "Power of Two Choices" Load-Balancing Algorithm |url=https://www.nginx.com/blog/nginx-power-of-two-choices-load-balancing-algorithm/ |website=nginx.com |archive-url=https://web.archive.org/web/20191212194243/https://www.nginx.com/blog/nginx-power-of-two-choices-load-balancing-algorithm/ |archive-date=2019-12-12 |date=2018-11-12))</ref><ref>((cite web |title=Test Driving "Power of Two Random Choices" Load Balancing |url=https://www.haproxy.com/blog/power-of-two-load-balancing/ |website=haproxy.com |archive-url=https://web.archive.org/web/20190215173140/https://www.haproxy.com/blog/power-of-two-load-balancing/ |archive-date=2019-02-15 |date=2019-02-15))</ref>

===Master-Worker Scheme===
[[Master/slave (technology)|Master-Worker]] schemes are among the simplest dynamic load balancing algorithms. A master distributes the workload to all workers (also sometimes referred to as "slaves"). Initially, all workers are idle and report this to the master. The master answers worker requests and distributes the tasks to them. When he has no more tasks to give, he informs the workers so that they stop asking for tasks.

The advantage of this system is that it distributes the burden very fairly. In fact, if one does not take into account the time needed for the assignment, the execution time would be comparable to the prefix sum seen above.

The problem with this algorithm is that it has difficulty adapting to a large number of processors because of the high amount of necessary communications. This lack of [[scalability]] makes it quickly inoperable in very large servers or very large parallel computers. The master acts as a [[Bottleneck (software)|bottleneck]].
[[File:Master-Worker_and_bottleneck.png|thumb|Master-Worker and bottleneck]]

However, the quality of the algorithm can be greatly improved by replacing the master with a task list that can be used by different processors. Although this algorithm is a little more difficult to implement, it promises much better scalability, although still insufficient for very large computing centers.

===Non-hierarchical architecture, without knowledge of the system: [[work stealing]]===
Another technique to overcome scalability problems when the time needed for task completion is unknown is [[work stealing]].
 
The approach consists of assigning to each processor a certain number of tasks in a random or predefined manner, then allowing inactive processors to "steal" work from active or overloaded processors. Several implementations of this concept exist, defined by a task division model and by the rules determining the exchange between processors. While this technique can be particularly effective, it is difficult to implement because it is necessary to ensure that communication does not become the primary occupation of the processors instead of solving the problem.

In the case of atomic tasks, two main strategies can be distinguished, those where the processors with low load offer their computing capacity to those with the highest load, and those were the most loaded units wish to lighten the workload assigned to them. It has been shown<ref>((cite journal |last1=Eager |first1=Derek L |last2=Lazowska |first2=Edward D |last3=Zahorjan |first3=John |title=A comparison of receiver-initiated and sender-initiated adaptive load sharing |journal=Performance Evaluation |date=1 March 1986 |volume=6 |issue=1 |pages=53–68 |doi=10.1016/0166-5316(86)90008-8 |language=en |issn=0166-5316))</ref> that when the network is heavily loaded, it is more efficient for the least loaded units to offer their availability and when the network is lightly loaded, it is the overloaded processors that require support from the most inactive ones. This rule of thumb limits the number of exchanged messages.

In the case where one starts from a single large task that cannot be divided beyond an atomic level, there is a very efficient algorithm "Tree-Shaped computation",<ref>((cite journal |last1=Sanders |first1=Peter |title=Tree Shaped Computations as a Model for Parallel Applications |journal=Workshop on Application Based Load Balancing (Alv '98), München, 25. - 26. März 1998 - Veranst. Vom Sonderforschungsbereich 342 "Werkzeuge und Methoden für die Nutzung Paralleler Rechnerarchitekturen". Ed.: A. Bode |date=1998 |page=123 |doi=10.5445/ir/1000074497))</ref> where the parent task is distributed in a work tree.

====Principle====
Initially, many processors have an empty task, except one that works sequentially on it. Idle processors issue requests randomly to other processors (not necessarily active). If the latter is able to subdivide the task it is working on, it does so by sending part of its work to the node making the request. Otherwise, it returns an empty task. This induces a [[tree structure]]. It is then necessary to send a termination signal to the parent processor when the subtask is completed so that it, in turn, sends the message to its parent until it reaches the root of the tree. When the first processor, i.e. the root, has finished, a global termination message can be broadcast. In the end, it is necessary to assemble the results by going back up the tree.

====Efficiency====
The efficiency of such an algorithm is close to the prefix sum when the job cutting and communication time is not too high compared to the work to be done. To avoid too high communication costs, it is possible to imagine a list of jobs on [[shared memory]]. Therefore, a request is simply reading from a certain position on this shared memory at the request of the master processor.

==Use cases==
In addition to efficient problem solving through parallel computations, load balancing algorithms are widely used in [[HTTP]] request management where a site with a large audience must be able to handle a large number of requests per second.

===Internet-based services===
((Multiple issues|section=y|
((cleanup|section|date=December 2010))
((more citations needed|article's section|date=December 2010))
))

One of the most commonly used applications of load balancing is to provide a single Internet service from multiple [[Server (computing)|server]]s, sometimes known as a [[server farm]]. Commonly load-balanced systems include popular [[web site]]s, large [[Internet Relay Chat]] networks, high-bandwidth [[File Transfer Protocol]] (FTP) sites, [[Network News Transfer Protocol]] (NNTP) servers, [[Domain Name System]] (DNS) servers, and databases.

====Round-robin DNS====
((Main|Round-robin DNS))

[[Round-robin DNS]] is an alternate method of load balancing that does not require a dedicated software or hardware node. In this technique, multiple [[IP address]]es are associated with a single [[domain name]]; clients are given IP in a round-robin fashion. IP is assigned to clients with a short expiration so the client is more likely to use a different IP the next time they access the Internet service being requested.

====DNS delegation====

Another more effective technique for load-balancing using DNS is to delegate ((mono|www.example.org)) as a sub-domain whose zone is served by each of the same servers that are serving the website. This technique works particularly well where individual servers are spread geographically on the Internet. For example:
<pre>one.example.org A 192.0.2.1
two.example.org A 203.0.113.2
www.example.org NS one.example.org
www.example.org NS two.example.org
</pre>
However, the zone file for ((mono|www.example.org)) on each server is different such that each server resolves its own IP Address as the A-record.<ref>[http://www.zytrax.com/books/dns/ch8/a.html IPv4 Address Record (A)]</ref> On server ''one'' the zone file for ((mono|www.example.org)) reports:
<pre>@ in a 192.0.2.1
</pre>
On server ''two'' the same zone file contains:
<pre>@ in a 203.0.113.2
</pre>

This way, when a server is down, its DNS will not respond and the web service does not receive any traffic. If the line to one server is congested, the unreliability of DNS ensures less HTTP traffic reaches that server. Furthermore, the quickest DNS response to the resolver is nearly always the one from the network's closest server, ensuring geo-sensitive load-balancing ((Citation needed|date=November 2014)). A short [[Time to live|TTL]] on the A-record helps to ensure traffic is quickly diverted when a server goes down. Consideration must be given to the possibility that this technique may cause individual clients to switch between individual servers in mid-session.

====Client-side random load balancing====
Another approach to load balancing is to deliver a list of server IPs to the client, and then to have the client randomly select the IP from the list on each connection.<ref>[https://gameserverarchitecture.com/2015/10/pattern-client-side-load-balancing/ Pattern: Client Side Load Balancing]</ref><ref name="ithare">[http://ithare.com/chapter-vib-server-side-architecture-front-end-servers-and-client-side-random-load-balancing/ MMOG Server-Side Architecture. Front-End Servers and Client-Side Random Load Balancing]</ref> This essentially relies on all clients generating similar loads, and the [[Law of Large Numbers]]<ref name="ithare" /> to achieve a reasonably flat load distribution across servers. It has been claimed that client-side random load balancing tends to provide better load distribution than round-robin DNS; this has been attributed to caching issues with round-robin DNS, that in the case of large DNS caching servers, tend to skew the distribution for round-robin DNS, while client-side random selection remains unaffected regardless of DNS caching.<ref name="ithare" />

With this approach, the method of delivery of a list of IPs to the client can vary and may be implemented as a DNS list (delivered to all the clients without any round-robin), or via hardcoding it to the list. If a "smart client" is used, detecting that a randomly selected server is down and connecting randomly again, it also provides [[fault tolerance]].

====Server-side load balancers====
For Internet services, a server-side load balancer is usually a software program that is listening on the [[TCP and UDP port|port]] where external clients connect to access services.  The load balancer forwards requests to one of the "backend" servers, which usually replies to the load balancer. This allows the load balancer to reply to the client without the client ever knowing about the internal separation of functions. It also prevents clients from contacting back-end servers directly, which may have security benefits by hiding the structure of the internal network and preventing attacks on the kernel's network stack or unrelated services running on other ports.

Some load balancers provide a mechanism for doing something special in the event that all backend servers are unavailable. This might include forwarding to a backup load balancer or displaying a message regarding the outage.

It is also important that the load balancer itself does not become a [[single point of failure]]. Usually, load balancers are implemented in [[High availability|high-availability]] pairs which may also replicate session persistence data if required by the specific application.<ref>((cite web|url= http://www.linuxvirtualserver.org/HighAvailability.html|title= High Availability|publisher=linuxvirtualserver.org | access-date=2013-11-20))</ref> Certain applications are programmed with immunity to this problem, by offsetting the load balancing point over differential sharing platforms beyond the defined network. The sequential algorithms paired to these functions are defined by flexible parameters unique to the specific database.<ref>((cite journal |last1=Ranjan |first1=R |title=Peer-to-peer cloud provisioning: Service discovery and load-balancing |journal=Cloud Computing |date=2010))</ref>

=====Scheduling algorithms=====
Numerous [[scheduling algorithm]]s, also called load-balancing methods, are used by load balancers to determine which back-end server to send a request to.
Simple algorithms include random choice, [[Round-robin scheduling|round robin]], or least connections.<ref name=":0">((Cite web|url=https://f5.com/resources/white-papers/load-balancing-101-nuts-and-bolts|archive-url=https://web.archive.org/web/20171205223948/https://f5.com/resources/white-papers/load-balancing-101-nuts-and-bolts|url-status=dead|archive-date=2017-12-05|title=Load Balancing 101: Nuts and Bolts|date=2017-12-05|publisher=[[F5 Networks]]|access-date=2018-03-23))</ref> More sophisticated load balancers may take additional factors into account, such as a server's reported load, least response times, up/down status (determined by a monitoring poll of some kind), a number of active connections, geographic location, capabilities, or how much traffic it has recently been assigned.

=====Persistence=====
An important issue when operating a load-balanced service is how to handle information that must be kept across the multiple requests in a user's session. If this information is stored locally on one backend server, then subsequent requests going to different backend servers would not be able to find it. This might be cached information that can be recomputed, in which case load-balancing a request to a different backend server just introduces a performance issue.<ref name=":0" />

Ideally, the cluster of servers behind the load balancer should not be session-aware, so that if a client connects to any backend server at any time the user experience is unaffected. This is usually achieved with a shared database or an in-memory session database like [[Memcached]].

One basic solution to the session data issue is to send all requests in a user session consistently to the same backend server. This is known as "persistence" or "stickiness". A significant downside to this technique is its lack of automatic [[failover]]: if a backend server goes down, its per-session information becomes inaccessible, and any sessions depending on it are lost. The same problem is usually relevant to central database servers; even if web servers are "stateless" and not "sticky", the central database is (see below).

Assignment to a particular server might be based on a username, client IP address, or random. Because of changes in the client's perceived address resulting from [[DHCP]], [[network address translation]], and [[web proxy|web proxies]] this method may be unreliable. Random assignments must be remembered by the load balancer, which creates a burden on storage. If the load balancer is replaced or fails, this information may be lost, and assignments may need to be deleted after a timeout period or during periods of high load to avoid exceeding the space available for the assignment table. The random assignment method also requires that clients maintain some state, which can be a problem, for example when a web browser has disabled the storage of cookies. Sophisticated load balancers use multiple persistence techniques to avoid some of the shortcomings of any one method.

Another solution is to keep the per-session data in a [[database]]. This is generally bad for performance because it increases the load on the database: the database is best used to store information less transient than per-session data. To prevent a database from becoming a [[single point of failure]], and to improve [[scalability]], the database is often replicated across multiple machines, and load balancing is used to spread the query load across those replicas.  [[Microsoft]]'s [[ASP.net]] State Server technology is an example of a session database. All servers in a web farm store their session data on State Server and any server in the farm can retrieve the data.

In the very common case where the client is a web browser, a simple but efficient approach is to store the per-session data in the browser itself. One way to achieve this is to use a [[HTTP cookie|browser cookie]], suitably time-stamped and encrypted. Another is [[URL rewriting]]. Storing session data on the client is generally the preferred solution: then the load balancer is free to pick any backend server to handle a request. However, this method of state-data handling is poorly suited to some complex business logic scenarios, where session state payload is big and recomputing it with every request on a server is not feasible. URL rewriting has major security issues because the end-user can easily alter the submitted URL and thus change session streams.

Yet another solution to storing persistent data is to associate a name with each block of data, and use a [[distributed hash table]] to pseudo-randomly assign that name to one of the available servers, and then store that block of data in the assigned server.

=====Load balancer features=====
Hardware and software load balancers may have a variety of special features. The fundamental feature of a load balancer is to be able to distribute incoming requests over a number of backend servers in the cluster according to a scheduling algorithm. Most of the following features are vendor specific:

; Asymmetric load
: A ratio can be manually assigned to cause some backend servers to get a greater share of the workload than others. This is sometimes used as a crude way to account for some servers having more capacity than others and may not always work as desired.
; Priority activation
: When the number of available servers drops below a certain number, or the load gets too high, standby servers can be brought online.
; [[TLS acceleration|TLS Offload and Acceleration]]
: TLS (or its predecessor SSL) acceleration is a technique of offloading cryptographic protocol calculations onto specialized hardware. Depending on the workload, processing the encryption and authentication requirements of a [[Transport Layer Security|TLS]] request can become a major part of the demand on the Web Server's CPU; as the demand increases, users will see slower response times, as the TLS overhead is distributed among Web servers. To remove this demand on Web servers, a balancer can terminate TLS connections, passing HTTPS requests as HTTP requests to the Web servers. If the balancer itself is not overloaded, this does not noticeably degrade the performance perceived by end-users. The downside of this approach is that all of the TLS processing is concentrated on a single device (the balancer) which can become a new bottleneck. Some load balancer appliances include specialized hardware to process TLS. Instead of upgrading the load balancer, which is quite expensive dedicated hardware, it may be cheaper to forgo TLS offload and add a few web servers. Also, some server vendors such as Oracle/Sun now incorporate cryptographic acceleration hardware into their CPUs such as the T2000. F5 Networks incorporates a dedicated TLS acceleration hardware card in their local traffic manager (LTM) which is used for encrypting and decrypting TLS traffic. One clear benefit to TLS offloading in the balancer is that it enables it to do balancing or content switching based on data in the HTTPS request.
; [[Distributed denial of service|Distributed Denial of Service]] (DDoS) attack protection
: Load balancers can provide features such as [[SYN cookies]] and delayed-binding (the back-end servers don't see the client until it finishes its TCP handshake) to mitigate [[SYN flood]] attacks and generally offload work from the servers to a more efficient platform.
; [[HTTP compression]]
: HTTP compression reduces the amount of data to be transferred for HTTP objects by utilising gzip compression available in all modern web browsers.  The larger the response and the further away the client is, the more this feature can improve response times.  The trade-off is that this feature puts additional CPU demand on the load balancer and could be done by web servers instead.
; TCP offload
: Different vendors use different terms for this, but the idea is that normally each HTTP request from each client is a different TCP connection.  This feature utilises HTTP/1.1 to consolidate multiple HTTP requests from multiple clients into a single TCP socket to the back-end servers.
; TCP buffering
: The load balancer can buffer responses from the server and spoon-feed the data out to slow clients, allowing the webserver to free a thread for other tasks faster than it would if it had to send the entire request to the client directly.
; Direct Server Return
: An option for asymmetrical load distribution, where request and reply have different network paths.
; Health checking
: The balancer polls servers for application layer health and removes failed servers from the pool.
; [[HTTP caching]]
: The balancer stores static content so that some requests can be handled without contacting the servers.
; Content filtering
: Some balancers can arbitrarily modify traffic on the way through.
; HTTP security
: Some balancers can hide HTTP error pages, remove server identification headers from HTTP responses, and encrypt cookies so that end users cannot manipulate them.
; [[Priority queuing]]
: Also known as [[rate shaping]], the ability to give different priorities to different traffic.
; Content-aware switching
: Most load balancers can send requests to different servers based on the URL being requested, assuming the request is not encrypted (HTTP) or if it is encrypted (via HTTPS) that the HTTPS request is terminated (decrypted) at the load balancer.
; Client authentication
: Authenticate users against a variety of authentication sources before allowing them access to a website.
; Programmatic traffic manipulation
: At least one balancer allows the use of a scripting language to allow custom balancing methods, arbitrary traffic manipulations, and more.
; [[Firewall (networking)|Firewall]]
: Firewalls can prevent direct connections to backend servers, for network security reasons.
; [[Intrusion prevention system]]
: Intrusion prevention systems offer application layer security in addition to the network/transport layer offered by firewall security.

===Telecommunications===
Load balancing can be useful in applications with redundant communications links.  For example, a company may have multiple Internet connections ensuring network access if one of the connections fails. A [[failover]] arrangement would mean that one link is designated for normal use, while the second link is used only if the primary link fails.

Using load balancing, both links can be in use all the time.  A device or program monitors the availability of all links and selects the path for sending packets. The use of multiple links simultaneously increases the available bandwidth.

====Shortest Path Bridging====
[[TRILL (computing)|TRILL]] (TRansparent Interconnection of Lots of Links) facilitates an [[Ethernet]] to have an arbitrary topology, and enables per flow pair-wise load splitting by way of [[Dijkstra's algorithm]], without configuration and user intervention. The catalyst for TRILL was an event at [[Beth Israel Deaconess Medical Center]] which began on 13 November 2002.<ref>((cite web |title=All Systems Down |url=https://community.cisco.com/legacyfs/online/legacy/0/9/8/140890-All%20Systems%20Down%20-%20Scott%20Berinato(CIO).pdf |website=cio.com |publisher=IDG Communications, Inc. |access-date=9 January 2022 |archive-url=https://web.archive.org/web/20200923200221if_/https://community.cisco.com/legacyfs/online/legacy/0/9/8/140890-All%20Systems%20Down%20-%20Scott%20Berinato(CIO).pdf |archive-date=23 September 2020 |url-status=dead))</ref><ref>((cite web |title=All Systems Down |url=https://www.computerworld.com/article/2581420/all-systems-down.html |website=cio.com |publisher=IDG Communications, Inc. |access-date=9 January 2022 |archive-url=https://web.archive.org/web/20220109020703/https://www.computerworld.com/article/2581420/all-systems-down.html |archive-date=9 January 2022 |url-status=dead))</ref>  The concept of Rbridges<ref>((cite web |title=Rbridges: Transparent Routing |url=https://courses.cs.washington.edu/courses/cse590l/05sp/papers/rbridges.pdf |website=courses.cs.washington.edu |publisher=Radia Perlman, Sun Microsystems Laboratories |access-date=9 January 2022 |archive-url=https://web.archive.org/web/20220109030037/https://courses.cs.washington.edu/courses/cse590l/05sp/papers/rbridges.pdf |archive-date=9 January 2022 |url-status=dead))</ref> [sic] was first proposed to the [[Institute of Electrical and Electronics Engineers]] in the year 2004,<ref>((cite web |title=Rbridges: Transparent Routing |url=https://www.researchgate.net/publication/4102976 |website=researchgate.net |publisher=Radia Perlman, Sun Microsystems; Donald Eastlake 3rd, Motorola))</ref> whom in 2005<ref>((cite web |title=TRILL Tutorial |url=http://www.postel.org/rbridge/trill-tutorial.pdf |website=postel.org |publisher=Donald E. Eastlake 3rd, Huawei ))</ref> rejected what came to be known as TRILL, and in the years 2006 through 2012<ref>((cite web |title=IEEE 802.1: 802.1aq - Shortest Path Bridging |url=https://ieee802.org/1/pages/802.1aq.html |website=ieee802.org |publisher=Institute of Electrical and Electronics Engineers ))</ref> devised an incompatible variation known as [[Shortest Path Bridging]].

The IEEE approved the [[IEEE 802.1aq]] standard in May 2012,<ref>((cite web
 |title = IEEE APPROVES NEW IEEE 802.1aq™ SHORTEST PATH BRIDGING STANDARD
 |publisher = IEEE
 |author = Shuang Yu
 |date = 8 May 2012
 |url = http://standards.ieee.org/news/2012/802.1aq.html
 |access-date = 2 June 2012
 |archive-date = 14 May 2013
 |archive-url = https://web.archive.org/web/20130514211405/http://standards.ieee.org/news/2012/802.1aq.html
 |url-status = dead
 ))</ref> also known as Shortest Path Bridging (SPB). SPB allows all links to be active through multiple equal-cost paths, provides faster convergence times to reduce downtime, and simplifies the use of load balancing in [[Network topology#Mesh|mesh network topologies]] (partially connected and/or fully connected) by allowing traffic to load share across all paths of a network.<ref>((cite web
 |title = Shortest Path Bridging IEEE 802.1aq Overview
 |publisher = Huawei
 |author = Peter Ashwood-Smith
 |date = 24 Feb 2011
 |url = http://meetings.apnic.net/__data/assets/pdf_file/0012/32007/APRICOT_SPB_Overview.pdf
 |access-date = 11 May 2012
 |archive-url = https://web.archive.org/web/20130515115628/http://meetings.apnic.net/__data/assets/pdf_file/0012/32007/APRICOT_SPB_Overview.pdf
 |archive-date = 15 May 2013
 |url-status = dead
 ))</ref><ref>
((cite web
 |title = Largest Illinois healthcare system uproots Cisco to build $40M private cloud
 |author = Jim Duffy
 |date = 11 May 2012
 |publisher = PC Advisor
 |quote = Shortest Path Bridging will replace Spanning Tree in the Ethernet fabric.
 |url = http://www.pcadvisor.co.uk/news/internet/3357242/largest-illinois-healthcare-system-uproots-cisco-build-40m-private-cloud/
 |access-date = 11 May 2012
 ))</ref> SPB is designed to virtually eliminate human error during configuration and preserves the plug-and-play nature that established Ethernet as the de facto protocol at Layer 2.<ref name="IEEE">
((cite news
 |title = IEEE Approves New IEEE 802.1aq Shortest Path Bridging Standard
 |publisher = Tech Power Up
 |date = 7 May 2012
 |url = http://www.techpowerup.com/165594/IEEE-Approves-New-IEEE-802.1aq-Shortest-Path-Bridging-Standard.html
 |access-date = 11 May 2012
 ))</ref>

====Routing 1====
((further|Routing))
Many telecommunications companies have multiple routes through their networks or to external networks.  They use sophisticated load balancing to shift traffic from one path to another to avoid [[network congestion]] on any particular link, and sometimes to minimize the cost of transit across external networks or improve [[Reliability (computer networking)|network reliability]].

Another way of using load balancing is in [[network monitoring]] activities. Load balancers can be used to split huge data flows into several sub-flows and use several network analyzers, each reading a part of the original data. This is very useful for monitoring fast networks like [[10 Gigabit Ethernet|10GbE]] or STM64, where complex processing of the data may not be possible at [[wire speed]].<ref>Mohammad Noormohammadpour, Cauligi S. Raghavendra [https://www.researchgate.net/publication/323723167_Minimizing_Flow_Completion_Times_using_Adaptive_Routing_over_Inter-Datacenter_Wide_Area_Networks Minimizing Flow Completion Times using Adaptive Routing over Inter-Datacenter Wide Area Networks] ''IEEE INFOCOM 2018 Poster Sessions, DOI:10.13140/RG.2.2.36009.90720'' 6 January 2019</ref>

===Data center networks===
Load balancing is widely used in [[data center]] networks to distribute traffic across many existing paths between any two servers.<ref name=architecture>M. Noormohammadpour, C. S. Raghavendra, [https://www.researchgate.net/publication/321744877_Datacenter_Traffic_Control_Understanding_Techniques_and_Trade-offs "Datacenter Traffic Control: Understanding Techniques and Trade-offs,"] ''IEEE Communications Surveys & Tutorials'', vol. PP, no. 99, pp. 1-1.</ref> It allows more efficient use of network bandwidth and reduces provisioning costs. In general, load balancing in datacenter networks can be classified as either static or dynamic.

Static load balancing distributes traffic by computing a hash of the source and destination addresses and port numbers of traffic flows and using it to determine how flows are assigned to one of the existing paths. Dynamic load balancing assigns traffic flows to paths by monitoring bandwidth use on different paths. Dynamic assignments can also be proactive or reactive. In the former case, the assignment is fixed once made, while in the latter the network logic keeps monitoring available paths and shifts flows across them as network utilization changes (with arrival of new flows or completion of existing ones). A comprehensive overview of load balancing in datacenter networks has been made available.<ref name=architecture/>

===Failovers===
Load balancing is often used to implement [[failover]]—the continuation of service after the failure of one or more of its components.  The components are monitored continually (e.g., web servers may be monitored by fetching known pages), and when one becomes unresponsive, the load balancer is informed and no longer sends traffic to it.  When a component comes back online, the load balancer starts rerouting traffic to it. For this to work, there must be at least one component in excess of the service's capacity ([[N+1 redundancy]]). This can be much less expensive and more flexible than failover approaches where every single live component is paired with a single backup component that takes over in the event of a failure ([[dual modular redundancy]]).  Some [[RAID]] systems can also utilize [[hot spare]] for a similar effect.<ref name="IBM">[https://www.ibm.com/support/knowledgecenter/en/SSVJJU_6.4.0/com.ibm.IBMDS.doc_6.4/ds_ag_srv_adm_dd_failover_load_balancing.html Failover and load balancing] ''IBM'' 6 January 2019</ref>

==See also==

((Div col|colwidth=25em))
* [[Affinity mask]]
* [[Application Delivery Controller]]
* [[Autoscaling]]
* [[Cloud computing]]
* [[Cloud load balancing]]
* [[Common Address Redundancy Protocol]]
* [[Edge computing]]
* [[InterPlanetary File System]]
* [[Network Load Balancing]]
* [[SRV record]]
((div col end))

==References==
<references />

==External links==
((commons category|Load balancing (computing)))
* [http://www.udaparts.com/document/articles/snpisec.htm Server routing for load balancing with full auto failure recovery]
((Authority control))

((DEFAULTSORT:Load Balancing (Computing)))
[[Category:Servers (computing)]]
[[Category:Routing]]
[[Category:Load balancing (computing)| ]]
[[Category:Balancing technology]]

Pages transcluded onto the current version of this page (help):

Load balancing (computing) (edit)
Template:Ambox (view source) (template editor protected)
Template:Authority control (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite book (view source) (protected)
Template:Cite journal (view source) (protected)
Template:Cite news (view source) (protected)
Template:Cite web (view source) (protected)
Template:Clarify (view source) (template editor protected)
Template:Cleanup (view source) (template editor protected)
Template:Commons category (view source) (template editor protected)
Template:DMC (view source) (template editor protected)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:Div col (view source) (template editor protected)
Template:Div col/styles.css (view source) (template editor protected)
Template:Div col end (view source) (template editor protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Fact (view source) (protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix-span (view source) (template editor protected)
Template:Fix/category (view source) (protected)
Template:Further (view source) (template editor protected)
Template:Hlist/styles.css (view source) (protected)
Template:Ifsubst (view source) (template editor protected)
Template:Main (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:Mono (view source) (template editor protected)
Template:Mono/styles.css (view source) (template editor protected)
Template:More citations needed (view source) (template editor protected)
Template:Multiple issues (view source) (template editor protected)
Template:Multiple issues/styles.css (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:Pagetype (view source) (protected)
Template:Plainlist/styles.css (view source) (protected)
Template:Replace (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Side box (view source) (template editor protected)
Template:Sister project (view source) (template editor protected)
Template:Sp (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Authority control (view source) (template editor protected)
Module:Authority control/config (view source) (template editor protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:DecodeEncode (view source) (template editor protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:EditAtWikidata (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:Format link (view source) (template editor protected)
Module:Hatnote (view source) (template editor protected)
Module:Hatnote/styles.css (view source) (template editor protected)
Module:Hatnote list (view source) (template editor protected)
Module:Labelled list hatnote (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbox (view source) (template editor protected)
Module:Navbox/configuration (view source) (template editor protected)
Module:Navbox/styles.css (view source) (template editor protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Side box (view source) (template editor protected)
Module:Side box/styles.css (view source) (template editor protected)
Module:String (view source) (protected)
Module:Unsubst (view source) (protected)
Module:WikidataIB (view source) (template editor protected)
Module:WikidataIB/nolinks (view source) (template editor protected)
Module:WikidataIB/titleformats (view source) (template editor protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Load balancing (computing).

Retrieved from "https://en.wikipedia.org/wiki/Load_balancing_(computing)"