最近有位朋友向我咨询技术问题，他们的客户提出一个大数据系统的服务器硬件需求，其中元数据有xxTB左右。并给出了以下初步建议：

节点类型1（元数据节点）

Xeon E5 14核CPU x2

256GB DDR4内存

600GB SAS 15K硬盘x5

RAID卡

节点类型2（数据节点）

Xeon E5 14核CPU x2

128GB DDR4内存

4TB 7.2K近线硬盘x4

RAID卡

软件并非我擅长的方面，不过大数据概念炒了好几年，从各方面还是多少了解到一些Hadoop/HDFS硬件架构方面的东西。在与朋友讨论的过程中，我觉得相关技术还需要补补，以跟上“应用定义硬件”的形势，于是就把之前收集到的一些资料翻看了下。 

在分享我的学习心得之前，先列出以上案例中的几个疑问，同时附上专家意见。

1.  Hadoop是否需要RAID？

根据我的了解，HDFS（Hadoop分布式文件系统）的数据盘应该是不做RAID，靠跨节点的3副本来实现冗余高可用。那么是否还需要配SAS RAID卡？如果是RAID卡需要改成直通（HBA）模式吗？

专家观点

据了解开源版本的HDFS multiple master应该还未ready，所以现在HDFS master是master-slave或者单点部署或者共享存储。如果不是共享，那么master机器本身最好不要down掉，RAID卡不仅提升性能，也能一定程度上避免单盘坏带来的问题。网上有人说Master的内存要尽可能大，要有更强的ECC功能，可以参考下。

2. 是否应该添加额外的系统硬盘？元数据节点的SAS盘如果换成SSD效果更好？按照传统的观点，在有条件的情况下服务器的系统盘和数据盘建议分开，无论从容量规划还是性能角度考虑，特别是存储密集型应用。此外，用户提出15K高转速硬盘应该是有IOPS需求，而SSD在这方面优势明显。

专家观点

如果需要高性能，SSD更好，价格也会持续下降，master采购SSD的话也浪费不了多少，一旦挂了，读image恢复也快。单个磁盘容量应该大于内存，比如2倍，这样内存数据image才能落在磁盘上，甚至保留最近的几个备份。

3. 这个建议中数据节点只配了4块硬盘，能否满足容量的需求？

4块4TB硬盘裸容量按照16TB来计算不少了，但是HDFS默认是3副本，也就是3个节点的有效容量只相当于单节点物理容量。而且处理过程中的数据集应该会大于导入的元数据量，那么整个集群需要增加节点还是每节点的硬盘数？

专家观点

只有4块浪费了点，机器机架的公摊变多了，如果价格差别不大，10块+更好，哪怕现在不插盘。不过这取决于应用想干什么，以及当前的业务规模。一般来说，数据量是X，那么容量需要是X*配置的replica/容量比。配置的replica一般是3，容量比80%，如果有大量的中间结果，容量比会比较低，比如60%。

4. CPU/内存/硬盘配比有计算公式吗？

由于这位朋友认识的一位大数据专家出差了，我被临时找来抱佛脚：）听应用高手说，可以根据自己的情况来计算出需要的硬件配置。对于我们而言，这方面有没有给用户的建议呢？

专家观点

跟业务类型紧密相关，比如跑人工智能类的迭代，那么CPU就要多，甚至配置GPU。如果是一般的数据处理，比如网站分析点击日志，512GB空间，1个CPU，4-8GB内存一般也差不多了。

Facebook资料里的参考

这两年，伴随着OpenStack、Docker被人们追捧，云计算的话题依旧保持着一定热度，或者说正在落地。而大数据泡沫在几年前感觉有些被吹大了，以至于在Hadoop科普时我关注过一些，后来除了开源项目的发展之外，厂商们的推广力度也没有开始时那么大了，进入务实阶段。 

下面引用一个当年给我印象比较深的表格，来自Facebook关于非结构化数据存储硬件选型的分享资料。

 

我们知道Facebook每天都有海量上传的照片和视频，上表中Type V硬件类型对应的就是这个，其特点为低CPU、内存开销，主要是温数据和冷数据。 

而本文关注的Type IV针对Hadoop应用，硬盘仍然按照12块3TB大容量来配置，CPU和内存的需求都是“中等”，从具体的Xeon X5650 CPU来看这份资料也比较早了。

Hadoop组件、节点分工和高可用架构

 

上图引用自《Dell  Cloudera Apache Hadoop Solution Reference Architecture》文档，Cloudera是一家排名领先的Hadoop发行版厂商，我们借此来了解下今天Apache Hadoop方案中流行的组件。 

底层有服务器和网络硬件、操作系统、Java虚拟机（中间件）；往上包括了资源管理（YARN）、HDFS文件系统、HBase（开源的NoSQL分布式数据库）；MapReduce数据处理框架和Hive数据仓库在几年前就已经讲的比较多，而Spark In Memory Processing等这两年也比较火。 

既然最终目的是讨论硬件配置，先看看不同的节点类型及其主要职能。

 

Admin Node即管理员节点，这里不过多讨论；Edge Node（边缘节点）被称为Hadoop Clients，主要作用是集群数据与外界之间的导入导出；在数据节点和命名（Name）/HA节点之中，蓝色部分属于管理模块，绿色则是存储模块，二者各有一套网络连接到Edge Node。数据节点之间完全对等，下面介绍一下元数据服务的高可用实现。 

记得Hadoop在早期的1.0版本时，Name Node还曾经有过单点故障问题，下面这段描述只代表部分商业版本的解决方案。 

首先不难理解，Active Name Node和Standby Name Node之间是主备关系，而第三个HA节点上也有Cloudera Manager和Zookeeper，其作用就是Name Node自动切换的仲裁。HA节点上不运行Name Node服务，但元数据的Journal会由主节点同时向3个节点写入，多数返回才算成功。 

这个Journal，让我想起了Oracle Data Guard中同步复制的Redo log。

专家观点

Name Node HA这一块现在并无统一的方案，我看到Hadoop网站上是建议使用NAS类的共享存储，在不能基于类似paxos提供高可用情况下，我觉得共享存储是个不错的选择，因为一致性能得到保证，主备就怕一致性问题。（参考链接：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html）

 集群网络架构、起步配置

上面是Hadoop节点间的网络连接。目前主流的数据网络是双万兆，iDRAC/管理网络可以用千兆，作为与外界数据沟通的Edge Node还应有2个万兆连接至用户的企业网络。这个示例为角色完整的最小节点数集群，而实际上还有进一步精简的配置方式。

专家观点

万兆是趋势，不过也看业务，千兆目前在Hadoop数据网络中也挺流行的。

 

所谓“QuickStart”应该就是最小起步规模。上图中2个R730xd Infrastructure Node估计包含了元数据和Edge节点的功能，这里减掉了第3个HA节点是不是意味着故障切换的机制有变化？

专家补充

Master Namenode HA并无标准，开源以及一些基于开源的商业公司都想做自己的。

硬盘数与性能、CPU/内存/磁盘配比公式

 

本文开头提到过每个数据节点的硬盘数。除了容量之外，这还会影响到存储性能，上面的图表显示了执行时间与硬盘数之间的对应关系。 

从这个来看，8块硬盘相比4块速度提升了一倍，同时容量翻番。尽管12块盘的性能更好，但在今天硬盘容量不断增长（传输率也有些提升）的情况下，有些场景数据节点用8块盘应该也是一种不错的选择，特别是对性能和容量不太敏感的应用。

 

关于合理的硬件资源配比，我从一份资料里引用整理出上面的图表供参考。其中有3种不同应用侧重的Hadoop计算（存储）节点，我们先按照一般规律假设磁盘主轴数为12。对于数据密集型和存档型应用其CPU核心配置12个（2颗6核入门级）即可；计算密集型应用可以配置24核——2颗12核。内存容量方面，对于存档节点24GB即够用，数据密集型可以配置48GB，而计算密集型在这里的建议是96GB。 

当然，上表也有一定的时间局限性，比如磁盘是按照主轴而不是容量来统计。这样从存储性能角度看比较合理，但硬盘容量毕竟在慢慢提高，比如3、4年前的主流3TB今天上升到4TB或者更大；与此同时内存价格在不断下降，CPU集成核心数越来越多，为了更好地适应更大的数据集规模，主流应用的配比也应该随着时间发展而适当调整。 

下面我们来看一些更具体的建议。

元数据节点磁盘分工及配置

 

该表格引用自《Dell Reference Configuration for Hortonworks Data Platform 2.4》，列出了Name Node和HA见证节点的磁盘配置建议。Hortonworks是另外一个主要的Hadoop发行版。

可见OS、HDFS元数据和数据库有可靠性和可用性的要求；Zookeeper和NameNode Journal应该只有在故障时才会用到，并且在多个节点上有副本，所以不用RAID保护。对于日志这类顺序写入负载，SSD可以提供更高的吞吐量。

 

上面是具体的Name Node和HA见证节点配置。在这个PowerEdge R730xd服务器平台上，CPU为2颗Xeon E5-2650 v4 12核、128GB内存，网络子卡（Daughter Card）选择双万兆+双千兆；硬盘方面，2块600GB SAS盘RAID 1用于OS（安装在服务器后端的Flexbay中），另外8块1TB数据盘的用途参见上面。

 

作为一款12Gb SAS RAID卡，PERC 9 H730支持设置为HBA直通模式。上图为Dell服务器标配H730 mini RAID子卡，通过专用连接器插在主板上，不占用标准PCIe扩展槽。这种子卡的成本比标准尺寸的RAID卡要低（网络子卡的情况类似），即使当做SAS HBA来使用也不会造成多少浪费。

对比本文开头用户提出的元数据节点配置，内存容量比这个还大，而硬盘上没有写这么细致，总的来说还算合理吧。毕竟配置建议与实际应用情况相关，可以跟用户做进一步的沟通。

 

上图是我几年前在PowerEdge 12G发布活动上，拍摄的R720xd后侧Flexbay——2个2.5英寸热插拔盘位。

数据节点：标准、内存密集型和容量扩展配置

接下来是数据节点的硬件建议，这里给出了通用用途、高性能和高容量三种配置：

 

通用数据节点的CPU和内存与前面的Name Node等相同，算是主流配置吧。HDFS数据存储方面，配置了12块4TB 7.2K NL-SAS硬盘（企业级近线SATA用在服务器上差不多），非RAID或者RAID 0模式。 

由于数据节点的多副本容错模式，对单机可用性要求大为降低，因此多数情况下操作系统盘的RAID 1也可以不用。上表中应该属于一种比较豪华的配置方式。

 

高性能节点建议配置2颗Xeon E5-2690 14核CPU、512GB内存，除了板载网络子卡之外，额外增加一块Intel双端口万兆配置LACP聚合以提高带宽。 

磁盘配置也相应的比较豪华。服务器平台调整为24个2.5英寸盘位的R730xd，包括20x 1.2TB SAS + 3x 800GB SSD的HDFS分层存储；另有一块800GB Intel S3710应该是用于Spark数据持久化——这就可以理解为什么内存要配这么大，因为它就是针对“内存计算”的。

 

最后是高容量节点，它的配置在通用数据节点基础上做了增强——采用一款特定版本的R730xd机箱（12+2+4，带有Flexbay和Mid-bay）。如下图，在2U机箱的中部增加了4个3.5英寸硬盘位，因此4TB HDFS数据盘的数量增加到16块。

 

这4块盘也能够支持热插拔，不过需要先打开服务器上盖。Dell这种设计属于在标准服务器基础上的改良，其他品牌可能也有自己提高存储密度的方式。

架构验证——云带来真正的便利

有个方法是可以检验一下选型的，就是在云服务厂商那里先按照自己的配置租一些服务器，根据业务调整云服务器的配置，这个很方便（硬件买了就很难调整了），最终也能得出比较合理的配置。 

本文到此先告一段落，开头提出的几个问题应该都有答案了。笔者不是大数据方面的专家，希望这些学习心得加上专家观点对大家有所帮助。如有错误和不足欢迎批评指正，欢迎您在下面留言交流！