本节书摘来自华章出版社《Hadoop集群与安全》一书中的第1章，第1.1节，作者 （美）Danil Zburivsky Sudheesh Narayanan，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.1 选择Hadoop集群硬件
Hadoop是可扩展的集群，它采用非共享系统处理大规模并行数据。Hadoop的总体概念是单个节点对于整个集群的稳定性和性能来说并不重要。根据这种设计理念，我们可以在单个节点上选择能够高效处理少量（相对于整体的数据量大小）数据的硬件并且在硬件层面也无需过分追求稳定性和冗余性。读者可能已经知道，Hadoop集群由多种类型的服务器所组成。它们中有主节点，比如NameNode、备份NameNode以及JobTracker，还有称为DataNode的工作节点。除了核心的Hadoop成员外，我们通常还会采用多种辅助服务器，比如网关、Hue服务器以及Hive元存储服务器。典型的Hadoop集群结构如图1-1所示。
这些类型的服务器在集群中各有分工，因此对于节点的硬件规格和可靠性要求也不尽相同。我们首先讨论针对DataNode的不同硬件配置，随后讲解有关NameNode和JobTracker的典型配置。
1.1.1 选择DataNode硬件
DataNode是Hadoop集群中的主要工作节点，它的作用主要有以下两种：存储分布式文件系统数据以及执行MapReduce任务。DataNode是Hadoop的主要存储和计算资源。有些读者可能认为既然DataNode在集群中扮演了如此重要的角色，我们就应该尽可能地使用最好的硬件。事实并非如此。在Hadoop的设计理念中将DataNode定义为“临时工”，也就是说，服务器作为集群的一部分需要足够高效地完成任务，同时在出现故障时替换的成本不会太过昂贵。在大型集群中的硬件故障频率可能是核心Hadoop开发者所考虑的最为重要的因素之一。Hadoop通过将冗余实现从硬件迁移到了软件解决了这一问题。
Hadoop提供了多种级别的冗余。每个DataNode只存储了分布式文件系统文件的部分数据块，同时这些分块在不同节点中进行了多次复制，因此在单个服务器故障时，数据仍然能保证可访问性。根据读者选择的配置，集群甚至能够承受多个故障节点。除此之外，Hadoop还允许我们指定服务器位于机架上的位置并且在不同的机架上存储多份数据副本，这样即使在整个机架的服务器发生故障时也能极大地增加数据的可访问性（尽管这并不能严格地保证）。这种设计理念意味着我们无需为Hadoop DataNode采用独立磁盘冗余阵列（RAID）控制器。
我们可以为本地磁盘使用一种称为简单磁盘捆绑（JBOD）的配置来代替RAID。它为Hadoop的工作负载提供了更加出色的性能并且减少了硬件成本。由于冗余性是由分布式文件系统提供的，因此我们不必担心单个磁盘发生故障。
存储数据是DataNode的首要工作。它的第二个工作是作为数据处理节点运行自定义的MapReduce代码。MapReduce作业有多种不同的任务组成，它们在多个DataNode中并列执行并且在所有子任务都完成后作业才能生成逻辑上的统一结果。
因此Hadoop需要在存储和计算层面都提供冗余性。Hadoop通过在不同节点上重新执行失败的任务来实现这点，这样就不会扰乱整体作业。同样它会跟踪那些故障率较高、响应速度较慢的节点，最终这些节点会被列入到黑名单中并且从集群中剔除。
那么典型的DataNode需要配置何种硬件呢？在理想情况下，DataNode应该是一个平衡的系统，它应该拥有适量的磁盘存储容量以及运行功率。定义“平衡的系统”和“适量的存储容量”并不像听起来那么容易。在我们尝试构建具有可扩展性的最佳Hadoop集群时有需要考虑的因素。其中最重要的问题之一是集群的总存储量以及集群存储密度。这些参数关系密切。总存储量相对比较容易进行估算。基本上只需要了解集群中容纳的数据量就能够解决问题。根据下面的步骤读者可以估算集群中所需的存储量。
- 确定数据源：列举所有已知的数据源并且确认是否需要引入所有或者部分数据。读者应该保留群集总存储量的15%～20%，甚至更多，这是为新数据源或者未知的数据增长预留的容量。
- 估算数据增长率：每个确定的数据源都有对应的数据摄入率。举例来说，读者准备从OLTP数据库中进行导出，我们可以清楚地估算出该数据源在特定时间段内所生成的数据量。当然，读者也需要进行一些导出测试来获得准确的数字。
- 将估算的存储量乘以副本因子（replication factor）：到目前为止，我们所讨论的都是可用存储量。Hadoop通过将数据块进行多次复制并将它们放置在集群中的不同节点中来实现分布式文件系统层面的冗余性。默认情况下，每个分块都会进行3次复制。通过增加或者减少副本因子，读者可以对该参数进行调整。将副本因子设置为1并不可取，因为这样集群中就不存在任何的可靠性。我们首先应该获取集群存储量的估算值，然后将它乘以副本因子。如果读者估算今年需要300TB的可用容量并且所设置的副本因子为3，那么我们所需的存储量大约为900TB。
- 考虑MapReduce临时文件以及系统数据：MapReduce任务在映射（map）执行和化简（Reduce）步骤之间会生成中间数据。这些临时数据并不位于分布式文件系统中，因此读者需要为临时文件预留服务器磁盘总量的25%～30%。此外，还应该为操作系统预留单独的磁盘分卷，但是操作系统的存储要求通常并不重要。
确定所有可用以及原始的集群存储量是选择DataNode硬件标准的第一步。为了更进一步进行讨论，我们将集群所有可用的存储量称为原始容量，从硬件角度来说这点是非常重要的。另一个重要的标准是数据密度，它是集群总存储量与DataNode数量之间的商。通常我们有两种选择：采用大量配置低存储密度的服务器或者使用少量具有高存储密度的服务器。我们将对这两者进行介绍同时加以比较。
1.1.2 低存储密度集群
一直以来Hadoop集群都采用低存储密度的服务器。这样我们就可以使用市面上的低密度硬盘将集群的能力扩展到PB级别。尽管在最近数年中硬盘的容量有了大幅的增加，但是使用大型低密度集群仍然是大部分人的选择。成本是让我们进行如此选择的主要原因。单个Hadoop节点的性能与存储量以及RAM/CPU与硬盘之间的平衡有关。如果在每个DataNode上都有较大的数据量，但是却没有足够的RAM和CPU资源来进行处理，这种情况在大部分项目中都是不可取的。
对于Hadoop集群硬件给出具有针对性的建议始终是一件很困难的事情。一个平衡的配置取决于集群的工作负载以及分配的预算。市面上不断有新的硬件推出，因此我们所考虑的问题也应该相应进行调整。我们采用下面的示例来讲解低密度集群的硬件选择。
假设我们选择了一个配有6个硬盘驱动器（HDD）插槽的服务器。如果我们采用价格相对低廉的2TB硬盘，那么在每台服务器上我们将拥有12TB的原始容量。
我们没有必要在集群中采用读写速度超过15000rpm的硬盘。在集群中，比起随机的访问速度，连贯的读写性能更为重要。在大部分情况下7200rpm的硬件是一个更好的选择。
对于低密度服务器，我们主要的目标是控制成本来承载大型的服务器。2×4核的CPU正符合我们的要求并且能提供所需的处理能力。每项map或者reduce任务都会采用单个CPU核，由于在输入输出时需要进行等待，因此我们也可以采用更多核的CPU。对于8核的处理器，我们在每个节点上大概可以配置12个map/reduce空位。
每项任务需要2～4GB的内存。对于该类型的服务器，我们可以采用36GB的内存，当然48GB的内存更为理想。请注意，我们正在尝试平衡各种不同的组件，在配置中仅仅增加内存的容量只是徒劳，因为我们不能在单个节点上合理分配任务。
假设准备在集群中存储500TB的数据。在默认副本因子为3的情况下，我们需要1500TB的原始容量。如果使用低密度DataNode配置，那么我们应采用63台服务器来满足需求。如果将所需容量进行翻倍，那么我们需要在集群中使用超过100台服务器。管理大量的服务器本身就是一项富有挑战的任务。我们需要考虑是否有足够的空间来容纳新增的机架。当服务器数量增加时，额外的能耗以及温度调节都是一项巨大的挑战。要解决这些问题，我们可以增加单个服务器的存储量，同时对其他的硬件标准进行调整。
1.1.3 高存储密度集群
许多企业致力于开发小型的Hadoop集群，其中每台服务器上都有更大的存储量以及更强的计算能力。除了解决上述的问题之外，在不优先考虑大量数据的情况下适合采用这种类型的集群，这种集群适合处理具有计算密集的工作，如机器学习、探索分析以及其他问题等。
高密度集群的组件选择以及平衡与低密度集群相同。在本例中，我们可以选择16块2TB的硬盘或者24块1TB的硬盘。在每台服务器上选择低容量的硬盘更为合理，因为这将提供更为高效的输入输出以及更强的容错能力。我们使用16核的CPU以及96GB的内存来增加单台机器的计算能力。
1.1.4 NameNode和JobTracker硬件配置
Hadoop采用中央协调模型，也就是说，有单个节点（或者一组节点）用于在组成集群的服务器之间协调任务。用于分布式文件系统协调的服务器称为NameNode，负责MapReduce作业分配的服务器称为JobTracker。实际上，NameNode和JobTracker都是Hadoop的不同进程，但是由于在大部分情况下的这两种服务的重要性，这些服务通常运行在指定的服务器上。
NameNode硬件
NameNode对于分布式文件系统的可用性非常关键。它存储了所有文件系统的元数据：文件由哪些分块组成、在哪些DataNode上可以查找到这些分块、可用分块的数量以及作为宿主的服务器。如果没有NameNode，分布式文件系统中的数据几乎没有任何用处。数据本身没有变化，但是如果没有NameNode就无法从数据分块中重组文件，同时我们也无法上传新的数据。一直以来，NameNode都是一块短板，和号称诸多组件和进程都具有高容错性以及冗余性的系统来说并不相称。在Apache Hadoop 2.0中引入的NameNode高可用性设置解决了这一问题，但是NameNode的硬件要求与前一节中的DataNode仍然有很大的区别。我们首先对NameNode所需的内存进行估算。NameNode存储了所有分布式文件系统的元数据，其中包括文件、目录结构以及内存中的分块分配。这听起来可能浪费了内存，但是NameNode必须保证大量服务器对于文件的快速访问，因此使用硬盘进行信息访问并不能达到预期的速度。根据Apache Hadoop文档，每个分布式文件系统分块在NameNode的内存中大小约为250个字节，此外还要加上文件和目录所需的250字节空间。假设我们有5000个平均大小为20GB的文件并且使用默认的分布式文件系统分块大小（64MB）同时副本因子为3，那么NameNode需要保存5千万个分块的信息，这些分块的大小加上文件系统的开销总共需要1.5GB的内存。但是一切并非读者想象的那样，在大部分情况下Hadoop集群会有更多的文件并且每个文件至少由一个分块组成，因此NameNode上的内存使用率会更高。所以根据集群的要求，我们应该预留空间为NameNode配置更多的内存。为NameNode服务器配备64～94GB的内存是一个不错的选择。
为了保证文件系统元数据的稳定性，NameNode还需要在硬盘上保存内存结构的一份副本。NameNode维护editlog文件，其中捕获了所有分布式文件系统中发生的变化，比如新文件和目录的创建以及副本因子的修改。它和大部分关系数据库采用的重做日志文件非常类似。除了editlog文件外，NameNode还在fsimage文件中维护当前分布式文件系统元数据状态的完整快照。在重新启动或者服务器崩溃时，NameNode会使用最新的fsimage文件，同时根据editlog文件中的变化将文件系统还原成即时可用状态。
和传统的数据库不同，NameNode定期性地将editlog文件中的变化传送到fsimage文件中，这项任务分配给称为备份节点的独立服务器。这么做能够控制editlog文件的大小，因为传送到fsimage文件中的变化在日志文件中已经不需要了，同时还可以将恢复时间最小化。由于这些文件是NameNode保存在内存中的文件结构镜像，因此它们所占的硬盘空间并不大。fsimage文件的大小不会超过我们分配给NameNode的内存量，当editlog文件达到默认的64MB大小时会重新进行调整，也就是说可以将NameNode的硬盘空间需求控制在500GB的范围内。我们有必要在NameNode中使用RAID，因此当磁盘崩溃时它会对其中的重要数据进行保护。除了为满足分布式文件系统客户端的文件系统请求外，NameNode同样需要处理集群中所有DataNode的心跳信息。这种类型的工作负载需要巨大的CPU资源，因此根据规划的集群大小，我们最好为NameNode提供8～16核的CPU。
在本书中我们将重点放在构建NameNode高可用方案上，它要求主从NameNode在硬件层面上保持一致。更多有关NameNode高可用方案的细节请参见第2章。
JobTracker硬件
除了NameNode和备份NameNode外，在Hadoop集群中还有另一个称为JobTracker的主服务器。从概念上讲，它在MapReduce框架中的作用和分布式文件系统中的NameNode相似。JobTracker负责向运行TaskTracker—在每个DataNode上的服务提交用户作业。除此之外，JobTracker在内存中保留了最近执行的作业历史（数量可以进行配置）并且提供对Hadoop指定或者用户定义的作业计数器访问。可用内存量对JobTracker非常重要，通常情况下它的内存占用量（memory footprint）要小于NameNode。对于中型以及大型的集群大约需要配置24～48GB的内存。如果读者构建的集群是一个多租户环境请自行对该配置调整。默认情况下，JobTracker不会在硬盘上存储任何状态信息，它只会将永久存储作为日志使用，也就是说该服务的磁盘需求并不大。和NameNode类似，JobTracker同样需要处理大量来自TaskTracker的心跳信息，接收和分配输入的用户作业并且根据作业分配算法最高效地利用集群。这是一项CPU高度密集型任务，因此和NameNode类似，我们应该为其配置高速的多核处理器。
这三种类型的主节点对于Hadoop集群可用性都很重要。如果NameNode服务发生故障，那么我们将无法访问分布式文件系统数据。备份NameNode的故障不会造成即时中断，但是会延迟文件系统的检查点过程。同样，JobTracker的崩溃将导致所有运行中的MapReduce作业中止并且新的作业将无法得到执行。所有这些结果都要求我们为主节点选择与DataNode不同的硬件。为重要的数据采用RAID阵列、冗余网络以及电源，采用更高端的企业级硬件组件都是不错的选择。
1.1.5 网关和其他辅助服务
网关服务器是Hadoop集群中的客户端访问点。同分布式文件系统中的数据进行交互要求客户端程序与集群内部的节点进行连接。从网络设计以及安全角度考虑这始终不符合实际。因此网关通常部署在主集群子网的外部并且用于数据导入和其他用户程序。其他基础设施组件以及不同命令解释器（shell）可以部署在单独的服务器上，或者配合其他服务使用。这些可选服务的硬件要求远低于集群中的节点，通常我们可以在虚拟机中部署网关。对于网关节点，4～8核的CPU以及16～24GB的内存是一个比较合理的配置。
1.1.6 网络配置
在Hadoop集群中，网络和CPU、磁盘或者内存同样重要。分布式文件系统依赖网络通信对当前文件系统状态下的NameNode进行更新、向客户端接收以及发送数据分块。MapReduce作业同样使用网络传输状态信息，通过带宽从远程DataNode上读取文件分块以及从map接口向reduce接口发送中间数据。总而言之，在Hadoop集群中包含了许多网络活动（network activity）。对于网络硬件我们主要有两种选择。1千兆位以太网网络成本低廉，但是吞吐量有限。10千兆位以太网网络会大大增加Hadoop的部署成本。和集群中的其他组件类似，网络的选择取决于集群的布局。
对于大型的集群，我们通常采用较低规范的硬件，假设服务器上的分卷能够提供足够的容量，那么我们可以尽可能少地配置磁盘、内存以及节点CPU。对于小型的集群，我们应该选择高端的服务器。在选择使用的网络架构时我们可以采用同样的参数。
如果集群中节点的流量不是很大，那么安装10千兆位以太网网络没有太大的意义，原因主要有两个。首先这会大大增加构建集群的总成本，同时读者也未必能够完全使用所有的网络功能。例如，在每个DataNode上有6块磁盘，那么读者可以获得大约420MB/s的本地写入速度，而该数值小于网络带宽，也就是说集群的瓶颈从网络变为了磁盘的输入输出能力。从另一方面来说，由高速服务器组成的小型集群中的大量数据很有可能会在1千兆位以太网网络中堵塞，从而导致服务器的大部分可用资源浪费。该类型集群规模通常都不是很大，10千兆位以太网网络硬件对于大型集群的构建成本不会产生太大的影响。
大部分最新的服务器都有多个网络控制器。读者可以使用绑定来增加网络吞###吐量（network throughput）。
1.1.7 Hadoop硬件总结
下面我们来总结不同类型的集群对应的Hadoop硬件配置。
低存储密度集群中的DataNode配置参见表1-1。
高存储密度集群中的DataNode配置参见表1-2。
NameNode和备份NameNode配置参见表1-3。
JobTracker的配置参见表1-4。
