目录
文章目录
问题描述
需求实现 Rally 扩展插件的缘起是因为希望通过 Rally 来自动化测试 Octavia 项目的稳定性以及评估大规模 LB 工作负载对自身云平台的性能影响，所以下述的内容主要记录了在 Rally（stable/0.12）Benchmark Engine/Task Framework 中实现 Octavia Plugin 的方式。
Rally 简介
OpenStack Rally 是一个自动化测试工具，社区希望通过 Rally 来解答 “How does OpenStack work at scale?（如何规模化运行 OpenStack）” 的问题。为了实现这一目的，Rally 被设计成集自动化部署、功能验证、性能测试和分析报告于一体，作为 OpenStack CI/CD 系统中的基础工具，帮助用户不断提高系统的 SLA（服务等级协议）、性能和稳定性。
简而言之，Rally 能够帮助用户完成整个 OpenStack 平台或者某个单一组件功能的压力测试，帮助用户验证和评估稳定系统工作负载的规模。
应用场景
应用案例
- 自动化测试、分析，评估新引入的代码如何影响云平台的性能；
- 自动化测试、分析新引入的代码是否完美兼容云平台功能清单；
- 评估不同的部署方式如何影响云平台的性能，以此得出性能峰值最高的云平台部署架构；
- 评估不同硬件设备对云平台的性能影响，以此得出性能峰值最高的云平台硬件设施；
更多案例，请浏览官方文档：https://docs.openstack.org/rally/latest/overview/overview.html#who-is-using-rally
Rally 安装
下载源码：
git clone https://github.com/openstack/rally.git
安装项目：
cd rally && ./install_rally.sh
NOTE：建议在沙盒环境安装
Rally 使用
本篇以自动化测试为例，使用 Rally 自动化完成云平台功能的压力测试。
Step 1. 创建 Deploy
这里我们使用 Existing Cloud，所以 deploy file 如下：
# vim ~/existing.json
{
"openstack": {
"auth_url": "http://172.18.22.222/identity",
"region_name": "RegionOne",
"endpoint_type": "public",
"admin": {
"username": "admin",
"password": "admin",
"tenant_name": "admin"
},
"https_insecure": false,
"https_cacert": ""
}
}
执行 deployment 执行进行创建及查看：
$ rally deployment create --filename=~/existing.json --name=existing
$ rally deployment list
+--------------------------------------+----------------------------+----------+------------------+--------+
| uuid | created_at | name | status | active |
+--------------------------------------+----------------------------+----------+------------------+--------+
| 97f7ccce-76dc-4af0-8583-f1a15be56c99 | 2018-10-25T03:22:11.399523 | existing | deploy->finished | * |
+--------------------------------------+----------------------------+----------+------------------+--------+
Existing Cloud deployment status 为 deploy->finished 则表示正常。
验证是否成功对接 OpenStack 云平台：
$ rally deployment check
--------------------------------------------------------------------------------
Platform openstack:
--------------------------------------------------------------------------------
Available services:
+-------------+----------------+-----------+
| Service | Service Type | Status |
+-------------+----------------+-----------+
| __unknown__ | block-storage | Available |
| __unknown__ | compute_legacy | Available |
| __unknown__ | placement | Available |
| __unknown__ | volumev2 | Available |
| __unknown__ | volumev3 | Available |
| cinder | volume | Available |
| glance | image | Available |
| keystone | identity | Available |
| neutron | network | Available |
| nova | compute | Available |
| octavia | load-balancer | Available |
+-------------+----------------+-----------+
打印 Available services 表示正常对接。
Step 2. 自动化执行 Task
Rally 自动化执行 Task 的功能依赖于 Task file，Task file 描述了任务的内容和执行任务所必须要的参数。Rally 自身就提供非常完善的 Task file sample，满足了大部分的测试需求，在路径 rally/samples/tasks/scenarios 下查看。
[root@control01 rally]# cd ../samples/tasks/scenarios/
[root@control01 scenarios]# ll
total 100
drwxr-xr-x 2 root root 4096 Oct 25 10:43 authenticate
drwxr-xr-x 2 root root 4096 Oct 25 10:43 ceilometer
drwxr-xr-x 2 root root 4096 Oct 25 10:43 cinder
drwxr-xr-x 2 root root 4096 Oct 25 10:43 designate
drwxr-xr-x 2 root root 4096 Oct 25 10:43 dummy
drwxr-xr-x 2 root root 90 Oct 25 10:43 ec2
drwxr-xr-x 2 root root 4096 Oct 25 10:43 glance
drwxr-xr-x 2 root root 4096 Oct 25 10:43 gnocchi
drwxr-xr-x 3 root root 4096 Oct 25 10:43 heat
drwxr-xr-x 2 root root 142 Oct 25 10:43 ironic
drwxr-xr-x 2 root root 4096 Oct 25 10:43 keystone
drwxr-xr-x 3 root root 4096 Oct 25 10:43 magnum
drwxr-xr-x 2 root root 4096 Oct 25 10:43 manila
drwxr-xr-x 2 root root 4096 Oct 25 10:43 mistral
drwxr-xr-x 2 root root 56 Oct 25 10:43 monasca
drwxr-xr-x 2 root root 4096 Oct 25 10:43 murano
drwxr-xr-x 2 root root 8192 Oct 25 18:20 neutron
drwxr-xr-x 2 root root 8192 Oct 25 10:43 nova
drwxr-xr-x 2 root root 50 Oct 26 15:07 octavia
drwxr-xr-x 2 root root 4096 Oct 25 10:43 quotas
-rw-r--r-- 1 root root 452 Oct 25 10:43 README.rst
drwxr-xr-x 2 root root 124 Oct 25 10:43 requests
drwxr-xr-x 3 root root 4096 Oct 25 10:43 sahara
drwxr-xr-x 2 root root 98 Oct 25 10:43 senlin
drwxr-xr-x 2 root root 4096 Oct 25 10:43 swift
drwxr-xr-x 2 root root 4096 Oct 25 10:43 vm
drwxr-xr-x 2 root root 234 Oct 25 10:43 watcher
drwxr-xr-x 2 root root 50 Oct 25 10:43 workload
drwxr-xr-x 2 root root 116 Oct 25 10:43 zaqar
这里我们以 Nova 的 boot-and-delete-server 为例，直接使用 Task file：rally/samples/tasks/scenarios/nova/boot-and-delete.json 来频繁创建和删除云主机。
rally task start ~/rally/samples/tasks/scenarios/nova/boot-and-delete.json
Step 3. 生成并查看测试报告
$ rally task report 5b24ef46-6061-443a-be14-dab1e5cdf51a --out output.html
使用浏览器打开 output.html 即可查看 Report 的内容。
Report 中展示了 Task 描述、SLA（服务质量协议）、Durations（任务持续时间）、Task Details 和执行成功率等用于评估性能参数的有效信息。
Rally 架构
上图是 Rally 的总体架构，描述了 Rally 的组成结构、数据流和 OpenStack 的调用方式。
- Deploy Engine：存储部署所需要的凭证（credentials）信息，以插件的形式集成第三方自动化部署工具（e.g. Devstack, Fuel, etc.），提供自动化部署能力。
- Verification：通过调用 Tempest（基于 unittest 的功能测试框架）来验证云平台的功能清单。
- Benchmark Engine/Task Engine：是一个通用的测试用例插件框架，允许用户编写参数化的 Plugin 实现以及对应的 Task File（YAML/JSON）来满足自定义功能、性能测试需求，使用这种通用的方式来生成真实的用户负载。
Rally 最初被设计成一种不需要 Daemon 的 CLI-Driver，这使 Rally 非常易于使用和开发。但通常 OpenStack Projects 总是以 “as-a-Service” 来实现的，所以现在社区也提出了 RaaS 的理念，并付诸于行动（work in progress）。
上图描述了 “Rally-as-a-Service” 和 “Rally-as-an-APP” 两种形式的实现架构，显然两者在实现上的区别主要在于是否具有 Daemon 以及相应的 HTTP、RPC Invoke，也就是所谓的是否实现了泛 “Service” 化。实际上，对于用户而言无需太过于关心上层的调用方式，用户只需关心 Rally Core 的 Benchmark Engine/Task Framework 的应用。所以本文采用的是更为成熟、简单以及常用的 “Rally-as-an-APP” 模式。
Rally Plugin 分析与实现
程序入口
依旧从 setup.cfg 切入：
[entry_points]
console_scripts =
rally = rally.cli.main:main
rally-manage = rally.cli.manage:main
可见 Rally 只有 rally 和 rally-manage 两个启动脚本，其中 rally-manage 主要用于打印 Version 信息、程序编译以及比较重要的数据库版本控制 3 个功能，不过这些功能至 0.10.0 之后都被移植到了rally 中，rally-manage 也被标记为了 deprecated：
`rally-manage db <command>` was deprecated since 0.10.0 version and is going to be removed soon. Please use `rally db <command>`.
所以我们重点要关注的程序入口还是 rally = rally.cli.main:main。
# file: ~/rally/rally/cli/main.py
"""CLI interface for Rally."""
from __future__ import print_function
import sys
from rally.cli import cliutils
from rally.cli.commands import db
from rally.cli.commands import deployment
from rally.cli.commands import env
from rally.cli.commands import plugin
from rally.cli.commands import task
from rally.cli.commands import verify
categories = {
"db": db.DBCommands,
"env": env.EnvCommands,
"deployment": deployment.DeploymentCommands,
"plugin": plugin.PluginCommands,
"task": task.TaskCommands,
"verify": verify.VerifyCommands
}
def main():
return cliutils.run(sys.argv, categories)
if __name__ == "__main__":
sys.exit(main())
- cliutils module：实现了常见的 CLI 调用的封装
- db/env/deployment/plugin/task/verify modules：每个 module 对应一个 rally 子命令 API 的调用封装
下文以 rally task start 子命令为例。
执行 rally task start 的 UML
从上述 UML 分析得出，当 Rally 执行一个任务时主要进行了以下工作：
- 加载、解析 Task File 并以统一的形式（TaskConfig Object）返回，TaskConfig 中包含了：
- benchmark scenarios name
- benchmark scenarios args
- runner type
- runner args
- 基于 TaskConfig 生成 TaskEngine Object，TaskEngine 是执行 benchmark scenarios 的对象，所谓的 benchmark scenarios 就是实际 Plugin Class/Method 实现的代码逻辑
- 基于 TaskConfig 生成 Runner Object，Runner 设定了执行 Task 进程拓扑（总数、并发数）
显然，开发者需要关心的主要有两点：
- task file 的定义
- benchmark scenarios 的实现
最后
最后总结一下完成实现所需要解决的几个问题：
- 如何通过 Task file 的 benchmark scenario name 加载指定的 Plugin Class/Method？
- 如何传入 Task file 中定义的 args 到 Plugin Class/Method？
- 如何返回 Octavia REST API 的 client？