IPVS的调度算法

LVS官方网站上的调度算法

IPVS在内核中的负载均衡调度是以连接为粒度的。在HTTP协议（非持久）中，每个对象从WEB服务器上获取都需要建立一个TCP连接， 同一用户的不同请求会被调度到不同的服务器上，所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。

在内核中的连接调度算法上，IPVS已实现了以下十种调度算法：

• 轮叫调度（Round-Robin Scheduling）
• 加权轮叫调度（Weighted Round-Robin Scheduling）
• 最小连接调度（Least-Connection Scheduling）
• 加权最小连接调度（Weighted Least-Connection Scheduling）
• 基于局部性的最少链接（Locality-Based Least Connections Scheduling）
• 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication Scheduling）
• 目标地址散列调度（Destination Hashing Scheduling）
• 源地址散列调度（Source Hashing Scheduling）
• 最短预期延时调度（Shortest Expected Delay Scheduling）
• 不排队调度（Never Queue Scheduling）

内核中每种调度算法均被实现为一个内核模块，在需要时加载

# lsmod | grep ip_vs
ip_vs_wrr               6977  1 
ip_vs_rr                6081  2 
ip_vs                  78209  7 ip_vs_wrr,ip_vs_rr

从上面的示例可以看到，由于目前只用到了rr和wrr两种调度算法，其他调度算法的内核模块没有加载。

轮询调度算法

轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

在系统实现时，我们引入了一个额外条件，当服务器的权值为零时，表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务（如屏蔽服务器故障和系统维护），同时与其他加权算法保持一致。

rr算法结构体

1 2 3 4 5 6 7 8 9 10

static struct ip_vs_scheduler ip_vs_rr_scheduler = { .name = "rr", /* name */ .refcnt = ATOMIC_INIT(0), // 引用计数 .module = THIS_MODULE, // 模块 .n_list = LIST_HEAD_INIT(ip_vs_rr_scheduler.n_list), .init_service = ip_vs_rr_init_svc, // 初始化 即svc->sched_data = &svc->destinations .update_service = ip_vs_rr_update_svc, // 新rs加入时调用的函数 更新svc->sched_data, // 实际上就是将其重新指向&svc->destinations .schedule = ip_vs_rr_schedule, // 调度算法的具体时间，这个每个调度算法最核心的函数 };

rr算法的具体实现

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

/* * Round-Robin Scheduling (Round-Robin rs选择调度算法) */ static struct ip_vs_dest * ip_vs_rr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb) { struct list_head *p, *q; struct ip_vs_dest *dest; IP_VS_DBG(6, "%s(): Scheduling...\n", __func__); write_lock(&svc->sched_lock); p = (struct list_head *)svc->sched_data; // sched_data初始化为&svc->destintions(新rs加入到时候也会初始化) p = p->next; q = p; do { /* skip list head */ if (q == &svc->destinations) { q = q->next; continue; } dest = list_entry(q, struct ip_vs_dest, n_list); if (!(dest->flags & IP_VS_DEST_F_OVERLOAD) && // 找到一个weight>0且没有标记为IP_VS_DEST_F_OVERLOAD的rs atomic_read(&dest->weight) > 0) /* HIT */ goto out; q = q->next; } while (q != p); //如果p==q时,说明q遍历一遍没有找到合适的rs，返回NULL write_unlock(&svc->sched_lock); ip_vs_scheduler_err(svc, "no destination available"); return NULL; out: svc->sched_data = q; // 更新sched_data为q，下一次调度从q开始 write_unlock(&svc->sched_lock); IP_VS_DBG_BUF(6, "RR: server %s:%u " "activeconns %d refcnt %d weight %d\n", IP_VS_DBG_ADDR(svc->af, &dest->addr), ntohs(dest->port), atomic_read(&dest->activeconns), atomic_read(&dest->refcnt), atomic_read(&dest->weight)); return dest; }

轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。

加权轮询算法

在rr算法的基础上引入一个weight，按weight的比例来调度rs

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

/* * Weighted Round-Robin Scheduling */ static struct ip_vs_dest * ip_vs_wrr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb) // 加权轮询调度算法 { struct ip_vs_dest *dest; struct ip_vs_wrr_mark *mark = svc->sched_data; struct list_head *p; IP_VS_DBG(6, "%s(): Scheduling...\n", __func__); /* * This loop will always terminate, because mark->cw in (0, max_weight] * and at least one server has its weight equal to max_weight. */ write_lock(&svc->sched_lock); p = mark->cl; // destinations链表 while (1) { if (mark->cl == &svc->destinations) { /* it is at the head of the destination list */ if (mark->cl == mark->cl->next) { // 没有rs 返回NULL /* no dest entry */ ip_vs_scheduler_err(svc, "no destination available: " "no destinations present"); dest = NULL; goto out; } mark->cl = svc->destinations.next; mark->cw -= mark->di; // 更新cw 减去rs weight的gcd if (mark->cw <= 0) { // 如果cw<=0，则将其改为mw mark->cw = mark->mw; /* * Still zero, which means no available servers. */ if (mark->cw == 0) { // cw还是0，即mw==0, 说明没有rs了 mark->cl = &svc->destinations; ip_vs_scheduler_err(svc, "no destination available"); dest = NULL; goto out; } } } else mark->cl = mark->cl->next; // 不是destinations表头，直接查找下一个

最小连接数调度算法

最小连接调度（Least-Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

在系统实现时，我们也引入当服务器的权值为零时，表示该服务器不可用而不被调度

当各个服务器有相同的处理性能时，最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上，所有处理时间比较长的请求不可能被发送到同一台服务器上。但是，当各个服务器的处理能力不同时，该算法并不理想，因为TCP连接处理请求后会进入TIMEnWAIT状态，TCP的TIMEWAIT一般为2分钟，此时连接还占用服务器的资源，所以会出现这样情形，性能高的服务器已处理所收到的连接，连接处于TIMEWAIT状态，而性能低的服务器已经忙于处理所收到的连接，还不断地收到新的连接请求。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/* * Simply select the server with the least number of * (activeconns<<5) + inactconns * Except whose weight is equal to zero. * If the weight is equal to zero, it means that the server is * quiesced, the existing connections to the server still get * served, but no new connection is assigned to the server. */ list_for_each_entry(dest, &svc->destinations, n_list) { if ((dest->flags & IP_VS_DEST_F_OVERLOAD) || atomic_read(&dest->weight) == 0) continue; doh = ip_vs_dest_conn_overhead(dest); // activeconns<<5) + inactconns if (!least || doh < loh) { least = dest; loh = doh; } }

加权最小连接调度

加权最小连接调度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

基于局部性的最少链接调度

基于局部性的最少链接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。

带复制的基于局部性最少链接调度

带复制的基于局部性最少链接调度（Locality-Based Least Connections with Replication Scheduling，以下简称为LBLCR）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。

LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

目标地址散列调度

目标地址散列调度（Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

散列算法为： (dest_ip* 2654435761UL) & HASH_TAB_MASK;

原地址散列调度

地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。

在实际应用中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

参考资料

LVS中文网站