你是否在自建Ceph 集群中,犯过这五个错误?
存储 存储软件
Ceph是一个开源的分布式对象,块和文件存储。该项目诞生于2003年,是塞奇·韦伊的博士论文的结果,然后在2006年在LGPL 2.1许可证发布。Ceph已经与Linux内核KVM集成,并且默认包含在许多GNU / Linux发行版中。

本文转载自微信公众号「新钛云服」,作者祝祥。转载本文请联系新钛云服公众号。

Ceph是一个开源的分布式对象,块和文件存储。该项目诞生于2003年,是塞奇·韦伊的博士论文的结果,然后在2006年在LGPL 2.1许可证发布。Ceph已经与Linux内核KVM集成,并且默认包含在许多GNU / Linux发行版中。

当前的工作负载和基础设施需要不同的数据访问方法(对象,块,文件),Ceph支持所有这些方法。它旨在具有可扩展性,并且没有单点故障。它是一款开源软件,可以在生产环境,通用硬件上运行。

RADOS (可靠的自动分布式对象存储)是Ceph的核心组件。RADOS对象和当今流行的对象之间存在着重要的区别,例如Amazon S3,OpenStack Swift或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 也会更加繁忙地工作。最后,它负责一些选举的任务,这就是为什么通常有奇数个监视器的原因。这里记录(https://docs.ceph.com/en/latest/rados/configuration/mon-config-ref/)是“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的优化方式很多,但一定要选择有效且合理的优化方式。

 

责任编辑:武晓燕 来源: 新钛云服

同话题下的热门内容

技术大比武:让每一个人都是一道光,不断突破与成长

编辑推荐

再谈Raid 5和Raid 6的写性能差异ECC内存和普通内存有什么区别,有必要买ECC内存吗云存储技术的原理是什么?百度网盘技术原理分析分布式存储与传统SAN、NAS相比,有什么优势与劣势?Redis内存淘汰策略,看这一篇就够了!
我收藏的内容
点赞
收藏

51CTO技术栈视频号