刀片服务器、SAN、虚拟化技术

“螺旋式前进”这种东西存在于各个领域，在大规模数据存储与处理上，一样如此。

曾经，当管理人员购买服务器的时候，如需更高的性能，则会购买更高配置的服务器，这种做法称之为 “纵向扩展(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集群为什么优先选择硬件方式而不是虚拟化方式？