OpenContrail 體系架構(gòu)文檔

英文原文：http://opencontrail.org/opencontrail-architecture-documentation/

翻譯者：@KkBLuE知行合一? 其微信號：kkbluepublic， SDNAP.com翻譯整理

OpenContrail?體系架構(gòu)文檔

1? 概述?
1.1? 使用案例?
1.2? OpenContrail控制器和vRouter?
1.3? 虛擬網(wǎng)絡(luò)?
1.4???? Overlay Networking?
1.5???? Overlays based on MPLS L3VPNs and EVPNs?
1.6???? OpenContrail and Open Source?
1.7? 擴(kuò)展架構(gòu)和高可用性

1.8? 數(shù)據(jù)模型中心規(guī)則：SDN作為編譯器存在?
1.9? 北向應(yīng)用程序接口?
1.10? GUI用戶端口?
1.11? 擴(kuò)展平臺

2? 體系細(xì)節(jié)?
2.2? OpenContrail轉(zhuǎn)發(fā)平面?
2.3? 服務(wù)鏈?
2.4? 控制和管理平臺協(xié)議?
2.5? 集成?
2.6? 安全?
2.7? 層次化擴(kuò)展和高可用性?
3? 數(shù)據(jù)模型?
3.1? 編程模型?
3.2? 配置和運維數(shù)據(jù)模型

4? OpenContrail用戶案例?
4.1? 數(shù)據(jù)中心域用戶案例?
4.2? 運營商網(wǎng)絡(luò)NFV

5? 比較OpenContrail系統(tǒng)和MPLM VPN

6? 縮略語表

7? 參考文檔

1? Overview of OpenContrail

本章節(jié)介紹OpenContrail系統(tǒng)—一個SDN的擴(kuò)展平臺

所有主要內(nèi)容在本章中都有簡略介紹，詳細(xì)內(nèi)容會在后續(xù)章節(jié)中繼續(xù)描述

1.1??使用案例

OpenContrail是一個擴(kuò)展系統(tǒng)，可以應(yīng)用在不同的網(wǎng)絡(luò)環(huán)境中，但是，其使用的主要驅(qū)動力在于如下兩個體系結(jié)構(gòu)下

• 云計算網(wǎng)絡(luò)-企業(yè)和運營商的私有云網(wǎng)絡(luò)提供體系即架構(gòu)-IAAS服務(wù)和云服務(wù)提供商提供的虛擬私有云（VPCs）服務(wù)
• 在運營商網(wǎng)絡(luò)中的網(wǎng)絡(luò)功能虛擬化（NFV）–為運營商邊界網(wǎng)絡(luò)提供增值服務(wù)，如提供業(yè)務(wù)邊界網(wǎng)絡(luò)，寬帶用戶管理邊界網(wǎng)絡(luò)和移動邊界網(wǎng)絡(luò)

私有云，虛擬私有云（VPC）和基礎(chǔ)架構(gòu)即服務(wù)（IAAS）的使用場景里，都需要多租戶虛擬數(shù)據(jù)中心，在這些案例中，都 在一個數(shù)據(jù)中心中存在多個租戶，共享相同的物理資源（物理服務(wù)器，物理存儲和物理網(wǎng)絡(luò)），每個租戶被指定使用他們自己的邏輯資源（虛擬機(jī)，虛擬存儲，虛擬 網(wǎng)絡(luò)），這些租戶的邏輯資源之間相互隔離，除非基于某些安全策略使之可以相互訪問，數(shù)據(jù)中心中的虛擬網(wǎng)絡(luò)一樣可以通過物理的IP VPN或者L2 VPN進(jìn)行互聯(lián)網(wǎng)絡(luò)功能虛擬化（NFV）的使用場景中引入了協(xié)調(diào)器和網(wǎng)絡(luò)管理功能，例如防火墻，入侵檢測系統(tǒng)，深度包檢測，數(shù)據(jù)緩存，廣域網(wǎng)加速等等，這 些功能在虛擬機(jī)中實現(xiàn)，從而替代了以往的傳統(tǒng)物理設(shè)備，這些，都驅(qū)動了網(wǎng)絡(luò)層面的虛擬化，使其可以走向市場，優(yōu)化網(wǎng)絡(luò)成本

1.2 OpenContrail?控制器和虛擬路由器

OpenContrail系統(tǒng)由兩個主要部件組成：OpenContrail控制器和OpenContrail虛擬路由器

OpenContrail控制器是一個邏輯上集中但是物理上分布的SDN控制器，為虛擬網(wǎng)絡(luò)提供管理，控制和分析功能。

OpenContrail vRouter（虛擬路由器）是一個轉(zhuǎn)發(fā)平面（或者是分布部署的路由器），運行在虛擬服務(wù)器的hypervisor，將網(wǎng)絡(luò)從一個數(shù)據(jù)中心的網(wǎng)絡(luò)的物理路 由器和交換機(jī)擴(kuò)展成一個虛擬的基于虛擬服務(wù)器主機(jī)之間通訊的overlay網(wǎng)絡(luò)（關(guān)于overlay網(wǎng)絡(luò)的詳細(xì)介紹將會在1.4章節(jié) 中,OpenContrail虛擬路由器從概念上和現(xiàn)在的商用和開源vSwitch（如OVS）很像，但是他會提供路由以及更高層的服務(wù)（使用 vRouter替代vSwitch）

OpenContrail控制器提供了系統(tǒng)的邏輯集中控制平面和管理平面，并且協(xié)調(diào)管理vRouter

1.3?虛擬網(wǎng)絡(luò)

虛擬網(wǎng)絡(luò)是OpenContrail系統(tǒng)的重要部件，虛擬網(wǎng)絡(luò)是部署物理網(wǎng)絡(luò)頂層的邏輯架構(gòu)，虛擬網(wǎng)絡(luò)也用于替代基于 VLAN隔絕網(wǎng)絡(luò)的方案，為多租戶提供虛擬數(shù)據(jù)中心，每一個租戶或者應(yīng)用可以擁有一個或者多個虛擬網(wǎng)絡(luò)，每個虛擬網(wǎng)絡(luò)之間相互隔絕，除非使用安全策略允許 之間相互訪問

虛擬網(wǎng)絡(luò)通過在數(shù)據(jù)中心的邊界路由器上使用MPLS L3 VPN或者EVPN，作為物理網(wǎng)絡(luò)連接擴(kuò)展使用（譯者注，實際上是使用這些技術(shù)實現(xiàn)跨數(shù)據(jù)中心的虛擬化）

虛擬網(wǎng)絡(luò)同樣可以使用部署在NFV環(huán)境和服務(wù)鏈上，詳細(xì)內(nèi)容會在2.3中介紹

1.4? Overlay Networking

虛擬網(wǎng)絡(luò)也可以使用在兩個網(wǎng)絡(luò)中—物理underlay網(wǎng)絡(luò)或者虛擬overlay網(wǎng)絡(luò)。Overlay網(wǎng)絡(luò)技術(shù)已經(jīng)廣 泛應(yīng)用在無線局域網(wǎng)產(chǎn)業(yè)十年以上，但是現(xiàn)在數(shù)據(jù)中心網(wǎng)絡(luò)為之賦予了新意，并且被不同的組織標(biāo)準(zhǔn)化，例如IETF下屬的NVO3工作組，并且通過不同廠商的 開源或者商業(yè)網(wǎng)絡(luò)虛擬化產(chǎn)品進(jìn)行部署

物理底層網(wǎng)絡(luò)的作用，就是提供的一個“IP矩陣”，他的職責(zé)是提供所有物理設(shè)備之間的單播IP可達(dá)性（服務(wù)器，存儲設(shè)備，路由器或者交換機(jī)），一個理想化的底層網(wǎng)絡(luò)，可以提供網(wǎng)絡(luò)中任意一點之間的低延遲，無阻塞和高帶寬連接

虛擬路由器運行在虛擬服務(wù)器的hypervisor層，通過在物理底層網(wǎng)絡(luò)的上層創(chuàng)建虛擬overlay網(wǎng)絡(luò)，使用動態(tài) 的“通道”網(wǎng)，保證虛擬服務(wù)器之間的連通性，在OpenContrail overlay通道中，可以使用MPLS over GRE/UDP通道，或者VXLAN通道。

底層物理路由器和交換機(jī)不需要保存任何租戶的信息：他們不需要保存任何MAC地址，IP地址或者虛擬機(jī)之間的策略，在底 層物理交換機(jī)和路由器的轉(zhuǎn)發(fā)表中，只會包含物理server的IP前綴或者M(jìn)AC地址。網(wǎng)關(guān)路由器或者交換機(jī)是一個特例，因為他們需要保證虛擬網(wǎng)絡(luò)和物理 網(wǎng)絡(luò)的通訊，他們需要包含租戶的MAC或者IP地址信息

從另一個方面說，虛擬路由器會包含每一個租戶的信息，他們會包含每一個虛擬網(wǎng)絡(luò)的獨立轉(zhuǎn)發(fā)表（或者稱為一個路由實例）， 這些轉(zhuǎn)發(fā)表包含虛擬機(jī)的IP前綴（在L3 overlay網(wǎng)絡(luò)中）或者M(jìn)AC地址（在L2 overlay網(wǎng)絡(luò)中），并不是一個虛擬路由器需要保存整個數(shù)據(jù)中心所有虛擬機(jī)的所有IP前綴或者所有MAC地址信息，給定的虛擬路由器只需要保存本地服 務(wù)器存在的路由實例的信息上（舉例說明，至少每個服務(wù)器上存在一個虛擬機(jī)）譯者注：實際上就是每個虛擬路由器會負(fù)責(zé)一個每一個物理server上的虛擬機(jī) 內(nèi)部，或者之間的通訊，會保存路由表，轉(zhuǎn)發(fā)表等

1.5??基于MPLS L3VPNs?和?EVPNs的overlay架構(gòu)

廠商和標(biāo)準(zhǔn)化組織已經(jīng)提出了真對于overlay網(wǎng)絡(luò)的各自不同的控制平面和數(shù)據(jù)平面協(xié)議

例如，IETF VXLAN提出了一個新的數(shù)據(jù)平面封裝，并且提出了一個和標(biāo)準(zhǔn)以太網(wǎng)“泛洪和學(xué)習(xí)源地址”，進(jìn)而形成L2轉(zhuǎn)發(fā)表的行為類似的控制平面協(xié)議，需要在底層網(wǎng)絡(luò)部署一個或者多個組播組來實現(xiàn)泛洪

OpenContrail也受此類技術(shù)的影響，其解決方案在概念上類似于標(biāo)準(zhǔn)的MPLS L3VPNs (用于 L3 overlays)和 MPLS EVPNs (用于 L2 overlays)

在數(shù)據(jù)平面，OPENCONTRAIL支持MPLS over GRE，這種數(shù)據(jù)平面的封裝可以被目前的大部分主流廠商的現(xiàn)有路由器支持，OPENCONTRAIL同時支持其他數(shù)據(jù)平面封裝標(biāo)準(zhǔn)，例如MPLS over UDP (在多路徑和CPU優(yōu)化上更具優(yōu)勢) 和 VXLAN，其他的封裝標(biāo)準(zhǔn)例如NVGRE會非常容易添加在后續(xù)版本中

OPENCONTRAIL系統(tǒng)的控制平面或者物理網(wǎng)關(guān)路由器（或者交換機(jī)）之間的控制平面協(xié)議是BGP（以及使用Netconf用于管理），這也同MPLS L3VPN 和 MPLS EVPN使用的控制平面協(xié)議相同。

用于OPENCONTRAIL控制器和OPENCONTRAIL虛擬路由器之間的協(xié)議基于XMPP，XMPP信息的交互方式在IETF草案上已有描述，盡管語法不同，但是語意上和BGP非常相似

實際上，OPENCONTRAIL系統(tǒng)使用的控制和轉(zhuǎn)發(fā)平面協(xié)議與MPLS L3VPN和 EVPN協(xié)議非常類似，這樣做存在諸多好處：這些協(xié)議比較成熟，而且易于擴(kuò)展，被廣泛應(yīng)用在生產(chǎn)網(wǎng)絡(luò)，并被多個廠商產(chǎn)品支持，可以無縫互操作，而無需軟件 網(wǎng)關(guān)（譯者注：最后一句話實際上是重點，使用老技術(shù)來保證新部署模式不需要更新硬件設(shè)備）

1.6 Source—OPENCONTRAIL和開源

OPENCONTRAIL被設(shè)計可以運行在一個開源云網(wǎng)絡(luò)環(huán)境中，用于提供完整的集成端到端的解決方案

• OPENCONTRAIL系統(tǒng)可以和開源的hypervisor集成，例如KVM和XEN
• OPENCONTRAIL系統(tǒng)可以和開源的虛擬化協(xié)調(diào)協(xié)同集成，例如OpenStack和CloudStack
• OPENCONTRAIL系統(tǒng)可以和開源的服務(wù)器管理系統(tǒng)集成，例如chef, puppet, cobbler和 ganglia.

OPENCONTRAIL目前遵從Apache 2.0許可，這意味著任何人可以開發(fā)和修改OPENCONTRAIL系統(tǒng)代碼，不需要承擔(dān)公布或者釋放修改代碼的任何義務(wù)

Juniper網(wǎng)絡(luò)同時提供OPENCONTRAIL系統(tǒng)的商用版本，為Juniper網(wǎng)絡(luò)和其代理商提供整個開源棧（不僅是OPENCONTRAIL系統(tǒng)，還包括其他開源組件如OpenStack）的商業(yè)支持

OPENCONTRAIL系統(tǒng)的開源版本不是一個“戲弄者”（譯者注：不是隨便玩玩的版本），會提供和商用版本一樣的功能，以及擴(kuò)展性

1.7? Scale-Out Architecture and High Availability

前文我們提到，OPENCONTRAIL控制器是一個邏輯集中化的平臺

物理分布意味著OPENCONTRAIL控制器結(jié)合不同類型的節(jié)點，每一個都可以有多個實例，提供高可用性和層次化擴(kuò)展，這些節(jié)點實例可以是物理服務(wù)器或者虛擬機(jī)，最小部署環(huán)境下，這些節(jié)點可以合并在一個server上，整個系統(tǒng)一共三個類型的節(jié)點

• 配置節(jié)點主要負(fù)責(zé)管理層，控制節(jié)點提供北向REST應(yīng)用程序接口（API），可以用于配置系統(tǒng)，或者獲取系統(tǒng)的運行狀態(tài)信息，使用層次化數(shù)據(jù)庫組 件表現(xiàn)實例服務(wù)，實例化的服務(wù)是以一個可橫向擴(kuò)展的數(shù)據(jù)庫為對象，而這個數(shù)據(jù)庫通過一個正式的服務(wù)數(shù)據(jù)模型所描述（更多的數(shù)據(jù)模型在后面描述）。配置節(jié)點 同時也包含一個轉(zhuǎn)換引擎（有時可以理解為編譯器），將高層級服務(wù)數(shù)據(jù)模型的組件轉(zhuǎn)換成相應(yīng)的更多的低層級技術(shù)數(shù)據(jù)層面的組件。也就是說，高層級服務(wù)數(shù)據(jù)模 型描述什么服務(wù)需要被部署，而低層級技術(shù)數(shù)據(jù)模型描述什么服務(wù)通過什么技術(shù)怎樣被部署，配置節(jié)點使用IF-MAP發(fā)布低層級技術(shù)數(shù)據(jù)平面的內(nèi)容給控制平 面。
• 控制節(jié)點部署在控制平面的邏輯集中部分，不是所有的控制平面功能全部邏輯集中—一些控制平面的的功能依然會在網(wǎng)絡(luò)中的物理和虛擬路由器上以當(dāng)前流 星的分布式的方式部署（譯者注：也就是說控制平面的功能也會向以前的組網(wǎng)一樣，在每一個路由器或者交換機(jī)上），控制節(jié)點使用IF-MAP協(xié)議監(jiān)控底層技術(shù) 數(shù)據(jù)模型的內(nèi)容，并通過配置節(jié)點進(jìn)行計算描述網(wǎng)絡(luò)的需要狀態(tài)。控制節(jié)點使用南向協(xié)議的集成來達(dá)到“使其成真”的目的，例如把網(wǎng)絡(luò)的實際狀態(tài)等同于網(wǎng)絡(luò)實際 需要的狀態(tài)（譯者注：就是按需定義網(wǎng)絡(luò)），當(dāng)前的初代版本，OpenContrail系統(tǒng)的南向協(xié)議包括XMPP去控制OpenContrail虛擬路由 器，XMPP集成了BGP和Netconf協(xié)議去控制物理路由器，控制節(jié)點同時使用BGP去進(jìn)行其他節(jié)點控制節(jié)點多個實例的狀態(tài)同步，來達(dá)到擴(kuò)展和高可用 性的目的。
• 分析節(jié)點的職責(zé)是收集，核對和展示分析信息，用于排除網(wǎng)絡(luò)故障和了解網(wǎng)絡(luò)的使用情況，每個OpenContrail系統(tǒng)的組件會產(chǎn)生系統(tǒng)中每一個 顯著事件的詳細(xì)記錄，這些時間記錄會發(fā)送給分析節(jié)點一個或者多個實例（擴(kuò)展目的），在一個層次化可擴(kuò)展的數(shù)據(jù)庫中核對和儲存信息，提供更便于時間系列分析 和查詢的優(yōu)化數(shù)據(jù)格式。分析節(jié)點具有事件發(fā)生時自動觸發(fā)和收集詳細(xì)信息的機(jī)制，目標(biāo)是可以獲取任何問題的故障原因，而無需重現(xiàn)故障。分析節(jié)點提供被北向分 析查詢REST API。

OpenContrail控制器的物理分布式特性是一個特殊的功能，因為這可以使任何節(jié)點的多個冗余實例，運行在主-主 模式（另一種模式是主備模式），系統(tǒng)可以在任意節(jié)點故障時持續(xù)工作而不會有任何中斷，當(dāng)節(jié)點變得超載，節(jié)點的其他實例將會被實例化，負(fù)載可以自動重新分 布，這樣可以防止單一節(jié)點成為瓶頸，使得系統(tǒng)可以具備極大的擴(kuò)展性—支持?jǐn)?shù)以萬計的服務(wù)器

邏輯集中意味著OpenContrail系統(tǒng)的行為是一個單一的邏輯點，盡管實際上他會部署成為集群或者多個節(jié)點

1.8??數(shù)據(jù)模型核心規(guī)則：SDN即是編譯器

數(shù)據(jù)模型扮演著OpenContrail系統(tǒng)中的中心角色，一個數(shù)據(jù)模型包括設(shè)置的組件，性能，和數(shù)據(jù)模型之間的關(guān)系。

數(shù)據(jù)模型允許應(yīng)用可以快速宣告而不是經(jīng)由某種必要行為來實現(xiàn)，這是實現(xiàn)程序高效的關(guān)鍵所在，OpenContrail架 構(gòu)的基本目標(biāo)就是平臺上的數(shù)據(jù)操作，就如同平臺上維護(hù)的應(yīng)用一下，也就意味著應(yīng)用的處理是無狀態(tài)虛擬化的，更重要的結(jié)果是這個設(shè)計可以讓獨立的有那個用可 以從復(fù)雜的網(wǎng)絡(luò)操作解放出來，不需要擔(dān)心其高可用性，擴(kuò)展性和互聯(lián)性。（譯者注：個人理解是OpenContrail希望達(dá)到的目的是業(yè)務(wù)的快速部署，以 前部署業(yè)務(wù)，除了服務(wù)器上面配置之外，還需要在網(wǎng)絡(luò)層進(jìn)行進(jìn)一步的配置，而OpenContrail里面的數(shù)據(jù)模型可以讓應(yīng)用快速通告，而不擔(dān)心基礎(chǔ)架構(gòu) 網(wǎng)絡(luò)的調(diào)整）

有兩類數(shù)據(jù)模型：高層級數(shù)據(jù)模型和低層級數(shù)據(jù)模型，這兩個數(shù)據(jù)模型都使用格式化數(shù)據(jù)模型語言—目前使用的是IF-MAP的XML語法，YANG也會在未來的版本中被考慮作為模型化語言

高層級服務(wù)數(shù)據(jù)模型在抽象化的最高層描述網(wǎng)絡(luò)所需要的狀態(tài)，使用組件直接將服務(wù)對應(yīng)到終端用戶上，例如，虛擬網(wǎng)絡(luò)，連接策略或者安全策略等

低層級技術(shù)數(shù)據(jù)模型描述在抽象層中非常底層的網(wǎng)絡(luò)所需要的狀態(tài)，使用組件來對應(yīng)特定的網(wǎng)絡(luò)協(xié)議，例如BGP的路由標(biāo)記（RT）或者VXLAN的網(wǎng)絡(luò)標(biāo)識

配置節(jié)點的職責(zé)就是將高層級服務(wù)數(shù)據(jù)模型的修改轉(zhuǎn)換成低層級技術(shù)數(shù)據(jù)模型的修改，這在概念上和即時編譯（JIT）類似，借此“SDN即為編譯器”在有時用于描述OpenContrail系統(tǒng)的體系結(jié)構(gòu)

控制節(jié)點的職責(zé)是識別網(wǎng)絡(luò)需要的狀態(tài)，這種狀態(tài)被使用北向協(xié)議如XMPP，BGP和Netconf這些北向協(xié)議的集合形成的低層級技術(shù)數(shù)據(jù)模型所描述。

譯者注：這段比較晦澀難懂，但是整體看來并不復(fù)雜，重點在于，我們要從數(shù)據(jù)中心應(yīng)用的角度去理解，簡單來說，數(shù)據(jù)中心內(nèi) 部服務(wù)器上需要跑各種類型的服務(wù)，這些服務(wù)之間的通訊靠數(shù)據(jù)中心內(nèi)部的交換機(jī)以及路由器實現(xiàn)，在以前的部署環(huán)境中，當(dāng)我們開啟一個業(yè)務(wù)，或者說在數(shù)據(jù)中心 中建立一個業(yè)務(wù)分區(qū)，那么我們需要做的是，在物理機(jī)或者VM上安裝服務(wù)，然后，根據(jù)服務(wù)的要求，建立和其他分區(qū)的流量轉(zhuǎn)發(fā)策略以及安全策略，這需要在不同 的設(shè)備上去進(jìn)行配置來實現(xiàn)一個業(yè)務(wù)的開局，那么在“SDN”的環(huán)境中，我們現(xiàn)在把數(shù)據(jù)中心想象成一個整體來考慮，其中，交換機(jī)等基礎(chǔ)架構(gòu)的工作是只需要提 供一個物理接口，接下來要做的就是有一個集成化的工具，也就是OpenContrail系統(tǒng)，從創(chuàng)建虛擬機(jī)開始，一路next，直接把服務(wù)開啟，網(wǎng)絡(luò)也瞬 間進(jìn)行調(diào)整，這樣實現(xiàn)“SDN”的目的，在這個思路下，上面的高層級和低層級，控制和配置模型的介紹，實際上就是事先這個思想的技術(shù)而已。

1.9??北向API接口

OpenContrail控制器中配置節(jié)點為預(yù)留或協(xié)調(diào)系統(tǒng)提供北向REST API接口，北向REST PAI會由格式化的高級數(shù)據(jù)模型創(chuàng)建。這保證北向REST API是“第一批市民”，意味著任何服務(wù)可以通過REST API進(jìn)行預(yù)留

REST API采用安全通訊方式：使用HTTPS用于驗證和加密，并且提供基于策略的授權(quán)，同時具有層次化的擴(kuò)展，因為API可以被多個配置節(jié)點實例讀取

1.10?圖形化用戶接口

OpenContrail系統(tǒng)也提供圖形化接口，GUI在使用REST API 描述前構(gòu)建完成，保證不會在API內(nèi)產(chǎn)生延遲，同時，我們預(yù)期大規(guī)模部署或者運營商OSS/BSS系統(tǒng)可以使用REST API集成于此

附注：我們正在進(jìn)行UI 代碼級別的修改，以便未來允許我們可以使其開源

1.11???可擴(kuò)展平臺

OpenContrail系統(tǒng)的初代版本使用特定的高層級服務(wù)數(shù)據(jù)模型，特定的低層級技術(shù)數(shù)據(jù)模型，以及轉(zhuǎn)換引擎進(jìn)行前者后者的映射，此外，OpenContrail系統(tǒng)的初代版本也是用特定的南向協(xié)議集合

高級服務(wù)數(shù)據(jù)模型在OpenContrail系統(tǒng)的初代版本中的模型化服務(wù)結(jié)構(gòu)包括：租戶，虛擬網(wǎng)絡(luò)，連接策略和安全策略，選擇這些模型組件支持的基本業(yè)務(wù)環(huán)境主要是云計算網(wǎng)絡(luò)和NFV（適用環(huán)境：云計算網(wǎng)絡(luò)，多租戶網(wǎng)絡(luò)）

低層級服務(wù)數(shù)據(jù)模型在OpenContrail系統(tǒng)的初代版本中主要面向的服務(wù)部署模型是使用overlay networking（網(wǎng)絡(luò)構(gòu)建模型：overlay）

配置節(jié)點的轉(zhuǎn)換引擎包括“編譯器”去實現(xiàn)高層級服務(wù)數(shù)據(jù)模型到低層級數(shù)據(jù)模型的轉(zhuǎn)換映射

初始版本控制節(jié)點使用的南向協(xié)議包括XMPP，BGP，Netconf

OpenContrail系統(tǒng)是一個擴(kuò)展平臺，意味著，在未來的版本中，我們可以通過組件擴(kuò)展的方式去支持更多的用戶部署環(huán)境和網(wǎng)絡(luò)技術(shù)

• 高級服務(wù)數(shù)據(jù)模型可以擴(kuò)展新的組件去支持新的服務(wù)，例如：運營商核心網(wǎng)絡(luò)的流量工程和流量日歷（根據(jù)日期進(jìn)行流量管理）
• 低層級服務(wù)數(shù)據(jù)模型也可以基于其中一個原因進(jìn)行擴(kuò)展，相同的高級服務(wù)使用不同的技術(shù)去進(jìn)行部署，例如，多租戶可以使用VLAN去替代 overlay，新的高層級服務(wù)的引入會需要新的低層級技術(shù)，例如引入流量工程或者流量日歷作為高級服務(wù)就需要引入新的低層級組件例如TE-LSP

譯者注：這章定義了OpenContrail系統(tǒng)的使用環(huán)境：用于云計算或者多租戶的數(shù)據(jù)中心，采用overlay的網(wǎng)絡(luò)模型，當(dāng)然，作為一個可以擴(kuò)展的系統(tǒng)，在未來版本中，可以根據(jù)業(yè)務(wù)的需要增加新的服務(wù)，但是有了新的服務(wù)，也就需要新的技術(shù)。

• 轉(zhuǎn)換引擎可以為映射現(xiàn)在的高級服務(wù)組件到新的低層級技術(shù)組件（實現(xiàn)當(dāng)前業(yè)務(wù)的新的方式或者新的網(wǎng)絡(luò)技術(shù)），或者映射新的服務(wù)組建到新的或者現(xiàn)有的低層級技術(shù)組件（例如部署新服務(wù)）進(jìn)行擴(kuò)展。

新的南向協(xié)議可以引入到控制節(jié)點中，這主要用于支持網(wǎng)絡(luò)中使用不同協(xié)議的新類型的物理或者虛擬設(shè)備。例如特定廠商的網(wǎng)絡(luò)設(shè)備使用的CLI命令行接口可以被引入，或者可能因為需要部署新的協(xié)議，新的組件需要引入到低層級技術(shù)數(shù)據(jù)層面中。

2? OpenContrail系統(tǒng)結(jié)構(gòu)細(xì)節(jié)

如圖1所示，OpenContrail系統(tǒng)包含兩個部分：一個邏輯集中但是物理分布的控制器和一個vRouter(虛擬路由器)的集合，使用軟件轉(zhuǎn)發(fā)模式部署在通用虛擬服務(wù)器的hypervisor層

控制器提供北向REST API接口供應(yīng)用使用，這些API用于和云協(xié)調(diào)系統(tǒng)集成，如通過neutron（以前叫做quantum）和Openstack集成，REST API也可以被其他應(yīng)用以及或運營商的OSS/BSS系統(tǒng)使用，最終，REST API被部署在OpenContrail系統(tǒng)內(nèi)基于網(wǎng)頁的GUI集成

OpenContrail系統(tǒng)提供三個接口：北向接口集合用于與協(xié)調(diào)系統(tǒng)和應(yīng)用通訊，南向接口用于與虛擬網(wǎng)絡(luò)環(huán)境（虛擬 路由器）或者物理網(wǎng)絡(luò)環(huán)境(網(wǎng)關(guān)路由器和交換機(jī))通訊，東西向接口用于和其他控制器對等通訊，Openstack和CloudStack支持協(xié)調(diào)器，標(biāo)準(zhǔn) BGP用于東西向接口，XMPP用于虛擬路由器的北向接口，BGP和Netconf和南向接口用于網(wǎng)關(guān)路由器和交換機(jī)。

在內(nèi)部，控制器包括三個主要組件

• 配置節(jié)點的職責(zé)是通過網(wǎng)絡(luò)環(huán)境的協(xié)作，為高層級數(shù)據(jù)模型到低層級數(shù)據(jù)模型提供轉(zhuǎn)換。（譯者注：把上層的應(yīng)用使用底層技術(shù)進(jìn)行實現(xiàn)）
• 控制節(jié)點的職責(zé)是在網(wǎng)絡(luò)環(huán)境和對等系統(tǒng)之間進(jìn)行低層級狀態(tài)信息的轉(zhuǎn)播，保證整個環(huán)境的信息一致。（譯者注：進(jìn)行信息同步，例如BGP信息，路由信息等）
• 分析節(jié)點的職責(zé)是記錄網(wǎng)絡(luò)環(huán)境的實時狀態(tài)，抽象化數(shù)據(jù)，并且適宜表現(xiàn)出來供應(yīng)用進(jìn)行使用（分析數(shù)據(jù)，呈現(xiàn)數(shù)據(jù)）

所有的節(jié)點都會在本章的后面詳細(xì)描述

虛擬路由器將通過軟件方式部署在網(wǎng)絡(luò)環(huán)境中，他們的責(zé)任通過服務(wù)器到服務(wù)器之間的通道進(jìn)行一個虛擬機(jī)到另一個虛擬機(jī)之間 的數(shù)據(jù)包轉(zhuǎn)發(fā)。這些overlay網(wǎng)絡(luò)的通道位于物理IP-over-Ethernet網(wǎng)絡(luò)的上層。每個虛擬路由器包含兩個部分：一個用戶空間代理部署控 制平面，一個內(nèi)核模塊部署轉(zhuǎn)發(fā)平面。

OpenContrail系統(tǒng)部署三個基本區(qū)塊

1.多租戶，也被理解為網(wǎng)絡(luò)虛擬化或者網(wǎng)絡(luò)分片，用于創(chuàng)建虛擬網(wǎng)絡(luò)，提供CUG（封閉用戶組）設(shè)置虛擬機(jī)

2.網(wǎng)關(guān)功能：通過網(wǎng)關(guān)路由器連接虛擬網(wǎng)絡(luò)到物理網(wǎng)絡(luò)（或者互聯(lián)網(wǎng)），連接非虛擬化的服務(wù)器，或者通過網(wǎng)關(guān)連接虛擬網(wǎng)絡(luò)的網(wǎng)絡(luò)服務(wù)。

3.服務(wù)鏈：也被理解為NFV，通過物理或者虛擬網(wǎng)絡(luò)服務(wù)（例如防火墻，深入包檢測，負(fù)載均衡）形成一個有序的流量服務(wù)流

2.1.1?節(jié)點

我們轉(zhuǎn)到系統(tǒng)的內(nèi)部服務(wù)架構(gòu)上，如圖2所示，系統(tǒng)通過通用x86服務(wù)器運行的相互協(xié)作的節(jié)點集合進(jìn)行部署，每個節(jié)點可以部署在獨立的服務(wù)器上或者部署在一個虛擬機(jī)上

所有給定類型的節(jié)點使用A-A配置運行來保證單點不會形成瓶頸，這種擴(kuò)展化的設(shè)計提供冗余和層次化的靈活性。

• 配置節(jié)點保留一個預(yù)計配置狀態(tài)的持續(xù)備份，并且為適應(yīng)網(wǎng)絡(luò)環(huán)境的互操作從高層級數(shù)據(jù)模型到低層級數(shù)據(jù)模型的轉(zhuǎn)換，這些都保存在一個NoSQL的數(shù)據(jù)庫中
• 控制節(jié)點部署一個邏輯集中的控制平面，旨在維護(hù)一個短暫的網(wǎng)絡(luò)狀態(tài)，控制節(jié)點之間以及和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)設(shè)備之間互操作，在保證網(wǎng)絡(luò)狀態(tài)的持續(xù)一致。
• 分析節(jié)點搜集，存儲，關(guān)聯(lián)和分析虛擬和物理網(wǎng)絡(luò)環(huán)境中的信息，這些信息包括統(tǒng)計，日志，事件和錯誤。

另外一些節(jié)點類型也作為OpenContrail控制器的一部分，我們同時也在物理服務(wù)器和物理網(wǎng)絡(luò)環(huán)境中定義了一些另外的節(jié)點類型，來在整個OpenContrail系統(tǒng)中執(zhí)行一些特定的規(guī)則

• 計算節(jié)點是運行虛擬機(jī)的通用物理服務(wù)器，這些虛擬機(jī)可能是租戶運行通用應(yīng)用，或者這些虛擬機(jī)可以運行虛擬網(wǎng)絡(luò)服務(wù)，例如虛擬負(fù)載均衡或者虛擬防火墻，每一個計算節(jié)點都包含一個虛擬路由器，部署轉(zhuǎn)發(fā)平面和分布式控制平面（計算節(jié)點實際上就是物理服務(wù)器）
• 網(wǎng)關(guān)節(jié)點是一個物理網(wǎng)關(guān)路由器或者交換機(jī)，連接租戶虛擬網(wǎng)絡(luò)到物理網(wǎng)絡(luò)（互聯(lián)網(wǎng)，客戶VPN，另一個數(shù)據(jù)中心或者非虛擬化的服務(wù)器）中來
• 服務(wù)節(jié)點物理網(wǎng)絡(luò)環(huán)境提供諸如深度包檢測（DPI），入侵檢測（IDP），入侵防護(hù)（IPS），廣域網(wǎng)優(yōu)化和負(fù)載均衡，服務(wù)鏈可以包含這些虛擬服務(wù)的匯集（例如在計算節(jié)點中的虛擬機(jī)）和物理服務(wù)器（在服務(wù)節(jié)點中）

為便于理解，圖中沒有展示在下層IP over Ethernet 網(wǎng)絡(luò)中的物理路由器和交換機(jī)。同事，在每個節(jié)點中和分析節(jié)點中存在一個接口，為避免混亂，這個接口在圖2中也沒有展示。

2.1.2?計算節(jié)點

計算節(jié)點是一個通用的x86架構(gòu)服務(wù)器，作為VMs的承載。這些虛擬機(jī)可以是租戶的虛擬機(jī)，運行客戶的應(yīng)用，例如網(wǎng)頁服 務(wù)器，數(shù)據(jù)庫服務(wù)器，或者企業(yè)應(yīng)用，或者這些虛擬機(jī)可以運行虛擬服務(wù)，用于創(chuàng)建服務(wù)鏈，標(biāo)準(zhǔn)的配置是使用KVM或者Xen作為hypervisor，上層 運行Linux，虛擬路由器的轉(zhuǎn)發(fā)平面在Linux 的Kernel中，虛擬路由器的代理作為邏輯控制平面，其整體接口如圖3所示

其他支持的OS或者h(yuǎn)ypervisor例如VMware ESXi或者Windows Hyper-V可能會在未來支持。

計算節(jié)點部署的虛擬路由器包括兩個區(qū)塊：虛擬路由器代理和虛擬路由器轉(zhuǎn)發(fā)平面，這些將會在后續(xù)描述。

2.1.2.1虛擬路由器代理（虛擬路由器）

虛擬路由器是一個用戶空間進(jìn)程，在Linux中運行，是一個本地的，輕量控制平面，主要提供如下功能

• 使用XMPP實現(xiàn)和控制節(jié)點的例如路由的控制狀態(tài)交換
• 使用XMPP從控制節(jié)點上接收低層級配置狀態(tài)，例如路由進(jìn)程和轉(zhuǎn)發(fā)策略
• 向分析節(jié)點匯報例如日志，匯總和事件的分析狀態(tài)
• 向轉(zhuǎn)發(fā)平面安裝轉(zhuǎn)發(fā)狀態(tài)（下發(fā)轉(zhuǎn)發(fā)表）
• 查找VM的存在和屬性，和Nova代理進(jìn)行交互
• 為每個新流的首包應(yīng)用轉(zhuǎn)發(fā)策略，在轉(zhuǎn)發(fā)平面的流表安裝流表項
• 為DHCP，ARP和MDNS提供代理，其他代理會在未來版本中添加

每個虛擬路由器都會連接至少兩個控制節(jié)點，在A-A冗余模型中提供冗余

2.1.2.2?虛擬路由器轉(zhuǎn)發(fā)平面

虛擬路由器轉(zhuǎn)發(fā)平面運行在Linux的kernel中，主要負(fù)責(zé)如下功能

• 封裝數(shù)據(jù)包到overlay網(wǎng)絡(luò)中，從overlay網(wǎng)絡(luò)中解封裝數(shù)據(jù)包
• 分配數(shù)據(jù)包到路由實例中
  • 從overlay網(wǎng)絡(luò)中接受數(shù)據(jù)包，并基于MPLS標(biāo)簽或者虛擬網(wǎng)絡(luò)標(biāo)識（VNI）分配到路由實例中
  • 為虛擬機(jī)提供虛擬接口，并綁定在路由實例中。
  • 在轉(zhuǎn)發(fā)信息表中進(jìn)行對于目的地址的查表，并轉(zhuǎn)發(fā)數(shù)據(jù)包到正確目的，路由可以基于三層IP前綴或者二層MAC地址。
  • 可選項—在轉(zhuǎn)發(fā)表中應(yīng)用轉(zhuǎn)發(fā)策略。
    • 匹配流表中的數(shù)據(jù)包，并應(yīng)用流表操作
    • 可選項—當(dāng)安裝轉(zhuǎn)發(fā)規(guī)則在流表虛擬路由器轉(zhuǎn)發(fā)數(shù)據(jù)時，沒有找到流規(guī)則時掛起數(shù)據(jù)包（譯者注：這段不好翻譯，用防火墻的方式就好理解了，防火墻利用 流表轉(zhuǎn)發(fā)數(shù)據(jù)，但是流表是根據(jù)rule規(guī)則來執(zhí)行，通過首包創(chuàng)建流表，進(jìn)而，當(dāng)收到首包時，還沒有出現(xiàn)流表，就會根據(jù)規(guī)則創(chuàng)建流表，這時這個數(shù)據(jù)包是會被 暫時緩存）
    • 在虛擬路由器中掛起諸如DHCP，ARP，MDNS等數(shù)據(jù)包用于代理

圖四介紹了虛擬路由器轉(zhuǎn)發(fā)平面的內(nèi)部結(jié)構(gòu)

轉(zhuǎn)發(fā)平面在overlay網(wǎng)絡(luò)中支持MPLS over GRE/UDP和VXLAN封裝，轉(zhuǎn)發(fā)平面支持三層轉(zhuǎn)發(fā)，對目的地址進(jìn)行最長掩碼匹配（LPM），也支持進(jìn)行二層轉(zhuǎn)發(fā)，基于MAC地址。當(dāng)前虛擬路由器的轉(zhuǎn)發(fā)平面支持IPv4，未來會支持IPv6

2.2會介紹更多細(xì)節(jié)

2.1.3?控制節(jié)點

圖5介紹控制節(jié)點的內(nèi)部結(jié)構(gòu)

控制節(jié)點和多個類型的節(jié)點進(jìn)行通訊

• 控制節(jié)點使用IF-MAP從配置節(jié)點接受配置狀態(tài)
• 控制節(jié)點使用IBGP和其他控制節(jié)點交換路由，保證所有的控制節(jié)點保存相同的網(wǎng)絡(luò)狀態(tài)。
• 控制節(jié)點使用XMPP和在計算節(jié)點上的虛擬路由器交換路由，他們同樣也使用XMPP發(fā)送配置狀態(tài)，例如路由實例和轉(zhuǎn)發(fā)策略
• 控制節(jié)點同時代理計算節(jié)點方面的某些流量，這些代理請求同樣使用XMPP接收
• 控制節(jié)點使用BGP和網(wǎng)關(guān)節(jié)點（路由器和交換機(jī)）交換路由，他們使用Netconf發(fā)送配置狀態(tài)

2.1.4?配置節(jié)點

圖6展示配置節(jié)點的內(nèi)部結(jié)構(gòu)。配置節(jié)點通過REST接口和協(xié)調(diào)系統(tǒng)通訊，和其他配置節(jié)點通過分布式同步機(jī)制通訊，使用IP-MAP和配置節(jié)點通訊。

配置節(jié)點同時提供查詢服務(wù)，客戶可以用于定位本地提供服務(wù)（例如其他節(jié)點提供特定服務(wù)），例如，當(dāng)計算節(jié)點的虛擬路由器 想要連接一個控制節(jié)點（更準(zhǔn)確說，一對A-A控制虛擬機(jī)的另外一個），用于服務(wù)查詢控制額節(jié)點的IP地址，客戶使用本地配置，DHCP或者DNS定位服務(wù) 查詢服務(wù)器。

配置節(jié)點包含如下組件

一個REST API服務(wù)器提供北向接口到協(xié)調(diào)系統(tǒng)或者其他應(yīng)用，這個接口用于使用高層級數(shù)據(jù)模型安裝配置狀態(tài)

一個Redis信息總線，用于內(nèi)部組件中的通訊。

一個Cassandra數(shù)據(jù)庫用于持續(xù)存儲配置，Cassandra是一個可容錯并且層次化擴(kuò)展的數(shù)據(jù)庫。

一個Schema轉(zhuǎn)換器，學(xué)習(xí)通過Redis信息學(xué)習(xí)高層級數(shù)據(jù)平面的修改，并且轉(zhuǎn)換（編譯）這些高層級數(shù)據(jù)模型的改變到低層級數(shù)據(jù)層面

• 一個IF-MAP服務(wù)器提供南向接口，推送計算過的低層級配置到控制節(jié)點

Zookeeper（圖中沒有現(xiàn)實），用于分配獨立的組件標(biāo)識，并且部署

2.1.5?分析節(jié)點

圖7介紹分析節(jié)點的內(nèi)部結(jié)構(gòu)，分析節(jié)點使用北向REST API和應(yīng)用進(jìn)行通訊。使用分布式同步機(jī)制和其他分析節(jié)點同步，使用基于XML的協(xié)議與控制節(jié)點和配置節(jié)點的組件通訊（基于XML的協(xié)議叫做Sandesh，設(shè)計用來處理數(shù)據(jù)的高值）

分析節(jié)點包含如下組件

• 一個收集器，與控制節(jié)點和配置節(jié)點交換Sandesh信息，收集分析信息
• 一個NoSQL數(shù)據(jù)庫存儲這些信息
• 一個規(guī)則引擎，當(dāng)特定事件發(fā)生時自動收集運行狀態(tài)
• 一個REST API服務(wù)器，提供北向接口，用于查詢分析數(shù)據(jù)庫和檢索操作狀態(tài)
• 一個查詢引擎，通過北向RESTAPI執(zhí)行查詢接收，這個引擎為潛在的大型分析數(shù)據(jù)中提供靈活訪問的能力

Sandesh 攜帶兩類信息：異步信息從分析節(jié)點中接受，目的是匯報日志，事件和監(jiān)控，同步信息用于分析節(jié)點向特定的操作狀態(tài)發(fā)送請求和接受響應(yīng)，

所有的信息通過收集器收集并持續(xù)的保存在NoSQL數(shù)據(jù)庫中，信息源不會做任何過濾。

分析節(jié)點提供北向REST API接口允許客戶應(yīng)用提交查詢。

分析節(jié)點提供分散收集邏輯，叫做“聚合”，一個單一的GET請求（一個客戶應(yīng)用對應(yīng)的CLI命令）可以映射到多個請求信息，并且形成組合的結(jié)果。

查詢引擎是一個簡單的Map-reduce引擎，OpenContrail最主要的查詢是時間系列。

2.2? OpenContrail系統(tǒng)轉(zhuǎn)發(fā)平面

轉(zhuǎn)發(fā)平面部署在一個overlay的網(wǎng)絡(luò)中。Overlay可以是三層IP的overlay網(wǎng)絡(luò)或者二層（以 太）overlay網(wǎng)絡(luò)。對于三層overlay，目前只支持IPv4，IPv6會在后續(xù)版本中增加，三層overlay網(wǎng)絡(luò)支持單播和組播，代理可以避 免DHCP，ARP以及其他協(xié)議的泛洪

2.2.1?包封裝

系統(tǒng)支持多種overlay封裝格式，每個封裝會在后續(xù)介紹

2.2.1.1? MPLS over GRE

圖8介紹了針對L3的overlay的MPLS over GRE包格式

圖9介紹了針對L2的overlay的MPLS over GRE包格式

MPLS L3VPN和EVPN都是使用MPLS over MPLS的封裝格式，但是也可以在核心網(wǎng)絡(luò)沒有使用MPLS的情況下使用MPLS over GRE。OpenContrail系統(tǒng)使用MPLS over GRE而不使用MPLS over MPLS有諸多原因：第一，數(shù)據(jù)中心的底層交換機(jī)經(jīng)常不支持MPLS，第二，即便支持，運維人員也不希望數(shù)據(jù)中心因使用MPLS兒變得復(fù)雜化，第三，因為 在數(shù)據(jù)中心中帶寬都足夠預(yù)期，不需要使用流量工程

2.2.1.2? VXLAN

對于L2的overlay，OpenContrail系統(tǒng)同樣支持VXLAN封裝，如圖10所示

使用VXLAN封裝的諸多好處之一是可以通過在外層頭部的UDP源端口注入entropy（詞庫翻譯成墑-內(nèi)層包頭的哈希）的特點支持底層的多路徑

OpenContrail部署VXLAN和VLAN IETF草案標(biāo)準(zhǔn)有兩個顯著的不同，第一，僅僅遵從IETF 草案的的數(shù)據(jù)包封裝格式，沒有使用其泛洪和學(xué)習(xí)的控制平面內(nèi)容，取而代之的是使用基于XMPP協(xié)議的控制平面實現(xiàn)（在本章中有描述），第二，出口虛擬路由 器的VXLAN包頭的虛擬網(wǎng)絡(luò)標(biāo)識為本地唯一，替代了全局唯一。

2.2.1.3?????? MPLS over UDP

OpenContrail支持第三種封裝—MPLS over UDP，這綜合MPLS over GRE和VXLAN封裝，支持二層或者三層的overlan，是用一個“內(nèi)層”MPLS包頭作為本地MPLS標(biāo)簽標(biāo)識，用于識別目的路由實例（類似于 MPLS over GRE），但是是用一個外層UDP包頭，便于底層網(wǎng)絡(luò)的多路徑傳輸（類似VXLAN）

圖11 顯示了MPLS over UDP封裝支持三層overlay

圖12 顯示了MPLS over UDP封裝支持二層overlay

2.2.2? Layer 3 Unicast???三層單播

下面介紹VM 1a到VM 2a發(fā)送一個IP 數(shù)據(jù)包的逐一流程，詳細(xì)內(nèi)容可以參考?[draft-ietf-l3vpn-end-system].，這個流程描述的是IPv4，而IPv6在步驟上類似。

1.VM 1a上的應(yīng)用發(fā)送一個數(shù)據(jù)包，目的地址是VM 2a

2.VM 1a有一個缺省路由指向路由實例 1a的169.254.x.x 本地地址

3.VM 1a為這個本地地址發(fā)送一個ARP請求，在路由實例 1a上的ARP 代理進(jìn)行響應(yīng)

4.VM 1a發(fā)送IP數(shù)據(jù)包到路由實例 1a

5.在路由實例1a上的IP FIB（IP轉(zhuǎn)發(fā)信息表）會包含相同虛擬網(wǎng)絡(luò)中其他所有VM的32位路由，包括VM 2a。這些路由是控制節(jié)點通過XMPP安裝。對于下一條路由會具有以下操作

a.壓入一個MPLS 標(biāo)簽，該標(biāo)簽為虛擬路由器2 為路由實例2a分配。

b.壓入一個GRE標(biāo)簽，目的地址為計算節(jié)點2

6.虛擬路由器1 通過全局 IP FIB1 查找封裝包新的目的IP（計算節(jié)點2的IP）

7.虛擬路由器1發(fā)送封裝后的數(shù)據(jù)包到計算節(jié)點2，下一步如何發(fā)生，將根據(jù)底層網(wǎng)絡(luò)是使用二層交換網(wǎng)絡(luò)還是三層IP網(wǎng)絡(luò)，這部分描述會在后面介紹，現(xiàn)在我們先忽略這個步驟，設(shè)定封裝過的數(shù)據(jù)包已經(jīng)傳送到了計算節(jié)點2

8.計算節(jié)點 2 接收封裝后的數(shù)據(jù)包，并開始在全局 IP FIB 2上進(jìn)行IP查找，當(dāng)外層目的IP就是本地地址時，會進(jìn)行解封裝，移除GRE頭，顯示出MPLS頭

9.計算節(jié)點 2 在全局 MPLS FIB 2中執(zhí)行MPLS標(biāo)簽的查找，查找到表項定位在路由實例 2a上，解封裝包頭，移除MPLS標(biāo)簽，并把解封裝后的數(shù)據(jù)包發(fā)送進(jìn)入路由實例 2s

10.計算節(jié)點2a 在IP FIB 2a中進(jìn)行解封裝后的內(nèi)層IP地址的查找，定位路由指向連接VM2a的虛擬端口

11.計算節(jié)點 2 發(fā)送數(shù)據(jù)包到VM 2a

現(xiàn)在我們回到剛才步驟7略過的部分，如果把封裝后的數(shù)據(jù)包通過底層網(wǎng)絡(luò)轉(zhuǎn)發(fā)。

如果底層網(wǎng)絡(luò)是二層網(wǎng)絡(luò)，那么：

1.封裝數(shù)據(jù)包的外層源IP地址（計算節(jié)點1）和目的IP地址（計算節(jié)點2）在同一個子網(wǎng)

2.計算節(jié)點1 發(fā)送對于計算節(jié)點2的ARP請求，計算節(jié)點2發(fā)出ARP響應(yīng)，包含計算節(jié)點2的MAC地址，注意，在底層網(wǎng)絡(luò)中沒有ARP代理封裝的數(shù)據(jù)包

3. 通過二層交換基于目的MAC地址從計算節(jié)點1發(fā)送到計算節(jié)點2

如果底層網(wǎng)絡(luò)是3層網(wǎng)絡(luò)，那么：

1.封裝數(shù)據(jù)包的外層源IP地址（計算節(jié)點1）和目的IP地址（計算節(jié)點2）在不同子網(wǎng)

2.所有包括物理路由器（S1和S2）和虛擬路由器（虛擬路由1和虛擬路由器2）底層網(wǎng)絡(luò)的路由都在運行某一個路由協(xié)議（如OSPF）中

3.封裝后的數(shù)據(jù)包通過三層路由基于目的IP地址從計算節(jié)點1到計算節(jié)點2，等開銷多路徑（ECMP）允許多個平行路徑可以被使用，基于這個原因，在UDP包源端口內(nèi)VXLAN封裝的entropy也可以被使用。

2.2.3二層單播

二層overlay網(wǎng)絡(luò)的轉(zhuǎn)發(fā)和前面提到的三層overlay網(wǎng)絡(luò)的轉(zhuǎn)發(fā)相同，區(qū)別在于

• 路由實例里面的轉(zhuǎn)發(fā)表包含MAC地址，而不是IP前綴
• ARP并不用于overlay中（但是用在底層網(wǎng)絡(luò)）

2.2.4??? Fallback Switching

OpenContrail支持混合模式—在虛擬網(wǎng)絡(luò)中混雜二層和三層的overlay。虛擬路由器中的路由實例同時包含 IP FIB和MAC FIB。對于每一個數(shù)據(jù)包，虛擬路由器先查找IP FIB，如果IP FIB中匹配路由，那么將轉(zhuǎn)發(fā)數(shù)據(jù)包，如果IP FIB中不匹配路由，那么將查找MAC FIB-這就是fallback switching

注意fallback switch“先路由后交換”的行為于IRB（集成路由交換）“先交換后路有的行為”完全相反。

2.2.5?三層組播

OpenContrail支持三層overlay的IP組播，組播操作將通過overlay的組播樹和底層網(wǎng)絡(luò)的組播樹來實現(xiàn)，任何一種方式，組播樹都可以是共享樹（*.G）或者詳細(xì)源樹（S,G）

2.2.5.1? overlay?組播樹

OpenContrail支持組播部署使用overlay中的組播樹取代底層網(wǎng)絡(luò)的組播樹，詳細(xì)描述可在[draft-marques-l3vpn-mcast-edge]中，這里我們只匯總一些基本概念

圖15描述了在overlay中創(chuàng)建組播樹的基本概念。作為組播樹的root的虛擬路由器發(fā)送N個復(fù)制流量到N個下行虛擬路由器，下行路由器在發(fā)送N個復(fù)制流量給更多的虛擬路由器，進(jìn)而，知道所有的接受路由器全部覆蓋，這個案例中N等于2，數(shù)字N并不等于每一個虛擬路由器

系統(tǒng)使用XMPP信令在每個虛擬網(wǎng)絡(luò)中的虛擬路由器建立FIB，創(chuàng)建overlay的組播樹，協(xié)議比較復(fù)雜，詳細(xì)描述請參考[draft-marques-l3vpn-mcast-edge]

入口復(fù)制，如圖16所示，通常是用于常規(guī)的overlay組播樹的一些陳舊案例中，從實踐上來說，入口復(fù)制的信令要比常見overlay組播樹要更簡單一些

2.2.5.2?底層組播復(fù)制樹

組播實現(xiàn)的另外一個替代方案是在底層使用組播樹，如圖17所示

這個和通常在MPLS VPN中部署組播比較接近（參見 RFC6513），同樣，VXLAN中泛洪并轉(zhuǎn)發(fā)控制平面（描述在?[draft-mahalingam-dutt-dcops-vxlan]?），也依賴于底層的組播樹

底層組播樹是使用組播地址建立GRE通道，這就暗示著底層網(wǎng)絡(luò)必須要支持IP組播，必須運行一個組播路由協(xié)議例如PIM協(xié)議，并且必須為每個組播樹提供一個組播租

2.2.5.3??對比

對于底層網(wǎng)絡(luò)的交換機(jī)使用組播樹，支持IP組播，在實踐上會出現(xiàn)一些問題，主要包括

• 盡管底層網(wǎng)絡(luò)支持組播，運維人員不希望開啟組播帶來管理和排錯的復(fù)雜性
• 基于商用芯片的交換機(jī)，往往在轉(zhuǎn)發(fā)平面支持比較相對有限的組播租，對于組播的最優(yōu)部署，需要底層網(wǎng)絡(luò)為overlay網(wǎng)絡(luò)每一個租戶的每一個組提 供組播地址，這就需要大量的組播租。當(dāng)然，使用為每個虛擬網(wǎng)絡(luò)單一共享樹可以減少底層網(wǎng)絡(luò)的組播租，但是這又帶來可優(yōu)化的開銷，并增加的復(fù)雜性，
• 在底層運行組播，數(shù)據(jù)中心交換機(jī)在控制平面上維護(hù)每一個組接受者的狀態(tài)，這些狀態(tài)信息會異常巨大。
• 組播控制平面協(xié)議會帶來CPU的密集操作，因為組播樹需要在接受者加入或離開時時刻更新。

從另一個方面來說，overlay的組播樹也會帶來產(chǎn)生影響，但是

• 第一個問題，組播復(fù)制同樣的數(shù)據(jù)包跨越相同的物理鏈路，尤其是靠近源端的鏈路，這樣會消耗帶寬，但是和廣域網(wǎng)不同，對于數(shù)據(jù)中心網(wǎng)絡(luò)，這并不是一個大問題，因為數(shù)據(jù)中心矩陣而言，所提供的是一個CLOS架構(gòu)的矩陣，可以提供任意點無阻塞的連接。
• 第二個問題是overlay組播樹將組播實現(xiàn)的功能在軟件虛擬路由器上實現(xiàn)，也會帶來CPU的影響，底層網(wǎng)絡(luò)的硬件交換機(jī)通常使用硬件支持組播實現(xiàn)，這個問題可以如圖15所示，通過多個虛擬路由器級聯(lián)的方式實現(xiàn)組播復(fù)制，來得以緩解。

2.2.6? Layer 2 BUM Traffic

二層廣播，未知單播和組播流量需要在二層網(wǎng)絡(luò)中泛洪，在OpenContrail中，未知淡泊流量會被丟棄，而不是泛 洪，因為系統(tǒng)并不是依賴泛洪-學(xué)習(xí)的機(jī)制來建立MAC地址表，取而代之的是，使用控制協(xié)議去建立MAC地址表，如果目的地址未知，那意味著可能是系統(tǒng)出現(xiàn) 了某些故障。二層廣播也同樣避免，因為大部分二層廣播都是因為一些協(xié)議的操作出現(xiàn)。

對于其他已知的二層廣播和組播，系統(tǒng)為每一個虛擬網(wǎng)絡(luò)的創(chuàng)建一個分布樹，連接虛擬網(wǎng)絡(luò)中的所有路由實例，這個樹可以由overlay或者底層網(wǎng)絡(luò)構(gòu)成。

2.2.7?代理服務(wù)

虛擬路由器代理很多類型的流量（從VM發(fā)出的），以此避免泛洪。虛擬路由器攔截特定的數(shù)據(jù)包，并把這些流量通過XMPP代理給控制節(jié)點，控制節(jié)點通過XMPP返回響應(yīng)

當(dāng)前系統(tǒng)代理如下類型的流量（其他流量代理會在后續(xù)增加）

• DHCP請求。控制節(jié)點會根據(jù)VM的配置提供DHCP的響應(yīng)
• ARP響應(yīng)。控制節(jié)點提供IP和MAC地址的對應(yīng)
• DNS和MDNS請求，控制平面提供域名和IP地址的對應(yīng)。

2.2.8?轉(zhuǎn)發(fā)策略

虛擬路由器轉(zhuǎn)發(fā)平面包含一個流表，提供多個功能—防火墻策略，負(fù)載均衡，匯總等。流表包含流表條目，包含匹配條件的關(guān)聯(lián) 的操作，匹配田間可以是接收數(shù)據(jù)包N元組的匹配（可能是掩碼匹配），操作包括數(shù)據(jù)包的丟棄，允許，或者重定向到另外一個路由實例。流表條目通過虛擬路由器 代理在轉(zhuǎn)發(fā)平面上形成。

當(dāng)流表中沒有相應(yīng)條目時，會把數(shù)據(jù)包掛起，并轉(zhuǎn)發(fā)給虛擬路由器代理，這樣可以讓虛擬路由器識別是否是一個新的流的首包，虛擬路由器代理會為每一個新流創(chuàng)建流表，并把首包發(fā)送到轉(zhuǎn)發(fā)平面。

2.3?服務(wù)鏈

OpenContrail支持高級策略語言，允許虛擬網(wǎng)絡(luò)基于策略互聯(lián)，這個策略語言類似于Snort規(guī)則語言，但是在系統(tǒng)上做了改變和擴(kuò)展，策略規(guī)則如類似于

allow?? any?? src-vn -> dst-vn?? svc-1, svc-2

這個規(guī)則允許所有的流量，從虛擬網(wǎng)絡(luò)src-vn到虛擬網(wǎng)絡(luò)dst-vn，并且強(qiáng)制流量經(jīng)由服務(wù)鏈，先經(jīng)過服務(wù)svc-1，然后到svc-2，在前面的案例中，規(guī)則允許虛擬網(wǎng)絡(luò)src-vn的任何虛擬機(jī)發(fā)送流量到虛擬網(wǎng)絡(luò)dst-vn的任何虛擬機(jī)。

系統(tǒng)考慮流量的引導(dǎo)，將流量使用虛擬接口注入到正確的虛擬機(jī)中，這些（負(fù)責(zé)服務(wù)的）虛擬機(jī)可以提供諸如防火墻，DPI，IDS，IPS，緩存等網(wǎng)絡(luò)服務(wù)

系統(tǒng)為租戶虛擬機(jī)增加新的路由實例，為負(fù)責(zé)服務(wù)的虛擬機(jī)創(chuàng)建路由實例，流量被引導(dǎo)

• 通過操縱路由的route target（RT）影響從一個路由實例到另外一個路由實例的注入和導(dǎo)出
• 通過操縱下一條和（或者）路由的標(biāo)簽，使得他們可以把路由實例的路由相互泄漏，強(qiáng)制流量按照正確的順序在路由實例中轉(zhuǎn)發(fā)，流量經(jīng)由正確的虛擬機(jī)。

圖18描述了服務(wù)鏈中流量在路由實例中轉(zhuǎn)發(fā)的基本概念

在上面的案例中

• 通過路由實例中的RT（route target）的注入和導(dǎo)出，使得路由泄漏可以從ri-t2到ri-s2，然后泄漏到ri-s1，再到ri-t1
• 當(dāng)負(fù)責(zé)服務(wù)的路由實例導(dǎo)出路由時，他們將自己指定為下一跳，并且產(chǎn)生一個新的label。
  • 下一跳引導(dǎo)流量到服務(wù)器（也就是服務(wù)虛擬機(jī)所在物理服務(wù)器）
  • 標(biāo)簽引導(dǎo)流量到該物理服務(wù)器上的負(fù)責(zé)服務(wù)的虛擬機(jī)上

IETF draft[draft-rfernando-virt-topo-bgp-vpn]?描述了服務(wù)鏈的類似機(jī)制

2.4??控制和管理平面協(xié)議

2.4.1? IF-MAP

The Interface for Metadata Access Points (IF-MAP)?^[if-map]?是一個開放標(biāo)準(zhǔn)的客戶端/服務(wù)器協(xié)議，由Trusted Computer Group (TCG)開發(fā)，作為Trusted Network Connect (TNC)開放架構(gòu)的核心協(xié)議。

原始的IF-MAP應(yīng)用提供一個Metadata Access Point (MAPs)的通用接口，數(shù)據(jù)庫服務(wù)器扮演票據(jù)交易所的角色，負(fù)責(zé)TNC架構(gòu)中的安全事件，組件和其他內(nèi)容的信息

IF-MAP提供一個定義數(shù)據(jù)模型的擴(kuò)展機(jī)制，同時也定義了一個協(xié)議，用于發(fā)布，訂閱，數(shù)據(jù)存儲的查詢。

OpenContrail使用IF-MAP協(xié)議從配置節(jié)點到控制節(jié)點分發(fā)信息。控制節(jié)點可以使用訂閱機(jī)制，僅僅接受他們感興趣的配置信息的子集。系統(tǒng)同時使用IF-MAP定義高層級和低層級配置數(shù)據(jù)模型。

2.4.2? XMPP

The Extensible Messaging and Presence Protocol (XMPP)?^[xmpp]?是一個用于信息導(dǎo)向的中間件，基于XML的通訊協(xié)議。XMPP原來叫Jabber，用于即時信息，出席信息和聯(lián)系列表維護(hù)，其設(shè)計具有擴(kuò)展性，協(xié)議已經(jīng)進(jìn)化成通用的發(fā)布訂閱信息總線，可以用在多種應(yīng)用中。

OpenContrail使用XMPP作為一個計算節(jié)點和控制節(jié)點之間交換大量例如路由，配置，運行狀態(tài)，統(tǒng)計，日志和事件的通用信息總線

IETF drafts?[draft-ietf-l3vpn-end-system]?和?[draft-marques-l3vpn-mcast-edge]?描述了 XMPP 和信息格式

2.4.3? BGP

OpenContrail使用BGP在控制節(jié)點之間交換路由信息。BGP也被應(yīng)用在控制節(jié)點和網(wǎng)關(guān)節(jié)點（大多數(shù)網(wǎng)絡(luò)廠商路由器和交換機(jī)）交換路由信息。

2.4.4? Sandesh

Sandesh是一個基于XML的協(xié)議，用于匯報分析信息。XML信息的結(jié)構(gòu)被描述成公共語法格式。每個節(jié)點的組件都有一個Sandesh連接到分析節(jié)點之一上。Sandesh攜帶兩類信息

• 系統(tǒng)的所有組件發(fā)送異步協(xié)議到分析節(jié)點上，匯報日志，監(jiān)控，事件等
• 分析節(jié)點可以發(fā)送請求信息和接收響應(yīng)信息去收集特定的運行狀態(tài)。

2.5? Openstack Integration

圖19描述了OpenStack Nova, Neutron 和 OpenContrail之間的集成。

OpenStack的Nova模型通過計算節(jié)點中的Nove 代理創(chuàng)建虛擬機(jī)。Nova代理和OpenContrail Neutron插件通訊，檢索新的虛擬機(jī)的網(wǎng)絡(luò)屬性（如IP地址），當(dāng)虛擬機(jī)創(chuàng)建，Nova代理通知虛擬路由器代理為新創(chuàng)建的虛擬機(jī)創(chuàng)建虛擬網(wǎng)絡(luò)

2.6??安全性

所有的控制平面協(xié)議使用Transport Layer Security (TLS) 和? Secure Sockets Layer (SSL)提供驗證和數(shù)據(jù)完整性，也可以用于提供數(shù)據(jù)的私密性，盡管這并不在數(shù)據(jù)中心的考慮之內(nèi)。

初始化服務(wù)查找證書用于驗證，后續(xù)的通訊都是基于令牌的驗證，用以提高性能。服務(wù)查詢服務(wù)器通過證書驗證TLS連接在服務(wù)器和客戶端之間產(chǎn)生令牌證書的分發(fā)超出了本文檔的范圍，從實踐上說，這部分工作由服務(wù)管理系統(tǒng)例如puppet或者chef來負(fù)責(zé)。

所有系統(tǒng)內(nèi)的REST API使用基于策略的授權(quán)，服務(wù)器通過TLS驗證識別客戶端，并且指派一個或者多個規(guī)則。規(guī)則定義客戶端的接口操作（只讀或者讀取）和哪些數(shù)據(jù)模型的組件客戶端可以訪問。

2.7??層次化彈性和高可用性

為使層次化彈性的高可用性更佳，控制節(jié)點，配置節(jié)點和分析節(jié)點都有多個實例，所有實例都是雙活（A-A），OpenContrail并沒有使用A-S方式

2.7.1?配置節(jié)點

目前，所有的控制都包含整個系統(tǒng)的運行狀態(tài)，例如，所有虛擬網(wǎng)絡(luò)中所有虛擬機(jī)的路由，控制狀態(tài)的總數(shù)相比較而言較少，更適合每個配置節(jié)點的內(nèi)存占用。當(dāng)更多的功能加入之后，控制節(jié)點之間控制狀態(tài)的匯總和分片將會在未來引入，原理類似于BGP中的RT特定路由反射。

每個虛擬路由器代理連接兩個或者多個節(jié)點，所有的節(jié)點都是A-A狀態(tài)，虛擬路由器代理從每個控制節(jié)點接受所有的狀態(tài)（路 由，路由實例的配置等），從兩個或者多個節(jié)點接受到的狀態(tài)保證最終一直，但是有可能短暫的不一致。每個虛擬路由器代理執(zhí)行本地選擇，選擇使用哪一個控制狀 態(tài)的副本。這類似于BGP PE路由器接受到相同路由（從每一個BGP鄰居）的拷貝但是執(zhí)行本地的最優(yōu)路徑選擇。

當(dāng)一個控制節(jié)點失效，虛擬路由器代理將會通知到這個控制節(jié)點的連接已經(jīng)丟失，將會刷新所有從這個失效控制節(jié)點接收的狀態(tài) 信息。因為已經(jīng)有了從其他控制節(jié)點的所有信息的狀態(tài)，虛擬路由器可以本地迅速進(jìn)行切換，而不需要重新同步，虛擬路由器代理將會再次聯(lián)系服務(wù)查詢服務(wù)器，和 一個新的控制節(jié)點建立連接，取代失效的控制節(jié)點。

2.7.2?配置節(jié)點

配置節(jié)點保存所有配置狀態(tài)在一個可容錯，高可用性的NoSQL數(shù)據(jù)庫中，包含高層級數(shù)據(jù)模型的內(nèi)容，如預(yù)留系統(tǒng)明確安裝的配置狀態(tài)，同時也包括低層級數(shù)據(jù)模型的內(nèi)容，例如通過轉(zhuǎn)換模型從高層級數(shù)據(jù)模型導(dǎo)出的配置狀態(tài)

控制節(jié)點使用IF-MAP訂閱控制平面需要的低層級數(shù)據(jù)模型的部分。服務(wù)查找服務(wù)器指定每一個控制節(jié)點到特定的配置節(jié)點。如果配置服務(wù)器失效，控制節(jié)點重新聯(lián)系服務(wù)查找服務(wù)器指定另一個配置服務(wù)器、

切換之后，控制節(jié)點重新和新的配置節(jié)點同步，這類似于路由協(xié)議中平滑重啟達(dá)到的目的—保證所有狀態(tài)，完整回復(fù)并且刷新已有狀態(tài)信息。

2.7.3?分析節(jié)點

系統(tǒng)提供所有分析組件的完整高可用性功能，類似于配置節(jié)點，分析節(jié)點是無狀態(tài)的，分析節(jié)點的失效不會導(dǎo)致系統(tǒng)丟失信息， 當(dāng)一個分析節(jié)點失效，系統(tǒng)查找服務(wù)器將會將會把功能轉(zhuǎn)移到一個可工作的分析節(jié)點上，并且所有上行REST API同樣使用查找服務(wù)器去檢測節(jié)點的失敗和功能節(jié)點的轉(zhuǎn)移，失效的分析節(jié)點將會從可用的節(jié)點池中剔除，剩下的分析節(jié)點中的一個將會執(zhí)行工作，收集數(shù)據(jù)和 處理查詢。

OpenContrail提供數(shù)據(jù)庫組件的完整的高可用性，數(shù)據(jù)庫集群設(shè)置有多重備份的屬性，當(dāng)數(shù)據(jù)庫節(jié)點失敗，數(shù)據(jù)本 身可具備彈性，集群可以在多個數(shù)據(jù)庫節(jié)點失效時具備彈性，當(dāng)數(shù)據(jù)庫節(jié)點失效，分析節(jié)點可以平滑的從失效節(jié)點到可用節(jié)點上，在這個過程中，我們將會把數(shù)據(jù)隊 列清空，在轉(zhuǎn)移過程中數(shù)據(jù)的丟失將會非常小。

2.7.4?虛擬路由器代理

虛擬路由器的高可用性基于包括BGP在內(nèi)的很多路由協(xié)議的平滑重啟，如果虛擬路由器代理因為任何原因重啟（崩潰，升級），虛擬路由器的轉(zhuǎn)發(fā)平面將會基于由虛擬路由器代理在重啟前安裝的轉(zhuǎn)發(fā)狀態(tài)繼續(xù)轉(zhuǎn)發(fā)數(shù)據(jù)。

當(dāng)虛擬路由器代理失效，虛擬路由器的轉(zhuǎn)發(fā)平面運行在一個“無腦”模式，所有的轉(zhuǎn)發(fā)狀態(tài)都是保持原有，當(dāng)虛擬路由器代理重啟，將會重新和冗余的控制節(jié)點建立通訊關(guān)系，并且從控制節(jié)點上重新學(xué)習(xí)狀態(tài)，重新在轉(zhuǎn)發(fā)平面上安裝狀態(tài)，替換原由的狀態(tài)。

當(dāng)虛擬路由器代理完成從控制節(jié)點的狀態(tài)學(xué)習(xí)，完成轉(zhuǎn)發(fā)平面內(nèi)的狀態(tài)重新安裝，所有轉(zhuǎn)發(fā)平面的狀態(tài)全部被刷新。

2.7.5?虛擬路由器轉(zhuǎn)發(fā)平面

如果虛擬路由器轉(zhuǎn)發(fā)平面因為任何原因（崩潰，升級）重啟，將會影響特定服務(wù)器的流量處理。

這種情況不可避免，因為我們在每一個路由器上只有一個轉(zhuǎn)發(fā)平面和轉(zhuǎn)發(fā)實例，所以，保證路由器的越簡單越好，減少崩潰和升級的可能，是非常重要的。

3??數(shù)據(jù)模型

系統(tǒng)所有狀態(tài)的基礎(chǔ)，不管是配置，運行還是分析，都是數(shù)據(jù)模型的集合。每個數(shù)據(jù)模型定義了組件的集合，語意，以及他們之 間的關(guān)系。系統(tǒng)運行在他們的數(shù)據(jù)模型上來執(zhí)行工作：創(chuàng)建和更新組件和關(guān)系，轉(zhuǎn)換“高層級”組件到“低層級”組件，安裝低層級組件到網(wǎng)絡(luò)環(huán)境中，創(chuàng)建所需要 的連接和服務(wù)。數(shù)據(jù)模型提供確定的性能給可供操作的模塊，并且為模塊定義確定的需求。數(shù)據(jù)模型如此設(shè)計的主要結(jié)果是系統(tǒng)具有分布式，可靈活，高可用性，易 于升級和具備彈性。

數(shù)據(jù)模型是從本質(zhì)上從表層提供一個具有注釋的圖表來展現(xiàn)組件，和通過連接展現(xiàn)組件之間的關(guān)系，系統(tǒng)使用一個數(shù)據(jù)模型語言 （DML）Data Modeling Language 去定義他們，一些組件的語意和他們之間的關(guān)系，在數(shù)據(jù)模型中直接體現(xiàn)，例如圖表的表層可以展示抽象或者具體的組件，并且連接可以展示一對組件之間是“父 子”關(guān)系還是從屬關(guān)系。剩余的語意可以通過表層或者鏈路的注釋來描述，一對表層之間的連接鏈路可以注釋上需要的帶寬，路由實例之間的鏈路可以注釋需要的路 由策略（譯者注：vertices翻譯過來時頂層，最頂?shù)囊馑?#xff0c;實際上個人理解就是在ppt里面畫圖上的最上層的圖標(biāo)）

3.1?程序模型

配置和運行狀態(tài)的數(shù)據(jù)模型使用IF-MAP定義，其自身數(shù)據(jù)保存在一個Cassandra數(shù)據(jù)庫中，這個數(shù)據(jù)庫提供持續(xù) 的，可用的和可擴(kuò)展的規(guī)格參數(shù)。一個使用Redis的“發(fā)布訂閱模型”總線覆蓋在頂層，作為內(nèi)存關(guān)鍵值存儲。模塊和數(shù)據(jù)庫互操作，可以選擇定于制定類型的 更新，當(dāng)模塊發(fā)布一個更新到一個組件，更新會發(fā)布給其他訂閱該類型組建的模塊。

數(shù)據(jù)模型的所有修訂必須具有向后兼容的能力，從另一個角度說，參考數(shù)據(jù)模型的程序必須可以和以前一樣持續(xù)工作，而不需要 修改。這就意味著對于數(shù)據(jù)模型的改變只能擴(kuò)展現(xiàn)有組件，連接和注釋，但是必須不能改變現(xiàn)有組件的語意，或者他們之間的關(guān)系。進(jìn)而，修改永遠(yuǎn)不能和一個組件 或者鏈路類型相悖。例如組件之間的關(guān)系可以向后兼容，可以修改到數(shù)據(jù)模型中的未來需求必須是增量的，注入到現(xiàn)有運行模塊的改變，而不需要重新編譯。

訪問數(shù)據(jù)模型是經(jīng)由一個RESTful API，從模型定義自動產(chǎn)生，進(jìn)一步，為其他語言（Python，Java等等）的綁定也會產(chǎn)生，允許成需要使用這些語言在模型中操作數(shù)據(jù)。

運行在這些數(shù)據(jù)模型的模塊必須是事件驅(qū)動的。這意味著兩件事：第一，一個模塊必須監(jiān)聽“發(fā)布訂閱模型”總線的更新；第 二，當(dāng)?shù)玫教囟ㄐ袨樗枰乃行畔r，就要執(zhí)行行為。更新可能來自任何順序—發(fā)布訂閱模型總線不會保證更新的順序或者管理歸屬—這是每個模塊的責(zé)任。進(jìn) 一步說，模塊必須要可重啟，如果崩潰，或者強(qiáng)制重啟（如更新），將會重新連接數(shù)據(jù)庫，重新請求狀態(tài)并持續(xù)處理。為完成這些，一個模塊必須要通過數(shù)據(jù)模型或 者“這個網(wǎng)絡(luò)”保持所有數(shù)據(jù)庫的非臨時狀態(tài)，模塊可以重新從對等體請求狀態(tài)信息。最后，模塊必須是有彈性的，他們必須具有分布式的工作特性。實例必須依據(jù) 當(dāng)前的負(fù)載決定創(chuàng)建或者終止。完成這一目標(biāo)需要分布式數(shù)據(jù)庫保持?jǐn)?shù)據(jù)模型，并且具有分布式的條目（例如為獨立的ID產(chǎn)生）協(xié)調(diào)服務(wù)（譯者注，這段比較晦 澀，也翻譯的不是很準(zhǔn)確）

3.2??配置和運維數(shù)據(jù)模型

數(shù)據(jù)模塊包含一個層次化的模型，呈現(xiàn)成一個樹狀的，帶有注釋的直連非循環(huán)圖表（DAG）。DAG的頂點展現(xiàn)的組件可能是 管理名稱，或者是物理或者邏輯的資源。DAG之間的連接體現(xiàn)的是組件之間的關(guān)系。一個組件可能有0個或者多個子集但是必須有一個明確的父集（除了根之外， 根不需要父集），刪除一個組件就會隱形的刪除下面的子樹。一個組件可以參考另外一個組件–用一個“參考點”作為維護(hù)。刪除參考的組件就削弱參考點。刪除顯 著參考的組件是不允許的。可以不存在組件的“弱參考”，一個組件的“弱參考”可能被刪除。（譯者注：這段是描述組件之間的關(guān)系，意義不大，可以看下面的圖 就會理解的多一些）

如圖20所示，DAG的根層下面顯示的是系統(tǒng)的多個領(lǐng)域的組件，例如“管理域”（AD），可能是一個數(shù)據(jù)中心集群，一個 POP節(jié)點，一個辦公網(wǎng)中心，或者是一個廣域網(wǎng)。一個AD具有一個全局的管理員去進(jìn)行管理，AD還有一個為內(nèi)部可能使用的標(biāo)識關(guān)聯(lián)的命名空間。例如，IP 地址，域名和路由實例ID的標(biāo)識。

一個AD中包含一個或者多個租戶或域，舉例來說，DC內(nèi)的租戶可能是可口和百事。在POP或者CO的租戶可能是業(yè)務(wù)客戶或者寬帶業(yè)務(wù)的服務(wù)部門。

一個租戶可以包含多個項目，租戶中的一個部門，例如市場部將作為一個項目存在，項目包含虛擬網(wǎng)絡(luò)（VN），DC中的一個VN可以包含一個應(yīng)用層的一系列虛擬機(jī)。POP上的VN可能是為企業(yè)客戶的VPN，使用類似策略的一組移動寬帶用戶，或者是企業(yè)網(wǎng)絡(luò)中的一組用戶。

一個項目包含服務(wù)實例，網(wǎng)關(guān)和策略。一個項目同時具有安全組，管理員可以制定“規(guī)則”到端點，這些規(guī)則可以為端點定義未來的策略。

虛擬網(wǎng)絡(luò)VN包含端點，在DC域，端點就是虛擬機(jī)，對于業(yè)務(wù)邊緣，端點就是客戶站點（CE），端點作為安全組中的一部分，可以參考安全組。

數(shù)據(jù)模型的其他組件是路由實例“RI”，一個VN會編譯進(jìn)入一個或者多個RI，在虛擬路由器里面部署，另外其他的組件是RT,用于控制RI之間的路由泄漏。

在數(shù)據(jù)中心中的內(nèi)容做了層次化的部署，但是這種部署已經(jīng)足夠包含其他領(lǐng)域。在一些案例中，層次化的特定層級可能是冗余 的，在這個案例中，一個獨立的實例可以用在這個級別去維護(hù)層級。舉例來說，如果租戶的概念不需要，那就是一個租戶作為作為部署的基本租戶層級，如果需要新 的層級，那么必須向后兼容（譯者注：這部分的內(nèi)容主要是介紹業(yè)務(wù)的部署模式層次化，例如，把數(shù)據(jù)中心分成多個租戶，然后每個租戶下面還可以開啟多個部門， 每個部門下面在開啟project，然后在劃分VR和VN，當(dāng)然，如果環(huán)境比較簡單的話，就意味著數(shù)據(jù)中心只有一個租戶，這個租戶有沒有部門沒關(guān)系，開啟 project，然后劃分VR和VN，具體看下面的圖表會比較容易理解）

假定層次化的一個新的層級-部門—部署在租戶和項目之間，可以很簡單的添加進(jìn)來，當(dāng)然，這種需求可以向后兼容，這就意味著三件事

1.部門必須是層次化中的可選級別，這就意味著，必須可以直接在租戶下面創(chuàng)建項目并且也可以在部門下面創(chuàng)建項目

2.一個項目可以作為租戶的子集存在，直到這個子集被刪除。

3.一個新的項目可以作為租戶或者部門的子集，但是不同屬于兩個。

同樣，一個應(yīng)用，如果請求一個租戶的子集，就必須準(zhǔn)備接受其他類型的子集，可以簡單的忽略他們，但是一定會引發(fā)問題，或者造成失敗。（譯者注）

前面的圖表左面顯示的是做為租戶和項目之間父集-子集關(guān)系的數(shù)據(jù)模型，在項目上的虛線連接一個新的級別—部門，右面是數(shù) 據(jù)模型的一個實例，有租戶t1和項目t1.p2,用橙色表示，這是原始的數(shù)據(jù)模型，同時也展示了一個部門t1.d1，并且另外一個項目t1.d1.p1， 用紫色表示，這就遵循了修改后的數(shù)據(jù)模型，注意每一個項目只能屬于一個父集，橙色項目t1有自己的父集，紫色項目t1.d1也有自己的子集。

3.2.1?高層級和底層級數(shù)據(jù)模型

所有的組件和關(guān)系存在于常見的數(shù)據(jù)模型。在高層級和低層級內(nèi)部的組件也有些區(qū)別。配置狀態(tài)需要考慮通過外部系統(tǒng)（協(xié)調(diào)系 統(tǒng)或者應(yīng)用）創(chuàng)建的組件，并且作為高級數(shù)據(jù)模型的一個部分，例如租戶和項目。模塊創(chuàng)建的組件處于運行狀態(tài)，同時也要作為低層級考慮的部分，因為他們處于內(nèi) 部網(wǎng)絡(luò)環(huán)境的抽象層中，如路由實例。一些組建需要同時被配置和創(chuàng)建，在高層級和底層級均有涉及，例如RT—會被創(chuàng)建，同時也會配置，使得系統(tǒng)可以和外部的 BGP speaker通訊。

進(jìn)一步說，一些物理設(shè)備條目也會顯示在數(shù)據(jù)模型中。舉例來說，每個服務(wù)器上的虛擬路由器的實例都會顯示，系統(tǒng)感興趣的每 個BGP speaker（在控制節(jié)點內(nèi)部，同時包括OpenContrail的對等體，例如DC網(wǎng)關(guān)）也會顯示。最終，物理和虛擬的平臺也展示出來，這些組件用來 監(jiān)控BGP或者XMPP會話，以及他們之間的服務(wù)鏈接。

3.2.2?服務(wù)連接數(shù)據(jù)模型

一個服務(wù)“鏈”既是在跨越兩個VN對之間數(shù)據(jù)流的標(biāo)準(zhǔn)，從VN出來的流量可能在到達(dá)另外一個VN之前通過仲裁圖示經(jīng)過一個服務(wù)節(jié)點，流量可能會基于服務(wù)選擇不同的路徑（例如，一個IDS可能指引流量到一個DPI引擎），或者為了監(jiān)控的目的復(fù)制流量。

服務(wù)鏈的定義包含兩個部分：從入口VN，到設(shè)置的服務(wù)部分，在到出口VN的流量路徑和應(yīng)用在每一個服務(wù)部分的服務(wù)模板。如圖所示，每一個定義都會注釋到組件上。

4? OpenContrail使用案例

OpenContrail有三個當(dāng)前可用的應(yīng)用案例—企業(yè)的私有云架構(gòu)即為服務(wù)（b）和運營商的虛擬私有云，網(wǎng)絡(luò)功能虛擬化（c），本文并不能全面的提供完整的應(yīng)用案例，但是可以提供一個應(yīng)用案例的簡單描述。

4.1??數(shù)據(jù)中心領(lǐng)域應(yīng)用案例

4.1.1?數(shù)據(jù)中心內(nèi)部協(xié)調(diào)器的職責(zé)

在我們深入探討數(shù)據(jù)中心應(yīng)用案例規(guī)范之前，討論數(shù)據(jù)中心內(nèi)部協(xié)調(diào)器的職責(zé)是非常必要的。

在數(shù)據(jù)中心內(nèi)，協(xié)調(diào)器（Openstack, CloudStack, VMware, Microsoft System Center, 等等）管理著數(shù)據(jù)中心多諸多關(guān)鍵要素。

• 計算
• 存儲
• 網(wǎng)絡(luò)
• 應(yīng)用

SDN控制器的職責(zé)是繼續(xù)應(yīng)用的需求協(xié)調(diào)網(wǎng)絡(luò)和網(wǎng)絡(luò)服務(wù)（如負(fù)載均衡和安全），并指定計算和存儲資源。

協(xié)調(diào)器使用SDN控制器的北向接口在抽象層的最高層級協(xié)調(diào)網(wǎng)絡(luò)，例如：

• 為租戶創(chuàng)建一個虛擬網(wǎng)絡(luò)，在數(shù)據(jù)中心內(nèi)部或者是跨越數(shù)據(jù)中心。
• 為租戶虛擬網(wǎng)絡(luò)附加一個虛擬機(jī)
• 連接虛擬租戶虛擬網(wǎng)絡(luò)到一些外部網(wǎng)絡(luò)，例如互聯(lián)網(wǎng)或者VPN
• 在一組虛擬機(jī)或者租戶網(wǎng)絡(luò)的邊界應(yīng)用一個安全策略
• 在虛擬網(wǎng)絡(luò)中部署網(wǎng)絡(luò)服務(wù)（例如負(fù)載均衡器）

SDN控制器的責(zé)任是將這些抽象層高層級的請求轉(zhuǎn)化成物理或者虛擬網(wǎng)絡(luò)設(shè)備上實際的操作，例如：

• 物理交換機(jī)，如架頂（TOR）交換機(jī)，匯聚交換機(jī)，或者單層交換矩陣
• 物理路由器
• 物理服務(wù)設(shè)備例如防火墻和負(fù)載均衡器
• 虛擬服務(wù)-例如虛擬防火墻

4.1.2?虛擬多租戶數(shù)據(jù)中心

虛擬多租戶數(shù)據(jù)中心使用案例允許多個租戶存在于一個數(shù)據(jù)中心，多租戶意味著租戶共享同樣的物理基礎(chǔ)環(huán)境（服務(wù)器，網(wǎng)絡(luò)，存儲）但是邏輯上彼此分割

租戶的概念著在不同的描述下可以有不同的定義

在運營商數(shù)據(jù)中心提供公有云服務(wù)，是一個客戶或者是客戶的一類服務(wù)

• 在一個企業(yè)數(shù)據(jù)中心部署私有云，意味著可能是一個部門或者是為用戶提供的一個服務(wù)。
• 因為一些網(wǎng)絡(luò)架構(gòu)（特別是常見的點到點VLAN）具有每數(shù)據(jù)中心4096個租戶的限制，所以，租戶的數(shù)量很重要。

不是所有的數(shù)據(jù)中心都是多租戶，一些大型內(nèi)容提供商（例如Facebook）具有私有數(shù)據(jù)中心，僅作為內(nèi)部應(yīng)用，目前還沒有提供云服務(wù)。盡管這些數(shù)據(jù)中心可以支持多租戶行為，但是并不去使用多租戶的定義。

例如，早期的亞馬遜網(wǎng)站服務(wù)（AWS）支持多租戶，但是從網(wǎng)絡(luò)方面去看租戶并不是相互隔離（所有的租戶連接相同的三層網(wǎng)絡(luò)），直到亞馬遜引入一些高級服務(wù)（叫做虛擬私有云-VPC），允許每個租戶可以獲得一個或者多個私有隔離網(wǎng)絡(luò)。

圖23介紹了在不同市場劃分下虛擬化和多租戶的需求，虛擬化的使用，不同的市場分段使用不同的協(xié)調(diào)器和hypervisor。

• 在企業(yè)市場方面，商業(yè)協(xié)調(diào)器被廣泛使用，隨著云的逐漸采用和向SDN的演進(jìn)，也存在和開源（如OpenStack或者CloudStack）集成的需求
• 在架構(gòu)即服務(wù)（IaaS）和公有云市場，開源協(xié)調(diào)器（OpenStack，CloudStack）和hypervisor（如KVM，Xen）經(jīng)常被使用，可以用于定制化，開銷和擴(kuò)展的原因。
• 大型內(nèi)容提供商（如Google和Facebook）經(jīng)常建設(shè)他們自己的協(xié)調(diào)器軟件并且不使用hypervisor（因為性能和 擴(kuò)展性的原因）（譯者注，這段只能贊同一點點）

通常情況，如24圖所示，每一個租戶相當(dāng)于運行在物理服務(wù)器上的虛擬機(jī)的集合，hypervisor包含虛擬交換機(jī)（vSwitch）連接虛擬機(jī)到物理網(wǎng)絡(luò)和其他虛擬機(jī)，應(yīng)用也可以直接運行在物理服務(wù)器上（不是在虛擬機(jī)中），如右側(cè)的綠色服務(wù)器（B）現(xiàn)實。

在圖24中，數(shù)據(jù)中心網(wǎng)絡(luò)可能會有多層網(wǎng)絡(luò)，或者在圖25中，數(shù)據(jù)中心網(wǎng)絡(luò)可能是單層網(wǎng)絡(luò)（如Fabric）

服務(wù)器使用物理數(shù)據(jù)中心網(wǎng)絡(luò)互聯(lián)，在圖24中，網(wǎng)絡(luò)分成兩層（接入和核心）網(wǎng)絡(luò)，也可能是三層（接入，匯聚，核心）網(wǎng)絡(luò)，或者一層（如Q-Fabric）網(wǎng)絡(luò)。對于overlay解決方案中，數(shù)據(jù)中心網(wǎng)絡(luò)建議是Layer 3網(wǎng)絡(luò)（IP或者M(jìn)PLS）。

在最簡的網(wǎng)絡(luò)架構(gòu)，如圖26所示，云提供商為每個虛擬機(jī)指定IP地址，給定租戶的虛擬機(jī)不在同一個L2網(wǎng)絡(luò)中。所有的虛擬機(jī)（從同一個租戶或者不同的租戶）可以通過路由IP網(wǎng)絡(luò)相互通訊

例如，亞馬遜網(wǎng)站服務(wù)，彈性計算云（EC2）默認(rèn)給每一個虛擬機(jī)一個私有IP地址（可以在亞馬遜EC2網(wǎng)絡(luò)里互聯(lián)）和一 個公有IP地址（通過NAT和互聯(lián)網(wǎng)通訊），當(dāng)虛擬機(jī)建立后，亞馬遜自動生成私有和公有IP。亞馬遜EC2彈性IP地址功能指定有限的（默認(rèn)五個）靜態(tài) IP（給租戶用于分配給VM）用于和互聯(lián)網(wǎng)連接。

在一個網(wǎng)絡(luò)中隔絕租戶里面的相互訪問，每一個租戶可以被指定一個私有的L2網(wǎng)絡(luò)，如圖27所示，租戶網(wǎng)絡(luò)允許虛擬機(jī)和其 他同一個租戶的虛擬機(jī)相互訪問，除非是策略限制。租戶網(wǎng)絡(luò)相互之間隔絕，一個租戶內(nèi)的虛擬機(jī)不能和其他租戶的虛擬機(jī)相互訪問，除非被特定策略允許。同樣， 除非是特定策略允許，虛擬機(jī)不能實現(xiàn)互聯(lián)網(wǎng)訪問。

租戶私有網(wǎng)絡(luò)通常成為虛擬網(wǎng)絡(luò)。在給定的租戶網(wǎng)絡(luò)中的所有的虛擬機(jī)在一個L3子網(wǎng)。租戶可能允許允許使用他們自己的IP給虛擬機(jī)，或者云提供商可以分配IP地址，任何一種方式下，在不同的租戶里IP地址可能不唯一（如相同的IP地址可能用在兩個不同租戶的兩個虛擬機(jī)中）

一個租戶可能會有多個虛擬網(wǎng)絡(luò)，這些虛擬網(wǎng)絡(luò)之間通過使用三層路由器，防火墻，NAT，負(fù)載均衡或者其他服務(wù)有可能互聯(lián)，也可能不互聯(lián)。

作為一個虛擬租戶網(wǎng)絡(luò)隔離的案例，亞馬遜虛擬私有云服務(wù)（VPC）允許租戶創(chuàng)建一個或者多個子網(wǎng)，并且將他們相互連接，或者到互聯(lián)網(wǎng)，或者使用路由器或者服務(wù)（如NAT）到特定網(wǎng)絡(luò)。

使用案例包括一個邏輯集中的協(xié)調(diào)層（在前面都沒有顯示）去管理租戶網(wǎng)絡(luò)

• 添加和刪除租戶
• 定義租戶網(wǎng)絡(luò)的帶寬，QOS和安全屬性
• 其他

協(xié)調(diào)層必須覆蓋租戶網(wǎng)絡(luò)的所有方面（計算，存儲，網(wǎng)絡(luò)和存儲）和支持快速改變。

4.1.3?連接租戶到互聯(lián)網(wǎng)/VPN

在這個案例里，租戶連接到互聯(lián)網(wǎng)或者通過VPN連接到企業(yè)網(wǎng)絡(luò)，VPN可以是L3VPN，L2VPN，SSLVPN和IPsec VPN等等。

數(shù)據(jù)中心網(wǎng)關(guān)的功能是連接租戶網(wǎng)絡(luò)到互聯(lián)網(wǎng)或者VPN，網(wǎng)關(guān)的功能可以部署為軟件或者硬件形式（例如使用網(wǎng)關(guān)路由器）

4.1.4?數(shù)據(jù)中心互聯(lián)

在這個案例中，多個數(shù)據(jù)中心通過廣域網(wǎng)（WAN）進(jìn)行互聯(lián)。

數(shù)據(jù)中心可以是在災(zāi)難恢復(fù)上使用活躍/備份模式，在災(zāi)難避免時使用活躍/活躍方式，或者永久的雙活，在雙活案例中，租戶可能在多個數(shù)據(jù)中心中存在虛擬機(jī)，數(shù)據(jù)中心互聯(lián)技術(shù)使得跨越所有數(shù)據(jù)中心的給定租戶的虛擬機(jī)處在同一個虛擬網(wǎng)絡(luò)中。

DCI必須滿足如下網(wǎng)絡(luò)需求

• 存儲的復(fù)制
• 允許租戶網(wǎng)絡(luò)使用覆蓋的IP地址跨域數(shù)據(jù)中心
• 全局的負(fù)載均衡
• 為容災(zāi)實現(xiàn)虛擬機(jī)跨越數(shù)據(jù)中心遷移

數(shù)據(jù)中心互聯(lián)上存在很多技術(shù)，包括裸光纖，SONET/SDH, DWDM, 偽線, Layer 3 VPN, E-VPN等等，不同于數(shù)據(jù)中心網(wǎng)絡(luò)，在DCI的廣域網(wǎng)上，帶寬是一個稀缺資源，所以流量工程經(jīng)常使用，保證資源的有效利用。

4.1.5?網(wǎng)絡(luò)監(jiān)控

在數(shù)據(jù)中心網(wǎng)絡(luò)一直得經(jīng)常需要在網(wǎng)絡(luò)中特定的節(jié)點復(fù)制特定的流，并且為了未來的分析需要發(fā)送到一個或者多個監(jiān)控設(shè)備，這就是所謂的網(wǎng)絡(luò)監(jiān)控或者TAP使用案例

監(jiān)控可能是臨時的，舉例來說，做網(wǎng)絡(luò)的debug，或者監(jiān)控可能是永久的，例如為了常規(guī)審計的原因

常見的監(jiān)控部署，是配置交換機(jī)的端口分析（SPAN）功能在網(wǎng)絡(luò)中，發(fā)送復(fù)制的數(shù)據(jù)到特定的端口。遠(yuǎn)程SPAN是更高級的功能，允許復(fù)制的流量可以通過GRE發(fā)送到遠(yuǎn)端分析設(shè)備上

一個集中的SDN系統(tǒng)可以用于

• 在網(wǎng)絡(luò)中的監(jiān)控選擇點（TAP）創(chuàng)建一個通道，監(jiān)控設(shè)備收集和分析流量
• 要求網(wǎng)絡(luò)中交換機(jī)和路由器輪詢流量的特定流進(jìn)入通道進(jìn)行分析。

4.1.6?動態(tài)虛擬服務(wù)

在這個使用案例中，網(wǎng)絡(luò)服務(wù)如防火墻，入侵防護(hù)系統(tǒng)，入侵監(jiān)測系統(tǒng)，負(fù)載均衡，SSL負(fù)載，緩存和廣域網(wǎng)優(yōu)化都被部署在租戶網(wǎng)絡(luò)中

這些服務(wù)由服務(wù)節(jié)點提供，可以放置在圖31中的各種位置

服務(wù)可以部署在多個位置

• 在hypervisor上
• 在虛擬機(jī)內(nèi)
• 在物理設(shè)備上
• 在物理或者虛擬交換機(jī)上商用ACL
• 在路由器或者交換機(jī)的服務(wù)板卡上開啟服務(wù)，或者本身在轉(zhuǎn)發(fā)ASIC上就具備支持此類服務(wù)的能力

服務(wù)可能會關(guān)聯(lián)一個或多個VM，例如使用一個安全策略到一個或多個VM上，

取而代之的是，服務(wù)可能被關(guān)聯(lián)在網(wǎng)絡(luò)邊界上，例如應(yīng)用安全策略在網(wǎng)絡(luò)邊界，或者安裝負(fù)載均衡設(shè)備在網(wǎng)絡(luò)邊界，如圖32所示，網(wǎng)絡(luò)邊界可能是

• 租戶網(wǎng)絡(luò)和外部網(wǎng)絡(luò)之間的邊界（互聯(lián)網(wǎng)或者企業(yè)VPN）
• 租戶網(wǎng)絡(luò)之間的邊界
• 同一個租戶的多個網(wǎng)絡(luò)之間的邊界

4.2 SP環(huán)境下的NFV

4.2.1?服務(wù)注入

邊界路由器需要應(yīng)用一些服務(wù)（防火墻，DPI，caching，HTTP包頭豐富）到訪問用戶的流量上。這些服務(wù)可能是由一個路由器的服務(wù)卡提供，也可能是有物理服務(wù)組件或者云中的虛擬物理組件實現(xiàn)。

SDN系統(tǒng)用于創(chuàng)建和管理虛擬或者物理的服務(wù)，并且創(chuàng)建服務(wù)鏈，為訪問用戶的流量形成服務(wù)的流量鏈，這些可以基于本地的配置但是更多是通過一個集中的策略服務(wù)器來完成。

4.2.2?服務(wù)案例-虛擬CPE

在寬帶接入網(wǎng)絡(luò)中，每一個接入訪問者會被提供一個用戶前端設(shè)備（CPE）-通常是多業(yè)務(wù)服務(wù)器。運維者希望這些CPE可以提供更多的功能以便和OTT廠商競爭，但是這又面臨挑戰(zhàn)，因為

• CPE廠家增加新功能緩慢，硬件功能增加有限，（為實現(xiàn)新功能）替換設(shè)備又代價昂貴。
• 諸多不同的CPE設(shè)備在網(wǎng)絡(luò)中又帶來功能支持的不一致性。

在虛擬CPE使用案例中（也就是云CPE案例）運維者可以解決這些問題

• 使用簡單的CPE僅支持基本的二層和三層功能
• 虛擬化剩下的服務(wù)，在虛擬機(jī)中運行，或者集中式的運行在通用x86硬件上，被集中的協(xié)調(diào)和預(yù)留管理

基于服務(wù)器的虛擬CPE可以部署在不同的位置

• 附著在寬帶網(wǎng)關(guān)上
• 在BNG的服務(wù)卡上
• 在BNG和CPE的線卡上內(nèi)部支持
• 數(shù)據(jù)中心
• 綜合上面全部

5? OpenContrail系統(tǒng)和MPLS VPN的比較

如圖33所示，OpenContrail系統(tǒng)的架構(gòu)在很多方向上和MPLS VPN相似（另外一個類似的地方是，比較控制VM和路由引擎，比較虛擬路由器和線卡）

兩個架構(gòu)類似的地方包括

在OpenContrail系統(tǒng)的底層交換機(jī)類似于在MPLS VPN中的P路由器，OpenContrail系統(tǒng)使用MPLS over GRE 或者 VXLAN作為封裝協(xié)議，不需要底層交換機(jī)支持MPLS，唯一的對底層交換機(jī)的要求僅僅是知道如何把一個單播數(shù)據(jù)包從一個物理服務(wù)器到另外一個物理服務(wù) 器。

• OpenContrail系統(tǒng)中的虛擬路由器相當(dāng)于MPLS VPN中的PE路由器，和無力的PE路由器一樣，虛擬路由器中也包含多個路由實例
• OpenContrail系統(tǒng)中的VM相當(dāng)于MPLS VPN中的CE路由器，在OpenContrail系統(tǒng)中，不需要PE和CE之間的協(xié)議，因為CE路由可以通過其他機(jī)制被查找。（譯者注，因為相當(dāng)于是主機(jī)，所以靜態(tài)路由就好了）
• 在OpenContrail系統(tǒng)中MPLS over GRE隧道和VXLAN隧道相當(dāng)于MPLS VPN中的MPLS over MPLS
• OpenContrail系統(tǒng)中的XMPP協(xié)議綜合了MPLS VPN中的兩個協(xié)議的功能。
  • XMPP分發(fā)路由協(xié)議，類似于MPLS VPN中的IBGP
  • XMPP推送特定類型的配置（如路由實例），類似于MPLS VPN中的DMI（Device Manageability Instrumentation）
  • OpenContrail系統(tǒng)提供三個功能
    • 集中控制，類似于MPLS VPN中BGP的RR
    • 管理，向虛擬路由器的配置下發(fā)，類似于MPLS VPN中NMSAnalytics.分析
    • OpenContrail支持包括layer 3的overlay，等同于MPLS L3 VPN，也支持Layer 2的overlay，等同于MPLS EVPN。

6 Acronyms

Acronym

Meaning

AD

Administrative Domain

API

Application Programming Interface

ASIC

Application Specific Integrated Circuit

ARP

Address Resolution Protocol

BGP

Border Gateway Protocol

BNG

Broadband Network Gateway

BSN

Broadband Subscriber Network

BSS

Business Support System

BUM

Broadcast, Unknown unicast, Multicast

CE

Customer Edge router

CLI

Command Line Interface

COTS

Common Off The Shelf

CPE

Customer Premises Equipment

CSP

Cloud Service Provider

CO

Central Office

CPU

Central Processing Unit

CUG

Closed User Group

DAG

Directed Acyclic Graph

DC

Data Center

DCI

Data Center Interconnect

DHCP

Dynamic Host Configuration Protocol

DML

Data Modeling Language

DNS

Domain Name System

DPI

Deep Packet Inspection

DWDM

Dense Wavelength Division Multiplexing

EVPN

Ethernet Virtual Private Network

FIB

Forwarding Information Base

GLB

Global Load Balancer

GRE

Generic Route Encapsulation

GUI

Graphical User Interface

HTTP

Hyper Text Transfer Protocol

HTTPS

Hyper Text Transfer Protocol Secure

IaaS

Infrastructure as a Service

IBGP

Internal Border Gateway Protocol

IDS

Intrusion Detection System

IETF

Internet Engineering Task Force

IF-MAP

Interface for Metadata Access Points

IP

Internet Protocol

IPS

Intrusion Prevention System

IPVPN

Internet Protocol Virtual Private Network

IRB

Integrated Routing and Bridging

JIT

Just In Time

KVM

Kernel-Based Virtual Machines

LAN

Local Area Network

L2VPN

Layer 2 Virtual Private Network

LSP

Label Switched Path

MAC

Media Access Control

MAP

Metadata Access Point

MDNS

Multicast Domain Naming System

MPLS

Multi-Protocol Label Switching

NAT

Network Address Translation

Netconf

Network Configuration

NFV

Network Function Virtualization

NMS

Network Management System

NVO3

Network Virtualization Overlays

OS

Operating System

OSS

Operations Support System

P

Provider core router

PE

Provider Edge router

PIM

Protocol Independent Multicast

POP

Point of Presence

QEMU

Quick Emulator

REST

Representational State Transfer

RI

Routing Instance

RIB

Routing Information Base

RSPAN

Remote Switched Port Analyzer

(S,G)

Source Group

SDH

Synchronous Digital Hierarchy

SDN

Software Defined Networking

SONET

Synchronous Optical Network

SP

Service Provider

SPAN

Switched Port Analyzer

SQL

Structured Query Language

SSL

Secure Sockets Layer

TCG

Trusted Computer Group

TE

Traffic Engineering

TE-LSP

Traffic Engineered Label Switched Path

TLS

Transport Layer Security

TNC

Trusted Network Connect

UDP

Unicast Datagram Protocol

VAS

Value Added Service

vCPE

Virtual Customer Premises Equipment

VLAN

Virtual Local Area Network

VM

Virtual Machine

VN

Virtual Network

VNI

Virtual Network Identifier

VXLAN

Virtual eXtensible Local Area Network

WAN

Wide Area Network

XML

Extensible Markup Language

XMPP

eXtensible Messaging and Presence Protocol

7 References

[AWS]?Amazon Web Services.?http://aws.amazon.com/

[AWS-EC2]?Amazon Eleastic Compute Cloud (Amazon EC2)?http://aws.amazon.com/ec2/

[AWS-EC2-EIP]?Amazon EC2 Elastic IP Address.?http://aws.amazon.com/articles/1346

[AWS-EC2-INSTANCE-ADDRESSING]?Amazon EC2 Instance IP Addressing.http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html

[AWS-VPC]?Amazon Virtual Private Cloud (Amazon VPC).?http://aws.amazon.com/vpc/

[AWS-VPC-SUBNETS]?Amazon Virtual Private Cloud Subnets.http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

[cassandra]?Apache Cassandra website.?http://cassandra.apache.org/

[draft-rfernando-virt-topo-bgp-vpn]?“Virtual Service Topologies in BGP VPNs.”?IETF Internet Draft draft-rfernando-virt-topo-bgp-vpn.https://datatracker.ietf.org/doc/draft-rfernando-virt-topo-bgp-vpn/

[draft-mahalingam-dutt-dcops-vxlan]?“VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks.”IETF Internet Draft draft-mahalingam-dutt-dcops-vxlan.?https://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/

[draft-marques-l3vpn-mcast-edge]?“Edge Multicast Replication for BGP IP VPNs.”?IETF Internet Draft draft-marques-l3vpn-mcast-edge.?https://datatracker.ietf.org/doc/draft-marques-l3vpn-mcast-edge/

[draft-ietf-l3vpn-end-system]?“BGP-signaled end-system IP/VPNs.”?IETF Internet Draft draft-ietf-l3vpn-end-system.https://datatracker.ietf.org/doc/draft-ietf-l3vpn-end-system/

[draft-raggarwa-sajassi-l2vpn-evpn]?“BGP MPLS Based Ethernet VPN.”?IETF Internet Draft draft-raggarwa-sajassi-l2vpn-evpn.https://datatracker.ietf.org/doc/draft-raggarwa-sajassi-l2vpn-evpn/

[ietf-xmpp-wg]?IETF XMPP working group.?http://datatracker.ietf.org/wg/xmpp/

[if-map]?if-map.org website.?http://www.if-map.org/

[juniper-why-overlay]?“Proactive Overlay versus Reactive End-to-End.”?Juniper Networks.http://www.juniper.net/us/en/local/pdf/whitepapers/2000515-en.pdf

[redis]?Redis website.?http://redis.io/

[RFC4023]?“Encapsulating MPLS in IP or Generic Routing Encapsulation.”?IETF RFC4023.?http://tools.ietf.org/html/rfc4023

[RFC4271]?“A Border Gateway Protocol 4 (BGP-4).”?IETF RFC4271.?http://www.ietf.org/rfc/rfc4271.txt

[RFC4364]?“BGP/MPLS IP Virtual Private Networks (VPNs).”?IETF RFC4364.?http://tools.ietf.org/html/rfc4364

[RFC6513]?“Multicast in BGP/MPLS VPNs.”?IETF RFC6513.?http://tools.ietf.org/html/rfc6513

[snort]?Snort Website.?http://www.snort.org/

[snort-rules-intro]?“A Brief Introduction to Snort Rules.”??The Security Analysts.?http://www.secanalyst.org/2010/05/27/a-brief-introduction-to-snort-rules/

[xmpp]?XMPP.org Website.?http://xmpp.org/

[zookeeper]?Apache Zookeeper website.?http://zookeeper.apache.org/

轉(zhuǎn)載于:https://www.cnblogs.com/liuhongru/p/11134475.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的[转]OpenContrail 体系架构文档的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。