OpenFlow多級流表在云計算網(wǎng)絡(luò)中的應(yīng)用

編者按：OpenFlow多級流表是當(dāng)前的熱點話題，但目前缺少實際的應(yīng)用案例，盛科基于SDN提出一種性能優(yōu)化方案，將影響網(wǎng)絡(luò)性能的一些工作從服務(wù)器Offload到TOR交換機上去做，將TOR交換機作為服務(wù)器網(wǎng)卡的一部分，并且該方案已經(jīng)在實際網(wǎng)絡(luò)中進行了部署。本文中，盛科張衛(wèi)峰分享了OpenFlow多級流表在這個方案中的運用。以下為原文：

作者簡介： 盛科張衛(wèi)峰，熟悉二三層路由交換、PTN/IPRAN技術(shù)、芯片設(shè)計，對SDN/OpenFlow技術(shù)也有深刻的研究和理解。著有《深度解析SDN》。新浪微博ID：@ 盛科張衛(wèi)峰

先說個題外話

眾所周知OpenFlow里面很多行為都是協(xié)議無關(guān)的，在很多人看來都是脫離實際地要求任意靈活，純屬瞎胡鬧。比如要求流規(guī)則中至少匹配12元組，比如要求任意數(shù)量的多級流表，既難實現(xiàn)又找不到應(yīng)用。但是事實上，它的要求是否合理，完全取決于你怎么去理解它。在講正文前，先順便聊一下這個題外話。如果你對OpenFlow標準的理解是：廠家的實現(xiàn)必須要能同時匹配12元組，必須要能支持任意數(shù)量的多級流表，必須要能在流表之間任意跳轉(zhuǎn)，那我可以告訴你，這種要求是做不到的，也是不合理的，這并不是OpenFlow的本意，OpenFlow的本意在于要求你能滿足各種實際應(yīng)用的需求，場景一中需要匹配Mac，那你要能匹配Mac；場景二中需要匹配IP，那你要匹配IP。場景三種需要你先匹配Mac,再匹配IP，你要能做到；而場景四種要求你先匹配IP，再匹配Mac，你也要能做到。換句話說，公司要求你懂中英日韓四國語言，不是要求你同時能講這四種語言，而是要求你碰到日本人能講日文，碰到英國人能講英文，碰到韓國人能講韓文。

現(xiàn)有的純軟件Tunnel Overlay云計算網(wǎng)絡(luò)解決方案

題外話說完了，再回頭講正題。盡管如此，就算是理性的人，也還是覺得難以找到OpenFlow多級流表的實際應(yīng)用案例。今天我就來分享一個在實際生產(chǎn)網(wǎng)絡(luò)中對OpenFlow多級流表的運用，這個實際生產(chǎn)網(wǎng)絡(luò)就是IaaS云計算網(wǎng)絡(luò)，已經(jīng)在客戶那里實際部署。

我們都知道現(xiàn)在最主流的IaaS云計算網(wǎng)絡(luò)的解決方案就是純軟件的Tunnel Overlay，為什么最主流？因為靈活嘛，而且能解決問題。包括現(xiàn)在最火的OpenStack，使用Tunnel Overlay方式來組網(wǎng)的也很多，它在轉(zhuǎn)發(fā)面的大概工作流程就是一個VM發(fā)送報文到vSwitch，vSwitch加上Tunnel Header(VxLAN或者NvGRE)后，從服務(wù)器網(wǎng)卡發(fā)出去，通過中間的物理網(wǎng)絡(luò)，送到目的服務(wù)器上的vSwitch, vSwitch將Tunnel解封裝后，原始報文轉(zhuǎn)發(fā)到目的VM。如下圖所示。

基于硬件的OpenFlow四級流表架構(gòu)

純軟件Tunnel Overlay方案雖然靈活，但是有不同程度的性能問題（程度取決于每個云平臺研發(fā)團隊對它的優(yōu)化力度），而且云計算網(wǎng)絡(luò)中通常都會因為各種各樣的原因，有非虛擬化的設(shè)備，這些設(shè)備如果要接入到tunnel overlay的網(wǎng)絡(luò)中去，必須借助于硬件TOR交換機作為tunnel gateway。

盛科網(wǎng)絡(luò)一直都在為各種應(yīng)用場景進行SDN定制，云計算網(wǎng)絡(luò)作為SDN的目前最重要的應(yīng)用領(lǐng)域，自然也不例外。現(xiàn)在盛科基于SDN提出一種性能優(yōu)化方案，將影響網(wǎng)絡(luò)性能的一些工作從服務(wù)器Offload到TOR交換機上去做，從理念上講并不是把TOR交換機作為物理網(wǎng)絡(luò)的一部分，而是作為服務(wù)器網(wǎng)卡的一部分。該方案已經(jīng)在部分客戶網(wǎng)絡(luò)中部署。現(xiàn)在我們來分享一下OpenFlow多級流表在這個方案中的運用。

在該方案中，云平臺（如OpenStack）跟SDN TOR交換機緊密集成，通過Controller控制SDN TOR交換機的流表下發(fā)，來完成虛擬網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑的建立。VM將報文送到vSwitch，vSwitch直接將報文加上Vlan通過網(wǎng)卡送到TOR交換機，TOR上查流表，去掉VlanTag，識別VM，進而識別Tenant，可選地，可以對VM或者Tenant應(yīng)用一些策略（如限流，安全過濾），然后查表，如果是跨機架送到別的TOR，則加上Tunnel，經(jīng)過中間物理網(wǎng)絡(luò)，送到目的TOR，目的TOR剝?nèi)unnel Header后查表轉(zhuǎn)發(fā)（仍然可以先應(yīng)用策略），到了服務(wù)器上，vSwitch查本地流表（只需要維護本地VM信息）后，轉(zhuǎn)發(fā)到目的VM。整個架構(gòu)和報文流程如下圖所示。

為了完成整個過程，盛科專門針對云計算的應(yīng)用場景，利用交換機芯片內(nèi)置的N-FlowTM技術(shù)，專門研發(fā)出一種四級流表的OpenFlow模型。

每張Flow Table完成的具體功能如下：

Table ID為0的功能： 

• VM識別（基于macSa）；
• 租戶識別（基于macSa or Vlan）；
• Tunnel識別（基于Tunnel VniId）；
• 基于VM或者租戶的策略應(yīng)用；
• 傳遞metadata到后面；

Table ID為1的功能：

• 全局安全或者QoS策略應(yīng)用
• 決定下一級table跳轉(zhuǎn)到2還是3

Table ID為2的功能：

• 二層流表轉(zhuǎn)發(fā)到Port或者Tunnel

Table ID為3的功能：

• 三層流表轉(zhuǎn)發(fā)到Port或者Tunnel

跟云平臺的集成

云平臺直接通過盛科提供的（或者用戶自己寫的）插件跟一個集中式的Controller打交道（當(dāng)然用戶也可以出于可擴展性的考慮自己設(shè)計分布式Controller），通過這個Controller的標準OpenFlow接口去控制交換機，大量的工作（抽象信息翻譯成流表）是在插件里面做的。這種架構(gòu)的一個好處是可以兼容不同廠商的設(shè)備，只要這些設(shè)備都能支持云平臺所需要的OpenFlow的能力（比如多級流表），支持足夠數(shù)量的Tenant和VM。

Controller跟TOR交換機之間的消息不僅僅有OpenFlow消息，還需要OVSDB消息，用來創(chuàng)建Tunnel（OpenFlow并不支持創(chuàng)建Tunnel）。

原則上這種架構(gòu)可以跟任何云平臺集成，我們以O(shè)penStack為例來說明如何將多級流表SDN TOR交換機集成到云平臺中。

如下圖所示，計算節(jié)點上的OVS Agent跟盛科 插件之間只有Query消息，是OVS Agent主動發(fā)過來查詢VlanId/TunnelId的。所有的流表項配置消息都僅僅發(fā)生在Controller和SDN TOR之間，將Neutron Server所需要控制的節(jié)點數(shù)量從Hypervisor的數(shù)量級降低到TOR的數(shù)量級，可以大大緩解控制面的壓力，提高云平臺的可擴展性。

總結(jié)

SDN時代的網(wǎng)絡(luò)，不再是以設(shè)備為中心，而是以應(yīng)用為中心，應(yīng)用驅(qū)動網(wǎng)絡(luò)變革。這就需要很多深度定制的工作，云計算網(wǎng)絡(luò)尤其如此。OpenFlow協(xié)議設(shè)計了多級流表，一直以來我們都沒看到有什么典型的應(yīng)用場景。本文所介紹的這個例子，可以算是OpenFlow多級流表的一個絕佳實踐，我們能看到這個方案帶來的明顯的優(yōu)勢。

1. 它基于標準的OpenFlow接口，可以防止廠商鎖定，只要廠商支持OpenFlow多級流表，且能支持相應(yīng)的匹配字段和編輯動作。
2. 讓Server專注于計算，將流表查找、Tunnel加解封裝、QoS、Security Group等網(wǎng)絡(luò)處理功能都Offload到TOR，可以大大減輕Server負擔(dān)，提升網(wǎng)絡(luò)性能。
3. 分布式L3 Gateway的設(shè)計，特別是將L3 Gateway做到TOR上，可以避免集中式L3 Gateway帶來的single point failure的風(fēng)險，并消除它的性能瓶頸。而且是將router功能做在TOR而非hypervisor，可提升路由性能。
4. 將云平臺需要控制的網(wǎng)絡(luò)節(jié)點數(shù)量從Hypervisor的數(shù)量變?yōu)門OR的數(shù)量，降低了一個數(shù)量級，有效減輕云平臺的可擴展性壓力。特別是在VM遷移的時候，需要去更新的節(jié)點數(shù)量降低一個數(shù)量級。
5. 可以很好地支持非虛擬化環(huán)境。
6. TOR仍然可以對用戶數(shù)據(jù)應(yīng)用策略，進行監(jiān)控，極大緩解了純軟件方案帶來的網(wǎng)絡(luò)不可視問題。

（責(zé)編：周小璐）

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機掃描二維碼進行捐贈