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

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

3、2885 （一）網(wǎng)絡(luò)設(shè)計原則 PAGEREF _Toc66542885 h 6 HYPERLINK l _Toc66542886 （二）網(wǎng)絡(luò)架構(gòu) PAGEREF _Toc66542886 h 7 HYPERLINK l _Toc66542887 四、基于ODL開源控制器的數(shù)據(jù)中心內(nèi)SDN網(wǎng)絡(luò)方案研究與實現(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è)計 PAGEREF _Toc66542890 h 11 HYPERLINK l _Toc66542891 （三）基于OpenFlow流表的能力實現(xiàn) PAGEREF _Toc66542891 h 13 HYPERLINK l _Toc66542892 五、原型實踐與效果 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)與云控平臺集成 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è)計原則與架構(gòu)規(guī)劃，和基于ODL開源控制器的數(shù)據(jù)中心內(nèi)SDN網(wǎng)絡(luò)方案研究與實現(xiàn)。一、行業(yè)發(fā)展歷程與技術(shù)發(fā)展趨勢（一）行業(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è)中的核心。中國金融數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)的歷程與金融行業(yè)近三十年信息化過程密不可分，總結(jié)歸納金融數(shù)據(jù)中心網(wǎng)絡(luò)的發(fā)展主要經(jīng)歷了三個階段：第

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

8、下能夠?qū)W(wǎng)絡(luò)的靈活、彈性等要求進行有效應(yīng)對。（二）技術(shù)發(fā)展趨勢近年來，隨著金融數(shù)據(jù)中心云化的加速，金融云作為最新的基礎(chǔ)設(shè)施形態(tài)開始被行業(yè)認同并接納。但在金融云環(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)生的新場景，如虛擬機的出現(xiàn)要求網(wǎng)絡(luò)顆粒度從物理機細化到了虛擬機級別；另一方面面向互聯(lián)網(wǎng)的金融創(chuàng)新業(yè)務(wù)的快速發(fā)展，也會對網(wǎng)絡(luò)的性能、彈性等特性提出更高的要求。所以未來金融數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)必將進行變革式的創(chuàng)新發(fā)展，我們認為未來發(fā)展趨勢主要包括以下三點：1、面向互聯(lián)網(wǎng)新興業(yè)務(wù)的敏捷網(wǎng)絡(luò)，即未來金融云網(wǎng)絡(luò)能夠高效滿足互聯(lián)

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

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

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

12、效并重；高性能，面對秒殺等新業(yè)務(wù)場景等的極限服務(wù)能力，實現(xiàn)時延和帶寬等關(guān)鍵指標的跨越式提升，同時注重資源的高效利用，用盡可能少的資源實現(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小時業(yè)務(wù)連續(xù)性服務(wù)的能力；高彈性，一是內(nèi)部彈性強化，打破豎井式架構(gòu)中網(wǎng)絡(luò)區(qū)域成為限制資源共享的壁壘，實現(xiàn)網(wǎng)絡(luò)資源池整合與靈活共享與隔離，二是外部彈性兼容，支持新老架構(gòu)并存，從而使原有網(wǎng)絡(luò)可以平滑過渡到新架構(gòu)；高可管理，一是實現(xiàn)管理的體系的簡化，支持多品牌的融合管理，二是實現(xiàn)管理自動化與智能化，提供端到端的業(yè)務(wù)可視和故障快速定位、排查能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

34、由于外部網(wǎng)關(guān)的分布式實現(xiàn)導(dǎo)致的，具體方案會在分布式路由實現(xiàn)中進行詳細描述，在此不做贅述；同樣是由于連接防火墻與區(qū)域內(nèi)部網(wǎng)絡(luò)方案的不同需要進行報文轉(zhuǎn)換，只不過這次轉(zhuǎn)換是有Vlan報文轉(zhuǎn)換為Vxlan報文。綜上所述，要實現(xiàn)跨區(qū)域通信的影響面較廣，分布式網(wǎng)關(guān)、防火墻接入都會有所涉及。為使功能實現(xiàn)更加清晰，我們在這里只對Vlan到Vxlan的報文轉(zhuǎn)換的實現(xiàn)方式進行描述。流表設(shè)計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標簽為310、目的IP地址為10.2.1.0/24的報文并轉(zhuǎn)發(fā)到br-int。Vlan 310是該租戶在外部網(wǎng)絡(luò)的Vlan ID，output:1則表示從br-ex的標號為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當檢測到其它區(qū)域發(fā)來的流量時，檢測Vlan號和網(wǎng)段是否屬于本區(qū)域并且對應(yīng)關(guān)系一致，如

36、果該流量的目的終端確實在本區(qū)域，卸載Vlan號，并進行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流表邏輯實現(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能力實現(xiàn)2：防火墻物理并聯(lián)邏輯串聯(lián)接入實現(xiàn)在上文的問題分析中，已經(jīng)提到為什么防火墻要采用物理并聯(lián)邏輯串聯(lián)的接入方式，并且也提到通過引流方式進行實現(xiàn)。在本節(jié)中對實現(xiàn)具體方案和步驟進行詳細描述。首先，從引流的場景看，都有哪些南北向流量需要通過引導(dǎo)才能

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

40、考慮兩點：第一路由器與防火墻之間是Vlan模式的網(wǎng)絡(luò)，因此流量在通過路由器的時候應(yīng)打上Vlan標簽；第二每個租戶有各自的防火墻接口，接口的MAC地址要進行獲取。最終流表實現(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)路由的實現(xiàn)，報文目標IP地址是另一個租戶的網(wǎng)段時，將目標mac地址改成外部網(wǎng)絡(luò)上租戶防火墻接口的m

41、ac地址，根據(jù)源IP和tun_id確認租戶，設(shè)置租戶對應(yīng)的的Vlan id，將報文發(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流表邏輯實現(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能力實現(xiàn)3：支持去Floating IP的分布式路由原生ODL實現(xiàn)方式在能力設(shè)計中，我們提出采用分布式路由的實現(xiàn)方式。在ODL原生方案中，也對分布式路由進行了實現(xiàn)，具體實現(xiàn)方式如下圖9所示。圖9 原生ODL分布式路由實現(xiàn)示意圖從圖9可以看出，原生ODL的分布式路由

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

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

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

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

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

49、題：1. 實現(xiàn)區(qū)域外部接口對外來流量的數(shù)據(jù)接收能力；2. 外部接口接收到數(shù)據(jù)后，能夠?qū)?shù)據(jù)送達目的虛擬機。流表實現(xiàn)針對問題1，我們通過設(shè)計外部接口的ARP響應(yīng)的openflow流表，實現(xiàn)外部接口接收外來數(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)造了一個ARP的響應(yīng)包，在接收到對外部接口的ARP請求的時候，OVS會根據(jù)該流表生成一個ARP響應(yīng)包，發(fā)回給請求方。當請求方接收到該ARP響應(yīng)報文后，就會將數(shù)據(jù)包發(fā)出，送至發(fā)出該響應(yīng)報文的物理節(jié)點的OVS上。為了保證路由的分布式架構(gòu)，我們會在所有的物理節(jié)點上下發(fā)外部接口的ARP響應(yīng)的流表。所以，在外部網(wǎng)絡(luò)發(fā)出ARP請求后，所有

51、物理節(jié)點都會對該請求進行響應(yīng)。收到響應(yīng)后，外部網(wǎng)絡(luò)就會將數(shù)據(jù)包發(fā)出，發(fā)出后數(shù)據(jù)包就會按照物理交換機上的mac表進行轉(zhuǎn)發(fā)，最終發(fā)送到平臺中的某一個物理節(jié)點的OVS上。具體如下圖11所示。圖11 分布式網(wǎng)關(guān)ARP響應(yīng)示意圖針對問題2，當物理節(jié)點收到數(shù)據(jù)包后，會進一步對數(shù)據(jù)包進行分析。此時就會有兩種情況：一是該虛擬機恰好在該物理節(jié)點中，此時就可以直接將數(shù)據(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ā)到虛擬機，23口與是虛擬機連接的OVS的端口）還有一種情況就是虛擬機不在該物理節(jié)點中，那么這時候就要用隧道的方式，將數(shù)據(jù)包通過Vxlan隧道發(fā)送到虛擬機所處的物理節(jié)點，然后再送到虛擬機，如圖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（通過Tunnel轉(zhuǎn)發(fā)到對應(yīng)物理機，后面的output：3代表從3口發(fā)出，3口即為隧道的端口）到對端物理機的OVS后：table=110, tun_id=0 x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二層轉(zhuǎn)發(fā)到虛擬機）圖12虛擬機定位示意圖整個流程統(tǒng)一起來，步驟如圖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流表邏輯實現(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ū)域通信實現(xiàn)案例分析下面我們結(jié)合一個跨區(qū)域通信的場景，舉例分析跨區(qū)域虛擬機通信過程中經(jīng)過的流表以及各個流表的功能。如圖14所示，兩個虛擬機VM1和VM2分別在兩個區(qū)域的兩臺主機上，VM1向VM2發(fā)送ICMP請求。圖14 跨區(qū)域通信流表作用示意圖首先VM1會發(fā)送目標IP為網(wǎng)關(guān)IP 10.1.1.1的ARP請求廣播包，由OVS獲取并發(fā)送到Table20中進行處理，起作用的流表如下：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，目標IP為10.1.1

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

59、04:04:04:04:04，給報文打上VLAN TAG 100，并將報文轉(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接收到報文進行流表匹配后，最終會匹配到優(yōu)先級最低的NORMAL流表，N

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