云原生场景下的Ceph企业级实践（附云原生平台存储性能评估白皮书下载）

Posted 2021-05-03 灵雀云

导语：

存储服务是所有应用运行的基础。随着云原生技术的日益普及，存储服务需要增加哪些特性来支撑容器化应用，刚刚兴起的云原生存储领域又面临着哪些机遇和挑战？来自灵雀云的运维总监周铁砚将以Ceph为例，从企业应用的角度出发，分享云原生场景下Ceph如何在企业落地。

云原生存储的前世今生

讲云原生存储之前，我们先了解一下什么是云原生（Cloud Native）。Cloud，云是和本地相对的，应用跑在云端，包括公有云、私有云以及混合云；Native，表示为云而生的设计，设计应用之初就要考虑到应用将来是运行在云环境里面的。云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论，同时还包含一系列工具。

接下来再介绍一下12-Factor，它是由Heroku创始人Adam Wiggins首次提出并开源，是开发此类应用的理想实践标准。它定义了一个优雅的云端应用在设计过程中需要遵循的一些基本原则，和 Cloud-Native 有异曲同工之处。

那么如何构建应用程序才符合云原生标准？它需要符合上述12条最佳实践原则，这里面包括基准代码，一份代码在多个环节上同时去做部署，它的配置和代码是分离的，这里面后端服务就跟存储的关系很大。它并没有把后端作为一种服务来对待，并不会区分这个服务是在公有云还是在私有云，也不区分服务是远程还是本地，这就是云原生的一个特点，它是一个无序、无状态、不共享的服务。

存储是云原生里面非常关键的一部分。目前对于无状态的应用已经非常成熟了，有非常好的平滑扩展能力，但对于有状态的应用，还有很大提升的空间。

K8s本身具备跟存储相关的能力，就是CSI插件。为什么会引入CSI插件呢？是因为如果我们把所有存储的代码能力都写到开发代码里面的话，是非常复杂的，所以用in-tree和out-of-tree 的方式对预定插件进行解耦。这个插件基于 K8s的标准，包括两个组成部分CSI Controller 和CSI Node。Controller是跟K8s相关的工作节点，与Controller Manager进行通信，把存储的能力引入到K8s集群里面；CSI Node是把存储的能力和存储的内容引入到真正使用的Pod节点上，它的架构是非常简单的，如果想在云原生平台中引入一个第三方存储，比如Ceph或者其他企业级存储，是很简单的事情，代码量非常少。

我们也在关注云原生技术的落地情况。在前不久云原生技术实践联盟（CNBPA）发表的“第三期（2020-2021）云原生技术落地调研报告”中显示，72.7%的受访企业已经在生产环境中采用K8s作为容器编排技术，这足以证明，在中国K8s已经完全进入主流市场。同时，云原生存储的重要性也相应地逐渐提高。

 

存储是K8s的基石

容器和K8s推动了云原生基础设施的发展，借助CNCF 的landscape，我们可以看到已经有大量的企业在将自身的存储能力引入到K8s，简单地做一个分类，一种是老牌存储厂商，比如NetApp，它的实现方式是通过trident插件，跟我们上面讲的CSI插件相结合，成为K8s的一个资源，如果我们想在K8s里创建一块存储，只用一条简单的命令就好，另外一类是新兴的存储厂商，也具备同样的能力，且随着新兴存储技术开始逐渐步入商业化阶段，这类厂商也慢慢影响了存储行业的格局。

云原生的发展借助了K8s的力量，可以说存储是K8s的基石。我们运行一个程序的时候，一般用到4种资源：计算、内存、存储、网络，这里我们可以看到存储在整个资源的最底层，在云原生领域对存储的重视程度是非常高的。

如何判断云原生存储的价值？我们总结了以下几点：

1、适用场景：每个企业对存储的使用场景都是不同的，有的是数据库类型，有的是文件类型，也有归档，如果我们希望通过单一的技术去解决这些复杂的使用场景，是不现实的；

2、可靠性：数据是不可再生资源，不允许丢失，因此企业对于存储可靠性的重视程度是相当高的；

3、性能：我们认为，性能只要足够满足企业的应用需求即可，不必过分追求高性能，世面上流行的高性能解决方案往往是各种资源组合调试到最优进而呈现出的效果，不论是标准CPU内存还是网络存储，它的性能都是有阶梯性的；

4、易维护性：如果某个存储产品的易维护性很差，或者对技术能力要求很高的话，对用户来讲其实是不太友好的，这样的产品也很难做到大面积覆盖用户；

5、成本：成本固然重要，但相对于可靠性而言就显得不那么重要了，一个可靠性差数据易丢失的方案，成本再低也不会有人用，所以企业级的存储方案通常会全盘考虑。

云原生存储的企业级实践

接下来讲一下存储在云原生领域的落地。Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统，具备大规模、高性能、无单点失败的特点。Ceph 是一个软件定义的系统，可以运行在任何符合其要求的硬件之上。通常，维护Ceph集群有一定的复杂性，Rook就是为此而生。Rook是 CNCF迄今为止13个毕业的项目之一，灵雀云目前的云原生存储实践的一部分就是基于Rook来实现的。

Rook 是一个可以提供 Ceph 集群管理能力的 Operator。Rook 使用 CRD 控制器来对 Ceph 之类的资源进行部署和管理，可以简化大量针对Ceph存储的操作和维护工作。

理想很丰满，但在实际的使用场景中还是会遇到下面的这些问题，尤其是在一些大规模和超大规模的使用场景下。

1、Rook社区的发版一直都是跟随 Ceph的发版在向前走，只是把Ceph的新能力纳入到云原生环境里，并不像Ceph是有自己非常完整的roadmap，全盘去考虑自己的发版进程；

2、如果日常使用中遇到问题，经常会遇到Ceph社区跟Rook社区“互相甩锅”的情况，比如我们遇到过一个比较典型的场景，MDS在Pod上使用会有内存益出的问题，Ceph社区认为是你的资源不够，但Rook 社区则认为他们并没有考虑这是在容器的使用场景下，这是非常有意思的；

3、在使用中我们发现，Rook的重启率是非常高的，而传统的Ceph的启动频率不是那么高，所以就数据丢失的风险而言Rook要比Ceph高一些；

4、Rook对管理复杂度要求很高。在我非常精通Ceph的时候，也无法很好地去运维一个Rook 环境，因为K8s本身是有技术壁垒的，对K8s技术的掌握程度成为了运行好Rook的关键。

上面这张片子里，右半部分是在 GitHub上面的一个片子的截图，介绍Rook在哪些生产环境上已经开始被采用，我们可以看到，即使Rook存在这样那样的问题，大家对这个项目的热情也还是很高，说明企业对云原生存储的需求是非常强烈的。

基于云原生平台的Rook的功能需求，一个是通用化配置的需求，我们当前对于Ceph或者Rook的管理基本上都是通过命令行去管的；第二是对图形化监控的需求，当我们发现故障，很难通过简单的命令去对整个环境有一个比较好的判断，所以监控比如Prometheus的引入是非常重要的；第三，因为Rook本身有些问题，它的数据可靠性，比如基于传统Ceph的副本数，这些都要在Rook上重新去做衡量；最后是日常运维管理，这可能是当前将Rook引入到企业级平台里面的一个非常大的挑战。

 

云原生存储性能评估白皮书

最后介绍一下灵雀云基于英特尔傲腾非易失性内存设备和Rook以及Open CAS缓存加速方案进行的存储性能评估测试。

我们通过模拟数据库的使用场景进行基准测试，引入了一组面向生产环境的复杂基准测试集CockroachDB和HammerDB，并将它们容器化部署在K8s集群中，此外还引入CosBench对象存储基准。

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

1、SSD直接作为存储引擎BlueStore的单独分区；

2、SSD作为BlueStore的主数据分区，而BlueStore的元数据 (RocksDB和WAL) 部署在内存设备上；

3、SSD和内存设备通过Open CAS缓存软件组合成新的CAS设备作为BlueStore的主数据分区，BlueStore的元数据 (RocksDB和WAL) 部署在内存设备上。

通过三种方式的比较，最终的结论是第三种部署方式的吞吐性能和延迟会有一个比较大的改善，有接近3倍的吞吐量的提升，延迟降低了34.2%。

感谢中国开源云联盟、Ceph中国社区和英特尔中国的帮助，这个云原生存储白皮书才得以面世。欢迎大家下载和讨论。

后台回复“0429”

即可下载《云原生平台存储性能评估白皮书》

 

相关阅读：