基于Kubernetes与云原生的存储测试基准CNSBench

基础知识

如果读者想要更第一手的原材料资源，请参看CNSBench A Cloud Native Storage Benchmark
在介绍正文之前，考虑到面向群众的原因，对后续涉及到的概念进行一些说明解释，这将有助于理解
云计算（cloud computing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云计算早期，简单地说，就是简单的分布式计算，解决任务分发，并进行计算结果的合并。因而，云计算又称为网格计算。通过这项技术，可以在很短的时间内（几秒钟）完成对数以万计的数据的处理，从而达到强大的网络服务。云计算指通过计算机网络(多指因特网)形成的计算能力极强的系统，可存储、集合相关资源并可按需配置，向用户提供个性化服务。

现阶段所说的云服务已经不单单是一种分布式计算，而是分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗杂和虚拟化等计算机技术混合演进并跃升的结果。

私有云(Private Clouds)是为一个客户单独使用而构建的，因而提供对数据、安全性和服务质量的最有效控制。该公司拥有基础设施，并可以控制在此基础设施上部署应用程序的方式。私有云可部署在企业数据中心的防火墙内，也可以将它们部署在一个安全的主机托管场所，私有云的核心属性是专有资源。
公有云通常指第三方提供商为用户提供的能够使用的云，公有云一般可通过 Internet 使用，可能是免费或成本低廉的，公有云的核心属性是共享资源服务。这种云有许多实例，可在当今整个开放的公有网络中提供服务。
== 容器化==则是一种应用程序或系统分发方法，它将应用程序或系统及其依赖项与底层基础设施隔离开来。它是一种操作系统级虚拟化，允许用户在容器中部署和运行分布式应用程序或系统，而无需为每个应用程序启动整个虚拟机。
容器有着一个非常重要的作用：保证代码运行环境的一致性
容器通过为应用程序打包和部署提供轻量级、不可变的基础结构来解决应用程序移动到其他环境就无法正常运行的问题，将应用程序或服务、其依赖项及其配置打包为容器映像。容器技术为开发人员和 IT 专业人员只需做出少量修改，甚至不需要进行任何修改，即可跨环境部署应用程序。

至于为什么容器比传统虚拟机要优秀的点在于：
（一）容器比虚拟机更加轻量化
（二）容器实在操作系统级别进行虚拟化，而虚拟机则是在硬件级别进行虚拟化
（三）容器共享操作系统内核，占用的内存对比虚拟机要少很多

云原生（Cloud Native）是基于微服务原理而开发的应用，以容器的方式进行打包。在运行时，容器由运行于云基础设施之上的平台进行调度。应用开发采用持续交付和 DevOps 实践。总结来说云原生就是基于云计算而来的技术，对云计算技术的不断精进和细化。
微服务：传统的大的单体应用拆分为更小的组件或者模块，这个组件或者模块就叫微服务。拆分为纵向拆分，从底层的 IT 基础设施到数据库，到应用中间件，再到软件程序部署包都能做到完全独立，可以单独的进行需求设计、开发、打包和部署，实现各个微服务之间一个彻底的松耦合。同时各个微服务之间又能够通过轻量的 HTTP rest 接口进行交互和协同。总结来说微服务的核心为两点：大的单体拆小、拆小的微服务之间通过接口进行交互和协同。
Kubernetes是Google公司在2014年6月开源的一个容器集群管理系统，使用Go语言开发，也叫K8S。Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署，规划，更新，维护的一种机制。正确的发音是**[kubə’netis]**

CNSBench的摘要与介绍

CNSBench (github.com) ，文章应用程序的开源地址如前面，读者可以去GitHub仓库中找到。
摘要：
现代混合云基础设施要求软件能够在异构集群之间轻松移植。应用程序容器化是一种经过验证的技术，可以为应用程序的功能提供这种可移植性。然而，为了确保性能可移植性，需要在实际工作负载下对集群的性能进行可靠的验证。这种验证通常是通过对目标环境及其存储进行基准测试来实现的，因为I/O通常是应用程序中最慢的组件。然而，现有的存储基准测试并不适合生成云原生工作负载，因为它们不生成任何存储控制操作(例如，卷或快照创建)，不能轻松地编排大量同时运行的不同工作负载，并且在运行过程中动态更改工作负载特征的能力受到限制。
在本文中，我们提出了第一个云本地存储基准- cnsbench的设计和原型。CNSBench将控制操作与传统存储基准工作负载与用户定义的控制操作工作负载结合起来。由于CNSBench本身是一个云本机应用程序，它本机支持大规模编排不同的控制和I/O工作负载组合。我们为Kubernetes构建了一个CNSBench原型，利用了几个现有的用于数据和元数据I/O生成的容器存储基准。我们通过对Ceph和OpenEBS (Kubernetes上两个流行的存储提供商)的案例研究，展示了CNSBench的有用性，揭示和分析了之前未知的性能特征。

介绍：
基准测试的基本要求是要能够生成实际的工作负载，其结果就能反应将其实际运用之后的性能。因为以下的三个缺点但现有的存储基准测试不足以生成现代云原生环境的工作负载，因此我们提出了基于Kubernetes的CNSBench。
① 云本地存储工作负载包含大量的控制操作，如卷创建、快照等
② 典型的工作群应承载大量不同的且同时运行的工作负载
③ 云原生环境下的应用是高度动态的
启动、停止、扩展、故障转移、更新、回滚等等。这将导致工作负载行为在短时间内发生各种变化，因为每个主机上运行的工作负载的排列发生了变化。尽管现有的基准测试允许配置一个基准测试的单独运行，以生成不同阶段的工作负载，但这样的基准测试并没有提供在单一运行中表示动态的通用方法

Cnsbench针对此完成以下三种改进：
(i) 产生实际的控制操作;
(ii) 协调各种各样的存储工作负载;以及
(iii) 作为基准测试运行的一部分动态改变工作负载。
因此CNSBench可视为可以产生控制操作基准且使在大量容器运行时各部协调的应用。

文章的主要贡献有
1. 我们将确定云本地存储基准测试的需求和独特要求。
2. 本文介绍了CNSBench的设计和实现，这是一个满足上述需求的基准测试，允许用户在实际工作负载的情况
   下方便地大规模地对云本地存储解决方案进行基准测试。
3.我们使用CNSBench来研究Kubernetes的两种存储解决方案(Ceph和OpenEBS)在之前没有研究过的工作负载下
的性能。

在对CNSBench进行介绍之前，需要对它所基于的环境进行介绍。CNSBench相当于是建立在Kubernetes大环境下的适用于云原生的实时快捷的应用程序，且表现良好，具有创新性。

Kubernetes Background

它由控制平面节点、工作节点和存储提供程序(以及其他组件)组成。工作节点和控制平面节点运行P ods，这是由一个或多个容器组成的Kubernetes中最小的工作负载单位。用户工作负载运行在工作节点上，而核心Kubernetes组件运行在控制平面节点上。核心组件包括(1)API服务器，它管理Kubernetes集群的状态，并公开用于访问状态的HTTP端点;(2)调度器，它将Pods分配给节点。通常，一个Kubernetes集群有多个工作节点，也可能有多个控制平面节点以实现高可用性。
存储提供者负责按单个pod的需要以卷的形式提供持久存储。

Kubernetes的工作流程

Pod（Plain Old Documentation）是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。

持久存储也是Kubernetes的工作流程介绍：一个需要存储的Pod产生一个PVC（持久存储声明，persistent volume claim），PVC指明它需要多少存储空间，存储控制面板，工作节点和存储提供程序，和为Pod提供存储所涉及的操作和资源。然后持久卷（PV，persistent volume）由供应商提供。如果存在满足存储请求的现有PV，则使用它。否则，从PVC中指定的存储提供者提供一个新的PV。一旦PV形成了，它就和PVC绑定在一起，卷就被挂在到了Pod的文件系统中。

这里的PVC就相当于是任务清单，告诉你要做什么，然后根据任务清单从存储库中实例化PV，PV就相当于是OS
中进程的PCB，具体对应到工作节点中的最小资源调度单位Pod，PV对其进行管理和说明。但这里资源调度的最
小单位Pod不是说大小最小，而实际上是把它绑定为了一个整体，每次运行都是整体运行调用。

CNSBench提出的需求分析

(i) 控制操作的频率增加;如容器的创建和删除，控制操作的种类也越来越丰富。除了丰富之外，依赖于底层存储技术的控制操作也可能是数据密集型的。这使得它们变慢，并增加了它们对正在运行的应用程序的I/O路径的影响。例如，卷创建通常需要(i)耗时的文件系统格式化;(ii)创建或删除快照，根据存储的设计，可能会消耗大量的I/O流量;卷大小调整，这可能需要数据迁移和更新许多元数据结构;以及(iv)卷重新挂载，这会导致缓存刷新和预热。
(ii) 个人工作量的高度多样性;
应用程序的多样化和工作负载的特殊化使得实际的工作负载生成只能通过手动选择、创建和部署几个适当的容器(例如，运行多个单独的存储基准测试，每个基准测试都模拟单个工作负载的特征)。但是，随着越来越多的各种应用程序采用集装箱化并被分解为专门的微服务集，必须选择的容器数量以组成实际工作负载继续增加。在今天的云原生环境中，手动进行这种选择是不可行的。
(iii) 这些工作量的动态性。
基准测试缺乏在这些高度动态条件下轻松评估应用程序性能的能力。在某些情况下，基准测试用户求助于手动创建这些条件，以评估应用程序的响应方式—例如手动扩展数据库实例[46]的数量。然而，在云原生环境中发现的高度动态和多样性使得手动重新创建这些条件几乎是不可能的。

因此提出了以下五点设计的核心需求

1. I/O工作负载应该独立于控制工作负载指定和创建，以便对(I)不同控制工作负载下的I/O工作负载的性能和(ii)不同I/O工作负载下的控制工作负载的性能进行基准测试。
2. 它应该能够编排I/O和控制工作负载，以模拟代表当今云的动态环境。此外，应该能够生成控制工作负载，作为评估单个控制操作的性能的微基准。
3. I/O工作负载应该通过运行现有的工具或应用程序生成，可以是像Filebench这样的合成工作负载生成器，也可以是像带有流量生成器的web服务器这样的实际应用程序
4. 用户应该能够快速配置和运行基准测试，而不牺牲提供给更高级用户的可定制性。
5. 基准应该能够将来自不同基准的非结构化输出聚集到一个方便的位置，以便进一步分析

CNSBench设计与实现

在介绍完实现背景和需求之后，就来开始介绍正文

CNSBench的示意图

蓝色部分是CNSBench的组件
总体控制流程如下:A基准控制器监视API服务器创建新的基准资源。B当一个新的基准资源被创建时，控制器会创建在基准的I/O工作负载中描述的资源:用于运行工作负载的I/O W orkload P ods和用于运行工作负载的Persistent V volume (pv)的pvc (Persistent V volume Claims)。C为了运行控制操作工作负载，基准包括一个速率生成器，它以用户指定的间隔触发一个动作执行器，以调用所需的控制操作(动作)。

在原有的Kubernetes下，CNSBench实现了基准定义控制器，里面包括对动作、速率的分别控制，对I/O的负载控制等等，并且完成了容器内的封装，需要控制时，在用户端只需要参数输入等友好的使用，减少了大量代码编辑与多次不同工作环境下的多次但不重复的申明工作。CNSBench兼容了很多种基准测试情况，可以让用户更专心地将注意力集中到测试中，而不用理会语法、定义，代码编写等的繁琐工作中。

CNSBench的主要核心有两个：基准自定义资源和基准测试控制器

CNSBench的基准自定义资源

基准自定义资源定义

基准自定义资源允许用户指定三个主要基准属性:(1)控制操作工作负载;(2)运行的I/O负载;(3)输出应该发送到哪里进行收集。
(1) 控制操作工作负载：
CNSBench的主要需求之一是能够创建现实的控制工作负载，使用操作和速率的组合指定控制工作负载，动作和速率被可以地分开，这样可以更清晰地看待问题。
(2) I / O工作负载
通常，基准测试的目标是了解特定工作负载或一组工作负载在各种条件下的执行情况。CNSBench的I/O工作负载组件的作用是实例化这些工作负载，或者实例化具有与实际工作负载相同的I/O特征的合成工作负载。指定这些I/O工作负载需要定义为了运行I/O工作负载而必须创建的所有不同资源(例如，Pods和pvc)。这可能很困难，并使基准测试规范冗长而复杂。
为了减轻用户的负担并帮助他们关注整体基准测试规范，而不是I/ o工作负载的具体细节，CNSBench将I/ o工作负载规范与基准测试规范的其余部分分离开来。I/O工作负载规范是使用configmap定义的，这是一个核心Kubernetes资源，用于存储配置文件和其他自由格式的文本。
因此用户可以使用引用(按名称)要创建的I/O工作负载的创建资源操作来指定要在Benchmark自定义资源中运行哪个I/O工作负载。为了实现跨各种用例和基准的重用，当工作负载由特定基准实例化时，I/ o工作负载规范中的字段可以参数化并指定值。
(3) 输出应该发送到哪里进行收集（基准输出）
收集输出有三个挑战：目前没有一种干净通用的方式从Pods中提取文件；产生输出的运行时间可能很长；很多输出是无结构的文本形式，这使得结果难以分析。
为了解决这些问题，我们允许I/ o工作负载作者指定应该从工作负载Pods中收集哪些文件，并提供解析器脚本来处理输出。解析输出允许将大文件缩小到更简洁的大小，并以标准的方式输出结果。使用helper容器收集和解析输出文件。用户指定将最终解析的结果发送到Benchmark自定义资源的输出部分的何处。结果不需要全部发送到相同的输出。

基准自定义资源实例

6-13：指定了基准测试的I/O工作负载
这样使得I/O工作负载规范可以参数化，以支持它们在不同用例和基准之间的重用。
14-18：指定一个快照卷操作

与其对应的是I/O工作负载工作表和I/O负载图

上图是 样例I/O工作负载规范

上图是 具有单个工作节点和一个PV的Kubernetes集群的子集。显示所涉及的CNSBench资源(I/O W工作负载和基准)，以及由CNSBench控制器根据基准规范创建的核心Kubernetes资源(快照、pvc、PV和工作负载Pods)。

基准测试控制器

基准控制器监视新创建的基准对象并运行它们指定的操作。控制器主要有三个职责:(1)触发控制操作;(2)同步各个基准工作负载;(3)收集各个工作负载的输出。

性能测试与实验

测试环境与内容

每个工作节点是一个拥有4个vcpu、8GB RAM和384GB本地连接存储的虚拟机。控制平面节点为4vcpu、12GB RAM、100GB本地存储的虚拟机。虚拟机主机位于多个机架中，机架通过10Gbps网络连接，单独的主机通过1Gbps链路连接到机架交换机的顶部。

测试了在Ceph和OpenEBS存储供应商平台下，无数据副本，三个数据副本、只运行空存储提供程序和擦除编码模式下的性能

实验结果

为不同的存储提供商配置创建和挂载卷所需的时间的cdf。N为同时创建的卷数量。对于所有存储配置，同时进行卷操作的数量的增加增加了创建和挂载单个卷的平均时间

每分钟创建的体积和附件，用于不同数量的同时操作。每一点的竖线显示该点的卷创建和附着率的标准偏差。

快照对I/O工作负载的影响。R =0表示为0卷副本，R =3表示为3卷副本，R =ec表示为erasure coding

针对不同存储提供商配置的快照创建时间的CDF。
以及在组合情况下的运行数据

对于五种不同存储配置上三种不同比例的I/O工作负载，与基线相比的性能变化。

未来展望

在某些情况下，控制和I/O操作可能交织在一起。例如，I/O操作的增加可能导致工作负载向外扩展，从而执行更多的控制操作。用CNSBench再现这样的事件需要一种反馈机制，将I/O工作负载执行的I/O操作的信息传递给CNSBench。CNSBench的设计和实现并不排除这种机制，但我们将其实现留给了未来的工作。

总的来说，文章就是在云原生的环境中，设计了符号各种平台负载，很好连接并可以进行性能评估的应用。
应用实    现了内部接口，使得生成负载参数化，不需要每次进行繁琐的代码设计编程，且也可以忽略内部
Kubernetes的设计规范，因为内部已经完成了封装，将其考虑进接口中的内部程序了。通过分析，应用更贴近于
现在流行的云原生，且在大环境下具有创造性地提出可广泛应用的性能评估测试应用，使得文章能够在FAST
中脱颖而出。

参考文献

[9]Merenstein A, Tarasov V, Anwar A, et al. {CNSBench}: A Cloud Native Storage Benchmark[C]//19th USENIX Conference on File and Storage Technologies (FAST 21). 2021: 263-276.