目錄
1 背景
2 CLOUD-DPVS網關整體架構
2.1 CLOUD-DPVS網關整體架構選型
3 CLOUD-DPVS網關方案概述
3.1 高可用方案的改進
3.1.1 支援BFD探測
3.2 負載均衡轉發層适配
3.2.1 FULLNAT模式
3.2.2 引入VPC的概念
3.2.3 cloud-dpvs轉發原理
3.2.3 增加VXLAN子產品
4 CLOUD-DPVS後續工作
5 參考文章
1 背景
随着雲計算和網絡技術的不斷發展，越來越多的業務有着上雲的需求。上雲後，業務能夠使用雲上已有的服務提升開發效率，也可以利用雲平台的彈性伸縮特性，及時應對業務的負載變化。實際生産環境中，使用者的服務一部分部署在雲平台上，另一部分部署在自己的IDC機房。使用者有從VPC通路IDC中服務的需求，且IDC内的服務需要支援負載均衡。為了實作IDC的平滑上雲，必須打通VPC網絡到IDC機房經典網絡間的互聯互通，其中最核心的裝置是VXLAN網關，用來完成VXLAN網絡和VLAN網絡間的映射。雖然可以通過交換機完成VXLAN到VLAN的轉換，但是業務的負載均衡需求無法滿足。是以，360虛拟化團隊根據業務需求，決定自研CLOUD-DPVS裝置支援負載均衡、VXLAN隧道、BFD探活等功能，來實作VPC網絡到IDC網絡的互聯互通。
2 CLOUD-DPVS網關整體架構
CLOUD-DPVS工作在VXLAN網絡和VLAN網絡的中間層，來自VPC網絡的使用者請求被引流到CLOUD-DPVS網關，進行VXLAN解封裝和SNAT/DNAT處理後，請求被發送至IDC内服務所在的機器上。回包同樣會經過CLOUD-DPVS進行SNAT/DNAT後，進行VXLAN封裝發送至VPC。
2.1 CLOUD-DPVS網關整體架構選型
為了滿足高性能，多主部署和負載均衡等需求，360虛拟化團隊在經過調研後決定在DPVS的基礎上進行開發。
DPVS是一個基于DPDK軟體庫加速LVS的高性能負載均衡器，通過使用網卡使用者态驅動、零拷貝、大頁記憶體和隊列綁定等技術解決了LVS的性能瓶頸，同時保留LVS的負載均衡邏輯。基于DPVS，我們隻需要在現有邏輯的基礎上增加VPC屬性，支援VXLAN封裝解封裝等功能，就可以為每個VPC業務提供虛拟IP來通路IDC内的服務。選型完成後随即啟動了cloud-dpvs的項目，其核心架構如下：
3 CLOUD-DPVS網關方案概述
3.1 高可用方案的改進
傳統的高可用方案大都采用 BGP+ECMP 的模式建構叢集，用 ECMP 将資料包散列到叢集中各個節點上，通過 BGP 協定保證單台機器故障後将這台機器的路由動态剔除出去，由此做到了動态 failover，組網結構如下圖所示：
伺服器通過 BGP 将 VIP 釋出到網絡中，交換機學習到 VIP，形成 BGP 等價多路徑路由（ecmp），然後根據哈希因子計算得到 hash lb key，進行 ECMP 下一跳鍊路數(Member-count)求餘計算，再與 ECMP 基值進行加法運算得出轉發下一跳 index，即确定了下一跳轉發路由到達伺服器。
這種方式要求伺服器必須部署在三層網絡中，需要與交換機建立BGP連接配接。另外伺服器叢集出現問題後，其恢複時間受限于BGP協定的收斂時間，這個時間值一般是秒級，根據以往在現網環境中的經驗，叢集的收斂時間一般在6~9秒左右。
為了提高收斂時間和減少對環境的依賴，360虛拟化團隊對上面提到的兩點進行了改進，引入BFD協定将收斂時間減少到毫秒級别，并在VPC網絡中增加排程器使其不再依賴底層網絡就可以把流量hash到各台伺服器上。
3.1.1 支援BFD探測
BFD(Bidirectional Forwarding Detection) 雙向轉發檢測協定，提供了一個通用的标準化的媒體無關和協定無關的快速故障檢測機制。具有以下優點：
1.對網絡裝置間任意類型的雙向轉發路徑進行故障檢測，包括直連實體鍊路、虛電路、隧道、MPLS LSP、多跳路由路徑以及單向鍊路等
2.可以為不同的上層應用服務，提供一緻的快速故障檢測時間
3. 提供小于1s的檢測時間，進而加快網絡收斂速度，減少應用中斷時間，提高網絡的可靠性
利用BFD的優點，VPC内的機器會周期性向CLOUD-DPVS各個節點發送BFD探測封包，根據探測結果動态更新hash計算結果，選擇可用的CLOUD-DPVS伺服器，進而保證服務的高可用。
在CLOUD-DPVS中，我們實作了BFD協定處理子產品，并将其挂載在INET_HOOK_PRE_ROUTING。當資料包進入CLOUD-DPVS後，優先判斷其是否為BFD封包，并回複相應狀态的BFD封包，如STATE_INIT/STATE_UP。
3.2 負載均衡轉發層适配
3.2.1 FULLNAT模式
DPVS支援NAT、Tunnel、DR和FULLNAT等幾種負載均衡模式，但是 NAT、DR、Tunnel這三種模式都有一定的限制，需要一定的環境的支援，才能正常的工作
- DR模式的限制：RS跟Director Server必須有一個網卡在同一個實體網絡中
- TUNNEL必須在所有的realserver上綁定VIP
- NAT：RS的網關必須指向LVS所在伺服器
而FULLNAT模式通過對入封包做了DNAT+SNAT，即将封包的目的位址改為RS的位址，源位址改為DPVS裝置位址；RS上不需要配置路由政策，回包到達DPVS裝置後做SNAT+DNAT，即将封包的源位址改為DPVS裝置上的VIP位址，目的位址改為真實的使用者位址，進而規避上面三種方式的限制，使其組網更加的靈活，适應性更強，是以CLOUD-DPVS網關使用的是FULLNAT模式。
3.2.2 引入VPC的概念
DPVS社群最初設計的應用場景是IDC的經典網絡，并不适用于雲化場景。雲化場景與IDC經典網絡最核心的差別是：經典網絡提供的是多使用者共享的網絡，而VPC提供的是使用者專屬的網絡。VPC内使用者可以任意定義雲主機的IP位址，而在經典網絡模式下，大家擠在一個二層網絡裡面，IP位址首先要保證不能重合。
如上圖所示，VIP:PORT可以唯一表示一個服務，服務後面挂載了多個執行個體，但在雲化場景下，其VIP位址是可以重複的，是以仍然使用VIP:PORT來表示一個具體服務就行不通了。是以CLOUD-DPVS轉發層面不能繼續沿用DPVS原有的處理邏輯，為了解決這個問題研發團隊引入了租戶VPC的概念，把服務和VPC關聯起來，不同的VPC可以有相同的VIP:PORT，這也與實際使用方式相吻合，改造後就變成了VXLAN+VIP:PORT來表示一個服務，具體如下圖所示：
基于DPDK實作VPC和IDC間互聯互通的高性能網關1 背景2 CLOUD-DPVS網關整體架構3 CLOUD-DPVS網關方案概述4 CLOUD-DPVS後續工作5 參考文章 3.2.3 cloud-dpvs轉發原理
為實作其轉發功能，在cloud-dpvs上新增了伺服器資訊表和虛機資訊表，其中服務資訊表由vxlan和VIP:PORT以及RS:PORT等資訊組成，表格式如表1所示：
| Vxlan | VIP | vPort | RS-IP | Port |
| 96 | 172.16.25.13 | 80 | 10.182.10.13 | 80 |
| 96 | 172.16.25.13 | 80 | 10.182.10.23 | 80 |
| 101 | 172.16.25.13 | 8080 | 10.182.20.2 | 80 |
表1：服務資訊表
其中Vxlan+VIP+vPort代表VPC内的一個公共服務，使用者VPC私有網絡内的用戶端可以通過通路VIP+vPort來使用其公共服務，用戶端感覺到VIP是私有網絡内的私網IP位址，由cloud-dpvs實作私網VIP到IDC網絡位址的映射，其映射關系和後端Real-Sever對使用者無感覺。
虛拟資訊表由vxlan、虛機IP、虛機MAC以及主控端IP位址組成，表格式如表2所示：
| Vxlan | 虛機IP | 虛機MAC | 主控端IP |
| 96 | 172.16.25.30 | fa:16:3f:5d:6c:08 | 10.162.10.13 |
| 96 | 172.16.25.23 | fa:16:3f:5d:7c:08 | 10.162.10.23 |
| 101 | 172.16.25.30 | fa:16:3f:5d:6c:81 | 10.192.20.2 |
表2：虛機資訊表
在虛拟化VPC網絡中，由于使用者可以按需自定其私有IP位址，所有不同VPC内的虛機IP位址可能存在重複，故無法以IP位址來唯一确定一台伺服器或者虛機，在cloud-dpvs的實作中采用了Vxlan+虛機IP的方式來表示虛機或者伺服器。
VPC内的虛機通路VIP:vPort的流量通過OVS内流表規則引流到Vxlan隧道後流量到達cloud-dpvs網關，網關根據查詢服務資訊表查詢服務挂在的後端Real-Server,然後再根據一定的排程算法把流量分發給具體的Real-Server伺服器，具體路徑如下圖所示：
| 流量路徑說明 | |
|---|---|
| 1 | VPC内Client發起對VIP:vPort的通路請求 |
| 2 | 流量經過OVS時，會根據流表規則把流量引入Vxlan隧道進行vxlan封裝，其外層目的IP位址為Cloud-dpvs網關的IP，外層源IP位址為虛機所在的主控端IP位址 |
| 3 | 流量到達Cloud-dpvs網關後，對隧道封包進行解封裝，提取封包的vxlanId以及内層的目的IP和Port，由三者即可确定一個VPC内的公共服務 |
| 4 | Cloud-dpvs根據公共服務上配置的排程算法選擇其上挂載的Real-Server伺服器，然後對封包進行映射修改封包的目的IP位址和端口并對映射關系進行記錄，最終把流量引流到IDC網絡的一台實體伺服器 |
| 5 | 後端Real-Server對封包處理完成後，按照源流量路徑會把流量傳回給Cloud-dpvs網關 |
| 6 | Cloud-dpvs收到後端Real-Server傳回的封包，首先查找映射關系表，擷取會話所屬的公共服務，并對封包的源目IP頭進行修改，修改後的目的IP即為虛機IP位址 |
| 7 | 根據公共服務裡的VxlanId和封包的目的IP位址可以确定唯一一台虛機，然後根據虛機資訊表可以獲知虛機MAC位址以及虛機所在的主控端IP |
| 8 | 根據擷取虛機MAC和主控端IP對封包進行封裝Vxlan頭操作，虛機MAC位址為内層目的MAC，主控端IP為外層目的IP，源IP位址使用Cloud-dpvs的IP位址，封裝後的vxlan隧道封包經過underlay網絡的轉發，封包會到達虛機所在主控端 |
| 9 | vxlan隧道封包在虛機所在主控端上按照OVS流表進行解封裝，并按照OVS流表的轉發規則把封包送入對應的VPC内的Client |
3.2.3 增加VXLAN子產品
雲化場景下，所有來自VPC的請求都進行了VXLAN封裝。CLOUD-DPVS在轉發層實作了VXLAN子產品，用于解封VPC發來的VXLAN資料包，保證轉發給IDC中伺服器的為解封後的資料包，使得後端伺服器對于VPC無感覺。當後端伺服器回包到達CLOUD-DPVS後，再由CLOUD-DPVS封裝好VXLAN頭部并轉發給VPC。
4 CLOUD-DPVS後續工作
目前CLOUD-DPVS打通了VPC到IDC的路徑，後續将繼續實作IDC到VPC的打通。目前VXLAN子產品是在轉發層軟體實作，下一步會計劃使用智能網卡實作OFFLOAD相關工作。
5 參考文章
1. https://github.com/iqiyi/dpvs
2. https://yq.aliyun.com/articles/497058
3. https://tools.ietf.org/html/rfc5880#section-6.8.5