行业研究|灵雀云发布云原生平台的存储性能评估白皮书

导语：

本研究在中国开源云联盟和Ceph中国社区指导下，由灵雀云基于英特尔傲腾非易失性内存设备和Rook以及Open CAS缓存加速方案测试并发布。

前言

可能你遇到过下面的场景：

1.你们公司刚刚购买了英特尔傲腾存储硬件，你设计了一个加速业务的使用场景，觉得用起来还不错，但是需要有个全方位的性能评估报告。

2.你负责维护一个大型的存储集群，引入了新的缓存架构对系统存储的瓶颈进行优化，你首先要要设立一个基准并搭建一套快速易用的评估工具，并且可以反映出当前主流的工作负载。

3.你是一名运维工程师，为了提升效率，研发团队引入了集群取代原有的闭源部署方案，很多业务都开始向云原生转换，运维系统也需要将一些基准测试工具容器化。原有的存储系统如何跟容器化的业务和基准测试工具无缝集成？

希望本篇白皮书介绍的基于容器平台的存储性能的评估方法有助于您解决类似的问题。

项目简介

以容器为代表的云原生技术作为一类新型基础设施，是支撑着企业数字化建设的重要支撑技术。云原生逐渐在人工智能、大数据、边缘计算、5G 等新兴领域崭露头角，成为驱动数字基础设施的强大引擎。

Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统，具备大规模、高性能、无单点失败的特点。Ceph 是一个软件定义的系统，可以运行在任何符合其要求的硬件之上。通常，维护Ceph集群有一定的复杂性，Rook就是为此而生。Rook 是一个可以提供 Ceph 集群管理能力的 。Rook 使用 CRD 控制器来对 Ceph 之类的资源进行部署和管理，可以简化大量针对Ceph存储的操作和维护工作。

本测试基于灵雀云ACP3.0全栈云原生开放平台。ACP 3.0是以为核心的云原生技术打造的新一代全栈混合云平台，包括 5条产品线、16大子产品，涵盖了云原生基础设施、云原生应用架构、云原生、云原生数据服务和云原生数智五大平台。全平台采用容器原生架构，以为底座和控制平面，支持一键部署、自动运维，持续升级，并具备开放、灵活、可扩展等特性。

ACP3.0可通过 的存储类对接不同类型的存储资源，全面支持 Ceph、NFS等存储系统。平台还提供超融合的集群内存储方案——内置存储。内置存储是一种高度可扩展的分布式存储解决方案，支持中小规模存储需求的块存储、文件存储能力。内置存储采用开源的 Rook 存储方案，并进行深度定制，实现了一个可自动管理的、自动扩容的、自动修复的分布式存储服务。

典型场景基准测试

在存储业界广泛使用的微基准测试程序比如FIO、等，这些微基准测试工具配置灵活，模式简单，可以在某个配置下快速验证单个性能，比如4K大小的随机读写等，但是它们不能反映出复杂生产环境下的真实负载。模拟复杂的基准测试填补了这一缺憾，它定义了特定的工作负载模型，通过操作数据库的方式模拟出各种基准场景，并且这些模拟的行为是可以重现的。

总的来说，微基准测试和模拟复杂基准测试系统可以互为补充，它们使用的条件和情况也有所不同。模拟复杂基准测试适合在下面几个场景下使用：

·综合评估存储系统。评估系统的性能天花板，瓶颈以及查找可能存在的缺陷。这个场景相对复杂，本篇白皮书暂不讨论。

·引入新解决方案或重要功能。比如更换新的硬件，存储系统的重大版本升级，引入新的解决方案架构或者将原来的系统切换到新的系统中。本篇白皮书会重点讨论其中的两个场景。

· 客户要求。客户有在线的业务场景，我们需要模拟这些场景来进行相关的优化。

我们为此引入了下面一组面向生产环境的复杂基准测试集和，并将它们容器化部署在集群中。此外我们引入对象存储基准，对象存储在云平台上需求日益旺盛，根据IDC的数据显示，企业级数据中的80%是非结构化数据，而75%将会存放到对象存储上。

以为代表的容器环境越来越广泛的部署在生产环境中，本白皮书提供了容器环境下的典型场景，基于新硬件（英特尔傲腾非易失性内存硬件）和新的解决方案（Open CAS缓存框架）对分布式存储系统Rook-Ceph及上层业务的加速。

下表简要介绍了我们选取的几个典型基准测试。

场景框架

容器化的环境下，通过Rook部署Ceph集群，Ceph集群的存储服务OSD有三种部署方案：

· SSD直接作为存储引擎的单独分区

·SSD作为的主数据分区，而的元数据 (和WAL) 部署在英特尔傲腾非易失性内存设备上

·SSD和傲腾非易失性内存设备通过Open CAS缓存软件组合成新的CAS设备作为的主数据分区，的元数据 (和WAL) 部署在傲腾非易失性内存设备上。

傲腾非易失性内存可以手工创建为块设备直接使用，但是需要管理维护的成本。在环境下可以通过存储容器接口（CSI）自动管理，PMem-CSI（针对傲腾非易失性内存的CSI驱动）提供面向容器的存储卷类型，此存储卷可以作为Ceph 的元数据分区。同样，Ceph通过Ceph-CSI（Ceph的容器存储接口）提供RBD块设备给上层容器应用。我们选取的基准测试程序以应用服务的方式部署，通过Ceph提供的RBD块服务及Ceph的对象网关来评估新傲腾硬件和新缓存框架的性能提升。

Open CAS是英特尔开发的缓存加速方案，通过加载内核的方式，将高速介质盘作为缓存，和慢速盘 “融合” 为一块盘使用，从而提高系统整体的磁盘读写性能。

性能评估环境软硬件环境

针对上面的典型场景，我们搭建一套兼容性的环境，包含硬件和软件配置。在服务器端，以Rook Ceph为核心的存储集群提供块存储和对象存储服务；在客户端部署基准测试程序，基于块存储和对象存储之上运行工作负载。这套软硬件环境在灵雀云实验室完成搭建和测试。

硬件配置

– CPU

2 * Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz

1 * Intel(R) Xeon(R) 8280L CPU @2.70GHZ

– 内存

16 * 32 GB

– 傲腾非易失性内存

4 * 128 GB

– SSD

3 * SSD 730 800 GB

– 网络交换机

1 Gb/s

软件配置

– 操作系统

Linux 7.8.2003

– 内核版本

Linux 3.10.0-1160.6.1.el7.

– 版本

19.03.9

– 版本

1.18.13

– Ceph版本

15.2.2

– Ceph集群

3服务节点和1客户端(和服务节点共享物理节点)

– Rook版本

1.3.3

– Open-CAS版本

20.06.00.

– 版本

20.1.1

– 版本

3.3

– MySQL版本

8.0.19

– 版本

0.4.2

场景

– OSD个数

6 (SSD:OSD=1:2)

– RBD大小

200 GB

– Data分区

400 GB

– + Wal 分区

6 * ? GB 傲腾内存（手工创建）

– Cache

6 * 20 GB 傲腾内存（PMem-CSI）

基准测试

– 模式

Bank, MOVR和YCSB with drop

– 测试时间

300秒

– 工作负载

TPC-C with VU=8

– 测试时间

300秒

– 工作负载

with 70% Read and 30% Write

–

100

–

500

–

18

– size

4 KB

– 测试时间

1200秒

Rook-Ceph存储集群

首先部署三个节点的集群，Rook-Ceph基于集群之上通过Rook 将Ceph的各个模块以Pod的形式部署在各个节点上，在这里我们部署1个客户端和3个Ceph的服务节点，其中某一个Ceph服务节点和客户端共享一个物理节点，这样体现了部署的灵活性。

Rook也支持Ceph部署在两个网络上，公共网络和集群网络 (使用主机网络) 的配置可以通过 的方式，也可以通过定义Ceph集群的yaml网络配置 (功能不太成熟稳定)，我们采用第一种方式。

客户端上以 Pod的形式部署三种基准测试程序。对于块存储，通过在yaml里定义m向Ceph集群以Ceph-CSI的方式申请；对于对象存储，以S3 API的方式向Ceph 对象网关获取对象。

需要注意的是Rook集群的OSD的配置有两种方式：

· 直接定义每个节点上的设备路径。这种方式简单，适合轻量部署的场合，但扩展性不太好，而且不支持远端的公有云存储。

· 通过PVC (m) 的方式，需要定义PVC模板，然后填充每个OSD类型所需的即可。这种方式扩展性好，支持本地和远端的各种存储。

我们定义了的三个分区的PVC模板，分别对应data, block.db和block.wal分区，每个分区对应一种类型的，如果通过PVC能申请到相应大小的块设备，就创建成功，组建一个新的OSD组件服务。本样例中，我们通过local-内置类型创建了多个PV ( )，然后PVC选取符合大小的PV就可以绑定成功。

对于客户端块设备的获取，标准方式是通过存储容器接口 (CSI) 的方式，Rook的部署目前支持Ceph-CSI，正常的加载过程需要确保两个条件：

· CSI服务，包括插件和驱动正常运行，默认Rook会启动CSI服务

· 创建对应的: rook-ceph-block，其中配置项是: rook-ceph.rbd.csi.ceph.com

性能数据和对比分析场景测试数据

Unit

1

2

Bank

Ops/sec

504.4

648.8

1494.5

(ms)

437.8

340.9

149.7

MOVR

Ops/sec

233.2

248.3

258.8

(ms)

4.3

3.9

YCSB

Ops/sec

50766.5

51287.7

57635.6

(ms)

4.4

4.4

3.9

mysql TPCC (vu8)

TPM

7718

8535

10578

NOPM

2544

2844

3525

4K – Size

(70% Read – 30% Write)

Read Time (ms)

4.27

4.36

4.35

Read (op/s)

2589.33

2813.52

3198.58

Write Time (ms)

18.8

16.25

13.07

Write (op/s)

1107.46

1207.04

1371.9

从测试结果来看，-2的结果最好，-1的其次，最差，这是符合我们的预期。是个基线值，它完全基于传统SSD搭建的Ceph集群；而-1在Ceph OSD 的元数据+Wal侧使用傲腾非易失性内存做了加速；-2配置在-1基础上，在Ceph OSD 的Block主数据分区使用Open-CAS缓存框架使用傲腾非易失性内存做了缓存设备的加速。-2相比配置带来的提升最多的情况下可以达到的2.96倍吞吐，延迟也最多能减少到的34.2%。

下面的两幅图分别表示原始数据柱状图和归一化的柱状图比较，可以更直观的看到性能带来的提升。

总结和展望

容器平台下，搭建Rook-Ceph存储集群，并且使用英特尔傲腾非易失性内存对Ceph OSD端的元数据及OpenC-CAS缓存框架对主数据分区的加速，采用模拟真实生产环境的基准测试工具包括, TPC-C及对Ceph的块存储服务和对象存储服务性能进行评估，发现不同的工作负载模式下，提升的程度有所差异，最高吞吐量提升可以达到原来的2.96倍，延迟也可以缩减到原来的34.2%。

基于的容器环境在生产环境中部署的越来越广泛，而模拟真实环境的复杂基准测试是常规微基准测试的有效补充，在集中特定场景下可以有效全面的评估系统的性能，特别是对联机数据分析，订单系统等真实应用有很好的参考意义。

参考资料

Rook官网及：://.com/rook/rook

工作负载：

TPC官网：

官网：

：

附录基准测试与工作负载存储的工作负载

对于一个存储系统来说，评价性能好坏的有几个标准单位。

· IOPS：每秒钟的处理IO请求数。

·吞吐量（MB/s）：单位时间内的读写数据量。

·响应时间/等待时间：处理一个请求的时延，包括从发送请求到接到响应的时间。

而对于底层的存储介质来说，主要的操作就是读和写，还有一些文件系统元数据的操作。而读写根据地址空间的访问模式分成随机访问和顺序访问。随机访问的逻辑地址/物理地址是不可预测的，而顺序访问是根据当前的逻辑地址依次访问。

读写请求的块大小也对系统的性能有影响。一般来说，小块的请求更看重IOPS或响应时间，大块的请求以吞吐量为考量。

底层存储还有个重要因素就是队列深度，就是在端口队列中等待服务的I/O请求数量。适当增大队列深度，可以测出磁盘的峰值，但IOPS不会随着队列深度的增加而一直增加，达到一定峰值后会有所下降。对于IO请求的等待时间，随着队列深度的增加而增大。

根据请求块大小，顺序随机访问读写模式的不同，存储负载可以可以分成几个典型的类型：

·数据库 (OLTP)：也叫联机事务处理，表示事务性非常高的系统，以小的事务以及小的查询为主。负载类型以小块的随机（随机约占80%）写（读25%，写75%）为主，主要评估响应时间。

·数据仓库 (OLAP)：也叫联机分析处理，支持复杂的分析操作，侧重决策分析，并且提供直观易懂的查询结果。负载类型以大块顺序（顺序约占80%）读（读75%，写25%）为主，主要评估吞吐量。

·视频数据采集：负载类型以大块顺序写为主。

·虚拟桌面基础架构：负载类型以小块的随机读写（读50%，写50%）为主。

·物联网：负载类型以混合大小块的顺序写为主。

现实世界的负载要比这些典型的负载模型复杂的多，我们选取复杂基准测试是为了更真实的模拟生产环境中的负载，来指导我们对系统的评估和改造。

综合复杂负载 —

是一个可伸缩，跨区域复制，并支持事务，高可用性和高度一致性的分布式SQL数据库。它带有内置的负载生成器，用于模拟不同类型的客户端工作负载。下面列出几个常用的负载。

·Bank (银行)：使用货币平衡表为一组账户建模。

·KV (键值)：在整个集群中均匀随机地读取和写入键值对。

·MovR：模拟MovR示例应用程序的工作负载。MovR是一家虚构的车辆共享公司，旨在展示功能。这个负载的数据集包含6个数据库表，模拟的操作按照比例如下图所示：

·TPCC：使用多个丰富的图表模拟联机事务处理工作负载。

·YCSB：使用其他自定义功能，模拟大量读，写或基于扫描的大规模键值工作负载。

的负载还在不断的增加中，这些内置的负载操作简单、模式丰富，是快速验证的综合复杂基准测试的最佳选择之一。

联机事务处理与联机分析处理 —

是基准测试和负载测试套件，支持当前流行的数据库、SQL 、IBM DB2、MySQL、、和Redis等。它支持基于TPC-C和TPC-H的工作负载，但是支持的TPC-C/TPC-H和标准的TPC-C/TPC-H测试数据集略有不同，它更灵活轻量。

TPC被称为事务处理性能委员会，负责定义诸如TPC-C、TPC-H、TPC-W等基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试想昂木发布客观的性能数据。

TPC-C是衡量OLTP（联机事务处理）的系统工业标准，是行业中公认的最权威和最复杂的在线事务处理基准测试。它通过模拟仓库和订单管理系统，测试广泛的数据库性能，包括查询、更新和队列是小批量业务。TPC-C基准测试的评价是一种模拟订单录入每分钟商业事务 (tpmC)吞吐量。

TPC-C的测试模型是一个大型批发销售公司，在地里分布的多个区域有业务，并且使用仓库管理。当业务扩展的时候，公司将添加新的仓库，每个仓库负责10个区域的供货，每个区域3000个客户服务，每个仓库维护10万种商品的库存记录。

它包含五种不同类型和复杂性的并发事务的混合体，这些事务可以在线执行或排队等待延迟执行。这五种事务包括：

·新订单：客户输入新订单交易，占比45%。

·付款：更新账户余额以反映其付款状态，占比43%。

·交货：批量交易，占比4%。

·订单状态：查询客户最近交易的状态，占比4%。

·库存级别：查询仓库的库存状态，以便及时补货，占比4%。

TPC-H是决策支持基准，也叫OLAP（联机分析处理）基准，它是在TPC-D上发展起来并取代了TPC-D，它模拟决策支持系统中的数据库操作，测试数据库系统复杂查询的响应时间，以每小时执行的查询数(TPC-H QphH@Siz)作为度量指标。

在TPC-H模型中，定义了8张表，22个复杂查询()和2个更新(带有和的程序段)操作，被测试数据库的数据量从1GB～有8个级别供用户选择。测试时，将22个查询随机组成查询流，2个更新操作组成一个更新流，查询流和更新流并发执行数据路访问，查询流数目随数据量增加而增加。

数据库的应用一般有两种：以TPC-C为代表的联机事务处理和以TPC-H为代表的数据挖掘/联机分析处理。TPC-C的结果对于数据库系统有一定的参考价值，银行、证券、税务报税系统、电子商务网站、电信业务都是比较典型的联机事务处理应用。TPC-H的结果针对决策分析，也具有普遍的商业实用意义，目前在银行信贷分析和信用卡分析、电信运行分析、税收分析、烟草行业决策分析中都有广泛的应用。

基准测试配置文件

基准分成两个部分：测试套件和数据库 (本例中使用MySQL)。我们定义了一个TCL脚本来自动执行命令行配置和相应工作负载的运行：

#!/usr/bin/tclshproc runtimer { seconds } {set x 0set timerstop 0  while {!$timerstop} {        incr x after 1000  if { ![ expr {$x % 60} ] } {  set y [ expr $x / 60 ]  puts "Timer: $y minutes elapsed"  } update if {  [ vucomplete ] || $x eq $seconds } { set timerstop 1 }    }return}puts "SETTING CONFIGURATION"dbset db mysqldbset bm tpc-cdiset tpcc mysql_driver timeddiset tpcc mysql_rampup 0diset tpcc mysql_duration 1vuset logtotemp 1loadscriptputs "SEQUENCE STARTED"foreach z { 1 2 4 8 16 32 64 } {puts "$z VU TEST"vuset vu $zvucreatevurunruntimer 300vudestroyafter 5000}puts "TEST SEQUENCE COMPLETE"

基准基于Rook Ceph的Rados ，至于在Rook下详细设置的方式参考：

支持Web UI的方式，直接将xml格式的负载配置文件上传即可自动加载运行。的配置文件我们定义了对象大小4K和1M的，4K的配置文件如下所示：

Rook-Ceph下PVC方式配置OSD

示例配置文件如下：

volumeClaimTemplates:- metadata:    name: data  spec:    resources:      requests:        storage: 64Gi    # IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, gp2)    storageClassName: local-ssd    volumeMode: Block    accessModes:      - ReadWriteOnce- metadata:    name: metadata  spec:    resources:      requests:        storage: 5Gi    # IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, io1)    storageClassName: local-pmem    volumeMode: Block    accessModes:      - ReadWriteOnce- metadata:    name: wal  spec:    resources:      requests:        storage: 5Gi    # IMPORTANT: Change the storage class depending on your environment (e.g. local-storage, io1)    storageClassName: local-pmem    volumeMode: Block    accessModes:      - ReadWriteOnce