定義 roc min ffffff 網絡類型 提供服務 color neu 不可

一、概述

想必接觸過Open stack的人都知道，Opens stack中最復雜的是網絡部份，在實際的生產環境中更是如此，實際場景下往往不僅有Open stack網絡，還有外部網絡（Open stack將其無法管理的網絡統稱為外部網絡），即便在Open stack內部，客戶也有不同的網絡訴求，本文選取2個案例對常見的網絡模型進行說明。

二、案例說明

1.運營商網絡和租戶網絡
Open stack是面向眾多租戶提供服務的雲操作系統，由租戶自行創建的網絡稱為租戶網絡，但有時候會出現以下這種情況：

上圖是一個租戶的VLAN網絡，其VID為100，這個網絡的計算機並不是虛擬機，即不受Open stack管理，此時該租戶需要增加一批虛擬機，而虛擬機VID也必須是100（br-XX轉換後的VID），這時Open stack就需要創建一個網絡來映射外部網絡，創建的這個網絡就稱為運營商網絡。運營商網絡可以看成是Open stack網絡的外部延展，但其生命周期並不受Neutron組件管理，需要註意的是，創建的網絡類型和VID號要和待映射的網絡完全一致。運營上網絡和租戶網絡的區別主要表現在以下2點：

（1）管理的權限與角色不同。租戶網絡由租戶自行創建，而運營商網絡是由管理員通過administrator賬戶創建。
（2）創建網絡時，傳遞的參數不同。創建運營商網絡時需要傳遞provider:network_type、provider:physical_network、provider:network_id這3個參數，Open stack認為用戶只需要關心服務，所以租戶創建網絡時不需要傳遞這3個參數，這3個參數實際上是通過配置文件間接獲取。
上文中提到的provider:network_type、provider:network_id好理解，就是對應的網絡類型（VLAN或VXLAN）和VID值，但provider:physical_network又起到什麽作用？通過上圖可以知道，對於非隧道型網絡（VLAN）VM在經過br-XX2之後需要轉換成待映射網絡的VID後就可與外部網絡中的物理節點進行通信，但問題是Neutron怎麽知br-int必須要將報文發送給br-XX2，此時就需要用到provider:physical_network參數了，因為在配置文件中定義了每個physical_network所對應的物理網卡。對於隧道型網絡（VXLAN）這個參數沒有什麽意義，因為有了目的IP，主機的IP協議棧自己會找到合適的網卡發送出去。
2.VLAN aware VM
在之前的介紹中，VM接受和發送的都是Untag報文，如果這個VM（實際上是VM的vNIC）需要接入多個Vlan中，由於Neutron的資源模型是1個Port只能隸屬於1個Network，所以讓這1個Port屬於多個Network的方法就行不通，而給1個VM配置多個vNIC的方法在VM要接入多個Network的時候（比如1000個Network）就顯得不可取，此時就需要VM可以接受和發送帶有tag的報文。而根據先前的模型，br-int上的VID是由Open stack自行維護，所有報文必須經過br-int，且VM與br-int之間都是Access接口，一旦將VM與br-int之間的接口改為Trunk，當VM發出帶有tag的報文和br-int中的一致時就會造成撞車

為了解決上述問題，Open stack在N版本之後，就引入了VLAN aware VM模型，它采用1個父端口+多個子端口的方式，將原有的模型改為以下所示：

圖中VM1-1是普通的虛擬機，VM2-1是VLAN aware VM的虛擬機，它是通過在VM和br-int之間加入了1個br-trunk來解決了VID在br-int上撞車的問題，同時Untag的報文走父端口，Tag報文走子接口，有多少個VLAN就有多少個子接口，這樣也沒有改變Neutron中1個Port屬於1個Network的模型，需要註意的是：有多少個VLAN aware VM的虛擬機就有多少個br-trunk虛擬交換機。

Open stack生產環境中幾種常見的網絡結構