【科讯】元核云怎么处理Ceph分布式存储中碰到的坑

本篇文章2499字，读完约6分钟

最近很多朋友拿着关于ceph运维哪个洞的复印件来找我，一开始没注意。 毕竟，对新物种来说通常有疑问。 但是，当越来越多的伙伴和社团内的同事问我如何看待这个复印件时，我认为作为ceph开发和运维的技术人员，应该为ceph说点什么。

首先，原作者在拆除ceph运维方面面临的问题是实际存在的，在实际的运维过程中也发生过其他更多的复杂问题。 第一个ceph是社区提供的开源版本，因此像第一个安卓系统一样，实现产品化需要多次坑。 因为技术本身发现了问题，在处理问题的道路上飞速发展，所以每个产品最初都很难做到完美。 但是，这里想清楚的是，即使是第一次参与ceph的承运人也能发现的问题，研究ceph多年的资深技术人员们一定早就发现了。

接下来，根据那个复印件中提到的漏洞，谈谈在实际的产品化过程中我们是如何处理它们的。

一、扩张问题

ceph本身基于crush算法，具有各种数据复制策略，可以安装在磁盘、主机、机柜等地方。 例如，如果使用三个复制副本的数据保护策略，请使用复制策略来确定三个复制副本是否分布在不同的磁盘、不同的主机、不同的隔离域、不同的机柜等位置，以及硬件

ceph的基础是在资源池( POL )中实现数据的逻辑分离，经常会出现由于容量和性能不足而需要扩展资源池的问题，但在容量扩展过程中需要重新平衡数据。 ceph的数据以pg为单位组织。 这是因为在数据池中添加新的存储单元( osd )时，可以通过调整osdmap来重新平衡数据。 正如复制的那样，如果涉及多个osd的扩展，则可用pg的osd将小于min_size，pg将无法使用，io可能会被阻止。 为了尽可能不发生这种情况，一次只能扩展一个osd或一台机器、一个机柜(主要取决于存储隔离战略)等，只能减小扩展的粒度，但这带来了很大的承运人量，扩大了

与这个问题相比，元数据云分布式存储产品在运维管理平台级别进行了优化。 如果发生扩展，承运人只需将扩展的服务器新闻和策略添加到运维管理平台，随后的事件将由运维管理平台自动解决。 简单来说，运维平台基于pg的状态和扩展的osd资源，寻求在扩展动作完全完成之前，不影响pg的可用性，逐次扩展osd的最佳扩展方法。 例如，在三个拷贝的场景中，如果某个pg被添加到两个osd，则运维平台通过算法分两次完成扩展，一次只扩展一个osd，由此可以保证pg的min_size总是大于1。 整个过程完全由运维平台自动完成，对运维管理员完全透明。

二、数据迁移中的io竞争问题

副本中提到的第二个问题是频繁数据迁移过程中出现的io竞争问题。 如果集群规模变大，硬盘破损、pg数的扩展可能会常态化。

根据我们的运维经验，客人大致每年做几次相关运维的操作。 我们发货的所有群集最多都超过了1000个存储节点，但在此过程中，每个月会有1~2台硬盘损坏，大约3个月就会进行集中更换。 这些运维的操作都需要通过数据迁移进行数据恢复，在数据恢复过程中竞争硬盘io，如何比较高效智能地控制io，进行恢复，使业务io不受影响，这是ceph

在元数据云自动运维管理平台中，使用时间策略和流量策略来控制数据恢复的速度。 我们采用业务高峰时、8:00 18:00时间段的流量恢复策略，业务高峰时、18:00次日8:00时间段采用其他流量恢复策略。 流量恢复策略可以根据磁盘的io利用率动态调整数据流量的恢复速率。 例如，如果恢复流量将io使用率阈值设定为不超过50%，则可以保证恢复流量对io的使用率不超过50%，业务io的使用率越大，恢复io的使用率越小，业务io的使用 这种方法可以相对高效地利用空闲io，在不影响业务io的情况下迅速完成数据迁移恢复。

三、pg数量调整问题

处理数据迁移中的pg可用性问题和io冲突问题时，当然也会处理副本中提到的pg数量调整问题。 数据迁移本身是一个正常的过程，它可以抑制数据在迁移过程中的不利影响，如果pg在osdmap变化过程中始终可用，如副本中所述调整pg的数量不会带来灾难性的后果。 另外，pg的调整也确实不是典型的动作。

四、集群利用率问题

拷贝中提到的存储价格问题是，在ceph集群规模增大后，伪随机算法使存储资源的分布不均衡，磁盘利用率的分散过大。

实际上，为了平衡每个磁盘的数据，这是一个相对复杂的过程。 首先，保证数据分散符合各pool的rule-set规则，和与各pool对应的pg合理地分散于各osd (由于部分pool配置了元数据，因此没有主机大量的数据)，pg数发生变化， 元云基于ceph开发智能数据分布管理的特点，通过事先设定的计算模型，反复计算，可以预测最佳的数据分布，以现实运维的经验，我们在osd之间的数据容量差在2%以下，存储库 此特征功能可管理因群集初始化、扩展、硬件故障等原因导致的数据迁移后的数据不平衡，实现良好的空间利用率。

五、运输维多利亚和杂度问题

正如文案所述，ceph本身是一个非常复杂的系统，为了实现稳定的运维，非常重视团队的实力。 核心云不仅高度优化了ceph核心，还提供了支持数据中心之间多ceph集群的自动运维管理平台，大大提高了运维效率，降低了ceph存储集群的运维价格。 现在，我们使用这个运维平台实现了五个数据中心数千个节点的存储集群，每年只有一个运维人才的例子。

总之，对于这个复印件中提到的漏洞，我们已经采取了充分的预防措施。 桌子上的空谈都很简单，但实际操作比这个多，杂乱几千倍。 如何人云亦云，要真正认识事实的真相，还是需要很长的实践操作经验。 元云主导的某大型金融集团50pb+附近的分布式存储方案是国内金融领域最大的ceph存储的例子，达到了4年软件存储产品本身的故障记录，期间也出现了各种互联网异常、服务器和硬盘故障 经历了操作系统补丁和升级、存储软件补丁和升级等问题，保持了存储数据的正常。 软件定义存储软件系统是一个工程项目，为了保证产品的成熟度需要大规模的生产实践经验和时间积累。 毕竟，存储是基础的重要技术产品，是数据的最后防线，如果要正式进行生产应用，建议采用成熟的商业化ceph存储产品。