《LINUX教學:性能測試之OVN vs (ML2+OVS)》要點：
本文介紹了LINUX教學:性能測試之OVN vs (ML2+OVS)，希望對您有用。如果有疑問，可以聯系我們。

我們已經對OVN做了許多次的性能測試,但是缺少一個OVN和(ML2+OVS)的性能對比測試.我和許多人一起對比了這2種后端.本文是第一部分：控制平面的性能對比. 后面會另外發文頒布數據平面的性能對比結果.

控制平面的分歧之處

ML2+OVS 控制平面是基于Openstack 的.首先有大量由Python編寫的agents . Neutron server與這些agents交互式使用基于AMQP的RPC機制(本文的案例用到了最廣泛使用的RabbitMQ).

OVN 的控制平面使用了分布式數據庫驅動的方式. 配置和狀態由這2個數據庫管理: OVN northbound 和 southbound databases.這2個數據庫都基于OVSDB.與通過RPC接收更新的方式不同, OVN中的組件監控數據庫中相關表項的變化并將最新的表項應用于當地.這些組件的詳細信息可以閱讀the first release of OVN 和 ovn-architecture document .

OVN 沒有使用任何的Neutron agents.相反,所有功能都由ovn-controller 和 OVS 流實現.好比security groups, DHCP, L3 routing和 NAT功能等.

測試環境使用的硬件和軟件

本次測試使用了實驗室的13臺機器,并分派下面的這幾種角色:

• 1 個OpenStack TripleO Undercloud for provisioning
• 3 個Controllers (OpenStack and OVN control plane services)
• 9 個Compute Nodes (Hypervisors)

硬件規格如下:

• 2x E5-2620 v2 (12 total cores, 24 total threads)
• 64GB RAM
• 4 x 1TB SATA
• 1 x Intel X520 Dual Port 10G

軟件:

• CentOS 7.2
• OpenStack, OVS, and OVN from their master branches (early December, 2016)
• Neutron?configuration notes
  • (OVN) 6 API workers, 1 RPC worker (since rpc is not used and neutron requires at least 1) for neutron-server on each controller (x3)
  • (ML2+OVS) 6 API workers, 6 RPC workers for neutron-server on each controller (x3)
  • (ML2+OVS) DVR was enabled

配置和測試

性能測試工具為 OpenStack Rally . 我們使用 Browbeat 進行快速的安裝、配置、運行測試、存儲闡發和結果對比.

?Browbeat 中的Rally參數為:

rerun: 3
...
rally:
? enabled: true
? sleep_before: 5
? sleep_after: 5
? venv: /home/stack/rally-venv/bin/activate
? plugins:
? ? - netcreate-boot: rally/rally-plugins/netcreate-boot
? ? - subnet-router-create: rally/rally-plugins/subnet-router-create
? ? - neutron-securitygroup-port: rally/rally-plugins/neutron-securitygroup-port
? benchmarks:
? ? - name: neutron
? ? ? enabled: true
? ? ? concurrency:
? ? ? ? - 8
? ? ? ? - 16
? ? ? ? - 32
? ? ? times: 500
? ? ? scenarios:
? ? ? ? - name: create-list-network
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/neutron/neutron-create-list-network-cc.yml
? ? ? ? - name: create-list-port
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/neutron/neutron-create-list-port-cc.yml
? ? ? ? - name: create-list-router
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/neutron/neutron-create-list-router-cc.yml
? ? ? ? - name: create-list-security-group
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/neutron/neutron-create-list-security-group-cc.yml
? ? ? ? - name: create-list-subnet
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/neutron/neutron-create-list-subnet-cc.yml
? ? - name: plugins
? ? ? enabled: true
? ? ? concurrency:
? ? ? ? - 8
? ? ? ? - 16
? ? ? ? - 32
? ? ? times: 500
? ? ? scenarios:
? ? ? ? - name: netcreate-boot
? ? ? ? ? enabled: true
? ? ? ? ? image_name: cirros
? ? ? ? ? flavor_name: m1.xtiny
? ? ? ? ? file: rally/rally-plugins/netcreate-boot/netcreate_boot.yml
? ? ? ? - name: subnet-router-create
? ? ? ? ? enabled: true
? ? ? ? ? num_networks:? 10
? ? ? ? ? file: rally/rally-plugins/subnet-router-create/subnet-router-create.yml
? ? ? ? - name: neutron-securitygroup-port
? ? ? ? ? enabled: true
? ? ? ? ? file: rally/rally-plugins/neutron-securitygroup-port/neutron-securitygroup-port.yml

上述配置定義了幾種運行場景.在3個分歧的并行級別下,分別運行500次.最后,開頭的"rerun: 3"意味著我們要將整個配置再運行3遍.是不是被繞暈啦, 那我們拿個例子看一下 ：

"netcreate-boot" 場景是創立一個網絡,并在這個網絡上啟動一個虛擬機.這個場景會按下面這樣多次執行:

• Run 1
  • Create 500 VMs, each on their own network, 8 at a time, and then clean up
  • Create 500 VMs, each on their own network, 16 at a time, and then clean up
  • Create 500 VMs, each on their own network, 32 at a time, and then clean up
• Run 2
  • Create 500 VMs, each on their own network, 8 at a time, and then clean up
  • Create 500 VMs, each on their own network, 16 at a time, and then clean up
  • Create 500 VMs, each on their own network, 32 at a time, and then clean up
• Run 3
  • Create 500 VMs, each on their own network, 8 at a time, and then clean up
  • Create 500 VMs, each on their own network, 16 at a time, and then clean up
  • Create 500 VMs, each on their own network, 32 at a time, and then clean up

總共會創立4500 個虛擬機.

?

測試成果

Browbeat 能夠存儲 rally 生成的測試成果.這些測試成果可以用elastic 進行查詢,用Kibana顯示在網頁上.

接下來的幾個表格分離展示 average times, 95th percentile, Maximum, 和 minimum times 下的 API執行性能

譯者注：百分比響應光陰是比平均響應光陰更好的性能指標.

因為在數理統計學上,早就有數學家用理論證明平均值是一個非常弗成信的數據.

好比稍微幾個遠離置信區間的數值就可以嚴重影響到平均值

?

譯者注：average是指并行度為8、16、32的場景下完成測試所需光陰的平均值

?

譯者注：95%指4500個測試成果按從小到大排列,選擇第4275個的數據(4500*0.95=4275)

?

譯者注：Maximum是指并行度為32的場景下完成測試所需光陰

?

譯者注：Minimum是指并行度為8的場景下完成測試所需光陰

分析

從上述表格中可以看到OVN對性能提升最猛的便是"nova.boot_server".這是測試不只是衡量從Neutron加載配置所花時間,同時也衡量了提供網絡功能所花的時間.(譯者注：這個"server"其實便是虛擬機)

當Nova 啟動一個虛擬機時,得先等待Neutron發出的端口可用變亂.收到這個變亂后,虛擬機才會被啟動,啟動完成時變為ACTIVE狀態.ML2+OVS 和OVN 都使用這個機制.我們的測試場景測量了虛擬機變為ACTIVE狀態所花時間.

在未來的測試中,我們將把這個Nova和Neutron間的同步機制關閉,再來比較ML2+OVS 和OVN的測試結果.這將確認等待Neutron申報端口可用的過程中花費了額外的時間.

我要說明一點,你不應該關閉這個同步機制.關閉這個機制的唯一原因為：不是所有的Neutron后端都支持該同步機制(ML2+OVS and OVN都支持這個同步機制 ).實施同步機制后,就能避免出現競爭狀態.同時也保證在啟動虛擬機之前,網絡便是可用的.這個問題便是花費多長時間能讓Neutron提供可用的網絡. 未來將分析Neutron (ML2+OVS)在提供網絡功能的過程中,到底在哪里花費了大部分的時間.?

本文永遠更新鏈接地址：

學習更多LINUX教程，請查看站內專欄，如果有LINUX疑問，可以加QQ交流《LINUX教學:性能測試之OVN vs (ML2+OVS)》。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/12073.html