一、背景介紹
在集中式網絡節點模式下，所有的計算節點只安裝二層代理，所有的三層流量無論是東西或者南北走向都必須經過網絡節點，盡管可以通過HA的方式保證網絡節點的高可用，但是基於vrrp的HA方式在同一時間點只有一個網絡節點處於工作狀態，這樣在大規模場景下網絡節點仍然會成為性能瓶頸，因此OpenStack社區從Juno版本開始推出的DVR模式來解決上述問題，需要說明的是：Mitaka版本之前DVR和L3 HA功能不能同時啟用，從Mitaka版本之后才支持DVR和L3 HA功能同時開啟
二、DVR模式介紹
為了解決網絡節點的流量瓶頸問題，DVR通過在計算節點部署L3 Agent，讓不同subnet之間的東西流量和綁定floating ip的vm的南北流量直接通過計算節點訪問外網，只有未綁定floating ip的vm的南北流量才需要通過網絡節點SNAT訪問外網，此時的集群架構如下圖所示
不同於集中式網絡節點中所有計算節點直走二層流量，DVR模式下，每個計算節點都可以走三層流量，以此來分攤網絡節點的流量壓力
三、網絡、計算節點的內部組件
1.網絡節點
DVR模式下，網絡節點內部組件如下圖所示
可以看到，啟用DVR模式后的網絡節點多了一個SNAT Namespace空間，在所有計算節點都開啟DVR功能時，Router Namespace中的Metadata Agent只負責處理Project網絡中的元數據，SNAT Namespace空間負責對只有fix ip的vm通過源地址轉換的方式訪問外網，如果所有的計算節點將DVR模式關閉，此時vm的流量和集中式網絡節點一致，即所有的三層流量都需經過網絡節點的Router Namespace處理
2.計算節點
當開啟DVR功能后，此時計算節點內部組件如下圖所示
啟用DVR功能的計算節點因為部署了L3 Agent組件，所以擁有Distribute Router NameSpace，並且當創建vm時，還會自動生成fip名稱空間，所有計算節點的Distribute Router NameSpace完全一致，名稱空間接口的ip和mac地址也一樣（初始化時所有計算節點的名稱空間都是源自網絡節點的副本），了解網絡的都知道，同一時間同一網絡中ip和mac地址要一致，否則交換通過反復mac地址學習到的arp表條目會有沖突，為了解決這一問題，DVR結構為每個運行L3 Agent的計算節點指定全局唯一的mac地址（dvr_host_mac）
四、vm的東西流量分析
1.相同subnet間通信
相同subnet之間通信不需要借助L3 Agent，vm之間的流量如下圖所示
1.vm1向vm2發起請求，通過目的IP地址得知vm2和自己在同一網段
2.數據包經過linux bridge，進行安全策略檢查，進入br-int打上內部vlan號
3.數據包脫掉br-int的內部vlan號進入br-tun/bt-vlan
4.進入br-tun的數據包此時vxlan封裝並打上vni號，進入br-vlan的數據包此時打上外部vlan號，通過nic離開compute1
5.數據包進入compute2，經過bt-tun的數據包完成vxlan的解封裝去掉vni號，經過br-vlan的數據包去掉vlan號
6.數據包進入br-int，此時會被打上內部vlan號
7.數據包離開br-int並去掉內部vlan號，送往linux bridge通過其上的iptables安全策略檢查
8.最后數據包到達vm2
2.不同subnet間通信
1.位於compute1中的vm1向compute2中的vm2發出請求，此時源/目的ip為vm1/2的ip地址，源/目的mac地址為vm1與網關qr-1的mac地址
2.報文經過linux bridge進行iptables安全檢查，然后送往br-int
3.進入br-int上的報文被打上內部vlan號並送往vm1的網關qr-1，qr-1接口上配置vm1的網關地址，經查表報文從qr-2口流出，qr-2接口設置vm2的網關地址
4.從qr-2口出來的報文，此時源/目的ip為vm2網關（qr-2）的ip和vm2的ip地址，源/目的mac為qr-2口和mac和vm2的mac地址，並將報文進入br-tun
5.報文在br-tun交換機上將源mac地址（qr-2）替換為全局唯一mac地址（dvr_host_mac），然后進行vxlan封裝，離開compute1
6.報文到達compute2后首先vxlan解封裝，然后再將源mac地址（dvr_host_mac）換位vm2網關（qr-2）mac地址，送往br-int並在br-int交換機打上內部vlan號
7.報文脫掉內部vlan號，進入linux bridge，進行安全策略檢查
8.最終數據包到達vm2
五、vm的南北流量分析
vm南北流量分為floating ip和fix ip兩種情況，對這兩種情況分別進行說明
1.fix ip訪問外網
沒有綁定floating ip的vm在訪問外網時需要通過網絡節點的SNAT Router NameSpace進行地址轉換，其流量走向如下圖所示
1.vm向外網發起請求，數據包送往linux bridge
2.進入linux bridge的數據包經過iptables安全策略檢查后將數據包送往br-int，此時打上內部vlan號
3.數據報文從br-int送往Router NameSpace的qr口，該接口配置了vm的網關地址，在Router NameSpace內對SNAT NameSpace的sg口的mac地址進行解析，sg接口為vm所在子網的接口，該接口上的ip地址與vm在同一網段，然后將包送往br-tun
4.數據包進入br-tun后脫掉內部vlan號，進行vxlan封裝，打上vni號，離開compute1
5.數據包進入網絡節點，脫掉vni號，進行vxlan解封裝，送往br-int交換機，進入br-int交換機后打上內部vlan號
6.數據包進入sg后，進行路由查表，將數據發往fg口，fg口上配置的是可被路由公網ip
7.數據包在fg口上進行SNAT地址轉換，轉換后的源ip地址為fg口上配置的公網ip訪問公網
2.floating ip訪問外網
啟用DVR功能后，每台計算節點主機都安裝了L3 Agent，綁定了floating ip的vm不再需要繞行到網絡節點，直接由計算節點主機訪問公網，其流量走向如下圖所示
1.vm向外網發起訪問，由於vm是provider類型的私網地址，所以首先要去找vm地址所在的網關
2.數據包經過linux bridge和br-int后進入Distribute NameSpace的qr口，該接口配置的ip地址為vm的網關地址
3.數據包從qr口流出，進入rfp口，該接口上配置有2個ip地址，其中3為vm綁定floating ip地址，在此處進行SNAT地址轉換，外網流量訪問vm時在此名稱空間利用iptables做DNAT地址轉換
4.通過qrouter與fip內部通信的直連接口（4），接口地址由L3 Agent自行維護，ip為169.254.x.x/31格式，將數據包發往fip名稱空間
5.fip空間的直連接口fpr接收到數據包后，轉發給外網網關fg口
6.fip名稱空間外網網關接口將數據包發到br-ex交換機最后通過物理網卡訪問Internet，外網訪問vm的數據流向為該過程的反方向，不在贅述
3.注意事項
針對使用floating ip的數據包進出時需要注意的地方是
1.fg接口上會額外配置一個外網ip地址，這也是為什么公有雲場景下不會講vm外網ip直接設置成公網ip地址的原因，因為每個vm都需要一個額外的地址作為fg網關地址
2.當外部網絡訪問vm時，請求的ip地址是qrouter名稱空間中rfp接口上做SNAT的ip地址，但此時fg接口會響應rfp接口上外網的arp地址解析請求，所以通常認為fg接口時floating ip的arp代理接口
六、網絡節點HA
通過前文得知，開啟DVR模式下的網絡節點只是針對沒有綁定floating ip的vm進行SNAT地址轉換，並且qrouter名稱空間只處理元數據，所以不同於傳統L3 HA對Router NameSpace的高可用，DVR下的L3 HA是對SNAT NameSpace進行的高可用，仍采用vrrp實現，如下如所示
從部署結構來看，分別要對SNAT外網ip地址和子網接口ip地址做高可用，所以當使用keepalived時，此時架構如下圖所示
鏈接：https://blog.51cto.com/arkling/2409789