服务器评测
我们已经对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的场景下完成测试所需时间的平均值
|
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)在提供网络功能的过程中，到底在哪里花费了大部分的时间。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-06/144766.htm
