文档中心 负载均衡 最佳实践 均衡算法选择与权重配置实例

均衡算法选择与权重配置实例

最近更新时间:2019-04-26 10:12:14

负载均衡算法比较分析

加权轮询算法 Weighted Round-Robin Scheduling

  • 原理
    轮叫调度算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,选出第i台服务器。加权轮叫调度算法可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
  • 优势
    算法的优点是其简洁性,和实用性。它无需记录当前所有连接的状态,所以它是一种无状态调度。
  • 劣势
    加权轮叫调度算法相对简单,但不适用于请求服务时间变化比较大,或者每个请求所消耗的时间不一致的情况,此时轮叫调度算法容易导致服务器间的负载不平衡。
  • 适用场景
    每个请求所占用的后端时间基本相同,负载情况最好。常用于短连接服务,例如 HTTP 等服务。
  • 用户推荐
    用户可知每个请求所占用后端时间基本相同时,如已知rs处理的都是同类型或者相似类型的请求时,推荐选择加权轮询的方式。当请求时间相差较小时也推荐使用加权轮询的方式,因为该实现方式消耗小,无需遍历,效率较高。

加权最小连接数 Weighted Least-Connection Scheduling

  • 原理
    在实际情况中,客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间的延伸,如果采用简单的轮询或随机均衡算法,每一台服务器上的连接进程数目可能会产生极大的不同,这样实际上并没有达到真正的负载均衡。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。与轮询调度算法相反,最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。权重最少连接数调度算法是在做少连接数调度算法的基础上,根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求,是在最少连接数调度算法的基础上的改进。
    1. 假设各台 rs 的权值依次为 wi,当前连接数依次为 ci,依次计算 ci/wi,值最小的 rs 作为下一个分配的 rs。
    2. 如果存在 ci/wi 相同的 rs,这些 rs 再使用加权轮询的方式调度
  • 优势
    此种均衡算法适合长时处理的请求服务,如FTP等应用。
  • 劣势
    由于接口限制,目前最小连接数和会话保持功能不能同时开启。
  • 适用场景
    每个请求所占用的后端时间相差较大的场景。常用于长连接服务。
  • 用户推荐
    如果用户需要处理不同的请求,且请求所占用后端时间相差较大,如3ms和3s这种数量级的差距时,推荐使用加权最小连接数算法实现负载均衡。

源地址散列调度算法 ip_hash

  • 原理
    根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空
  • 优势
    ip_hash 可以实现部分会话保持的效果,能够记住源 IP,使某一 client 请求通过 hash 表一直映射在同一台 rs 上。因此在不支持会话保持的场景可以使用 ip_hash 进行调度。
  • 用户推荐
    将请求的源地址进行hash运算,并结合后端的服务器的权重派发请求至某匹配的服务器,这可以使得同一个客户端 IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无 cookie 功能的 TCP 协议。

均衡算法选取及权重配置实例

在负载均衡即将发布的新功能中,七层转发将支持最小连接数的均衡方式,为了让用户在不同场景下,能够让 RS 集群稳定的承接业务,因此我们给出几个负载均衡选择与权重配置的实例供用户进行参考。

  • 场景1
    设有3台配置相同(CPU / 内存)的 RS,由于性能一致,用户可以将RS权重都设置为10。设现在每台 RS 与 client 端建立了100个 TCP 链接,此时新增1台 RS。在此场景下,推荐用户使用最小连接数的均衡方式,这种配置能快速的让第四台 RS 的负载提升,降低另外3台 RS 的压力。
  • 场景2
    设用户首次接触云服务,且建站时间不长,网站负载较低,则建议购买相同配置的 RS,因此 RS 都是无差别的接入层服务器。在此场景下,用户可以将 RS 权重都设为10,采用加权轮询的均衡方式进行流量分发。
  • 场景3
    用户有5台服务器,用与承载简单的静态网站访问,且5台服务器的计算能力的比例为 9:3:3:3:1(按 CPU、内存换算)。在此场景下,用户可以依次将 RS 权重比例设置为90,30,30,30,10,由于静态网站访问大多数是短连接请求,因此可以采用加权轮询的均衡方式,让 CLB 按 RS 的性能比例分配请求。
  • 场景4
    某用户有10台 RS 用于承担海量的WEB访问请求,且不希望多购置 RS 增加支出。 某台 RS 经常会因为负载过高,导致服务器重启。在此场景下,建议用户根据 RS 的性能进行相应的权重设置,给负载过高的 RS 设置较小的权值。除此之外,可以采用最小连接数的负载均衡方式,将请求分配到活跃连接数较少的 RS 上,从而解决某台 RS 负载过高的问题。
  • 场景5
    某用户有3台 RS 用于处理若干长连接请求,且这3太服务器的计算能力比例为3:1:1(按 CPU、内存换算)。 此时性能最好的服务器处理请求较多,用户不希望过载此服务器,希望能够将新的请求分配到空闲服务器上。在此场景下,可以采用最小连接数的均衡方式,并适当降低繁忙服务器的权重,便于 CLB 将请求分配到活跃数较少的 RS 上,实现负载均衡。
  • 场景6
    某用户希望后续客户端的请求可以分配到同一服务器上。而采用加权轮询或加权最小连接数的方式,不能保证相同客户端的请求被分到固定某台服务器上去。为了配合客户特定应用程序服务器的需求,保证客户端的会话具有“粘性”或是“持续性”,在此场景下,我们可以采用 ip_hash 的均衡方式进行流量分发。此方法可以确保来自同一客户端的请求总被定向分发到同一 RS 上去。(服务器数量变化或是该服务器不可用时除外)