怎么理解Ceph分布式存储集群-创新互联

怎么理解Ceph分布式存储集群，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

在规划Ceph分布式存储集群环境的时候，对硬件的选择很重要，这关乎整个Ceph集群的性能，下面梳理到一些硬件的选择标准，可供参考：

1）CPU选择

Ceph metadata server会动态的重新分配负载，它是CPU敏感性的，所以Metadata Server应该有比较好的处理器性能 (比如四核CPU). Ceph OSDs运行RADOS服务，需要通过CRUSH来计算数据的存放位置，replicate数据，以及维护Cluster Map的拷贝，因此OSD也需要合适的处理性能 Ceph Monitors 简单的维护了Cluster Map的主干信息所以这个是CPU不敏感的。

2）RAM选择

Metadata servers 以及Monitors 必须能够快速的提供数据，因此必须有充足的内存(e.g., 1GB of RAM per daemon instance). OSDs 在执行正常的操作时不需要过多的内存 (e.g., 500MB of RAM per daemon instance);但是 执行恢复操作时，就需要大量的内存(e.g., ~1GB per 1TB of storage per daemon). Generally, 而且是越多越好。

3）Data Storage选择

规划数据存储时要考虑成本和性能的权衡。同时OS操作，同时多个后台程序对单个驱动器进行读写操作会显着降低性能。也有文件系统的限制考虑：BTRFS对于生产环境来说不是很稳定，但有能力记录journal和并行的写入数据，而XFS和EXT4会好一点。

提示:不推荐单个磁盘的分区上运行多个OSD。不推荐单个磁盘的分区上运行一个OSD和一个监视器或元数据服务。

存储驱动器受寻道时间，访问时间，读取和写入时间，以及总吞吐量的限制。这些物理限制会影响整个系统的性能，尤其是在恢复过程中。我们建议为操作系统和软件使用专用的驱动器，并且为你在主机上运行每个OSD守护分配一个驱动器。大多数“慢OSD”的问题的产生是由于在一个操作系统同一驱动器上运行多个OSDs和/或多个日志。

由于解决性能问题的一小部分的成本可能超过额外的磁盘驱动器的成本，因此你可以加快你的的集群设计规划，为了避免OSD存储驱动器负荷过重。

在每个硬盘驱动器上同时运行多个Ceph的OSD守护程序，但是这可能会导致资源争用，并降低整体吞吐量。你可能把日志和对象数据存储在相同的驱动器上，但这样可能会增加所花费在记录写入操作和发送ACK给客户端的时间。在CEPH可以ACK对于写入操作前,Ceph必须把操作写入到日志。

BTRFS文件系统的日志数据和对象数据的同时可以写，而XFS和ext4的不能。Ceph的推荐做法，分开在单独的驱动器上运行操作系统，OSD数据和OSD日志。

本文原创地址：/tupian/20230522/ network和cluster_network。集群网络（最好别连接到互联网）用于处理由数据复制产生的额外负载，并且有助于阻止拒绝服务攻击，拒绝服务攻击会干扰数据归置组，使之在OSD数据复制时不能回到active+clean状态。请考虑部署万兆网卡。通过1Gbps网络复制1TB数据耗时3小时，而3TB（一个典型的驱动配置）需要9小时，与之相反，如果使用10Gbps复制时间可分别缩减到20分钟和1小时。

在一个PB级集群中，OSD磁盘失败是常态，而非异常；在性价比合理的前提下，系统管理员想让PG尽快从degraded（降级）状态恢复到active+clean状态。采用10G网卡值得考虑使用。每个网络的顶级机架路由器到核心路由器通信应该有更快的吞吐量，例如，40Gbps~100Gbps。

6）其他注意事项：

可以在每台主机上运行多个OSD进程，但应该确保OSD硬盘的吞吐量总和不超过客户端读取或写入数据所需的网络带宽。也应该考虑在每个主机上数据的存储率。如果一个特定的主机上的百分比较大，它可能会导致问题:为了防止数据丢失,会导致Ceph停止操作。

当每台主机上运行多个OSD进程时，还需要保证内核是最新的。 当每台主机上运行多个OSD进程时（如>20）会产生很多的线程，特别是进行recovery和relalancing操作。许多 Linux 内核默认线程限大数量比较小（例如，32k的）。如果您遇到这方面的问题，可以考虑把kernel.pid_max设置的高一点。理论上的大值为4,194,303。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联-成都网站建设公司行业资讯频道，感谢您对创新互联的支持。