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的优化方式很多，但一定要选择有效且合理的优化方式。