「精心整理」Ceph搭建硬件建议详解

Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）

Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。因此，OSD应该有合理的处理能力（例如双核处理器）。监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。

除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。我们建议在单独的主机上运行额外的CPU密集型进程。

一般来说，RAM越多越好

监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。

对于小型集群，一般来说，1-2GB就足够了。

对于大型集群，你应该提供更多（5-10GB）。

你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size

Bluestore使用自己的内存来缓存数据，而不是依赖 *** 作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量

•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。

重要：

OSD的内存自动调整是“尽力而为”。虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。OSD有时仍然可能会超过它的内存目标。我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。这个值可能会比需要的多或少取决于系统的具体配置。

在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关

仔细规划你的数据存储配置。在规划数据存储时，需要考虑重大的成本和性能权衡。同时进行 *** 作系统 *** 作，以及多个守护进程对单个驱动器同时请求读取和写入 *** 作，会大大降低性能。

重要

由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。

OSD应该有足够的硬盘空间来存放对象数据。我们建议硬盘驱动器的最小容量为1T。考虑到较大磁盘的每GB的成本优势。我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。例如，价格为75美元的1T硬盘，每千兆字节的成本为007美元。相比之下，价格为150美元的3T硬盘的成本为每千兆字节005美元。在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。

Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意

Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意

存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。这些物理限制会影响整体系统性能，特别是在恢复期间。我们建议为 *** 作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个 *** 作系统，多个OSD，或多个日志。由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。

您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。Ceph必须先写入到日志，然后再进行ACK写入。

ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入

Ceph最佳实践规定，你应该在不同的驱动器上运行 *** 作系统、OSD数据和OSD日志

提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。

固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。但固态硬盘确实有很大的局限性。在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。

重要

我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能

由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。相对便宜的SSD可能会吸引你的经济意识。请谨慎使用。在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。日志和SSD有几个重要的性能注意事项：

•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。确保SSD分区正确对齐

虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。

Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。Ceph为CephFS元数据提供了一个默认的元数据池。你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。详情请参见将池映射到不同类型的OSDs。

•意思是可以将一个池的所有数据都存储到SSD类型的OSD

磁盘控制器对写入吞吐量也有很大影响。在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。

Tips：Ceph博客通常是对Ceph性能问题的一个很好的信息来源。更多详情请参加Ceph写吞吐量1和Ceph写吞吐量2

•>有问题可以留言，咋们一起成长(๓´╰╯`๓)

当第一次理解raft协议的基本原理之后, 给我的第一印象就是raft能够保证多个副本的日志(状态机)强一致这种强一致性就相当于你开启副本了同步复制机制, 只要系统已经提交客户端的请求,那么接下来客户端向任何一个副本发起读请求都能够读到之前提交的数据但是不同于简单粗暴的同步复制方案,分布式系统的可用性将降低至 (P为一个副本的失效概率,N为分布式系统中的副本个数)

即使我认识到了raft这么强的一致性,但是还是忽视了一个细节陈述:raft保证提交的状态机 最终 会 被应用 对于TiKV或者RheaKV,最终状态机会被应用到rocksdb中最终这词似乎在弱化raft的一致性,似乎在向最终一致性靠拢不过可以放心,raft不是最终一致性协议,它就是强一致性,因为它保证了“当日志被提交后,那么在该瞬间可以在N+1个副本上找到该日志条目”, 只不过这个日志条目当前可能还没有被应用到rocksdb上而已,而该应用 *** 作会发生在未来的某个时刻 因此如果你希望看到最新提交点rocksdb的状态, 那么只需要综合计算已经提交但还为被应用的日志条目和rocksdb数据就好了 而raft的线性一致性读的原理就是这么一回事情

为了更好的理解raft的线性一致性读,先来认识一下什么是线性一致性博客[1]对线性一致性已经有了一个比较完整描述线性一致性是一种很强的一致性语义了,它强调 *** 作时间的因果关系, 即使两个 *** 作在逻辑上是完全独立的即使在博客[1]中, clientC读取的不是x,而是y, 但是也要保证如果clientC读取x,也是发现x=2

那么raft是如何实现线性一致性的呢 博客[1,2,3]的解释比较可以理解总结一下:

1、就是我们之前提到的“综合计算已经提交但还为被应用的日志条目和rocksdb数据”而raft的综合计算方式是等待提交点CommitIndex之前的日志条目都被应用到rocksdb中, 然后向rocksdb发起读请求;

2、CommitIndex作为逻辑时间,将请求在时间线上进行排序;

以上就是raft的线性一致性读的核心思想不过这里还需要考虑网络分区的问题raft是能够保证在网络分区发生时仍然能够正常工作, 这里的正常工作是其中一个分区能够正常接受并复制日志条目,而另一个分区将不能复制日志条目当然这并不意味者后者不能再接受请求,因为该分区的leader仍然会认为自己是leader,并接收读请求, 当处理的读请求时,两个分区的提交点就会不同,导致线性一致性读被破坏 因此在ReadIndex方案中,leader会通过心跳rpc来证明在当前提交点下,自己仍然是leader 不过心跳增加了网络开销,另一中LeaseRead方案就通过租期来保证在该租期内自己的leader身份不会被替换,因此在该租期内的一致性读就不需要像ReadIndex方案一样,通过心跳rpc来证明自己的leader身份当然这需要不同副本对租期的长短有一个相对一致的认知, 因为租期通过选举超时计算得到如果不同副本服务器的时钟严重频率不一致,即存在严重的漂移,那么它们对选举超时很难保持一致

[1] >