嘉賓介紹

　　閆國旗，就職于京東集團，任資深系統架構師，主要負責京東集團的基礎服務建設，專注于數據庫、分布式計算、SDN、網絡安全等技術領域。

　　先簡單介紹一下Nova-Network和Neutron。

　　Nova-Network

　　Nova-Network是Openstack在Folsom版本之前的網絡解決方案，做為Compute項目(Nova)的子模塊之一。支持Flat Network，Flat DHCP Network，VLAN Network等網絡模型，利用到的主要技術有linux-bridge，vlan等。

　　Neturon

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

　　在Havana版本之后，由于商標問題從Quantum更名為Neturon。支持Local Network，VLAN Network，GRE Network，VXLAN Network等網絡模型。利用到的主要技術有linux-bridge，ovs，vxlan，gre，vlan，openflow等。

　　目前Openstack已經Release了Kilo版本，Neturon在經歷了7個大版本后，已經做了相當多的改善。Neturon本質上就是Nova-Network后續的升級版本。

　　Nova-Network的網絡模式相對較為簡單，Flat和FlatDHCP都是通過統一的IP池，對VM進行IP分配，不同的是IP分配的手段。

　　該兩種模式沒有實現任何隔離功能，在此類場景下僅能通過安全組等手段進行網絡層面的隔離，適合規模較小，網絡拓撲不經常變化，且對網絡隔離不嚴格要求的場景。

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

　　在Neturon的實現中，包括：

　　1.控制節點

　　控制節點運行Neturon Server，早期僅僅是用于維護數據庫中網絡相關的信息。

　　2.網絡節點

　　網絡節點運行L3 Agent。在DVR模式下，計算節點和網絡節點分別要運行L3 Agent和L3 NAT Agent。

　　3.計算節點

　　計算節點和網絡節點根據所選擇的配置，還要運行相應的Plugin Agent。

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

　　DVR的實現，一定程度上降低了網絡節點的壓力，東西流量及部分南北流量(擁有Floating IP的VM)不再經過網絡節點，但網絡節點仍然存在瓶頸。

　　Dragonflow在網絡節點上運行Openflow控制器，對L3流量進行調度，不再需要L3 Agent。

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

　　1.替換網絡節點

　　Openstack最大的優勢就是開放，插件化設計，因此可以很容易將自己原有的產品集成進去。用成熟的硬件方案加上對應的插件，將網絡節點替換掉，現在很多廠商都已提供了成熟的解決方案。

　　2.網絡節點主從模式

　　在開啟DVR功能后，網絡節點主要的流量便是SNAT，通過VRRP和Conntrack Table同步，可以實現網絡節點的主備。目前社區的實現還不穩定，如果需要的話只能自行實現。

　　3.合并網絡節點

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

　　4.利用SDN

　　利用Openflow等協議的特性和相關實現，根據數據庫定義的網絡信息，對數據包包頭直接修改并路由，以此實現NAT、LB等網絡功能，便不在需要網絡節點對流量進行轉發，網絡節點上的其他功能也需要重新設計實現。

　　除了網絡節點是較為明顯的瓶頸，另一個我們再聊聊關于Overlay Network。

　　Overlay Network

　　其實Overlay Network已經很廣泛的應用了，例如我們每天用到的VPN協議，如PPTP，L2TP，MPLS，GRE等。

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

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

　　NVGRE和STT主要應用于Microsfot，VMware生態的產品上。

　　Geneva協議在kernel 3.18才提供，因此現在使用最多的便是VxLAN。

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

　　所以在Openstack中網絡組件的選擇，一定要明確你的業務場景。新版本Neturon有很多誘人的特性，但一定要經過嚴格的測試，才可應用。

　　網絡無小事，做網絡規劃和設計時一定要貼合你的業務，盡量做到簡單高效。 

　　精彩互動

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

　　目前京東私有云和公有云所面向的業務場景不同,所以網絡模型上的選擇也有所不同。

　　2.可以把流量直接引導物理交換上嗎?

　　目前新部署的機房節點都是接入萬兆，現在的網絡方案基本都是硬軟分離。硬件網絡只需要保證基礎網絡的正常轉發即可。

　　3.Cinder后端存儲目前你們覺得可以生產使用的有哪個?GlusterFS CEPH?

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

　　可能大家更多的還是保留了傳統的業務部署的習慣。

　　4.云平臺主要用于京東哪些業務?

　　京東私有云主要支撐整個京東集團的內部業務，京東公有云主要支撐京東生態的相關業務。

　　如何一起愉快地發展

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

　　提示：目前高效運維兩個微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國個人微信號 xiaotianguo 為好友，進行申請;或申請加入我們技術交流群(技術討論為主，沒有主群那么多規矩，更熱鬧)。

　　重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行及如下二維碼。