LXC（Linux Containers）的不足和改进

在之前的博文中（参见Linux Cgroups详解系列），作者对LXC 的实现做了分析，

这里再例举一下LXC 的一些不足和作者个人的一些改进意见。
（一） 缺少对磁盘配额（disk quota）的支持
LXC 依赖于Linux Cgroups 实现资源管理的功能，而Cgroups 并没有相应的
子系统来提供限制磁盘空间的功能。对于服务器整合而言，限制磁盘空间是个很
有用的功能，可以限制单一应用占有过多的磁盘空间，从而导致其他应用失败。
LXC 现在的解决办法是在创建容器的时候利用LVM 创建一个LVM 分区来
限制容器可使用的磁盘空间。这个办法依赖于LVM，用户在使用LXC 时需要做
额外的工具。最好的解决办法是将这个功能集成到LXC 本身，而不是依赖于第
三方工具。LXC 实现限制磁盘空间的功能，可以利用内核的resouce counter 机制，
采取类似Cgroups memory 子系统的实现，也可以借鉴OpenVZ 两级磁盘配额的
实现。
（二） 缺少对写时复制（copy on write）的支持
对于基于容器的虚拟化技术来说，每个容器都是一个操作系统用户态实例，
因此每个容器都需要自己的系统函数库文件等必需文件。如果每个容器都存一份
拷贝的话，在一个系统上有多个容器的情况下，就会造成磁盘空间的浪费。
一个简单的解决办法就是对于容器共用的文件，可以只保存一份拷贝，其他
容器都采取硬连接的方式来共享文件。这样减少占用的磁盘空间，减少内存里的
inode 缓存等。但是如果没有其他的额外措施，当一个容器修改这种共享文件的
话就会影响到其他容器。解决这个问题的最佳方法就是写时复制，当有容器对共
享文件写入时，为其单独创建一份拷贝。LXC 现在并不支持写时复制技术。实
现写时复制，可以借鉴内核对内存写时复制的实现。内存对共享的内存页增加了
额外的标记，当进程试图对此类内存页写入时，就会对其执行写时复制操作。以
此类推，实现写时复制就需要对文件加入额外的属性值，并对write 等系统调用
添加额外的处理代码，以保证当容器对共享文件进行修改时，为其创建单独的拷
贝。
（三） 进程和容器之间的动态关联还不够完善
在基于容器的虚拟化技术中，进程不再是个全局概念，而是从属于某个特定
的容器（如果我们采取类似Solaris Containers 的观点，将系统本身看成是一个特
殊的容器的话）。理想情况下，进程跟容器之间是动态关联的，进程可以在容器
之间迁移。在基于容器的虚拟化技术中，容器既是资源容器，也是隔离的命名空
间。因此，进程的迁移既是资源主体的变更，也是命名空间的变更。就LXC 而
言，资源管理是通过Cgroups 实现的，进程可以在cgroup 之间有条件地迁移；
命名空间的隔离是通过Namespaces 机制实现的，目前内核只支持进程变更有限
的几类命名空间。LXC 在处理进程在容器间迁移时，使用setns 系统调用切换进
程的命名空间，但是setns 系统调用目前只支持三类命名空间的切换，而LXC 需
要所有的命名空间都切换。因此，在现有内核上，使用LXC 的进程迁移功能会
失败。LXC 的解决办法是为内核打补丁来增加对剩余命名空间切换的支持。但
是这种办法对于用户并不友好，也抵消了LXC 的一部分优势，毕竟LXC 相对于
OpenVZ 等技术的一大优势就是内核级的支持，使用时不用额外打补丁。这个问
题目前还没有好的解决方法，理想情况就是新版本的内核集成这个补丁。
（四） 不支持checkpoint
checkpoint 技术可以将容器中所有的进程暂时Frozen，并容器完整的状态存
储到磁盘上。目前LXC 还不支持checkpoint 技术，虽然利用Cgroups 的Freezer
子系统，可以将容器中的进程暂时Frozen，也可以将Frozen 的进程恢复进行，
但是并没有存储容器完整的状态，效果类似将容器中的进程暂停和恢复。完整的
实现checkpoint，还需要在进程Frozen 时，将容器中所有进程的状态存下来，这
个可以通过扫描/proc 文件系统，记录相应的状态信息来实现。
（五） 不支持容器的动态迁移（live migration）
动态迁移是指将正在运行的容器从一个机器迁移到另一个机器。动态迁移不需要
停止容器中的进程，可以用来维护在线系统，减少服务器宕机的可能。另外，动
态迁移可以通过将容器从负载较高的服务器迁移到负载较低的服务器来优化服
务器集群的资源配置。LXC 目前并不支持动态迁移。动态迁移可以通过
checkpoint 来实现。将容器的进程暂时Frozen，将状态保存到文件，再将文件传
输到目标机器，在目标机器上恢复容器的运行。