如何基于Ceph设计与构建一套软件定义存储系统

段立功

发布于 2022-06-13 11:16:23

6350

发布于 2022-06-13 11:16:23

文章被收录于专栏：云计算之道

目前流行的软件定义存储相关的开源项目主要有GlusterFS、Swift、Lustre和Ceph。这四个项目各有各的特点：GlusterFS提供文件存储，Swift提供对象存储，Lustre主要用在高性能计算，Ceph则基于一套系统提供块、对象及文件功能。

但近年来随着OpenStack的兴起，Ceph由于与OpenStack的良好的集成而受到越来越多的关注。而Ceph本身也以其良好的自管理，横向扩展等特性赢得使用者的关注，成为软件定义存储领域最受欢迎的开源项目。

那么如何基于Ceph来构建一套符合企业业务需求的软件定义存储系统呢？

构建之前

在进行正式的设计和构建之前，一定要调查清楚对存储系统的需求。

首先理解你希望运行的workload的特性. 运行在SDS之上的是结构化数据还是非结构化数据？如果是结构化数据，是OLTP数据库应用还是OLAP数据库应用？如果是非结构化数据，是文件，图片，语音还是视频？

这些问题的答案将帮助你在平衡你的目标特性或者对某些特性更友好：

读 or 写？随机读写 or 顺序读写？读写IO的延时 or 更高的IOPS？存储密度 or 可用性？多点访问存储 or 单点访问存储？单点访问的情况下，是否对单点的突发性能有较高要求。还有，业务是否需要扩展。如果未来需要扩展，提前规划好crushmap, 可以减少未来扩展时的数据迁移。

然后结合你的应用，定义希望达到的的目标特性（性能（包括延时，IOPS，吞吐）、容量、密度、可用性、可靠性、安全等）。请记住，不要预期一套系统满足所有的应用。

- 基于上述答案，构建一套PoC系统。该PoC系统与实际系统的大小比例应该在1：10到1：100之间。

- 对PoC系统进行调优甚至调整，以便达到你要求的性能

- 对该系统进行扩展，并进行持续的性能调优，以保持你的PoC时达到的性能。由于Ceph本身具有易横向扩展的特性，所以在扩展系统时，性能指标会保持一定的稳定状态。

设计架构

1）网络

网络是容易出现分布式存储系统性能瓶颈的所在，因此，选择大带宽的网络往往不会出错。考虑Bond以及交换机的适配，选择1Gb，10Gb，25Gb，100Gb。另外，可能的情况下，采用Jumbo Frames, 会对网络性能带来一定的提升；采用中断亲和特性，可以减少中断对网络传输的影响。

关于网络，要考虑的第二点是Ceph的内部数据网（一般叫Cluster网络）和接受客户端读写的网络（一般叫Public网络）分离。这是因为，Public网络接收外部的IO请求，而Cluster网络承载IO请求到达后，数据在存储节点之间的传输，因此，大量IO的情况容易出现网络带宽瓶颈。

第三，可以考虑将Cluster网络的带宽设计为Public网络的两倍。这是考虑到，分布式存储系统在三备份的情况下，外部数据在写入主备节点后，主备节点会将该数据同时写入第二和第三备份节点；同时，数据在各存储节点之间的re-balance以及recovery都需要消耗Cluster网络带宽。

最后，对性能敏感的场景，Cluster网络和Public网络可以考虑采用InfiniBand+RDMA。虽然Infiniband的成本较高，但是会带来更低的网络延时以及更高的带宽。

2）存储节点的选型：

CPU：Ceph OSD运行RADOS服务，需要通过CRUSH来计算数据的存放位置，复制数据，以及维护Cluster Map的拷贝，需要消耗一定的计算能力。因此，通常建议一个OSD进程对应一个CPU核。

内存：OSD在响应客户IO业务时，通常不需要太多的内存，可以为每个OSD预留500M~800MB内存即可。但在执行恢复操作时，则需要大量的内存。（每OSD进程恢复没TB数据需要约1G内存）。而内存过小会导致OSD占用内存不足。

日志盘：通用场景下，一般采用SSD或者NVMe盘做Ceph的日志盘，以便降低写的延时和提高IOPS。

数据盘：由于数据最终存储到数据盘上，数据盘的个数、容量、性能（转速等）至关重要；另外，一般情况下一个HDD对应一个OSD。

在系统扩容的过程中，增加存储节点的HDD通常是最常见的选择。增加HDD一定会带来容量的增加和冗余性的增强，也可能会带来更高的IOPS和吞吐，但会消耗存储节点更高的CPU，内存及网络带宽，而且会带来更高的缓存竞争的可能性。另外，一般情况下，整存储系统的IO时延会保持不变，不受影响。

当然，扩容存储系统还存在另外一个选择：即增加存储节点。增加存储节点会带来更高的容量、吞吐、IOPS以及更强的冗余性，而时延不受影响。但能够增加节点的个数取决于网络拓扑的限制。另外，增加加点或者增加HDD通常都会带来暂时的数据再平衡，如果不加控制，可能会影响前端业务。

3) OSD文件系统的选择：Btrfs VS XFS

XFS由于稳定，成熟，并且更方面表现均衡，成为生产环境下的首选。Ceph存储系统中另一种文件系统选择是Btrfs。 BTRFS有丰富的特性，如压缩，校验，CopyOnWrite等; 并且，写操作的吞吐量通常更高。但是它的问题是非常消耗CPU。可能在不远的将来，Btrfs会成为更多人的选择。

4）缓存

根据Ceph存储系统的IO路径来看，Cache通常发生在三个地方：Client端，存储节点的OS缓存，存储控制器。

Client端的缓存：虽然对不会影响写的性能，但是对读，尤其是顺序读的性能有非常大的提高。

存储节点的OS缓存：在没有设置Client端缓存的情况下，会对读性能有提高。但是如果已经使能了Client端缓存，对读写性能帮助不大。

存储控制器缓存：对于写性能有很大帮助。但是缓存本身最好有备用电池支持，否则一旦断电，会导致缓存中的数据丢失。

5）Journal

一般情况下，采用SSD或者NVMe SSD作为Ceph的Journal盘，采用HDD盘作为数据盘，会提高并发写或者随机写的性能。但是一旦只存在在Journal盘而没有落到HDD盘的数据超过Journal盘或者分区的大小，性能则会下降到HDD的水平。一般情况，为每个OSD进程和数据盘，设置10G~20GB的SSD分区作为日志。

另外，SSD作为Journal盘，对读性能没有帮助。另外，由于SSD盘会占据硬盘或者PCIe插槽，可能会导致存储密度降低。

6）HDD

选择硬盘一般考虑以下几个方面：

a) 容量。单个硬盘的容量越大，通常会带来总容量和存储密度的增加。但是大容量的单盘的价格往往更贵。

b) 硬盘本身的缓存。由于Journal盘及其他缓存机制的存在，通常磁盘本身的缓存容量的意义不大。

c) 转速。更高的RPM通常会提高IOPS和吞吐，但是也会增加功率消耗。高性能的情况下一般考虑15K RPM的硬盘。

d) SMR。选择SMR硬盘可以提高单盘的容量，但是写性能可能会下降。

7) 冗余：副本 VS 纠删码

副本机制，简单来说，就是保存N个完全相同，与原始数据一致的备份。生产环境下一般选择N=3个副本。采用副本的好处是数据可以利用多个数据源进行恢复，并且在采用类似条带（stripe）技术的情况下，会提高读性能。但是对数据进行N个副本的复制，会降低写吞吐，延长写时延，并增加了Cluster网络带宽的使用率。当然，最大的影响是容量，N=3的情况下导致用户数据的有效容量为物理容量的三分之一。

另一种冗余机制是纠删码，即把数据分为N个部分以及M个校验码。相比副本机制，纠删码具有更高的空间使用率，但其代价是更高的I/O时延和更高的CPU使用率，尤其在数据重建时，需要消耗更高的CPU以及网络带宽。

目前来看，块存储一般不使用纠删码机制。

8) Cache Tiering

Ceph目前支持针对Pool的分层机制，即创建一个3备份的以SSD作为数据盘的缓存存储池，然后创建其他以HDD为数据盘，并且采用纠删码机制的数据存储池。Ceph支持设置缓存池的数据更新到数据池的策略，包括基于相对或绝对的缓存数据量，以及数据的新旧程度。

这种方式很好地结合了副本机制和纠删码机制的优点，但它通常需要复杂的配置以及额外的调优工作。

9） Placement Group数目

PG数，即每存储池中哈希樋（Hash Buckets）的个数。该值通常需要在创建池时指定，并且在存储池的生命周期内不可调整。

如果PG数太大，则会导致更多的Peering，从而占用更多的资源。如果太小，则会导致每个group里有过多的数据，会有过多的hotspots,而数据的条带化不够，从而导致过慢的recovery和re-balance。

关于PG的一个大概的经验公式是：

PG数目的近数 = ((OSD的个数 * 100) / Replica的最大数) / Pool的个数

PG的数目 = 跟上述公式计算出的PG数目的2的N次幂最接近的数

如果对结果不太确定，Ceph专门提供了一个网页，供精确计算PG时使用。