性能测试之OVN vs (ML2+OVS)

发表于:2017-6-15 10:05

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:zhengmx100    来源:51Testing软件测试网采编

分享:
  我们已经对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)在提供网络功能的过程中,到底在哪里花费了大部分的时间。 
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号