设计原则及集中式管理解析

在没有看到控制组原始设计文档的情况下，作者试着根据代码复原一下控制组的设计原则：

（1）以进程为控制单位

同一个用户运行的进程可能是计算任务进程，可能是网络传输进程，也可能是文件读写操作进程。如果以用户或用户组为单位，就很难根据进程的实际功能进行控制。

（2）集中式管理

集中式管理的对立面是分散式管理。文件的属性管理就是一种分散式管理。用户可以很容易地查看一个文件的属主是谁，但是要想查出某个用户拥有的所有文件，就必须遍历整个文件系统！控制组的集中式管理是指管理员可以很容易地了解到控制组中所有的进程的相关情况。

（3）功能模块化

计算机系统的资源有很多种。资源控制模块也必然不止一种。首先应该允许用户使用部分资源控制模块；其次应该让开发者能够在现有的控制组框架下轻松地增加新资源控制模块，而不是为了引入新的功能控制而另外发明新的控制架构。

（4）动态调配(www.xing528.com)

管理员可以在运行时修改控制组参数，也可以将进程动态分配给控制组。比如系统中有4个控制组：web控制组、ftp控制组、优质客户控制组、普通客户控制组。管理员可以调低web控制组可用资源，调高ftp控制组可用资源，也可以将某个客户的进程组从普通客户控制组升级到优质客户控制组。

（5）层级结构

控制组应该支持层级结构。比如，系统有2个控制组：web控制组、ftp控制组，web控制组分得网络带宽的70%，ftp控制组分得网络带宽的30%。进一步，管理员又可以在web控制组下创建两个控制组：虚拟站点控制组1、虚拟站点控制组2，虚拟站点控制组1的网络带宽占比为60%，虚拟站点控制组2的网络带宽占比为40%。于是虚拟站点控制组1实际分得网络带宽为42%，虚拟站点控制组2实际分得网络带宽28%。

（6）多对多映射

一个进程可以加入多个控制组，一个控制组可以包含多个进程。由于资源的多样性，用一种控制方案往往难度很大。考虑下面这个应用场景。一个大学的服务器，有三类客户：管理员、教职工、学生；有三类网络服务：www、NFS、其他。如果一定要用一种控制方案控制所有资源，那就会产生3×3=9个控制组。如果分开，cpu和memory使用一个，network使用一个，那就只有6个控制组，结构也清晰很多，如图21-1所示。假设某个学生启动了一个firefox进程，此进程就会被加入“student”和“www”两个控制组中。

图21-1 一所大学服务器的cgroup配置