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

目前流行的软件定义存储相关的开源项目主要有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占用内存不足 。

推荐阅读