针对 OpenStack 企业级云计算性能测试标准和解决方案，第 1 部分

本帖最后由 fc013 于 2016-4-16 19:50 编辑

问题导读：

1.怎样收集云计算性能测试的需求？

2.怎样分析和定制针对 OpenStack 云计算性能测试策略？

3.怎样制定云计算性能测试的解决方案？

综述

OpenStack 是如今最为流行一种开源的云计算项目方案, 作者所在 IBM 的基于企业级云计算战略产品就应用了相关技术。但目前针对 OpenStack 云计算平台的性能测试还没有一个统一的企业级标准，通过互联网得到的大部分技术资料也都是零散的，只针对 OpenStack 部分组件或局部层级的实验性性能测试方法。而企业级的云计算平台通常是一个多节点分布式并行系统，这也对基于 OpenStack 企业云开发过程中云系统性能的评估与测试带来了目标不明，方法不清的挑战。所以有必要制定一套针对 OpenStack 企业级的性能测试标准和解决方案。

作者提出制定该标准和解决方案的基础是：一. 作者具有在企业级云计算项目中的具体实践，以及以往大型金融和企业分布式管理系统如 AIA、Metlife、Merck、Wellpoint 等企业级性能测试与调优的项目经验；二. 作者所在的 IBM 公司就是 OpenStack 核心组织成员，这就给作者提供了丰富的技术资源与咨询的平台；三. 此标准和解决方案对今后的云计算系统性能测试的流程和目标提供了很好的借鉴作用，为在基于 OpenStack 云计算系统性能测试与分析的过程中，有效地解决“做什么”与“如何做”的困惑。

因为篇幅所限，本文将以三个部分的形式发布，其中

第 1 部分将包括：

OpenStack 的模块组成和架构；
云计算性能测试的需求收集；

第 2 部分将包括：

针对 OpenStack 云计算性能测试策略的分析和定制；
云计算性能测试的指标；
云计算性能测试的流程；

第 3 部分包括：

云计算性能测试的解决方案。

OpenStack 的模块组成和架构

首先我们要从 OpenStack 系统架构入手分析该云计算系统的结构特点，这样我们才能有针对性的制定性能测试流程和方案。OpenStack 云计算环境是基于 IaaS（Infrastructure as a Service 基础架构服务）提供的云服务，具体的说 OpenStack 是由一系列分布式组件组成的云计算管理平台。要做好针对 OpenStack 云平台的性能测试，首先要把该平台的相关组件以及组件间的组合架构和分布式协同工作原理解析清楚，这样才能制定好性能测试的目标和流程。

OpenStack 的模块组成

OpenStack 是面向 Iaas 服务的，即基础架构云平台。该平台的可以比喻成一个生产虚拟化基础架构的车间。这个车间主要生产 a. 虚拟机实例，b. 虚拟存储块，c. 虚拟网段等云服务组件，而每种服务组件都有相应的“车间主任”进行管理、调度和分配，这里的“车间主任”就是 OpenStack 云平台的管理模块，下面对 OpenStack 的管理模块进行介绍：

1. Keystone: 提供 OpenStack 的认证服务，用以管理云系统的 user，project（tenant），role 等认证和权限组件，这个模块可以看做是云系统车间的安全部门。

2. Nova：这个模块很重要，可以说是 OpenStack 的核心模块之一，以至于在 OpenStack 的初期版本里大部分的云系统管理功能都是由该模块负责管理的，只不过后来为了减轻该“车间主任”的压力，也便于功能分配管理，才把虚拟存储、网络等部分分离出来，而使该模块主要负责云虚拟机实例（Compute 或 Instance) 的生成、监测、终止等管理功能。

3. Glance：提供云虚拟机上的服务镜像(Image)功能，该模块可看成车间里的模具生产部门，该模具最基本的使用方式就是在为云虚拟机实例提供安装操作系统的模式，比如 RedHat Linux、Ubuntu、Windows 等。同时云服务使用者也可以在已经生成和个性化安装后的云虚拟机实例来生成自定义的镜像。这样以后就可以根据该自定义镜像直接生成所需的虚拟机实例。

4. Neutron: 提供 OpenStack 虚拟网络服务，也是 OpenStack 重要的核心模块之一，该模块最开始是 Nova 的一部分，叫 nova-network，后来从 Nova 中分离出来，开始名字为 Quantum，后来由于商业名权的原因改为了 Neutron。该模块之所以重要是因为如果没有虚拟网络服务，OpenStack 就变为单纯提供虚拟机实例和虚拟存储服务的平台，这就违背了提供分布式虚拟服务的云计算核心价值。该模块不仅提供基本的创建子网、路由和为虚拟机实例分配 IP 地址功能，还提供了 a. 同时支持多种物理网络类型，支持 Linux Bridge、Hyper-V 和 OVS bridge 计算节点共存；b. 支持防火墙服务；c. 支持虚拟网络中节点间 VPN 服务；d. SDN 实现完善和提高

5. Cinder: 提供 OpenStack 存储块（Volume）服务，该管理模块原来也为 Nova 的一部分，即 Nova-volume，后来从 Folsom 版本开始使用 Cinder 来分离出块存储服务。具体地说 Cinder 是云存储服务的调度监控模块，它需要与如 NFS、Ceph 等网络文件系统配合使用。

6. Horizon：为 OpenStack 提供交互式界面的 UI 组件。

以上是 OpenStack 的基本组件，通过这些组件就可以搭建一套基本的云计算服务平台，如果再加入面向对象存储的 Swift；用于 OpenStack 系统资源监控的 Ceilometer；和云系统部署用的 Heat，该云计算平台则会更加完善。

OpenStack 架构解析

从性能测试的角度，不仅要熟悉各模块的原理，也要清楚云系统的架构，下面从逻辑与物理两方面对 OpenStack 云系统进行架构解析：

1. OpenStack 的逻辑架构

先看 OpenStack 官网上的该云系统的概念图，该概念图展示了 OpenStack 云系统上各模块是如何协同工作的以及工作流程，这使我们对 OpenStack 各组件的逻辑概念有了先导的作用。之后我们通过各组件的逻辑概念再逐步深入了解 OpenStack 的逻辑架构，进而对我们针对该系统在逻辑上分析出性能测试的侧重点。

图 1. OpenStack 逻辑架构图

首先 OpenStack 云系统的使用者或环境部署者可以根据业务需要通过 Heat 组件订制出模板，该模板里定义了一套工作序列，其中核心部分包含了在云系统上生成虚拟机镜像（Image），安装规格的系统（InstanceType)，采用何种访问秘钥规格（Key），如下图所示。

图 2. Heat 参数配置

Heat 会根据该套模板执行自动化部署程序制定出可用的 OpenStack 云计算平台，可以说 Heat 是用来生成 OpenStack 云平台的自动化工厂，而我们测试的目标是 OpenStack 云平台的本身和其产生的虚拟系列。所以 Heat 一般不作为性能测试的目标对象。

在制定好的云系统平台上，用户在经 KeyStone 模块授权后（Provide Auth），通过 Horizon 或 RestAPI 模式创建虚拟机服务。创建过程包括了利用 Nova 模块创建虚拟机实例（VM Provision），该 VM 采用了 Glance 模块提供的镜像服务（Provide Image），然后用 Neutron 模块为新建的 VM 分配 IP 地址，把其纳入到虚拟网络中（Provide network connectivity），之后再通过 Cinder 模块创建的 Volume 为 VM 挂载存储块。整个过程都在 Cellometer 模块的资源监控下（Monitors)，Cinder 产生的 Volume 和 Glance 提供的 Image 可以通过 Swift 的对象存储机制进行保存。

通过以上解析我们可以看到 OpenStack 云平台服务的提供主要是依靠 Nova、Glance、Cinder 和 Neutron 四个核心模块完成的，相对四个辅助模块 Horizon、Cellometer、Keystone、Swift 提供的访问、监控、权限和对象存储功能，这四个核心模块的日常工作量将是相对繁重的，所以针对这四个核心模块的性能测试也将是针对 OpenStack 云系统测试工作的重中之重。当然有的人说 Horizon 是访问模块，不是要承载多并发用户的访问吗？

可是对 OpenStack 云系统的操控还有一个更重要的 REST API 的访问模式，这种模式下用户尤其是开发和维护云服务的用户，可以自定义自己的前端访问，而直接与 OpenStack 核心模块对话，所以 Horizon 应该是说访问 OpenStack 的一种便捷辅助方式，而且即使是这种辅助方式也是间接的通过 API 来访问 OpenStack 服务的，如下图所示外部对 OpenStack 及 OpenStack 模块之间都是以 API message queue 形式通信的：

图 3. OpenStack 主要模块结构

2. OpenStack 的物理架构

在清楚 OpenStack 云系统逻辑架构及模块机制的同时，对 OpenStack 云系统物理架构的掌握也是性能测试进行的重要工作，因为性能测试就是按照某系统的核心工作流程在物理平台上展开并发访问，而考评和分析该平台性能瓶颈和性能指标评估的测试。作者在此例举了一个典型的基于 OpenStack 云系统的物理架构配置，如下图所示：

图 4. OpenStack 的物理架构图

此配置分为 Network、Controller、Computing、Storage 四个层面，每个层面部署相应的服务单元（Node)，我们可以发现每层的服务单元都有至少一个和其相同配置的镜像单元，这种结构配置一可以增加 OpenStack 云系统的故障中持续性运营的保障性，其次可以在高并发访问下达到负载平衡功能，我们称其为 HA（Hight Available）模式，前端的访问协议则为 HAProxy。

在本 OpenStack 物理架构中我们可以看到，在 Network 层我们采用 Customer 和 Management 独立的访问网关，这是为把普通用户与系统管理的访问权限分离而设立的。而在 Controller 层，客户端通过 HAProxy 和 Horizon 页面访问 OpenStack Controller 模块，客户端的服务请求一般是转化成 REST API 的访问方式的，在逻辑架构中提到的 Nova，Glance,，Cinder 等逻辑模块就蕴含在其中，Controller 模块把相关 REST API 请求以信息队列的模式通过 Apache 开发的一款面向对象的消息中间件 QPID 来传输给相应的虚拟化服务系统，在这里我们采用 KVM（Kernel-based Virtual Machine）来实现物理系统的虚拟化服务，KVM 在此就起到了下层硬件分配管理与上层虚拟化服务建立的承上启下的作用。

与此同时 Neutron 模块也在该层发挥虚拟网络，如创建虚拟 IP、虚拟 VLAN 等服务。在 Computing Node 层的 Computing Node 就是预备为虚拟化城 VM 所提供的物理机单元，可以说 Computing Node 就是未来虚拟机单元的制造车间和承载平台。而在 Storage Node 层我们采用 NFS（网络文件系统）作为本 OpenStack 云平台的虚拟存储服务。

在这个物理架构中，我们可以通过创建一台虚拟机服务来看一下云服务提供的的工作流程，即当 Controller 模块接到如建立 VM 的 REST 命令时通过 QPID 把信息队列发送到 KVM，再由 KVM 访问 Computing Node，KVM 根据客户端的 REST 请求调用 Computing Node 物理机提供的 CPU、Memory 等物理资源并结合 Neutron 创建的虚拟 IP 创建了一台虚拟裸机，这时调用 Glance 模块提供的 Image 为这台虚拟裸机配置上请求对应的操作系统和服务软件，再调用 Cinder 模块从 NFS 中划分一个 Volume 存储块给这台 VM 作为扩展存盘。至此一台完整的 VM 诞生了。

云计算性能测试的需求收集

系统性能测试需求的收集一是来源于客户信息，OpenStack 是一个开源的系统平台，在用于商业化过程中，一般会经过二次开发以达到客户的订制化需求。二是来源于系统的应用属性，其包括 a.系统组件的使用频率；b.系统组件的关键程度；c.CPU、内存、磁盘 I/O、网卡等资源占用率。我们再通过上述 OpenStack 逻辑与物理架构的解析，根据 OpenStack 架构特点逐步分析出云计算平台的性能测试需求。云计算平台的一个重要系统功能是把数据中心的硬件资源虚拟化，而虚拟化过程中各虚拟资源的产生、管理和运行效率就是我们的性能测试重点。

现假设我们需要搭建一个的 OpenStack 云计算平台，其包含网络（Network）、控制（Controller)、计算（Computing)和存储（Storage）四个层面，每个层面配置若干台节点服务器。系统结构如下图所示：

图 5. OpenStack 云计算案例结构图

为了保证云计算平台的高稳定性和，每一层的服务器节点都需要冗余配套设置，具体配置信息如下表所示：

表 1. 案例配置信息表

服务层	节点软件配置	节点物理配置	节点数量
Network	Customer Gateway	Gateway Server	2
	Management Gateway	Gateway Server	2
Controller	HAProxy	32CPU Cores,96GRAM2500G(RAID0)43T(RAID10)	2
	Horizon
	OpenStack Controller
	DB2
	Neutron
	QPID
	RedHat KVM
Computing	Created VM	32CPU Cores,128GRAM2500G(RAID0)63T(RAID10)	8
	RedHat KVM
Storage	RedHat NFS	32CPU Cores,96GRAM2500G(RAID0)224T(RAID10)	2

所以我们的云计算性能测试需求主要面向以下两个方面：

并发访问下云计算平台各组件运行效率及服务器资源使用率：
根据上一节的分析我们知道，OpenStack 云计算平台使用频率高，而且关键程度重要的组件包括 Nova、Cinder、Glance、Neutron、Keystone，如果客户要求通过 UI 的方式访问和管理云计算平台，则 Horizon 也是使用频率高的组件。这些组件在面对外部并发访问时的运行效率以及其所在服务器资源如，CPU、内存、磁盘 I/O、网速的使用率决定了云计算平台的运转性能。
测试虚拟资源的运行效率：
云计算对用户的服务主要体现在云计算系统产生的各项虚拟资源，如虚拟机、虚拟存储、虚拟网络。而各项虚拟资源的运行效率决定了云计算的服务质量，所以对虚拟资源的性能测试也是云计算性能测试需求的一个重要部分。

根据上面的需求分析我们就可以展开对两大部分性能测试的需求收集。

云计算平台各组件性能测试需求
- Nova 组件
  该组件的性能测试主要应面对虚拟机（Server）的管理效率，其中包括 Server 的产生，Server 的转变成 Active 状态所需的时间。
- Cinder 组件
  该组件的性能测试主要面对虚拟存储（Volume）的管理效率，其中包括 Volume 的产生，Volume 的转变成 Available 状态所需的时间。
- Glance 组件
  该组件的性能测试主要面对虚拟镜像（Image）的管理效率，其中包括 Image 的产生，Image 的转变成 Available 状态所需的时间。
- Neutron 组件
  该组件的性能测试需要根据实际的虚拟网络的要求来定，如果只是基本需求那只需关注 Subnet 的创建耗时，浮动 IP 生效时间。如果扩展开来则需关注 VLAN、Firewall、SDN 等服务的性能，其中测试参数包含了网络带宽（bandwidth）、延迟（latency）、IO 请求（IOPS）等。
- Keystone 组件
  该组件的性能测试主要面对 OpenStack 的用户(user)、项目租约（tenant)、用户角色（role)等管理性功能，测试这些功能的产生和生效的的响应时间。
云计算平台虚拟资源的性能测试需求
如果把 OpenStack 云计算平台比喻成生成汽车的工厂，那么这部分就是测试生产出的汽车的性能。这一部分是关注在云计算平台上生成的虚拟资源的工作效率，这涉及到虚拟机、虚拟存储、虚拟网络各个部分协同工作，具体包括以下几个部分：
a.虚拟机（VM）分配 CPU、内存的使用性能
b.虚拟存储（volume）的使用性能
c.虚拟网络（network）的工作性能