一文读懂｜Linux 进程管理之CFS负载均衡

Posted 2022-02-16 Linux内核那些事

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一文读懂｜Linux 进程管理之CFS负载均衡相关的知识，希望对你有一定的参考价值。

前面的调度学习都是默认在单个CPU上的调度策略。我们知道为了CPU之间减少“干扰”，每个CPU上都有一个任务队列。运行的过程种可能会出现有的CPU“忙的一笔”，有的CPU“闲的蛋疼”，于是便需要负载均衡。

将task从负载较重的CPU上转移到负载相对较轻的CPU上执行，这个过程就是负载均衡的过程。

在了解负载均衡前有必要了解soc上对CPU的拓扑关系。

我们知道一个多核心的soc片上系统，内部结构是很复杂的，内核采用CPU拓扑结构来描述一个SOC的架构。内核使用调度域来描述CPU之间的层次关系，对于低级别的调度域来说，CPU之间的负载均衡处理开销比较小，而对于越高级别的调度域，其负载均衡的开销就越大。

比如一个4核心的SOC，两个核心是一个cluster，共享L2 cache，那么每个cluster可以认为是一个MC调度域，每个MC调度域中有两个调度组，每个调度组中只有一个CPU。而整个SOC可以认为是高一级别的DIE调度域，其中有两个调度组，cluster0属于一个调度组，cluster1属于另一个调度组。跨cluster的负载均衡是需要清除L2 cache的，开销是很大的，因此SOC级别的DIE调度域进行负载均衡的开销会更大一些。

CPU对应的调度域和调度组可通过在设备模型文件 /proc/sys/kernel/sched_domain 里查看。

调度域 sched_domain 主要的成员如下：

成员	描述
parent 和 child	sched domain会形成层级结构，parent和child建立了不同层级结构的父子关系。对于base domain而言，其child等于NULL；对于top domain而言，其parent等于NULL。
groups	一个调度域中有若干个调度组，这些调度组形成一个环形链表，groups成员就是链表头
min_interval 和 max_interval	做均衡也是需要开销的，不能时刻去检查调度域的均衡状态，这两个参数定义了检查该sched domain均衡状态的时间间隔的范围
balance_interval	定义了该sched domain均衡的时间间隔
busy_factor	正常情况下，balance_interval定义了均衡的时间间隔，如果cpu繁忙，那么均衡要时间间隔长一些，即时间间隔定义为busy_factor x balance_interval
imbalance_pct	调度域内的不均衡状态达到了一定的程度之后就开始进行负载均衡的操作，imbalance_pct定义了不均衡的water mark。
level	该sched domain在整个调度域层级结构中的level
span_weight	该sched domain中cpu的个数
span	该调度域的跨度

调度组 sched_group 主要的成员如下：

成员	描述
next	sched domain中的所有sched group会形成环形链表，next指向groups链表中的下一个节点
group_weight	该调度组中有多少个cpu
sgc	该调度组的算力信息
cpumask	该调度组包含哪些cpu

为了减少锁的竞争，每一个cpu都有自己的MC domain、DIE domain（sched domain是分成两个level，base domain称为MC domain（multi core domain），顶层的domain称为DIE domain）以及sched group，并且形成了sched domain之间的层级结构，sched group的环形链表结构。可以通过/sys/devices/system/cpu/cpuX/topology查看cpu topology信息。

在上面的结构中，sched domain是分成两个level，base domain称为MC domain，顶层的domain称为DIE domain。顶层的DIE domain覆盖了系统中所有的CPU，小核cluster的MC domain包括所有小核cluster中的cpu，大核cluster的MC domain包括所有大核cluster中的cpu。

通过DTS和CPU topo子系统，可以构建sched domain层级结构，用于具体的均衡算法。流程是：kernel_init() -> kernel_init_freeable() -> smp_prepare_cpus() -> init_cpu_topology() -> parse_dt_topology()

图中可以看出左边主要分为CPU负载跟踪和task负载跟踪。

CPU负载跟踪：考虑每一个CPU的负载。汇聚cluster上所有负载，方便计算cluster之间负载的不均衡状况。

task负载跟踪：判断该任务是否适合当前CPU算力。如果判定需要均衡，那么需要在CPU之间迁移多少的任务才能达到平衡。

右边是通过DTS和CPU topo子系统，构建的sched domain层级结构。流程是：kernel_init() -> kernel_init_freeable() -> smp_prepare_cpus() -> init_cpu_topology() -> parse_dt_topology()

有了左右两边的基础设施，那么什么时候触发负载均衡呢？这主要和调度事件相关，当发生任务唤醒、任务创建、tick到来等调度事件的时候，就可以检查当前系统的不均衡情况，并酌情进行任务迁移，以便让系统负载处于平衡状态。

CFS任务的负载均衡器有两种。一种是为繁忙CPU们准备的periodic balancer，用于CFS任务在busy cpu上的均衡；一种是为idle cpu们准备的idle balancer，用于把繁忙CPU上的任务均衡到idle cpu上来。

周期性负载均衡（periodic load balance或者tick load balance）是指在tick中，周期性的检测系统的负载均衡状况，找到系统中负载最重的domain、group和CPU，将其上的runnable任务拉到本CPU以便让系统的负载处于均衡的状态。

nohz load balance是指其他的cpu已经进入idle，本CPU任务太重，需要通过 IPI 将其他idle的CPUs唤醒来进行负载均衡。nohz idle load balance也是通过busy cpu上tick驱动的，如果需要kick idle load balancer，那么就会通过GIC发送一个ipi中断给选中的idle cpu，让它代表系统所有的idle cpu们进行负载均衡。

new idle load balance 比较好理解，就是在CPU上没有任务执行，马上要进入idle状态的时候，看看其他CPU是否需要帮忙，来从busy cpu上拉任务，让整个系统的负载处于均衡状态。

当一个CPU上进行负载均衡的时候，总是从base domain开始，检查其所属sched group之间的负载均衡情况，如果有不均衡情况，那么会在该cpu所属cluster之间进行迁移，以便维护cluster内各个cpu core的任务负载均衡。

load_balance是处理负载均衡的核心函数，它的处理单元是一个调度域，也就是sched domain，其中会包含对调度组的处理。

在该domain中找到最忙的sched group
在最忙的group中挑选最忙的CPU runqueue，该CPU就成为任务迁移的src
从该队列中选择要迁移的任务（判断的依据主要是task load的大小，优先选择load重的任务）
向着作为dst的CPU runqueue迁移

Nginx系列教程| 一文带你读懂 Nginx 的负载均衡

作者：JackTian
微信公众号：杰哥的IT之旅（ID：Jake_Internet）

LAMP 系列导读

LNMP 系列导读

01. Nginx 系列教程（一）| 手把手教你在 Linux 环境下搭建 Nginx 服务
 02. Nginx 系列教程（二）| 一文带你读懂 Nginx 的正向与反向代理

一、负载均衡

当一台服务器的访问量越大时，服务器所承受的压力也就越大，超出自身所指定的访问压力就会崩掉，避免发生此类事情的发生，因此也就有了负载均衡来分担服务器的压力。

那么究竟什么是负载均衡呢？通俗些讲，就是我们有几十台、几百台甚至更多服务器，将这些服务器组成一个服务器集群，当客户端访问某台设备的数据时，首先发送的请求先到一台中间服务器，并通过中间服务器在服务器集群中平均分摊到其他服务器中，因此，当用户每次所发送的请求都将会保证服务器集群中的设备均与平摊，以此来分担服务器的压力，从而保持服务器集群的整理性能最优，避免出现有崩溃的现象。
技术图片

二、Nginx负载均衡的作用

转发功能：Nginx 会按照一定的算法轮询、权重将客户端发来的请求转发至不同的应用服务器上，同时减轻单台服务器的压力，提高服务器的并发量；
故障迁移：当一台服务器出现了故障时，客户端发来的请求将自动发送到其他服务器；
添加恢复：当故障服务器恢复正常工作时，将自动添加到处理用户请求中；

三、Nginx负载均衡的几种策略方式

1）轮询（默认）

客户端发出的每个请求将按照时间顺序逐一分配到不同的后端服务器，如后端服务器down掉，能自动剔除。

upstream backserver {
    server 192.168.1.10;
    server 192.168.1.11;
    }

2）weight

weight 代表权重，默认为1，权重越高被分配的客户端也就越多。

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况，也就是说：哪个 server 的连接数少，路由就到哪个 server 中去。

upstream backserver {
    server 192.168.1.10 weight=3;
    server 192.168.1.11 weight=7;
}

3）ip_hash

每个请求按访问 IP 的hash结果分配，每个访客固定访问一个后端服务器，可解决session的问题。

upstream backserver {
    ip_hash;
    server 192.168.1.10:80;
    server 192.168.1.11:88;
    }

4）fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backserver {
    server server1;
    server server2;
    fair;
    }

5）url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
    }

四、常见的负载均衡方案有哪些？

将下图进行拆分，其常见互联网分布式架构，主要分为：

客户端层
反向代理层
服务器站点层
服务层
数据层

因此，可以看出，从一台客户端发出的请求到最终的数据层，上游都可以访问到下游，实现最终的均匀平摊。

第一层：从客户端层到反向代理层

客户端层到反向代理层的负载均衡，通过DNS轮询实现，在DNS服务器上对应的域名配置多个IP,当客户端发出的请求到DNS服务器时，会轮询返回对应域名配置的 IP，保证解析的IP是必须与Nginx服务器的IP是相同的，以此Nginx服务器的请求分配也将是均衡的。
技术图片

第二层：从反向代理层到服务器站点层

反向代理层到服务器站点层的负载均衡，通过Nginx实现，修改nginx.conf配置文件，实现多种负载均衡策略；

PS:这里我们通过nginx.conf配置文件的方式进行实现，其主要实现的方式可参考上述：三、Nginx负载均衡的几种方式（主要包括：轮询、weight、ip_hash、fair（第三方）、url_hash（第三方）的相关描述）

技术图片

第三层：从服务器站点层到服务层

服务器站点层到服务层的负载均衡，是通过服务连接池实现的，上游连接池会建立与下游服务多个连接，每次请求将会随机选取连接来访问下游服务。
技术图片

第四层：从服务层到数据层

服务层到数据层时，数据量很大的情况下，数据层(db，cache)会涉及数据的水平切分，所以数据层的负载均衡会更加复杂一些，分为数据的均衡与请求的均衡。

数据的均衡：是指水平切分后的每个服务(db，cache)，数据量是均匀的。
请求的均衡：是指水平切分后的每个服务(db，cache)，请求量是均匀的。

常见的水平切分方式有两种：

第一种：按照range水平切分
技术图片

每一个数据服务，存储一定范围的数据

user0 服务，存储 uid 范围：1-1kw；
user1 服务，存储 uid 范围：1kw-2kw；

这个方案的好处是：

规则简单，service 只需判断一下 uid 范围就能路由到对应的存储服务；
数据均衡性较好；
易扩展，可随时加一个 uid [2kw,3kw] 的数据服务；

这个方案的不足是：

请求的负载不一定均衡，对新用户会比老用户更活跃，大 range 的服务请求压力会更大。

第二种：按照 id 哈希水平切分
技术图片

每一个数据服务，存储某个 key 值 hash 后的部分数据

user0 服务，存储偶数 uid 数据；
user1 服务，存储奇数 uid 数据；

这个方案的好处是：

规则简单，service 需对 uid 进行 hash 能路由到对应的存储服务；
数据均衡性较好；
请求均匀性较好；

这个方案的不足是：

不易扩展，扩展一个数据服务，hash 方法改变时候，可能需要进行数据迁移。

五、Nginx负载均衡配置实例

1、实现效果

在浏览器地址栏中输入http://192.168.1.10/abc/20200320.html，负载均衡效果平均到端口号8080和8081中。

2、准备工作

1）准备两台Tomcat服务器，一台服务器为8080，另一台服务器为8081。

2）分别在两台Tomcat服务器中的webapps目录中，创建名称是abc文件夹，在abc文件夹中创建页面20200325.html，进行测试。

在上一篇文章中，我们对其两台Tomcat服务创建好了8080和8081，所以这里我们就无需在创建了，并且分别查看8080和8081服务下webapps目录中是否都存在测试页面文件，如没有可自行创建即可。

Tomcat8080

# cat /root/tomcat8080/apache-tomcat-7.0.70/webapps/abc/20200320.html
<h1>welcome to tomcat 8080!</h1>

Tomcat8081

# cd /root/tomcat8081/apache-tomcat-7.0.70/webapps/
# mkdir abc
# cd abc/
# vim 20200320.html
<h1>welcome to tomcat 8081!</h1>

切换到/root/tomcat8081/apache-tomcat-7.0.70/bin/目录下，启动8081的Tomcat服务。

# ./startup.sh 
Using CATALINA_BASE:   /root/tomcat8081/apache-tomcat-7.0.70
Using CATALINA_HOME:   /root/tomcat8081/apache-tomcat-7.0.70
Using CATALINA_TMPDIR: /root/tomcat8081/apache-tomcat-7.0.70/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /root/tomcat8081/apache-tomcat-7.0.70/bin/bootstrap.jar:/root/tomcat8081/apache-tomcat-7.0.70/bin/tomcat-juli.jar
Tomcat started.

测试验证

在客户端浏览器中分别测试Tomcat8080：http://192.168.1.10/abc/20200320.html和Tomcat8081：http://192.168.1.10:8081/abc/20200325.html进行验证。
技术图片

3）在 Nginx 的配置文件中进行负载均衡的配置；

在http模块下添加upstream myserver配置、server_name 由原来的localhost改为Nginx服务器地址，在location下添加proxy_pass http://myserver;即可；

# vim /usr/local/nginx/conf/nginx.conf
 17 http {
 18 ......
 34     upstream myserver {
 35         server 192.168.1.10:8080;
 36         server 192.168.1.10:8081;
 37     }
 38 
 39     server {
 40         listen       80;
 41         server_name  192.168.1.10;
 42 
 43         #charset koi8-r;
 44 
 45         #access_log  logs/host.access.log  main;
 46 
 47         location / {
 48             proxy_pass http://myserver;
 49             root   html;
 50             index  index.html index.htm;
 51         }
 52 ......

操作完 Nginx 文件的负载均衡的配置后，重启Nginx服务，出现如下问题：

# ./nginx -s stop
nginx: [warn] conflicting server name "192.168.1.10" on 0.0.0.0:80, ignored
# ./nginx

意思是重复绑定了server name，该警告不会影响到服务器运行。而且，这个重复绑定的意思是现在运行的Nginx服务和将要加载的新配置中的重复，所以，这个警告其实是不必的。