1、 基于開(kāi)源SDN控制器的下一代金融云網(wǎng)絡(luò)方案 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66542877 基于開(kāi)源SDN控制器的下一代金融云網(wǎng)絡(luò)方案 PAGEREF _Toc66542877 h 1 HYPERLINK l _Toc66542878 一、行業(yè)發(fā)展歷程與技術(shù)發(fā)展趨勢(shì) PAGEREF _Toc66542878 h 3 HYPERLINK l _Toc66542879 （一）行業(yè)發(fā)展歷程 PAGEREF _Toc66542879 h 3 HYPERLINK l _Toc66542880 （二）技術(shù)發(fā)展趨勢(shì) PAGEREF _Toc66542880 h 3

2、 HYPERLINK l _Toc66542881 二、以金融云為載體的創(chuàng)新網(wǎng)絡(luò)需求 PAGEREF _Toc66542881 h 4 HYPERLINK l _Toc66542882 （一）金融云對(duì)網(wǎng)絡(luò)的創(chuàng)新需求 PAGEREF _Toc66542882 h 4 HYPERLINK l _Toc66542883 （二）金融私有云與行業(yè)云對(duì)網(wǎng)絡(luò)需求的異同分析 PAGEREF _Toc66542883 h 5 HYPERLINK l _Toc66542884 三、下一代金融云SDN網(wǎng)絡(luò)的設(shè)計(jì)原則與架構(gòu)規(guī)劃 PAGEREF _Toc66542884 h 6 HYPERLINK l _Toc6654

3、2885 （一）網(wǎng)絡(luò)設(shè)計(jì)原則 PAGEREF _Toc66542885 h 6 HYPERLINK l _Toc66542886 （二）網(wǎng)絡(luò)架構(gòu) PAGEREF _Toc66542886 h 7 HYPERLINK l _Toc66542887 四、基于ODL開(kāi)源控制器的數(shù)據(jù)中心內(nèi)SDN網(wǎng)絡(luò)方案研究與實(shí)現(xiàn) PAGEREF _Toc66542887 h 8 HYPERLINK l _Toc66542888 （一）銀聯(lián)SDN應(yīng)用研究現(xiàn)狀 PAGEREF _Toc66542888 h 8 HYPERLINK l _Toc66542889 （二）下一代金融云網(wǎng)絡(luò)軟件SDN網(wǎng)絡(luò)方案 PAGEREF _T

4、oc66542889 h 9 HYPERLINK l _Toc66542890 3.能力設(shè)計(jì) PAGEREF _Toc66542890 h 11 HYPERLINK l _Toc66542891 （三）基于OpenFlow流表的能力實(shí)現(xiàn) PAGEREF _Toc66542891 h 13 HYPERLINK l _Toc66542892 五、原型實(shí)踐與效果 PAGEREF _Toc66542892 h 29 HYPERLINK l _Toc66542893 （一）物理架構(gòu)概述 PAGEREF _Toc66542893 h 29 HYPERLINK l _Toc66542894 （二）管理控制平

5、面概述 PAGEREF _Toc66542894 h 30 HYPERLINK l _Toc66542895 （三）云網(wǎng)與云控平臺(tái)集成 PAGEREF _Toc66542895 h 30 HYPERLINK l _Toc66542896 （四）整體網(wǎng)絡(luò)架構(gòu) PAGEREF _Toc66542896 h 33 HYPERLINK l _Toc66542897 （五）效果展示 PAGEREF _Toc66542897 h 34 HYPERLINK l _Toc66542898 六、總結(jié)與展望 PAGEREF _Toc66542898 h 37 HYPERLINK l _Toc66542899 （一

6、）工作總結(jié) PAGEREF _Toc66542899 h 37 HYPERLINK l _Toc66542900 （二）展望 PAGEREF _Toc66542900 h 38本文介紹了下一代金融云SDN網(wǎng)絡(luò)的設(shè)計(jì)原則與架構(gòu)規(guī)劃，和基于ODL開(kāi)源控制器的數(shù)據(jù)中心內(nèi)SDN網(wǎng)絡(luò)方案研究與實(shí)現(xiàn)。一、行業(yè)發(fā)展歷程與技術(shù)發(fā)展趨勢(shì)（一）行業(yè)發(fā)展歷程金融數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)架構(gòu)與行業(yè)安全、合規(guī)等特色性要求緊密結(jié)合，是金融數(shù)據(jù)中心顯著區(qū)別與其他行業(yè)數(shù)據(jù)中心的關(guān)鍵領(lǐng)域，是金融數(shù)據(jù)中心建設(shè)中的核心。中國(guó)金融數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)的歷程與金融行業(yè)近三十年信息化過(guò)程密不可分，總結(jié)歸納金融數(shù)據(jù)中心網(wǎng)絡(luò)的發(fā)展主要經(jīng)歷了三個(gè)階段：第

7、一階段：專網(wǎng)專用階段。該階段是采用特有的網(wǎng)絡(luò)協(xié)議來(lái)對(duì)專用設(shè)備進(jìn)行連通，如IBM的專有網(wǎng)絡(luò)協(xié)議SNA對(duì)其大型機(jī)與中型機(jī)的支持；第二階段：基于IP協(xié)議，分層分區(qū)。在本階段采用了更為開(kāi)放通用的IP技術(shù)協(xié)議，不再受制于某個(gè)廠商，組網(wǎng)更加靈活。此外，本階段中雖然各金融機(jī)構(gòu)的網(wǎng)絡(luò)架構(gòu)跟隨應(yīng)用系統(tǒng)的發(fā)展而變化，但一般會(huì)出于應(yīng)用分層及安全的要求，遵循“垂直分層、水平分區(qū)”的理念。第三階段：大規(guī)模共享接入。技術(shù)上更為開(kāi)放，網(wǎng)絡(luò)虛擬化與SDN等技術(shù)開(kāi)始在金融行業(yè)應(yīng)用。在繼承安全區(qū)域保護(hù)機(jī)制下，采用“總線型、模塊化”架構(gòu)，中國(guó)的金融數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)趨于一致，并且普遍采用網(wǎng)絡(luò)虛擬化共享接入的技術(shù)方案，在新的云計(jì)算環(huán)境

8、下能夠?qū)W(wǎng)絡(luò)的靈活、彈性等要求進(jìn)行有效應(yīng)對(duì)。（二）技術(shù)發(fā)展趨勢(shì)近年來(lái)，隨著金融數(shù)據(jù)中心云化的加速，金融云作為最新的基礎(chǔ)設(shè)施形態(tài)開(kāi)始被行業(yè)認(rèn)同并接納。但在金融云環(huán)境下，傳統(tǒng)網(wǎng)絡(luò)技術(shù)架構(gòu)受到了挑戰(zhàn)：一方面虛擬化思想的出現(xiàn)，顛覆了原有的數(shù)據(jù)中心網(wǎng)絡(luò)模型，使得傳統(tǒng)網(wǎng)絡(luò)技術(shù)已不足以適配云環(huán)境下產(chǎn)生的新場(chǎng)景，如虛擬機(jī)的出現(xiàn)要求網(wǎng)絡(luò)顆粒度從物理機(jī)細(xì)化到了虛擬機(jī)級(jí)別；另一方面面向互聯(lián)網(wǎng)的金融創(chuàng)新業(yè)務(wù)的快速發(fā)展，也會(huì)對(duì)網(wǎng)絡(luò)的性能、彈性等特性提出更高的要求。所以未來(lái)金融數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)必將進(jìn)行變革式的創(chuàng)新發(fā)展，我們認(rèn)為未來(lái)發(fā)展趨勢(shì)主要包括以下三點(diǎn)：1、面向互聯(lián)網(wǎng)新興業(yè)務(wù)的敏捷網(wǎng)絡(luò)，即未來(lái)金融云網(wǎng)絡(luò)能夠高效滿足互聯(lián)

9、網(wǎng)方式下金融創(chuàng)新應(yīng)用的多樣化需求。一是網(wǎng)絡(luò)資源的快速提供與開(kāi)通，以支撐應(yīng)用的快速投產(chǎn)；二是強(qiáng)化細(xì)粒度的網(wǎng)絡(luò)策略管控能力，在應(yīng)用需求的頻繁變化的情況下，網(wǎng)絡(luò)能夠進(jìn)行靈活地變更調(diào)整；三是網(wǎng)絡(luò)可兼容多樣化的資源類型接入，以融合網(wǎng)絡(luò)方式實(shí)現(xiàn)虛擬機(jī)、容器、物理機(jī)不同資源的統(tǒng)一接入。2、面向數(shù)據(jù)中心資源動(dòng)態(tài)變化的彈性網(wǎng)絡(luò)，即在大流量挑戰(zhàn)下保證網(wǎng)絡(luò)的平穩(wěn)運(yùn)行。一是金融云規(guī)模巨大，承載業(yè)務(wù)系統(tǒng)眾多，要求網(wǎng)絡(luò)必須具備足夠的容量與健壯性，比如如何解決網(wǎng)絡(luò)規(guī)模快速增長(zhǎng)情況下存在廣播風(fēng)暴的風(fēng)險(xiǎn)；二、在營(yíng)銷活動(dòng)等訪問(wèn)量暴增的情況下，網(wǎng)絡(luò)能夠根據(jù)應(yīng)用重要性與鏈路情況實(shí)現(xiàn)對(duì)流量的智能調(diào)度，保證核心業(yè)務(wù)平穩(wěn)運(yùn)行；三則是在計(jì)算

10、資源不充足的情況下，網(wǎng)絡(luò)能夠連通分布在不同物理位置的計(jì)算資源池，打破由于物理區(qū)域隔離所造成的資源容量限制。3、面向數(shù)字化智能化運(yùn)維模式的網(wǎng)絡(luò)，即在網(wǎng)絡(luò)運(yùn)維壓力暴增的情況下，能夠做到先于業(yè)務(wù)發(fā)現(xiàn)網(wǎng)絡(luò)問(wèn)題。一方面，金融行業(yè)數(shù)據(jù)中心規(guī)模不斷擴(kuò)張，網(wǎng)絡(luò)終端數(shù)量與網(wǎng)絡(luò)模型復(fù)雜度都呈幾何式增長(zhǎng)，必須采用高效、出錯(cuò)率低自動(dòng)化運(yùn)維代替?zhèn)鹘y(tǒng)的手工方式；另一方面，在金融云的新常態(tài)下，網(wǎng)絡(luò)運(yùn)維模式需要形成閉環(huán)來(lái)提升自身價(jià)值，通過(guò)對(duì)流量數(shù)據(jù)的采集分析，實(shí)現(xiàn)對(duì)網(wǎng)絡(luò)的問(wèn)題預(yù)測(cè)、排障、優(yōu)化，甚至做到對(duì)網(wǎng)絡(luò)攻擊的規(guī)避，提升整體網(wǎng)絡(luò)的穩(wěn)定性。軟件定義網(wǎng)絡(luò)（SDN）技術(shù)通過(guò)分布式架構(gòu)理念，將網(wǎng)絡(luò)中數(shù)據(jù)平面與控制平面相分離，從而實(shí)

11、現(xiàn)了網(wǎng)絡(luò)流量的靈活控制，為核心網(wǎng)絡(luò)及應(yīng)用的創(chuàng)新提供了良好的平臺(tái)，其與金融云網(wǎng)絡(luò)發(fā)展趨勢(shì)相契合，是實(shí)現(xiàn)金融云網(wǎng)絡(luò)服務(wù)的有效支撐技術(shù)。二、以金融云為載體的創(chuàng)新網(wǎng)絡(luò)需求（一）金融云對(duì)網(wǎng)絡(luò)的創(chuàng)新需求基于上述金融云網(wǎng)絡(luò)的發(fā)展趨勢(shì)，結(jié)合金融業(yè)務(wù)面向互聯(lián)網(wǎng)的挑戰(zhàn)，我們認(rèn)為未來(lái)金融云網(wǎng)絡(luò)需求可總結(jié)為高安全、高敏捷、高性能、高可用、高彈性與高可管理：高安全，金融業(yè)務(wù)的特殊性對(duì)承載網(wǎng)絡(luò)的第一要求即為保證數(shù)據(jù)的安全性，因此金融云網(wǎng)絡(luò)必須具備能夠抵御系統(tǒng)外部攻擊，保證數(shù)據(jù)完備性與私密性的能力；高敏捷，實(shí)現(xiàn)業(yè)務(wù)快速上線，面對(duì)應(yīng)用的變化達(dá)到資源的按需變更，通過(guò)新技術(shù)應(yīng)用打破因重安全而舍效率的困局，在云計(jì)算新環(huán)境下安全與高

12、效并重；高性能，面對(duì)秒殺等新業(yè)務(wù)場(chǎng)景等的極限服務(wù)能力，實(shí)現(xiàn)時(shí)延和帶寬等關(guān)鍵指標(biāo)的跨越式提升，同時(shí)注重資源的高效利用，用盡可能少的資源實(shí)現(xiàn)最大的性能服務(wù)。高可用，網(wǎng)絡(luò)架構(gòu)持續(xù)穩(wěn)定影響金融數(shù)據(jù)中心全局服務(wù)能力，網(wǎng)絡(luò)架構(gòu)需要基于穩(wěn)定可靠的技術(shù)構(gòu)建，使網(wǎng)絡(luò)服務(wù)具備7*24小時(shí)業(yè)務(wù)連續(xù)性服務(wù)的能力；高彈性，一是內(nèi)部彈性強(qiáng)化，打破豎井式架構(gòu)中網(wǎng)絡(luò)區(qū)域成為限制資源共享的壁壘，實(shí)現(xiàn)網(wǎng)絡(luò)資源池整合與靈活共享與隔離，二是外部彈性兼容，支持新老架構(gòu)并存，從而使原有網(wǎng)絡(luò)可以平滑過(guò)渡到新架構(gòu)；高可管理，一是實(shí)現(xiàn)管理的體系的簡(jiǎn)化，支持多品牌的融合管理，二是實(shí)現(xiàn)管理自動(dòng)化與智能化，提供端到端的業(yè)務(wù)可視和故障快速定位、排查能

13、力，使日常運(yùn)維從大量人工維護(hù)的高工作量解放出來(lái)；（二）金融私有云與行業(yè)云對(duì)網(wǎng)絡(luò)需求的異同分析雖然金融私有云與行業(yè)云本質(zhì)上都承載金融業(yè)務(wù)，但是由于應(yīng)用場(chǎng)景與服務(wù)模式上的不同，也使得金融私有云與行業(yè)云對(duì)網(wǎng)絡(luò)的需求有所差異。在表1中，我們基于上面提出網(wǎng)絡(luò)需求的6個(gè)維度，對(duì)金融私有云與行業(yè)云網(wǎng)絡(luò)需求的異同進(jìn)行分析。表1 金融私有云與行業(yè)云對(duì)網(wǎng)絡(luò)需求的異三、下一代金融云SDN網(wǎng)絡(luò)的設(shè)計(jì)原則與架構(gòu)規(guī)劃（一）網(wǎng)絡(luò)設(shè)計(jì)原則SDN技術(shù)的應(yīng)用顛覆式地改變了金融數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，因此基于對(duì)網(wǎng)絡(luò)發(fā)展趨勢(shì)與具體需求的分析，在云環(huán)境下構(gòu)建新一代的SDN網(wǎng)絡(luò)需進(jìn)行針對(duì)性的設(shè)計(jì)。據(jù)此我們提出了以下三條設(shè)計(jì)原則：1.根據(jù)不同網(wǎng)

14、絡(luò)邊界分層構(gòu)建網(wǎng)絡(luò)資源池從能力層面來(lái)看，網(wǎng)絡(luò)作為一種基礎(chǔ)設(shè)施資源，應(yīng)構(gòu)建統(tǒng)一的云網(wǎng)絡(luò)資源池，打破傳統(tǒng)網(wǎng)絡(luò)豎井式架構(gòu)，提升計(jì)算、存儲(chǔ)資源調(diào)用的靈活性；從管理與安全層面看的話，因?yàn)椴煌W(wǎng)絡(luò)區(qū)域能力不同，在數(shù)據(jù)中心網(wǎng)絡(luò)中的角色不同，所以應(yīng)根據(jù)對(duì)不同網(wǎng)絡(luò)區(qū)域分別構(gòu)建資源池。2.網(wǎng)絡(luò)能力全部服務(wù)化實(shí)現(xiàn)面向服務(wù)理念，對(duì)每層網(wǎng)絡(luò)功能以服務(wù)、標(biāo)準(zhǔn)API接口的形式對(duì)外提供，網(wǎng)絡(luò)系統(tǒng)內(nèi)部以服務(wù)的形式進(jìn)行自組織，從而提升對(duì)外服務(wù)能力，簡(jiǎn)化外部調(diào)用網(wǎng)絡(luò)能力的復(fù)雜性；3.網(wǎng)絡(luò)資源統(tǒng)一編排管理數(shù)據(jù)中心內(nèi)網(wǎng)絡(luò)二/三層連通、四/七層功能的管理界面統(tǒng)一視圖，不同網(wǎng)絡(luò)資源池的管理采用二級(jí)管理編排方式，即底層適配不同網(wǎng)絡(luò)資源池管理

15、操作、上層異構(gòu)協(xié)調(diào)編排。（二）網(wǎng)絡(luò)架構(gòu)根據(jù)上述網(wǎng)絡(luò)設(shè)計(jì)原則，我們規(guī)劃了金融數(shù)據(jù)中心的整體網(wǎng)絡(luò)架構(gòu)如下圖1所示。圖1 金融數(shù)據(jù)中心整體網(wǎng)絡(luò)架構(gòu)首先，我們根據(jù)數(shù)據(jù)中心網(wǎng)絡(luò)構(gòu)成，將整體網(wǎng)絡(luò)分成了三個(gè)部分，具體如下：1.區(qū)域網(wǎng)絡(luò)，也就是我們常說(shuō)的一個(gè)云平臺(tái)Region的網(wǎng)絡(luò)，業(yè)務(wù)系統(tǒng)就運(yùn)行在該區(qū)域內(nèi)。其網(wǎng)絡(luò)方案可分為硬件方案和軟件方案。網(wǎng)絡(luò)設(shè)備包括區(qū)域交換機(jī)、區(qū)域內(nèi)控制器、負(fù)載均衡；2.核心網(wǎng)，核心網(wǎng)就是連通各個(gè)區(qū)域的網(wǎng)絡(luò)，主要設(shè)備包括核心交換機(jī)；3.數(shù)據(jù)中心網(wǎng)絡(luò)，其實(shí)稱為數(shù)據(jù)中心外聯(lián)網(wǎng)絡(luò)可能更準(zhǔn)確一些，負(fù)責(zé)數(shù)據(jù)中心與外部網(wǎng)絡(luò)的連通，其與外部骨干網(wǎng)連接，主要設(shè)備包括邊緣路由器。網(wǎng)絡(luò)分區(qū)確定后，隨后就根

16、據(jù)各個(gè)分區(qū)的能力邊界構(gòu)建各自的網(wǎng)絡(luò)資源池，并對(duì)各個(gè)資源池能力進(jìn)行標(biāo)準(zhǔn)的API接口化實(shí)現(xiàn)。最后，在頂層設(shè)計(jì)一個(gè)統(tǒng)一的網(wǎng)絡(luò)能力編排系統(tǒng)，將各個(gè)資源池的能力通過(guò)API對(duì)接的方式進(jìn)行上收，隨后根據(jù)權(quán)限配置將不同網(wǎng)絡(luò)區(qū)域的能力下放至相應(yīng)的管理員與應(yīng)用系統(tǒng)。四、基于ODL開(kāi)源控制器的數(shù)據(jù)中心內(nèi)SDN網(wǎng)絡(luò)方案研究與實(shí)現(xiàn)SDN方案分為硬件和軟件兩大類。硬件SDN是采用專用的硬件交換設(shè)備與控制器來(lái)實(shí)現(xiàn)相關(guān)的網(wǎng)絡(luò)功能，控制器對(duì)硬件設(shè)備進(jìn)行策略以及流表的下發(fā)，來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)相關(guān)的功能。它的優(yōu)點(diǎn)是性能強(qiáng)，比較穩(wěn)定，缺點(diǎn)是不靈活且組網(wǎng)成本很高。業(yè)界常見(jiàn)的硬件方案包括思科的ACI，華為AC、華三VCF等。而在軟件SDN的解決

17、方案中，網(wǎng)絡(luò)的功能是通過(guò)軟件層面的Linux協(xié)議棧以及相關(guān)的虛擬交換機(jī)技術(shù)實(shí)現(xiàn)的。它的優(yōu)點(diǎn)可以避免對(duì)硬件網(wǎng)絡(luò)設(shè)備的過(guò)度依賴，同時(shí)降低了組網(wǎng)的成本，缺點(diǎn)是穩(wěn)定性、性能和可擴(kuò)展性不如硬件方案。常用的軟件方案包括Neutron+OpenvSwitch、OpenDayLight+OpenvSwitch等。下面對(duì)銀聯(lián)當(dāng)前對(duì)SDN應(yīng)用研究的現(xiàn)狀進(jìn)行介紹。（一）銀聯(lián)SDN應(yīng)用研究現(xiàn)狀中國(guó)銀聯(lián)自2014年啟動(dòng)軟件定義網(wǎng)絡(luò)（SDN）技術(shù)在金融云環(huán)境下的應(yīng)用研究，長(zhǎng)期跟蹤SDN技術(shù)在國(guó)內(nèi)外金融行業(yè)的研究進(jìn)展，并積極推動(dòng)SDN技術(shù)在銀聯(lián)生產(chǎn)環(huán)境的應(yīng)用以及與銀行金融機(jī)構(gòu)的合作研究。目前，銀聯(lián)對(duì)SDN軟硬方案的研究測(cè)試

18、工作均已完成，兩套方案全部落地生產(chǎn)。銀聯(lián)私有生產(chǎn)云采用華為SDN整體硬件方案，銀聯(lián)生產(chǎn)托管云則采用Neutron+OpenvSwitch的軟件SDN方案。當(dāng)前實(shí)現(xiàn)了網(wǎng)絡(luò)二/三層、負(fù)載均衡、防火墻等多網(wǎng)絡(luò)資源服務(wù)，承載了近期銀聯(lián)與相關(guān)合作金融機(jī)構(gòu)的關(guān)鍵應(yīng)用，有效支撐了銀聯(lián)業(yè)務(wù)創(chuàng)新。當(dāng)前，銀聯(lián)結(jié)合當(dāng)前生產(chǎn)現(xiàn)狀與行業(yè)技術(shù)發(fā)展趨勢(shì)，開(kāi)展下一代金融SDN相關(guān)技術(shù)研究工作。目前主要針對(duì)金融數(shù)據(jù)中心區(qū)域內(nèi)的軟件SDN方案進(jìn)行進(jìn)一步研究?jī)?yōu)化，從而滿足下一代金融云的網(wǎng)絡(luò)要求。下圖2中的紅色范圍即為本次研究工作的定位。圖2 本次研究工作定位示意圖（二）下一代金融云網(wǎng)絡(luò)軟件SDN網(wǎng)絡(luò)方案1.方案設(shè)計(jì)與實(shí)現(xiàn)思路圖3

19、整體方案能力設(shè)計(jì)與實(shí)現(xiàn)思路圖（1）首先在對(duì)方案的能力設(shè)計(jì)上，我們結(jié)合了當(dāng)前金融數(shù)據(jù)中心針對(duì)軟件SDN方案的需求來(lái)進(jìn)行規(guī)劃，主要圍繞三點(diǎn)：首先性能是軟件SDN方案較硬件方案來(lái)說(shuō)比較明顯的短板，在性能上我們從兩個(gè)層面上進(jìn)行優(yōu)化。一是要簡(jiǎn)化物理機(jī)內(nèi)部的網(wǎng)流轉(zhuǎn)發(fā)路徑，如Neutron方案下物理機(jī)內(nèi)部的網(wǎng)橋有三層，過(guò)多的網(wǎng)橋數(shù)量勢(shì)必減緩對(duì)網(wǎng)絡(luò)數(shù)據(jù)的處理速度，所以要簡(jiǎn)化；二是要優(yōu)化物理機(jī)外部的網(wǎng)流轉(zhuǎn)發(fā)路徑，如Neutron方案下所有跨網(wǎng)段通信的流量全部要繞至專門的網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行路由轉(zhuǎn)發(fā)，給性能帶來(lái)較大的影響。然后是金融行業(yè)著重關(guān)注的穩(wěn)定性上，我們也有相關(guān)的能力設(shè)計(jì)考慮。一是由于節(jié)點(diǎn)數(shù)量的規(guī)模快速增長(zhǎng)所導(dǎo)致的

20、廣播風(fēng)暴會(huì)對(duì)網(wǎng)絡(luò)造成極大的損傷，因此本方案中將會(huì)針對(duì)該問(wèn)題進(jìn)行解決；二是優(yōu)化網(wǎng)流路徑，精簡(jiǎn)網(wǎng)流數(shù)據(jù)的處理節(jié)點(diǎn)，進(jìn)一步減少網(wǎng)流轉(zhuǎn)發(fā)中存在的風(fēng)險(xiǎn)點(diǎn)，并且打破集中式的網(wǎng)絡(luò)瓶頸，采用分布式架構(gòu)實(shí)現(xiàn)。最后是為應(yīng)對(duì)業(yè)務(wù)流量的突發(fā)式增長(zhǎng)，方案在支撐資源的可擴(kuò)展性上也有相關(guān)考慮。主要是網(wǎng)絡(luò)能夠打通跨區(qū)域的計(jì)算資源，并且做到在多租戶環(huán)境下實(shí)現(xiàn)跨區(qū)域資源的互通。（2）其次根據(jù)方案的能力設(shè)計(jì)，我們對(duì)方案的技術(shù)選型也進(jìn)行了思考與規(guī)劃，具體分為兩個(gè)層次：首先整體方案的技術(shù)框架我們依然選擇采用基于開(kāi)源技術(shù)實(shí)現(xiàn)。一是因?yàn)榻鹑谛袠I(yè)的一些特殊需求需要對(duì)相關(guān)能力進(jìn)行定制化開(kāi)發(fā)，而且足夠快速和靈活，這就要求我們對(duì)方案具備自主可控的

21、能力，采用商業(yè)軟件是做不到的；二是如果從頭進(jìn)行開(kāi)發(fā)將會(huì)消耗大量的時(shí)間經(jīng)歷，基于開(kāi)源技術(shù)則會(huì)達(dá)到快速實(shí)現(xiàn)的目的；從具體的能力技術(shù)設(shè)計(jì)上，我們會(huì)進(jìn)行分布式路由、分布式ARP、跨區(qū)域互聯(lián)、防火墻并聯(lián)接入等具體的技術(shù)方案以滿足最初的能力設(shè)計(jì)。分布式路由打破了Neutron網(wǎng)絡(luò)集中式節(jié)點(diǎn)處理方式，會(huì)對(duì)網(wǎng)絡(luò)的性能、穩(wěn)定性進(jìn)行優(yōu)化；分布式ARP將會(huì)很大程度上抑制網(wǎng)絡(luò)中存在的廣播報(bào)文，提高網(wǎng)絡(luò)穩(wěn)定性；跨區(qū)域互聯(lián)通過(guò)對(duì)接RI系統(tǒng)實(shí)現(xiàn)；防火墻并聯(lián)的實(shí)現(xiàn)也避免了防火墻成為網(wǎng)絡(luò)瓶頸。具體設(shè)計(jì)思路式會(huì)在下文中詳細(xì)闡述。（3）最后根據(jù)方案的能力設(shè)計(jì)與技術(shù)選型，我們整理了兩點(diǎn)具體實(shí)現(xiàn)的思路。一是能力的實(shí)現(xiàn)方案應(yīng)充分考慮當(dāng)前

22、數(shù)據(jù)中心現(xiàn)狀，應(yīng)選取可以平滑遷移和應(yīng)用的方案進(jìn)行實(shí)現(xiàn)；二是不同能力在實(shí)現(xiàn)的過(guò)程中相互之間會(huì)有聯(lián)系或影響，比如要實(shí)現(xiàn)高級(jí)的跨區(qū)域通信能力，就必須對(duì)底層的分布式路由、ARP代答等能力進(jìn)行修善。因此在能力實(shí)現(xiàn)中要對(duì)這種情況進(jìn)行充分預(yù)估與判斷，防止由于忽視相互之間的影響而導(dǎo)致能力不足或出現(xiàn)相關(guān)隱患。2.整體技術(shù)框架本次方案研究中，我們依然采用開(kāi)源技術(shù)框架來(lái)進(jìn)行實(shí)現(xiàn)。核心控制層采用開(kāi)源控制器OpenDayLight（下文簡(jiǎn)稱ODL），上層編排仍使用OpenStack的Neutron，Neutron與ODL之間使用ML2 plugin進(jìn)行對(duì)接；底層數(shù)據(jù)層使用OpenvSwitch（下文簡(jiǎn)稱OVS）進(jìn)行網(wǎng)流

23、轉(zhuǎn)發(fā)交換，并通過(guò)OVSDB與Openflow協(xié)議與控制器對(duì)接，其中OVSDB負(fù)責(zé)對(duì)OVS進(jìn)行配置，Openflow則負(fù)責(zé)實(shí)現(xiàn)所有的數(shù)據(jù)轉(zhuǎn)發(fā)功能現(xiàn)。整體框架圖如下。圖4 方案整體框架圖3.能力設(shè)計(jì)（1）基于虛擬化的多租戶支持多租戶虛擬化網(wǎng)絡(luò)解決方案通過(guò)Overlay網(wǎng)絡(luò)和SDN控制器的相互配合，可以使得邏輯網(wǎng)絡(luò)與物理網(wǎng)絡(luò)解耦、控制平面和轉(zhuǎn)發(fā)平面分離，進(jìn)而實(shí)現(xiàn)消除網(wǎng)絡(luò)限制、虛機(jī)任意遷移、IP地址靈活分配的目的，從而充分滿足用戶隨時(shí)隨地接入、業(yè)務(wù)快速上線、虛機(jī)遷移及策略自動(dòng)跟隨的需求。當(dāng)前多租戶已成為行業(yè)云的基本能力要求，但是在私有云中則會(huì)根據(jù)管理方式選擇性部署。但是我們認(rèn)為隨著私有云規(guī)模的不斷擴(kuò)大

24、，多租戶也必將成為私有云的必需。一方面多租戶技術(shù)允許網(wǎng)絡(luò)資源重疊，能夠緩解整體網(wǎng)絡(luò)資源緊張的局面；另一方面多租戶概念的引入將會(huì)使得不同應(yīng)用之間的網(wǎng)絡(luò)邏輯邊界更加明顯，在方便管理的同時(shí)也使得抽象的訪問(wèn)策略更加具象化，提升運(yùn)維效率。本方案中我們采用比較通用的Vxlan技術(shù)來(lái)實(shí)現(xiàn)多租戶的能力。（2）跨區(qū)域互聯(lián)能力傳統(tǒng)交換網(wǎng)絡(luò)穩(wěn)定有余但靈活、高效不足。各網(wǎng)絡(luò)分區(qū)之間計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、機(jī)房物理環(huán)境等資源均為獨(dú)享模式，不同分區(qū)之間計(jì)算宿主機(jī)無(wú)法共享資源，虛擬機(jī)不允許在不同分區(qū)宿主機(jī)間漂移，計(jì)算資源利用率下降。為打破傳統(tǒng)分區(qū)，本方案將會(huì)對(duì)基于多租戶模式下的跨區(qū)域資源互聯(lián)進(jìn)行實(shí)現(xiàn)，提高資源利用率與應(yīng)用部署靈活

25、性。在具體能力實(shí)現(xiàn)中，我們采用與銀聯(lián)自研的區(qū)域互聯(lián)系統(tǒng)（以下簡(jiǎn)稱RI，RI具體實(shí)現(xiàn)方式請(qǐng)見(jiàn)文章中國(guó)銀聯(lián)與上海銀行基于SDN的下一代金融云網(wǎng)絡(luò)聯(lián)合研究與應(yīng)用實(shí)踐）進(jìn)行對(duì)接的方案，在數(shù)據(jù)平面通過(guò)Vlan的方式與防火墻進(jìn)行連通。（3）分布式網(wǎng)絡(luò)功能設(shè)計(jì)云的本質(zhì)是分布式計(jì)算的一種形式，采用虛擬化技術(shù)將集中的物理資源進(jìn)行切割，并通過(guò)網(wǎng)絡(luò)將資源分散給不同用戶。因此，為了更好的契合云計(jì)算分布式的本質(zhì)，避免集中式的網(wǎng)絡(luò)功能成為云的瓶頸，在進(jìn)行下一代金融云網(wǎng)絡(luò)能力設(shè)計(jì)中，我們將分布式的網(wǎng)絡(luò)功能作為必備能力。常用的云網(wǎng)絡(luò)功能包括網(wǎng)關(guān)、DHCP、ARP響應(yīng)、防火墻在本方案中，防火墻的能力通過(guò)硬件實(shí)現(xiàn)，所以在此不對(duì)其

26、分布式實(shí)現(xiàn)進(jìn)行討論；DHCP主要作用只是在虛擬機(jī)網(wǎng)絡(luò)發(fā)生變化時(shí)，向虛擬機(jī)下發(fā)主機(jī)名和IP地址，應(yīng)用場(chǎng)景少、涉及流量小，并非云網(wǎng)絡(luò)瓶頸，對(duì)其進(jìn)行分布式實(shí)現(xiàn)意義也較小。而相反，在軟件云網(wǎng)絡(luò)方案中，網(wǎng)關(guān)與ARP響應(yīng)兩組功能也全為軟件實(shí)現(xiàn)，屬于網(wǎng)絡(luò)基礎(chǔ)能力，應(yīng)用頻繁。網(wǎng)關(guān)是三層通信的流量轉(zhuǎn)發(fā)點(diǎn)，不同網(wǎng)絡(luò)之間的流量通信都必須經(jīng)過(guò)網(wǎng)關(guān)進(jìn)行路由；而ARP響應(yīng)則是獲取目的MAC地址的唯一途徑，是二層通信中不可或缺的流程與手段，同時(shí)也是區(qū)域內(nèi)正常通信下廣播流量的主要來(lái)源。因此，對(duì)網(wǎng)關(guān)與ARP響應(yīng)進(jìn)行分布式實(shí)現(xiàn)將會(huì)較大幅度地提升云網(wǎng)絡(luò)的效率與穩(wěn)定性。綜上所述，本方案會(huì)對(duì)網(wǎng)關(guān)與ARP響應(yīng)能力進(jìn)行分布式實(shí)現(xiàn)。（4）防

27、火墻并聯(lián)方式接入防火墻用于提供四到七層網(wǎng)絡(luò)安全服務(wù)，實(shí)現(xiàn)邏輯區(qū)域之間的安全隔離。金融云網(wǎng)架構(gòu)模型中，可將硬件防火墻資源進(jìn)行池化部署，并按需進(jìn)行調(diào)度，通過(guò)云控制平臺(tái)實(shí)現(xiàn)防火墻統(tǒng)一管理。除此之外，金融數(shù)據(jù)中在防火墻接入形態(tài)上采用物理并聯(lián)、邏輯串聯(lián)的方式，在防火墻故障的情況下仍能保證業(yè)務(wù)的正常運(yùn)行，提升了業(yè)務(wù)的穩(wěn)定性。在本方案中也將實(shí)現(xiàn)該效果。（5）最終能力實(shí)現(xiàn)效果以上能力全部實(shí)現(xiàn)后，最終的效果圖如下所示。圖5 網(wǎng)絡(luò)能力效果圖（三）基于OpenFlow流表的能力實(shí)現(xiàn)從數(shù)據(jù)平面來(lái)看，本方案中所有的數(shù)據(jù)轉(zhuǎn)發(fā)功能全部通過(guò)Openflow流表進(jìn)行實(shí)現(xiàn)，即區(qū)域中所有的流量都由OVS依照Openflow流表來(lái)進(jìn)

28、行轉(zhuǎn)發(fā)動(dòng)作；而從控制平面上看，控制器只是根據(jù)方案預(yù)先制訂的Openflow流表框架來(lái)實(shí)現(xiàn)到OVS的自動(dòng)配置與下發(fā)的能力。所以，方案能力實(shí)現(xiàn)的關(guān)鍵仍在對(duì)Openflow流表的設(shè)計(jì)。1.整體流表設(shè)計(jì)框架OVS的網(wǎng)絡(luò)功能主要由網(wǎng)橋，端口與流表等實(shí)現(xiàn)。一個(gè)網(wǎng)橋中可以包含多級(jí)流表（Table0,Table1,Table2,），流量在轉(zhuǎn)發(fā)的過(guò)程中可以在不同的Table上進(jìn)行跳轉(zhuǎn)，以實(shí)現(xiàn)不同的功能；同時(shí)一個(gè)Table可以包含多條流表（flow entry），對(duì)流表可進(jìn)行優(yōu)先級(jí)的控制，但是只有一條流表會(huì)對(duì)進(jìn)入Table的流量起作用。原生ODL會(huì)在平臺(tái)的每臺(tái)物理機(jī)上創(chuàng)建br-int、br-ex兩個(gè)OVS 網(wǎng)橋，

29、其中br-ex主要負(fù)責(zé)南北向通信，連接外部網(wǎng)絡(luò)和br-int網(wǎng)橋，且只有一個(gè)Table 0，功能比較簡(jiǎn)單；而br-int則負(fù)責(zé)虛擬機(jī)的接入，并實(shí)現(xiàn)大部分的網(wǎng)絡(luò)能力，包含了Table0、10、20到110共12個(gè)Table，功能較為復(fù)雜。各個(gè)Table的具體功能如下所示。CLASSIFIER Table0 流量分類DIRECTOR Table10 DirectorARP_RESPONDER Table20 分布式ARP應(yīng)答INBOUND_NAT Table30 入站流量浮動(dòng)IP流量DNATEGRESS_ACL Table40 出口訪問(wèn)控制LOAD_BALANCER Table50 分布式負(fù)載均衡

30、ROUTING Table60 分布式路由L3_FORWARDING Table70 3層轉(zhuǎn)發(fā)L2_REWRITE Table80 2層重寫(xiě)服務(wù)INGRESS_ACL Table90 入口訪問(wèn)控制OUTBOUND_NAT Table100 訪問(wèn)外部網(wǎng)絡(luò)流量的SNATL2_FORWARDING Table110 二層轉(zhuǎn)發(fā)為方便開(kāi)發(fā)，本方案在流表設(shè)計(jì)中繼續(xù)沿用原生ODL的流表框架與各個(gè)流表的功能設(shè)計(jì)。同時(shí)為了實(shí)現(xiàn)方案的設(shè)計(jì)能力，對(duì)相關(guān)Table進(jìn)行能力補(bǔ)足與優(yōu)化，具體修改的流表如下圖6所示。圖6 主要流表框架圖Table 0：租戶在云網(wǎng)分區(qū)內(nèi)部與外部之間的標(biāo)簽轉(zhuǎn)換；Table60：防火墻物理并聯(lián)邏

31、輯串聯(lián)接入實(shí)現(xiàn)；Table 20、70、110：支持去Floating IP的分布式網(wǎng)關(guān)實(shí)現(xiàn)。下文中會(huì)對(duì)每項(xiàng)功能具體實(shí)現(xiàn)的技術(shù)方案、詳細(xì)流表與代碼架構(gòu)進(jìn)行詳細(xì)說(shuō)明。2.能力優(yōu)化與實(shí)現(xiàn)能力實(shí)現(xiàn)1：多租戶環(huán)境下跨區(qū)域互聯(lián)做到多租戶環(huán)境下的跨區(qū)域互聯(lián)主要難點(diǎn)在與如何對(duì)存在于不同云網(wǎng)分區(qū)的租戶流量進(jìn)行標(biāo)記與識(shí)別，從而保證通過(guò)核心交換網(wǎng)絡(luò)后，云網(wǎng)分區(qū)可以正確將IP地址重用的多租戶流量轉(zhuǎn)發(fā)至正確的租戶資源。在對(duì)接RI后，所有跨區(qū)域通信流量在出區(qū)域防火墻后，即通過(guò)RI在核心交換區(qū)架起的隧道到達(dá)另一區(qū)域的防火墻。不同的租戶在核心交換區(qū)對(duì)應(yīng)不同的隧道，從而實(shí)現(xiàn)了不同區(qū)域不同租戶的流量隔離。因此，我們只需關(guān)心跨區(qū)

32、域互聯(lián)時(shí)在區(qū)域內(nèi)部的一些功能操作，而無(wú)需關(guān)心外部核心交換區(qū)域如何實(shí)現(xiàn)。具體如下圖7所示。圖7 RI跨區(qū)域通信示意圖在進(jìn)行跨區(qū)域通信時(shí)我們考慮的問(wèn)題有兩個(gè)：一是跨區(qū)域的流量通過(guò)什么方式送到防火墻；二是防火墻接收到外部區(qū)域發(fā)來(lái)的跨區(qū)域訪問(wèn)流量的時(shí)候，如何將該流量發(fā)送到區(qū)域內(nèi)。下面我們對(duì)這兩個(gè)問(wèn)題進(jìn)行逐一分析。問(wèn)題一：跨區(qū)域流量通過(guò)什么方式發(fā)送到防火墻在考慮該問(wèn)題的時(shí)候，又會(huì)衍生出新的子問(wèn)題：1.火墻支持的接入方式是什么，是否支持隧道接入；2.防火墻的物理連接方式是什么，并聯(lián)還是串聯(lián)。先看子問(wèn)題1。在金融行業(yè)，對(duì)防火墻的性能和可用性有著比較高的要求，因此金融數(shù)據(jù)中心內(nèi)部絕大部分仍使用硬件防火墻。而硬

33、件防火墻往往不支持如Vxlan、GRE等一些隧道功能，所以一般還是采用Vlan的方式與防火墻連接。子問(wèn)題2提出了防火墻的物理連接方式。在能力設(shè)計(jì)的第四點(diǎn)已經(jīng)提出，為保證業(yè)務(wù)運(yùn)行的穩(wěn)定性，降低網(wǎng)絡(luò)故障瓶頸與影響范圍，在金融數(shù)據(jù)中心防火墻采用并聯(lián)方式接入。且為保證防火墻的性能，降低故障率，區(qū)域的外部網(wǎng)關(guān)不會(huì)建立在防火墻上。既然防火墻已并聯(lián)方式接入且外部網(wǎng)關(guān)不在防火墻上，那么區(qū)域內(nèi)流量要發(fā)送到防火墻必須經(jīng)過(guò)引流才能實(shí)現(xiàn)。具體引流方案我們會(huì)放在后面關(guān)于防火墻并聯(lián)接入實(shí)現(xiàn)的內(nèi)容中，在此不做贅述。問(wèn)題二：防火墻如何將流量發(fā)送到區(qū)域內(nèi)該問(wèn)題也會(huì)產(chǎn)生兩個(gè)子問(wèn)題：防火墻如何將流量發(fā)送到區(qū)域的外部網(wǎng)關(guān)。該問(wèn)題則是

34、由于外部網(wǎng)關(guān)的分布式實(shí)現(xiàn)導(dǎo)致的，具體方案會(huì)在分布式路由實(shí)現(xiàn)中進(jìn)行詳細(xì)描述，在此不做贅述；同樣是由于連接防火墻與區(qū)域內(nèi)部網(wǎng)絡(luò)方案的不同需要進(jìn)行報(bào)文轉(zhuǎn)換，只不過(guò)這次轉(zhuǎn)換是有Vlan報(bào)文轉(zhuǎn)換為Vxlan報(bào)文。綜上所述，要實(shí)現(xiàn)跨區(qū)域通信的影響面較廣，分布式網(wǎng)關(guān)、防火墻接入都會(huì)有所涉及。為使功能實(shí)現(xiàn)更加清晰，我們?cè)谶@里只對(duì)Vlan到Vxlan的報(bào)文轉(zhuǎn)換的實(shí)現(xiàn)方式進(jìn)行描述。流表設(shè)計(jì)br-ex Table0：table=0,priority=2048,in_port=3,dl_Vlan=310,nw_dst=10.2.1.0/24 actions= output:1以上流表位于br-ex Table0，接收

35、到Vlan標(biāo)簽為310、目的IP地址為10.2.1.0/24的報(bào)文并轉(zhuǎn)發(fā)到br-int。Vlan 310是該租戶在外部網(wǎng)絡(luò)的Vlan ID，output:1則表示從br-ex的標(biāo)號(hào)為1的端口發(fā)出，該端口即是br-ex 與br-int的連接端口。br-int Table0：table=0,priority=2048,in_port=4,IP,dl_Vlan=310,nw_dst=10.2.1.0/24 actions=strIP_Vlan, set_field:0 x28-tun_id,goto_table:20當(dāng)檢測(cè)到其它區(qū)域發(fā)來(lái)的流量時(shí)，檢測(cè)Vlan號(hào)和網(wǎng)段是否屬于本區(qū)域并且對(duì)應(yīng)關(guān)系一致，如

36、果該流量的目的終端確實(shí)在本區(qū)域，卸載Vlan號(hào)，并進(jìn)行Vlan到Vxlan的映射操作，并將該流量發(fā)送到下一流表中繼續(xù)處理。代碼架構(gòu)添加接口：文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/ClassifierProvider.java函數(shù)：programVlanToVxlanFlowEntry文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/L3ForwardingProvider.java函數(shù)：pro

37、gramBrexFlowEntry流表邏輯實(shí)現(xiàn)：文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/NeutronL3Adapter.java函數(shù)：handleNeutronRouterInterfaceEvent流表下發(fā)：文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/ClassifierService.java函數(shù)：progra

38、mVlanToVxlanFlowEntry文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/L3ForwardingService.java函數(shù)：programBrexFlowEntry能力實(shí)現(xiàn)2：防火墻物理并聯(lián)邏輯串聯(lián)接入實(shí)現(xiàn)在上文的問(wèn)題分析中，已經(jīng)提到為什么防火墻要采用物理并聯(lián)邏輯串聯(lián)的接入方式，并且也提到通過(guò)引流方式進(jìn)行實(shí)現(xiàn)。在本節(jié)中對(duì)實(shí)現(xiàn)具體方案和步驟進(jìn)行詳細(xì)描述。首先，從引流的場(chǎng)景看，都有哪些南北向流量需要通過(guò)引導(dǎo)才能

39、發(fā)送到防火墻。在本方案中，南北向流量可分為兩種，一種是通過(guò)Floating IP被外部訪問(wèn)的流量，另一種是通過(guò)內(nèi)網(wǎng)網(wǎng)段信息對(duì)外通信的跨區(qū)域流量。具體如下圖8所示。圖8 云網(wǎng)區(qū)域南北向通信示意圖對(duì)第一種南北向流量，因?yàn)閹в蠪loating IP地址，因此其默認(rèn)下一跳就會(huì)被送至外部接口網(wǎng)關(guān)，因此不需要引流就會(huì)被傳送至防火墻并發(fā)出。對(duì)第二種南北向流量，其源IP和目的IP都為內(nèi)網(wǎng)地址，其傳送的防火墻屬于跨網(wǎng)段通信，因此需要設(shè)置路由表對(duì)其進(jìn)行引流，將去往另一個(gè)區(qū)域網(wǎng)段的下一跳設(shè)置在防火墻與路由器的接口上，從而實(shí)現(xiàn)了防火墻的引流功能。流表實(shí)現(xiàn)確定需要引流的流量后，我們就要進(jìn)行引流功能的流表實(shí)現(xiàn)。在這里需要

40、考慮兩點(diǎn)：第一路由器與防火墻之間是Vlan模式的網(wǎng)絡(luò)，因此流量在通過(guò)路由器的時(shí)候應(yīng)打上Vlan標(biāo)簽；第二每個(gè)租戶有各自的防火墻接口，接口的MAC地址要進(jìn)行獲取。最終流表實(shí)現(xiàn)如下：table=60,priority=4096,IP,tun_id=0 x1e,nw_src=10.1.1.0/24,nw_dst=10.2.1.0/24,actions=set_field:f8:4a:bf:5a:2b:ea -eth_dst,dec_ttl,mod_Vlan_vid:211,output:3以上流表是靜態(tài)路由的實(shí)現(xiàn)，報(bào)文目標(biāo)IP地址是另一個(gè)租戶的網(wǎng)段時(shí)，將目標(biāo)mac地址改成外部網(wǎng)絡(luò)上租戶防火墻接口的m

41、ac地址，根據(jù)源IP和tun_id確認(rèn)租戶，設(shè)置租戶對(duì)應(yīng)的的Vlan id，將報(bào)文發(fā)出。代碼架構(gòu)添加接口：文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/RoutingProvider.java函數(shù)：programStaticRoutesFlowEntry文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/api/GatewayMacResolver.java函數(shù)：resolveMacAddressWithVla

42、nTag流表邏輯實(shí)現(xiàn)：文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/NeutronL3Adapter.java函數(shù)：handleNeutronRouterEvent流表下發(fā)：文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/RoutingService.java函數(shù)：programStaticRoutesFlowEntry文件：

43、net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/arp/ArpSender.java函數(shù)：sendVlanTaggedArpcreateVlanTaggedArpFrame能力實(shí)現(xiàn)3：支持去Floating IP的分布式路由原生ODL實(shí)現(xiàn)方式在能力設(shè)計(jì)中，我們提出采用分布式路由的實(shí)現(xiàn)方式。在ODL原生方案中，也對(duì)分布式路由進(jìn)行了實(shí)現(xiàn)，具體實(shí)現(xiàn)方式如下圖9所示。圖9 原生ODL分布式路由實(shí)現(xiàn)示意圖從圖9可以看出，原生ODL的分布式路由

44、機(jī)制則在每個(gè)節(jié)點(diǎn)上都使能一個(gè)路由器。對(duì)于東西向的流量， 流量會(huì)直接在計(jì)算節(jié)點(diǎn)之間傳遞。對(duì)于南北向的流量，如果有Floating IP，流量就直接走計(jì)算節(jié)點(diǎn)；但是對(duì)于沒(méi)有Floating IP的流量，依然要通過(guò)集中式的網(wǎng)絡(luò)節(jié)點(diǎn)發(fā)送。在一般場(chǎng)景應(yīng)用中，區(qū)域的南北向流量都要經(jīng)過(guò)NAT處理（即使用Floating IP）才能進(jìn)行正常通信。如不進(jìn)行NAT處理，區(qū)域內(nèi)部的網(wǎng)段地址無(wú)法被外部網(wǎng)絡(luò)識(shí)別，因此無(wú)法實(shí)現(xiàn)預(yù)期的數(shù)據(jù)轉(zhuǎn)發(fā)。但是在本方案中，由于存在跨區(qū)域通信的場(chǎng)景，為了識(shí)別租戶信息，反而需要攜帶內(nèi)部網(wǎng)絡(luò)地址信息與其它區(qū)域進(jìn)行通信。而該場(chǎng)景恰恰與上文中提到的無(wú)Floating IP進(jìn)行南北向通信的方式相吻

45、合。所以在原生的ODL設(shè)計(jì)中，該流量仍需要通過(guò)集中式的網(wǎng)絡(luò)節(jié)點(diǎn)發(fā)送，這就與本方案的能力設(shè)計(jì)不符。原理分析與問(wèn)題提出為了實(shí)現(xiàn)支持去Floating IP的分布式路由能力，我們需要對(duì)ODL原生分布式路由的設(shè)計(jì)方式進(jìn)行進(jìn)一步分析：為什么無(wú)Floating IP的南北向流量不能使用分布式網(wǎng)關(guān)方式實(shí)現(xiàn)？為了闡述起來(lái)更直觀，我們通過(guò)下面的一個(gè)具體場(chǎng)景來(lái)尋找原因。圖10 分布式網(wǎng)關(guān)物理結(jié)構(gòu)圖上圖是一張分布式網(wǎng)關(guān)的物理結(jié)構(gòu)圖，由圖可看出每臺(tái)物理節(jié)點(diǎn)的OVS都具備路由的功能。圖中六臺(tái)虛擬機(jī)同屬同一租戶且分布在兩個(gè)網(wǎng)段中，租戶與外部網(wǎng)絡(luò)的接口地址為172.16.1.100，同時(shí)為每臺(tái)虛擬機(jī)都分配了相應(yīng)的Float

46、ing IP。在該環(huán)境下，當(dāng)虛擬機(jī)在與external網(wǎng)絡(luò)通信時(shí)，流量到達(dá)OVS上時(shí)，OVS中的相關(guān)表項(xiàng)會(huì)將數(shù)據(jù)包的源IP地址轉(zhuǎn)換為唯一與該虛擬機(jī)對(duì)應(yīng)的Floating IP。如v1在與外部網(wǎng)絡(luò)通信時(shí)，從v1中出來(lái)的數(shù)據(jù)包的源IP地址還是v1的IP地址，即10.0.0.1，那么數(shù)據(jù)包到了OVS上之后，OVS根據(jù)該數(shù)據(jù)包的目的IP地址判斷出這是v1與外部網(wǎng)絡(luò)通信的流量，這時(shí)OVS中就會(huì)有相應(yīng)的流表對(duì)該數(shù)據(jù)包的源IP地址字段進(jìn)行轉(zhuǎn)換，即將10.0.0.1轉(zhuǎn)換為172.16.1.1，也就是v1的Floating IP。那么對(duì)于外部網(wǎng)絡(luò)來(lái)說(shuō)，v1的IP地址也就變?yōu)榱?72.16.1.1。因?yàn)镕loat

47、ing IP與虛擬機(jī)之間是一一對(duì)應(yīng)的，所以外部網(wǎng)絡(luò)在進(jìn)行回包的時(shí)候，就可以直接通過(guò)Floating IP找到v1所在的位置，從直接而將數(shù)據(jù)送回至v1。如果v1沒(méi)有Floating IP ，雖然它主動(dòng)向外部網(wǎng)絡(luò)發(fā)送的數(shù)據(jù)是能夠送至目的端的，但是目的端的返回包是無(wú)法送至v1的。因?yàn)関1的數(shù)據(jù)包是其內(nèi)網(wǎng)地址10.0.0.1作為源IP地址的，而其內(nèi)網(wǎng)地址是不為外部網(wǎng)絡(luò)所認(rèn)知的，這是存在的第一個(gè)問(wèn)題。不過(guò)回到我們的跨區(qū)域通信場(chǎng)景中，由于對(duì)接RI系統(tǒng)，帶有內(nèi)網(wǎng)地址的數(shù)據(jù)可通過(guò)RI建立的隧道跨過(guò)核心交換區(qū)域到達(dá)另一個(gè)云網(wǎng)分區(qū)的防火墻上。所以第一個(gè)問(wèn)題在跨區(qū)域通信的場(chǎng)景中不存在，我們繼續(xù)往下分析。當(dāng)數(shù)據(jù)流到達(dá)

48、云網(wǎng)分區(qū)的防火墻上時(shí)，我們需要解決上文中已經(jīng)提及的問(wèn)題：在分布式的網(wǎng)關(guān)場(chǎng)景下，流量如何通過(guò)防火墻發(fā)送到云網(wǎng)區(qū)域的外部接口上？在原生的ODL方案中，區(qū)域的外部接口并沒(méi)有實(shí)現(xiàn)接收外部網(wǎng)絡(luò)數(shù)據(jù)的能力，所以我們需要對(duì)此功能進(jìn)行實(shí)現(xiàn)。實(shí)現(xiàn)了數(shù)據(jù)接收能力后，仍存在另外一個(gè)問(wèn)題。如圖10所示，云網(wǎng)分區(qū)的外部接口分布在區(qū)域內(nèi)的每臺(tái)物理節(jié)點(diǎn)上，而跨區(qū)域通信的數(shù)據(jù)包的目的虛擬機(jī)只存在于一臺(tái)物理節(jié)點(diǎn)中。當(dāng)防火墻向云網(wǎng)區(qū)域的外部接口發(fā)送數(shù)據(jù)包時(shí)，應(yīng)該將數(shù)據(jù)包發(fā)送到哪一臺(tái)物理節(jié)點(diǎn)上呢？換句換說(shuō)就是如何定位目的虛擬機(jī)的具體位置。綜合分析下來(lái)，我們得知，要實(shí)現(xiàn)支持去Floating IP分布式網(wǎng)關(guān)實(shí)現(xiàn)，就必須解決下面兩個(gè)問(wèn)

49、題：1. 實(shí)現(xiàn)區(qū)域外部接口對(duì)外來(lái)流量的數(shù)據(jù)接收能力；2. 外部接口接收到數(shù)據(jù)后，能夠?qū)?shù)據(jù)送達(dá)目的虛擬機(jī)。流表實(shí)現(xiàn)針對(duì)問(wèn)題1，我們通過(guò)設(shè)計(jì)外部接口的ARP響應(yīng)的openflow流表，實(shí)現(xiàn)外部接口接收外來(lái)數(shù)據(jù)的能力。具體流表如下table=20,priority=1024,arp,arp_tpa=172.16.1.100,arp_op=1 actions=move:NXM_OF_ETH_SRC-NXM_OF_ETH_DST,set_field:f8:4a:bf:5a:2b:ea-eth_src,load:0 x2-NXM_OF_ARP_OP,move:NXM_NX_ARP_SHA-NXM_NX_

50、ARP_THA,move:NXM_OF_ARP_SPA-NXM_OF_ARP_TPA,load:0 xf84abf5a2bea-NXM_NX_ARP_SHA,load:0 xac100164-NXM_OF_ARP_SPA,IN_PORT上面的流表的主要作用就是為外部接口構(gòu)造了一個(gè)ARP的響應(yīng)包，在接收到對(duì)外部接口的ARP請(qǐng)求的時(shí)候，OVS會(huì)根據(jù)該流表生成一個(gè)ARP響應(yīng)包，發(fā)回給請(qǐng)求方。當(dāng)請(qǐng)求方接收到該ARP響應(yīng)報(bào)文后，就會(huì)將數(shù)據(jù)包發(fā)出，送至發(fā)出該響應(yīng)報(bào)文的物理節(jié)點(diǎn)的OVS上。為了保證路由的分布式架構(gòu)，我們會(huì)在所有的物理節(jié)點(diǎn)上下發(fā)外部接口的ARP響應(yīng)的流表。所以，在外部網(wǎng)絡(luò)發(fā)出ARP請(qǐng)求后，所有

51、物理節(jié)點(diǎn)都會(huì)對(duì)該請(qǐng)求進(jìn)行響應(yīng)。收到響應(yīng)后，外部網(wǎng)絡(luò)就會(huì)將數(shù)據(jù)包發(fā)出，發(fā)出后數(shù)據(jù)包就會(huì)按照物理交換機(jī)上的mac表進(jìn)行轉(zhuǎn)發(fā)，最終發(fā)送到平臺(tái)中的某一個(gè)物理節(jié)點(diǎn)的OVS上。具體如下圖11所示。圖11 分布式網(wǎng)關(guān)ARP響應(yīng)示意圖針對(duì)問(wèn)題2，當(dāng)物理節(jié)點(diǎn)收到數(shù)據(jù)包后，會(huì)進(jìn)一步對(duì)數(shù)據(jù)包進(jìn)行分析。此時(shí)就會(huì)有兩種情況：一是該虛擬機(jī)恰好在該物理節(jié)點(diǎn)中，此時(shí)就可以直接將數(shù)據(jù)包送到虛擬機(jī)上，相應(yīng)流表如下；table=70,priority=1024,IP,tun_id=0 x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47-eth_dst,goto_table

52、:80（三層轉(zhuǎn)發(fā)）table=110, tun_id=0 x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二層轉(zhuǎn)發(fā)到虛擬機(jī)，23口與是虛擬機(jī)連接的OVS的端口）還有一種情況就是虛擬機(jī)不在該物理節(jié)點(diǎn)中，那么這時(shí)候就要用隧道的方式，將數(shù)據(jù)包通過(guò)Vxlan隧道發(fā)送到虛擬機(jī)所處的物理節(jié)點(diǎn)，然后再送到虛擬機(jī)，如圖12所示。相應(yīng)流表如下：table=70,priority=1024,IP,tun_id=0 x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47-eth_dst,goto_table:80（

53、三層轉(zhuǎn)發(fā)）table=110, tun_id=0 x5a,dl_dst=fa:16:3e:99:df:47 actions=output:3（通過(guò)Tunnel轉(zhuǎn)發(fā)到對(duì)應(yīng)物理機(jī)，后面的output：3代表從3口發(fā)出，3口即為隧道的端口）到對(duì)端物理機(jī)的OVS后：table=110, tun_id=0 x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二層轉(zhuǎn)發(fā)到虛擬機(jī)）圖12虛擬機(jī)定位示意圖整個(gè)流程統(tǒng)一起來(lái)，步驟如圖13所示。圖13 支持去Floating IP分布式網(wǎng)關(guān)數(shù)據(jù)處理流程圖代碼架構(gòu)添加接口:文件：net-virt/src/main/java/o

54、rg/opendaylight/netvirt/openstack/netvirt/api/ArpProvider.java函數(shù)：programPFWProviderArpEntry文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/PortHandler.java函數(shù)：doNeutronPortCreated流表邏輯實(shí)現(xiàn)文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/DistributedArpService

55、.java函數(shù)：handleNeutronPortForArp流表下發(fā)文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/ArpResponderService.java函數(shù)：programPFWProviderArpEntry文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/ser

56、vices/L3ForwardingService.java函數(shù)：programForwardingTableEntry3.跨區(qū)域通信實(shí)現(xiàn)案例分析下面我們結(jié)合一個(gè)跨區(qū)域通信的場(chǎng)景，舉例分析跨區(qū)域虛擬機(jī)通信過(guò)程中經(jīng)過(guò)的流表以及各個(gè)流表的功能。如圖14所示，兩個(gè)虛擬機(jī)VM1和VM2分別在兩個(gè)區(qū)域的兩臺(tái)主機(jī)上，VM1向VM2發(fā)送ICMP請(qǐng)求。圖14 跨區(qū)域通信流表作用示意圖首先VM1會(huì)發(fā)送目標(biāo)IP為網(wǎng)關(guān)IP 10.1.1.1的ARP請(qǐng)求廣播包，由OVS獲取并發(fā)送到Table20中進(jìn)行處理，起作用的流表如下：table=20,priority=1024,arp,arp_tpa=10.1.1.1,tun

57、_id=0 x3e8,arp_op=1 actions=move:NXM_OF_ETH_SRC-NXM_OF_ETH_DST,set_field:02:02:02:02:02:02-eth_src,load:0 x2-NXM_OF_ARP_OP,move:NXM_NX_ARP_SHA-NXM_NX_ARP_THA,move:NXM_OF_ARP_SPA-NXM_OF_ARP_TPA,load:0 x020202020202-NXM_NX_ARP_SHA,load:0 x0a010101-NXM_OF_ARP_SPA,IN_PORTTable20匹配tun_id為1000，目標(biāo)IP為10.1.1

58、.1的ARP請(qǐng)求包，將報(bào)文的目標(biāo)MAC設(shè)為10.1.1.3的MAC地址，將報(bào)文的源MAC和ARP_SHA改為10.1.1.1的MAC地址（從Neutron獲取），將報(bào)文類型改為ARP響應(yīng)，并將響應(yīng)報(bào)文原路送回到發(fā)送方。VM1拿到網(wǎng)關(guān)的MAC地址后，就會(huì)將ICMP報(bào)文發(fā)出，報(bào)文的源IP是10.1.1.3，目標(biāo)IP是10.2.1.3，并在整個(gè)傳輸過(guò)程中保持不變。報(bào)文發(fā)送到OVS后，首先起作用的報(bào)文是Table60的靜態(tài)路由流表，本場(chǎng)景的靜態(tài)路由流表會(huì)匹配tun_id為1000，源地址是10.1.1.0/24，目標(biāo)地址是10.2.0.0/16的流量，將目標(biāo)MAC地址修改為區(qū)域防火墻的MAC地址04:

59、04:04:04:04:04，給報(bào)文打上VLAN TAG 100，并將報(bào)文轉(zhuǎn)發(fā)至br-ex。具體流表如下：table=60, priority=4096,IP,tun_id=0 x3e8,Vlan_tci=0 x0000/0 x1fff,nw_src=10.1.1.0/24,nw_dst=10.2.0.0/16 actions=push_Vlan:0 x8100,set_field:4196-Vlan_vid,set_field:04:04:04:04:04:04 -eth_dst,dec_ttl,output:1br-ex接收到報(bào)文進(jìn)行流表匹配后，最終會(huì)匹配到優(yōu)先級(jí)最低的NORMAL流表，N

60、ORMAL action會(huì)以普通交換機(jī)的行為轉(zhuǎn)發(fā)報(bào)文，也就是根據(jù)MAC地址和端口的對(duì)應(yīng)關(guān)系轉(zhuǎn)發(fā)，具體流表如下：table=0, priority=0 actions=NORMALbr-ex的NORMAL流表會(huì)將報(bào)文通過(guò)host1的eth0發(fā)送到區(qū)域防火墻上，區(qū)域防火墻的默認(rèn)網(wǎng)關(guān)在區(qū)域核心上，流量會(huì)通過(guò)路由到達(dá)交換核心并最終送到另一個(gè)區(qū)域的防火墻。防火墻上有區(qū)域內(nèi)部網(wǎng)絡(luò)的回程路由，由于目標(biāo)地址是10.2.1.3，會(huì)匹配到區(qū)域內(nèi)10.2.1.0/24的回程路由，并送到下一跳172.16.2.1。防火墻會(huì)發(fā)送目標(biāo)IP為172.16.2.1的ARP請(qǐng)求廣播報(bào)文，ARP代答流表所在的主機(jī)host2會(huì)響應(yīng)