使用 OVS DPDK 加速滴滴雲網路

在基於現有 ovs-dpdk 開源軟體基礎上，滴滴雲技術團隊通過創新性的改進，實現了 ms 級別的熱公升級，同時保持現有的高效能**能力。

滴滴雲初期採⽤學習 openstack 的思路，採用核心態的 ovs 實現了 sdn overlay 網路。這個實踐過程中，我們也遇到了一些問題，可以歸納為以下幾個⽅面：

基於 vf 的資料流改造

借助硬體將 overlay 的流量與宿主機的其他⽹絡流量進⾏分離。通過 flow classification 命令將前者導⼊到 vf 上，而後者仍然是通過 pf 口到核心進行處理，保持原有處理邏輯不變。ovs- dpdk 只接管 vf ⽹口，⽽不觸碰 pf 口上的非 sdn overlay ⽹絡流量。

這樣既簡化了 ovs-dpdk 的處理邏輯，同時也避免了因 ovs-dpdk 本身的穩定性，而影響其他⾮ sdn ⽹絡模組的穩定性。

無狀態的**功能

⽬前，我們對計算節點⽹絡層面的需求，可以分為兩大類：vm 流量的**和 vm 網路的安全監控。其中後者是內部開發的，暫時略過。

針對 vm 流量**的這個需求，⼜拆解為兩部分：overlay 外層頭的處理和內層報文的**。

借助 ovs-dpdk 的 flow 表實現這兩部分功能。因為沒有啟⽤ conntrack 功能，因此我們這部分的實現是⽆狀態的。這個拆解，特別是無狀態的特性，在熱公升級的時候取得了不錯的效果。

ovs 單網橋

之前參考 openstack 的模型，我們使⽤了 br-int，br-tunnel 兩個網橋。在這個模型裡，ovs ⽹橋的使⽤方式跟傳統的 bridge 使⽤⽅式差別不大，沒有充分發揮 ovs ⽹橋的優勢。

在我們的模型中，把兩個網橋集成為乙個網橋，將 vxlan ⼝和 vhost-user 的⼝都放到⽤⼀個網橋上。vm 發出的報⽂經過 ovs **處理後，攜帶外層頭資訊進入 vxlan 驅動，經過 vxlan 網口的封裝後，傳送給 vf 網口。

根據我們的資料模型，進入 vf ⼝的報⽂只可能是發往 vm 的 vxlan 型別的報文。這些報文，在被剝除 vxlan 頭後，經過 vxlan ⼝進⼊網橋，經過⽹橋**到各個 vm 的 vport 。

降低與核心的耦合性

原有的 ovs 橋的路由和 arp 表需要去核心查詢，跟核心的耦合性很強。

我們通過 sdn 控制器下發到 ovs-dpdk，來規避直接與核心的互動。這樣⼀方⾯簡化了 bridge 的配置(不用單獨設定ip位址等)，降低了核心的耦合性，另⼀方⾯也降低了熱公升級時候的複雜度。

vhost-user增強

我們使用的是 qemu 作為 vhost-user 的 server 端，ovs-dpdk 程序通過 unixsocket 連線到 qemu。qemu 預設僅支援乙個這樣的連線，改造 qemu 後，使得 qemu 支援兩個主備倒換的連線，這樣熱公升級的時候，可以通過控制 ovs-dpdk 端的開關，輕鬆的在新⽼兩個程序間切換。

記憶體模型採用 2m/4k。

儘量減少對現有 vm 的影響，為以後公升級和遷移做準備。

公升級時間短：業內⽬前的熱公升級方案基本都是秒級的，切換時間⽐較長。而在我們的框架下，每個vm的熱公升級時間大約 80ms 左右，極大的縮短了 vm 的網路中斷時間，基本做到⽤戶無感知。

可擴充套件性好：熱公升級過程中，vm ⽹絡中斷時間跟 vm 規模無關。熱公升級的時候，我們逐個把 vm 的流量從⽼的 ovs-dpdk 程序裡，切換到新的程序裡。這種逐個切換的模式，使得單個 vm 的流量切換，不會影響其他的 vm 網路功能。即使上百個 vm，總的公升級時間達到⼏秒甚至⼏十秒的情況下，單個 vm 的⽹絡中斷時間仍然是 80ms。

故障恢復快：我們熱公升級的模型中採⽤的是兩個獨⽴的 ovs-dpdk 程序，因此提前啟動乙個新的 ovs-dpdk 程序作為後備程序，這個程序完成所有熱公升級相關的初始化，比如初始化 vf2。這樣當原有 ovs-dpdk 程序 crash 後，新的程序可以做快速的切換，實驗室環境下，單 vm 測試可以做到跟熱公升級時間差不多。

使用 OVS DPDK 加速滴滴雲網路

使用阿里雲Docker映象加速

docker 使用阿里雲映象加速

如何使用阿里雲加速Docker映象拉取

使用 OVS DPDK 加速滴滴雲網路

使用阿里雲Docker映象加速

docker 使用阿里雲映象加速

如何使用阿里雲加速Docker映象拉取

相關推薦