“螺旋式前进”这种东西存在于各个领域,在大规模数据存储与处理上,一样如此。
曾经,当管理人员购买服务器的时候,如需更高的性能,则会购买更高配置的服务器,这种做法称之为 “纵向扩展(Scale up)” ;后来当我们意识到纵向扩展会带来更高的开销时,我们开始采用购买更多的服务器来解决问题,而不是购买更高端的服务器,这种做法叫做 “横向扩展(Scale Out)” 。今天的数据中心就是如此,由于机架空间是很重要的一个因素,因此发展出了现在我们称为 “刀片服务器” 的1U、2U 这种概念的服务器,可以使得在一个机架内装入更多的服务器。再后来,发现其实很多服务器的利用率都不高,于是又发展出了虚拟化技术,以更充分的利用各个服务器资源。
存储发展也是同样,先是单机内单块儿硬盘的存储追求更高的容量和更高的IO,遇到困难后,在单机内发展多块硬盘做RAID做小规模横向扩展,再后来,独立出SAN和NAS用很多硬盘来做大规模的横向扩展。
Hadoop 也是基于同样的横向扩展理念发展出来的。那么 Hadoop 在使用现在流行的刀片服务器、SAN和虚拟化技术上,是否和传统服务一样会提高性能呢?不尽然。
先说 Hadoop 操作的特点。Hadoop 是对IO性能非常敏感的,操作过程中将会有大量的IO操作。Hadoop 不需要 RAID,相反,使用RAID可能会降低 worker 的性能; Hadoop 希望硬盘使用 JBOD (Just Bunch of Disk 就是简单的一堆硬盘) 的简单形式,说白了,磁盘不需要特殊处理,简单的由操作系统挂载即可。这样的好处是,每一个磁盘将有独立的 IO,互相之间不需要协作,谁的数据准备好了,就把谁的数据从缓冲直接送到对应进程。而RAID的麻烦在于磁盘之间有协作,往往最慢的磁盘决定了整个RAID的性能,更严重的是,由于所有磁盘都通过一块RAID控制芯片,往往该芯片成为了磁盘性能的瓶颈。
对于 SAN 和 NAS 来说,具有和 RAID 同样的特性,由于大量的磁盘位于1-2个控制芯片之后,他们的IO无法像JBOD那样充分利用,受限于控制芯片,从而导致当集群中大量的节点并发访问的时候,很容易会造成其控制芯片的拥堵。这与传统意义上的服务器不同,在传统意义上 SAN 和 NAS 会大幅提高 IO 性能,但是 Hadoop 所需的 IO 要远远超过当前 SAN 或 NAS 的能力,至少在性价比上,SAN 和 NAS 并不是很适用于 Hadoop 的操作特性。
那么,当 Hadoop 遇到虚拟化后,问题同样就会暴露出来,由于虚拟化的系统无法意识到别的系统的存在,因此在磁盘IO调度上,无法整体的优化调度。我们知道磁盘和Flash不同,其固有的物理特性是顺序读写速度很快,但是寻道时间则很慢。而 虚拟化技术会使得操作系统无法优化调度寻道操作,导致会产生大量的寻道,从而无法充分利用磁盘顺序读写的能力 ,而降低了性能(这也是为什么Hadoop Block非常大的原因之一,用于将数据顺序写入磁盘,并顺序读出,以大幅增加IO性能)。
刀片服务器的问题是在于内部空间十分有限,前文所知,Hadoop 的需要大量的IO,因此一个节点内,如果有更多的独立磁盘,其IO性能会更好。这也是为什么前文中提议配置时,24 x 1TB 的磁盘比 12 x 3TB 的磁盘要更好的原因。刀片服务器内部的空间限制,往往束缚了增加更多硬盘的可能性。
从这里,我们就更好的能够看出 Hadoop 所谓的运行于独立的商用服务器,以及其特意强调的 Share Nothing 的构架的原因。任务独立、IO独立对于Hadoop来说,会产生更好的性能,换句话说,这种 Share Nothing的构架,会更充分的利用硬件资源。
参考1:http://twang2218.github.io/readings/hadoop-operations/hadoop-operations-notes-ch04.html
参考2:http://www.ha97.com/5673.html
本文出自 “神威新空间” 博客,请务必保留此出处http://abool.blog.51cto.com/8355508/1883429
部署Hadoop集群为什么优先选择硬件方式而不是虚拟化方式?
原文地址:http://abool.blog.51cto.com/8355508/1883429