基於開源SDN控制器的下一代金融雲網路的研究與實踐
作者及來源
本文由以下單位作者聯合研究寫作，轉載請註明出處。
電子商務與電子支付國家工程實驗室（中國銀聯電子支付研究院）：袁航、周雍愷、祖立軍
中國銀聯信息總中心：任明、吳一娜
中國銀行數據中心：許泓
一、行業發展歷程與技術發展趨勢
（一）行業發展歷程
金融數據中心網路技術架構與行業安全、合規等特色性要求緊密結合，是金融數據中心顯著區別與其他行業數據中心的關鍵領域，是金融數據中心建設中的核心。中國金融數據中心網路建設的歷程與金融行業近三十年信息化過程密不可分，總結歸納金融數據中心網路的發展主要經歷了三個階段：
第一階段：專網專用階段。該階段是採用特有的網路協議來對專用設備進行連通，如IBM的專有網路協議SNA對其大型機與中型機的支持；
第二階段：基於IP協議，分層分區。在本階段採用了更為開放通用的IP技術協議，不再受制於某個廠商，組網更加靈活。此外，本階段中雖然各金融機構的網路架構跟隨應用系統的發展而變化，但一般會出於應用分層及安全的要求，遵循「垂直分層、水平分區」的理念。
第三階段：大規模共享接入。技術上更為開放，網路虛擬化與SDN等技術開始在金融行業應用。在繼承安全區域保護機制下，採用「匯流排型、模塊化」架構，中國的金融數據中心網路結構趨於一致，並且普遍採用網路虛擬化共享接入的技術方案，對新的雲計算環境下對網路的靈活、彈性等要求進行有效應對。
（二）技術發展趨勢
近年來，隨著金融數據中心雲化的加速，金融雲作為最新的基礎設施形態開始被行業認同並接納。但在金融雲環境下，傳統網路技術架構受到了挑戰：一方面虛擬化思想的出現，顛覆了原有的數據中心網路模型，使得傳統網路技術已不足以適配雲環境下產生的新場景，如虛擬機的出現要求網路顆粒度從物理機細化到了虛擬機級別；另一方面面向互聯網的金融創新業務的快速發展，也會對網路的性能、彈性等特性提出更高的要求。所以未來金融數據中心網路技術必將進行變革式的創新發展，我們認為未來發展趨勢主要包括以下三點：
1、面向互聯網新興業務的敏捷網路,即未來金融雲網路能夠高效滿足互聯網方式下金融創新應用的多樣化需求。一是網路資源的快速提供與開通，以支撐應用的快速投產；二是強化細粒度的網路策略管控能力，在應用需求的頻繁變化的情況下，網路能夠進行靈活地變更調整；三是網路可兼容多樣化的資源類型接入，以融合網路方式實現虛擬機、容器、物理機不同資源的統一接入。
2、面向數據中心資源動態變化的彈性網路，即在大流量挑戰下保證網路的平穩運行。一是金融雲規模巨大，承載業務系統眾多，要求網路必須具備足夠的容量與健壯性，比如如何解決網路規模快速增長情況下存在廣播風暴的風險；二、在營銷活動等訪問量暴增的情況下，網路能夠根據應用重要性與鏈路情況實現對流量的智能調度，保證核心業務平穩運行；三則是在計算資源不充足的情況下，網路能夠連通分布在不同物理位置的計算資源池，打破由於物理區域隔離所造成的資源容量限制。
3、面向數字化智能化運維模式的網路，即在網路運維壓力暴增的情況下，能夠做到先於業務發現網路問題。一方面，金融行業數據中心規模不斷擴張，網路終端數量與網路模型複雜度都呈幾何式增長，必須採用高效、出錯率低自動化運維代替傳統的手工方式；另一方面，在金融雲的新常態下，網路運維模式需要形成閉環來提升自身價值，通過對流量數據的採集分析，實現對網路的問題預測、排障、優化，甚至做到對網路攻擊的規避，提升整體網路的穩定性。
軟體定義網路（SDN）技術通過分散式架構理念，將網路中數據平面與控制平面相分離，從而實現了網路流量的靈活控制，為核心網路及應用的創新提供了良好的平台，其與金融雲網路發展趨勢相契合，是實現金融雲網路服務的有效支撐技術。
二、以金融云為載體的創新網路需求
（一）金融雲對網路的創新需求
基於上述金融雲網路的發展趨勢，結合金融業務面向互聯網的挑戰，我們認為未來金融雲網路需求可總結為高安全、高敏捷、高性能、高可用、高彈性與高可管理：
高安全，金融業務的特殊性對承載網路的第一要求即為保證數據的安全性，因此金融雲網路必須具備能夠抵禦系統外部攻擊，保證數據完備性與私密性的能力；
高敏捷，實現業務快速上線，面對應用的變化達到資源的按需變更，通過新技術應用打破因重安全而舍效率的困局，在雲計算新環境下安全與高效並重；
高性能，面對秒殺等新業務場景等的極限服務能力，實現時延和帶寬等關鍵指標的跨越式提升，同時注重資源的高效利用，用儘可能少的資源實現最大的性能服務。
高可用，網路架構持續穩定影響金融數據中心全局服務能力，網路架構需要基於穩定可靠的技術構建，使網路服務具備7*24小時業務連續性服務的能力；
高彈性，一是內部彈性強化，打破豎井式架構中網路區域成為限制資源共享的壁壘，實現網路資源池整合與靈活共享與隔離，二是外部彈性兼容，支持新老架構並存，從而使原有網路可以平滑過渡到新架構；
高可管理，一是實現管理的體系的簡化，支持多品牌的融合管理，二是實現管理自動化與智能化，提供端到端的業務可視和故障快速定位、排查能力，使日常運維從大量人工維護的高工作量解放出來；
（二）金融私有雲與行業雲對網路需求的異同分析
雖然金融私有雲與行業雲本質上都承載金融業務，但是由於應用場景與服務模式上的不同，也使得金融私有雲與行業雲對網路的需求有所差異。在表1中，我們基於上面提出網路需求的6個維度，對金融私有雲與行業雲網路需求的異同進行分析。
表1 金融私有雲與行業雲對網路需求的異同
三、下一代金融雲SDN網路的設計原則與架構規劃
（一）網路設計原則
SDN技術的應用顛覆式地改變了金融數據中心網路架構，因此基於對網路發展趨勢與具體需求的分析，在雲環境下構建新一代的SDN網路需進行針對性的設計。據此我們提出了以下三條設計原則：
1.根據不同網路邊界分層構建網路資源池
從能力層面來看，網路作為一種基礎設施資源，應構建統一的雲網路資源池，打破傳統網路豎井式架構，提升計算、存儲資源調用的靈活性；從管理與安全層面看的話，因為不同網路區域能力不同，在數據中心網路中的角色不同，所以應根據對不同網路區域分別構建資源池。
2.網路能力全部服務化實現
面向服務理念，對每層網路功能以服務、標準API介面的形式對外提供，網路系統內部以服務的形式進行自組織，從而提升對外服務能力，簡化外部調用網路能力的複雜性；
3.網路資源統一編排管理
數據中心內網路二/三層連通、四/七層功能的管理界面統一視圖，不同網路資源池的管理採用二級管理編排方式，即底層適配不同網路資源池管理操作、上層異構協調編排。
（二）網路架構
根據上述網路設計原則，我們規划了金融數據中心的整體網路架構如下圖1所示。
圖1 金融數據中心整體網路架構
首先，我們根據數據中心網路構成，將整體網路分成了三個部分，具體如下：
1.區域網路，也就是我們常說的一個雲平台Region的網路，業務系統就運行在該區域內。其網路方案可分為硬體方案和軟體方案。網路設備包括區域交換機、區域內控制器、負載均衡；
2.核心網，核心網就是連通各個區域的網路，主要設備包括核心交換機；
3.數據中心網路，其實稱為數據中心外聯網路可能更準確一些，負責數據中心與外部網路的連通，其與外部骨幹網連接，主要設備包括邊緣路由器。
網路分區確定後，隨後就根據各個分區的能力邊界構建各自的網路資源池，並對各個資源池能力進行標準的API介面化實現。
最後，在頂層設計一個統一的網路能力編排系統，將各個資源池的能力通過API對接的方式進行上收，隨後根據許可權配置將不同網路區域的能力下放至相應的管理員與應用系統。
四、基於ODL開源控制器的數據中心內SDN網路方案研究與實現
SDN方案分為硬體和軟體兩大類。硬體SDN是採用專用的硬體交換設備與控制器來實現相關的網路功能，控制器對硬體設備進行策略以及流表的下發，來實現網路相關的功能。它的優點是性能強，比較穩定，缺點是不靈活且組網成本很高。業界常見的硬體方案包括思科的ACI，華為AC、華三VCF等。
而在軟體SDN的解決方案中，網路的功能是通過軟體層面的Linux協議棧以及相關的虛擬交換機技術實現的。它的優點可以避免對硬體網路設備的過度依賴，同時降低了組網的成本，缺點是穩定性、性能和可擴展性不如硬體方案。常用的軟體方案包括Neutron+OpenvSwitchOpenDayLight+OpenvSwitch等。
下面對銀聯當前對SDN應用研究的現狀進行介紹。
（一）銀聯SDN應用研究現狀
中國銀聯自2014年啟動軟體定義網路（SDN）技術在金融雲環境下的應用研究，長期跟蹤SDN技術在國內外金融行業的研究進展，並積極推動SDN技術在銀聯生產環境的應用以及與銀行金融機構的合作研究。目前，銀聯對SDN軟硬方案的研究測試工作均已完成，兩套方案全部落地生產。
銀聯私有生產雲採用華為SDN整體硬體方案，銀聯生產託管雲則採用Neutron+OpenvSwitch的軟體SDN方案。當前實現了網路二/三層、負載均衡、防火牆等多網路資源服務，承載了近期銀聯與相關合作金融機構的關鍵應用，有效支撐了銀聯業務創新。
當前，銀聯結合當前生產現狀與行業技術發展趨勢，開展下一代金融SDN相關技術研究工作。目前主要針對金融數據中心區域內的軟體SDN方案進行進一步研究優化，從而滿足下一代金融雲的網路要求。下圖2中的紅色範圍即為本次研究工作的定位。
圖2 本次研究工作定位示意圖
（二）下一代金融雲網路軟體SDN網路方案
1.方案設計與實現思路
圖3 整體方案能力設計與實現思路圖
（1）首先在對方案的能力設計上，我們結合了當前金融數據中心針對軟體SDN方案的需求來進行規劃，主要圍繞三點：
※首先性能是軟體SDN方案較硬體方案來說比較明顯的短板，在性能上我們從兩個層面上進行優化。一是要簡化物理機內部的網流轉發路徑，如Neutron方案下物理機內部的網橋有三層，過多的網橋數量勢必減緩對網路數據的處理速度，所以要簡化；二是要優化物理機外部的網流轉發路徑，如Neutron方案下所有跨網段通信的流量全部要繞至專門的網路節點進行路由轉發，給性能帶來較大的影響。
※然後是金融行業著重關注的穩定性上，我們也有相關的能力設計考慮。一是由於節點數量的規模快速增長所導致的廣播風暴會對網路造成極大的損傷，因此本方案中將會針對該問題進行解決；二是優化網流路徑，精簡網流數據的處理節點，進一步減少網流轉發中存在的風險點，並且打破集中式的網路瓶頸，採用分散式架構實現。
※最後是為應對業務流量的突髮式增長，方案在支撐資源的可擴展性上也有相關考慮。主要是網路能夠打通跨區域的計算資源，並且做到在多租戶環境下實現跨區域資源的互通。
（2）其次根據方案的能力設計，我們對方案的技術選型也進行了思考與規劃，具體分為兩個層次：
※首先整體方案的技術框架我們依然選擇採用基於開源技術實現。一是因為金融行業的一些特殊需求需要對相關能力進行定製化開發，而且足夠快速和靈活，這就要求我們對方案具備自主可控的能力，採用商業軟體是做不到的；二是如果從頭進行開發將會消耗大量的時間經歷，基於開源技術則會達到快速實現的目的；
※從具體的能力技術設計上，我們會進行分散式路由、分散式ARP、跨區域互聯、防火牆並聯接入等具體的技術方案以滿足最初的能力設計。分散式路由打破了Neutron網路集中式節點處理方式，會對網路的性能、穩定性進行優化；分散式ARP將會很大程度上抑制網路中存在的廣播報文，提高網路穩定性；跨區域互聯通過對接RI系統實現；防火牆並聯的實現也避免了防火牆成為網路瓶頸。具體設計思路式會在下文中詳細闡述。
（3）最後根據方案的能力設計與技術選型，我們整理了兩點具體實現的思路。一是能力的實現方案應充分考慮當前數據中心現狀，應選取可以平滑遷移和應用的方案進行實現；二是不同能力在實現的過程中相互之間會有聯繫或影響，比如要實現高級的跨區域通信能力，就必須對底層的分散式路由、ARP代答等能力進行修善。因此在能力實現中要對這種情況進行充分預估與判斷，防止由於忽視相互之間的影響而導致能力不足或出現相關隱患。
2.整體技術框架
本次方案研究中，我們依然採用開源技術框架來進行實現。核心控制層採用開源控制器OpenDayLight（下文簡稱ODL），上層編排仍使用OpenStack的Neutron，Neutron與ODL之間使用ML2 plugin進行對接；底層數據層使用OpenvSwitch（下文簡稱OVS）進行網流轉發交換，並通過OVSDB與Openflow協議與控制器對接，其中OVSDB負責對OVS進行配置，Openflow則負責實現所有的數據轉發功能現。整體框架圖如下。
圖4 方案整體框架圖
3.能力設計
（1）基於虛擬化的多租戶支持
多租戶虛擬化網路解決方案通過Overlay網路和SDN控制器的相互配合，可以使得邏輯網路與物理網路解耦、控制平面和轉發平面分離，進而實現消除網路限制、虛機任意遷移、IP地址靈活分配的目的，從而充分滿足用戶隨時隨地接入、業務快速上線、虛機遷移及策略自動跟隨的需求。
當前多租戶已成為行業雲的基本能力要求，但是在私有雲中則會根據管理方式選擇性部署。但是我們認為隨著私有雲規模的不斷擴大，多租戶也必將成為私有雲的必需。一方面多租戶技術允許網路資源重疊，能夠緩解整體網路資源緊張的局面；另一方面多租戶概念的引入將會使得不同應用之間的網路邏輯邊界更加明顯，在方便管理的同時也使得抽象的訪問策略更加具象化，提升運維效率。
本方案中我們採用比較通用的Vxlan技術來實現多租戶的能力。
（2）跨區域互聯能力
傳統交換網路穩定有餘但靈活、高效不足。各網路分區之間計算、存儲、網路、機房物理環境等資源均為獨享模式，不同分區之間計算宿主機無法共享資源，虛擬機不允許在不同分區宿主機間漂移，計算資源利用率下降。為打破傳統分區，本方案將會對基於多租戶模式下的跨區域資源互聯進行實現，提高資源利用率與應用部署靈活性。
在具體能力實現中，我們採用與銀聯自研的區域互聯繫統（以下簡稱RI，RI具體實現方式請見文章《中國銀聯與上海銀行基於SDN的下一代金融雲網路聯合研究與應用實踐》）進行對接的方案，在數據平面通過Vlan的方式與防火牆進行連通。
（3）分散式網路功能設計
雲的本質是分散式計算的一種形式，採用虛擬化技術將集中的物理資源進行切割，並通過網路將資源分散給不同用戶。因此，為了更好的契合雲計算分散式的本質，避免集中式的網路功能成為雲的瓶頸，在進行下一代金融雲網路能力設計中，我們將分散式的網路功能作為必備能力。
常用的雲網路功能包括網關、DHCP、ARP響應、防火牆在本方案中，防火牆的能力通過硬體實現，所以在此不對其分散式實現進行討論；DHCP主要作用只是在虛擬機網路發生變化時，向虛擬機下發主機名和IP地址，應用場景少、涉及流量小，並非雲網路瓶頸，對其進行分散式實現意義也較小。
而相反，在軟體雲網路方案中，網關與ARP響應兩組功能也全為軟體實現，屬於網路基礎能力，應用頻繁。網關是三層通信的流量轉發點，不同網路之間的流量通信都必須經過網關進行路由；而ARP響應則是獲取目的MAC地址的唯一途徑，是二層通信中不可或缺的流程與手段，同時也是區域內正常通信下廣播流量的主要來源。因此，對網關與ARP響應進行分散式實現將會較大幅度地提升雲網路的效率與穩定性。
綜上所述，本方案會對網關與ARP響應能力進行分散式實現。
（4）防火牆並聯方式接入
防火牆用於提供四到七層網路安全服務，實現邏輯區域之間的安全隔離。
金融雲網架構模型中，可將硬體防火牆資源進行池化部署，並按需進行調度，通過雲控制平台實現防火牆統一管理。除此之外，金融數據中在防火牆接入形態上採用物理並聯、邏輯串聯的方式，在防火牆故障的情況下仍能保證業務的正常運行，提升了業務的穩定性。在本方案中也將實現該效果。
（5）最終能力實現效果
以上能力全部實現後，最終的效果圖如下所示。
圖5 網路能力效果圖
（三）基於OpenFlow流表的能力實現
從數據平面來看，本方案中所有的數據轉發功能全部通過Openflow流表進行實現，即區域中所有的流量都由OVS依照Openflow流表來進行轉發動作；而從控制平面上看，控制器只是根據方案預先制訂的Openflow流表框架來實現到OVS的自動配置與下發的能力。所以，方案能力實現的關鍵仍在對Openflow流表的設計。
1.整體流表設計框架
OVS的網路功能主要由網橋，埠與流表等實現。一個網橋中可以包含多級流表（Table0,Table1,Table2,…），流量在轉發的過程中可以在不同的Table上進行跳轉，以實現不同的功能；同時一個Table可以包含多條流表（flow entry），對流表可進行優先順序的控制，但是只有一條流表會對進入Table的流量起作用。
原生ODL會在平台的每台物理機上創建br-int、br-ex兩個OVS 網橋，其中br-ex主要負責南北向通信，連接外部網路和br-int網橋，且只有一個Table 0，功能比較簡單；而br-int則負責虛擬機的接入，並實現大部分的網路能力，包含了Table0、10、20到110共12個Table，功能較為複雜。各個Table的具體功能如下所示。
為方便開發，本方案在流表設計中繼續沿用原生ODL的流表框架與各個流表的功能設計。同時為了實現方案的設計能力，對相關Table進行能力補足與優化，具體修改的流表如下圖6所示。
圖6 主要流表框架圖
Table 0：租戶在雲網分區內部與外部之間的標籤轉換；
Table60：防火牆物理並聯邏輯串聯接入實現；
Table 20、70、110：支持去Floating IP的分散式網關實現。
下文中會對每項功能具體實現的技術方案、詳細流表與代碼架構進行詳細說明。
2.能力優化與實現
能力實現1：多租戶環境下跨區域互聯
做到多租戶環境下的跨區域互聯主要難點在與如何對存在於不同雲網分區的租戶流量進行標記與識別，從而保證通過核心交換網路後，雲網分區可以正確將IP地址重用的多租戶流量轉發至正確的租戶資源。
在對接RI後，所有跨區域通信流量在出區域防火牆後，即通過RI在核心交換區架起的隧道到達另一區域的防火牆。不同的租戶在核心交換區對應不同的隧道，從而實現了不同區域不同租戶的流量隔離。因此，我們只需關心跨區域互聯時在區域內部的一些功能操作，而無需關心外部核心交換區域如何實現。具體如下圖7所示。
圖7 RI跨區域通信示意圖
在進行跨區域通信時我們考慮的問題有兩個：一是跨區域的流量通過什麼方式送到防火牆；二是防火牆接收到外部區域發來的跨區域訪問流量的時候，如何將該流量發送到區域內。下面我們對這兩個問題進行逐一分析。
問題一：跨區域流量通過什麼方式發送到防火牆
在考慮該問題的時候，又會衍生出新的子問題：1.火牆支持的接入方式是什麼，是否支持隧道接入；2.防火牆的物理連接方式是什麼，並聯還是串聯。
先看子問題1。在金融行業，對防火牆的性能和可用性有著比較高的要求，因此金融數據中心內部絕大部分仍使用硬體防火牆。而硬體防火牆往往不支持如Vxlan、GRE等一些隧道功能，所以一般還是採用Vlan的方式與防火牆連接。
子問題2提出了防火牆的物理連接方式。在能力設計的第四點已經提出，為保證業務運行的穩定性，降低網路故障瓶頸與影響範圍，在金融數據中心防火牆採用並聯方式接入。且為保證防火牆的性能，降低故障率，區域的外部網關不會建立在防火牆上。
既然防火牆已並聯方式接入且外部網關不在防火牆上，那麼區域內流量要發送到防火牆必須經過引流才能實現。具體引流方案我們會放在後面關於防火牆並聯接入實現的內容中，在此不做贅述。
問題二：防火牆如何將流量發送到區域內
該問題也會產生兩個子問題：
1. 防火牆如何將流量發送到區域的外部網關。該問題則是由於外部網關的分散式實現導致的，具體方案會在分散式路由實現中進行詳細描述，在此不做贅述；
2. 同樣是由於連接防火牆與區域內部網路方案的不同需要進行報文轉換，只不過這次轉換是有Vlan報文轉換為Vxlan報文。
綜上所述，要實現跨區域通信的影響面較廣，分散式網關、防火牆接入都會有所涉及。為使功能實現更加清晰，我們在這裡只對Vlan到Vxlan的報文轉換的實現方式進行描述。
流表設計
br-ex Table0：
以上流表位於br-ex Table0，接收到Vlan標籤為310、目的IP地址為10.2.1.0/24的報文並轉發到br-int。Vlan 310是該租戶在外部網路的Vlan ID，output:1則表示從br-ex的標號為1的埠發出，該埠即是br-ex 與br-int的連接埠。
br-int Table0：
當檢測到其它區域發來的流量時，檢測Vlan號和網段是否屬於本區域並且對應關係一致，如果該流量的目的終端確實在本區域，卸載Vlan號，並進行Vlan到Vxlan的映射操作，並將該流量發送到下一流表中繼續處理。
代碼架構
添加介面：
流表邏輯實現：
流表下發：
能力實現2：防火牆物理並聯邏輯串聯接入實現
在上文的問題分析中，已經提到為什麼防火牆要採用物理並聯邏輯串聯的接入方式，並且也提到通過引流方式進行實現。在本節中對實現具體方案和步驟進行詳細描述。
首先，從引流的場景看，都有哪些南北向流量需要通過引導才能發送到防火牆。在本方案中，南北向流量可分為兩種，一種是通過Floating IP被外部訪問的流量，另一種是通過內網網段信息對外通信的跨區域流量。具體如下圖8所示。
圖8 雲網區域南北向通信示意圖
對第一種南北向流量，因為帶有Floating IP地址，因此其默認下一跳就會被送至外部介面網關，因此不需要引流就會被傳送至防火牆並發出。對第二種南北向流量，其源IP和目的IP都為內網地址，其傳送的防火牆屬於跨網段通信，因此需要設置路由表對其進行引流，將去往另一個區域網段的下一跳設置在防火牆與路由器的介面上，從而實現了防火牆的引流功能。
流表實現
確定需要引流的流量後，我們就要進行引流功能的流表實現。在這裡需要考慮兩點：第一路由器與防火牆之間是Vlan模式的網路，因此流量在通過路由器的時候應打上Vlan標籤；第二每個租戶有各自的防火牆介面，介面的MAC地址要進行獲取。最終流表實現如下：
以上流表是靜態路由的實現，報文目標IP地址是另一個租戶的網段時，將目標mac地址改成外部網路上租戶防火牆介面的mac地址，根據源IP和tun_id確認租戶，設置租戶對應的的Vlan id，將報文發出。
代碼架構
添加介面：
流表邏輯實現：
流表下發：
能力實現3：支持去Floating IP的分散式路由
原生ODL實現方式
在能力設計中，我們提出採用分散式路由的實現方式。在ODL原生方案中，也對分散式路由進行了實現，具體實現方式如下圖9所示。
圖9 原生ODL分散式路由實現示意圖
從圖9可以看出，原生ODL的分散式路由機制則在每個節點上都使能一個路由器。對於東西向的流量， 流量會直接在計算節點之間傳遞。對於南北向的流量，如果有Floating IP，流量就直接走計算節點；但是對於沒有Floating IP的流量，依然要通過集中式的網路節點發送。
在一般場景應用中，區域的南北向流量都要經過NAT處理（即使用Floating IP）才能進行正常通信。如不進行NAT處理，區域內部的網段地址無法被外部網路識別，因此無法實現預期的數據轉發。
但是在本方案中，由於存在跨區域通信的場景，為了識別租戶信息，反而需要攜帶內部網路地址信息與其它區域進行通信。而該場景恰恰與上文中提到的無Floating IP進行南北向通信的方式相吻合。所以在原生的ODL設計中，該流量仍需要通過集中式的網路節點發送，這就與本方案的能力設計不符。
原理分析與問題提出
為了實現支持去Floating IP的分散式路由能力，我們需要對ODL原生分散式路由的設計方式進行進一步分析：為什麼無Floating IP的南北向流量不能使用分散式網關方式實現？為了闡述起來更直觀，我們通過下面的一個具體場景來尋找原因。
圖10 分散式網關物理結構圖
上圖是一張分散式網關的物理結構圖，由圖可看出每台物理節點的OVS都具備路由的功能。圖中六台虛擬機同屬同一租戶且分布在兩個網段中，租戶與外部網路的介面地址為172.16.1.100，同時為每台虛擬機都分配了相應的Floating IP。
在該環境下，當虛擬機在與external網路通信時，流量到達OVS上時，OVS中的相關表項會將數據包的源IP地址轉換為唯一與該虛擬機對應的Floating IP。如v1在與外部網路通信時，從v1中出來的數據包的源IP地址還是v1的IP地址，即10.0.0.1，那麼數據包到了OVS上之後，OVS根據該數據包的目的IP地址判斷出這是v1與外部網路通信的流量，這時OVS中就會有相應的流表對該數據包的源IP地址欄位進行轉換，即將10.0.0.1轉換為172.16.1.1，也就是v1的Floating IP。那麼對於外部網路來說，v1的IP地址也就變為了172.16.1.1。
因為Floating IP與虛擬機之間是一一對應的，所以外部網路在進行回包的時候，就可以直接通過Floating IP找到v1所在的位置，從直接而將數據送回至v1。
如果v1沒有Floating IP ，雖然它主動向外部網路發送的數據是能夠送至目的端的，但是目的端的返回包是無法送至v1的。因為v1的數據包是其內網地址10.0.0.1作為源IP地址的，而其內網地址是不為外部網路所認知的，這是存在的第一個問題。不過回到我們的跨區域通信場景中，由於對接RI系統，帶有內網地址的數據可通過RI建立的隧道跨過核心交換區域到達另一個雲網分區的防火牆上。所以第一個問題在跨區域通信的場景中不存在，我們繼續往下分析。
當數據流到達雲網分區的防火牆上時，我們需要解決上文中已經提及的問題：在分散式的網關場景下，流量如何通過防火牆發送到雲網區域的外部介面上？
在原生的ODL方案中，區域的外部介面並沒有實現接收外部網路數據的能力，所以我們需要對此功能進行實現。
實現了數據接收能力後，仍存在另外一個問題。如圖10所示，雲網分區的外部介面分布在區域內的每台物理節點上，而跨區域通信的數據包的目的虛擬機只存在於一台物理節點中。當防火牆向雲網區域的外部介面發送數據包時，應該將數據包發送到哪一台物理節點上呢？換句換說就是如何定位目的虛擬機的具體位置。
綜合分析下來，我們得知，要實現支持去Floating IP分散式網關實現，就必須解決下面兩個問題：
1. 實現區域外部介面對外來流量的數據接收能力；
2. 外部介面接收到數據後，能夠將數據送達目的虛擬機。
流表實現
針對問題1，我們通過設計外部介面的ARP響應的openflow流表，實現外部介面接收外來數據的能力。具體流表如下
上面的流表的主要作用就是為外部介面構造了一個ARP的響應包，在接收到對外部介面的ARP請求的時候，OVS會根據該流表生成一個ARP響應包，發回給請求方。當請求方接收到該ARP響應報文後，就會將數據包發出，送至發出該響應報文的物理節點的OVS上。
為了保證路由的分散式架構，我們會在所有的物理節點上下發外部介面的ARP響應的流表。所以，在外部網路發出ARP請求後，所有物理節點都會對該請求進行響應。收到響應後，外部網路就會將數據包發出，發出後數據包就會按照物理交換機上的mac表進行轉發，最終發送到平台中的某一個物理節點的OVS上。具體如下圖11所示。
圖11 分散式網關ARP響應示意圖
針對問題2，當物理節點收到數據包後，會進一步對數據包進行分析。此時就會有兩種情況：一是該虛擬機恰好在該物理節點中，此時就可以直接將數據包送到虛擬機上，相應流表如下：
還有一種情況就是虛擬機不在該物理節點中，那麼這時候就要用隧道的方式，將數據包通過Vxlan隧道發送到虛擬機所處的物理節點，然後再送到虛擬機，如圖12所示。相應流表如下：
到對端物理機的OVS後：
table=110, tun_id=0x5a,dl_dst=fa:16:3e:99:df:47 actions=output:23（二層轉發到虛擬機）
圖12虛擬機定位示意圖
整個流程統一起來，步驟如圖13所示。
圖13 支持去Floating IP分散式網關數據處理流程圖
代碼架構
添加介面：
流表邏輯實現
流表下發
3.跨區域通信實現案例分析
下面我們結合一個跨區域通信的場景，舉例分析跨區域虛擬機通信過程中經過的流表以及各個流表的功能。
如圖14所示，兩個虛擬機VM1和VM2分別在兩個區域的兩台主機上，VM1向VM2發送ICMP請求。
圖14 跨區域通信流表作用示意圖
首先VM1會發送目標IP為網關IP 10.1.1.1的ARP請求廣播包，由OVS獲取並發送到Table20中進行處理，起作用的流表如下：
Table20匹配tun_id為1000，目標IP為10.1.1.1的ARP請求包，將報文的目標MAC設為10.1.1.3的MAC地址，將報文的源MAC和ARP_SHA改為10.1.1.1的MAC地址（從Neutron獲取），將報文類型改為ARP響應，並將響應報文原路送回到發送方。
VM1拿到網關的MAC地址後，就會將ICMP報文發出，報文的源IP是10.1.1.3，目標IP是10.2.1.3，並在整個傳輸過程中保持不變。報文發送到OVS後，首先起作用的報文是Table60的靜態路由流表，本場景的靜態路由流表會匹配tun_id為1000，源地址是10.1.1.0/24，目標地址是10.2.0.0/16的流量，將目標MAC地址修改為區域防火牆的MAC地址04:04:04:04:04:04，給報文打上VLAN TAG 100，並將報文轉發至br-ex。具體流表如下：
br-ex接收到報文進行流表匹配後，最終會匹配到優先順序最低的NORMAL流表，NORMAL action會以普通交換機的行為轉發報文，也就是根據MAC地址和埠的對應關係轉發，具體流表如下：
br-ex的NORMAL流表會將報文通過host1的eth0發送到區域防火牆上，區域防火牆的默認網關在區域核心上，流量會通過路由到達交換核心並最終送到另一個區域的防火牆。防火牆上有區域內部網路的回程路由，由於目標地址是10.2.1.3，會匹配到區域內10.2.1.0/24的回程路由，並送到下一跳172.16.2.1。防火牆會發送目標IP為172.16.2.1的ARP請求廣播報文，ARP代答流表所在的主機host2會響應ARP請求，ARP代答流表如下：
響應防火牆ARP請求後，防火牆會將IP報文發送到響應的主機host2，通過eth0網卡進入OVS，開始流表匹配。首先br-ex上的引流流表將外部區域訪問本區域的流量轉發到br-int，匹配VLAN ID 為200，目標IP為10.2.1.0/24的報文，轉發到br-int。具體流表如下：
br-int收到流量後對報文進行VLAN到VXLAN的轉換，匹配VLAN ID為200，目標IP為10.2.1.0/24，從br-ex發來的IP報文，去掉VLAN TAG，打上相應的VXLAN ID並交給之後的table繼續處理。具體流表如下：
報文不會匹配到table20到table60的處理流程，在table70匹配到三層轉發流表，根據報文的VXLAN ID，目標IP地址，將報文的目標MAC地址修改為目標IP地址對應的MAC地址，並交給之後的table繼續處理，具體流表如下：
報文不會匹配到table80到table100的處理流程，在table110匹配到二層轉發流表，根據報文的VXLAN ID，目標MAC地址，轉發到相應的虛擬機埠。如果目標MAC對應的虛擬機不在本節點，則轉發到目標虛擬機所在主機的VXLAN隧道埠。具體流表如下：
至此，VM1的數據包發送至另一個區域的VM2，VM2收到數據後，會按照上述步驟將響應數據返回，跨區域通信結束。
五、原型實踐與效果
（一）物理架構概述
由於是軟體SDN方案，實現網路功能的模塊分布在每台伺服器上，複雜性也卸載到SDN控制器和每台伺服器上，所以物理架構相對比較簡單。下圖展示了原型平台的物理架構，整體架構由兩個雲網區域和一個RI區域組成。RI區域由兩台交換核心設備和兩個區域各一台的區域核心設備組成。區域核心下聯區域防火牆，防火牆下聯交換機，交換機接入伺服器。
圖15 原型平台物理架構圖
我們在中國銀聯的數據中心實驗環境搭建了原型平台，平台由兩個SDN雲網分區組成，雲網分區包含接入交換機，伺服器，同時配備了防火牆。平台基於OpenStack、OVS、ODL、Centos等開源軟體進行研發，相應軟體版本情況見如表2所示。
表2 軟體版本情況表
（二）管理控制平面概述
本次原型實踐使用OpenStack作為雲平台來管理虛擬資源的生命周期，向上提供標準API供用戶使用，向下通過SDN控制器，防火牆驅動來實現對下層網路資源的抽象、隔離和調度。其中網路的控制平面使用ODL而非原生OpenStack的Neutron網路功能，ODL提供ML2和GBP的方式和OpenStack集成，本次實踐使用ML2的方式。
（三）雲網與雲控平台集成
OpenStack需要管理我們實踐環境中的二層虛擬網路，三層虛擬路由，以及防火牆，其中二層和三層的功能由ODL提供，防火牆功能由Neutron直接控制獨立的防火牆實現。
ODL與OpenStack的集成需要兩個平台的介面來實現。如圖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請求發送到ODL的北向介面，ODL的Neutron Northbound和Netvirt項目分別提供對應Neutron的北向介面和業務邏輯，其中MD-SAL是ODL內部的數據交互模塊。南向介面OVSDB Southbound和OpenFlow Southbound Plugin分別通過OVSDB和OpenFlow協議操作OVS。
下面我們詳細介紹每個模塊的具體集成方式。
1.ODL與OpenStack集成
本次原型實踐使用ODL的netvirt模塊與OpenStack Neutron集成，需要OpenStack和ODL兩個平台的介面實現。
OpenStack方面，需要在控制節點，網路節點，計算節點做以下配置的變更：
（1）控制節點
修改配置，使用ODL ML2 mechanism driver替代OVS mechanism driver；
修改配置，使用ODL L3 plugin替代原生OpenStack的L3 plugin；
配置ODL的訪問路徑和認證方式。
（2）網路節點
停止原生OVS agent，OVS由ODL控制；
停止原生L3 agent，三層服務由ODL提供；
DHCP服務使用OpenStack原生的DHCP agent；
metadata服務使用OpenStack原生的metadata agent。
（3）計算節點
停止原生OVS agent，OVS由ODL控制；
ODL方面，需要安裝包含netvirt的feature odl-OVSdb-OpenStack並修改配置，打開ODL L3功能。
2.ODL與OVS集成
如圖17所示，OVS主要由兩個用戶態進程OVSdb-server、OVS-vswitchd和OVS內核模塊組成，其中OVSdb-server接收OVSDB協議的消息，保存bridge，port等信息到資料庫，並通知OVS-vswitchd創建相應對象。OVS-vswitchd同時接收OpenFlow協議的消息，操作OVS中的流表，最終使流表在內核模塊中生效。
ODL提供了OVSDB southbound和OpenFlow Southbound Plugin兩種南向介面來操作OVS，其中OVSDB southbound操作OVS上的bridge，port等元素，OpenFlow Southbound Plugin操作OVS上的流表。
圖17 OVS集成模塊示意圖
OVS集成ODL需要在所有計算節點做以下配置：
將OVS的manager設置為ODL，ODL會在OVS上創建兩個bridge：br-int和br-ex，並會自動將這兩個bridge的控制器設置為ODL，之後ODL就可以通過OVSDB和OpenFlow來控制OVS。
3.防火牆集成
在原型環境中我們使用Neutron FWaaS來驅動防火牆。
OpenStack為防火牆服務提供了V1.0和V2.0兩種API模型， FWaaS 2.0在社區M版本中提出，現在仍在開發中，因此我們採用FWaaS 1.0 模型和防火牆設備進行集成。
防火牆服務被抽象成多種虛擬資源，分別是firewall，policy和rule。一個firewall可以關聯應用到多個router，一個firewall使用一個policy，policy是rule的集合。
在原型環境中，防火牆物理上位於伺服器和區域核心中間，邏輯上串聯在租戶虛擬路由和區域核心中間。在我們的環境中防火牆同時也承擔路由器的作用，所以FWaaS除了需要驅動防火牆下發安全規則外，還需要在防火牆上配置路由，具體包括：
一條默認路由指向上層的區域核心，用於將目標是其他區域的流量送到區域核心
數條靜態路由指向下層的租戶虛擬路由，用於將目標是本區域的流量送到虛擬路由。
除此以外，為了支持多租戶通信，創建每個防火牆實例時FWaaS驅動需要相應地在物理防火牆上創建context，創建內向流量internal和外向流量external的Vlan子介面並加入context中。
（四）整體網路架構
原型環境的整體網路架構由雲網分區和RI區域組成，其物理組網方式仍為Vlan模式，兩個雲網分區連接到RI互聯區域。
防火牆和RI區域之間通過路由控制，防火牆以下的網路由ODL下發的OpenFlow流表控制。
伺服器分別連接到一個管理網路，一個通往防火牆的VLAN網路，以及一個區域內通信的VXLAN隧道網路。
虛擬機之間的網路通信大致可以分為以下三種場景：
區域內同網段虛擬機二層通信，ARP代答流表會替目標虛擬機代答ARP請求，並接收通信報文，根據目標MAC地址和VXLAN ID，通過VXLAN隧道送到指定的節點，再匹配二層轉發流表送到OVS的相應埠上。
區域內不同網段虛擬機三層通信，ARP代答流表會替網關代答ARP請求，OVS接收報文，匹配流表，由路由流表模擬路由功能並將報文的目標MAC地址修改為目標虛擬機的MAC地址，根據目標MAC地址和VXLAN ID，通過VXLAN隧道送到指定的節點，再匹配二層轉發流表送到OVS的相應埠上。
跨區域通信，發送出區域時，ARP代答流表會替網關代答ARP請求，OVS接收報文，匹配流表，靜態路由流表會將報文的目標MAC地址修改為防火牆介面的MAC地址，給報文加上VLAN TAG，並通過VLAN網路送到防火牆。兩個區域防火牆之間由路由控制。接收進區域時，ARP代答流表會響應防火牆對虛擬路由器介面地址的ARP請求。VLAN到VXLAN轉換流表會卸載報文VLAN TAG並打上目標網路的VXLAN ID。如果目標虛擬機位於本節點，由二層轉發流表送到虛擬機埠，如果目標虛擬機位於其他節點，由二層轉發流表通過VXLAN隧道送到相應節點，再由相應節點的OVS接收。
原型環境的整體網路部署架構如圖18所示：
圖18 原型環境整體網路部署架構圖
（五）效果展示
1.跨區域網路拓撲
原型平台基於多租戶能力，創建了兩個金融機構租戶，兩個租戶的網路地址完全隔離復用，每個租戶橫跨基於ODL的軟體SDN方案的兩個雲網分區資源，且共同復用所有硬體資源，通過核心交換網路進行數據互通，最終網路拓撲如圖19所示。
圖19 整體網路拓撲圖
在此拓撲中，租戶進行跨區域資源訪問測試，可以相互通信，如圖20所示。
圖20 跨區域通信ping測結果圖
2.性能測試
方案實現後，我們在萬兆環境下對該方案進行了性能測試，並且與之前應用的Nuetron方案進行了對比。
（1）測試環境
硬體環境：CPU Intel E5-2630 V3； 網卡 Intel 82599；
軟體環境：操作系統 Centos7.2；雲平台 OpenStack L版； 測試工具 IPerf；
測試項時長：5分鐘。經與10分鐘測試時長比對，5分鐘測試時長所得數據已足夠平穩、精確，所以本次測試時長為5分鐘；
測試包長：在單對虛機性能測試，測試包長的選取參考了RFC2544，分別是134、256、512、1024、1280、1456，其中134和1456是IPerf支持的最小和最大包長；在隨後的極限性能測試中，採用最大包長1456進行測試。
（2）單對虛擬機性能測試數據（虛擬機配置：8c32g）
在測試中，我們首先測試了單對虛擬機的數據轉發性能，在結果中挑選了部分代表性數據如表3所示。
表3 單對虛擬機性能測試數據表
結果分析：從測試數據上看，ODL方案不管是在延時上還是在帶寬上相比Neutron來說都有了比較好的提升。經計算，ODL方案時延較Neutron平均降低68.8%；帶寬（不含跨網段不同主機場景）平均提升39.3%。
（3）極限性能測試數據
在本項測試中，逐步增加虛擬機數量，在同網段不同主機的場景下，採用最大包長測試跨主機通信的極限性能（帶寬），得到數據如下圖21所示。
圖21 極限性能測試數據圖
測試結果：在跨物理機通信的情況下，ODL與Neutron方案的極限帶寬分別為3.17G與1.93G，ODL高出Neutron 64.2%。
（4）測試結果分析
通過測試，我們發現雖然ODL方案在萬兆環境下的性能依然高於Neutron方案，但整體測試數據不佳，最高帶寬只能達到3.17G，僅佔整體帶寬的30%，不能對網路資源進行較高效率的利用。
經過分析，我們認為產生該問題的主要原因是因為硬體網卡不支持Vxlan offload功能造成的。具備Vxlan offload功能的網卡，能夠識別Vxlan數據包並對包頭進行相應的處理，將原本在協議棧中進行的分片、TCP分段、重組、checksum校驗等操作，轉移到網卡硬體中進行，降低系統CPU的消耗，提高處理性能，能夠在使用Vxlan通信的情況下較大幅度的提升帶寬。而本次測試中使用的Intel 82599網卡則不具備該功能，所以造成總體性能較低。
六、總結與展望
（一）工作總結
通過本次研究我們形成了許多技術積澱。首先，我們根據實際需求，設計出一整套的軟體SDN解決方案，包括整體的網路架構、能力設計與流表框架，相比其它方案來說，優勢如下：
1.整體完全自主可控；
2.方案按照金融需求設計，相比其它方案更能貼合金融場景下的應用；
3. 相比商業方案更加靈活、成本更低。
其次我們通過對ODL的開發，對原生的能力進行了增強與優化，掌握了軟體控制器功能定製化的能力；最後，在性能測試中，對Linux環境下的網路接收性能調優也進行了相關的研究，這對於我們來說也是很好的一次技術積累。
雖然當前方案已經實現，但是在具體的實踐過程中仍存在一些問題有待解決，具體如下：
1.支持去Floating IP的分散式網關功能仍不完善，目前平台內分散式的外部介面進行ARP響應會造成交換機的MAC表震蕩，當平台物理節點的數量較多的時候會影響網路穩定。因此，後續我們會對該實現機制進行進一步的優化，採用定向下發ARP響應流表的方式進行功能實現；
2.本方案中只實現了通過Vlan連接物理防火牆的流表框架，其實通過Vxlan連接虛擬防火牆的流表我們也設計了出來，只不過當前應用場景較少所以沒有在控制器上進行能力實現。後續隨著NFV技術在金融行業的推廣應用，我們也會擇機對該Vxlan的連接方案進行實現；
3.萬兆環境下網路性能極限測試效果不佳，具體原因已經在上文中進行了分析，後續將優化測試環境，更換具備相應能力的網卡進行進一步測試；
4.控制器的高可用性仍待加強，針對ODL控制器的高可用方案社區中也沒有給出較好的方法，所以在後續工作中也希望能得到更多業內專家們的幫助與支持。
（二）展望
中國銀聯正積極探索軟體定義網路技術在下一代金融雲環境中的深化研究與應用，並已與中國銀行、中國農業銀行、中國工商銀行、中國建設銀行、中國交通銀行、興業銀行、恆豐銀行、上海銀行等機構就SDN技術在金融行業中的應用與聯合研究需求進行了緊密溝通。當前結合各單位聚焦研究點，中國銀聯已發起「跨數據中心多雲協同資源管理技術」的聯合研究課題，希望更多的銀行等金融合作機構能夠參與到相關的研究工作中，共同推進軟體定義網路相關的金融科技聯合研究與應用。
