出品 | 滴滴技術
做者 | 張軍偉安全
在基於現有 OVS-DPDK 開源軟件基礎上,滴滴雲技術團隊經過創新性的改進,實現了ms級別的熱升級, 同時保持現有的高性能轉發能力。網絡
背景
滴滴雲初期採⽤學習OpenStack的思路,採用內核態的OVS實現了SDN OverLay網絡。這個實踐過程當中,咱們也遇到了一些問題,能夠概括爲如下幾個⽅面:框架
原型設計socket
針對這些問題,通過技術調研,也參考了國內外同⾏的已有解決方案,在過程當中和Intel團隊緊密合做,咱們採用OVS-DPDK進⾏開發部署,並最終取得了不錯的效果。以下是數據流模型:性能
| 數據層面的幾個重要改造學習
1. 底層:⽹卡硬件相關測試
- 基於VF的數據流改造spa
藉助硬件將OverLay的流量與宿主機的其餘⽹絡流量進⾏分離。經過flow classification命令將前者導⼊到VF上,然後者仍然是經過PF口到內核進行處理,保持原有處理邏輯不變。OVS- DPDK只接管VF⽹口,⽽不觸碰PF口上的非SDN OverLay⽹絡流量。這樣既簡化了OVS-DPDK的處理邏輯,同時也避免了因OVS-DPDK自己的穩定性,而影響其餘⾮SDN⽹絡模塊的穩定性。設計
2. 中間層:OVS 報⽂處理unix
- 無狀態的轉發功能
⽬前,咱們對計算節點⽹絡層面的需求,能夠分爲兩大類:VM流量的轉發和VM網絡的安全監控。其中後者是內部開發的,暫時略過。
針對VM流量轉發的這個需求,⼜拆解爲兩部分:
OverLay外層頭的處理,和內層報文的轉發。藉助OVS-DPDK的flow表實現這兩部分功能。由於沒有啓⽤conntrack功能,所以咱們這部分的實現是⽆狀態的。這個拆解,特別是無狀態的特性,在熱升級的時候取得了不錯的效果。
以前參考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地址等),下降了內核的耦合性,另⼀方⾯也下降了熱升級時候的複雜度。
3. 上層vhost-user與VM交互層
咱們使用的是QEMU做爲vhost-user的Server端,OVS-DPDK進程經過unixsocket鏈接到QEMU。QEMU默認僅支持一個這樣的鏈接,改造QEMU後,使得QEMU支持兩個主備倒換的鏈接,這樣熱升級的時候,能夠經過控制OVS-DPDK端的開關,輕鬆的在新⽼兩個進程間切換。
儘可能減小對現有VM的影響,爲之後升級和遷移作準備。
1. 升級時間短
業內⽬前的熱升級方案基本都是秒級的,切換時間⽐較長。而在咱們的框架下,每一個VM的熱升級時間大約80ms左右,極大的縮短了VM的網絡中斷時間,基本作到⽤戶無感知。
2. 可擴展性好
熱升級過程當中,VM⽹絡中斷時間跟VM規模無關。熱升級的時候,咱們逐個把VM的流量從⽼的OVS-DPDK進程里,切換到新的進程里。這種逐個切換的模式,使得單個VM的流量切換,不會影響其餘的VM網絡功能。即便上百個VM,總的升級時間達到⼏秒甚至⼏十秒的狀況下,單個VM的⽹絡中斷時間仍然是80ms。
3. 故障恢復快
咱們熱升級的模型中採⽤的是兩個獨⽴的OVS-DPDK進程,所以提早啓動一個新的OVS-DPDK進程做爲後備進程,這個進程完成全部熱升級相關的初始化,好比初始化vf2。這樣當原有OVS-DPDK進程Crash後,新的進程能夠作快速的切換,實驗室環境下,單VM測試能夠作到跟熱升級時間差很少。
附上測試數據
性能:單核性能400wpps左右
熱升級:單VM網絡中斷時間 80ms 左右
DPDK version:17.11
OVS version:2.9.0
QEMU version:2.9
CPU:Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz kernel:3.10.0-514.16.1.el7.x86_64
NIC:Ethernet Controller X710 for 10GbE SFP+ 1572