OpenStack性能测试工具Rally实践和分析
1Rally介绍
Rally是OpenStack社区推出开源测试工具，可用于对OpenStack各个进行性能测试。通过使用Rally组件，用户可完成OpenStack云计算平台的安装部署、功能验证、大规模负载测试(性能测试)、输出测试报告等一系列动作。对于我们环境中性能测试来说，由于我们的网络平台和Neutron的API接口基本一致，所以可以直接拿来测试我们的网络平台。
以下为官方网站上面的图片，展示了Rally强大的功能：
1.2应用场景
对于不同的使用场景，Rally在测试中的流程也有所不同，主要支持以下三种场景：
1) 开发测试，可以评估处于开发阶段的OpenStack系统的性能，能够完成安装部署、仿真测试并输出测试结果等一系列动作;
2) 开发运维测试，可以基于现有的OpenStack云平台，对已经安装部署的云平台进行仿真测试并输出测试结果;
3) CI/CD场景测试，可以将Rally集成到CI/CD系统。
以下为三种主要场景的使用流程：
Rally内部架构如下：
2Rally安装
2.1自动化安装
有多种方式安装Rally组件，如下是官方推荐的3种方法，这三种方法都要求你的安装环境能够访问Internet(如果很不幸，你的环境不能访问外网，请查看下2.2小节)：
1.自动化独立安装
这个是全自动化，省事省力，如下命令即可搞定，如果是缺少什么软件，会自动下载安装。
wget -q -O-/openstack/rally/master/install_rally.sh |bash
# or using curl
curl/openstack/rally/master/install_rally.sh |bash
安装完成后，执行以下命令构建rally：
rally-manage db recreate
2.和DevStack allinone一起安装
git clonehttps://git.openstack.org/openstack-dev/devstack
git clone/openstack/rally
cd devstack
cp samples/local.conflocal.conf
编辑local.conf文件，在[[local|localrc]]段里面新增如下行：
enable_pluginrally/openstack/rallymaster
之后执行：
./stack.sh
3.使用Docker方式安装
docker build -t myrally .
sudo mkdir/var/lib/rally_container
sudo chown 65500 /var/lib/rally_container
docker run -it -v/var/lib/rally_container:/home/rally rallyforge/rally
如有疑问，可查阅官方安装文档：
https://rally.readthedocs.io/en/latest/install.html
如果安装环境不能访问外网环境，那么只能采用手工方式进行源码安装了，这种方式费时费力，经常会遇到莫名其名的坑，但是一步步排雷下来，相信会对系统有更深的理解。以下是源码安装过程：
1.首先下载一份Rally源码(我用的是Rally-0.4.0),将源码拷贝到安装机器上面;
2.修改pbr/packaging.py文件(等安装完成后再修改回来)
vim/usr/lib/python2.7/site-packages/pbr/packaging.py
在get_version函数中新增如下代码(红色字体)：
if version:
return version
return '0.4.0' #我使用了rally的0.4.0版本
raise Exception(&Versioning for thisproject requires either an sdist&
& tarball, or accessto an upstream git repository.&
& Are you sure thatgit is installed?&)
3.安装sphinx软件(可使用yum內源方式安装或者rpm安装)
yum install *sphinx
yum install subunit*
4.进入rally源码目录，可看到里面有setup.py文件，执行如下命令：
cd rally-0.4.0/
python setup.py install
5.为rally新建my
-u root -proot -e&CREATE　DATABASE&
mysql -u root -proot -e&GRANT ALL PRIVILEGES ON rally.* TO 'rally'@'localhost' IDENTIFIED BY'rally';&
mysql -u root -proot -e&GRANT ALL PRIVILEGES ON rally.* TO 'rally'@'%' IDENTIFIED BY'rally';&
6.为rally生成alembic
cd /usr/lib/python2.7/site-packages/rally/common/db/sqlalchemy
alembic init alembic
vim alembic.ini #编辑配置文件，修改如下行：
sqlalchemy.url =mysql://rally:rally@localhost/rally
7.修改rally的配置文件，添加数据库访问路径
vim /etc/rally/rally.conf
[database]
connection =mysql://rally:rally@10.25.49.2/rally
8.初始化rally数据库
rally-manage db recreate
9.验证rally命令是否调用成功，可以发现安装的版本是0.4.0
[root@control home]# rally--version
No handlers could be foundfor logger &oslo_config.cfg&
3Rally使用
下面介绍常用的Rally命令。
3.1创建Deployment
如果要测试已存在的OpenStack系统，则在创建deployment直接导入环境变量即可，如果测试的OpenStack不存在，需要在创建Deployment时安装部署一套openstack，这需要配置deployment engine。我是对已经安装好的NSP进行测试，因此没有配置deployment engine.
对于已经安装部署了OpenStack系统，有两种方式创建deployment：
1) 使用环境变量创建
rally deployment create --fromenv--name=existing
环境变量中需要存在如下变量：
OS_USERNAME
OS_PASSWORD
OS_AUTH_URL
OS_TENANT_NAME
OS_ENDPOINT
OS_REGION_NAME
OS_INSECURE
其实执行openstack各个组件都需要环境变量，如果能够执行nova/neutron等命令没有错误说明已经包含了要求的环境变量，如果执行失败，需要导入你自己的环境变量，以下是我的环境变量文件：
[root@control home]# cat /root/admin-openrc.sh
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=****
export OS_AUTH_URL=http://10.25.*.*:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2
执行. /root/admin-openrc.sh就可以将环境变量导入。
2) 使用json文件创建
rally deployment create--file=existing.json --name=existing
existing.json文件内容如下：
&type&:&ExistingCloud&,
&auth_url&: &http://10.25.*.*:35357/v3&,
&region_name&:&RegionOne&,
&endpoint_type&:&public&,
&admin&: {
&username&:&admin&,
&password&: &****&,
&tenant_name&: &admin&
&users&: [
&username&: &nsp_test_1&,
&password&:&password&,
&tenant_name&:&nsp_tenant_1&
&username&:&nsp_test_2&,
&password&:&password2&,
&tenant_name&:&nsp_tenant_2&
3.2检查deployment
可检查创建的deployment各项服务是否正常，以下是执行结果
[root@controlrally_test]# rally deployment check existing
查看所有的deployment列表
[root@controlrally_test]# rally deployment list
查看已创建的deployment的详情
[root@controlrally_test]# rally deployment show existing
当存在多个deployment时，可以使用命令查看当前active的deployment，并切换deployment,如下：
[root@control rally_test]# rally deploymentuse 25ee44af--8ec9-ac9c2fbb94bb
3.3执行Task
Task是Rally执行的一个测试单元，执行Task时需要指定入口文件，可以是json文件或者yaml文件，如下可执行一个task：
[root@control rally_test]# rally taskstartnsp_test/yaml_files/network/create.yaml
其中create.yaml内容如下：
[root@control rally_test]# catnsp_test/yaml_files/network/create.yaml
NSPNetworks.create_and_list_networks:
network_create_args: {}
network_vlan_start:600
type:&constant&
concurrency: 10
context:{}
NSPNetworks是新增的针对NSP性能测试的类，create_and_list_networks是该类的一个函数，args是函数需要的参数，runner中定义了运行过程参数，context定义了使用的用户数、租户数等信息，这个例子context为空，这是因为使用了预先定义好的用户和租户。
如下的例子展示了context不为空的情况，这个时候用户和租户都是在测试过程中Rally临时创建的，等测试结束后会自动删除。
NSPNetworks.create_and_delete_networks:
network_create_args: {}
network_vlan_start: 600
type: &constant&
concurrency: 3
tenants: 1
users_per_tenant: 1
network: -1
上面这些例子是针对NSP定制的，引入了network_vlan_start参数，初学者也可参考原生的rallytask实例，位于rally安装包中(路径：rally-0.4.0/samples/tasks/scenarios/)。
Task执行完成后，会打印出执行结果信息，如下：
3.4查看Task
可使用rally tasklist [task_id]，来列出已经执行的task：
可以指定task id进行查看执行的结果：
[root@controlrally_test]# rally task results93aa3f32-7c70--ea
3.5生成Web测试报告
使用rally task report[task_id] --out=[outfile.html]可以生成web格式的测试报告，如下：
[root@controlhtml_report]# rally task report93aa3f32-7c70--ea --out=report.html
上面的命令执行成功，可以看到生成的Html文件，在中可查看Html文件。展示效果如下：
查看web报告问题错误排查：
在查看测试报告文件时，遇到了一个奇怪的现象，我发现在公司电脑上面打不开report.html文件，但是在另外一个同事Mac电脑上面却可以正常打开。后来我在家里用个人电脑上查看report.html文件，发现当打开翻墙功能就可以查看，但是关闭翻墙功能就不能正常查看。于是查看html源代码，发现report.html文件中使用了一些css、js库，而这些库放在了google网站上，因此才会出现这么奇怪的现象。
需要将report.html里面如下四行中的libs网址：
替换为可以访问的bootcss静态库的libs网址，如下：
之后就可以打开了。或者直接将report.html模板文件的对应行修改掉，这样生成的报告web页面都会自动替换。
模板文件位置：/usr/lib/python2.7/site-packages/rally/ui/templates/task/report.html
4. Rally测试的局限性
Rally测试数据主要是根据REST API的请求和响应时间进行统计时间，由于OpenStack的API是异步的，当API返回时，其请求的资源未必真正完成创建，因此Rally没有办法测试出资源从开始创建到最后创建完成整个流程需要的时间。而在我们的场景下，Rally也是只是测试NSP的API响应时间，无法测试出NSP给Service-engine下发消息的时间，也无法测试出Service-engine组件调用AC 接口创建相关网络资源的时间。
从改善用户体验角度来说，测试API的响应时间非常关键，科学研究表明，对于一个人机交互系统来说，用户等待时间 &4s而不给任何响应则会给人的体验非常差。从这个意义上来说，Rally的测试非常有必要，也很有价值。但是API返回结果，未必意味着用户的资源已经准备好，从整个流程的优化来看，还需要统计出Service-engine组件调用AC 接口创建相关网络资源的时间，这是下一步的工作。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'用Docker之后还需要OpenStack吗？ | UnitedStack有云
深度博文的激烈碰撞
有云博客沉淀了有云工程师们的智慧，碰撞着相互学习进步，感受不一样的有云文化，展示不一样的有云风采。
Solomon Hykes创立了Docker，没有想到过Docker会人气爆棚，成为仅次于OpenStack的最受欢迎的云开源项目。
然而听说过Docker的朋友很少知道其真正的意义，很多人会被各种概念混淆，甚至把OpenStack和Docker进行类比，三周前看到一篇好文章（虽然发此篇时间上已经优势全无，但依仗我们精准的理解，翻译和挑选眼光，还是决定无耻滴发了），答案可以在以下这篇Nati Shalom的博文中找到，在此感谢朱荣泽同学的技术翻译矫正。
（原文链接）
Docker从一个新兴的技术到一个商品化模式，这一过程的发展速度很惊人，它炙手可热的同时也给带来一些困惑。
笔者从一些刚开始用Docker的同学听到一些评论和疑问： 假如用了Docker再去用OpenStack是否合适？
讨论之前，先介绍Docker的相关背景：
简单来说，Docker提供了一种程序运行的容器，同时保证这些容器相互隔离。虚拟机也有类似的功能，但是它通过Hypervisor创建了一个完整的操作系统栈。不同于虚拟机的方式，Docker依赖于Linux自带的LXC(Linux Containers)技术。LXC利用了Linux可以对进程做内存、CPU、网络隔离的特性。Docker镜像不需要新启动一个操作系统，因此提供了一种轻量级的打包和运行程序的方式。而且Docker能够直接访问硬件，从而使它的I/O操作比虚拟机要快得多。Docker可以直接跑在物理服务器上，这引起大家的疑问：假如已经用了Docker，还有必要使用OpenStack吗？
最近Boden Russell在DockerCon上做了关于Docker和KVM的性能测试对比图表。和预期的一样，启动KVM和Docker容器的时间差异非常显著，而且在内存和CPU利用率上，双方差距非常大，如下表所示。
双方巨大的性能差异，导致了在相同工作负载下，KVM需要更多的CPU和内存资源，导致成本上升。
观点如下：
1，这个问题和OpenStack没有直接的联系，也可以套在其他云平台上。大家为什么会拿Docker和OpenStack做比较的原因是：OpenStack是私有云环境中最流行的云平台，在私有云环境中，大家认为可以把Docker作为另一种选择。
2，有关于Hypervisor的误区：
很多KVM和Docker的性能测试的对比跟OpenStack一点关系都没有，因为OpenStack只是一种框架。事实上这种性能测试(不管是KVM还是Docker)是跑在OpenStack下，这表明了KVM和Docker可以共存。当使用OpenStack去管理Docker情况下，Docker和OpenStack的争论是没有意义的。
3，云平台提供一个完整管理数据中心的解决方案，至于用哪种hypervisor或container只是云平台中的一个小部分。像OpenStack这样的云平台包含了多租户的安全、隔离、管理、监控、存储、网络等其他部分。云数据中心的管理需要很多服务支撑，但这和用Docker还是KVM其实没多大关系。
4，Docker不是一个全功能的VM, 它有很多严重的缺陷，比如安全、Windows支持，因此不能完全替代KVM。现在Docker社区一直在弥补这些缺陷，当然这会带来一定的性能损耗。
5，原生hypervisor的性能、容器化的性能、应用的性能是不一样的东西，相互对比没有意义。
6，把Docker容器打包进KVM镜像中对Docker运行几乎没有影响。这种架构通常是用hypervisor来管理计算资源，而像Heat、Cloudify、Kubernetes这样的的orchestration layer都用于管理在hypervisor中的docker容器。
正确看待OpenStack、KVM、Docker的方式应该是:
OpenStack用于管理整个数据中心，KVM和Docker作为相应的补充，KVM用于多租户的计算资源管理，Docker Container用于应用程序的打包部署。
在这种场景下，Docker的作用是：
1，Docker提供一种特定的软件打包方式，使得软件可以保持在相同的环境下运行。
2，Docker为微服务提供了很好的容器。
3，Docker在OpenStac、裸机上运行几乎一样。
总得来说，对于大部分的应用场景，使用那种云平台都可以。比如我要给一个DevOps小组提供自动化开发和测试环境，我会考虑直接在物理服务器上跑Docker。
Orchestration对于这两种环境(OpenStack和Docker)是很好的抽象工具。
使用Docker的Orchestration框架的好处是可以在任意时候在OpenStack和裸机环境中切换，也就是说你可以指定Docker跑在OpenStack或裸机环境中。OpenStack Orchestration工具Heat从Icehouse版本开始支持Docker。Cloudify是一个基于开源的Orchestration，它可以跑在openstack、VMwara、AWS、裸机环境中，最近也支持Docker。
我们将及时回复您
400-898-5401
北京市海淀区东北旺西路8号中关村软件广场4号楼C座101
Copyright (C) 2017
优思得云计算科技（北京）有限公司
Copyright (C)2017 优思得云计算科技（北京）有限公司 UnitedStack Inc. All Rights Reserved.}