为你的 Hadoop 集群选择合适的硬件

随着Apache Hadoop的起步，云客户的增多面临的首要问题就是如何为他们新的的Hadoop集群选择合适的硬件。

尽管Hadoop被设计为运行在行业标准的硬件上，提出一个理想的集群配置不想提供硬件规格列表那么简单。 选择硬件，为给定的负载在性能和经济性提供最佳平衡是须要测试和验证其有效性。（好比，IO密集型工做负载的用户将会为每一个核心主轴投资更多）。

在这个博客帖子中，你将会学到一些工做负载评估的原则和它在硬件选择中起着相当重要的做用。在这个过程当中，你也将学到Hadoop管理员应该考虑到各类因素。 

结合存储和计算 过去的十年，IT组织已经标准化了刀片服务器和存储区域网(SAN)来知足联网和处理密集型的工做负载。尽管这个模型对于一些方面的标准程序是有至关意义 的，好比网站服务器，程序服务器，小型结构化数据库，数据移动等，但随着数据数量和用户数的增加，对于基础设施的要求也已经改变。网站服务器如今有了缓存 层；数据库须要本地硬盘支持大规模地并行；数据迁移量也超过了本地可处理的数量。 大部分的团队尚未弄清楚实际工做负载需求就开始搭建他们的Hadoop集群。 硬 件提供商已经生产了创新性的产品系统来应对这些需求，包括存储刀片服务器，串行SCSI交换机，外部SATA磁盘阵列和大容量的机架单元。然 而，Hadoop是基于新的实现方法，来存储和处理复杂数据，并伴随着数据迁移的减小。 相对于依赖SAN来知足大容量存储和可靠性，Hadoop在软件层次处理大数据和可靠性。 Hadoop在一簇平衡的节点间分派数据并使用同步复制来保证数据可用性和容错性。由于数据被分发到有计算能力的节点，数据的处理能够被直接发送到存储有数据的节点。因为Hadoop集群中的每一台节点都存储并处理数据，这些节点都须要配置来知足数据存储和运算的要求。

工做负载很重要吗？ 在几乎全部情形下，MapReduce要么会在从硬盘或者网络读取数据时遇到瓶颈（称为IO受限的应用），要么在处理数据时遇到瓶颈（CPU受限）。排序是一个IO受限的例子，它须要不多的CPU处理（仅仅是简单的比较操做），可是须要大量的从硬盘读写数据。模式分类是一个CPU受限的例子，它对数据进行复杂的处理，用来断定本体。 下面是更多IO受限的工做负载的例子： 索引 分组 数据导入导出 数据移动和转换 下面是更多CPU受限的工做负载的例子： 聚类/分类 复杂文本挖掘 天然语言处理 特征提取

Cloudera的客户须要彻底理解他们的工做负载，这样才能选择最优的Hadoop硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工做组在没有完全剖析他们的工做负载时，就已经搭建好了Hadoop集群，一般Hadoop运行的工做负载随着他们的精通程度的提升而彻底不一样。并且，某些工做负载可能会被一些未预料的缘由受限。例如，某些理论上是IO受限的工做负载却最终成为了CPU受限，这是多是由于用户选择了不一样的压缩算法，或者算法的不一样实现改变了MapReduce任务的约束方式。基于这些缘由，当工做组还不熟悉要运行任务的类型时，深刻剖析它才是构建平衡的Hadoop集群以前须要作的最合理的工做。

接下来须要在集群上运行MapReduce基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工做负载中的适当位置添加监视器来检测瓶颈。咱们推荐在Hadoop集群上安装Cloudera Manager，它能够提供CPU，硬盘和网络负载的实时统计信息。（Cloudera Manager是Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager安装以后，Hadoop管理员就能够运行MapReduce任务而且查看Cloudera Manager的仪表盘，用来监测每台机器的工做状况。

第一步是弄清楚你的做业组已经拥有了哪些硬件 在为你的工做负载构建合适的集群以外，咱们建议客户和它们的硬件提供商合做肯定电力和冷却方面的预算。因为Hadoop会运行在数十台，数百台到数千台节点上。经过使用高性能功耗比的硬件，做业组能够节省一大笔资金。硬件提供商一般都会提供监测功耗和冷却方面的工具和建议。

为你的CDH(Cloudera distribution for Hadoop) Cluster选择硬件 选择机器配置类型的第一步就是理解你的运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队常常根据必定的观点或者强制需求来选择，而且他们倾向于工做在本身业已熟悉的平台类型上。Hadoop不是惟一的从规模效率上获益的系统。再一次强调，做为更通用的建议，若是集群是新创建的或者你并不能准确的预估你的极限工做负载，咱们建议你选择均衡的硬件类型。 Hadoop集群有四种基本任务角色:名称节点（包括备用名称节点），工做追踪节点，任务执行节点，和数据节点。节点是执行某一特定功能的工做站。大部分你的集群内的节点须要执行两个角色的任务，做为数据节点（数据存储）和任务执行节点（数据处理）。

这是在一个平衡Hadoop集群中，为数据节点/任务追踪器提供的推荐规格： 在一个磁盘阵列中要有12到24个1~4TB硬盘 2个频率为2~2.5GHz的四核、六核或八核CPU 64~512GB的内存 有保障的千兆或万兆以太网（存储密度越大，须要的网络吞吐量越高） 名字节点角色负责协调集群上的数据存储，做业追踪器协调数据处理（备用的名字节点不该与集群中的名字节点共存，而且运行在与之相同的硬件环境上。）。Cloudera推荐客户购买在RAID1或10配置上有足够功率和企业级磁盘数的商用机器来运行名字节点和做业追踪器。

NameNode也会直接须要与群集中的数据块的数量成比列的RAM。一个好的但不精确的规则是对于存储在分布式文件系统里面的每个1百万的数据块，分配1GB的NameNode内存。于在一个群集里面的100个DataNodes而言，NameNode上的64GB的RAM提供了足够的空间来保证群集的增加。咱们也推荐把HA同时配置在NameNode和JobTracker上， 这里就是为NameNode／JobTracker／Standby NameNode节点群推荐的技术细节。驱动器的数量或多或少，将取决于冗余数量的须要。 4–6 1TB 硬盘驱动器 采用 一个  JBOD 配置 (1个用于OS, 2个用于文件系统映像[RAID 1], 1个用于Apache ZooKeeper, 1个用于Journal节点) 2 4-/16-/8-核心 CPUs, 至少运行于 2-2.5GHz 64-128GB 随机存储器 Bonded Gigabit 以太网卡 or 10Gigabit 以太网卡 记住, 在思想上，Hadoop 体系设计为用于一种并行环境。

若是你但愿Hadoop集群扩展到20台机器以上，那么咱们推荐最初配置的集群应分布在两个机架，并且每一个机架都有一个位于机架顶部的10G的以太网交换。当这个集群跨越多个机架的时候，你将须要添加核心交换机使用40G的以太网来链接位于机架顶部的交换机。两个逻辑上分离的机架可让维护团队更好地理解机架内部和机架间通讯对网络需求。 Hadoop集群安装好后，维护团队就能够开始肯定工做负载，并准备对这些工做负载进行基准测试以肯定硬件瓶颈。通过一段时间的基准测试和监视，维护团队将会明白如何配置添加的机器。异构的Hadoop集群是很常见的，尤为是在集群中用户机器的容量和数量不断增加的时候更常见-所以为你的工做负载所配置的“不理想”开始时的那组机器不是在浪费时间。Cloudera管理器提供了容许分组管理不一样硬件配置的模板，经过这些模板你就能够简单地管理异构集群了。

下面是针对不一样的工做负载所采用对应的各类硬件配置的列表，包括咱们最初推荐的“负载均衡”的配置： 轻量处理方式的配置(1U的机器）:两个16核的CPU，24-64GB的内存以及8张硬盘（每张1TB或者2TB)。 负载均衡方式的配置(1U的机器）:两个16核的CPU，48-128GB的内存以及由主板控制器直接链接的12-16张硬盘（每张1TB或者2TB)。一般在一个2U的柜子里使用2个主板和24张硬盘实现相互备份。 超大存储方式的配置(2U的机器）:两个16核的CPU，48-96GB的内存以及16-26张硬盘（每张2TB-4TB)。这种配置在多个节点/机架失效时会产生大量的网络流量。 强力运算方式的配置(2U的机器）:两个16核的CPU，64-512GB的内存以及4-8张硬盘（每张1TB或者2TB)。 （注意Cloudera指望你配置它可使用的2x8,2x10和2x12核心CPU的配置。) 下图向你展现了如何根据工做负载来配置一台机器：

其余要考虑的 记住Hadoop生态系统的设计是考虑了并行环境这点很是重要。当购买处理器时，咱们不建议购买最高频率(GHZ)的芯片，这些芯片都有很高的功耗（130瓦以上）。这么作会产生两个问题：电量消耗会更高和热量散发会更大。处在中间型号的CPU在频率、价格和核心数方面性价比是最好的。 当咱们碰到生成大量中间数据的应用时-也就是说输出数据的量和读入数据的量相等的状况-咱们推荐在单个以太网接口卡上启用两个端口，或者捆绑两个以太网卡，让每台机器提供2Gbps的传输速率。绑定2Gbps的节点最多可容纳的数据量是12TB。一旦你传输的数据超过12TB，你将须要使用传输速率为捆绑方式实现的4Gbps(4x1Gbps)。另外，对哪些已经使用10Gb带宽的以太网或者无线网络用户来讲，这样的方案能够用来按照网络带宽实现工做负载的分配。若是你正在考虑切换到10GB的以太网络上，那么请确认操做系统和BIOS是否兼容这样的功能。

当计算须要多少内存的时候，记住Java自己要使用高达10%的内存来管理虚拟机。咱们建议把Hadoop配置为只使用堆，这样就能够避免内存与磁盘之间的切换。切换大大地下降MapReduce任务的性能，而且能够经过给机器配置更多的内存以及给大多数Linux发布版以适当的内核设置就能够避免这种切换。 优化内存的通道宽度也是很是重要的。例如，当咱们使用双通道内存时，每台机器就应当配置成对内存模块（DIMM）。当咱们使用三通道的内存时，每台机器都应当使用三的倍数个内存模块（DIMM）。相似地，四通道的内存模块（DIMM)就应当按四来分组使用内存。

超越MapReduce Hadoop不只仅是HDFS和MapReduce；它是一个无所不包的数据平台。所以CDH包含许多不一样的生态系统产品（实际上不多仅仅作为MapReduce使用）。当你在为集群选型的时候，须要考虑的附加软件组件包括Apache HBase、Cloudera Impala和Cloudera Search。它们应该都运行在DataNode中来维护数据局部性。 关注资源管理是你成功的关键。 HBase是一个可靠的列数据存储系统，它提供一致性、低延迟和随机读写。Cloudera Search解决了CDH中存储内容的全文本搜索的需求，为新类型用户简化了访问，可是也为Hadoop中新类型数据存储提供了机会。Cloudera Search基于Apache Lucene/Solr Cloud和Apache Tika，而且为与CDH普遍集成的搜索扩展了有价值的功能和灵活性。基于Apache协议的Impala项目为Hadoop带来了可扩展的并行数据库技术，使得用户能够向HDFS和HBase中存储的数据发起低延迟的SQL查询，并且不须要数据移动或转换。

因为垃圾回收器（GC）的超时，HBase的用户应该留意堆的大小的限制。别的JVM列存储也面临这个问题。所以，咱们推荐每个区域服务器的堆最大不超过16GB。HBase不须要太多别的资源而运行于Hadoop之上，可是维护一个实时的SLAs，你应该使用多个调度器，好比使用fair and capacity 调度器，并协同Linux Cgroups使用。 Impala使用内存以完成其大多数的功能，在默认的配置下，将最多使用80％的可用RAM资源，因此咱们推荐，最少每个节点使用96GB的RAM。与MapReduce一块儿使用Impala的用户，能够参考咱们的建议 － “Configuring Impala and MapReduce for Multi-tenant Performance.” 也能够为Impala指定特定进程所需的内存或者特定查询所需的内存。

搜索是最有趣的订制大小的组件。推荐的订制大小的实践操做是购买一个节点，安装Solr和Lucene，而后载入你的文档群。一旦文档群被以指望的方式来索引和搜索，可伸缩性将开始做用。持续不断的载入文档群，直到索引和查询的延迟，对于项目而言超出了必要的数值 － 此时，这让你获得了在可用的资源上每个节点所能处理的最大文档数目的基数，以及不包括欲期的集群复制此因素的节点的数量总计基数。 结论 购买合适的硬件，对于一个Hapdoop群集而言，须要性能测试和细心的计划，从而全面理解工做负荷。然而，Hadoop群集一般是一个形态变化的系统，而Cloudera建议，在开始的时候，使用负载均衡的技术文档来部署启动的硬件。重要的是，记住，当使用多种体系组件的时候，资源的使用将会是多样的，而专一与资源管理将会是你成功的关键。 咱们鼓励你在留言中，加入你关于配置Hadoop生产群集服务器的经验！ Kevin O‘Dell 是一个工做于Cloudera的系统工程师。