導讀 OpenBox: A Software-Defined Framework for Developing,Deploying, and Managing Network Functions

概要

作者提出名為 OpenBox 的 NFV 框架,可有效的將 NF 從 data plane 中解耦 control plane,有點像是 SDN 只解決網路的 forwarding plane。方法是將 NF 拆成多個 block(Click element),再利用合併方式消除 chain 中重複的 block。

此框架包含三種邏輯上的元件:

  • Application
    • 可透過 north-bound API 來指定 NF
  • Controller
    • 可合併多個 NF 的邏輯(可能來自不同租戶
    • 以 network-wide 的觀點在 data plane 有效的部署、擴展 NF
  • Instance
    • 為 data plane,可以是軟體或硬體

/img/OpenBox/Untitled.png

實際上,不同的 NF 做著類似的事情,此篇論文展現了重大的效能突破,並且透過 controller 支援智慧 placement、scaling、multi-tenancy。

編按:作者為三位以色列博士,研究室主要方向為 DPI

介紹

SDN 解決了許多 forwarding plane 的問題,像是花費、管理、多租戶、高進入門檻等等。

然而只有 forwarding appliances 是使用軟體打造的,data plane appliances 仍舊飽受於上面的問題,因此 NFV 出現了。研究顯示 NF 在大型網路當中佔了40~60%。

現今的網路流量在到達目的地前,通常會經過一連串的 NF(或是說 service chain),例如防火牆、IPS、負載平衡。

這些 NF 實際上用了非常相似的處理步驟,像是解析 header 後進行分類、修改 header、根據 L7 Payload 進行分類。

到目前為止(2016),此篇應是第一個提出如此分離架構的。同時也提出了 merge algorithm,用來在 control plane 合併 NF 們的核心邏輯,像是只做一次運算密集型的操作(例如 DPI)。

此專案是建立在 Mininet VM 上,並且有開源實作程式碼,同時也支援硬體 OBI 來加速運行。

架構

每個 NF 各自有其管理介面,且經由不同的機構管理,因此他們彼此不該知道彼此的存在

OpenBox 有效的解決管理問題,使用自行定義的 protocol 將 NF 的 control plane 完全解離出來。

  • OBI (OpenBox Instance)
    • 通用型 data plane entity
    • 許多 NF 有相似的 data plane 卻有不同的 control plane
    • 會通知 controller 其可提供的 abstract processing block 的實作
    • 套用由 controller 給的 processing graph
    • 向 controller 回報負載、系統資訊
  • OBC (OpenBox Controller)
    • logically-centralized control plane
    • 將 application 們的 logic 部署到 OBI
    • 了解 application 的行為意圖
  • Application (OpenBox Application)
    • NF 們
  • Protocol
    • 定義了 OBC 與 OBI 之間的 communication channel

開發

開發者可以使用基本的 building blocks(像是 header classification) 來開發、部署新的 NF 為 OpenBox Application 。

Data plane 除了這些基本的 building block 之外,application 還可以透過在 control plane 提供 extension module code 來擴充其功能,這些 module code 接著會被注入到相對應的 OBI 之中,且不需要重新編譯或是重新部署。

封包處理抽象化

Processing Graph

封包處理被抽象成有向無環的 processing graph,由許多的 processing block 組成。

  • Processing graph
    • 概念跟 Click 的 router configuration 很像
  • Processing block
    • 概念跟 Click 的 element 很像
    • 代表一個單一、封裝的邏輯單元
    • 用來對封包進行操作
    • 有 1 個以上的 input port,0 或多個 output port,每個 output port 會透過 connector 連接到一個 input port。
    • 可以代表任何針對封包、資料的操作
    • 可以在轉傳前緩存、接合、分離封包

然而 OpenBox Protocol 隱藏了低階的東東像是 Click 的 push/pull 機制。

在實作方面,作者將每個 processing block 對應到 Click 的 element 們或是自行實作的 element(如果沒有相對應的 Click element)。

/img/OpenBox/Untitled%201.png

  • Protocol
    • 定義了超過 40 種 abstract processing block
    • Abstract processing block 在 data plane 可能會有多種實作,依賴於底層的軟體或硬體(像是軟體用 trie,硬體用 TCAM
    • 允許從 controller 注入客製化 block

合併多個 graph

該框架允許在單一個 data plane location 執行多個 NF,並且在保證運行正確的前提下合併多個 graph,由於 block 減少了,整體延遲也會跟著減少。

執得注意的是,減少了多少個 block 不是重點,減少整體長度才能有效減少其延遲。

為了要塑造 merge algorithm,作者替 block 分成五個種類:

  • Terminals (T):開始、結束處理封包的 block。
  • Classifiers (C):替封包分類,並轉送到指定 port。
  • Modifiers (M):修改封包。
  • Shapers (Sh):做 traffic shaping,像是 active queue management、rate limiting。
  • Statics (St):不更改封包內容、不更改轉送路徑,也就是不屬於上述的種類。

為了要保持處理的正確性:

  • 可以更改 Static 的位置
  • 可以將 Classifier 移到 Static 前面
  • 不可以將 Classifier 在 Modifier、Shaper 間移動
  • 可以合併 Classifier(需注意 rule set 合併、output path
  • 可以合併 Static、Modifier(只有在一些情況

/img/OpenBox/Untitled%202.png

演算法分成四步驟:

  1. 將 processing graph 歸一化成 processing tree,使得路徑不會收斂

    編按:收斂? The process of graph normalization may theoretically lead to an exponential number of blocks. This only happens with a certain graph structure, and it never happened in our experiments. However, if it does, our system rolls back to the na ̈ıve merge

  2. 根據執行順序將 processing tree 串起來

    • 這時候,每個 tree 的長度(從 root 到 leaf)仍一樣(歸一化之前)
    • 總 block 數量最多為 $G_1 = (v_1, E_1), G_2=(V_2, E_2) \Longrightarrow |V_1|^2(1+|V_2|^2)$
    • 此外,如果 overhead 太高時,兩個 graph 不該被合併

    編按:overhead 是指什麼?

  3. 重新排序、合併 block(第 7 行)

    • 優先權處理(第 18~29 行)
    • 此演算法會在每個 path 中遞迴處理

    /img/OpenBox/Untitled%203.png

  4. 消除相同 block 的複製品

    • 此時會覆寫 connector 以保留單一副本
    • 最終結果如 Figure 4,長度比較短
    • 結果不一定得是 tree

/img/OpenBox/Untitled%204.png

架構

Data Plane

  • 由 OBI 組成,是 low-level 封包處理器
  • 從 controller 收到且套用 processing graph,並且回報其負載、系統資訊
  • 可由軟體(VM,可擴展)、硬體組成
  • 在傳給 OBC 的 Hello 訊息中,宣告其實作的 block type、相對應的 abstract block
  • OBC 可能明確指出 processing graph 的實作,或是僅點出 abstract block 名稱讓 OBI 自行實作

編按:OBI 自行實作這部分論文中沒有明講

  • 一個 OBI 可能只負責 processing graph 的其中一部分
  • OBI 會在轉送前在封包上添加 metadata,告知下一個 OBI 一些重要資訊(只有在 processing graph 有分岔時才需要)

/img/OpenBox/Untitled%205.png

/img/OpenBox/Untitled%206.png

實作上,作者使用 NSH(Network Service Header)來將 metadata 附加於封包上,其他像是 VXLANGeneveFlowTags 也可以用,但可能會需要增加 MTU。

不同的 OpenBox Application 需要不同大小的 metadata 空間,大多情況下都需要的不多,因其主要是告訴下一個 OBI 要往哪條路走。

編按:那下下一個呢?

  • 可以使用外部服務來進行 out-of-band 操作
    • 像是 logging、storage
    • OpenBox protocol 定義了這兩種服務,可用來做快取、隔離
    • 這些服務是經由外部伺服器(也可能在同台主機上)

Protocol

定義了溝通用的 message 集合、可用來部署 NF Application 的 processing block 集合。

就像是 Click 的 element 一樣,block 可能會有 read handleswrite handles

  • Read handles
    • 向 processing block 請求特定的資訊
    • 允許 Application、Controller 使用
  • Write handles
    • 更改 data plane 中 processing block 的值
    • 允許 control plane 使用
    • 舉例:重設計數器、修改配置參數

自定義 Module 注入

可以讓 Application 開發者擴充現有 OBI 而不需要修改其程式碼、也不須重新編譯或是部署。

方式是依照目標 OBI 的格式編譯出相對應的二進位檔案,在作者的實作中是編譯成 Click module。當這個 module 需要被使用時,controller 會發出 AddCustomModuleRequest 訊息與二進位檔案到 OBI,訊息內容包含 metadata 如檔案名稱、配置資訊、版本號等等。

Control Plane

OBC 是 logically centralized 的軟體伺服器,負責管理 OBI 的所有事情:

  • 設定處理邏輯
  • Control provisioning
  • 擴展執行個體

在 SDN 的環境下,OBC 可以連接到 traffic-steering 應用程式,以控制執行個體之間的連結、封包導向。

OBC 與 OBI 透過雙向的 REST 通道,使用 JSON 格式進行通訊。

作者使用階層式的 segment 來區分不同的邏輯分區,像是不同部門、管理範圍、租戶等等,他們可以分別套用不同的設定、NF。因此 Application 可以藉由設定 processing graph 的 segment 來宣告其邏輯,或是指定 OBI。這方法提供了網路管理上面的彈性,如支援安全、監控等等,同時支援 micro-segmentation 以降低 network segment 的大小。

在取得 OBI 的資訊後,controller 可以替執行個體做擴展、合併 task、合併 instance 等等,甚至可以降低 Application 運算複雜度。

編按:那為何不一開始就降低複雜度?有例子嗎?

因為 application 是依據 segment 做調整的,OBC 會負責替 OBI 導流。

OpenBox Applications

Application 使用statement 定義了 NF,每個 statement 都有用來指定 network segment 或特定 OBI 的 location specifier

Application 是:

  • 事件驅動
    • 事件可能會改變其狀態、傳送重新設定 message 到下游
    • 舉例:IPS 偵測到惡意攻擊後,改變網路設定以阻擋其流量
  • 如果事件發生得太頻繁,會將該 Application 做標記,之後 controller 看到標記後便不會對其更改請求做出反應

多租戶

OpenBox 允許多個網路租戶使用同個 controller 來部署 NF,分享 data plane 以減少開銷。

Application 狀態管理

許多 NF 都是有狀態的,因此狀態的管理是必須要有的,舉例來說 Snort 會記錄每條 flow 的資訊。

因為狀態是在 data plane 被使用,為了加速運行理當儲存在 data plane 當中,同時 protocol 提供了兩個資料結構給 OBI 來使用:

  • Metadata storage
    • 短暫、鍵值儲存
    • 用途是給特定封包一些特殊資訊
    • 其夾帶資訊會繞經所有 OBI
  • Session storage
    • 依附於 flow,flow 在它就在
    • 這對 stateful NF 的程式撰寫上很有幫助
    • 例如:flow tags, search state

作者提到可以使用 OpenNF 之類的框架來達成 OBI 的 replication、migration,如此可以保留其原本已儲存的資料,以確保執行的正確性。

實作

主要分成兩部分:OBI 與 OBC。

作者有提供安裝腳本,皆是運行在 Mininet VM 中。

Controller 實作

使用了 7500 行的 Java 運行了 REST API 伺服器,並且開放了兩個 package:

  • 第一個
    • 提供 prototol 中定義的基本結構
  • 第二個
    • 讓開發者在 controller 上定義、註冊 application,同時管理事件
    • 允許發送 read request 與 write request 來觸發 read/write handle
    • request 發出時可以順便攜帶一個 callback 函數

同時也開發了範例 application 像是防火牆、IPS、負載平衡器,此外也實作了流量導引 application 像是 OpenDaylight 的外掛。

Service Instance 實作

實作可以分成 generic wrapper 與 execution engine。

Generic wrapper 使用 5500 行 Python 撰寫,負責處理與 controller、storage、log 伺服器的通訊,並且將 protocol 轉譯到特定的底層 execution engine。

編按:為何需要 translation?

Execution engine 使用 Click modular router 在 user-level 以 2400 行 C++ 實作,能與 wrapper、storage server、許多 Click element 通訊。(備註:一個 OpenBox block 通常是由多個 Click block 組成)

藉由修改 wrapper 中的 translation module,底層的 execution engine 即可被替換,尤其是要使用硬體 execution engine 時。

如果要擴充 OBI 則須以 C++ 撰寫 Click module(element),並且用 Python 實作 translation object 來幫助 wrapper 解析新的 OpenBox block definition。

實驗

環境

  • Traffic generator
    • E3-1270 v3
    • 32G RAM
  • Hypervisor
    • Dual E5-2690 v3
    • 384G RAM
    • Ubuntu 14.04 with KVM
    • 10 Gbps NIC

測試應用

  • Firewall
    • 4560 條規則,為了測試 throughput 有調整規則以至於不會 drop 封包
  • IPS
    • 使用 Snort web rules 去掃描 header 與 payload,同樣有避免 drop
  • Web Cache
  • Load Balancer

測試配置

分流:

/img/OpenBox/Untitled%207.png

多租戶:

/img/OpenBox/Untitled%208.png

Pipeline NF 的效能測試結果:

/img/OpenBox/Untitled%209.png

Related Work

  • CoMb:專注於多個虛擬 middlebox 的 consolidation。
  • E2:對多個 VNF 做 scheduling 的框架,專注於特定的硬體。

上述兩個專注於解構 NF 以提供 I/O 最佳化,像是 zero-copy、TCP reconstruction,但沒有核心 processing block 的重用機制(如 classifier、modifier)。

  • xOMB:提供了運行 middlebox 的軟體平台,卻沒有 consolidate 多個 application 到相同 processing pipeline。
  • ClickOS:基於 Click modular router 的 VNF 執行環境,提供 I/O 最佳化以減少 latency,但沒有 network-wide centralized control,也沒對多個 VNF 進行合併。

商用解決方案如 OpenStack、OpNFV、UNIFY 專注於 orchestration 問題,假設每個 NF 都位於 monolithic VM 當中,並嘗試解決 scaling、placement、provisioning、migration 問題。

  • OpenNF:提出能夠在 VNF 間分享資訊的 centralized control plane。然而只重視 migration 與 replication 時發生的 state sharing、forwarding 問題。
  • OpenState:SDN switch 的有狀態程式語言,將 finite automata rule 套用到 switch 上,而不只是使用 match-action rule。
  • SNAP:SDN switch 的有狀態程式語言,使用 network-wide 的方法撰寫 “one big switch”,再經由 compiler 決定 local policy。
  • P4:可程式化封包處理語言,旨在定義通用型處理器的 match-action table。可用在 OpenBox 的 data plane 來解析相對應的 protocol。

comments powered by Disqus