《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 provisioning3 个Controllers (OpenStack and OVN control plane services)9 个Compute Nodes (Hypervisors)硬件规格如下:
2x E5-2620 v2 (12 total cores,24 total threads)64GB RAM4 x 1TB SATA1 x Intel X520 Dual Port 10G软件:
CentOS 7.2OpenStack,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 upCreate 500 VMs,16 at a time,32 at a time,and then clean upRun 2 Create 500 VMs,and then clean upRun 3 Create 500 VMs,and then clean up总共会创立4500 个虚拟机.
测试成果
browbeat 能够存储 rally 生成的测试成果.这些测试成果可以用elastic 进行查询,用Kibana显示在网页上.
接下来的几个表格分离展示 average times,95th percentile,Maximum,和 minimum times 下的 API执行性能
译者注:百分比响应光阴是比平均响应光阴更好的性能指标.
因为在数理统计学上,早就有数学家用理论证明平均值是一个非常弗成信的数据.
好比稍微几个远离置信区间的数值就可以严重影响到平均值
译者注:average是指并行度为8、16、32的场景下完成测试所需光阴的平均值
API | ML2+OVS Average | OVN Average | % improvement |
nova.boot_server | 80.672 | 23.45 | 70.93% |
neutron.List_ports | 6.296 | 6.478 | -2.89% |
neutron.List_subnets | 5.129 | 3.826 | 25.40% |
neutron.add_interface_router | 4.156 | 3.509 | 15.57% |
neutron.List_routers | 4.292 | 3.089 | 28.03% |
neutron.List_networks | 2.596 | 2.628 | -1.23% |
neutron.List_security_groups | 2.518 | 2.518 | 0.00% |
neutron.remove_interface_router | 3.679 | 2.353 | 36.04% |
neutron.create_port | 2.096 | 2.136 | -1.91% |
neutron.create_subnet | 1.775 | 1.543 | 13.07% |
neutron.delete_port | 1.592 | 1.517 | 4.71% |
neutron.create_security_group | 1.287 | 1.372 | -6.60% |
neutron.create_network | 1.352 | 1.285 | 4.96% |
neutron.create_router | 1.181 | 0.845 | 28.45% |
neutron.delete_security_group | 0.763 | 0.793 | -3.93% |
译者注:95%指4500个测试成果按从小到大排列,选择第4275个的数据(4500*0.95=4275)
API | ML2+OVS 95% | OVN 95% | % improvement |
nova.boot_server | 163.2 | 35.336 | 78.35% |
neutron.List_ports | 11.038 | 11.401 | -3.29% |
neutron.List_subnets | 10.064 | 6.886 | 31.58% |
neutron.add_interface_router | 7.908 | 6.367 | 19.49% |
neutron.List_routers | 8.374 | 5.321 | 36.46% |
neutron.List_networks | 5.343 | 5.171 | 3.22% |
neutron.List_security_groups | 5.648 | 5.556 | 1.63% |
neutron.remove_interface_router | 6.917 | 4.078 | 41.04% |
neutron.create_port | 5.521 | 4.968 | 10.02% |
neutron.create_subnet | 4.041 | 3.091 | 23.51% |
neutron.delete_port | 2.865 | 2.598 | 9.32% |
neutron.create_security_group | 3.245 | 3.547 | -9.31% |
neutron.create_network | 3.089 | 2.917 | 5.57% |
neutron.create_router | 2.893 | 1.92 | 33.63% |
neutron.delete_security_group | 1.776 | 1.72 | 3.15% |
译者注:Maximum是指并行度为32的场景下完成测试所需光阴
API | ML2+OVS Maximum | OVN Maximum | % improvement |
nova.boot_server | 221.877 | 47.827 | 78.44% |
neutron.List_ports | 29.233 | 32.279 | -10.42% |
neutron.List_subnets | 35.996 | 17.54 | 51.27% |
neutron.add_interface_router | 29.591 | 22.951 | 22.44% |
neutron.List_routers | 19.332 | 13.975 | 27.71% |
neutron.List_networks | 12.516 | 13.765 | -9.98% |
neutron.List_security_groups | 14.577 | 13.092 | 10.19% |
neutron.remove_interface_router | 35.546 | 9.391 | 73.58% |
neutron.create_port | 53.663 | 40.059 | 25.35% |
neutron.create_subnet | 46.058 | 26.472 | 42.52% |
neutron.delete_port | 5.121 | 5.149 | -0.55% |
neutron.create_security_group | 14.243 | 13.206 | 7.28% |
neutron.create_network | 32.804 | 32.566 | 0.73% |
neutron.create_router | 14.594 | 6.452 | 55.79% |
neutron.delete_security_group | 4.249 | 3.746 | 11.84% |
译者注:Minimum是指并行度为8的场景下完成测试所需光阴
API | ML2+OVS Minimum | OVN Minimum | % improvement |
nova.boot_server | 18.665 | 3.761 | 79.85% |
neutron.List_ports | 0.195 | 0.22 | -12.82% |
neutron.List_subnets | 0.252 | 0.187 | 25.79% |
neutron.add_interface_router | 1.698 | 1.556 | 8.36% |
neutron.List_routers | 0.185 | 0.147 | 20.54% |
neutron.List_networks | 0.21 | 0.174 | 17.14% |
neutron.List_security_groups | 0.132 | 0.184 | -39.39% |
neutron.remove_interface_router | 1.557 | 1.057 | 32.11% |
neutron.create_port | 0.58 | 0.614 | -5.86% |
neutron.create_subnet | 0.42 | 0.416 | 0.95% |
neutron.delete_port | 0.464 | 0.46 | 0.86% |
neutron.create_security_group | 0.081 | 0.094 | -16.05% |
neutron.create_network | 0.113 | 0.179 | -58.41% |
neutron.create_router | 0.077 | 0.053 | 31.17% |
neutron.delete_security_group | 0.092 | 0.104 | -13.04% |
从上述表格中可以看到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)》。
总结以上是内存溢出为你收集整理的LINUX教学:性能测试之OVN vs (ML2+OVS)全部内容,希望文章能够帮你解决LINUX教学:性能测试之OVN vs (ML2+OVS)所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)