Nova-Network

Nova-Network是Openstack在Folsom版本之前的網(wǎng)絡(luò)解決方案，做為Compute項目（Nova）的子模塊之一。支持Flat Network，F(xiàn)lat DHCP Network，VLAN Network等網(wǎng)絡(luò)模型，利用到的主要技術(shù)有linux-bridge，vlan等。

Neturon

Neturon是Openstack的Folsom版本正式發(fā)布的，將網(wǎng)絡(luò)模塊從Compute中剝離出來，獨立發(fā)展。其實在Essex版本就已經(jīng)提供了試用，在Grizzly版本得到了一定的增強。

在Havana版本之后，由于商標(biāo)問題從Quantum更名為Neturon。支持Local Network，VLAN Network，GRE Network，VXLAN Network等網(wǎng)絡(luò)模型。利用到的主要技術(shù)有l(wèi)inux-bridge，ovs，vxlan，gre，vlan，openflow等。

目前Openstack已經(jīng)Release了Kilo版本，Neturon在經(jīng)歷了7個大版本后，已經(jīng)做了相當(dāng)多的改善。Neturon本質(zhì)上就是Nova-Network后續(xù)的升級版本。

Nova-Network的網(wǎng)絡(luò)模式相對較為簡單，F(xiàn)lat和FlatDHCP都是通過統(tǒng)一的IP池，對VM進行IP分配，不同的是IP分配的手段。

該兩種模式?jīng)]有實現(xiàn)任何隔離功能，在此類場景下僅能通過安全組等手段進行網(wǎng)絡(luò)層面的隔離，適合規(guī)模較小，網(wǎng)絡(luò)拓撲不經(jīng)常變化，且對網(wǎng)絡(luò)隔離不嚴格要求的場景。

VLAN模式需要在網(wǎng)絡(luò)設(shè)備進行VLAN配置，管理維護成本相對較高，且規(guī)模受VLANID寬度的限制，適合有一定隔離需求，但規(guī)模較小的場景。

在Neturon的實現(xiàn)中，包括：

1.控制節(jié)點

控制節(jié)點運行Neturon Server，早期僅僅是用于維護數(shù)據(jù)庫中網(wǎng)絡(luò)相關(guān)的信息。

2.網(wǎng)絡(luò)節(jié)點

網(wǎng)絡(luò)節(jié)點運行L3 Agent。在DVR模式下，計算節(jié)點和網(wǎng)絡(luò)節(jié)點分別要運行L3 Agent和L3 NAT Agent。

3.計算節(jié)點

計算節(jié)點和網(wǎng)絡(luò)節(jié)點根據(jù)所選擇的配置，還要運行相應(yīng)的Plugin Agent。

我們從東西流量和南北流量這兩個維度來看Neturon中的網(wǎng)絡(luò)流向，在Neturon早期沒有DVR功能的時候，無論南北流量還是東西流量，在網(wǎng)絡(luò)路徑上都要通過網(wǎng)絡(luò)節(jié)點進行轉(zhuǎn)發(fā)，顯而易見網(wǎng)絡(luò)節(jié)點成為了最嚴重的瓶頸，一旦網(wǎng)絡(luò)節(jié)點失效，其所覆蓋的網(wǎng)絡(luò)便癱瘓。

DVR的實現(xiàn)，一定程度上降低了網(wǎng)絡(luò)節(jié)點的壓力，東西流量及部分南北流量（擁有Floating IP的VM）不再經(jīng)過網(wǎng)絡(luò)節(jié)點，但網(wǎng)絡(luò)節(jié)點仍然存在瓶頸。

Dragonflow在網(wǎng)絡(luò)節(jié)點上運行Openflow控制器，對L3流量進行調(diào)度，不再需要L3 Agent。

回到這個問題的核心“高可用”上，這里首要解決的問題便是網(wǎng)絡(luò)節(jié)點的高可用，目前主流有以下幾種方法：

1.替換網(wǎng)絡(luò)節(jié)點

Openstack最大的優(yōu)勢就是開放，插件化設(shè)計，因此可以很容易將自己原有的產(chǎn)品集成進去。用成熟的硬件方案加上對應(yīng)的插件，將網(wǎng)絡(luò)節(jié)點替換掉，現(xiàn)在很多廠商都已提供了成熟的解決方案。

2.網(wǎng)絡(luò)節(jié)點主從模式

在開啟DVR功能后，網(wǎng)絡(luò)節(jié)點主要的流量便是SNAT，通過VRRP和Conntrack Table同步，可以實現(xiàn)網(wǎng)絡(luò)節(jié)點的主備。目前社區(qū)的實現(xiàn)還不穩(wěn)定，如果需要的話只能自行實現(xiàn)。

3.合并網(wǎng)絡(luò)節(jié)點

將網(wǎng)絡(luò)節(jié)點遷移至計算節(jié)點，把NAT功能在計算節(jié)點上實現(xiàn)，以此降低網(wǎng)絡(luò)節(jié)點失效的故障域。該解決方案需要進行大量的改造，還要消耗一定的計算能力用于網(wǎng)絡(luò)轉(zhuǎn)發(fā)，且維護管理成本較高。

4.利用SDN

利用Openflow等協(xié)議的特性和相關(guān)實現(xiàn)，根據(jù)數(shù)據(jù)庫定義的網(wǎng)絡(luò)信息，對數(shù)據(jù)包包頭直接修改并路由，以此實現(xiàn)NAT、LB等網(wǎng)絡(luò)功能，便不在需要網(wǎng)絡(luò)節(jié)點對流量進行轉(zhuǎn)發(fā)，網(wǎng)絡(luò)節(jié)點上的其他功能也需要重新設(shè)計實現(xiàn)。

除了網(wǎng)絡(luò)節(jié)點是較為明顯的瓶頸，另一個我們再聊聊關(guān)于Overlay Network。

Overlay Network

其實Overlay Network已經(jīng)很廣泛的應(yīng)用了，例如我們每天用到的VPN協(xié)議，如PPTP，L2TP，MPLS，GRE等。

在IaaS這個場景中，常見的隧道協(xié)議有以下幾種，VxLAN，NVGRE，GRE，Geneva，STT。

但GRE屬于L3oL3，且性能較差，使用較少，其他幾種都是L2oL3。

NVGRE和STT主要應(yīng)用于Microsfot，VMware生態(tài)的產(chǎn)品上。

Geneva協(xié)議在kernel 3.18才提供，因此現(xiàn)在使用最多的便是VxLAN。

VxLAN底層使用UDP協(xié)議進行承載，而傳統(tǒng)網(wǎng)絡(luò)對UDP的優(yōu)化較少，特別是在封包解包里需要一定的計算資源，現(xiàn)在采用較多的優(yōu)化方案是將這一部分計算遷移至硬件上。目前Mellanox的網(wǎng)卡已經(jīng)支持了VxLAN Offload，Intel最新的網(wǎng)卡也將支持這個新特性。

所以在Openstack中網(wǎng)絡(luò)組件的選擇，一定要明確你的業(yè)務(wù)場景。新版本Neturon有很多誘人的特性，但一定要經(jīng)過嚴格的測試，才可應(yīng)用。

網(wǎng)絡(luò)無小事，做網(wǎng)絡(luò)規(guī)劃和設(shè)計時一定要貼合你的業(yè)務(wù)，盡量做到簡單高效。?

精彩互動

1.京東采用的哪種方式？目前私有云vlan其實最合適了吧？

目前京東私有云和公有云所面向的業(yè)務(wù)場景不同，所以網(wǎng)絡(luò)模型上的選擇也有所不同。

2.可以把流量直接引導(dǎo)物理交換上嗎？

目前新部署的機房節(jié)點都是接入萬兆，現(xiàn)在的網(wǎng)絡(luò)方案基本都是硬軟分離。硬件網(wǎng)絡(luò)只需要保證基礎(chǔ)網(wǎng)絡(luò)的正常轉(zhuǎn)發(fā)即可。

3.Cinder后端存儲目前你們覺得可以生產(chǎn)使用的有哪個？GlusterFS CEPH？

京東的后端存儲并沒有用社區(qū)的方案，而是自行研發(fā)。而且這也引出了另外一個問題，在基于云的架構(gòu)中，塊存儲真的很有必要嗎？

可能大家更多的還是保留了傳統(tǒng)的業(yè)務(wù)部署的習(xí)慣。

4.云平臺主要用于京東哪些業(yè)務(wù)？

京東私有云主要支撐整個京東集團的內(nèi)部業(yè)務(wù)，京東公有云主要支撐京東生態(tài)的相關(guān)業(yè)務(wù)。

如何一起愉快地發(fā)展

“高效運維”公眾號（如下二維碼）值得您的關(guān)注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上/線下活動精彩分享及部分群友原創(chuàng)?！案咝н\維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。