企业上云解决方案(openstack一键部署)-昊阳知识网

https://www.ibm.com/developerworks/cn/cloud/library/1501_wogq_openstack/

本文主要描述针对 OpenStack 云计算项目的企业级性能测试标准和性能测试实施的解决方案。这套标准和解决方案，为 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 等。同时云服务使用者也可以在已经生成和个性化安装后的云虚拟机实例来生成自定义的镜像。这样以后就可以根据该自定义镜像直接生成所需的虚拟机实例。

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

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

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

OpenStack 架构解析

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

OpenStack 的逻辑架构

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

图 1. OpenStack 逻辑架构图

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

图 2. Heat 参数配置

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

通过以上解析我们可以看到 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 主要模块结构

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 云计算平台，其包含网络（Network）、控制（Controller)、计算（Computing)和存储（Storage）四个层面，每个层面配置若干台节点服务器。系统结构如下图所示：

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

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

表 1. 案例配置信息表

服务层

节点软件配置

节点物理配置

节点数量

Network

Customer Gateway

Gateway Server

Management Gateway

Gateway Server

Controller

HAProxy

32CPU Cores,96GRAM2*500G(RAID0)4*3T(RAID10)

Horizon

OpenStack Controller

DB2

Neutron

QPID

RedHat KVM

Computing

Created VM

32CPU Cores,128GRAM2*500G(RAID0)6*3T(RAID10)

RedHat KVM

Storage

RedHat NFS

32CPU Cores,96GRAM2*500G(RAID0)22*4T(RAID10)

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

并发访问下云计算平台各组件运行效率及服务器资源使用率：

根据上一节的分析我们知道，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 组件

Keystone 组件