什么叫软文,网站最好的优化是什么,wordpress试试手气,phpcms下载过去两年#xff0c;我的主要工作都在Hadoop这个技术栈中#xff0c;而最近有幸接触到了Ceph。我觉得这是一件很幸运的事#xff0c;让我有机会体验另一种大型分布式存储解决方案#xff0c;可以对比出HDFS与Ceph这两种几乎完全不同的存储系统分别有哪些优缺点、适合哪些场…过去两年我的主要工作都在Hadoop这个技术栈中而最近有幸接触到了Ceph。我觉得这是一件很幸运的事让我有机会体验另一种大型分布式存储解决方案可以对比出HDFS与Ceph这两种几乎完全不同的存储系统分别有哪些优缺点、适合哪些场景。对于分布式存储尤其是开源的分布式存储站在一个SRE的角度我认为主要为商业公司解决了如下几个问题可扩展满足业务增长导致的海量数据存储需求比商用存储便宜大幅降低成本稳定可以驾驭好运维。总之目标就是又好用又便宜还稳定。但现实似乎并没有这么美好……本文将从这三个我认为的根本价值出发分析我运维Ceph的体会同时对比中心化的分布式存储系统比如HDFS横向说一说。一、可扩展性Ceph声称可以无限扩展因为它基于CRUSH算法没有中心节点。 而事实上Ceph确实可以无限扩展但Ceph的无限扩展的过程并不完全美好。首先梳理一下Ceph的写入流程。Ceph的新对象写入对象需要经过PG这一层预先定义好的定额Hash分片然后PG再经过一次集群所有物理机器硬盘OSD构成的Hash落到物理磁盘。因此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的完整副本又下降为1的极端情况发生。虽然PG有可能不能服务但数据的持久性是没有问题的。国内AT的云服务可靠性都没有做得特别高做到像持久性那样3个9、4个9。虽然我不确定这两朵大云里的对象存储是不是使用的Ceph但只要是基于类似CRUSH算法或者一致性哈希等类似的去中心化技术实现的对象存储应该都会面对部分数据暂时不可服务的情况。我们抛开最极端的情况即假设在扩容时以一个“容错域”加入机器时暂时没有磁盘损坏。那么有没有办法可以提升扩容粒度呢办法是在开始规划Ceph集群时设定好更大层次的“容错域”比如Rack。 可以是真实的Rack即使没有也可以是逻辑的Rack。这样扩容时可以扩一个逻辑“容错域”就可以打破扩一台机器的限制扩一整个Rack至少有好几台机器。Tips这里我没有讲为什么扩容粒度小是个不好的事。其实在很多公司数据的日均增长量是很有可能大于一台机器的存储容量的。这就会造成扩容速度赶不上写入速度的尴尬局面。这对于开始没有设计好图快速deploy而架设的集群在后期是一个不小的伤害。2.扩容时crushmap的改变Ceph是根据crushmap去放置PG的物理位置的倘若在扩容进行了一半时又有硬盘坏掉了那Ceph的crushmap就会改变Ceph又会重新进行PG的re-hash很多PG的位置又会重新计算。如果运气比较差很可能一台机器的扩容进度被迫进行了很久才回到稳定的状态。这个crushmap改变导致的Ceph重平衡不单单在扩容时几乎在任何时候对一个大的存储集群都有些头疼。在建立一个新集群时硬盘都比较新因此故障率并不高。但是在运行了2-3年的大存储集群坏盘真的是一个稀松平常的事情1000台规模的集群一天坏个2-3块盘很正常。crushmap经常变动对Ceph内部不稳定影响真的很大。随之而来可能是整体IO的下降(磁盘IO被反复的rebalance占满)甚至是某些数据暂时不可用。所以总的来说Ceph的扩容是有那么一丁点不痛快的。Ceph确实提供了无限的扩展能力但扩容过程并不平滑也不完全可控。crushmap的设计达到了很好的去中心化效果但也给集群大了之后的不稳定埋下了一个坑。而对比中心化元数据的HDFS在扩容时几乎无限制你可以撒欢地扩容。老数据的搬迁重平衡都会由单独的job来处理处理也很高效。它采用了满节点和空节点两两配对的方式从老节点移动足够的数据填满新机器即可。中心化元数据在扩容重平衡时反而变成了一个优点。3.扩容到一定量级后PG数量需调整如上文的Ceph数据写入流程图所示Ceph对象的最小放置单位是PGPG又会被放在硬盘上PG理论上肯定是越大越好。因为这样数据的分片随机性更好更能掩盖伪随机造成的单块盘容量偏差过大问题。但PG数量在现实中不是越大越好的它要受限于硬件如CPU、内存、网络。 因此我们在规划PG数时不会盲目调大一般社区也是建议200pg / osd。假设我们现在有10台机器每台一块硬盘一共10块盘有1024个PGPG都是单副本那么每个盘会存100个PG。此时这个设置非常健康但当我们集群扩容到1000台机器每台硬盘就只放一个PG了这会导致伪随机造成的不平衡现象放大。因此admin就要面临调整PG数量这就带来了问题。调PG基本也就意味着整个集群会进入一种严重不正常的状态。几乎50%的对象涉及到调整后的PG都需要重新放置物理位置这会引起服务质量的严重下降。虽然调整PG不是一个经常性的事件但在一个大型存储随着发展不可避免会经历这个大考。二、比商用存储便宜我们所说的和商业存储比较一般就是和EMC、IBM这类硬件软件存储解决方案厂家或者云解决方案Aliyun、AWS之类的对比。自己建设机房当然在硬件单价上更为便宜但需要考虑综合成本包括1.硬件成本2.自养运维人员成本3.服务质量由一般向好慢慢收敛。人的成本这种玄学的问题我就不谈了本文只谈Ceph在硬件成本这块有什么有趣的地方。讲道理自己建机房硬件成本应该是毫无疑问的便宜那么Ceph在这里有什么特殊呢问题在于集群可靠利用率。集群可靠利用率即整个集群在容量达到某个水平时不可对外服务或者说不能保持高可用的服务。打个比方我们的手机闪存/电脑硬盘是不是到99%了还能正常工作 当然因为是本地存储嘛。对于云解决方案也天然就没有这个问题了。对于商用存储解决方案比如EMC的Isilon分布式文件系统存储容量达到甚至98-99%仍能对外提供服务。对于HDFS在95%以下存储也能很好地对外提供服务。跑在HDFS上的Hadoop Job会因为没办法写入本地而挂掉。而对于Ceph在这一块表现得并不好。根据经验在集群整体使用率达到70%后就有可能进入不稳定的状态。这是为什么呢问题在于去中心化带来的tradeoff。Ceph是去中心化的分布式解决方案对象的元数据是分布在各台物理机上的。因此所有对象是被“伪随机”地分配到各个磁盘上的。伪随机不能保证所有磁盘的完全均匀分配不能降低很多大对象同时落在一块盘上的概率(我理解加入一层PG又使PG多replica是可以让磁盘的方差变小的)因此总有一些磁盘的使用率会高出均值。在集群整体使用率不高时都没有问题。而在使用率达到70%后就需要管理员介入了。因为方差大的盘很有可能会触及95%这条红线。admin开始调低容量过高磁盘的reweight但如果在这一批磁盘被调整reweight没有结束时又有一些磁盘被写满了那管理员就必须被迫在Ceph没有达到稳定状态前又一次reweight过高的磁盘。 这就导致了crushmap的再一次变更从而导致Ceph离稳定状态越来越远。而此时扩容又不及时的话更是雪上加霜。而且之前的crushmap的中间状态也会导致一些PG迁移了一半这些“不完整的”PG并不会被马上删除这给本来就紧张的磁盘空间又加重了负担。有同学可能会好奇一块磁盘满了Ceph为什么就不可用了。Ceph还真的就是这样设计的因为Ceph没法保证新的对象是否落在空盘而不落在满盘所以Ceph选择在有盘满了时就拒绝服务。在我咨询了一些同事和业界同行后基本上大家的Ceph集群都是在达到50%使用率时就要开始准备扩容了。这其实是挺不省钱的因为必须空置一大批机器的存储资源。并且未来集群的规模越大空置效应就会放得越大意味着浪费的钱/电费越多。而很多传统的中心化的分布式存储系统由于写入时可以由主控节点选择相对空闲的机器进行写入因此不会存在某些磁盘满了导致整个集群不可写入的问题。也正是如此才可以做到整体写入到95%了仍然保持可用性。我没有真正核算过这种效应带来的成本waste但至少看上去是有点不够完美的。打个比方当我预估有50pb的存储时需要300台物理机了我居然要提前采购好另外200-300台物理机还不能马上用上还要插上电。因此Ceph也并不一定会很便宜去中心化的分布式存储也并没有那么美好。但中心化的危害似乎又是没有争议的问题(单点问题、中心节点扩展性问题等等 )因此分布式里真的没有银弹只有tradeoff。还有一种办法就是Ceph的集群按整个pool来扩容一个pool满了就不扩容了开新的pool新的对象只准写新的pool老的pool的对象可以删除可以读取。 这乍看之下是一个很棒的解决方案但仔细想想这和HDFS的federation和MySQL的分库分表做前端的大Hash似乎没有区别。这也就谈不上是“无限扩容”了而且还需要写一个前面的路由层。三、稳定可驾驭好运维这个稳定好运维基本就看团队的硬实力了。对开源软件是否熟悉是否有经验真的会有很大不同。同时这还受开源社区文档质量的影响。Ceph的开源社区还是不错的Red Hat收购并主导了Ceph之后重新整理了Red Hat版本的Ceph文档我认为读起来逻辑感更强。在公司内积累自己的运维文档也很关键。一个新手很可能会犯很多错误导致事故发生。但对于公司踩了一次的坑就尽量不要再踩第二次了。这对公司的技术积累管理、技术文档管理、核心人才流失管理都产生了一些挑战。我在Ceph运维中曾遇到一个棘手的问题。即Ceph集群达到了80%后经常有磁盘变满然后管理员就要介入调低过高磁盘的reweight。而在这台磁盘使用量没降下来之前又有更多的磁盘被写满了管理员就又要介入又调整reweightCeph至此就再也没有进入过稳定状态了管理员还必须时时刻刻盯着集群。这导致了极大的运维投入所以像这种事情一定要避免这对运维人员的士气是很大的伤害。那么是否应该在早期进行容量预警启动采购流程呢可是这样做又回到了资源浪费的问题上。此外Ceph的对象是没有last_access_time这种元数据的因此Ceph对象的冷/热之分需要二次开发做额外的工作。集群大了之后如何清理垃圾数据、如何归档冷数据也带来了不小的挑战。总结思考1、Ceph确实有无限扩容的能力但需要良好的初始规划扩容过程也并不完美。中心化造就了扩容的上限是单台master结点的物理极限造就了无限扩容的理论基础但实际扩容时服务质量会受严重制约。2、Ceph有些浪费硬件成本核算时要考虑更多。3、Ceph本身的去中心化设计牺牲了不少元数据比如lastacesstime这给未来数据治理带来了压力也需要更强的团队来运维和二次开发。积累运维经验积累运维团队是驾驭好开源分布式存储的核心。对手随着时间越来越强大应对的运维团队也需要越来越好才能让生产关系匹配生产力的要求。4、技术本身没有绝对的好坏不同的技术是用来解决不同问题的。但在场景下技术是有好坏的。因为在场景下你有了立场就有了亟待解决的问题的优先级也就一定能按优先级选择出最适合你的技术。
