F5负载均衡算法及基本原理（Intro to Load Balancing）

F5负载均衡算法及基本原理（Intro to Load Balancing）  

2012-10-18 17:21:34|  分类： 负载均衡F5BIG-IP |  标签： |字号大中小 

• Random: This load balancing method randomly distributes load across the servers available, picking one via random number generation and sending the current connection to it. While it is available on many load balancing products, its usefulness is questionable except where uptime is concerned – and then only if you detect down machines.
• 随机：此负载均衡算法在可用的服务器间随机分发请求，通过生成随机数随机挑选一台服务器，并将当前连接发给它。系统对需要进行负载均衡的服务器建立一个数组（array），使用随机数生成器来决定谁将获得下一个连接。

Plain Programmer Description: The system builds an array of Servers being load balanced, and uses the random number generator to determine who gets the next connection… Far from an elegant solution, and most often found in large software packages that have thrown load balancing in as a feature.

• Round Robin: Round Robin passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced. Round Robin works well in most configurations, but could be better if the equipment that you are load balancing is not roughly equal in processing speed, connection speed, and/or memory.
• 轮询：将请求依次顺序循环地分发给服务器，从1到N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

Plain Programmer Description: The system builds a standard circular queue and walks through it, sending one request to each machine before getting to the start of the queue and doing it again. While I’ve never seen the code (or actual load balancer code for any of these for that matter), we’ve all written this queue with the modulus function before. In school if nowhere else.

• Weighted Round Robin (called Ratio on the BIG-IP): With this method, the number of connections that each machine receives over time is proportionate to a ratio weight you define for each machine. This is an improvement over Round Robin because you can say “Machine 3 can handle 2x the load of machines 1 and 2”, and the load balancer will send two requests to machine #3 for each request to the others.
• 权重：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

Plain Programmer Description: The simplest way to explain for this one is that the system makes multiple entries in the Round Robin circular queue for servers with larger ratios. So if you set ratios at 3:2:1:1 for your four servers, that’s what the queue would look like – 3 entries for the first server, two for the second, one each for the third and fourth. In this version, the weights are set when the load balancing is configured for your application and never change, so the system will just keep looping through that circular queue. Different vendors use different weighting systems – whole numbers, decimals that must total 1.0 (100%), etc. but this is an implementation detail, they all end up in a circular queue style layout with more entries for larger ratings.

• Dynamic Round Robin (Called Dynamic Ratio on the BIG-IP): is similar to Weighted Round Robin, however, weights are based on continuous monitoring of the servers and are therefore continually changing. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.
• 动态比率：类似于权重，不过权重值是随着对服务器持续的监控而变化的。这是一个动态的负载均衡算法，基于对服务器性能的实时分析，如连接数或响应时间。

Plain Programmer Description: If you think of Weighted Round Robin where the circular queue is rebuilt with new (dynamic) weights whenever it has been fully traversed, you’ll be dead-on.

• Fastest: The Fastest method passes a new connection based on the fastest response time of all servers. This method may be particularly useful in environments where servers are distributed across different logical networks. On the BIG-IP, only servers that are active will be selected.
• 最快模式：传递连接给那些响应速度最快的服务器。这种算法可能对于服务器处于不同的逻辑网络中的情况特别有用。均衡器记录着每个服务器的响应时间并选择最快的那一个。这非常直接了当，但是可能会导致拥塞，因为当前的响应时间并不一定真的还是1s或是2s了。
• 解释一下：最快模式算法是基于未完成的七层请求数来计算的。请求被发送到一个成员时，LTM将为它递增一个计数器，当请求被响应后，再对计数器递减。当LTM收到一个连接请求后，有最少的未完成请求的成员将被选择。如果VS没有关联七层的Profile，LTM是不能追踪请求和回应的，负载均衡算法将“降级”为最小连接数模式。

Plain Programmer Description: The load balancer looks at the response time of each attached server and chooses the one with the best response time. This is pretty straight-forward, but can lead to congestion because response time right now won’t necessarily be response time in 1 second or two seconds. Since connections are generally going through the load balancer, this algorithm is a lot easier to implement than you might think, as long as the numbers are kept up to date whenever a response comes through.

These next three I use the BIG-IP name for. They are variants of a generalized algorithm sometimes called Long Term Resource Monitoring.

• Least Connections: With this method, the system passes a new connection to the server that has the least number of current connections. Least Connections methods work best in environments where the servers or other equipment you are load balancing have similar capabilities. This is a dynamic load balancing method, distributing connections based on various aspects of real-time server performance analysis, such as the current number of connections per node or the fastest node response time. This Application Delivery Controller method is rarely available in a simple load balancer.
• 最小连接数：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
• 但是，像Fastest一样，当连接时间不同时也可能导致拥塞——比如一个服务器正在处理简单的HTML页面，而另一个正在运行处理一堆数据库查询的JSP脚本，连接数就不太适合这种情况了。

Plain Programmer Description: This algorithm just keeps track of the number of connections attached to each server, and selects the one with the smallest number to receive the connection. Like fastest, this can cause congestion when the connections are all of different durations – like if one is loading a plain HTML page and another is running a JSP with a ton of database lookups. Connection counting just doesn’t account for that scenario very well.

• Observed: The Observed method uses a combination of the logic used in the Least Connections and Fastest algorithms to load balance connections to servers being load-balanced. With this method, servers are ranked based on a combination of the number of current connections and the response time. Servers that have a better balance of fewest connections and fastest response time receive a greater proportion of the connections. This Application Delivery Controller method is rarely available in a simple load balancer.
• 观察模式：以连接数和响应时间这两项的最佳平衡为依据来为新的请求选择服务器。

Plain Programmer Description: This algorithm tries to merge Fastest and Least Connections, which does make it more appealing than either one of the above than alone. In this case, an array is built with the information indicated (how weighting is done will vary, and I don’t know even for F5, let alone our competitors), and the element with the highest value is chosen to receive the connection. This somewhat counters the weaknesses of both of the original algorithms, but does not account for when a server is about to be overloaded – like when three requests to that query-heavy JSP have just been submitted, but not yet hit the heavy work.

• Predictive: The Predictive method uses the ranking method used by the Observed method, however, with the Predictive method, the system analyzes the trend of the ranking over time, determining whether a servers performance is currently improving or declining. The servers in the specified pool with better performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections. The Predictive methods work well in any environment. This Application Delivery Controller method is rarely available in a simple load balancer.
• 预测模式：预测模式使用和观察模式一样的评选方法，只不过BIGIP会利用收集到的服务器当前的性能指标（连接数和响应时间），进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器来响应用户的请求。预测模式试图修复在观察模式中的一个问题，如果服务器的响应时间已经开始下滑，那么它是不太可能接受下一个请求的。

Plain Programmer Description: This method attempts to fix the one problem with Observed by watching what is happening with the server. If its response time has started going down, it is less likely to receive the packet. Again, no idea what the weightings are, but an array is built and the most desirable is chosen.

 

 

You can see with some of these algorithms that persistent connections would cause problems. Like Round Robin, if the connections persist to a server for as long as the user session is working, some servers will build a backlog of persistent connections that slow their response time. The Long Term Resource Monitoring algorithms are the best choice if you have a significant number of persistent connections. Fastest works okay in this scenario also if you don’t have access to any of the dynamic solutions.

你可以看到，有些算法遇到长连接可能会导致问题。像是轮询，如果长连接保持用户会话那么久，当连接数积压到一定值时会导致服务器响应时间变慢。如果你有大量的长连接，LTRM（ Long Term Resource Monitoring ）算法是最好的选择。如果没有动态的解决方案，Fastest算法也比较适合这种场景。

负载均衡模式（Load Balancing Method）分为以下几种：
Round Robin：这是缺省的配置方式。用户的连接请求被平均地分配给作为负载均衡的所有节点。如果作为服务器节点的设备在处理速度和内存上是一致的，那么这样的处理方式是最合适的。
Radio：服务器节点先确定根据处理能力确定他们各自的处理请求比重，然后根据比重把请求发送到服务器节点进行处理，这样可以解决在pool中存在不同机器型号的均衡器设备问题。
Dynamic Radio：这和Radio类似，但是他们的请求处理比重是根据每个节点的处理能力而动态分配的。节点处理能力的监控可以实时地通过获得每个节点的当前连接数、最快的响应时间等动态性能确定。
Fastest：设备获得当前处理速度最快的节点，然后把处理请求发向这个最快的节点。
Least Connections：在所有节点有差不多的处理能力情况下，把当前的处理请求发送到当前连接数最少的服务节点。
Observed：这是Fastest和Least Connections模式的结合。所有的节点按照连接数和响应速度的总体情况进行排序，后续用户请求中更大比例让那些连接数少并且处理速度快的节点处理。这种方式对节点的处理性能不一致时适用。
Predictive：这种方式使用Observed方式的处理方式对节点进行排序，但是设备还考虑了这些节点处理能力的变化趋势以确定某个节点的处理能力是在上升还是在降低，让那些处理能力呈上升趋势的节点处理更多的请求。

在各种程序或性能选择的项目中也能用到，先记下了

以不同条件满足不同需要的配置，最终达到均衡或合理或按需分配的结果

12种算法包括：

?    轮询（Round Robin）：顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。

?    比率（Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

?    优先权（Priority）：给所有服务器分组，给每个组定义优先权，BIG/IP用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIG/IP才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。

?    最少的连接方式（Least Connection）：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

?    最快模式（Fastest）：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

?    观察模式（Observed）：连接数目和响应时间以这两项的最佳均衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7层的故障，BIG/IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

?    预测模式（Predictive）：BIG/IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被bigip进行检测)

?    动态性能分配（Dynamic Ratio-APM):BIG/IP收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

?    动态服务器补充（Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。

?    服务质量(QoS)：按不同的优先级对数据流进行分配。

?    服务类型(ToS)：按不同的服务类型（在Type of Field中标识）对数据流进行分配。

?    规则模式：针对不同的数据流设置导向规则，用户可自行编辑流量分配规则，BIG/IP利用这些规则对通过的数据流实施导向控制。