找回密码

大数据存储硬件选型分析

大数据系统方案咨询中的疑问

最近有位朋友向我咨询技术问题,他们的客户提出一个大数据系统的服务器硬件需求,其中元数据有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这种设计属于在标准服务器基础上的改良,其他品牌可能也有自己提高存储密度的方式。

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

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

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

相关推荐