祖立軍 杜學凱 周雍愷 劉國寶 楊 陽 吳 杰 吳承榮
1(中國銀聯電子支付研究院電子商務與電子支付國家工程實驗室 上海 201201)2(復旦大學 上海 200433)
基于SDN的金融云試驗平臺虛擬網絡研究
祖立軍1杜學凱2周雍愷1劉國寶1楊 陽1吳 杰2吳承榮2
1(中國銀聯電子支付研究院電子商務與電子支付國家工程實驗室 上海 201201)2(復旦大學 上海 200433)
當前SDN網絡正在被很多研究機構研究或者被很多企業試驗。SDN網絡將傳統網絡架構中的控制層面與數據層面分離開來,使得網絡架構變得非常簡潔,并且更多的應用可以利用控制層面提供的北向接口實現,簡化了網絡的管理。數據層面則只是根據控制層面制定的規則進行數據的處理。論述了SDN的發展和未來趨勢,且簡要介紹中國銀聯電子支付研究院基于SDN的金融云試驗平臺,同時對此試驗型虛擬網絡進行分析與探討。
Software-Defined Network 控制層面 數據層面 金融云 中國銀聯
軟件定義網絡技術的發展給很多網絡技術提供了支持,在網絡虛擬化方面,云服務提供商能將物理網絡設備抽象成虛擬的網絡設備,提供給租戶,并允許每個租戶創建自己的虛擬網絡,結合租戶申請的虛擬機資源定義網絡拓撲,通過SDN技術對虛擬網絡進行管理[3,6]。
在金融云平臺下,虛擬網絡有著一系列的基本需求,比如,虛擬網絡中多租戶間網絡訪問的隔離、管理員對租戶網絡資源的管理、金融業務的擴展等等。而從租戶的角度來看,需要自己的業務數據以及網絡資源不能夠被其他租戶訪問與竊取,并且能夠在這些隔離與安全性被滿足的條件下不影響自身的業務運行[1]傳統物理網絡中不同網絡之間的隔離通常由部署在網絡邊界處的路由器和防火墻完成。同理,虛擬網絡的隔離是在虛擬網絡的邊界處實現。但相比之下,虛擬網絡環境中的網絡邊界更加模糊,也更加復雜,從而為租戶虛擬網絡提供路由服務及防火墻服務也更為復雜。不僅如此,在實際的業務運行云平臺下,不同租戶分配到的資源很有可能是物理上相互分散的,不同主機上的資源可能會被分配給不同的租戶,這樣的話對于租戶之間的隔離與租戶自身內部資源的隔離需要被更細粒度的劃分,而且各個隔離區域之間的隔離邊界需要更加明確。從銀聯的業務運行的試驗性環境來看,虛擬網絡中的隔離可分為以下幾類:不同租戶的虛擬網絡之間的隔離;同一租戶虛擬網絡下,不同虛擬子網之間的隔離;租戶虛擬網絡與外網之間的隔離。
隨著互聯網應用的普及和各個企業數據業務的增長,網絡性能與安全性的提高已經成為很多大型數據中心急需解決的問題。雖然在很多開源云平臺下已經存在一些針對于虛擬網絡安全隔離的解決方案,但是很多方案中數據處理比較大的工作都集中在單個設備上,容易造成故障,影響業務的運行,也造成了一些數據處理的延時。
隨著SDN技術的到來,一些傳統網絡架構下比較難以處理的問題能夠在SDN的網絡架構下得到很好的解決或者緩解,所以在我們的研究中,我們試圖將金融云平臺虛擬網絡中遇到的一些與業務相關的問題移入SDN的網絡架構之下,并且對其加以解決。
一般來說,一個功能完善的虛擬網絡系統一般應包含以下功能:虛擬機能夠與外網、物理機、其他虛擬機正常通信;網絡的虛擬化對用戶來說是透明的;虛擬機的IP地址可以動態分配,與其所在物理機的位置無關;虛擬機在遷移過程中網絡配置不變,主要是IP/MAC地址不變;虛擬網絡配置和管理方便;虛擬網絡要能夠方便擴展;網絡性能要達到一定要求;滿足安全需求,能夠實現不同用戶在網絡上的相互隔離。所以隨著虛擬網絡的擴展,其網絡系統的管理也越來越復雜,對于許多對網絡管理要求更高的系統來講更是如此,比如金融云平臺的虛擬網絡的管理。SDN技術的發展能夠很好地解決虛擬網絡擴展中所遇到的問題。
SDN網絡中網絡設備具有良好的可編程性,網絡管理人員和網絡研究人員可以非常容易地控制網絡設備、部署新型網絡協議。在SDN網絡中控制平面與數據平面相互分離,支持用戶定義自己的虛擬網絡,定義自己的網絡規則和控制策略,網絡服務提供者能夠為用戶提供端到端可控的網絡服務,甚至可以在硬件設備上直接添加新的應用。這都使得SDN網絡非常適合于虛擬網絡系統的管理。這種可編程的網絡平臺不僅能解開網絡軟件與特定硬件之間的掛鉤,還能將網絡軟件的智能性和硬件的高速性充分結合在一起,使得網絡變得更加智能與靈活。目前在SDN中網絡虛擬化技術研究項目和產品主要有Stanford大學的FlowVisor項目、匈牙利愛立信研究院的IVOF、瑞典皇家理工學院的OVN(OpenFlow Virtualization Network)項目和Nicira公司提出的NVP(Network Virtualization Platform)網絡虛擬化平臺。
2.1 控制層面與數據層面研究
控制層面的研究越來越多地集中在控制器的集群化方面。網絡界頂級學術會議SIGCOMM近年來關于控制層面的討論很多都是關于控制器集群發展的。從開始的基于故障災備處理機制的雙控制器模型到基于控制信息備份冗余、大數據量處理的控制器集群模型,還包括國內外企業級的控制器集群模型。
在控制層面方向上,軟件控制器OpenDaylight、Floodlight得到廣泛使用,OpenDayLight控制器是目前為止使用最為廣泛的開源控制器。同時,也有一些其他的控制器如Beacon,也漸漸走入商用的行列并且取得了很好的評價。SIGCOMM會議曾經有關于Beacon控制器[8]的學術探討,在介紹時主要提出了當時做Beacon控制器時所進行的設計思路的探討:首先,是否一個控制器能夠像一個網絡操作系統那樣在運行時開啟或停止應用程序。最終Beacon控制器應用了OSGI框架實現應用模塊的熱插拔。第二,編寫控制器的語言選擇,對C、C++、Java、C#等幾種語言進行對比,通過易于編寫和維護,能夠跨平臺等幾方面的考慮,最終選擇了Java語言。第三,對控制器讀取OpenFlow[7]消息時算法的改進,使用了一種Run-to-completion算法進行控制器的設計。第四,對控制器寫OpenFlow消息時算法的改進,使用了改進的Revised Switch Flush Method和Revised I/O Loop算法設計,增加了控制器的性能。第五,與其他類型控制器(沒有使用優化算法的Beacon、Floodlight、NOX、Maestro)在吞吐量和處理時延等方面進行實驗比較。
在控制層面上控制器設備的狀態遷移也是一個研究熱點,比如有些研究提出了一些控制器狀態熱遷移的解決方案,使得能夠在SDN控制器程序運行狀態下對控制器進行升級,而不至于SDN網絡的工作中斷。Princeton大學的HotSwap[9]工作就是這樣的一種解決方案,這篇文章提出在控制器熱升級過程中的幾個工作狀態:record階段、replay階段、compare階段、replace階段。各個階段具體處理一些熱遷移過程中的一些必要操作。這些工作階段的目的是使得old控制器與new控制器之間能夠處于HotSwap這樣一種容器中進行狀態的轉移或者應用程序的升級。
也有一些其他的研究角度,比如SIGCOMM 2013會議中《Exploiting Locality in Distributed SDN Control》[10]從算法層面對SDN控制器的部署進行研究,以求達到SDN控制器的高性能。本文的研究主要是從Locality算法與SDN控制器架構的部署關系開始的。
隨著控制層面研究的深入,控制器集群的概念開始出現,為了保證網絡服務質量與性能,以及避免主控制器故障帶來的影響,越來越多的學術文章以及工業界研究開始轉向控制層面的集群化發展。控制器集群化的發展也帶來了一些控制層面其他的問題,比如控制器集群的主控制器選舉機制,主控制器切換機制以及控制層面北向接口服務與南向接口服務分離的問題。在這些問題研究的過程中,很多學者以及工業界研究人員提出了自己的解決方案,對其中可能存在的一些問題進行了很好的解決。
在SDN學術界研究的過程中,控制層面的學術研究多于數據層面的研究[12-13]。因為根據SDN的架構定義,數據層面只是擁有執行控制層面命令或者轉發其他數據層面設備數據的功能。但是近些年來一些學者進行的部分研究開始轉向數據層面,賦予數據層面一些新的機制[15]。
2.2 集成的平臺化發展
隨著SDN架構的完善,越來越多的SDN北向應用開始部署,很多通用的北向應用開始集成,從而發展成為通用的SDN應用平臺,比如ONOS。ONOS是一種開放的分布式的SDN操作系統[14],這一控制層面是通過對FloodLight控制器進行改進得到的。ONOS平臺提供了對應用程序的北向接口服務,并且ONOS作為一個控制器的容器平臺,能夠容納很多OpenFlow控制器進行網絡控制層面的操作,并且實現了對于FloodLight控制器的支持。ONOS運行在多臺服務器上,每一臺服務器都獨立代表一個交換機子集的主控制器。在服務過程中,如其中一個服務器發生故障,則再分配給其數據層面一個主控制器,在發生故障后,可以通過相應檢測來發現現有的主控制器是否發生了故障,并且在確信發生故障后,可以在運行時通過選舉機制進行主控制器的選舉。
《Towards an Elastic Distributed SDN Controller》[11]也是通過平臺化的方法來對控制器進行操作。不過主要是針對研究控制器狀態遷移過程中應該需要處理的問題或者防止發生的問題來進行討論的,同時也提出了一些關于控制器遷移的協議來規范狀態遷移操作,并且規范了控制器的狀態來進行協議的準備工作。
2.3 SDN安全性發展研究
SDN技術的安全性需求通常集中和變現在對控制層面的安全性需求。SDN的安全性研究伴隨這SDN的發展與完善。學術界關于控制層面安全性的思考與討論一直是比較多的。
由于SDN的研究近些年才開始,所以SDN架構下很多安全問題還是比較突出的,從網絡安全的需求上,還是在SDN環境下的安全問題的很多方面比如DDos攻擊、攻擊易受攻擊的交換機、攻擊控制層面的通信、攻擊網絡中的控制器、控制器和管理應用之間的認證、攻擊SDN網絡管理者的站點、SDN網絡受到攻擊后補救方案等等還是需要及時在試驗環境下解決的。有些方面可以通過傳統的網絡安全保障方法進行解決,有的方面在SDN網絡架構下問題相對更加突出,需要運用新的思路或者新的方式進行解決。
通過多年來對于中國銀聯電子支付研究院的金融云平臺的分析和改進,我們將總結出的構建安全、穩定、可靠的金融云平臺的需求主要分為四大類,分別為多層次安全性需求、面向公眾的需求、合規性檢查需求和異地云平臺互聯的需求。本節我們分別對這幾類需求進行探討。
3.1 多層次安全性需求
1) 統一、全面的安全策略。計算資源集中管理使得邊界防護更易于部署。可以針對計算資源提供全面的安全策略、統一數據管理、安全補丁管理、以及突發事件管理等安全管理措施。對用戶而言,也意味著能夠有專業的安全專家團隊對其資源和數據進行安全保護。
2) 低安全措施成本。多個用戶共享云計算系統的計算資源,在集中的資源上統一應用安全措施,可以降低各用戶的安全措施平均成本,即更低的投資會給用戶帶來同樣安全的保護措施。
3) 按需提供安全防護。利用快速、彈性分配資源的優勢,云計算系統可以為過濾、流量整形、加密、認證等提供安全防護措施,動態調配計算資源,提高安全措施處理效率。
3.2 面向公眾的需求
金融云的本質是服務于金融業務。金融領域業務進入云平臺是當前的一大趨勢,基于云的業務能夠更好地為公眾提供服務的便利。傳統金融機構需要的是一套合理的適合自己業務特點的金融云架構。構建金融云,將各項金融業務引入云平臺,不是為了迎合概念,而是真正的業務需求。對于中小銀行而言,單獨構建機房(網絡、帶寬、服務器、存儲、軟件)并設置維護團隊都是不小的開支,如果遷往云,不僅人力物力以及成本的節省非常可觀,而且在安全性上也會有更多保障。如果能把業務接入云,則可動態調配資源,平時業務仍以自建平臺為主,高峰時候借用云的資源彈性擴容。
金融企業往往把SDN技術應用與原有的云戰略緊密結合,希望借助SDN實現私有云的網絡虛擬化和自動配置,以適應其擴展性和多租戶需求,并降低設備采購成本。銀聯建設金融云平臺,其中的一個計劃是將來能夠為中小銀行提供入口,將虛擬網絡資源提供給中小銀行使用,中小銀行用戶作為云平臺的租戶,可享受虛擬機、虛擬網絡等資源。
3.3 金融云合規性檢查需求
不管是傳統業務的遷移還是新業務的開發,一旦這些業務系統在云計算平臺上開始運行,它們所處的信息系統環境和之前傳統的信息系統環境相比有了很大的區別,加之云業務系統的特殊性(這些業務大多涉及敏感信息),這樣一來,原本合規的業務就存在不再合規的風險。所以,有必要對這些云計算業務重新進行合規性審核,檢查這些業務是否符合相關行業的安全標準和法律法規的要求。
由于已發布的《信息系統安全等級保護》并還沒考慮云計算的模式,所以,當金融業務遷往云平臺之后,原有的業務合規性就會受到沖擊。為此,我們有必要在《信息系統安全等級保護》的基礎之上,針對云計算的特點對移動支付服務業務重新進行合規性審核。
在云平臺事后審計方面,銀聯也做了大量工作。包括自研了云審計系統,通過其完善的計算、網絡審計功能可以發現云平臺的各類不合規的操作。重點需要關注以下幾個方面:
1) 系統隔離
云計算中廣泛使用了虛擬化技術,各業務系統之間共享資源。如果虛擬化系統之間沒有采取有效的隔離措施,那么隱私數據泄漏的風險就會大大增加。要仔細分析整個業務系統所處的環境,確保該系統和其他業務系統之間實施了很好的物理隔離或邏輯隔離;檢查Hypervisor的配置是否符合相關的安全規范,是否采取必要的措施來加固Hypervisor自身的安全性(例如:安全補丁、訪問控制、用戶認證、關閉不必要服務、通信加密、限制對Hypervisor的遠程訪問等)。
2) 網絡隔離
傳統的信息系統通常采用防火墻來實現網絡隔離,而在云計算中,虛擬防火墻和虛擬交換機等技術被用來實現虛擬機之間的訪問控制,要確保它們按照產品安全配置規范進行了正確的配置和部署,以達到和物理防火墻相當的保護級別。
3) 業務流量審計
通過截取分析業務流量審查業務的操作流程是否合規、業務流量是否純凈、數據包是否符合設計規范等。可以通過在Domain0中安裝虛擬交換機(vSwitch),配置端口鏡像,來監聽虛擬機之間的通信流量。
3.4 異地云平臺互聯需求
對于擁有多個數據中心的大型金融機構,利用金融云計算解決方案中的軟件定義網絡架構,實現多個數據中心建的互聯互通,并可實現網絡設備與配置的統一自動化管理。可以使金融云網絡管理效率大幅提升。
可使用VXLAN技術,對云平臺中的虛擬機通信數據包進行封裝,支持位于異地的多數據中心之間的網絡連接。該技術允許同一子網(具有相同的VXLAN標識)內的虛擬機分布在不同數據中心,且能夠互相訪問[5]。
4.1 網絡架構模型及其功能
銀聯網絡虛擬化的總體功能分為以下幾個層次:應用平臺功能、增值業務功能、增值管理功能、組網功能和資源管理功能。系統的角色分為以下幾類:超級管理員、租戶網絡管理員以及VPC租戶。
1) 應用平臺功能
(1) 計算資源(VM)管理:租戶在所屬VPC內創建并管理虛擬機,接入租戶虛擬網絡;
(2) 浮動IP管理:租戶申請為虛擬機綁定外網IP,使得外網能直接通過浮動IP訪問該虛擬機;
(3) VPC網絡管理:租戶網絡管理員對VPC網絡的虛擬路由、安全組進行配置管理,并處理租戶對虛擬機浮動IP地址的申請。
2) 增值業務功能
(1) 防火墻服務(Fwaas):租戶網絡管理員為VPC創建虛擬防火墻,并管理防火墻規則;
(2) 負載均衡服務(LBaaS):租戶網絡管理員為VPC創建虛擬負載均衡器,并配置規則;
(3) VPN服務(VPNaaS):租戶網絡管理員為VPC配置虛擬網絡VPN服務。
3) 增值運營功能
(1) 訪問控制:租戶網絡管理員在子網內和子網間配置訪問控制策略,阻止虛擬機資源被非法訪問的功能;
(2) 流量監控:租戶網絡管理員利用端口鏡像技術將網絡中虛擬機和物理機的網絡數據包鏡像到專用設備,并進行監控的功能;
(3) QoS管理:租戶網絡管理員按照一定的QoS管理策略,對網絡中的虛擬端口和物理端口進行帶寬限制的功能;
(4) 資源配額管理:租戶網絡管理員查看VPC租戶的虛擬網絡資源分配及使用情況,對租戶的虛擬網絡資源進行分配。
4) 組網功能
(1) 虛擬網絡:二層/三層數據交換,利用V(X)LAN技術對虛擬網絡進行邏輯劃分和隔離,通過VTEP(VXLAN Tunnel Endpoint)將隧道通信數據包組播/廣播到虛擬網絡中的功能;
(2) 網絡虛鏈路轉發:將虛擬網絡隧道通信鏈路映射到物理網絡設備中,并轉發的功能。
5) 資源管理功能
(1) 網絡資源池管理:超級管理員對網絡資源池的資源進行管理,包括外部網絡管理和IP地址段管理等;
(2) 計算資源池管理:超級管理員對計算資源池中的資源進行管理,包括計算節點(物理服務器)的管理等;
(3) 鏡像管理:超級管理員對虛擬網絡可使用的虛擬機鏡像進行管理;
(4) 網絡設備管理:超級管理員對硬件網絡設備進行管理,分配到各網絡資源池中,為網絡資源池的資源虛擬化提供設備硬件支持。
圖1為銀聯網絡架構模型圖,如圖1所示,管理平面組件運行于云管理平臺、控制平面組件運行于控制器,分別單獨部署。而數據平面組件則包含虛擬交換機、物理交換機與邊緣設備等,其中邊緣設備又包括網關、防火墻、負載均衡器等等。
該架構采用了VXLAN技術,對物理網絡架構并沒有特別要求,物理交換機可以按傳統網絡的方式進行部署,中間原有網絡設備啟用三層協議作為VXLAN的基礎網絡。

圖1 網絡架構模型圖
VTEP(VXLAN)作為VXLAN隧道的端點,用來創建、終結VXLAN隧道鏈路,OpenvSwitch和VXLAN網關都具備對其的實現。
VXLAN網關部署于VXLAN網絡的邊緣,用于終結VXLAN網絡,實現VXLAN網絡之間以及VXLAN與非VXLAN網絡的互連。應當使用專用硬件交換設備來實現VXLAN網關的功能。
防火墻專用設備旁掛部署于VXLAN網關,部署雙機熱備保護。為每個虛擬路由配置一個虛擬防火墻,通過子接口互聯。控制器在網關上配置策略,將租戶業務流量(三層流量)引至防火墻處理;同時在防火墻上配置策略,實現業務安全互訪控制;此外在防火墻出接口配置默認路由,將流量回引至虛擬路由。
負載均衡專用設備旁掛部署于VXLAN網關,部署雙機熱備保護。為每個虛擬路由配置一個虛擬負載均衡器,通過子接口互聯。
4.2 虛擬網絡控制平面分析
在銀聯云平臺虛擬網絡中,控制平面扮演著非常重要的角色,具體是由控制器集群構成的,包含OpenDaylight等為代表的開源控制器,或者硬件控制器設備。它首先能通過OpenFLow協議與底層的虛擬交換機(或支持OpenFlow的物理交換機)通信,定義并控制底層網絡數據流,實現對網絡設備的控制和管理;其次,控制層需要為上層的應用層提供API,能與云平臺集成,兼容主流的云管理平臺,幫助云平臺輕松實現網絡策略下發及調整。在銀聯云環境中主要需要兼容OpenStack[4],使得OpenStack能夠獲取虛擬網絡中的各類虛擬設備(控制器、路由器、交換機)信息。此外,還可以基于業務特點對網絡進行定制,實現網絡和業務的無縫融合。
當前,云平臺系統已通過虛擬化和自動化技術大幅提升了部署效率,但是云業務不僅需要計算和存儲資源,也包括網絡資源;物理網絡部署的低效率,以及其與虛擬網絡系統的割裂,日益成為云數據中心的核心矛盾。如果數據中心的虛擬網絡和物理網絡相互割裂,將在資源統一發放、故障聯動診斷等方面會產生一系列問題,成為云業務部署效率的最大障礙。
因此,在虛擬網絡與硬件網絡集成后,需要實現虛擬網絡和物理網絡相互感知,統一視圖,端到端統一管理。控制平面能同時獲取虛擬網絡和物理網絡的信息,以全網絡視角統一管理虛擬和物理網絡。當網絡發生故障時,不但可以及時準確呈現出故障節點,還能實現虛擬和物理網絡的故障聯動運維。
虛擬網絡控制平面主要由流表和控制器構成。在銀聯虛擬網絡環境中,所有虛擬網絡流量的轉發操作均由虛擬交換機Open vSwitch查詢流表之后完成,流表在用戶對網絡進行基本配置后由控制器生成并下發保存在Open vSwitch上。
控制器連接所有被控制交換機,所有在云管理平臺對網絡進行的配置操作,如創建網絡和子網、發放虛擬路由、虛擬防火墻與負載均衡器等,均通過控制器來最終實現對被控制交換機的配置。
控制器北向通過API同OpenStack平臺相鏈接。并提供REST APIs供使用者開發兼容于虛擬網絡的應用程序,來更好和個性化地控制虛擬網絡,提供諸如安全檢測、QoS保障、訪問控制等功能。控制器的北向還自帶GUI,方便用戶管理和控制虛擬網絡。
控制器的南向同所有的被控制交換機相連接,包括虛擬交換機Open vSwitch和用作VXLAN網關的硬件交換機,所有被控制交換機在連入虛擬網絡時通過LLDP協議在控制器上注冊。
在進行虛擬網絡控制平面設計的時候,我們主要根據控制層面需求的控制器高可用性、網關與接入高可用性、Neutron及OVS高可用性、防火墻與負載均衡高可用性進行設計。
根據圖2中控制器架構,實現網絡中控制器組件的高可用性。
(1) 架構中控制器為集群部署,采用浮動IP,并且集群中的每個控制器都有一個自己的編號ID。數據層面的網絡設備只與控制器集群的主控制器保持一條連接。當網絡中控制器集群的主節點出現故障時,控制器集群檢測到主節點連接斷開后,向其他節點廣播主節點故障消息,集群中的ID編號最小的控制器自動升為主控制器。

圖2 控制器高可用性架構
(2) 架構中數據層面設備與控制器之間存在主備鏈路。當設備與控制器連接發送鏈路故障時,設備與控制器之間的鏈路發送切換,重新建立連接。重新建立連接過程中,數據層面設備的流表不變,原有轉發不中斷。在新連接建立后,重新刷新數據層面設備的流表。
根據圖2中架構圖所示,可實現網絡中網關組件的高可用性。在此架構中,兩臺VXLAN網關設備主備,并且兩臺設備的配置一致。網絡中ARP請求由控制器代答,無泛洪學習過程。接入設備與網關設備鏈路形成等價路徑,實現備份及負載分擔。
根據圖2中所示,接入交換機堆疊,形成主備,實現接入的高可用性。接入交換機之間互連鏈路設置鏈路聚合實現備份和負載分擔。
在針對Neutron及OVS高可用性需求的設計方面,我們的設計方法為:
1) OVS及Neutron L2代理的高可用
Open vSwitch分布在各計算節點上,而Neutron二層代理同樣分布在每個計算節點上,用以配置Open vSwitch接口,保證虛擬網絡的連通性;Open vSwitch及Neutron二層代理本身已經是分布式部署,很難實現高可用。事實上,當某一Open vSwitch或Neutron二層代理發生故障時,會影響所在計算節點上虛擬機的網絡連通性,并不會對系統中其他位置的網絡造成影響。
2) Neutron組件高可用
除了二層代理,Neutron組件還包括DHCP代理、L3代理和LBaaS(負載均衡)代理,根據OpenStack官方文檔,以上代理的高可用性可通過主備方式實現,使用Pacemaker工具作為Neutron高可用組件。
在針對防火墻與負載均衡高可用性需求設計方面,我們的方式如下:
1) 防火墻高可用性設計
防火墻旁掛于VXLAN網關,通過部署雙機熱備份進行保護。防火墻通過虛擬化,每個虛擬路由器配置一個虛擬防火墻,并通過子接口進行互聯。VXLAN網關作為業務網關,終結VXLAN網絡中數據包向外傳輸,并通過控制器在網關上的配置策略將用戶的業務流量引至防火墻處理。控制器通過在防火墻上配置策略,用來實現業務的安全互訪控制。控制器通過在防火墻出接口配置默認路由,將流量回引至虛擬路由器并處理。

圖3 防火墻與負載均衡高可用性架構
2) 負載均衡高可用性設計
負載均衡旁掛部署于VXLAN網關(與防火墻部署類似),也是通過部署雙機熱備份進行保護。負載均衡通過虛擬化,每個虛擬路由器配置一個虛擬負載均衡,并且通過子接口互聯。如果業務流量有負載均衡需求,可以在虛擬負載均衡中定義負載均衡模式,將流量引入虛擬負載均衡,對流量進行處理之后通過虛擬負載均衡配置的默認路由將流量引至虛擬路由器。
4.3 虛擬網絡數據平面分析
數據平面實現邏輯視圖中的資源層部分,即虛擬交換機、物理交換機以及邊緣設備等。在銀聯虛擬網絡中,虛擬交換機由Open vSwitch實現,物理交換機由傳統物理交換機實現,邊緣設備由支持VXLAN與OpenFlow的網關設備以及旁掛的防火墻設備和負載均衡器等實現,數據中心虛擬網絡使用VXLAN技術構建。
同一物理主機上虛擬機之間的通信不需要使用VXLAN,依然可以使用VLAN技術;不同物理主機上的虛擬機通信時(同一VXLAN網絡),虛擬機產生的流會通過虛擬網橋br1上的VXALN接口進行封裝,最終以UDP數據包的形式進入物理網絡,這里的VXLAN接口起到了VTEP的作用。
如圖4(圖中各網絡元素關系見表1)所示,其通信流程為:
(1) VM1發送ARP請求。
(2) NVE1更新本地MAC轉發表。
(3) NVE1通過流表匹配,將ARP請求上送AC。
(4) AC根據目的IP,查找到VM3對應的MAC3及NVE2,通過NVE1發送ARP相應報文給VM1。
(5) AC同時向NVE1下發目的地址MAC3的轉發流表,出接口為VXLAN tunnel NVE2。
(6) VM1向VM3發送業務報文。
(7) 報文到達NVE1后,查找MAC轉發表,找到出接口VXLAN tunnel NVE2,進行VXLAN封裝,外層目的地址為NVE2,源地址為NVE1。
(8) 報文根據外層IP地址進行路由轉發到NVE2,NVE2接收報文后,執行VXLAN解封裝,然后本地轉發/廣播到VM3。

圖4 同子網二層互訪流程

表1 同子網通信網絡元素對應表
當接入VXLAN網絡的虛擬機與接入非VXLAN網絡的虛擬機需要進行通信時,需要VXLAN網關的支持,所有VXLAN網絡上的流均能通過VXLAN網關進入非VXLAN網絡。其訪問流程大致如下(參見圖5,圖5中各網絡元素關系見表2):
(1) VM1發送ARP請求。
(2) NVE1更新本地MAC轉發表。
(3) NVE1通過流表匹配,將ARP請求向AC上送。
(4) AC根據目的IP,查找到對應的MAC5及NVE3,通過NVE1發送ARP相應報文給VM1。
(5) AC同時向NVE1下發目的地址MAC5的轉發流表,其出接口為VXLAN Tunnel NVE3。
(6) VM1向VM4發送業務報文。
(7) 報文到達NVE1后,查找MAC轉發表,找到出接口NVE3,進行VXLAN封裝,外層目的地址為NVE3,源地址為NVE1。
(8) 報文依據外層IP路由轉發到NVE3,NVE3收到報文后進行VXLAN解封裝,查找路由,轉發報文至目的IP所在的網關NVE4;NV4查找MAC轉發表,找到出接口NVE2,進行VXLAN封裝,外層目的地址為NVE2,源地址為NVE4。
(9) 報文根據外層IP路由轉發到NVE2,NVE2接收報文后,執行VXLAN解封裝,然后本地轉發/廣播到VM4。

圖5 跨子網三層互訪流程

表2 跨子網通信網絡元素對應表
4.4 整體方案分析
我們設計銀聯虛擬網絡架構的原則,是根據銀聯之前虛擬網絡的需求進行的。從具體的技術層面分析,我們認為一個功能完善的虛擬網絡系統一般應包含以下功能:
(1) 虛擬機能夠與外網、物理機、其他虛擬機正常通信;
(2) 網絡的虛擬化對用戶來說是透明的;
(3) 虛擬機的IP地址可以動態分配,與其所在物理機的位置無關;
(4) 虛擬機在遷移過程中網絡配置不變,主要是IP/MAC地址不變;
(5) 虛擬網絡配置和管理方便;
(6) 虛擬網絡要能夠方便的擴展;
(7) 網絡性能要達到一定要求;
(8) 滿足安全需求,能夠實現不同用戶在網絡上的相互隔離。
根據以上的原則出發,在我們完成設計任務的時候,我們認為整體設計方案基本達到了以下目的:
(1) 能夠自定義虛擬機之間的訪問規則,控制虛擬機之間通信;
(2) 整個系統的各個功能模塊有清晰的職責界限;
(3) 能夠通過使用VLAN tag或VXLAN來隔離多租戶子網。
4.5 總 結
銀聯的云網絡服務構建了一個安全的云平臺網絡環境,通過云平臺管理系統可以完全掌握銀聯金融私有云平臺網絡資源,包括選擇自有IP地址范圍、劃分網段等。此外也可以通過互聯網/專線/VPN等連接方式連接至銀聯私有云平臺[2]。
通過創新性的云計算組織溝通機制,將大量計算資源組織起來,協同工作,資源個體可進可出,收縮自如,減少組織內的溝通損耗;當組織內個體情況發生變化時,可以及時查知信息,確保資源額變化實時反映在系統性能上,做到動態感知;并同時平衡各節點的壓力,做到動態負載均衡。同時,用戶無需關心底層的實現方式,只需要專注于上層的業務邏輯。
通過基于SDN的虛擬網絡架構來構建新的虛擬網絡相對于之前的金融云平臺的虛擬網絡架構來具有以下幾個方面的優勢:
? 網絡虛擬化能大幅度節省企業的開銷,一般只需要一個物理網絡即可滿足服務要求。而基于SDN的網絡架構進一步節省了企業的開銷。
? 相對于之前的網絡架構,新的網絡架構簡化了企業網絡的運維和管理。
? 提高了網絡的安全性。之前的虛擬網絡架構很難做到安全策略的統一和協調。在新的網絡架構下,通過控制層面的統一管理,整個網絡的安全策略得到了很好的統一與協調。
? 提升了網絡和業務的可靠性。由于新的網絡架構中對高可用性的設計,當集群中的一些小的設備出現故障時,整體的業務系統不會有任何的影響。
通過以上對基于SDN的金融云試驗平臺虛擬網絡架構的敘述,我們認為我們設計的網絡架構模型滿足了新的需求,并且對整體的業務和網絡的性能、功能都有了很大的提升,是一種比較好的解決方案。
以上為銀聯電子商務與電子支付國家工程實驗室在金融云平臺虛擬網絡領域的初步研究與設計,未來我們正計劃基于現有研究成果,在銀聯環境內搭建基于軟件定義網絡的下一代金融云平臺。該環境目標是對外向銀行、證券、保險以及第三方金融機構就未來金融領域聯合創新提供開放的、共享的服務平臺,對內向總/分/子公司提供技術先進、響應迅速的業務創新試驗場。
在該環境中,我們將重點解決現有軟件定義網絡技術綁定單一廠商的問題,同時可有效利用現有非SDN的網絡設備,兼容軟硬件、開源商業形態的解決方案并存共融,利用X86容錯機、DBDK等技術提升SDN網絡可用性與性能,研發出多種符合金融特色網絡應用功能模型。并探索出一套符合金融行業SDN網絡的測試評估方案,在對銀聯金融云環境進行實踐評測優化后,功能性、可用性、安全性、擴展性、管理性依據金融行業標準得到有效驗證后,向銀聯生產云進行推廣應用。
[1] Koponen T, Amidon K, Balland P, et al. Network virtualization in multi-tenant datacenters[C]// Usenix Conference on Networked Systems Design and Implementation. USENIX Association, 2014:203-216.
[2] 銀聯基于OpenStack的金融私有云建設實踐[EB/OL].[2015].http://www.csdn.net/article/2015-10-06/2825 848.
[3] Jain R, Paul S. Network virtualization and software defined networking for cloud computing: a survey[J]. Communications Magazine, IEEE, 2013, 51(11): 24-31.
[4] OpenStack[EB/OL].[2015]. http://docs.openstack.org.
[5] Mahalingam M, Dutt D, Duda K, et al. Virtual extensible local area network (VXLAN): A framework for overlaying virtualized layer 2 networks over layer 3 networks[J]. Internet Req. Comments, 2014.
[6] Mckeown N, Anderson T, Balakrishnan H, et al. OpenFlow: enabling innovation in campus networks[J]. Acm Sigcomm Computer Communication Review, 2008, 38(2):69-74.
[7] OpenFlow[EB/OL].[2015]. http://www.openflow.org/.
[8] Erickson D. The beacon openflow controller[C]// ACM SIGCOMM Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2013:13-18.
[9] Vanbever L, Reich J, Benson T, et al. HotSwap: correct and efficient controller upgrades for software-defined networks[C]// Proceedings of the Second Acm Sigcomm Workshop on Hot Topics in Software Defined Networking, 2013:133-138.
[10] Schmid S, Suomela J. Exploiting locality in distributed SDN control[C]// ACM SIGCOMM Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2013:121-126.
[11] Dixit A, Hao F, Mukherjee S, et al. Towards an elastic distributed SDN controller[J]. Acm Sigcomm Computer Communication Review, 2013, 43(4):7-12.
[12] Mekky H, Hao F, Mukherjee S, et al. Application-aware data plane processing in SDN[C]// The Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2014:13-18.
[13] Fayaz S K, Sekar V. Testing stateful and dynamic data planes with FlowTest[C]// The Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2014:79-84.
[14] Berde P, Gerola M, Hart J, et al. ONOS: towards an open, distributed SDN OS[C]// The Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2014:1-6.
[15] Al-Shabibi A, De Leenheer M, Gerola M, et al. OpenVirteX: make your virtual SDNs programmable[C]// The Workshop on Hot Topics in Software Defined NETWORKING. ACM, 2014:25-30.
RESEARCH ON VIRTUAL NETWORK OF FINANCIAL CLOUD TEST PLATFORM BASED ON SDN
Zu Lijun1Du Xuekai2Zhou Yongkai1Liu Guobao1Yang Yang1Wu Jie2Wu Chengrong2
1(NationalEngineeringLaboratoryforElectronicCommerceandElectronicPayment,ChinaUnionPayElectronicPaymentResearchInstitute,Shanghai201201,China)2(FudanUniversity,Shanghai200433,China)
The current SDN network is being studied by many research institutions and tested by many companies to test. The SDN network separates the control layer and the data layer in the traditional network architecture, making the network architecture become very simple, and more applications can be realized by using the north interface provided by the control layer, which simplifies the network management. This paper discussed the development and future trend of SDN, briefly introduced the SDN-based financial cloud test platform of China UnionPay Electronic Payment Research Institute, also analyzed and discussed this experimental virtual network.
Software-defined network Control layer Data layer Financial cloud China UnionPay
2016-02-05。國家云計算示范工程項目(C73623989020220110006)。祖立軍,工程師,主研領域:云計算與電子支付技術。杜學凱,碩士。周雍愷,碩士。劉國寶,碩士。楊陽,碩士。吳杰,博士。吳承榮,博士。
TP3
A
10.3969/j.issn.1000-386x.2017.06.026