操作系统虚拟化底层基础之命名空间(namespace)
来源:互联网 发布:舔女生尿道口 知乎 编辑:程序博客网 时间:2024/05/17 01:26
操作系统虚拟化底层基础之命名空间(namespace)
黎润(yijunzhu@qq.com)
背景
随着公司业务的迅猛发展,大量的机器在线上业务号召下投入了服务于广大网民的神圣职责。不过基于一个不完全统计,我们公司的线上机器平均利用率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结构,他的值分别如下所述。
上面讲述了UTS的代码表示,我们再来只管看一下UTS Namespace和Kref配合使用的场景。
IPC命名空间子模块
IPC作为一个常见的进程间通信工具,命名空间对他也进行了部分支持。另外IPC也是一个较为简单的扁平化进程间通信工具,命名空间之间不存在层级。
上面罗列的主要是IPC 命名空间里面包含的元素,各个命名空间之间的关系是并列的。
IPC Namespace
IPC Namespace
IPC Namespace
……
NSProxy
NSProxy
……
我们直观的给一个图描述资源隔离使用概念图。
属于不同命名空间的进程之间是不能访问对方的全局资源的,这儿展示的主要是IPC的SHM,MSG以及SEM,在较新的代码里MQueue也可以被隔离。
MNT命名空间子模块
在一个系统启动的时候,0号进程就设置好了自己所在的根目录以及当前目录。在创建子进程的时候,通过CLONE_FS来指明父子之间的共享信息,如果设置了两者共享同一个结构(指针加上引用计数),没有设置标记的话,子进程创建一个新的拷贝,两者之间互不影响。如果设置了CLONE_FS,接下来通过chroot(2),chdir(2), or umask(2)的调用结果两者之间会相互影响,反之两者是独立的。
通过文字以及代码描述还是比较枯燥而且不方便直观,下面我们通过图形的方式来看一下进程的文件系统映射情况。
最初我们在系统(system)目录里面创建了一个container目录,然后在这个目录里面为每一个虚拟机创建了独立的目录,例如1和2(本例)。在目录1和2里面分别创建相应虚拟机的根目录文件系统。这样虚拟机启动的时候,我们chroot到1或者2里面,看到的文件系统试图就如下所示。
在这种使用方式下,虚拟机1和虚拟机2之间的文件系统是互不可见的,而且虚拟机也看不到除了根目录之外的其他文件目录。为了和系统或者其他虚拟机部分共享文件,我们可以映射特定目录到虚拟机的根文件系统,达到部分隔离以及共享的效果,下图。
PID命名空间子模块
看完了PID命名空间的组织后,我们来看看他的代码实现。
struct pid_namespace {
};
上图里面重要的一些字段通过红色标注了出来,child_reaper指向的进程作用相当于全局命名空间的init进程,其中一个目的是对孤儿进程进行回收。Level则表明自己所处的命名空间在系统命名空间里面的深度,这是一个重要的标记,因为层次高的命名空间可以看到低级别的所有信息。系统的命名空间从0开始技术,然后累加。命名空间的层次结构通过parent来关联。
了解完PID命名空间的信息后,我们再来看看PID为了支持命名空间所需要做的修改。以前的PID命名空间是全局唯一的,现在则必须是命名空间局部化,有一个可见的命名空间就必须有一个PID变量。
这张表格和上图一起结合起来我们理解PID的管理结构。一个task_struct通过pid_link的hlist_node挂接到struct pid的链表上面去。同时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的命名空间隔离做的工作相对而言是最多的,但是整体思路还是一致的,即把全局的资源局部化,在每一个命名空间里面保留自己的控制信息。例如在目前的内核里面路由表,arp表,netfilter表,设备等等都已经空间化了,其所做的后续操作都要首先关联到特定的命名空间,然后再取出里面的数据进行后面的分析。
首先来看看net命名空间的结构体
struct net {
#ifdef NETNS_REFCNT_DEBUG
#endif
#ifdef CONFIG_SYSCTL
#endif
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
#endif
#if defined(CONFIG_IP_DCCP) || defined(CONFIG_IP_DCCP_MODULE)
#endif
#ifdef CONFIG_NETFILTER
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
#endif
#endif
#ifdef CONFIG_XFRM
#endif
};
上面这个结构实在较大,您在需要深入了解的时候慢慢了解每个子模块吧。在一个命名空间创建的时候,会做一些初始化。所有系统定义了一个回调函数,让感兴趣的模块注册。结构如下:
注册接口如下
那么现在有了很多命名空间,而且命名空间之间是隔离的,那么他们之间怎么通信呢。这儿需要注意的是引入了一个新的概念,就做网络设备对。一个设备对即A设备接收到的时间自动发送到B设备,反之亦然。
我们先来从直观上看一下网络概念图。
接下来的问题就是如何通信?其实可以通过二层或者三层来实现网络转发,本质上就是通过桥接还是路由。我们下面以桥接为例来说明数据报文是如何转发的。
对于容器1来说,veth1需要配置一个IP地址,但是veth0和eth0配置在同一个桥接设备上。Veth0和veth1是网络设备对。
创建过程不再讨论,就是每次创建一对,A和B的对端分别指向彼此。
创建完了后,彼此关联。
我们还是来看看数据通道,他们的数据是如何透传的。
总结
终于把内核的命名空间大致模块都看了一遍,其实我们只要在心理面把握住重要的一点就可以了。所有虚拟化的资源,在获取资源的时候,必须首先通过nsproxy获取到合适的命名空间,然后再进行接下来的操作。另外命名空间虽然用户空间程序不是很多,但是在内核里面很早就引入了,而且一堆人活跃的维护着。
- 操作系统虚拟化底层基础之命名空间(namespace)
- Linux虚拟化基础之命名空间
- 命名空间(namespace)
- 命名空间(namespace)
- C++之namespace命名空间
- namespace命名空间-之使用
- Docker基础: Linux内核命名空间之(1) mnt namespace
- Docker基础: Linux内核命名空间之(2) ipc namespace
- Docker基础: Linux内核命名空间之(3)net namespace
- Docker基础: Linux内核命名空间之(4)uts namespace
- Docker基础: Linux内核命名空间之(5)pid namespace
- Docker基础: Linux内核命名空间之(6)user namespace
- 理解namespace(命名空间)
- JS命名空间(namespace)
- xml 命名空间(Namespace)
- C++ 命名空间(namespace)
- php命名空间(namespace)
- C# 命名空间(Namespace)
- 从先序遍历和中序遍历重建二叉树
- 再试一下,看是否好用
- poj 2594 二分图 Floyd闭包+最小路径覆盖
- Dom解析XML文件具体用法
- poj 2029 (暴力枚举)水题
- 操作系统虚拟化底层基础之命名空间(namespace)
- 51416/D辛苦屎了,骗纸呐o o
- 网页设计用目标的好处
- 一个setInterval的小问题
- python学习二
- JSP中response.sendRedirect()后的代码为什么还能执行
- 编程之美--3.5最短摘要的生成
- DEV控件:gridControl常用属性设置
- POJ-1915 Knight Moves