OpenStack-Neutron的資源隔離機制
OpenStack是一個多租戶的雲操作系統，其中提供網路實現Neutron自然也需要提供多租戶的服務。所以，多租戶之間資源隔離是Neutron必須要支持的特性。在Neutron的資源模型中，老版本有一個tenant_id的欄位，而從Newton版本開始，又引入了project_id，在官方文檔解釋中，這兩個都是：The ID of the project。因此，不論新老版本，這兩個欄位都表示一個意思：租戶資源隔離。（注意：這裡的指多租戶，單租戶也沒隔離的必要！！！）
租戶隔離，顧名思義就是為了資源隔離，但其更深層次的含義是多租戶資源共享！！！----這句話怎麼理解?我們慢慢往下看。
下面，我們一點點來分析這四個字---「租戶隔離」。
Neutron下面租戶資源隔離的含義
從租戶的視角，或者從需求的角度來看，租戶資源隔離有三種含義：管理面資源隔離、數據面資源隔離和故障面資源隔離。
管理面資源隔離是指管理許可權的隔離，如下圖所示：
上圖中，兩個網路Network VIN 100和Network VNI 200都是Neutron的管理範圍，但是VNI 100屬於租戶A，VNI 200屬於租戶B，這就意味租戶A的網路對租戶B而言是不可見的，租戶A也就無法管理（增刪改查）租戶B的網路，反之亦然。
數據面資源隔離是指數據轉發的隔離。不同租戶的網路不僅在管理上面隔離，而且在數據轉發層面還可以「重複」。比如，租戶A建立一個私網網段10.0.10.0/24，租戶B同樣可以建立10.0.10.0/24這個網段，這兩個網段不僅不會衝突，還可以互通（通過3層轉發），因此，數據面資源隔離的目的正是為了資源共享。
故障面的資源隔離就是指一個租戶網路出問題了，不能影響另一個租戶網路，但是這是相對的。比如上面那個圖，如果租戶A和租戶B同屬於一個計算節點host1，當租戶A網路的分散式虛擬路由器DVR A出問題了，自然不會影響租戶B的網路。但是，當租戶A和租戶B在網路節點的互通路由器router_global出問題了，那麼自然兩個網路都會受影響。再比如，該雲系統在都在西咸新區A機房部署，那麼這個機房的動力、線路等出問題，自然該部署在該機房A的所有租戶業務都會中斷。因此，故障面的租戶資源隔離，只是針對租戶本身獨佔的資源而言，而對於多租戶共享資源是無法做到也無需刻意去做的（我想就算是土豪動，也不能做到每個租戶所有資源都獨佔，那屬於敗家！）。因此，在多租戶共享層面資源只能盡量做到容錯，比如高可用集群的架構，其實就是我們常說的容災備份這個東東。其實，不光Neutron的故障資源隔離是這樣，所有OpenStack其他服務的故障隔離都是這種特點。
Neutron的租戶資源隔離實現模型
管理面的租戶資源隔離實現模型
管理面，對於Neutron而言就是控制節點。OpenStack的控制節點實現模型如下圖所示：
對於管理面而言，租戶資源隔離一般涉及幾個層面：硬體/操作系統層面、應用程序層面、資料庫層面。Neutron在這幾個層面的隔離方案如下：
硬體/操作系統層面：不隔離。管理面（控制節點）都部署在一個Host，多個租戶共享一個Host、一個操作系統，因此無法隔離。只能依靠集群高可用在做容災保障。
應用程序層面：不隔離。原因同上，管理面的各個服務，多租戶共享，因此無法隔離。只能依靠集群高可用在做容災保障。
資料庫層面：輕微隔離。OpenStack的各個服務（包括Nuetron）針對多個租戶，在資料庫層面採用共享資料庫，共享表的方式進行資源共享，只是通過表中欄位(project_id）來區分不同租戶。因此是一種輕微隔離方案。除了這種方案，資料庫層面還以採用獨立資料庫或共享資料庫，獨立表的方式來做隔離。
通過上面的分析，在OpenStack這種雲操作系統中，為了盡量保證服務的高可用特性，針對控制節點而言，生產環境必然也必須採用高可用集群的方式部署，其目的就是容災備份。
數據面的租戶資源隔離實現模型
為清楚描述，這裡我們採用OVS的實現方案，LinuxBridge的實現方案由於SecurityGroups和網橋brq在一起，會呈現獨佔和共享一體的畫面，對於新手容易混淆。
Nuetron的計算節點和網路節點都涉及數據轉發，所以這兩個節點也都涉及數據轉發的租戶隔離機制。
計算節點的實現模型如下：
br-ethx/br-tun、br-int分別只有一個實例，這個是屬於：用「多租戶共享」的方案，來實現多租戶隔離。比如，br-int、br-ethx通過VLAN來隔離來自各個租戶網路的數據流量，br-tun通過相應的tunnel ID，即VNI來隔離多租戶的網路流量。
qbr和VM一一對應，這個屬於：「單租戶獨佔」的方案，來實現多租戶隔離。qbr由於綁定了安全組，它在原生的數據面租戶隔離的基礎上又多加了一層「安全層」來保證租戶資源隔離。原生的數據面轉發（br-tun/br-ehtx、br-int）負責「正常行為」的租戶隔離，而安全技術（qbr)負責「異常行為」（非法訪問）的租戶隔離。
Router/DVR跟租戶相對應，而且每個Router/DVR運行在一個namespace中，這個屬於：「單租戶獨佔」（用namespace隔離）的方案，來實現多租戶隔離的目的。這裡有必要先解釋下什麼是namespace？namespace是linux操作系統虛擬網路的一個重要概念。最早的linux系統的許多資源都是共享的，比如進程ID資源，而namespace的出現就是將這些資源進行隔離。linux可以在一個Host內創建許多namespace，於是linux系統下那些全局資源，就變成namespace範圍內的「全局」資源，而且不同namespace的資源互相透明，不可見。
從namespace的代碼可以看出哪些全局資源被進行隔離，如下所示，Linux全局資源的數據結構定義如下：（在文件nsproxy.h中）
Struct nsproxy {
Atomic_t count;
Struct uts_namespace *uts_ns;#UTS是Unix Timesharing System的簡稱，包含內核名稱、版本、底層體系結構等信息。
Struct ipc_namespace *ipc_ns;#所有與進程通信（IPC）有關的信息。
Struct mnt_namespace *mnt_ns;#當前系統裝在的文件系統；
Struct pid_namespace *pid_ns;#有關進程的id信息。
Struct user_namespace *user_ns;#資源配額信息。
Struct net *net_ns;#網路信息。
};
通過namespace隔離後的，在一個host內部多個namespace的資源獨佔效果如下：
上圖表示在一個host內部建了3個namespace，分別是LLB_NS1、LLB_NS2、LLB_NS3，每個namespace都對系統的全局資源進行隔離，彼此互相不可見，同時在Host中，當然也會有一套同樣資源。其實linux系統本身就是一個namespace，這個namespace管理系統的軟體和硬體資源，也就是整個host的物理資源都屬於這個namespace，這個namespace我們把它叫做root namespace。而我們建立的LLB_NS1/2/3等namespace，只是管理該namespace的虛擬資源，在內核底層其實還是共享的。
單純從網路角度來說，一個namespace提供了一份獨立的網路協議棧（網路設備介面、IPv4、IPv6、路由、防火牆規則和套接字socket等）。一個設備（linux device）只能位於一個namespace中，不同namespace的設備可以利用veth pair進行橋接。用個例子來驗證下，比如我們在用戶空間創建一個tap設備（創建tap設備的操作見前面章節），此時我們再創建一個namespace（llb_ns1），然後將前面創建的tap設備移到llb_ns1中，此時我們可以在用戶空間再查下是否還存在這個tap設備？
圖1：我們創建一個tap設備tap_llb1，在root空間可以查詢到.
圖2：此時我們再創建一個namespace（llb_ns1）
圖3：我們將root空間下的tap_llb1搬遷到llb_ns1空間下，然後再root空間下查詢，發現tap_llb1已經看不見了。
圖4：此時，我們進入llb_ns1下，通過查詢發現原來root空間的tap_llb1已經被放在了llb_ns1空間下。
通過上面我們的驗證就可以知道，namespace彼此之間是完全隔離不可見的。即使在root namespace下也查詢不到其他namespace空間的資源。
網路節點的實現模型如下：
網路節點中，br-ethx/br-tun、br-int、br-ex分別只有一個實例，這是屬於：「多租戶共享」的方案，實現了多租戶隔離的目的。
Router跟租戶對應，而且每個Router運行在一個namespace中，這屬於：「單租戶獨佔」的方案，實現了多租戶隔離的目的。Router/DVR不僅保證了租戶間網路不會互相訪問外，還解決了邏輯資源（IP地址）衝突的問題。
故障面的租戶資源隔離實現模型
通過前面的介紹，Neutron在數據面和控制面的租戶資源隔離方案分為兩類：資源單租戶獨佔（比如Router等）和資源多租戶共享（比如br-int等）。
在故障資源隔離層面，對資源共享方案，沒有任何故障層面的租戶隔離能力，一旦一個部件發生故障，所有與其關聯的租戶都要受到影響。而對於資源獨佔方案，具有一定故障層面隔離能力，比如一個租戶的Router發生故障，不會影響其他租戶。
以數據面的實現方案為例，故障面的租戶隔離度與資源共享度的關係如下圖所示。
但是，資源獨佔的粒度是有限的，也僅僅是在Router這樣的層面才能做到租戶資源獨佔，稍微大一點的粒度，比如主機Host，都不能保證資源獨佔。這不是技術問題，這是雲服務的商業本質決定的。因此，高可用集群部署方案必不可少。
用資源共享的方式來實現租戶隔離，在正常情況下沒有任何問題，但是如果發生故障，資源共享方案要想做到故障層面的租戶隔離，這是不可能的。如果非要做成獨佔方式來隔離故障那是敗家行為，土豪動也傷不起。
通過上面的介紹，就回到我們開頭那句話：「租戶隔離，顧名思義就是為了資源隔離，但其更深層次的含義是多租戶資源共享！！！」。隔離的其實都是租戶使用的邏輯資源，其目的就是為了對底層資源能夠做到復用，最大限度使用底層資源，這是針對控制面和數據而言。而針對故障面，由於隔離的真實目的是共享這個原因，正所謂，一榮俱榮，一損俱損，此時不僅是考邏輯資源隔離的問題，更多的是考慮資源容錯的問題，也就是我們常說的高可用集群，這其實也是資源復用的一種方式，只是復用的資源對象是集群這個整體而已。
PS：集群不是一堆伺服器的意思，一堆伺服器各自為政，每個對外提供和呈現的服務和資源都不一樣。而集群是個整體的概念，底層是由一堆伺服器組成，但是對外統一呈現、統一提供，因此，這裡面就涉及到數據和資源管理的問題（同步和共享）。
TAG:CloudSupermanLLB |