操作系统虚拟化底层基础之命名空间(namespace)

操作系统虚拟化底层基础之命名空间（namespace）黎润([e-mail])目录目录....................................................................................................................1背景...............................................................................................................2总览...............................................................................................................3UTS命名空间子模块........................................................................................3IPC命名空间子模块.........................................................................................5MNT命名空间子模块.......................................................................................7PID命名空间子模块.........................................................................................9NET命名空间子模块......................................................................................12总结.............................................................................................................16背景随着公司业务的迅猛发展，大量的机器在线上业务号召下投入了服务于广大网民的神圣职责。不过基于一个不完全统计，我们公司的线上机器平均利用率20%左右，这就意味着70%左右的机器都是可回收或者复用的。出于节约机器，统一管理以及在线迁移的初衷，我们进行了虚拟化计算的研究。经过选型测试以及具体应用场景的研究，我们选择了操作系统虚拟化技术，即LXC。（为什么选择LXC，OpenVZ如何？Xen效果如何等等这些问题请参考其他文档，本文主要讨论LXC的底层实现技术）。LXC本身不是一个具体的技术，它是一个集合技术的代称，我们可以总体上来看，LXC主要有namespace和cgroup两大模块构建而成，本系列主要就是说说这两个技术，本文则专注于namespace。在我们讲述具体的技术之前，先来看看容器模块的整个状态系统，目前主要是IBM，google等公司的团队在负责维护更新。目前container已经被上有内核所接纳，所以不存在自己维护分支版本的问题。但是这些团队之间合作不是我们想象的和谐，不同利益集团之间是有内核的政治诉求，都想把自家的内容扶位正房，导致我们再看操作系统虚拟化的时候会有不同项目博弈的事迹。总览每一个进程其所包含的命名空间都被抽象层一个nsproxy指针，共享同一个命名空间的进程指向同一个指针，指针的结构通过引用计数（count）来确定使用者数目。当一个进程其所处的用户空间发生变化的时候就发生分裂。通过复制一份老的命名空间数据结构然后做一些简单的修改，接着赋值给相应的进程。看了上面的数据结构，我们就会基本明白，命名空间本身只是一个框架，需要其他实行虚拟化的子系统实现自己的命名空间。这些子系统的对象就不再是全局维护的一份结构了，而是和进程的用户空间数目一致，每一个命名空间都会有对象的一个具体实例。目前Linux系统实现的命名空间子系统主要有UTS、IPC、MNT、PID以及NET网络子模块。我们在下文会针对这些子模块进行进一步的分析。UTS命名空间子模块UTS相对而言是一个简单的扁平化命名空间子模块，其不同的命名空间之间没有层次关系。我们先来看一下UTS的数据结构。New_utename结构里面就是我们通过uname–a能够看到的信息。看一下机器上的输出：我通过红色斜线把uname–a的输出分隔开，分别对应上面的new_utsname的结构体。另外内核还把这些信息也通过proc文件系统导出，我们可以通过/proc/sys/kernel目录里面的如下等变量（Ostype/hostname/osrelease/version）查看,当然这些变量的值也是可以更改的。初始的时候，系统默认构造了一个UTS结构，他的值分别如下所述。当一个新的命名空间创建的时候，copy_utsname会被调用来创建一个UTS的命名空间，主要工作在clone_uts_ns函数里面完成。上面讲述了UTS的代码表示，我们再来只管看一下UTSNamespace和Kref配合使用的场景。上述顺序描述了ustname在容器里面的局部化以及和引用计数配合完成的对象生命周期管理。IPC命名空间子模块IPC作为一个常见的进程间通信工具，命名空间对他也进行了部分支持。另外IPC也是一个较为简单的扁平化进程间通信工具，命名空间之间不存在层级。上面罗列的主要是IPC命名空间里面包含的元素，各个命名空间之间的关系是并列的。我们直观的给一个图描述资源隔离使用概念图。属于不同命名空间的进程之间是不能访问对方的全局资源的，这儿展示的主要是IPC的SHM，MSG以及SEM，在较新的代码里MQueue也可以被隔离。NamespaceNamespaceNamespace……NSProxyNSProxy……MNT命名空间子模块虚拟机的一个核心功能就是完成应用的隔离，即业务之间相互不可见。这一块主要通过文件系统的视图来完成，进程创建的时候，每一个进程都有自己的文件挂节点信息。看一下经典的structtask_struct.在一个系统启动的时候，0号进程就设置好了自己所在的根目录以及当前目录。在创建子进程的时候，通过CLONE_FS来指明父子之间的共享信息，如果设置了两者共享同一个结构（指针加上引用计数），没有设置标记的话，子进程创建一个新的拷贝，两者之间互不影响。如果设置了CLONE_FS，接下来通过chroot(2),chdir(2),orumask(2)的调用结果两者之间会相互影响，反之两者是独立的。下面这张图清晰明了的刻画了进程内部的文件系统信息以及文件描述符的位置，同时还可以看到一个文件的主要组成部分。通过文字以及代码描述还是比较枯燥而且不方便直观，下面我们通过图形的方式来看一下进程的文件系统映射情况。最初我们在系统（system）目录里面创建了一个container目录，然后在这个目录里面为每一个虚拟机创建了独立的目录，例如1和2（本例）。在目录1和2里面分别创建相应虚拟机的根目录文件系统。这样虚拟机启动的时候，我们chroot到1或者2里面，看到的文件系统试图就如下所示。在这种使用方式下，虚拟机1和虚拟机2之间的文件系统是互不可见的，而且虚拟机也看不到除了根目录之外的其他文件目录。为了和系统或者其他虚拟机部分共享文件，我们可以映射特定目录到虚拟机的根文件系统，达到部分隔离以及共享的效果，下图。PID命名空间子模块PID是虚拟化命名空间里面较复杂的模块，因为前面的命名空间基本都是扁平的，没有层次结构。但是PID命名空间是有层次的，在高层次命名空间能够看到所有的低层次命名空间信息，反之则不行。先直观来看看层次化的命名空间结构以及进程的数字变化。需要指出的是，对于命名空间里面的进程，我们看到好像有多个，其实是一一对应的，即进程只有一个，但是在不同的命名空间里面有不同的数据表示，获取一个进程信息需要进程号加上空间信息才能唯一确定一个进程。看完了PID命名空间的组织后，我们来看看他的代码实现。structpid_namespace{structkrefkref;structpidmappidmap[PIDMAP_ENTRIES];intlast_pid;structtask_struct*child_reaper;structkmem_cache*pid_cachep;unsignedintlevel;structpid_namespace*parent;……};上图里面重要的一些字段通过红色标注了出来，child_reaper指向的进程作用相当于全局命名空间的init进程，其中一个目的是对孤儿进程进行回收。Level则表明自己所处的命名空间在系统命名空间里面的深度，这是一个重要的标记，因为层次高的命名空间可以看到低级别的所有信息。系统的命名空间从0开始技术，然后累加。命名空间的层次结构通过parent来关联。了解完PID命名空间的信息后，我们再来看看PID为了支持命名空间所需要做的修改。以前的PID命名空间是全局唯一的，现在则必须是命名空间局部化，有一个可见的命名空间就必须有一个PID变量。来看看PID的内核表示，系统对于每一个PID都有一个PID结构体来表示，但是在每一个命名空间里面的upid表示具体的数值。上面的PID就是我们在系统中内核的表示，一个PID可能对应多个task_struct，所以在上面的表示里面通过一个task数组来表示。接着numbers数字分别表示在不同命名空间里面可以看到的pid数值，因为numbers在最后一个位置，所有本质上来说相当于一个指针，增加命名空间的时候，再增加一个numbers即可。上述的upid则是具体的命名空间内数值表示，nr表示数字，ns则指向关联的命名空间。当然系统的所有upid通过pid_chain挂在同一个全局链表里。这张表格和上图一起结合起来我们理解PID的管理结构。一个task_struct通过pid_link的hlist_node挂接到structpid的链表上面去。同时task_struct又是用过pid_link找到pid，通过pid遍历tasks链表又能够得到所有的任务，当然也可以读取numbers数字获取每一个命名空间里面的数字信息。为了在pid和upid之间转换，系统提供了很多内部转换接口，我们首先来了解一些基本指导性原则。..._nr()通过nr结尾的函数就是获取以前所谓的全局PID，这个全局PID和我们在以前系统里面所见的PID是一致的。例如pid_nr(pid)就返回给定pid的全局PID数值。这些数值往往只有在本机有效，例如一些通过PID获取进程结构的代码。但是在这种情况下，保存pid结构往往比全局PID更有意义，因为全局PID不能随意迁移。..._vnr()Vnr结尾的函数主要和局部pid打交道，例如一个进程可见的局部ID。来看一个例子，task_pid_vnr(tsk)就返回它能够看到任务PID。需要注意的是，这个数字仅仅在本命名空间内有效。..._nr_ns()以nr_ns结尾的函数能够获取到特定命名空间课间的PID数值，如果你想得到一些任务的PID数值，你就可以通过task_pid_nr_ns(tsk,current-nsproxy-pid_ns)调用得到数字，接着通过find_task_by_pid_ns(pid,current-nsproxy-pid_ns)反过来找到任务结构。当一个用户请求过来的时候，基本上都是调用这组函数，因为这种情况下一个任务可能需要得到另外一个命名空间的信息。NET命名空间子模块NET的命名空间隔离做的工作相对而言是最多的，但是整体思路还是一致的，即把全局的资源局部化，在每一个命名空间里