技術分享：OpenStack DVR部署與分析
為了提高neutron網絡服務的魯棒性與性能，OpenStack從J版開始正式加入的DVR(Distributed Virtual Router)服務，它將原本集中在網絡節點的部分服務分散到了計算節點上。
在該模式下，同租戶的跨網段路由在計算節點之間直接完成，無需網絡節點的參與。SNAT服務仍有網絡節點集中化的處理。Floating服務則可以選擇在計算節點分布式地處理，也可以選擇在網絡節點中心化的處理。
DVR在帶來網絡服務魯棒性與性能提升的同時，也帶來了一些缺陷。東西向的FWAAS服務變得無法實現，具體參考“鏈接”。簡單來說就是FWAAS功能依賴於在同命名空間的vrouter下看到雙向（有狀態）的進出兩條流。現在部署DVR功能後的東西向通信，打破了這條規則。下面將對OpenStack Queens版本的 DVR部署進行闡述分析。
部署
準備
已經部署好的基於租戶網絡是vxlan的OpenStack環境
控制節點配置
文件：neutron.conf
router_distributed = true
重啟服務
systemctl restart neutron-server.service
網絡節點配置
文件：openvswitch_agent.ini
l2_population=true
enable_distributed_routing = true
文件：l3_agent.ini
agent_mode =dvr_snat
external_network_bridge 留空
重啟服務
systemctl restart openvswitch.service
systemctl restart neutron-l3-agent.service
systemctl restart neutron-dhcp-agent.service
systemctl restart neutron-metadata-agent.service
計算節點配置
安裝neutron相關服務
yum install openstack-neutron
修改內核配置
echo ‘
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.bridge.bridge-nf-call-ip6tables=1
‘>>/etc/sysctl.conf
sysctl -p
修改配置dhcp_agent.ini,l3_agent.ini,metadata_agent.ini這3個文件。
文件：openvswitch_agent.ini
l2_population=true
enable_distributed_routing = true
文件：l3_agent.ini
agent_mode =dvr
external_network_bridge 留空
添加對外網橋，eth_TBD,IP_TBD要根據實際環境而定
echo ‘#
ovs-vsctl add-br br-ex
ovs-vsctl add-port br-ex eth_TBD
ovs-vsctl show
ifconfig eth_TBD 0.0.0.0
ifconfig br-ex IP_TBD/24
#‘>>/etc/rc.local
chmod +x /etc/rc.d/rc.local ; tail -n 8 /etc/rc.local |bash
重啟服務
systemctl restart openvswitch.service
systemctl restart neutron-openvswitch-agent.service
systemctl restart neutron-l3-agent.service
systemctl restart neutron-dhcp-agent.service
systemctl restart neutron-metadata-agent.service
驗證操作
在控制節點上查看network agent。
實驗分析
部署虛機與網絡
總覽
本著“無圖無真相””一圖勝千言”的原則，在接下來的分析中爭取多放圖，少廢話。
在部署好DVR，虛機，網絡後，整個系統的網絡組成及各節點上的功能分布如下圖所示。
同節點東西向
跨節點東西向
從上表中我們可以直觀的看到跨節點的路由通信過程。原理與傳統路由功能基本一致。唯一的區別在進入VXLAN隧道前把原本網關MAC替換成DVR_HOST_MAC,在出VXLAN隧道後又把DVR_HOST_MAC換回網關MAC。具體原理我們將在“如何解決各節點上DVR的沖突”這一小節給出解釋。
進入qrouter這個命名空間就使用linux的高級路由功能來完成路由過程。（引用《深入理解openstack neutron》中一句話：“Linux創建router並沒有像創建虛機bridge那樣，有一個直接的命令brctl，而且它間接命令也沒有，不能創建虛擬路由器……因為它就是路由器（router）”）。在compute-1計算節點上我們可以觀察到如下圖所示信息。不同網段該從哪個qr口出去，不同neighbor的IP,MAC的對應關系都是有neutron事先設置好的。
NAT
這裏遇到了和上一小節同樣的問題。具體原理我們將在“如何解決各節點上DVR的沖突”這一小節給出解釋。
FloatingIP
如何解決各節點上DVR的沖突
在各節點上的vrouter其qr口的IP,MAC都是圖中各network：router_interface_distributed Port的IP,MAC.在這種情況下，各節點中的VM是如何正確的找到同宿主機下正確的vrouter及正確的網關的呢？
讓我們看一下br-tun上的部分流表
從圖中可知，br-int中進入br-tun中的所有流量都會經過table 1的篩選過濾。註意流表項5、6、7、8的匹配項。這4條流表把所有查詢網關MAC的ARP廣播報文丟棄，把所有目的MAC是網關MAC的未知單播報文都丟棄。這裏就確保了一個宿主機內的VM只能感知到本宿主機內的vrouter，或者認為一些數據包是同宿主機內的vrouter給其轉送數據包。
但是經過上面描述的處理後，那麽三層轉發報文又如何能到達其他節點呢？這裏我們看一段社區給出的說明。
在初始化期間，OVS agent需要知道其持有的唯一的DVR MAC地址，以此在br-tun，br-int中輸入正確的流表項。出於這個目的，L2 agent通過RPC的方式調用ML2 plugin中的get_dvr_mac_address(host_id)函數。
讓我們去控制節點看看這個dvr_mac_address又是什麽。在Tables_in_neutron中找到一張名為dvr_host_macs的表，查詢其中的內容我們是不是又發現了熟悉的MAC。這些都是neutron分配的，全局唯一的，與各節點一一對應的MAC地址。如果有心的話在配置控制節點的neutron.conf文件時，可以看到有個名為”dvr_base_mac”配置項，該項可以自定義DVR MAC的前綴高位。
所有跨界點的三層通信，在出節點前都會把源MAC是網關MAC的報文，把源MAC都替換成各節點都唯一的DVR host MAC。這裏也就解釋了上面跨節點東西向和NAT中遺留的問題了。
總結
從實質上講，neutron的DVR模式並沒有使用任何顛覆性的技術手段。可以說也就是把原有的VRouter給Distribute了。至於生產環境中是否需要采用DVR功能，可能這也是網絡性能，魯棒性與網絡可維護性，是否需要東西向FWAAS之間的博弈。
技術分享：OpenStack DVR部署與分析