Ceph是一个开源的分布式对象,块和文件存储。该项目诞生于2003年,是塞奇·韦伊的博士论文的结果,然后在2006年在LGPL2.1许可证发布。Ceph已经与Linux内核KVM集成,并且默认包含在许多GNU / Linux发行版中。
当前的工作负载和基础设施需要不同的数据访问方法(对象,块,文件),Ceph支持所有这些方法。它旨在具有可扩展性,并且没有单点故障。它是一款开源软件,可以在生产环境,通用硬件上运行。
RADOS (可靠的自动分布式对象存储)是Ceph的核心组件。RADOS对象和当今流行的对象之间存在着重要的区别,例如AmazonS3,OpenStackSwift或Ceph的RADOS对象网关提供的对象。从2005年到2010年,对象存储设备(OSD)成为一个流行的概念。这些OSD提供了强大的一致性,提供不同的接口,并且每个对象通常驻留在单个设备上。
Ceph分为三大块,分别是对象存储、块设备存储和文件系统服务。在实际运营中,如何发现和解决关键的存储问题?尤其是随着规模的扩大与业务的几何级数的扩张,存在运维中不可预测的问题,如何提前预判和防治?
在我们的大量的客户案例中,我们遇到了,同时也帮客户规避了大量的风险。如果您要自建Ceph集群,以下是一些需要考虑的错误配置场景。
错误 #1 – 选择不佳的日志或缓存硬盘
在构建 Ceph 集群时,尤其是带有 HDD的集群时,您需要使用一个SSD作为日志或者缓存,它通常用来存储一些关键的数据(例如预写日志和元数据又或者是bluestore中的wal与db)。这也是为大多数存储场景提高性能的最经济有效的方法。
通常,大部分人会使用商业品牌服务器(用于启动引导盘)的 M.2 SATA 接口作为日志驱动盘。问题是大多数 M.2驱动盘仅推荐用于安装操作系统,从而用于系统启动,并且只有 1DWD(每天写入量)范围内的耐用性。尤其是对于filestore而言, Ceph使用预写日志和元数据的方式,这些可能很快就会耗尽。
如果您要坚持使用 M.2 端口,有些设备厂商可以定制化调整配置,从而增加ssd的读写耐用性。
错误 #2 – OSD使用 RAID
在某些情况下,这比较难解决的,尤其是对于使用英特尔至强架构的非密集型的 HDD 服务器。然而,RAID 功能在 Ceph集群的上下文中没有过多的作用。如果您必须要使用 RAID的话,请将其配置为 RAID-0。当然,在理想的情况下,您也可以找到一个以直通模式运行的 RAID控制器(JBOD,磁盘直通)。
如果您无法摆脱使用 RAID 控制器,您还应该注意以下两点:
不然,您肯定会遇到问题。我们在生产环境中已经遇到过很多次了。
另外,附带说明一下,这些服务器还往往带有很长的电缆,这代表了额外的物理故障点。大部分情况下,故障都会很容易处理,但在某些时候,线缆松动的情况下,它会造成维护方面的一些麻烦。
错误 #3 – 将 MON 守护进程与 OSD 放在同一台主机上
在Ceph正常运行的 99%场景中,监控服务的负载压力很小。但是,当您的集群处于繁忙或者故障时,例如硬件出现故障以及数据重新均衡时,它的工作将变的异常繁忙以及重要。此时,您的监视器MON会清理您的集群数据,以确保您返回的内容与您存储的内容一致。毕竟,Ceph的最核心的宗旨就是“我们不会丢失数据”。在故障期间,监视器会执行校验和,这需要大量的计算能力。它还可能执行将一个OSD迁移数据到另外一个OSD的任务,此时您的OSD也会更加繁忙地工作。最后,它负责一些选举的任务,这就是为什么通常有奇数个监视器的原因。这里记录(是“Ceph监视器经常将其数据从内存刷新到磁盘,干扰 Ceph OSD 守护进程的工作负载”的问题。
因此,当您构建一个最小规模的集群(通常为 3 台主机)并且其中一个出现故障时,整个集群也会崩溃,后面我们会简单讲解一下。
最好的解决方案是配置单独的监视器和存储服务守护程序。在实际生产中,大部分情况下,我们都没有从MON与OSD混合放在同一台主机中获得多少好处。如果您担心硬件资源的浪费,一种潜在的替代方法是将它们放在虚拟机中。这也是一个更好的选择,即独立了服务,也节省了资源。
错误 #4 – 错误地设置 min_size 和副本大小
将 min_size 设置为 1 并将副本大小设置为 2 是大部分人都喜欢的配置 。它看起来类似于服务器的RAID1,因为,这样可以让系统在副本降级的状态下运行,并且在数据副本恢复的过程中依然保留比较好的效率。
但请记住——Ceph不希望您丢失数据。这意味着当你读时,它会检查以确保你写的数据仍然是你写的。同时,这些结果都需要在多个副本之间进行同步与比较。当没有副本可供比较时,Ceph认为您不能再信任何 read ,它即不会让你写也不会再让你读。整个系统都被锁定了。因此,如果此时随便一块磁盘脱机,即使是暂时的,集群也将停止访问与使用故障OSD 关联的归置组。同样,使用 min_size 1,很容易出现重大问题,它没有法子保证Ceph数据的一致性。
如果您需要增加可用存储容量,另一种选择是使用纠删码。您可能会牺牲一些性能,但可以获得更高的存储效率,而不会冒大量数据无法访问的风险。
错误 #5 – 高密的服务器更好
更密集的服务器、更密集的驱动器、更密集的 CPU – 这样您就可以降低服务器、PCB、CPU 和网络的成本,对吗?
事实证明,当您在集群中使用基于复制或纠删码的数据保护机制时,最好将数据带宽分布范围扩大。在 CPU中——更密集意味着更多的时钟周期浪费和更大的功率预算,这会对您的机柜和功率容量产生额外影响。对于 25KW功率的机架来说可能没什么大不了的,但是当您的机架功率低于 8KW 时绝对是一个问题,这也是大部分机柜的标准水平。
但最大的问题是故障范围。假设您使用了3台高密的服务器来构建了一个最小可行集群。每台有最高配置的60快盘,每个盘的容量为18TB。如果从单个osd盘中恢复丢失的数据需要 1 天,那么从丢失的一台服务器中恢复数据将需要 2 个月。哪怕是迁移物理磁盘也不起作用,因为 OSD必须在新服务器中重新创建。在那个时候,如果您丢失另一个盘或服务器,这时候可能就会扩大故障,甚至丢失数据。
总结
拥有强大而活跃的 Ceph用户社区是保持Ceph项目持续发展的关键。但是这并不意味着大家可以放心的使用Ceph。反而,我们更应该关注Ceph的使用场景以及相关的运维方案。架构以及安装一个安全可靠的Ceph集群也变的至关重要。
Ceph确实有无限扩容的能力,但需要良好的初始规划,否则扩容过程也会出现一些问题。
在某些场景下,Ceph有些浪费硬件,成本核算时要考虑多一些。因此,如何合理去配置副本数,OSD数至关重要。不合理的规划除了资源浪费外,也可能导致性能问题,尤其是在副本恢复或者数据均衡的时候。
Ceph的优化方式很多,但一定要选择有效且合理的优化方式。