基于开源SDN控制器的下一代金融云网络的研究与实践
本文作者：
中國銀聯(lián)電子支付研究院（電子商務(wù)與電子支付國家工程實驗室）：袁航、周雍愷、祖立軍
中國銀聯(liá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)歷了三個階段：
第一階段：專網(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)境下對網(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)網(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ī)?？焖僭鲩L情況下存在廣播風(fēng)暴的風(fēng)險；二、在營銷活動等訪問量暴增的情況下，網(wǎng)絡(luò)能夠根據(jù)應(yīng)用重要性與鏈路情況實現(xiàn)對流量的智能調(diào)度，保證核心業(yè)務(wù)平穩(wěn)運行；三則是在計算資源不充足的情況下，網(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ù)平面與控制平面相分離，從而實現(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)境下安全與高效并重；
高性能，面對秒殺等新業(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ù)可視和故障快速定位、排查能力，使日常運維從大量人工維護的高工作量解放出來；
（二）金融私有云與行業(yè)云對網(wǎng)絡(luò)需求的異同分析
雖然金融私有云與行業(yè)云本質(zhì)上都承載金融業(yè)務(wù)，但是由于應(yīng)用場景與服務(wù)模式上的不同，也使得金融私有云與行業(yè)云對網(wǎng)絡(luò)的需求有所差異。在表1中，我們基于上面提出網(wǎng)絡(luò)需求的6個維度，對金融私有云與行業(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)絡(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ò)資源池管理操作、上層異構(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)
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ò)可能更準確一些，負責(zé)數(shù)據(jù)中心與外部網(wǎng)絡(luò)的連通，其與外部骨干網(wǎng)連接，主要設(shè)備包括邊緣路由器。
網(wǎng)絡(luò)分區(qū)確定后，隨后就根據(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的解決方案中，網(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軟硬方案的研究測試工作均已完成，兩套方案全部落地生產(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 整體方案能力設(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)致的廣播風(fēng)暴會對網(wǎng)絡(luò)造成極大的損傷，因此本方案中將會針對該問題進行解決；二是優(yōu)化網(wǎng)流路徑，精簡網(wǎng)流數(shù)據(jù)的處理節(jié)點，進一步減少網(wǎng)流轉(zhuǎn)發(fā)中存在的風(fēng)險點，并且打破集中式的網(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ā)，而且足夠快速和靈活，這就要求我們對方案具備自主可控的能力，采用商業(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)充分考慮當前數(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)流轉(zhuǎn)發(fā)交換，并通過OVSDB與Openflow協(xié)議與控制器對接，其中OVSDB負責(zé)對OVS進行配置，Openflow則負責(zé)實現(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ī)模的不斷擴大，多租戶也必將成為私有云的必需。一方面多租戶技術(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)用部署靈活性。
在具體能力實現(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)，所以在此不對其分布式實現(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）防火墻并聯(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流表來進行轉(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)橋，其中br-ex主要負責(zé)南北向通信，連接外部網(wǎng)絡(luò)和br-int網(wǎng)橋，且只有一個Table 0，功能比較簡單；而br-int則負責(zé)虛擬機的接入，并實現(xiàn)大部分的網(wǎng)絡(luò)能力，包含了Table0、10、20到110共12個Table，功能較為復(fù)雜。各個Table的具體功能如下所示。
CLASSIFIER Table0 “流量分類”
DIRECTOR Table10 “Director”
ARP_RESPONDER Table20 “分布式ARP應(yīng)答”
INBOUND_NAT Table30 “入站流量浮動IP流量DNAT”
EGRESS_ACL Table40 “出口訪問控制”
LOAD_BALANCER Table50 “分布式負載均衡”
ROUTING Table60 “分布式路由”
L3_FORWARDING Table70 “3層轉(zhuǎn)發(fā)”
L2_REWRITE Table80 “2層重寫服務(wù)”
INGRESS_ACL Table90 “入口訪問控制”
OUTBOUND_NAT Table100 “訪問外部網(wǎng)絡(luò)流量的SNAT”
L2_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)邏輯串聯(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ū)域互聯(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)部絕大部分仍使用硬件防火墻。而硬件防火墻往往不支持如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)生兩個子問題：
綜上所述，要實現(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，接收到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:0x28->tun_id,goto_table:20
當檢測到其它區(qū)域發(fā)來的流量時，檢測Vlan號和網(wǎng)段是否屬于本區(qū)域并且對應(yīng)關(guān)系一致，如果該流量的目的終端確實在本區(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ù)：programBrexFlowEntry
流表邏輯實現(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ù)：programVlanToVxlanFlowEntry
文件：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)才能發(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)。在這里需要考慮兩點：第一路由器與防火墻之間是Vlan模式的網(wǎng)絡(luò)，因此流量在通過路由器的時候應(yīng)打上Vlan標簽；第二每個租戶有各自的防火墻接口，接口的MAC地址要進行獲取。最終流表實現(xiàn)如下：
table=60,priority=4096,IP,tun_id=0x1e,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ò)上租戶防火墻接口的mac地址，根據(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ù)：resolveMacAddressWithVlanTag
流表邏輯實現(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
文件：net-virt-providers/src/main/java/org/opendaylight/netvirt/openstack/netvirt/providers/openflow13/services/arp/ArpSender.java
函數(shù)：sendVlanTaggedArp
createVlanTaggedArpFrame
能力實現(xiàn)3：支持去Floating IP的分布式路由
原生ODL實現(xiàn)方式
在能力設(shè)計中，我們提出采用分布式路由的實現(xiàn)方式。在ODL原生方案中，也對分布式路由進行了實現(xiàn)，具體實現(xiàn)方式如下圖9所示。
圖9 原生ODL分布式路由實現(xiàn)示意圖
從圖9可以看出，原生ODL的分布式路由機制則在每個節(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進行南北向通信的方式相吻合。所以在原生的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)的Floating 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。
因為Floating 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ù)流到達云網(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)，就必須解決下面兩個問題：
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:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xf84abf5a2bea->NXM_NX_ARP_SHA[],load:0xac100164->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請求后，所有物理節(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=0x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47->eth_dst,goto_table:80（三層轉(zhuǎn)發(fā)）
table=110, tun_id=0x5a,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=0x5a,nw_dst=10.0.0.3 actions=set_field:fa:16:3e:99:df:47->eth_dst,goto_table:80（三層轉(zhuǎn)發(fā)）
table=110, tun_id=0x5a,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=0x5a,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/org/opendaylight/netvirt/openstack/netvirt/api/ArpProvider.java
函數(shù)：programPFWProviderArpEntry
文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/PortHandler.java
流表邏輯實現(xiàn)
文件：net-virt/src/main/java/org/opendaylight/netvirt/openstack/netvirt/impl/DistributedArpService.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/services/L3ForwardingService.java
函數(shù)：programForwardingTableEntry
3.跨區(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_id=0x3e8,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:02:02:02:02:02:02->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0x020202020202->NXM_NX_ARP_SHA[],load:0x0a010101->NXM_OF_ARP_SPA[],IN_PORT
Table20匹配tun_id為1000，目標IP為10.1.1.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:04:04:04:04:04，給報文打上VLAN TAG 100，并將報文轉(zhuǎn)發(fā)至br-ex。具體流表如下：
table=60, priority=4096,IP,tun_id=0x3e8,Vlan_tci=0x0000/0x1fff,nw_src=10.1.1.0/24,nw_dst=10.2.0.0/16 actions=push_Vlan:0x8100,set_field:4196->Vlan_vid,set_field:04:04:04:04:04:04 ->eth_dst,dec_ttl,output:1
br-ex
接收到報文進行流表匹配后，最終會匹配到優(yōu)先級最低的NORMAL流表，NORMAL action會以普通交換機的行為轉(zhuǎn)發(fā)報文，也就是根據(jù)MAC地址和端口的對應(yīng)關(guān)系轉(zhuǎn)發(fā)，具體流表如下：
table=0, priority=0 actions=NORMAL
br-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)ARP請求，ARP代答流表如下：
table=20,priority=1024,arp,dl_Vlan=200,arp_tpa=172.16.2.1,arp_op=1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:06:06:06:06:06:06->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0x060606060606->NXM_NX_ARP_SHA[],load:0xac100201->NXM_OF_ARP_SPA[],IN_PORT
響應(yīng)防火墻ARP請求后，防火墻會將IP報文發(fā)送到響應(yīng)的主機host2，通過eth0網(wǎng)卡進入OVS，開始流表匹配。首先br-ex上的引流流表將外部區(qū)域訪問本區(qū)域的流量轉(zhuǎn)發(fā)到br-int，匹配VLAN ID 為200，目標IP為10.2.1.0/24的報文，轉(zhuǎn)發(fā)到br-int。具體流表如下：
table=0, priority=2048,IP,dl_Vlan=200,nw_dst=10.2.1.0/24 actions=output:2
br-int收到流量后對報文進行VLAN到VXLAN的轉(zhuǎn)換，匹配VLAN ID為200，目標IP為10.2.1.0/24，從br-ex發(fā)來的IP報文，去掉VLAN TAG，打上相應(yīng)的VXLAN ID并交給之后的table繼續(xù)處理。具體流表如下：
table=0,priority=2048,in_port=1,IP,dl_Vlan=200,nw_dst=10.2.1.0/24 actions=strIP_Vlan, set_field:0x7d0->tun_id,goto_table:20
報文不會匹配到table20到table60的處理流程，在table70匹配到三層轉(zhuǎn)發(fā)流表，根據(jù)報文的VXLAN ID，目標IP地址，將報文的目標MAC地址修改為目標IP地址對應(yīng)的MAC地址，并交給之后的table繼續(xù)處理，具體流表如下：
table=70,priority=1024,IP,tun_id=0x7d0,nw_dst=10.2.1.3 actions=set_field:08:08:08:08:08:08 ->eth_dst,goto_table:80
報文不會匹配到table80到table100的處理流程，在table110匹配到二層轉(zhuǎn)發(fā)流表，根據(jù)報文的VXLAN ID，目標MAC地址，轉(zhuǎn)發(fā)到相應(yīng)的虛擬機端口。如果目標MAC對應(yīng)的虛擬機不在本節(jié)點，則轉(zhuǎn)發(fā)到目標虛擬機所在主機的VXLAN隧道端口。具體流表如下：
table=110, tun_id=0x7d0,dl_dst=08:08:08:08:08:08 actions=output:2
至此，VM1的數(shù)據(jù)包發(fā)送至另一個區(qū)域的VM2，VM2收到數(shù)據(jù)后，會按照上述步驟將響應(yīng)數(shù)據(jù)返回，跨區(qū)域通信結(jié)束。
五、原型實踐與效果
（一）物理架構(gòu)概述
由于是軟件SDN方案，實現(xiàn)網(wǎng)絡(luò)功能的模塊分布在每臺服務(wù)器上，復(fù)雜性也卸載到SDN控制器和每臺服務(wù)器上，所以物理架構(gòu)相對比較簡單。下圖展示了原型平臺的物理架構(gòu)，整體架構(gòu)由兩個云網(wǎng)區(qū)域和一個RI區(qū)域組成。RI區(qū)域由兩臺交換核心設(shè)備和兩個區(qū)域各一臺的區(qū)域核心設(shè)備組成。區(qū)域核心下聯(lián)區(qū)域防火墻，防火墻下聯(lián)交換機，交換機接入服務(wù)器。
圖15 原型平臺物理架構(gòu)圖
我們在中國銀聯(lián)的數(shù)據(jù)中心實驗環(huán)境搭建了原型平臺，平臺由兩個SDN云網(wǎng)分區(qū)組成，云網(wǎng)分區(qū)包含接入交換機，服務(wù)器，同時配備了防火墻。平臺基于OpenStack、OVS、ODL、Centos等開源軟件進行研發(fā)，相應(yīng)軟件版本情況見如表2所示。
表2 軟件版本情況表（二）管理控制平面概述
本次原型實踐使用OpenStack作為云平臺來管理虛擬資源的生命周期，向上提供標準API供用戶使用，向下通過SDN控制器，防火墻驅(qū)動來實現(xiàn)對下層網(wǎng)絡(luò)資源的抽象、隔離和調(diào)度。其中網(wǎng)絡(luò)的控制平面使用ODL而非原生OpenStack的Neutron網(wǎng)絡(luò)功能，ODL提供ML2和GBP的方式和OpenStack集成，本次實踐使用ML2的方式。
（三）云網(wǎng)與云控平臺集成
OpenStack需要管理我們實踐環(huán)境中的二層虛擬網(wǎng)絡(luò)，三層虛擬路由，以及防火墻，其中二層和三層的功能由ODL提供，防火墻功能由Neutron直接控制獨立的防火墻實現(xiàn)。
ODL與OpenStack的集成需要兩個平臺的接口來實現(xiàn)。如圖16所示，OpenStack的networking-odl項目提供ODL ML2 mechanism driver替代OVS driver，ODL L3 Plugin替代原生L3 agent。
圖16 Neutron集成模塊示意圖
OpenStack Neutron的ODL ML2 Driver通過REST API將Neutron請求發(fā)送到ODL的北向接口，ODL的Neutron Northbound和Netvirt項目分別提供對應(yīng)Neutron的北向接口和業(yè)務(wù)邏輯，其中MD-SAL是ODL內(nèi)部的數(shù)據(jù)交互模塊。南向接口OVSDB Southbound和OpenFlow Southbound Plugin分別通過OVSDB和OpenFlow協(xié)議操作OVS。
下面我們詳細介紹每個模塊的具體集成方式。
1.ODL與OpenStack集成
本次原型實踐使用ODL的netvirt模塊與OpenStack Neutron集成，需要OpenStack和ODL兩個平臺的接口實現(xiàn)。
OpenStack方面，需要在控制節(jié)點，網(wǎng)絡(luò)節(jié)點，計算節(jié)點做以下配置的變更：
（1）控制節(jié)點
修改配置，使用ODL ML2 mechanism driver替代OVS mechanism driver；
修改配置，使用ODL L3 plugin替代原生OpenStack的L3 plugin；
配置ODL的訪問路徑和認證方式。
（2）網(wǎng)絡(luò)節(jié)點
停止原生OVS agent，OVS由ODL控制；
停止原生L3 agent，三層服務(wù)由ODL提供；
DHCP服務(wù)使用OpenStack原生的DHCP agent；
metadata服務(wù)使用OpenStack原生的metadata agent。
（3）計算節(jié)點
停止原生OVS agent，OVS由ODL控制；
ODL方面，需要安裝包含netvirt的feature odl-OVSdb-OpenStack并修改配置，打開ODL L3功能。
2.ODL與OVS集成
如圖17所示，OVS主要由兩個用戶態(tài)進程OVSdb-server、OVS-vswitchd和OVS內(nèi)核模塊組成，其中OVSdb-server接收OVSDB協(xié)議的消息，保存bridge，port等信息到數(shù)據(jù)庫，并通知OVS-vswitchd創(chuàng)建相應(yīng)對象。OVS-vswitchd同時接收OpenFlow協(xié)議的消息，操作OVS中的流表，最終使流表在內(nèi)核模塊中生效。
ODL提供了OVSDB southbound和OpenFlow Southbound Plugin兩種南向接口來操作OVS，其中OVSDB southbound操作OVS上的bridge，port等元素，OpenFlow Southbound Plugin操作OVS上的流表。
圖17 OVS集成模塊示意圖
OVS集成ODL需要在所有計算節(jié)點做以下配置：
將OVS的manager設(shè)置為ODL，ODL會在OVS上創(chuàng)建兩個bridge：br-int和br-ex，并會自動將這兩個bridge的控制器設(shè)置為ODL，之后ODL就可以通過OVSDB和OpenFlow來控制OVS。
3.防火墻集成
在原型環(huán)境中我們使用Neutron FWaaS來驅(qū)動防火墻。
OpenStack為防火墻服務(wù)提供了V1.0和V2.0兩種API模型， FWaaS 2.0在社區(qū)M版本中提出，現(xiàn)在仍在開發(fā)中，因此我們采用FWaaS 1.0 模型和防火墻設(shè)備進行集成。
防火墻服務(wù)被抽象成多種虛擬資源，分別是firewall，policy和rule。一個firewall可以關(guān)聯(lián)應(yīng)用到多個router，一個firewall使用一個policy，policy是rule的集合。
在原型環(huán)境中，防火墻物理上位于服務(wù)器和區(qū)域核心中間，邏輯上串聯(lián)在租戶虛擬路由和區(qū)域核心中間。在我們的環(huán)境中防火墻同時也承擔路由器的作用，所以FWaaS除了需要驅(qū)動防火墻下發(fā)安全規(guī)則外，還需要在防火墻上配置路由，具體包括：
一條默認路由指向上層的區(qū)域核心，用于將目標是其他區(qū)域的流量送到區(qū)域核心
數(shù)條靜態(tài)路由指向下層的租戶虛擬路由，用于將目標是本區(qū)域的流量送到虛擬路由。
除此以外，為了支持多租戶通信，創(chuàng)建每個防火墻實例時FWaaS驅(qū)動需要相應(yīng)地在物理防火墻上創(chuàng)建context，創(chuàng)建內(nèi)向流量internal和外向流量external的Vlan子接口并加入context中。
（四）整體網(wǎng)絡(luò)架構(gòu)
原型環(huán)境的整體網(wǎng)絡(luò)架構(gòu)由云網(wǎng)分區(qū)和RI區(qū)域組成，其物理組網(wǎng)方式仍為Vlan模式，兩個云網(wǎng)分區(qū)連接到RI互聯(lián)區(qū)域。
防火墻和RI區(qū)域之間通過路由控制，防火墻以下的網(wǎng)絡(luò)由ODL下發(fā)的OpenFlow流表控制。
服務(wù)器分別連接到一個管理網(wǎng)絡(luò)，一個通往防火墻的VLAN網(wǎng)絡(luò)，以及一個區(qū)域內(nèi)通信的VXLAN隧道網(wǎng)絡(luò)。
虛擬機之間的網(wǎng)絡(luò)通信大致可以分為以下三種場景：
區(qū)域內(nèi)同網(wǎng)段虛擬機二層通信，ARP代答流表會替目標虛擬機代答ARP請求，并接收通信報文，根據(jù)目標MAC地址和VXLAN ID，通過VXLAN隧道送到指定的節(jié)點，再匹配二層轉(zhuǎn)發(fā)流表送到OVS的相應(yīng)端口上。
區(qū)域內(nèi)不同網(wǎng)段虛擬機三層通信，ARP代答流表會替網(wǎng)關(guān)代答ARP請求，OVS接收報文，匹配流表，由路由流表模擬路由功能并將報文的目標MAC地址修改為目標虛擬機的MAC地址，根據(jù)目標MAC地址和VXLAN ID，通過VXLAN隧道送到指定的節(jié)點，再匹配二層轉(zhuǎn)發(fā)流表送到OVS的相應(yīng)端口上。
跨區(qū)域通信，發(fā)送出區(qū)域時，ARP代答流表會替網(wǎng)關(guān)代答ARP請求，OVS接收報文，匹配流表，靜態(tài)路由流表會將報文的目標MAC地址修改為防火墻接口的MAC地址，給報文加上VLAN TAG，并通過VLAN網(wǎng)絡(luò)送到防火墻。兩個區(qū)域防火墻之間由路由控制。接收進區(qū)域時，ARP代答流表會響應(yīng)防火墻對虛擬路由器接口地址的ARP請求。VLAN到VXLAN轉(zhuǎn)換流表會卸載報文VLAN TAG并打上目標網(wǎng)絡(luò)的VXLAN ID。如果目標虛擬機位于本節(jié)點，由二層轉(zhuǎn)發(fā)流表送到虛擬機端口，如果目標虛擬機位于其他節(jié)點，由二層轉(zhuǎn)發(fā)流表通過VXLAN隧道送到相應(yīng)節(jié)點，再由相應(yīng)節(jié)點的OVS接收。
原型環(huán)境的整體網(wǎng)絡(luò)部署架構(gòu)如圖18所示：
圖18 原型環(huán)境整體網(wǎng)絡(luò)部署架構(gòu)圖
（五）效果展示
1.跨區(qū)域網(wǎng)絡(luò)拓撲
原型平臺基于多租戶能力，創(chuàng)建了兩個金融機構(gòu)租戶，兩個租戶的網(wǎng)絡(luò)地址完全隔離復(fù)用，每個租戶橫跨基于ODL的軟件SDN方案的兩個云網(wǎng)分區(qū)資源，且共同復(fù)用所有硬件資源，通過核心交換網(wǎng)絡(luò)進行數(shù)據(jù)互通，最終網(wǎng)絡(luò)拓撲如圖19所示。
圖19 整體網(wǎng)絡(luò)拓撲圖
在此拓撲中，租戶進行跨區(qū)域資源訪問測試，可以相互通信，如圖20所示。
圖20 跨區(qū)域通信ping測結(jié)果圖
2.性能測試
方案實現(xiàn)后，我們在萬兆環(huán)境下對該方案進行了性能測試，并且與之前應(yīng)用的Nuetron方案進行了對比。
（1）測試環(huán)境
硬件環(huán)境：CPU Intel E5-2630 V3； 網(wǎng)卡 Intel 82599；
軟件環(huán)境：操作系統(tǒng) Centos7.2；云平臺 OpenStack L版； 測試工具 IPerf；
測試項時長：5分鐘。經(jīng)與10分鐘測試時長比對，5分鐘測試時長所得數(shù)據(jù)已足夠平穩(wěn)、精確，所以本次測試時長為5分鐘；
測試包長：在單對虛機性能測試，測試包長的選取參考了RFC2544，分別是134、256、512、1024、1280、1456，其中134和1456是IPerf支持的最小和最大包長；在隨后的極限性能測試中，采用最大包長1456進行測試。
（2）單對虛擬機性能測試數(shù)據(jù)（虛擬機配置：8c32g）
在測試中，我們首先測試了單對虛擬機的數(shù)據(jù)轉(zhuǎn)發(fā)性能，在結(jié)果中挑選了部分代表性數(shù)據(jù)如表3所示。
表3 單對虛擬機性能測試數(shù)據(jù)表（3）極限性能測試數(shù)據(jù)
在本項測試中，逐步增加虛擬機數(shù)量，在同網(wǎng)段不同主機的場景下，采用最大包長測試跨主機通信的極限性能（帶寬），得到數(shù)據(jù)如下圖21所示。
圖21 極限性能測試數(shù)據(jù)圖
測試結(jié)果：在跨物理機通信的情況下，ODL與Neutron方案的極限帶寬分別為3.17G與1.93G，ODL高出Neutron 64.2%。
（4）測試結(jié)果分析
通過測試，我們發(fā)現(xiàn)雖然ODL方案在萬兆環(huán)境下的性能依然高于Neutron方案，但整體測試數(shù)據(jù)不佳，最高帶寬只能達到3.17G，僅占整體帶寬的30%，不能對網(wǎng)絡(luò)資源進行較高效率的利用。
經(jīng)過分析，我們認為產(chǎn)生該問題的主要原因是因為硬件網(wǎng)卡不支持Vxlan offload功能造成的。具備Vxlan offload功能的網(wǎng)卡，能夠識別Vxlan數(shù)據(jù)包并對包頭進行相應(yīng)的處理，將原本在協(xié)議棧中進行的分片、TCP分段、重組、checksum校驗等操作，轉(zhuǎn)移到網(wǎng)卡硬件中進行，降低系統(tǒng)CPU的消耗，提高處理性能，能夠在使用Vxlan通信的情況下較大幅度的提升帶寬。而本次測試中使用的Intel 82599網(wǎng)卡則不具備該功能，所以造成總體性能較低。
六、總結(jié)與展望
（一）工作總結(jié)
通過本次研究我們形成了許多技術(shù)積淀。首先，我們根據(jù)實際需求，設(shè)計出一整套的軟件SDN解決方案，包括整體的網(wǎng)絡(luò)架構(gòu)、能力設(shè)計與流表框架，相比其它方案來說，優(yōu)勢如下：
1.整體完全自主可控；
2.方案按照金融需求設(shè)計，相比其它方案更能貼合金融場景下的應(yīng)用；
3. 相比商業(yè)方案更加靈活、成本更低。
其次我們通過對ODL的開發(fā)，對原生的能力進行了增強與優(yōu)化，掌握了軟件控制器功能定制化的能力；最后，在性能測試中，對Linux環(huán)境下的網(wǎng)絡(luò)接收性能調(diào)優(yōu)也進行了相關(guān)的研究，這對于我們來說也是很好的一次技術(shù)積累。
雖然當前方案已經(jīng)實現(xiàn)，但是在具體的實踐過程中仍存在一些問題有待解決，具體如下：
1.支持去Floating IP的分布式網(wǎng)關(guān)功能仍不完善，目前平臺內(nèi)分布式的外部接口進行ARP響應(yīng)會造成交換機的MAC表震蕩，當平臺物理節(jié)點的數(shù)量較多的時候會影響網(wǎng)絡(luò)穩(wěn)定。因此，后續(xù)我們會對該實現(xiàn)機制進行進一步的優(yōu)化，采用定向下發(fā)ARP響應(yīng)流表的方式進行功能實現(xiàn)；
2.本方案中只實現(xiàn)了通過Vlan連接物理防火墻的流表框架，其實通過Vxlan連接虛擬防火墻的流表我們也設(shè)計了出來，只不過當前應(yīng)用場景較少所以沒有在控制器上進行能力實現(xiàn)。后續(xù)隨著NFV技術(shù)在金融行業(yè)的推廣應(yīng)用，我們也會擇機對該Vxlan的連接方案進行實現(xiàn)；
3.萬兆環(huán)境下網(wǎng)絡(luò)性能極限測試效果不佳，具體原因已經(jīng)在上文中進行了分析，后續(xù)將優(yōu)化測試環(huán)境，更換具備相應(yīng)能力的網(wǎng)卡進行進一步測試；
4.控制器的高可用性仍待加強，針對ODL控制器的高可用方案社區(qū)中也沒有給出較好的方法，所以在后續(xù)工作中也希望能得到更多業(yè)內(nèi)專家們的幫助與支持。
（二）展望
中國銀聯(lián)正積極探索軟件定義網(wǎng)絡(luò)技術(shù)在下一代金融云環(huán)境中的深化研究與應(yīng)用，并已與中國銀行、中國農(nóng)業(yè)銀行、中國工商銀行、中國建設(shè)銀行、中國交通銀行、興業(yè)銀行、恒豐銀行、上海銀行等機構(gòu)就SDN技術(shù)在金融行業(yè)中的應(yīng)用與聯(lián)合研究需求進行了緊密溝通。當前結(jié)合各單位聚焦研究點，中國銀聯(lián)已發(fā)起“跨數(shù)據(jù)中心多云協(xié)同資源管理技術(shù)”的聯(lián)合研究課題，希望更多的銀行等金融合作機構(gòu)能夠參與到相關(guān)的研究工作中，共同推進軟件定義網(wǎng)絡(luò)相關(guān)的金融科技聯(lián)合研究與應(yīng)用。
（本次工作感謝英特爾、華為、思科、復(fù)旦大學(xué)電子金融實驗室、九州云等單位參與聯(lián)合研究）
總結(jié)
以上是生活随笔為你收集整理的基于开源SDN控制器的下一代金融云网络的研究与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 高中函数知识点太多记不住？一张思维导图教
- 下一篇： 每日新闻丨三大运营商公布5G套餐；华为云