計算、存儲和網絡,奠定了當今云計算格局的三足鼎立之勢。
計算通過虛擬化CPU、Disk、Memory等硬件來獲得高效的應用;存儲通過諸如Glusterfs、Ceph等分布式文件系統,提供了眾多特性的功能。而相對于,計算和存儲兩方面的成熟與穩定,網絡一直以其在穩定、效率、設計等方面,而備受人們愛之、痛之。
隨著物聯網和云計算的蓬勃發展,網絡作為信息傳輸的橋梁,其地位和重要性只會愈加凸顯。從另一種角度而言,鑒于Neutron的整個生態環境。這里我們將扼要淺析OpenStack Neutron中的那些前沿技術,或者說是非主流技術,從某種角度而言,它們代表了虛擬網絡服務的一些發展趨勢。
一、OpenvSwitchOVN項目
OVS團隊于2015年1月推出了C語言傾向的OVN項目,由VMWARE公司主導,旨在提高基于OpenvSwitch的OpenStack網絡方案的擴展性和易用性。
OVN體系架構,如下圖所示:
該項目用于給OVS這款在OpenStack項目中廣泛使用的虛擬交換機引入一個輕量級的控制平面,即類似于SDN控制器,致力于提高基于OVS的OpenStack網絡方案的擴展性和易用性,同時也為分布式路由等走捷徑似的轉發提供了可能性。
OpenvSwitch OVN項目將租戶的概念引入了OVS,正式向neutron方向發展。提供對L2/L3網絡虛擬化的支持。從目前的趨勢來看,neutron及 openstack最好的歸宿就是將精力集中于微內核,提供北向REST API建立生態圈,擴展的Service實現可以由第三方公司自己來做。
參看更加詳盡的PDF資料。
二、SDN Controller
典型的,SDN控制器的核心是實現集中控制平面(注:難道分布式控制不好嗎,為什么很多人一直在強調集中控制呢,這不是與SDN東西向擴展理念背道而馳嗎?大家如何看待呢!)和數據轉發平面的相分離。這里強調兩個,控制器和交換機的接口——我們叫做南向接口;另一個是往上的北向接口。
SDN的核心理念有三個,第一個控制和轉發分離,第二個集中控制,第三個開放的API——網絡可編程。
OpenStack平臺中應用的SDN技術已經成為了云環境中的網絡支柱,OpenStack的Neutron本身作為一個SDN網絡控制系統,在網絡配置方面提供了一種自服務能力,用戶可以創建自己的網絡并控制流量,實現連接服務器和設備到一個或多個網絡。基于Neutron的SDN技術,OpenStack網絡實現了一個可擴展的框架,并能部署和管理多種網絡服務,如入侵檢測系統(IDS),負載均衡,防火墻和虛擬專用網絡(VPN)等。
SDN技術在云計算中的核心作用不言而喻,鑒于當前業界SDN控制器如此繁多,這里,我們僅羅列出與openstack Neutron相關聯的開源控制器來。
主要有:OpenContrail、ONOS、Floodlight、Ryu、OpenDaylight項目等,它們都有各自的特點。關于這些控制器的具體講解,不在本文范疇內,請按需Google之。
值得注意的是,SDN中除了大名鼎鼎的OpenFlow協議之外,還有用于解決控制平面路由及計算的Routeflow協議。
三、Neutron DVR
相比較于其他一些前沿的非主流技術,DVR(分布式虛擬路由)應該算是玩家們所耳熟的一個項目了。為什么說是耳熟,而非能手呢。即在于,大部分人是通過看理論資料來認識它的,從實踐角度參與的人可真不多。
從實用主義角度而言,它也是一種非主流技術,且顯得太過于復雜。但由于,DVR本身作為社區為Neutron開發的一個子項目,這里,我們不能不提及。
需要特別指出的是,由于DVR是三層的路由轉換服務,所以僅適用于VXLAN、GRE等網絡模式場景中,而VLAN等并不適用。
DVR的核心作用是,通過Neutron的東西向橫向流量擴展,將L3-Agent同時分布于網絡節點和計算節點上,減輕網絡節點的L3性能瓶頸/流量集中,實現負載均衡等。并通過其他第三方軟件,來實現L3 Agent的高可用。
當某個租戶建立了一個路由的時候,如果某臺主機上存在其路由所連接子網的虛機,那么這臺主機上就會建立一個路由。所有的東西向流量都會由這個路由進行轉發而不是通過網絡節點進行轉發。如果虛擬機有浮動IP的話,所有的南北向流量也會由這個路由器進行轉發而不是由網絡節點進行轉發。只有沒有浮動IP的虛機訪問外網的時候,會通過SNAT走網絡節點進行轉發。
通過使用 DVR,三層的轉發和 NAT 功能都會被分布到計算節點上,這意味著計算節點也有了網絡節點的功能。但是,DVR 依然不能消除集中式的 Virtual Router,這是為了節省寶貴的 IPV4 公網地址,所以依然將 SNAT 放在網絡節點上提供。這樣,計算和網絡節點就看起來如下:
網絡節點:提供南-北 SNAT,即在不使用浮動 IP 時,虛機訪問外網的網絡得經過網絡節點。也就是說,網絡節點依然必須走傳統的 HA 解決方法,比如 VRRP 和PeaceMaker。
計算節點:提供南-北 DNAT,即外網訪問虛機的網絡流量得經過計算節點;以及東-西轉發,即虛機之間的網絡經過計算節點。因為所有計算節點的參與,這部分的網絡負載也就自然地被均衡了。
參看更加詳盡的DVR資料。
四、Dragonflow
Dragonflow作為Neutron最新的子項目之一,由華為以色列技術團隊提出,于2015年開始提交代碼,目前已經成為OpenStack的孵化項目。
Dragonflow和DVR,倒是像一對近親。從設計和理念等角度而言,都與DVR極為相似,可以說,Dragonflow是DVR的升級版或補充版。
Dragonflow的設計比較符合一個標準的Neutron擴展,通過Plugin來實現API,通過L2 Agent和L3 Agent分別實現功能。
在Dragonflow模式中,Service的實現方式是一樣的(service plugin)。它把Network節點由單純的網絡節點(走SNAT流量)改成了Neutron Controller Agent。Neutron Controller Agent相當于傳統SDN方案的網絡控制器,更準確的說是三層的SDN控制器。計算節點上跑的還是L2 Agent。在原來DVR的模式下,網絡節點要跑L3 Agent,現在就不需要了。Dragonflow改成了純粹用OpenFLow去控制三層流量的方式。
Dragonflow實現了Neutron的L3 Service API,還為Neutron提供了分布式虛擬路由器功能。從設計理念上講,Dragonflow使用的是可插入式無狀態化輕量級SDN控制器,實現了租戶子網間(東-西)流量的完全分布化,避開了網絡節點,減小了故障域,避免單點故障。
按照Dragonflow的設計理念,它可以提升OpenStack Neutron L3的可擴展性、性能和可靠性。它可以支持數千個計算節點,為實現動態增長而保持控制器的無狀態化,沒有中央瓶頸,通過避免使用iptables和命名空間減少計算節點開銷。
參看更加詳盡的dragonflow資料。
五、OpenContrail
OpenContrail是由瞻博網絡公司開源的網絡虛擬化和智能化解決方案,包含所有用于創建虛擬覆蓋網絡的組件:SDN控制器、vRouter 和分析引擎。當進行網絡配置時,Contrail是連接物理網絡與虛擬環境、配置底層服務、減少時間、降低成本和風險的一種簡便方法。
和VMware NSX相似的是,OpenContrail對通用路由封裝(GRE)或虛擬可擴展局域網(VXLAN)技術提供了技術支撐。另一方面,OpenContrail也和NSX方案一樣能夠控制網絡設備硬件。兩個平臺方案的根本區別在于兩者與編排系統的連接方式。OpenContrail 被設計為能夠在OpenStack云管理平臺上工作,而NSX是和Vmware的云自動化中心(vCAC)相連。
值得注意的是,OpenContrail通過一種分布式哈希表(DHT)NoSQL方式來訪問數據庫以防止單點失敗。
OpenContrail系統由兩個主要部件組成:OpenContrail控制器和OpenContrail虛擬路由器
OpenContrailvRouter(虛擬路由器)是一個轉發平面(或者是分布部署的路由器),運行在虛擬服務器的hypervisor,將一個數據中心的物理路由器和交換機擴展成一個虛擬的overlay網絡,OpenContrail虛擬路由器從概念上和開源的OVS很像,但是他會提供路由以及更高層的服務(使用vRouter替代vSwitch)。
OpenContrail控制器提供了系統的邏輯集中控制平面和管理平面,并且協調管理vRouter。該控制器是一個邏輯上集中但是物理上分布的SDN控制器,為虛擬網絡提供管理、控制和分析功能。
參看更詳盡的OpenContrail資料。
六、Midonet
MidoNet項目由日本Midokura公司開源,MidoNet是一款網絡虛擬化軟件,其基于底層物理設備來實現網絡虛擬化,具有分布式、分散、多層次的特點。主要作為OpenStack系統中的默認網絡組件,提供虛擬網絡解決方案,為云平臺如OpenStack服務。MidoNet是類似于 OpenContrail, Neutron DVR, DragonFlow, OVN的SDN產品
Midonet網絡解決方案,實現了很多企業級的特性,比如BGP的支持、Tunnel Zone、DoS抵御隔離的支持等。
Midonet充分借助了已有成熟的分布式軟件降低自己本身的復雜性,而且只使用了OpenvSwitch的Datapath模塊,使轉發和控制更加靈活,不失為一個好的設計。但是其企業級服務還需要定制,對社區的部分高級功能也支持有限,這也是它的缺點。
Midokura沒有開源MidoNet GUI部分的代碼。而GUI將作為企業版MidoNet的一部分。企業版MidoNet(MEM,Midokura Enterprise MidoNet)包括了MidoNet管理工具和集成了VMware的vSphere技術及第三方管理工具,此外還包括OpenStack發行認證等服務和支持等。
參看更詳盡的資料。
七、結語
基于眾所周知的原因,在生產環境上,基于上訴技術的使用,大多仍處于研究階段。
眾多的廠商舉著擁抱開源、擁抱OpenStack的旗幟,同時提供自己的產品,進行盈利。一方面因為利益的分歧,導致了Neutron的發展顯得相對混亂,遲滯了其規范化、協調發展。另一方面,通過提供開源或商用產品,也為OpenStack的虛擬網絡服務,提供了更多的選擇和發展。
作者簡介:
徐超:2015——至今,任職于九州云信息科技有限公司(上海),從事OpenStack相關工作。個人傾向于研究OpenStack、SDN和Docker。