操作系統(tǒng)虛擬化底層基礎之命名空間(namespace)-

1、操作系統(tǒng)虛擬化底層基礎之命名空間(namespace目錄目錄 (1背景 (2總覽 (3UTS命名空間子模塊 (3IPC命名空間子模塊 (5MNT命名空間子模塊 (7PID命名空間子模塊 (9NET命名空間子模塊 (12總結 (16背景隨著公司業(yè)務的迅猛發(fā)展,大量的機器在線上業(yè)務號召下投入了服務于廣大網(wǎng)民的神圣職責。不過基于一個不完全統(tǒng)計,我們公司的線上機器平均利用率20%左右,這就意味著70%左右的機器都是可回收或者復用的。出于節(jié)約機器,統(tǒng)一管理以及在線遷移的初衷,我們進行了虛擬化計算的研究。經(jīng)過選型測試以及具體應用場景的研究,我們選擇了操作系統(tǒng)虛擬化技術,即LXC。(為什么選擇LXC,Ope

2、nVZ如何?Xen效果如何等等這些問題請參考其他文檔,本文主要討論LXC的底層實現(xiàn)技術。LXC本身不是一個具體的技術,它是一個集合技術的代稱,我們可以總體上來看,LXC主要有namespace和cgroup兩大模塊構建而成,本系列主要就是說說這兩個技術,本文則專注于namespace。在我們講述具體的技術之前,先來看看容器模塊的整個狀態(tài)系統(tǒng),目前主要是IBM,google等公司的團隊在負責維護更新。 目前container已經(jīng)被上有內核所接納,所以不存在自己維護分支版本的問題。但是這些團隊之間合作不是我們想象的和諧,不同利益集團之間是有內核的政治訴求,都想把自家的內容扶位正房,導致我們再看操作

3、系統(tǒng)虛擬化的時候會有不同項目博弈的事跡。總覽每一個進程其所包含的命名空間都被抽象層一個nsproxy指針,共享同一個命名空間的進程指向同一個指針,指針的結構通過引用計數(shù)(count來確定使用者數(shù)目。當一個進程其所處的用戶空間發(fā)生變化的時候就發(fā)生分裂。通過復制一份老的命名空間數(shù)據(jù)結構然后做一些簡單的修改,接著賦值給相應的進程。 看了上面的數(shù)據(jù)結構,我們就會基本明白,命名空間本身只是一個框架,需要其他實行虛擬化的子系統(tǒng)實現(xiàn)自己的命名空間。這些子系統(tǒng)的對象就不再是全局維護的一份結構了,而是和進程的用戶空間數(shù)目一致,每一個命名空間都會有對象的一個具體實例。目前Linux系統(tǒng)實現(xiàn)的命名空間子系統(tǒng)主要有U

4、TS、IPC、MNT、PID以及NET網(wǎng)絡子模塊。我們在下文會針對這些子模塊進行進一步的分析。UTS命名空間子模塊UTS相對而言是一個簡單的扁平化命名空間子模塊,其不同的命名空間之間沒有層次關系。我們先來看一下UTS的數(shù)據(jù)結構。 New_utename結構里面就是我們通過uname a能夠看到的信息?？匆幌聶C器上的輸出: 我通過紅色斜線把uname a的輸出分隔開,分別對應上面的new_utsname的結構體。另外內核還把這些信息也通過proc文件系統(tǒng)導出,我們可以通過/proc/sys/kernel目錄里面的如下等變量(Ostype/ hostname/osrelease/ version查

5、看,當然這些變量的值也是可以更改的。初始的時候,系統(tǒng)默認構造了一個UTS結構,他的值分別如下所述。 當一個新的命名空間創(chuàng)建的時候,copy_utsname會被調用來創(chuàng)建一個UTS的命名空間,主要工作在clone_uts_ns函數(shù)里面完成。 上面講述了UTS的代碼表示,我們再來只管看一下UTS Namespace和Kref配合使用的場景。 上述順序描述了ustname在容器里面的局部化以及和引用計數(shù)配合完成的對象生命周期管理。IPC命名空間子模塊IPC作為一個常見的進程間通信工具,命名空間對他也進行了部分支持。另外IPC也是一個較為簡單的扁平化進程間通信工具,命名空間之間不存在層級。 上面羅列的

6、主要是IPC 命名空間里面包含的元素,各個命名空間之間的關系是并列的。 我們直觀的給一個圖描述資源隔離使用概念圖。 屬于不同命名空間的進程之間是不能訪問對方的全局資源的,這兒展示的主要是IPC 的SHM ,MSG 以及SEM ,在較新的代碼里MQueue 也可以被隔離。MNT命名空間子模塊虛擬機的一個核心功能就是完成應用的隔離,即業(yè)務之間相互不可見。這一塊主要通過文件系統(tǒng)的視圖來完成,進程創(chuàng)建的時候,每一個進程都有自己的文件掛節(jié)點信息?？匆幌陆?jīng)典的struct task_struct. 在一個系統(tǒng)啟動的時候,0號進程就設置好了自己所在的根目錄以及當前目錄。在創(chuàng)建子進程的時候,通過CLONE_F

7、S來指明父子之間的共享信息,如果設置了兩者共享同一個結構(指針加上引用計數(shù),沒有設置標記的話,子進程創(chuàng)建一個新的拷貝,兩者之間互不影響。如果設置了CLONE_FS,接下來通過chroot(2, chdir(2, or umask(2的調用結果兩者之間會相互影響,反之兩者是獨立的。 下面這張圖清晰明了的刻畫了進程內部的文件系統(tǒng)信息以及文件描述符的位置,同時還可以看到一個文件的主要組成部分。 通過文字以及代碼描述還是比較枯燥而且不方便直觀,下面我們通過圖形的方式來看一下進程的文件系統(tǒng)映射情況。 最初我們在系統(tǒng)(system目錄里面創(chuàng)建了一個container目錄,然后在這個目錄里面為每一個虛擬機創(chuàng)

8、建了獨立的目錄,例如1和2(本例。在目錄1和2里面分別創(chuàng)建相應虛擬機的根目錄文件系統(tǒng)。這樣虛擬機啟動的時候,我們chroot到1或者2里面,看到的文件系統(tǒng)試圖就如下所示。 在這種使用方式下,虛擬機1和虛擬機2之間的文件系統(tǒng)是互不可見的,而且虛擬機也看不到除了根目錄之外的其他文件目錄。為了和系統(tǒng)或者其他虛擬機部分共享文件,我們可以映射特定目錄到虛擬機的根文件系統(tǒng),達到部分隔離以及共享的效果,下圖。 PID命名空間子模塊PID是虛擬化命名空間里面較復雜的模塊,因為前面的命名空間基本都是扁平的,沒有層次結構。但是PID命名空間是有層次的,在高層次命名空間能夠看到所有的低層次命名空間信息,反之則不行。

9、先直觀來看看層次化的命名空間結構以及進程的數(shù)字變化。需要指出的是,對于命名空間里面的進程,我們看到好像有多個,其實是一一對應的,即進程只有一個,但是在不同的命名空間里面有不同的數(shù)據(jù)表示,獲取一個進程信息需要進程號加上空間信息才能唯一確定一個進程。 全局命名空間的init進程,其中一個目的是對孤兒進程進行回收。Level則表明自己所處的命名空間在系統(tǒng)命名空間里面的深度,這是一個重要的標記,因為層次高的命名空間可以看到低級別的所有信息。系統(tǒng)的命名空間從0開始技術,然后累加。命名空間的層次結構通過parent來關聯(lián)。了解完PID命名空間的信息后,我們再來看看PID為了支持命名空間所需要做的修改。以前

10、的PID命名空間是全局唯一的,現(xiàn)在則必須是命名空間局部化,有一個可見的命名空間就必須有一個PID變量。來看看PID的內核表示,系統(tǒng)對于每一個PID都有一個PID結構體來表示,但是在每一個命名空間里面的upid表示具體的數(shù)值。 上面的PID就是我們在系統(tǒng)中內核的表示,一個PID可能對應多個task_struct,所以在上面的表示里面通過一個task數(shù)組來表示。接著numbers數(shù)字分別表示在不同命名空間里面可以看到的pid數(shù)值,因為numbers在最后一個位置,所有本質上來說相當于一個指針,增加命名空間的時候,再增加一個numbers即可。 上述的upid則是具體的命名空間內數(shù)值表示,nr表示數(shù)

11、字,ns則指向關聯(lián)的命名空間。當然系統(tǒng)的所有upid通過pid_chain掛在同一個全局鏈表里。 這張表格和上圖一起結合起來我們理解PID的管理結構。一個task_struct通過pid_link的hlist_node掛接到struct pid的鏈表上面去。同時task_struct又是用過pid_link找到pid,通過pid遍歷tasks鏈表又能夠得到所有的任務,當然也可以讀取numbers數(shù)字獲取每一個命名空間里面的數(shù)字信息。為了在pid和upid之間轉換,系統(tǒng)提供了很多內部轉換接口,我們首先來了解一些基本指導性原則。._nr(通過nr結尾的函數(shù)就是獲取以前所謂的全局PID,這個全局PI

12、D和我們在以前系統(tǒng)里面所見的PID是一致的。例如pid_nr(pid就返回給定pid的全局PID數(shù)值。這些數(shù)值往往只有在本機有效,例如一些通過PID獲取進程結構的代碼。但是在這種情況下,保存pid結構往往比全局PID更有意義,因為全局PID不能隨意遷移。._vnr(Vnr結尾的函數(shù)主要和局部pid打交道,例如一個進程可見的局部ID。來看一個例子, task_pid_vnr(tsk就返回它能夠看到任務PID。需要注意的是,這個數(shù)字僅僅在本命名空間內有效。._nr_ns(以nr_ns結尾的函數(shù)能夠獲取到特定命名空間課間的PID數(shù)值,如果你想得到一些任務的PID數(shù)值,你就可以通過task_pid_n

13、r_ns(tsk, current-nsproxy-pid_ns調用得到數(shù)字,接著通過find_task_by_pid_ns(pid, current-nsproxy-pid_ns反過來找到任務結構。當一個用戶請求過來的時候,基本上都是調用這組函數(shù),因為這種情況下一個任務可能需要得到另外一個命名空間的信息。NET命名空間子模塊NET的命名空間隔離做的工作相對而言是最多的,但是整體思路還是一致的,即把全局的資源局部化,在每一個命名空間里面保留自己的控制信息。例如在目前的內核里面路由表,arp表,netfilter表,設備等等都已經(jīng)空間化了,其所做的后續(xù)操作都要首先關聯(lián)到特定的命名空間,然后再取出

14、里面的數(shù)據(jù)進行后面的分析。 名空間創(chuàng)建的時候,會做一些初始化。所有系統(tǒng)定義了一個回調函數(shù),讓感興趣的模塊注冊。結構如下: 注冊接口如下 一個新的用戶空間被創(chuàng)建的時候,注冊模塊的init結構被創(chuàng)建。同理,一個空間銷毀的時候,exit函數(shù)也會被調用。那么現(xiàn)在有了很多命名空間,而且命名空間之間是隔離的,那么他們之間怎么通信呢。這兒需要注意的是引入了一個新的概念,就做網(wǎng)絡設備對。一個設備對即A設備接收到的時間自動發(fā)送到B設備,反之亦然。我們先來從直觀上看一下網(wǎng)絡概念圖。 接下來的問題就是如何通信?其實可以通過二層或者三層來實現(xiàn)網(wǎng)絡轉發(fā),本質上就是通過橋接還是路由。我們下面以橋接為例來說明數(shù)據(jù)報文是如何

15、轉發(fā)的。對于容器1來說,veth1需要配置一個IP地址,但是veth0和eth0配置在同一個橋接設備上。Veth0和veth1是網(wǎng)絡設備對。 是一個實際網(wǎng)絡環(huán)境里面的虛擬化配置,veth0和eth0是通過橋接來完成轉發(fā),但是veth0和veth1之間是通過設備對來完成數(shù)據(jù)轉發(fā),其他概念都沒有太多變化,除了增加一個獨立的命名空間,這兒我們來看看網(wǎng)絡設備對是如何工作的。創(chuàng)建過程不再討論,就是每次創(chuàng)建一對,A和B的對端分別指向彼此。 創(chuàng)建完了后,彼此關聯(lián)。 我們還是來看看數(shù)據(jù)通道,他們的數(shù)據(jù)是如何透傳的。過 eth_type_trans 替換設備指針，接著就通過 netif_rx 送上起，設備已經(jīng)屬于一個