Ceph运维告诉你分布式存储的那些“坑”

转载自：<a href="https://dbaplus.cn/news-134-2079-1.html">https://dbaplus.cn/news-134-2079-1.html</a>
作者介绍
汪涉洋，来自美国视频网站hulu的工程师，毕业于北京理工大学计算机专业，目前从事大数据基础架构方面的工作。个人知乎专栏“大数据SRE的总结”：http://dwz.cn/7ygSgc
 
过去两年，我的主要工作都在Hadoop这个技术栈中，而最近有幸接触到了Ceph。我觉得这是一件很幸运的事，让我有机会体验另一种大型分布式存储解决方案，可以对比出HDFS与Ceph这两种几乎完全不同的存储系统分别有哪些优缺点、适合哪些场景。
 
对于分布式存储，尤其是开源的分布式存储，站在一个SRE的角度，我认为主要为商业公司解决了如下几个问题：
<ol><li> 可扩展，满足业务增长导致的海量数据存储需求； </li><li> 比商用存储便宜，大幅降低成本； </li><li> 稳定，可以驾驭，好运维。 </li></ol>
 
总之目标就是：又好用，又便宜，还稳定。但现实似乎并没有这么美好……
 
本文将从这三个我认为的根本价值出发，分析我运维Ceph的体会，同时对比中心化的分布式存储系统，比如HDFS，横向说一说。
 
 
一、可扩展性
 
 
Ceph声称可以无限扩展，因为它基于CRUSH算法，没有中心节点。而事实上，Ceph确实可以无限扩展，但Ceph的无限扩展的过程，并不完全美好。
 
首先梳理一下Ceph的写入流程。Ceph的新对象写入对象，需要经过PG这一层预先定义好的定额Hash分片，然后PG，再经过一次集群所有物理机器硬盘OSD构成的Hash，落到物理磁盘。
 
<img alt="" src="https://beijingoptbbs.oss-cn-beijing.aliyuncs.com/cs/5606289-315cae0236ff00eac90f443fa02cf6bb.png">
 
因此，Ceph的所有对象，是先被pre-hash到了一个固定数量的桶（PG）当中，然后根据集群的整体物理架构crushmap，选择落在具体的机器磁盘上。
 
这对扩容有什么影响呢？
 
1
 
扩容粒度
 
我给扩容粒度的定义是：一次可以扩容多少台机器。
 
Ceph在实践中，扩容受“容错域”制约，一次只能扩一个“容错域”。
 
容错域就是：副本隔离级别，即同一个replica的数据，放在不同的磁盘/机器/Rack/机房。
 
容错域这个概念，在很多存储方案里都有，包括HDFS。为什么Ceph会受影响呢？因为Ceph没有中心化的元数据结点，导致数据放置策略受之影响。
 
数据放置策略，即一份数据replica，放在哪台机器，哪块硬盘。
 
中心化的，比如HDFS，会记录每一个文件，下面每一个数据块的存放位置。这个位置是不会经常变动的，只有在1.文件新创建；2.balancer重平衡；3.有硬盘坏了，中心节点针对损坏硬件上的数据重新放置时才会改变。
 
而Ceph，因为去中心化，导致容纳数据的PG的位置，会根据crushmap的变化而变化。来了新的机器、硬盘，就要为一些受影响的PG计算新的位置。基于一致性哈希的技术，在扩容时也要面临同样的问题。
 
因此，Ceph扩容需要PG们调整。正因为这个调整，导致Ceph受“容错域”制约。
 
例如：有一个PG，是3副本，Ceph集群有一个配置是PG要向外提供正常服务，至少有2个完整的副本。而当这个数据pool的容错域是host时，同时扩容2台机器，一些PG就有可能把3副本中的2个都映射到2台新机器上去。而这2个副本都是新副本，都没有完整的最新数据。剩下的一个副本，无法满足老机器至少有完整的2副本的要求，也就不能提供正常读写服务了。
 
这就会导致这个PG里的所有对象，停止对外服务。
 
作为admin，当然可以把配置降低，把数据pool的min_size下降为1。但这种配置，即使在正常情况下，因为磁盘故障，都有可能丢失数据，因此一般不会这样设置。
 
那在扩容时，一次只扩容一台机器时，是不是就安全了呢？
 
这样就能保证所有PG都至少在老机器有2个完整的副本了。可是，即使是扩容一台机器，也还要面临扩容时老机器中有硬盘坏掉，导致PG