中国铁路基于intel架构超大规模 openstack行业云的...

中国铁路基于Intel架构超大规模OpenStack行业云的性能优化研究

1. 项目简介

铁路作为一种大众化的交通工具和非常重要的货物运输方式，其业务规模庞大、覆盖全

国、服务全国各族人民。铁路面向公众提供的服务业务，主要是客运和货运两大类，且每

年365天、每天7*24小时连续不间断运转。铁路业务规模大可从以下几组简单数字直接体

现出来，2016年日均客运量758万人，货运量日均726万吨；2017年预计日均客运量828

万人，货运量日均753万吨；铁路客运售票网站（www.12306.cn）的注册用户已超3亿人，

2017年春运售票高峰期间，互联网最高日售票量933万张，平均日售票量769万张。网站单

日最高浏览426亿次，日均点击次数为310亿次。截至2016年底，我国的铁路运营里程已达

12.4万公里，世界排名第二位，其中高铁运营里程2.2万公里，排世界第一位。中国铁路总公

司是国内唯一负责铁路运输统一调度指挥，经营铁路客货运输业务，承担专运、特运任务，

负责铁路建设，承担铁路安全生产主体责任等的国有大型企业。

目前铁路总公司正在瞄准世界一流的现代物流企业的目标转型发展，面对规模庞大、日益

增长的客流和物流，需要铁路IT部门提供坚实的信息技术支撑，更需要铁路IT部门适应当

前互联网+和数字化转型的需求。面对时代的变革和向现代物流企业转型的需要，铁路IT

部门需要建设更高效灵活、部署简便、安全可控的IT基础设施，以支持向客户提供便捷的

信息查询、线上购票、电子支付等网络服务，同时满足中国铁路总公司内部管理创新、业务

创新和应用创新等对IT基础设施日益增长的需求，支撑企业管理从粗放式向精细化转变、

从过去生产计划型向主动适应市场需求转变，借助云计算、大数据、物联网、移动互联等不

同类型的创新技术改造铁路传统业务。由此可见，建设和使用铁路云平台是提供更高效、

便捷和绿色IT基础设施的必由之路。铁路对云平台的基本需求是稳定、可靠、易用，同时满

足国家和铁路总公司对信息系统安全等级保护的有关要求，也只有这样才能保障铁路各项

业务安全有序运转。

中国铁路信息技术中心是中国铁路总公司的全资直属企业，主要负责铁路总公司本级数据

中心IT基础设施的建设和管理，以及铁路信息系统的研发集成、工程建设和运维保障等相

关工作。

为了更好地支持中国铁路总公司从传统客货运输企业向现代物流企业转型，中国铁路信息

技术中心于2014年底决定研发云计算解决方案和产品。作为一个大型行业的OpenStack用

户，中国铁路总公司希望真正掌握开源技术，安全可控地运用在生产中，而不是简单的产品

使用方，同时为了打造用户与厂商共生互利的OpenStack新商业生态，“铁信云”产品采用了

业界创新的联合研发模式，由中国铁路信息技术中心牵头组织，北京中铁信科技有限公司

和北京云途腾科技有限责任公司一起联合研制。铁信云是基于OpenStack的行业云产品，

致力于解决铁路传统信息系统建设模式下存在的各种弊端和不足，例如系统建设周期长、

总体拥有成本高、资源利用率不均衡且难以调整等问题，为铁路应用系统提供弹性、高效、

目录

1. 项目简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

2. 铁信云架构介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.1 铁信云平台架构介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.2 铁信云部署架构介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.3小规模测试部署介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

第一部分：控制平面性能测试及优化 . . . . . . . . . . . . . 33. 控制平面测试介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

3.1 测试目的及方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

3.2 相关知识简述 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

3.3 数据收集及分析方法概要 . . . . . . . . . . . . . . . . . . . . . . . .4

4. 控制平面性能测试分析及优化 . . . . . . . . . . . . . . . . . . . . . . . .4

4.1 第一轮参数优化调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

4.2 第二轮参数优化调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

4.2.1 两大错误问题分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

4.2.2 参数再次优化调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

4.3 消息统计模型及消息通信架构调整 . . . . . . . . . . . . . . . .7

4.4 OpenStack组件数据库负载分析及优化 . . . . . . . . . . .7

4.5 综合优化前后云主机创建请求成功率及耗时分析 . . . .9

第二部分：数据平面性能测试及优化 . . . . . . . . . . . . . 95. 前端数据平面网络性能测试及调优 . . . . . . . . . . . . . . . . . . .10

5.1 物理网络性能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

5.1.1 测试方法和环境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1.2 物理网络性能测试结果及分析 . . . . . . . . . . . . . . . . . . . . . . 10

5.2 虚拟网络性能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

5.2.1 测试配置和方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.2.2 测试结果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6. 后端数据平面分布式存储性能测试 . . . . . . . . . . . . . . . . . . .12

6.1 基于小规模环境的Ceph测试 . . . . . . . . . . . . . . . . . . . .12

6.1.1 测试方法及环境部署 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.1.2 SSD盘加HDD盘部署测试 . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.1.3 SSD卡加SSD盘部署测试 . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.2 基于大规模部署的Ceph测试 . . . . . . . . . . . . . . . . . . . .15

第三部分：关键业务应用承载验证 . . . . . . . . . . . . . . 167. 关键业务应用(Oracle RAC)负载性能测试 . . . . . . . . . . . . .16

7.1.Oracle数据库在铁路中的应用 . . . . . . . . . . . . . . . . . . .16

7.2.Oracle RAC测试部署方案及性能 . . . . . . . . . . . . . . . .16

7.2.1 缺省配置的Oracle RAC性能 . . . . . . . . . . . . . . . . . . . . . . . 17

7.2.2 优化配置的Oracle RAC性能 . . . . . . . . . . . . . . . . . . . . . . . 17

8. 总结和展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

9. 致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

10. 附件及参考资料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10.1 附件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10.2 参考资料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

作者：高明星胡明月金运通

白皮书

白皮书 | 中国铁路基于Intel架构超大规模OpenStack行业云的性能优化研究

安全、便捷、绿色的IT基础架构。2015年底，铁信云云管平台V1.0

产品发布；2016年7月，铁信云云管平台V2.0产品发布。2016年

底，铁信云在中国铁路信息技术中心的2015公共信息处理平台扩

容工程中开始建设和部署应用，按照工程设计规划，应在铁信云

IaaS平台上部署铁路客运、货运、调度、机务和公共基础平台五大

类共计十几个应用，截至目前整体应用迁移、部署基本完成并投入

生产运行。

基于铁路的应用及运维特点，铁信云要求以“稳定性、可靠性、易用

性、安全性”为标准对OpenStack进行二次开发，解决OpenStack

开源架构下各种模块与组件的不足，同时为了满足铁路行业超大规

模行业云部署实施，并对业务应用提供高性能、稳定可靠的支撑，

我们做了一系列的测试调优和验证工作，主要分为以下3个部分：

• 控制平面性能测试及优化

通过测试来验证铁信云在单一region下能支撑的最大规模，寻找在

单一region下部署的高效优化架构设计方案，以及在该架构下的优

化参数配置，以保障其在超大规模部署和高负载条件下云服务能

高效、稳定、可靠运行。

• 数据平面性能测试及优化

云平台承载业务的性能及运行稳定性与云平台的数据平面密切相

关，通过对存储，计算，网络方面的性能测试和优化来验证Intel产

品及技术对云平台数据平面的性能支撑，并为生产环境的部署及配

置提供参考和优化方法。

• 关键应用负载Oracle RAC性能测试及优化

Oracle RAC数据库作为铁路信息系统中的关键应用，在控制平面

及数据平面的优化验证基础之上，我们对Oracle RAC在铁信云环

境中进行了部署和验证。

2. 铁信云架构介绍

2.1 铁信云平台架构介绍

“铁信云”云平台目前主要包括基础设施服务层（IaaS）和平台服务层

（PaaS），整体架构如下图2.1所示：

“铁信云”的基础设施服务层（IaaS），以OpenStack架构为基础，实

现对计算资源池、存储资源池和网络资源池进行统一管理和调度，

为信息系统应用部署提供基础资源服务。计算资源池支持对KVM、

VMware、X86裸机、Power设备等多种资源的统一管理；存储资

源池支持对基于X86服务器的分布式存储和基于传统商用存储等

多种资源的统一管理；网络资源池支持对VLAN、VxLAN等多种模

式下的物理和虚拟网络资源的统一管理。

“铁信云”的平台服务层（PaaS），为应用运行提供数据库、中间件、

大数据、数据备份等平台软件的统一部署服务；提供数据抽取、分

析、存储及展示等服务，同时基于容器技术提供应用快速部署及迁

移服务。

“铁信云”还根据大规模部署等需求，不断改进完善云平台功能。例

如改进了云主机监控方式，舍弃了Ceilometer的监控功能，集成

了Open-Falcon；增加了日志审计模块，便于管理员和租户查阅

操作日志；实现了云主机HA，支持物理主机故障时云主机自动迁

移，等等。

2.2 铁信云部署架构介绍

“铁信云”一期项目大规模部署环境中包括一个由780个物理节点构

成的云系统，其中有3个控制节点、600个主机作为计算节点，网络

节点在计算节点上、117个存储节点等。部署架构如下图2.2 所示：

用存储等多种资源的统一管理；网络资源池支持对 VLAN、VxLAN 等多种模式下的物理和虚拟网络资源的统一

管理。

“铁信云”的平台服务层（PaaS），为应用运行提供数据库、中间件、大数据、数据备份等平台软件的统一

部署服务；提供数据抽取、分析、存储及展示等服务，同时基于容器技术提供应用快速部署及迁移服务。

“铁信云”还根据大规模部署等需求，不断改进完善云平台功能。例如改进了云主机监控方式，舍弃了

Ceilometer 的监控功能，集成了 Open-Falcon；增加了日志审计模块，便于管理员和租户查阅操作日志；实现

了云主机 HA，支持物理主机故障时云主机自动迁移，等等。

2.2 铁信云部署架构介绍

“铁信云”一期项目大规模部署环境中包括一个由 780 个物理节点构成的云系统，其中有 3 个控制节点、

600 个主机作为计算节点，网络节点在计算节点上、117 个存储节点等。部署架构如下图 2.2 所示：

图 2.2 铁信云平台部署架构

本次大规模优化验证基于以上铁信云 780 个节点的系统，主要软硬件设备及基本配置如下表 2.1 和 2.2 所

示：

CPU 内存(DDR4) 系统硬盘

控制节点 2*12 Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz

512G 2*480GB SATA SSD

计算节点 2*10 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz

256G 2*900GB SAS HDD (RAID 1)

存储节点 2*10 Intel(R) Xeon(R) CPU E5-2630 v4 @ 64G 2*900GB SAS

图2.2 铁信云平台部署架构

本次大规模优化验证基于以上铁信云780个节点的系统，主要软硬

件设备及基本配置如下表2.1 和 2.2 所示：

CPU 内存(DDR4) 系统硬盘控制节点 2*12 Intel(R)

Xeon(R) CPU E5-2650 v4 @ 2.20GHz

512G 2*480GB SATA SSD

计算节点 2*10 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz

256G 2*900GB SAS HDD (RAID 1)

存储节点 2*10 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz

64G 2*900GB SAS HDD (RAID 1)存储盘见6.4节

表2.1 服务器配置

图2.1 铁信云平台整体架构2

应用系统云安全云管理

铁信云引擎（PaaS）

铁信云引擎（IaaS）

计算资源池网络资源池网络资源池

战略决策访问安全

资源管理

主机安全

权限管理

系统安全

运维管理

数据安全

全局监控

网络安全

配置管理

应用安全

资产管理

大数据服务

计算管理

KVM/Xen 虚拟交换机分布式存储

网络管理

物理设备管理 VLAN 集中式存储

负载均衡

经营开发

中间件服务

块存储管理

VMware 虚拟路由器

安全认证

PowerVM VXLAN

资源弹性扩展

运输生产

应用容器服务

对象存储管理

资源编排

云机监控

数据库服务

文件存储管理

资源计量

云主机HA

存储备份服务

镜像管理

裸机管理

日志优化

资源管理建设管理综合协同

controller1 controller2 controller3


软件版本配置

主机操作系统 Centos 7.3

OpenStack 铁信云(基于Liberty版)

存储 Ceph (Jewel版本)

客户机操作系统 Centos 6.8

表2.2 软件配置

2.3 小规模测试部署介绍

对于数据平面的性能测试，我们单独部署了一个小规模隔离的环境，

其中三台4路服务器用做管理节点，四台2路服务器用作Ceph存储节

点，四台2路服务器用作计算节点，每台机器都有2个10G网络端口连

接到核心交换机。计算节点的一个10G端口作为数据网，另一个10G

端口连接存储网，存储节点一个10G端口用作存储网络访问，另一个

10G端口用作Ceph节点间存储复制，网络MTU值设置为1500。

Controller

OSD

VM VMVM VM

OSD OSD OSD

MON MON MON

OSD

VM VMVM VM

OSD OSD OSD…

… …… …

… … …

CEPH 1

COMPUTE 1 COMPUTE 3COMPUTE 2 COMPUTE 4

CEPH 2 CEPH 3 CEPH 4

2*10G NIC

2*10G NIC

小规模测试部署

图2.3 小规模测试部署

详细服务器配置见下表2.3，其中对于存储节点的存储配置会在相

应的测试环境中介绍：

管理服务器计算节点存储节点

CPU 4 * E7-4890 v2 2.8G (15 core)

2 * E5-2699 v4 2.2G (22 core)

2 * E5-2699 v4 2.2G (22 core)

内存 256G 128G 128G

存储(系统盘)

1 * Intel S3510 SSD 240G



网口 Intel X710 Dual Port2 * 10G SFP2 * 10G BaseT

Intel X710 Dual Port2 * 10G SFP2 * 10G BaseT

Intel X710 Dual Port2 * 10G SFP2 * 10G BaseT

表2.3 小规模测试配置

第一部分：控制平面性能测试及优化控制平面是指在云环境下为实现IT资源的统一管理和调度而设备

互联形成的网络，设备包括控制节点和被管控的计算、存储、网络

等资源节点；建立控制平面的目的是通过充分利用IT资源以更好

地满足业务应用运行需求。

控制平面的性能是云平台大规模部署的基础和关键，大规模行业

云的控制平面部署设计有多种方案，如单一region规模化部署、

多region部署、多cell等模式，无论哪种模式，单一region下的规

模部署是基础。通过测试来验证铁信云在单一region下能支撑的

最大规模，试图寻找在单一region下部署的高效优化架构设计方

案，以及在该架构下的优化参数配置，以保障其在超大规模部署

和高负载条件下云服务能高效、稳定、可靠运行。

3. 控制平面测试介绍

3.1 测试目的及方法

此次案例以探索单region的规模和性能边界为目标做了测试和优

化，最终希望利用现有经验探索大规模数据中心的云平台部署最

佳实践：

• 观察一定规模计算节点下创建云主机压力对控制节点集群的影

响，例如CPU、内存、网络IO、磁盘IO等，为今后大规模云数据中

心的云平台设计、扩容提供数据基础。

• 并发及资源利用率考量。来自用户的并发请求对整体系统稳定性

的考量，即寻找数据库、RabbitMQ集群和OpenStack组件瓶

颈，期望通过改良系统参数、服务配置、代码逻辑，在服务稳定

的前提下最大化提高物理资源的使用效率。

我们依次对100、200、300、400、500、600物理计算节点做了

多轮测试及优化：

• 通过固定计算节点数，以1：20的比例（1台计算节点创建20台

云主机）分批次创建相应数量的云主机，通过查询数据库和日

志信息可以计算获得其创建成功率，通过分析日志，对每台创

建成功的云主机，都可以计算得到它在创建过程中各模块的时

间消耗，并以此衡量创建云主机的性能。

• 针对RabbitMQ的分析，基于一组以1：2的比例（1台计算节点

创建2台云主机）分批次创建云主机的场景，用以获取准确的实

际消息数目，建立基准模型供后续分析参考验证。基于此，利用

监控数据定性分析在1:20比例下的优化效果。

• 模拟多API同时触发，针对失败的请求，结合系统返回的信息和

日志观察，分析错误原因。

• 通过用一些性能监测工具对创建云主机过程进行性能评测。

3


3.2 相关知识简述

3.2 相关知识简述

图 3-1：创建请求处理流程图

云主机的创建是 OpenStack 各种业务中最复杂的场景，因此为了验证规模场景，我们选择了云主机创建业

务作为验证参数边界的测试手段。为了后续讨论方便，下面简要介绍云主机创建流程。如图 3-1 所示，该过程

涉及各模块间的交互（Keystone 对整个过程 HTTP 请求均会进行验证）：

1）控制节点上的 Nova 服务接受请求并进行预处理，其中，通过 HTTP Get 请求与 Glance 和 Neutron 交

互检验请求信息，选出 host 主机后，再通过 RPC 交由相应计算节点的 nova-compute 服务处理；

2）Nova 向 Glance 发 HTTP Get 请求获取镜像信息，据此创建存储资源；

3）Nova 向 Neutron 发 HTTP Get 请求获取网络信息、Post 请求创建 port 并 attach 到该云主机；

4）等到云主机存储和网络资源准备完成，Nova 启动并成功创建云主机。

3.3 数据收集及分析方法概要

OpenStack 黑盒测试常会使用 Rally 项目，但要精细分析，需要不断轮询系统状态，会带来额外分析误差，

因此我们采用模拟测试系统直接调用 OpenStack API 作为替代方案，再基于资源性能监控数据和日志数据进行

图3-1 创建请求处理流程图

云主机的创建是OpenStack各种业务中最复杂的场景，因此为了

验证规模场景，我们选择了云主机创建业务作为验证参数边界的

测试手段。为了后续讨论方便，下面简要介绍云主机创建流程。如

图3-1所示，该过程涉及各模块间的交互（Keystone对整个过程

HTTP请求均会进行验证）：

1）控制节点上的Nova服务接受请求并进行预处理，其中，通过

HTTP Get请求与Glance和Neutron交互检验请求信息，选出

host主机后，再通过RPC交由相应计算节点的nova-compute

服务处理；

2） Nova向Glance发HTTP Get请求获取镜像信息，据此创建存

储资源；

3） Nova向Neutron发HTTP Get请求获取网络信息、Post请求

创建port并attach到该云主机；

4）等到云主机存储和网络资源准备完成，Nova启动并成功创建

云主机。

3.3 数据收集及分析方法概要

OpenStack黑盒测试常会使用Rally项目，但要精细分析，需要不

断轮询系统状态，会带来额外分析误差，因此我们采用模拟测试

系统直接调用OpenStack API作为替代方案，再基于资源性能监

控数据和日志数据进行建模分析，来获取结果数据。在本次案例

研究中，我们在中国铁路总公司数据中心780节点生产环境上线

前对它进行了大规模测试验证，发现了铁信云在系统架构、运行

机制、系统参数、数据库配置、OpenStack组件配置参数等各方

面存在的问题，并通过分析，调整了架构、更换了组件，优化了相

应参数，解决了问题。最终我们确定了铁信云在现有物理硬件节

点规模情况下，能稳定工作的部署架构以及优化建议。

本部分测试使用Open-Falcon从系统资源、RabbitMQ、数据

库等方面收集云平台性能监控数据；模拟测试系统直接调用

OpenStack API创建云主机；通过启用RabbitMQ的trace功能收

集消息日志；通过使用Flume+Kafka+Spark+HDFS收集云平台

日志，并做处理和分析。

通过分析OpenStack源码并结合测试，对创建过程中产生的

RabbitMQ消息总数与节点数的递增关系建模，鉴于大规模并发

创建对RabbitMQ强压导致性能等问题，我们的方案是，在小规

模环境下从trace日志中获取实验结果，对模型做精确定量验证，

基于此对系统进行优化，再在大规模场景下结合监控数据做了优

化效果定性分析。

为了避免由于收集测试数据对集群带来额外负载，我们选择针

对OpenStack的日志进行归纳汇总处理，避免在测试场景运行

期间，造成额外延迟。基于OpenStack的现有日志，通过分析建

模，获取创建过程各阶段的生命周期，对数据进行分类汇总，可以

有效展现高压力测试场景下各交易的真实并发处理效能。

4. 控制平面性能测试分析及优化

本章按照第三章中介绍的测试和数据收集方法，先对社区默认的

参数配置进行测试，通过对日志数据的收集和分析发现大规模部

署中的瓶颈所在，并逐步加以优化和验证，最终得出大规模部署

下最佳配置和部署实践。

4.1 第一轮参数优化调整

社区默认配置无法直接承载600+计算节点规模，表征如下：

• RabbitMQ连接超时，如图4-1和4-2所示

• 无法执行创建、获取资源等任务

• Keystone无法响应等

•

图 4-1：RabbitMQ 连接超时，neutron agent 上报状态异常图 4-2：RabbitMQ 繁忙，nova-compute 服务显示异常

为了满足大规模节点部署的应用场景，如下表 4-1 所示，我们对系统参数、数据库配置、OpenStack 组件

分别根据需求做了调整。例如,操作系统方面，我们调整了最大文件描述符、最大线程数，以提高单个系统吞吐

能力;数据库方面，我们调整了 openfile 限制，调大了查询缓存,以提高数据库节点的整体性能;OpenStack 方面，

我们根据自身环境情况做了 RPC 相关的服务配置，以缓解服务端压力。

文件修改参数说明

/usr/lib/systemd/system/rab

bitmq-server.service LimitNOFILE=65536

RabbitMQ 服务最大连接

数

/etc/rabbitmq/rabbitmq.con

fig

cluster_partition_handling, autoheal

vm_memory_high_watermark, 0.6

collect_statistics_interval, 30000

backlog, 2048

RabbitMQ 配置文件修改

/etc/rabbitmq/rabbitmq-env

.conf ulimit -S -n 4096

RabbitMQ 删除行

/usr/lib/systemd/system/ma

riadb.service LimitNOFILE=65536

Mysql 服务最大连接数

/etc/my.cnf max_user_connections=10000

max_connections=100000

table_open_cache = 4096

innodb_buffer_pool_size = 2G

innodb_log_file_size = 192

innodb_buffer_pool_instances = 2

wsrep_slave_threads = 48

innodb_flush_log_at_trx_commit = 0

thread_concurrency = 48

thread_cache_size = 32

query_cache_type = 0

query_cache_size = 0

join_buffer_size = 256K

Mysql 配置文件修改

图4-1 RabbitMQ连接超时，neutron agent上报状态异常

4


图 4-1：RabbitMQ 连接超时，neutron agent 上报状态异常图 4-2：RabbitMQ 繁忙，nova-compute 服务显示异常

为了满足大规模节点部署的应用场景，如下表 4-1 所示，我们对系统参数、数据库配置、OpenStack 组件

分别根据需求做了调整。例如,操作系统方面，我们调整了最大文件描述符、最大线程数，以提高单个系统吞吐

能力;数据库方面，我们调整了 openfile 限制，调大了查询缓存,以提高数据库节点的整体性能;OpenStack 方面，

我们根据自身环境情况做了 RPC 相关的服务配置，以缓解服务端压力。


/usr/lib/systemd/system/rab

bitmq-server.service LimitNOFILE=65536

RabbitMQ 服务最大连接

数

/etc/rabbitmq/rabbitmq.con

fig

cluster_partition_handling, autoheal

vm_memory_high_watermark, 0.6

collect_statistics_interval, 30000

backlog, 2048

RabbitMQ 配置文件修改

/etc/rabbitmq/rabbitmq-env

.conf ulimit -S -n 4096

RabbitMQ 删除行

/usr/lib/systemd/system/ma

riadb.service LimitNOFILE=65536

Mysql 服务最大连接数

/etc/my.cnf max_user_connections=10000

max_connections=100000

table_open_cache = 4096

innodb_buffer_pool_size = 2G

innodb_log_file_size = 192

innodb_buffer_pool_instances = 2

wsrep_slave_threads = 48

innodb_flush_log_at_trx_commit = 0

thread_concurrency = 48

thread_cache_size = 32

query_cache_type = 0

query_cache_size = 0

join_buffer_size = 256K

Mysql 配置文件修改

图4-2 RabbitMQ繁忙，nova-compute服务显示异常

第一轮参数优化调整的目标是为了满足大规模节点部署的应用场

景，使云管理平台能够基本正常运行。如下表4-1所示，我们对系

统参数、数据库配置、OpenStack组件分别根据需求做了调整。

例如,操作系统方面，我们调整了最大文件描述符、最大线程数，

以提高单个系统吞吐能力;数据库方面，我们调整了openfile限

制，调大了查询缓存,以提高数据库节点的整体性能;OpenStack

方面，我们根据自身环境情况做了RPC相关的服务配置，以缓解

服务端压力。


/usr/lib/systemd/system/rabbitmq-server.service

LimitNOFILE=65536RabbitMQ服务最大连接数

/etc/rabbitmq/rabbitmq.config cluster_partition_handling, autohealvm_memory_high_watermark, 0.6collect_statistics_interval, 30000backlog, 2048

RabbitMQ配置文件修改

/etc/rabbitmq/rabbitmq-env.conf ulimit -S -n 4096 RabbitMQ删除行

/usr/lib/systemd/system/mariadb.service LimitNOFILE=65536 Mysql服务最大连接数

/etc/my.cnf max_user_connections=10000max_connections=100000table_open_cache = 4096innodb_buffer_pool_size = 2Ginnodb_log_file_size = 192innodb_buffer_pool_instances = 2wsrep_slave_threads = 48innodb_flush_log_at_trx_commit = 0thread_concurrency = 48thread_cache_size = 32query_cache_type = 0query_cache_size = 0join_buffer_size = 256Kinnodb_checksum_algorithm=innodb

Mysql配置文件修改

/usr/lib/systemd/system/memcached.service LimitNOFILE=65536 Memcached服务最大连接数

/etc/sysconfig/memcached MAXCONN=”65535”CACHESIZE=”16384”OPTIONS=”-t 16”

Memcached配置文件修改

/usr/lib/systemd/system/haproxy.service LimitNOFILE=65536 Haproxy服务最大连接数

/etc/haproxy/haproxy.cfg maxconn=80000

/etc/haproxy/haproxy.cfg listen mq-cluster balance source hash-type consistent mode tcp option tcplog option clitcpka option srvtcpka timeout client 28801s timeout server 28801sneutron-api-cluster timeout server 600scinder-api-cluster timeout server 600s

Haproxy配置文件修改

5


经过上述第一轮参数配置修改后，600+节点构成的云平台工作正

常，并能正常对外提供服务。

4.2 第二轮参数优化调整

第二轮参数优化调整的目标是为了进一步提高云平台运行的稳

定性和可靠性。经过上述第一轮参数调整，在高并发和高负载条

件下创建云主机，仍然还存在较高的失败率。为更好地了解创建

云主机流程和错误性质，我们分析了3组场景（200、400、600

计算节点，以1:20比例创建云主机）的详细日志以及数据库中的

所有相关信息。在全部24000个请求中，我们成功追踪到所有请

求，其中17703个请求成功完成，成功率仅为73.76%。

我们对创建过程中的错误进行了分类，表4-2展示了错误分布情

况。基于分词、特征提取以及聚类建模分析，我们得到关键错误

信息，消除了重复和不相关的信息。

Error type Error Count

Neutron does not respond 3740

Nova api get net info failed from neutron 1715

Neutron binding failed for port 698

Neutron DBDeadlock 98

Instance stuck in scheduling 39

Authentication required 6

RPC failed when select destination for instance 1

表4-2 创建云主机异常分类统计表

4 .2 .1 两大错误问题分析

表4-2中列出了的几种错误表现形式，可以主要归纳为以下两大错误

类型：

• 消息队列相关问题：在压力太大的情况下，RabbitMQ集群不

稳定因素会导致队列同步失败，最终消息丢失，或者直接

导致队列消失，消费者无法拿到消息等。因此出现，Neutron

linuxbridge agent上报状态失败，neutron-server误认为与

port绑定的linuxbridge agent处于dead状态，导致port绑定

失败；Nova通过RPC与nova-scheduler交互选择host主机失

败导致选择主机失败、与nova-compute交互执行创建云主机

操作失败导致云主机一直处于scheduling状态等情况。

• 数据库问题：一方面，数据库表死锁，主要集中在Neutron创

建port分配IP的过程中，并发分配网络IP时会导致资源争抢；另

一方面，在nova-compute准备网络资源、及nova-api检验请求

网络信息时与Neutron交互的过程中，由于数据库读写较慢导致

Neutron处理请求过慢，无法响应Nova的请求。

4 .2 .2 参数再次优化调整

经进一步调查研究发现，表4-2列出的异常及错误问题，可采用如

下方法规避并进一步调优。

• 适当增加 N e u t r o n 配置中的 a ge nt _ d ow n _ t i m e，避免

linuxbridge agent出现僵死的现象。


/etc/sysctl.conf net.ipv4.neigh.default.gc_thresh1=204800net.ipv4.neigh.default.gc_thresh1=307200net.ipv4.neigh.default.gc_thresh1=409600net.ipv4.neigh.default. gc_stale_time= 604800

系统mac表配置修改

/etc/nova/nova.conf 增加配置项：block_device_allocate_retries = 200修改配置项：rpc_response_timeout=600修改配置项：Timeout=600（[neutron]模块）

Nova配置文件修改

/etc/neutron/neutron.conf 修改配置项：api_workers=24修改配置项：rpc_workers=24

Neutron配置文件修改

/etc/sysctl.conf 增加配置项 fs.file-max=502400 系统配置文件修改

/etc/keystone/keystone.conf 加入以下配置[memcache]servers = 172.17.1.250:11211[token]provider = keystone.token.providers.uuid.Providerdriver =keystone.token.persistence.backends.memcache.Token

Keystone配置文件修改

OpenStack各组件的notification driver 配置项都置为noop 去掉notification driver

/proc/sys/kernel/pid_max 80000 最大进程数修改

表4-1 配置参数优化

6


• 适当增加Nova配置文件的the service_down_time，避免nova-

scheduler调度过程中出现nova-compute僵死的现象。

• 将Nova配置文件中的the rpc_response_timeout设置为更长的

时间，允许更长的时间等待nova-scheduler调度。

经过上述参数优化调整后，可以在一定程度上缓解创建云主机的

失败率。完成第二轮参数优化调整后，我们再次在相同的3个场景

下，共创建24000台云主机，成功率由73.76%上升至84.50%。

但是仍然有一部分错误需要解决，接下来我们对2大错误问题根

源入手进行更深层次的分析优化。

4.3 消息统计模型及消息通信架构调整

测试过程中，伴随集群规模扩大（主要是计算节点增加），服务端

对成功响应创建请求的占比有所下降。通过进一步对错误日志分

析，在创建过程中，通常会出现以下几类异常：

• 消息队列丢失导致云主机一直处于调度状态（已经选出主机，但

是计算节点没有处理相关任务，云主机状态也不会变成error）

• 各服务连接RabbitMQ失败并不断重连

• 处理创建请求的过程中RabbitMQ崩溃

针对消息队列压力过大的问题，我们对比配置了nova-conductor

的两种API模式，由rpc改为local模式;另一方面，notification driver

配置为noop。这些措施一定程度上减少了消息队列的负荷。同时，

我们结合源码对测试数据进行分析，先从源码中汇总创建过程中出

现的rpc方法，再根据涉及的rpc类型估计相应的消息数目，最后得

到关于创建请求产生的消息总数的计算模型，通过分析测试过程中

RabbitMQ产生的的trace日志，可以获取实际消息数目。但考虑到

大规模创建对RabbitMQ的压力，我们采取的是小规模（按照1:2的

比例为每个计算节点创建云主机）定量验证模型，大规模定性分析

优化结果的方法。在小规模环境下，经过对比，如图4-3，实际消息

数与我们的模型分析结果一致。

针对消息队列压力过大的问题，我们对比配置了 nova-conductor 的两种 API 模式，由 rpc 改为 local 模式;

另一方面，notification driver 配置为 noop。这些措施一定程度上减少了消息队列的负荷。同时，我们结合源

码对测试数据进行分析，先从源码中汇总创建过程中出现的 rpc 方法，再根据涉及的 rpc 类型估计相应的消息数

目，最后得到关于创建请求产生的消息总数的计算模型，通过分析测试过程中 RabbitMQ 产生的的 trace 日志，

可以获取实际消息数目。但考虑到大规模创建对 RabbitMQ 的压力，我们采取的是小规模（按照 1:2 的比例为

每个计算节点创建云主机）定量验证模型，大规模定性分析优化结果的方法。在小规模环境下，经过对比，如图

4-3（连线是模型值，点是实际值），实际消息数与我们的模型分析结果一致。

图 4-3：消息模型验证结果（连线是模型值，点是实际值）

结果表明，消息总数和计算节点数紧密相关，会随着计算节点规模的增加而迅速增加，分析发现主要消息来

源是 neutron-server 向 linuxbridge agent 发送 l2 population 和安全组信息的广播涉及的两个方法：

securitygroups_member_updated 和 add_fdb_entries。例如 600 个节点会产生千万级别 [注 1] 的消息经由消

息队列处理，而 l2 population 和安全组的消息占这个消息总数的 90%以上。因此我们将这两类消息进行了剥

离，以减轻 RabbitMQ 的负担，图 4-4 中我们对比了这两类消息剥离前后的消息数量。我们从 100 到 600 节点

的场景，分别进行了 6 轮测试，梯度为 100。图 4-4 和图 4-5 中的监控数据说明了在大规模场景下，剥离前后

图4-3 消息模型验证结果（连线是模型值，点是实际值）

结果表明，消息总数和计算节点数紧密相关，会随着计算节点规

模的增加而迅速增加，分析发现主要消息来源是neutron-server

向linuxbridge agent发送l2 population和安全组信息的广播

涉及的两个方法：securitygroups_member_updated和add_

fdb_entries。例如600个节点会产生千万级别 [注1] 的消息经

由消息队列处理，而l2 population和安全组的消息占这个消息

总数的90%以上。因此我们将这两类消息进行了剥离，以减轻

RabbitMQ的负担，图4-4中我们对比了这两类消息剥离前后的消

息数量。我们从100到600节点的场景，分别进行了6轮测试，梯度

为100。图4-4和图4-5中的监控数据说明了在大规模场景下，剥

离前后消息数目的变化，可以看到图4-4中，由于RabbitMQ压力

过大，甚至有一段时间出现无法采集RabbitMQ数据的情况。消息数目的变化，可以看到图 4-4 中，由于 RabbitMQ 压力过大，甚至有一段时间出现无法采集 RabbitMQ 数

据的情况。

图 4-4：100 到 600 节点 1:20 创建云主机场景下剥离前消息速率描述

图 4-5：100 到 600 节点 1:20 创建云主机场景下剥离后消息速率描述

通过分析 OpenStack 服务的行为，我们可以成功评估所需消息队列节点的规模，并对未来集群规模做科学

的制定和规划。

注 1：受限于观测手段，图 4-4 示例中的数据采集时每个节点上的云主机数为 2。因此大规模 1:20 环境的

消息数会根据实际情况为图示数据的 10 倍左右。

4.4 数据库负载及优化对比

前文描述过，在并发创建的时候，由于 neutron 在分配 IP 地址时，会发生严重的资源争抢，这在高并发下

会导致请求缓慢，甚至请求超时的错误发生。通过仔细分析，这是由于在 liberty 版本中，IP 地址的分配是通过

select…for update 语句触发，该类语句会在数据库层获取相关行的 intend lock，高并发情况下，同一子网内

的 IP 分配请求都会对该子网所对应的数据库表的 intend lock 进行争抢，从而导致资源忙等超时，在业务层面

就会表现出数据库 deadlock。虽然在业务层面对该类异常进行了重试，但在实际的测试中发现分配成功率并没

有得到太大的改善。

图4-4 100到600节点1:20创建云主机场景下剥离前消息速率描述

图4-5 100到600节点1:20创建云主机场景下剥离后消息速率描述

通过分析OpenStack服务的行为，我们可以成功评估所需消息队

列节点的规模，并对未来集群规模做科学的制定和规划。

注1：受限于观测手段，图4-3示例中的数据采集时每个节点上的

云主机数为2。因此大规模1:20环境的消息数会根据实际情况为

图示数据的10倍左右。

4.4 OpenStack组件数据库负载分析及优化

前文描述过，在并发创建的时候，由于neutron在分配IP地址时，

会发生严重的资源争抢，这在高并发下会导致请求缓慢，甚至请求

超时的错误发生。通过仔细分析，这是由于在liberty版本中，IP地

址的分配是通过select…for update语句触发，该类语句会在数据

库层获取相关行的intend lock，高并发情况下，同一子网内的IP分

配请求都会对该子网所对应的数据库表的intend lock进行争抢，

7


从而导致资源忙等待超时，在业务层面就会表现出数据库 deadlock。虽然在业务层面对该类异常进行了重试，但在实际的测试中发现

分配成功率并没有得到太大的改善。

而在mitaka版本之后， IP分配方式得以改进。更改后的逻辑不再使用select…for update的方式获得结果，而是组合了select语句

配合一个窗口值随机分配IP地址。因为相关的IP分配流程都在内存中进行，这就避免了给IPAvailabilityRanges表加锁，我们更新

(backport)了相关patch，图4-6中对比了修改IP分配逻辑前后的rally测试结果。两张结果对比了更新patch前后并发创建port时的成功

率及耗时。可以看到社区的patch修复效果较为明显，并发创建240个port成功率和耗时上都较修复前有了较大的改进。

而在 mitaka 版本之后， IP 分配方式得以改进。更改后的逻辑不再使用 select…for update 的方式获得结

果，而是组合了 select 语句配合一个窗口值随机分配 IP 地址。因为相关的 IP 分配流程都在内存中进行，这就避

免了给 IPAvailabilityRanges 表加锁，我们更新(backport)了相关 patch，图 4-6 中对比了修改 IP 分配逻辑前

后的 rally 测试结果。两张结果对比了更新 patch 前后并发创建 port 时的成功率及耗时。可以看到社区的 patch

修复效果较为明显，并发创建 240 个 port 成功率和耗时上都较修复前有了较大的改进。

图 4-6：Liberty 原生 vs 社区 patch

但是社区目前的代码中，随机分配 IP 的窗口值是硬编码的，默认值是 10，这在更高的并发测试场景下，仍

然会出现失败的情况，我们通过增加两个配置项来进行更灵活的控制： ipallocation_window_size 、

ipallocation_window_ratio，其中 ipallocation_window_size 指定窗口的静态值，不管待分配子网的大小，IP

都会在 ipallocation_window_size 指定的窗口大小中进行分配，而 ipallocation_window_ratio 会根据子网的

大小按照比例动态计算出窗口大小。

图 4-7 中，对比了不同窗口大小(10,30)对 port 成功率和耗时的影响。从运行结果可以明显看到，在更高并

发测试的场景下（并发创建 500 个 port），相应的提高窗口值会提高分配的成功率。

图 4-7：window size 10 vs window size 30

而在 mitaka 版本之后， IP 分配方式得以改进。更改后的逻辑不再使用 select…for update 的方式获得结

果，而是组合了 select 语句配合一个窗口值随机分配 IP 地址。因为相关的 IP 分配流程都在内存中进行，这就避

免了给 IPAvailabilityRanges 表加锁，我们更新(backport)了相关 patch，图 4-6 中对比了修改 IP 分配逻辑前

后的 rally 测试结果。两张结果对比了更新 patch 前后并发创建 port 时的成功率及耗时。可以看到社区的 patch

修复效果较为明显，并发创建 240 个 port 成功率和耗时上都较修复前有了较大的改进。

图 4-6：Liberty 原生 vs 社区 patch

但是社区目前的代码中，随机分配 IP 的窗口值是硬编码的，默认值是 10，这在更高的并发测试场景下，仍

然会出现失败的情况，我们通过增加两个配置项来进行更灵活的控制： ipallocation_window_size 、

ipallocation_window_ratio，其中 ipallocation_window_size 指定窗口的静态值，不管待分配子网的大小，IP

都会在 ipallocation_window_size 指定的窗口大小中进行分配，而 ipallocation_window_ratio 会根据子网的

大小按照比例动态计算出窗口大小。

图 4-7 中，对比了不同窗口大小(10,30)对 port 成功率和耗时的影响。从运行结果可以明显看到，在更高并

发测试的场景下（并发创建 500 个 port），相应的提高窗口值会提高分配的成功率。

图 4-7：window size 10 vs window size 30

图4-6 Liberty原生 vs 社区patch

图4-7 window size 10 vs window size 30

但是社区目前的代码中，随机分配IP的窗口值是硬编码的，默认值是10，这在更高的并发测试场景下，仍然会出现失败的情况，我们

通过增加两个配置项来进行更灵活的控制：ipallocation_window_size、ipallocation_window_ratio，其中ipallocation_window_

size指定窗口的静态值，不管待分配子网的大小，IP都会在ipallocation_window_size指定的窗口大小中进行分配，而ipallocation_

window_ratio会根据子网的大小按照比例动态计算出窗口大小。

图4-7中，对比了不同窗口大小(10,30)对port成功率和耗时的影响。从运行结果可以明显看到，在更高并发测试的场景下（并发创建500

个port），相应的提高窗口值会提高分配的成功率。

在测试过程中，我们也尝试通过其他的架构来提高数据库的并发事

务能力，我们通过在数据库系统中开启dtrace探针来分析云主机生

成期间数据库的访问行为，例如分析OpenStack不同项目数据库的

访问热度、CUID(create,update,insert,delete)执行比例及耗时等。

图4-8展示了小规模集群下，云主机并发创建期间，OpenStack不

同项目的CUID占比。我们可以看到neutron, nova SELECT读的占

比分别达到82.1%(1972/2400)和62.1%(2356/3790)。

因此，当数据库集群主节点负荷较高时，我们可以通过在数据库

集群和sqlachemy之间增加数据库代理来分发读写请求。当然，

这首先需要在业务层增加额外的代码来帮助数据库代理层识别

读事务与写事务请求，数据库代理会透明的将读事务和写事务分

发到不同的数据库实例上，这可以有效的提高数据库的并发事务

能力。

8


图 4-8：创建过程中 OpenStack 不同项目的 CUID 占比

4.5 优化前后创建请求成功率及耗时

经过 4.2.2 部分参数调优后，集群规模从 100 依次增长到 600 个节点时，由于数据库、RabbitMQ、

OpenStack 组件服务的原因(详细分析见 4.2)，如图 4-9 所示，创建云主机的成功率从 100%逐渐衰减到 80%。

图 4-10（描述 nova-api、nova-scheduler、控制节点 nova 服务向计算节点发送 RPC 消息、nova-compute

这四部分组件级别耗时）对比了相同规模相同压力下，RabbitMQ 和数据库进一步调优前后，按照每个计算点

20 台云主机的比例创建云主机过程的平均耗时。可以看到，随着集群规模增加，创建耗时逐渐增长，当集群规

模增长到 600 个节点时，单台云主机创建平均耗时可达到 600s 左右。在前面 4.2 的基础上，通过对大量日志及

相关监控数据的进一步分析，我们发现 nova-api 等待 neutron-server 返回网络信息时间较长，导致 nova-api

耗时较长，同时，nova-scheduler 处理时间也较长，根源还是在于数据库和 RabbitMQ 的性能限制了云平台处

理请求的能力。

图4-8 创建过程中OpenStack不同项目的CUID占比

4.5 综合优化前后云主机创建请求成功率及耗时分析

经过4.2.2部分参数调优后，集群规模从100依次增长到600个节点

时，由于数据库、RabbitMQ、OpenStack组件服务的原因(详细分析见

4.2)，如图4-9所示，创建云主机的成功率从100%逐渐衰减到80%。

图4-10（描述nova-api、nova-scheduler、控制节点nova服务向计

算节点发送RPC消息、nova-compute这四部分组件级别耗时）对比

了相同规模相同压力下，RabbitMQ和数据库进一步调优前后，按照

每个计算点20台云主机的比例创建云主机过程的平均耗时。可以看

到，随着集群规模增加，创建耗时逐渐增长，当集群规模增长到600

个节点时，单台云主机创建平均耗时可达到600s左右。在前面4.2的

基础上，通过对大量日志及相关监控数据的进一步分析，我们发现

nova-api等待neutron-server返回网络信息时间较长，导致nova-

api耗时较长，同时，nova-scheduler处理时间也较长，根源还是在

于数据库和RabbitMQ的性能限制了云平台处理请求的能力。

经过4.3和4.4部分对RabbitMQ和数据库进行进一步调整优化后，

nova-scheduler调度效率提高了20倍, neutron-server的吞吐提

高了90%。从图4-9可以看到，优化后，并发创建云主机的成功率

几乎不受集群规模的影响，没有明显波动，稳定在100%附近；图

4-10显示，平均创建时间也比优化前也有明显缩短。

经过 4.3 和 4.4 部分对 RabbitMQ 和数据库进行进一步调整优化后，nova-scheduler 调度效率提高了 20

倍, neutron-server 的吞吐提高了 90%。从图 4-9 可以看到，优化后，并发创建云主机的成功率几乎不受集群

规模的影响，没有明显波动，稳定在 100%附近；图 4-10 显示，平均创建时间也比优化前也有明显缩短。

图 4-9：优化前后创建请求成功率对比图4-9 综合优化前后云主机创建请求成功率对比

* q

:

:

: 图4-10 综合优化前后云主机创建耗时对比

第二部分：数据平面性能测试及优化数据平面是指各种IT资源为支撑业务应用运行而设备互联形成的

网络；数据平面从横向上一般可分为前端和后端两部分；前端数

据平面主要是承载业务应用，即用户对业务服务器的访问或业务

服务器之间的交互访问，后端数据平面主要是承载业务数据，即

业务服务器对业务数据的存储和访问。在云环境下，前端数据平

面从纵向上还可以分为物理网络和虚拟网络两部分，物理网络是

指物理设备互联而形成的网络，虚拟网络一般是指虚拟设备互联

而形成的网络，虚拟网络无法独立存在，必须通过虚拟接口并借

助于物理硬件进行承载。在大规模数据中心，后端数据平面目前

有两种主流形态，一种是基于FC SAN的传统集中式存储网络，另

一种是基于IP的分布式存储网络。目前铁信云产品既支持分布式

存储（Ceph），也支持传统集中式存储。

云平台承载业务的性能及运行稳定性最终要落实到数据平面上，针

对前端数据平面的性能测试，本次主要完成了以下2个方面的工作：

（1）云环境下前端数据平面服务器设备物理网络的整体性能及吞

吐量测试，如何优化达到的物理层的极限性能；（2）云环境下前端

数据平面虚拟机承载业务应用的虚拟网络性能，业务应用是由虚拟

机承载的，从虚拟机里面能获取的性能数据，也就是业务应用能获

取到的性能数据。针对后端数据平面的性能测试，本次主要基于分

布式存储Ceph，完成了2个方面的工作：（1）在小规模环境下评估

SSD对存储的IOPS、带宽和延迟等性能的影响；（2）在大规模环境

下评估高并发条件下存储的IOPS性能及其拐点，为今后进行容量

管理提供参考数据。

本部分工作的目的是要通过铁信云在Intel平台上的部署，对基于

Ceph的分布式存储，基于VxLAN的overlay网络方面的性能进行

测试和优化，以此验证Intel产品及技术对云平台的性能支撑，并

为生产环境的部署及配置提供参考和优化方法。

9


本部分前端业务网络的测试验证基于2.3节中介绍的隔离的小规

模测试部署环境；后端存储网络的测试验证，根据不同的测试目

标，分别用到了2.3节中介绍的隔离的小规模测试部署环境和2.2

节中介绍的大规模部署环境。

5 前端数据平面网络性能测试及调优

前端业务网络性能的测试及调优分为2步来进行，首先测试物理

网络性能，调优系统使得物理机到物理机之间的带宽能够打满物

理网卡，为数据平面的虚拟网络提供底层网络保障，第二步是测

试数据平面的虚拟网络，测试虚拟网络的东西向流量带宽在什么

情况下能够达到物理网络的带宽，虚拟机之间的网络速率是多少

以及是否稳定。

对于前端业务网络性能的测试采用2.3节介绍的小规模部署环境，

测试部署如图2.3 所示，具体服务器配置见表2.3。

5.1 物理网络性能

5 .1 .1 测试方法和环境

数据平面采用万兆网卡连接，使用ixia XGS2测试仪产生网络包，

通过一台服务器的某一个万兆端口打入数据，图5.1 为物理网络测

试示意图，测试网卡为Intel® Ethernet Controller X710 6，测试

设置MTU为1500。

192.168.40.112

eno2 eno4

Ixia 测试仪

Ethemet-001 Ethemet-002

图5.1 物理网络测试示意图

为了让物理机之间的带宽能够达到万兆端口的极限带宽，参考Intel®

Ethernet Controller X710优化文档7，我们做了如下优化：

1. 配置IRQ Affinity可以显著的提高网络性能，它使得网络队列上

的中断与不同的CPU Core产生绑定，提供中断处理能力。

首先禁止用户空间态的IRQ Balance

• systemctl disable irqbalance

• systemctl stop irqbalance

再利用i40驱动程序里的脚本set_irq_affinity来设置IRQ

Affinity: [path-to-i40epackage]/scripts/set_irq_affinity -x

all ethX

2. 降低interrupt moderation中的interrupt rate可以提高网络

带宽，同时会带来一定的CPU损耗。

3. 如果网络的丢包率较大，通过ethtool -S ethX观察到rx_

dropped counters 较大，有可能是网卡的ring buffer设置的

不够大，Intel X710默认的ring buffer为512，最大可设置为

4096，这里设置最大值。

4. 操作系统和内核优化设置，增加socket的buffer size：

net.core.rmem_max – max size of rx socket buffer

net.core.wmem_max – max size of tx socket buffer

net.core.rmem_default – default rx size of socket buffer

net.core.wmem_default – default tx size of socket buffer

net.core.optmem_max – maximum amount of option memory

net.core.netdev_max_backlog – how many unprocessed rx

packets before kernel starts to drop them

net.ipv4.tcp_rmem - Memory reserver for TCP read buffers

net.ipv4.tcp_wmem - Memory reserver for TCP send buffers

5 .1 .2 物理网络性能测试结果及分析

测试结果如下表5.1 和表5.2：

表5.1 万兆网卡TCP模式

发包字节数

128 256 512 1024 1280 1518

带宽/Mbps

7798.66 9275.17 9623.85 9808.22 9845.95 9869.74

丢包率/% 0.501 0 0 0 0 0

表5.2 万兆网卡UDP模式

发包字节数

128 256 512 1024 1280 1518

带宽/Mbps

7807.56 9217.42 9623.86 9808.2 9845.95 9869.76

丢包率/% 0.387 0 0 0 0 0

经过优化之后物理机之间的带宽基本接近万兆网卡的理论带宽，

128字节大小的TCP和UDP包的丢包率在0.5%以下，大于128字

节的包的丢包率为0.

5.2 虚拟网络性能

通过对Neutron虚拟网络的东西向流量的测试来观察虚拟网络带

宽相比物理网络带宽的折损率，如何提高虚拟网络总带宽及每对

虚拟机之间的东西向流量带宽和稳定性。

5 .2 .1 测试配置和方法

在两台计算节点上各自部署1-10对CentOS VM(规格见图5.2)，使

用iperf在虚拟机之间进行网络压力测试。基中一台服务器上的虚

拟机作为client端，另一台服务器上的虚拟机作为server端，测试

什么情况下物理服务器的万兆端口带宽打满，以及每对VM之间

的网络带宽。具体见图5.2 VxLAN虚拟网络测试示意图。

10


Eth0: 192.167.10.5

Eth0: 192.167.10.7

Eth0: 192.167.10.14

Eth0: 192.167.10.16

Eth0

Eth0

Eth0

Eth0

Test-1

Test-11

Test-10

Test-20

tapab72fa39-c9

tap825e5e10-3c tap03fbdf58-af

brq17be8eb4-f1

brq17be8eb4-f1

tapea4c3218-b5

vxlan-80

vxlan-80

eno4

eno4

192.168.40.113

192.168.40.114

……

……

共 10 对虚拟机发 tcp 包的配置：2C4G

发 udp 包的配置：12C4G

图5.2 VxLAN虚拟网络测试示意图

Neutron中与东西向流量相关配置为：

1. ML2 LinuxBridge：使用了Neutron LinuxBridge agent作为

L2 agent

2. VxLAN/L2 POP：数据网络使用VxLAN，并打开L2 pop功能。

这里测试2种类型的万兆网卡: Intel® 82598 10 Gigabit

Ethernet Controller 和Intel® Ethernet Controller X710，并把

它们的测试性能加以对比，网卡的主要特性包括硬件offload，软

件加速和I/O虚拟化支持见下表5.3：

表5.3 Intel 82598和X710万兆网卡特性对比

网卡特性 Intel 82598 10 Gigabit Ethernet Controller

Intel Ethernet Controller X710

Tx/Rx IP, TCP, and UDP checksum offloading

支持支持

Tx TCP segmentation offload 支持支持

VxLAN offload 不支持支持

Data Plane Developer Kit (DPDK)加速

不支持支持

虚拟设备队列(VMDq) 支持支持

PCI-SIG SR-IOV 不支持支持

5 .2 .2 测试结果

TCP场景下，Neutron虚拟网络中采用Intel® 82598和 X710

10Gbps分别连接下总带宽如图5.3 所示，虚拟机之间的带宽如图

5.4 所示：

9

5

7

3

1

1 2 4 6 8 10

8

4

6

2

0

虚拟机对数

网卡带 VxLAN Offload 网卡不带 VxLAN Offload

网络总带宽（Gbits/sec）

模式

：T

CP

图5.3 TCP模式网络总带宽

0.2

0.6

1

0.4

0.8

1.2

1 2 4 6 8 10

0

虚拟机对数

网卡带 VxLAN Offload 网卡不带 VxLAN Offload

虚拟机之间带宽（Gbits/sec）

图5.4 TCP模式虚拟机之间带宽

分别使用Intel® 82598 10 Gigabit Ethernet Controller网卡和

Intel® X710网卡进行测试，同样是10G网卡，82598型号不带

VxLAN 硬件offload，而X710型号带VxLAN 硬件offload。

以上测试结果表明在不带VxLAN 硬件offload的网卡上，虚拟网

络的总带宽不到2G，而且随着VM对数的增加总带宽反而下降，平

均每对VM之间的带宽从最大0.9G下降到0.15G。在带VxLAN 硬

件offload的网卡上，随着VM对数的增加，虚拟网络的总带宽也

随之上升，最高可以超过8G，当虚拟网络总带宽达到最大值时，

每对VM之间的带宽也会稳定在0.8-1G之间。

所以，在VxLAN的虚拟网络中，在TCP场景下使用带有VxLAN 硬

件offload功能的网卡可以提升4倍以上的总带宽和6倍以上的VM

之间的带宽。

11


带有VxLAN 硬件offload功能的网卡对于UDP数据同样能取得

很好的总带宽，如图5.5所示最大UDP带宽可达5G，而在不带

VxLAN offload功能的情况下UDP的最大带宽只能达到2G8、9.

最后再看看虚拟网络的带宽和物理带宽之间的比较如图5.6 所

示，采用带有VXLAN硬件offload功能的英特尔® X710网卡来

连通数据平面，在TCP模式下虚拟网络带宽与物理带宽相比为

88%，在UDP模式下相比为53%。

1

3

5

2

4

6

1

0.92

1.91

3.7

4.62

5.05

4.33

2 4 6 8 10

0 0

虚拟机对数

虚拟网络总带宽（Gbits/sec）

模式

：U

DP

9

10

5

7

3

1

TCP

物理机 vxlan

UDP

8

4

6

2

0

万兆网卡带宽

单位

：G

bit

s/se

c

9.3 9.3

8.18

5.05

图5.5 Intel® X710虚拟网络UDP总带宽

6 后端数据平面分布式存储性能测试

后端存储网络性能测试是为了测试铁信云的Ceph存储平面整体

性能和虚拟机访问Ceph的存储性能，为了更好地提供生产环境部

署配置参考和云上业务应用的验证，一方面我们采用小规模的存

储部署用来获取一些基准性能数据，同时通过不同参数的调整得

到一些最佳配置参数，另一方面我们利用第二章中的大规模存储

部署环境用来测试存储系统的可扩展性，寻找整体性能的拐点。

6.1 基于小规模环境的Ceph测试

这里做了2种不同类型的小规模部署测试：

1. SSD盘+HDD盘部署，具体为每台存储节点一块Intel P3700

800G SSD10 闪存硬盘加 8 块 4T 7200 转 HDD硬盘的，其中

SSD闪存盘用作Ceph的日志存储，HDD盘用作数据存储。

2. SSD卡+SSD盘全闪存部署，具体为每台存储节点一块Intel

Optane P4800X 375G SSD11闪存卡加 Intel S3520 800G

SSD12的全闪存配置，其中Intel Optane SSD 作日志存储，

Intel S3520 SSD 作数据存储。

6 .1 .1 测试方法及环境部署

对于Ceph存储的最佳性能测试采用2.3节介绍的小规模部署环

境，测试部署如图2.3 所示，具体服务器配置见表2.3，和网络一

样也从2个方面进行考察：

1. 对Ceph存储的整体数据平面的考察，通过 CeTune13，使用FIO 进

行压力测试，其中在4台COMPUTE节点上部署了FIO测试软件。

2. 对虚拟主机访问Ceph存储的业务平面的考察，把KVM虚拟机

(1 vCPU, 4G vMEM)均匀部署到计算节点，在虚拟机内部通过

CeTune使用FIO进行压力测试.

测试场景如下：

• 4K随机读、随机写

• 128K(SSD卡+SSD盘)和512K(SSD盘+HDD盘) 顺序读、顺序写

• 针对每一种测试场景，测试时间选取 5 分钟左右，在CeTune中

设置的队列深度选取 64。每种测试场景获取：

• 每台客户端的 IOPS、 BandWidth（ MB/s）、 Latency（ ms）

• 所有客户端汇总的 IOPS、 BandWidth（MB/s）、Latency（ ms）

对于4K小数据块着重展现读写IOPS及延迟，对于128K(SSD卡

+SSD盘)和512K(SSD盘+HDD盘)大数据块着重展现读写带宽及

延迟。

6 .1 .2 SSD盘加HDD盘部署测试

我们先来看看在CeTune中设置不同的队列深度(QD)进行整体数

据平面的测试结果。队列深度(QD)代表FIO客户端发送I/O请求

的缓存队列长度，理论上QD 越大FIO发送I/O请求的速度越快。4

台客户机，每台客户机上启动4个FIO进行压力测试，数据为3个备

份，其他Ceph配置详见第10章的附件。

12


2500

3500

1500

500

4K 随机写 4K 随机读

QD8 QD64

4000

2000

3000

1000

0

4K 随机读写 IOPS

3187 32122835

3703

图6.1 4K随机读写IOPS

100

60

20

4K 随机写 4K 随机读

QD8

2.488

88.96

26.341

68.802

QD64

80

40

0

4K 随机读写延迟（ms）

图6.2 4K读写延迟

单个HDD盘的4K随机写的IOPS为300 左右，每台机器8个HDD，

一共4台，数据写入3份，理论IOPS为：8*4*300/3 = 3200，图6.1

上的测试数据显示Ceph上4K随机写的IOPS与理论值基本一致。

从图6.1 可以看出较大的队列深度(QD=64)虽然对于小数据块的

读IOPS有一定的提升，但对于随机写的情况却导致IOPS不及较小

的队列深度(QD=8)，同时如图6.2延迟却相应的大了很多。

600

500

300

100

512K 顺序写 512K 顺序读

QD8

393.836

256.534

519.433

376.357

QD64

400

200

0

512K 顺序读写带宽（MB/s）

图6.3 512K 顺序读写带宽

300

350

400

250

150

50

512K 顺序写 512K 顺序读

QD8

40.2362.427

238.035

338.173

QD64

200

100

0

512K 顺序读写延迟（ms）

图6.4 512K 顺序读写延迟

在大块512K的情况下(图6.3和6.4)，队列深度从8提高到64对读

写带宽的提升也比较有限，相应的延迟却增加了4-6倍。

针对虚拟机访问Ceph的测试，在每个虚拟机启动一个FIO，同时

KVM虚拟机的cache配置为none。

6000

2000

1 个 VM 4 个 VM 8 个 VM

4K 随机写

47324221 3985

2711

45564824

4K 随机读

4000

0

QD64 4K 随机读写 IOPS

图 6.5 虚拟机访问4K随机读写IOPS

600

800

200

1 个 VM 4 个 VM 8 个 VM

512K 顺序写

410

598 600

338

614

734

512K 顺序读

400

0

QD64 512K 顺序读写带宽（MB/s）

图 6.6 虚拟机访问512K顺序读写带宽

13


如图6.5所示，对于4K随机写，在一个虚拟机中运行FIO就达到

最大总IOPS，随着VM数量的增加总IOPS反而下降，显示SSD盘

+HDD盘的配置部署对于小数据块的IO密集型应用（比如数据

库）的扩展性非常差。

6 .1 .3 SSD卡加SSD盘部署测试

SSD卡加SSD盘的全闪存测试一共部署4个存储节点，每台节点均

采用1块Intel Optane P4800X 375G SSD卡作为Ceph 日志存储

盘， 4块Intel SSD DC S3520 800G SATA盘作为OSD数据盘。

4台客户机，每台客户机上启动4个FIO进行压力测试，数据为2个

备份，其他Ceph配置详见第10章的附件。

250000

350000

150000

50000

4K 随机写

239294

407621

2835 3703

4K 随机读

SSD+SSD SSD+HHD

400000

450000

200000

300000

100000

0


图6.7 4K随机读写IOPS对比

2500

1500

500

大块顺序写

1509

1943

376 519

大块顺序读

SSD+SSD（128K） SSD+HHD（512K）

2000

1000

0

QD64 大块顺序读写带宽（MB/s）

图6.8 大块顺序读写带宽对比

图6.7 为SSD卡+SSD盘与6.2节中SSD盘+HDD盘部署上4K随机

读写IOPS之间的比较，全SSD上4K随机写IOPS 为相应SSD盘

+HDD盘上的84倍 , 4K随机读为110倍。

SSD卡+SSD盘上4K 随机读写的带宽分别可达1. 5GB ps 和

0.98GBps，对于大块顺序读写(图6.8) SSD卡+SSD盘上的128K

的带宽分别可达到1.9GBps和1.5GBps，分别为SSD盘+HDD盘

上512K顺序读写带宽的3.7倍和4.0倍。

60

20

4K 随机写

4.142 2.433

88.96

68.802

4K 随机读

SSD+SSD SSD+HHD

80

100

40

0

QD64 4K 随机读写延迟（ms）

图6. 9 4K随机读写延迟比较

300

100

大块顺序写

8265

238

338

大块 K 顺序读

SSD+SSD（128K） SSD+HHD（512K）

400

200

0

QD64 大块顺序读写延迟（ms）

图6.10 大块顺序读写延迟比较

从图 6 . 9 4 K 随机读写延迟比较可以看出，同样的队列深度

(QD=64) SSD卡+SSD盘上的4K随机写延迟为SSD盘+HDD盘上

的 1/21，相应的读延迟为1/28。

从图6.10 大块顺序读写延迟比较可以看出对于SSD卡+SSD盘

上大块128K的读写延迟与SSD盘+HDD盘上的相比有了很大

的改善但绝对值还是较大，这时由于SSD上大块带宽达到1.5-

2.2GBps，Ceph节点之间的网络延迟加大，可以采用巨帧(jumbo

frame)把 MTU设置为9000，同时加大Ceph节点之间的物理网

络带宽比如升级网卡为25G或者双10G网卡端口绑定来降低Ceph

节点之间的网络延迟。

从虚拟机访问Ceph存储的测试(qemu-rbd)在4台计算节点上启

动12个KVM虚拟机，每个虚拟机里面启动一个FIO来进行压力测

试，设置FIO ioengine=rbd，同时KVM虚拟机的cache配置为

none。与从物理客户机访问Ceph存储(fio-rbd)的IOPS及带宽比

较如下图6.11 和6.12 所示，延迟对比如图6.13 和6.14 所示：

300000

100000

随机写

IOP

S

248195

330666

239294

407621

随机读

qemu-rbd fio-rbd

400000

500000

200000

0


图 6.11 4K随机读写IOPS对比

14


1500

500

顺序写

IOP

S

1355 132415091943

顺序读

qemu-rbd fio-rbd

2000

2500

1000

0

QD64 128K 顺序读写带宽（MB/s）

图6.12 128K顺序读写带宽对比

3

1

随机写

3.105

2.342

4.142

2.433

随机读

qemu-rbd fio-rbd

4

5

2

0

QD64 4K 随机读写延迟（ms）

图 6.13 4K随机读写延迟对比

60

20

顺序写

71.769 72.57882

65

顺序读

qemu-rbd fio-rbd

80

100

40

0

QD64 128K 顺序读写延迟（ms）

图6.14 128K顺序读写延迟对比

从图6.11及6.12可以看出从虚拟机访问Ceph存储的测试(qemu-

rbd) 与从物理客户机访问Ceph(fio-rbd) 存储的IOPS及带宽稍有

降低，主要是因为qemu-rbd测试中的FIO数量(12)要比fio-rbd

测试中的FIO数量(16)要少，这也导致在存储盘的I/O接近极限的

情况下相应的延迟也减小了(图6.13和6.14)。

6.2 基于大规模部署的Ceph测试

我们采用大规模存储部署环境用来测试Ceph存储系统的可扩展

性，寻找整体性能的拐点。采用第二章中描述的部署环境，一共有

117个存储节点，为了测试Ceph Journal部署在不同类型存储介

质上对性能的影响，我们把整个存储池分为低、中、高性能的3个

存储池，分别对应Ceph Journal 部署在HDD盘、SATA SSD盘、

PCIE SSD卡上，所有存储池中的存储盘均为HDD盘，具体划分见

下表6.1:

Pool性能类型

Journal 盘类型

存储节点数量(SAS HDD)

单节点OSD数量

Journal 盘数量

Journal 盘与OSD比

OSD总数

低 1.2T SAS HDD

27 10 未单独配置

N/A 270

中 480G SATA SSD

21 9 3 1:3 189

高 3.2T PCIE SSD

48 8 1 1:8 384

表6.1 大规模部署存储池划分

3种不同性能类型存储池的4K随机读写总IOPS和并发性能拐点

见图6.15 和表6.2：

120000

80000

40000

30 50 100 400200 500300 600

100000

60000

20000

0

虚拟机数量

低性能池随机写

低性能池随机读

中性能池随机写

中性能池随机读

高性能池随机写

高性能池随机读

4K 随机读写 IOPS

图6.15 4K随机读写IOPS

读写类型最大IOPS 并发量拐点

低性能池随机写 26361 400-500

中性能池随机写 45214 30-50

高性能池随机写 111088 30-100持续稳定

低性能池随机读 49802 300

中性能池随机读 31255 30-100持续稳定

高性能池随机读 82239 50-200持续稳定

表6.2 4K随机读写并发拐点

从表6.2 可以看出对于4K随机读写，低性能池需要较大的并发才能

达到最大IOPS，而对于中、高性能池在30个并发量时就可以达到最

大IOPS，并且在并发量持续增大时较好的保持了整体最大IOPS。

对于4K随机读，中、高性能池同样可以在在并发量持续增大时较

好的保持了整体最大IOPS。

3种不同性能类型存储池的512K顺序读写总IOPS和并发性能拐

点见图6.16 和表6.3 :

15


12000

14000

16000

18000

8000

4000

20 30 50 300100 400200

10000

6000

2000

0

虚拟机数量

低性能池随机写

低性能池随机读

中性能池随机写

中性能池随机读

高性能池随机写

高性能池随机读

512K 顺序读写 IOPS

图 6.16 512K顺序读写IOPS

读写类型最大IOPS 并发拐点

低性能池512k顺序写 4667 100-300持续稳定

中性能池512k顺序写 5400 50-200持续稳定

高性能池512k顺序写 10274 30-100持续稳定

低性能池512k顺序读 11150 200-400持续稳定

中性能池512k顺序读 11031 100-300持续稳定

高性能池512k顺序读 16600 50-300持续稳定

表6.3 512K顺序读写并发拐点

对于512K大块的顺序读写，3类不同性能存储池在VM并发量持

续增加时，基本都能较好的保持整体最大IOPS。

第三部分：关键业务应用承载验证业务应用系统一般由WEB服务器、应用服务器和数据库服务器组成，大型业务应用系统通常还包括负载均衡服务器、缓存服务器、通

信服务器、接口服务器等多种类型。在上述所有服务器中，通常情况下数据库服务器因为需要处理和保存业务数据而处于核心地位，因

此如何确保数据库服务器在云平台中高效、稳定运行是我们必须要面对和解决的一个非常重要的问题。目前Oracle数据库是铁路业务

应用中使用最广泛的一种数据库系统，Oracle数据库在铁路业务应用中一般以RAC方式运行。对于关键业务应用承载验证，我们将重

点针对Oracle RAC进行研究。

7 关键业务应用(Oracle RAC)负载性能测试

7.1.Oracle数据库在铁路中的应用

Oracle数据库在铁路行业中被广泛应用在运输管理系统、资源管

理系统、客户服务系统、电子支付平台、资金清算系统、财务管理

系统、综合统计系统、营销决策系统、协同办公系统等关键业务

中，为保证关键数据库的高可靠性和性能，当前大量Oracle RAC

运行在小型机平台上，支撑关键业务的运行。

为满足铁路关键业务向云平台的迁移，需要验证Oracle数据库系

统在云环境下的部署方案及可靠性，并对性能进行评估，为以后

关键数据库迁移到云环境打下坚实的基础。

本次Oracle RAC测试采用基于OpenStack和Ceph的铁信云环境

部署来验证相关的性能，其中Ceph分布式存储服务器采用了全闪

存配置以提高性能，由于Oracle RAC本身提供了高可用性，因此

本次测试不涉及Oracle的高可用性测试。

7.2.Oracle RAC测试部署方案及性能

本次Oracle RAC测试部署图如下图7.1所示：

COMPUTE 1

CEPH1

COMPUTE 2

CEPH2

COMPUTE 4

CEPH4

AaPR[TD35

! * 5T_ W 5T_W D35

! A_T]Ec PRZn ) D35 D35(

5

D35 BdQ[XR BaXePcT

! D46 5T_W D35( or

! D35 D35(

D35

! D35 AaPR[T D35 D35(

a64 e5BGp ,*9 D35 (.9

! D35 AaPR[T D35 D35( , *

a64 )( e5BGp/, D35 -,9

AaPR[TD35

! * 5T_ W 5T_W D35

! A_T]Ec PRZn ) D35 D35(

5

D35 BdQ[XR BaXePcT

! D46 5T_W D35( or

! D35 D35(

D35

! D35 AaPR[T D35 D35(

a64 e5BGp ,*9 D35 (.9

! D35 AaPR[T D35 D35( , *

a64 )( e5BGp/, D35 -,9

RAC 1

…

…

RAC 2

Controller1

… … …

2X10Gb NIC

2Xvirtio vNIC

2X10Gb NIC

TPCC 性能测试工具

2 个 RAC 节点集群• 16-32vCPU• 64-96GB 内存• Oracle 12C

4 个计算节点集群

• Intel® Xeon® E5-2699 v4

• 128GB 内存

• 1 块 Intel® S3510 240G安装操作系统

3 个控制节点集群


• 256GB 内存


4 个 Ceph 节点集群


• 128GB 内存


OSD1 OSD1 OSD1OSD8 OSD8 OSD8

• 1 块 Intel® P4800X 375G SSD 做日志盘

• 4 块 Intel® S3520 800G 做数据盘

• 每块 S3520 两个 OSD

图7.1 Oracle RAC测试部署

Hammer DB

16


具体部署方案如下：

• 4台Ceph节点构建成一个Ceph集群，提供计算节点上运行的

RAC所需的共享存储；

• 通过OpenStack（3台控制节点集群）在计算集群上生成两台虚

拟机RAC1和RAC2（两台虚拟机分别运行在集群中的两台不同

计算节点上，缺省在Compute 1和Compute 2上），两块虚拟

网卡提供RAC所需的Public和Private网络；

• 通过RBD接口将Ceph中生成的磁盘挂到计算节点上运行的两

台RAC1和RAC2虚拟机中（QEMU）；

• 在RAC1和RAC2中分别部署HammerDB测试软件

在实际测试过程中，采用两种配置来评估RAC的性能：

• 缺省配置：安装RAC节点后的Oracle缺省配置。RAC1和RAC2

挂载一块日志盘和一块数据盘，用于HammerDB测试的日志和

数据存储，16个vCPU，64G vMEM，每个RAC节点实际只使用

了28G的SGA+PGA。

• 优化配置：安装RAC节点后Oracle优化配置。RAC1和RAC2

挂载6块日志盘和4块数据盘，用于HammerDB测试的日志和

数据存储，32个vCPU，96GvMEM，每个RAC节点使用76G的

SGA+PGA。

下面分别描述两种配置情况下的HammerDB的测试结果。

7 .2 .1 缺省配置的Oracle RAC性能

在缺省配置下，分别在RAC1和RAC2上运行HammerDB，基于

500个warehouse运行64个virtual user进行压力测试，每个

virtual user负责100000个transaction，测试的交易吞吐量如

下图7.2所示：

图 7.2 缺省配置交易吞吐量

TPM 的峰值可达到 120 万左右，平均稳定在 100 万左右。利用 NMON 监测 RAC1、RAC2 和 Ceph 某一

节点的资源使用状况，数据如下图 7.3：

RAC1 RAC2 Ceph 节点

图7.2 缺省配置交易吞吐量

TPM的峰值可达到120万左右，平均稳定在100万左右。利用

NMON监测RAC1、RAC2和Ceph某一节点的资源使用状况，数

据如下图7.3：

RAC1 RAC2 Ceph节点

图 7.3 RAC1、RAC2 和 Ceph 资源使用率

其中 vdc 是一块 RAC1 和 RAC2 共享的 Ceph 日志盘，vdd 是一块 RAC1 和 RAC2 共享的 Ceph 数据盘。

从 NMON 资源监控图上基本可以确认 RAC1 和 RAC2 的 CPU 和磁盘资源接近饱和，网络还有比较大的余量，

但 Ceph 存储节点的资源消耗很小，还有很大的资源来支持更多的压测。当前配置下，提高 SGA 的大小，加入

更多的磁盘来分担 Oracle 数据库对日志的写入性能以及加入更多的 RAC 节点对 TPM 应该还有一定的提升。

在该种配置情况下，平均 100 万的 TPM 值，基本能满足大部分的业务应用对 Oracle 的性能要求。

7.2.2 优化配置的 Oracle RAC 性能

在优化配置下，对缺省配置下的 Oracle RAC 实例进行如下优化设置：

l 每个 Oracle RAC 实例所在的虚拟机的 CPU 从 16 增大到 32，内存从 64G 增大到 96G（由于虚拟机所

在物理机内存为 128G，因此无法提供更多的内存供虚拟机使用，实际生产部署上建议更大的物理机内

存）

l Oracle RAC 实例的 SGA 区和 PGA 区分别从 20G 和 8G 增加到 60G 和 16G

l 日志盘由原来的一块 Ceph 盘增加到 6 块 Ceph 盘，并形成一个 Oracle ASM 的 Disk Group，在其上

针对两个 Oracle RAC 的实例分别建立三个日志文件。数据盘由原来的一块 Ceph 盘增加到 4 块 Ceph

盘，形成一个 Oracle ASM 的 Disk Group，在其上建立一个Oracle Tablespace，用于存储 HammerDB

图7.3 RAC1、RAC2和Ceph资源使用率

其中vdc是一块RAC1和RAC2共享的Ceph日志盘，vdd是一块

RAC1和RAC2共享的Ceph数据盘。从NMON资源监控图上基本

可以确认RAC1和RAC2的CPU和磁盘资源接近饱和，网络还有比

较大的余量，但Ceph存储节点的资源消耗很小，还有很大的资源

来支持更多的压测。当前配置下，提高SGA的大小，加入更多的磁

盘来分担Oracle数据库对日志的写入性能以及加入更多的RAC节

点对TPM应该还有一定的提升。

在该种配置情况下，平均100万的TPM值，基本能满足大部分的业

务应用对Oracle的性能要求。

7 .2 .2 优化配置的Oracle RAC性能

在优化配置下，对缺省配置下的Oracle RAC实例进行如下优化

设置：

• 个Oracle RAC实例所在的虚拟机的CPU从16增大到32，内存

从64G增大到96G（由于虚拟机所在物理机内存为128G，因此

无法提供更多的内存供虚拟机使用，实际生产部署上建议更大

的物理机内存）

• Oracle RAC实例的SGA区和PGA区分别从20G和8G增加到

60G和16G

• 日志盘由原来的一块Ceph盘增加到6块Ceph盘，并形成一个

Oracle ASM的Disk Group，在其上针对两个Oracle RAC的

实例分别建立三个日志文件。数据盘由原来的一块Ceph盘增

加到4块Ceph盘，形成一个Oracle ASM的Disk Group，在其

上建立一个Oracle Tablespace，用于存储HammerDB的压测

数据。

分别在RAC1和RAC2上运行HammerDB，基于500个warehouse

运行64个virtual user进行压力测试，每个virtual user负责

100000个transaction，测试的交易吞吐量如下图7.4所示：

17

白皮书 | 中国铁路基于Intel架构超大规模OpenStack行业云的性能优化研究的压测数据。

分别在 RAC1 和 RAC2 上运行 HammerDB，基于 500 个 warehouse 运行 64 个 virtual user 进行压力测

试，每个 virtual user 负责 100000 个 transaction，测试的交易吞吐量如下图 7.4 所示：

图 7.4 优化配置交易吞吐量

TPM 的峰值可达到 160 万左右，平均稳定在 135 万左右。相对缺省配置，性能提升大概在 30%-40%左右。

Oracle RAC 节点的 CPU 利用率如下图 7.5 所示：

:

图7.4 优化配置交易吞吐量

TPM的峰值可达到160万左右，平均稳定在135万左右。相对缺省

配置，性能提升大概在30%-40%左右。Oracle RAC节点的CPU

利用率如下图7.5所示：

图 7.5 Oracle RAC 节点的 CPU 利用率

从上图可见，CPU 的平均利用率基本在 50%以上，还有一定的余量来进行更大的压测，但总体 CPU 利用

率已经较高（物理服务器是 2 路 Intel Xeon E5-2699 V4 的处理器，每个处理器 22 核 44 线程，每个处理器自

带 64G 内存，因此 96G 内存的分配已经需要跨物理 CPU 访问，因此 NUMA 方式下性能提升的幅度有限）

利用 NMON 监测 RAC1、RAC2 和 Ceph 某一节点的资源使用状况，数据如下图 7.6：

RAC1 RAC2 Ceph 节点

图7.5 Oracle RAC节点的CPU利用率

从上图可见，CPU的平均利用率基本在50%以上，还有一定的余

量来进行更大的压测，但总体CPU利用率已经较高（物理服务器

是2路Intel Xeon E5-2699 V4的处理器，每个处理器22核44线

程，每个处理器自带64G内存，因此96G内存的分配已经需要跨物

理CPU访问，因此NUMA方式下性能提升的幅度有限）

利用NMON监测RAC1、RAC2和Ceph某一节点的资源使用状况，

数据如下图7.6：

RAC1 RAC2 Ceph节点

图 7.6 RAC1、RAC2 和 Ceph 资源使用率

其中 vde-vdj 是六块 RAC1 和 RAC2 共享的 Ceph 日志盘，vdk-vdn 是四块 RAC1 和 RAC2 共享的 Ceph

数据盘。从 NMON 和 HammerDB 资源监控图上基本可以确认 RAC1 和 RAC2 的 CPU 利用率平均在 50%以上，

日志盘和数据盘使用率平均在 40%左右，内存和网络还有一定的余量，但 Ceph 节点的资源消耗很小，还有很

大的资源来支持更多的压测。

在优化配置情况下，平均 135 万的 TPM 值，相对缺省配置有 30%-40%的性能提升，而且加更大的压力时应该

还能提升 TPM 的性能指标。

8 总结和展望

通过上述 3 部分的工作，对铁信云在控制平面、数据平面及关键业务承载等方面的测试和优化，检测出性能

瓶颈并加以优化，发挥硬件平台的极限性能，全方位的验证了铁信云的性能和稳定性，也给平台的生产环境部署

提供了参考，Oracle RAC 作为铁路信息系统的关键业务应用，在上述云平台的测试也验证了铁信云为中国铁路

信息系统提供足够的性能和稳定性支撑，并为业务应用的迁移提供了参考。

在第一部分的控制平面性能测试和优化中，我们采用了两个主要方案，一是在单一 region 下部署大规模节

点数验证规模部署能力，二是压力测试，以准确地定位铁信云在大规模批量创建云主机过程中出现的各种问题。

: ，

图7.6 RAC1、RAC2和Ceph资源使用率

其中vde-vdj是六块RAC1和RAC2共享的Ceph日志盘，vdk-

vdn是四块R AC1和R AC2共享的 Ceph数据盘。从NMON和

HammerDB资源监控图上基本可以确认RAC1和RAC2的CPU利

用率平均在50%以上，日志盘和数据盘使用率平均在40%左右，

内存和网络还有一定的余量，但Ceph节点的资源消耗很小，还有

很大的资源来支持更多的压测。

在优化配置情况下，平均135万的TPM值，相对缺省配置有30%-

40%的性能提升，而且加更大的压力时应该还能提升TPM的性能

指标。

8 总结和展望

通过上述3部分的工作，对铁信云在控制平面、数据平面及关键业

务承载等方面的测试和优化，检测出性能瓶颈并加以优化，发挥

硬件平台的极限性能，全方位的验证了铁信云的性能和稳定性，

也给平台的生产环境部署提供了参考，Oracle RAC作为铁路信息

系统的关键业务应用，在上述云平台的测试也验证了铁信云为中

国铁路信息系统提供足够的性能和稳定性支撑，并为业务应用的

迁移提供了参考。

在第一部分的控制平面性能测试和优化中，我们采用了两个主要

方案，一是在单一region下部署大规模节点数验证规模部署能力，

二是压力测试，以准确地定位铁信云在大规模批量创建云主机过

程中出现的各种问题。然后利用特征提取、分类汇总以及定量定

性分析法，确定了主要问题，并通过优化配置和完善部署结构，解

决了操作系统、消息通信、数据库以及OpenStack组件等问题，

使铁信云平台可以管理更大规模的物理主机环境，并能稳定运

行，我们取得了如下部署建议：

• 操作系统方面，我们调整了最大文件描述符、最大线程数，以提

高单个系统吞吐能力;数据库方面，我们调整了openfile限制，

调大了查询缓存,以提高数据库节点的整体性能;OpenStack方

18


面，我们根据自身环境情况做了RPC相关的服务配置优化，以缓

解服务端压力。

• 通过把Neutron里的两种数量最大的消息（L2 Population 和

Security Group Update）转移到其他消息队列集群上，可以减少

RabbitMQ集群上的消息量，可以有效提高云主机创建成功率。

• 从捕捉到的数据库负载中，我们可以看出，时间占比上，

Keystone、Nova、Neutron是最主要的数据库消耗者，而

Keystone可以通过缓存减少对token的查询；Nova和Neutron

中的绝大多数操作是读请求，Neutron读数据的总耗时超过

自身总耗时的80%。将Galera Cluster替换成Mysql Group

Replication，可以有效提高数据库的吞吐能力。

通过调整，我们实现了铁信云在单region部署600台计算节点，基

于此在云平台上创建10万台云主机（如图8.1），用来验证配置的

有效性。

然后利用特征提取、分类汇总以及定量定性分析法，确定了主要问题，并通过优化配置和完善部署结构，解决了

操作系统、消息通信、数据库以及 OpenStack 组件等问题，使铁信云平台可以管理更大规模的物理主机环境，

并能稳定运行，我们取得了如下部署建议：

l 操作系统方面，我们调整了最大文件描述符、最大线程数，以提高单个系统吞吐能力;数据库方面，我

们调整了 openfile 限制，调大了查询缓存,以提高数据库节点的整体性能;OpenStack 方面，我们根据

自身环境情况做了 RPC 相关的服务配置优化，以缓解服务端压力。

l 通过把 Neutron 里的两种数量最大的消息（L2 Population 和 Security Group Update）转移到其他

消息队列集群上，可以减少 RabbitMQ 集群上的消息量，可以有效提高云主机创建成功率。

l 从捕捉到的数据库负载中，我们可以看出，时间占比上，Keystone、Nova、Neutron 是最主要的数

据库消耗者，而 Keystone 可以通过缓存减少对 token 的查询；Nova 和 Neutron 中的绝大多数操作

是读请求，Neutron 读数据的总耗时超过自身总耗时的 80%。将 Galera Cluster 替换成 Mysql Group

Replication，可以有效提高数据库的吞吐能力。

通过调整，我们实现了铁信云在单 region 部署 600 台计算节点，基于此在云平台上创建 10 万台云主机（如

图 8.1），用来验证配置的有效性。

图 8.1：创建 10 万云主机截图

本部分的铁信云测试除获得上述经验外，还取得如下经验：

: 种类

: 的

: 了

: 的

: 的

图8.1 创建10万云主机截图

本部分的铁信云测试除获得上述经验外，还取得如下经验：

• 实现了memcache高可用故障切换，解决Keystone的token查

询转移到缓存后控制节点故障切换失败问题

• 摸索了不同数量并发用户批量创建相同规模云主机的效率，试

验结果说明，批量创建同样数量的云主机，通过在单个API中批

量创建更多数量云主机，效率更高

• Vxlan网络的引入不仅需要将L2 Population的流量剥离，也需

要注意Vxlan网络规模大小适中，另外FDB表刷新机制值得进

一步优化

• 建议在生产应用中，不要出现超卖的情况

在第二部分的数据平面的测试中，通过对VxL AN虚拟网络及

Ceph存储测试和优化，我们基本达到了设备的物理性能极限，并

得到如下部署配置建议：

• 云平台的租户前端数据网络与后端存储网络分离，并分别采用

10G网卡连接，对于租户数据网络采用带有VxLAN硬件卸载功

能（offload）的网卡。

• 建议把数据库放置在高性能磁盘（SSD盘或PCIE-SSD卡）上，

避免在大规模的场景下，磁盘成为数据库读写的瓶颈。测试数

据表明，PCIE-SSD卡的性能卓越，对于提升存储读写性能效果

明显。

• 建议把系统日志放在独立的高性能磁盘（SSD盘或PCIE-SSD

卡）上，避免日志的读写影响到应用的性能。

在第三部分通过在云平台部署和测试Oracle RAC，验证了铁信云

平台为铁路信息系统上使用Oracle数据库提供足够的性能和稳

定性支撑。鉴于Oracle RAC对计算、存储、网络以及大内存的需

要，未来业务应用的迁移建议考虑如下配置：

• 采用全闪存的Ceph存储作为Oracle RAC的共享日志和数据

盘，并为日志和数据配置多块Ceph盘以提供更大的存储带宽和

访问性能；

• 采用4路或以上配置高主频的高性能Intel Xeon处理器提供更

多的计算处理能力；

• 单颗CPU的直连内存建议128G或以上，建议考虑256G

• 至少双端口10G网卡，建议考虑4端口10G网卡或双端口25G或

40G网卡

本次测试为铁路超大规模行业云部署设计和实施提供了经验，并

且为将来进一步提高规模边界指明了研究方向。

9 致谢

中国铁路信息技术中心的高明星组织了本次实验，北京中铁信科

技有限公司的饶伟等、北京云途腾科技有限责任公司的赵瑾阳等

参与了本次实验。英特尔的龚智、胡明月和金运通组织了这次与

中国铁路的合作。英特尔的梁冰撰写了本案例研究，陈绪和王庆

对本文进行了编辑，胡伟和宋毅梁对本文进行了审阅。

19


10 附件及参考资料

10.1 附件

本次测试验证的相关测试配置及原生测试数据均已放置到以下GitHub上：

https://github.com/yuntongjin/ChinaRailwayPoC

10.2 参考资料1 https://wiki.openstack.org/wiki/Rally2 http://www.rabbitmq.com/firehose.html3 http://open-falcon.org/4 http://flume.apache.org/5 http://dtrace.org/blogs/6 https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-x710-brief.pdf7 https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/xl710-x710-performance-tuning-

linux-guide.pdf8 https://www.mirantis.com/blog/openstack-neutron-performance-and-scalability-testing-summary/9 https://eezhova.github.io/mos-neutron-perf-results/shaker_reports/shaker_intel_6/udp_l2.html10 https://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/ data-center-ssds/dc-p3700-

series.html11 https://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/data-center-ssds/optane-dc-

p4800x-series.html12 https://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/data-center-ssds/dc-s3520-

series.html13 https://github.com/01org/CeTune

此处提供的信息可随时改变而毋需通知。请联系您的英特尔代表以了解最新的计划书和路线图。

英特尔技术特性和优势取决于系统配置，并可能需要支持的硬件、软件或服务才能激活。实际性能会因您使用的具体系统配置的不同而有所差异。任何计算机系统都无法提供绝对的安全性。更多信息，请见Intel.cn，或从原始设备制造商或零售商处获得更多信息。

英特尔公司2017年版权所有。所有权保留。英特尔、英特尔标识和英特尔至强是英特尔在美国和/或其他国家的商标。

*其他名称和品牌可能属于其它公司的财产。

中国铁路基于intel架构超大规模 openstack行业云的...

Documents