With Apache Hadoop taking off, the number one problem facing cloud customers is how to choose the right hardware for their new Hadoop clusters.
Although Hadoop is designed to run on industry-standard hardware, coming up with an ideal cluster configuration is not as simple as providing a list of hardware specifications. Selecting hardware that provides the best balance of performance and economics for a given workload requires testing and validating its effectiveness. (For example, users of IO-intensive workloads will invest more per core spindle).
In this blog post, you'll learn some of the principles of workload evaluation and the crucial role it plays in hardware selection. Along the way, you'll also learn that a Hadoop administrator should take into account various factors.
Combining storage and computing
Over the past decade, IT organizations have standardized on blade servers and storage area networks (SANs) for networking and processing-intensive workloads. Although this model is quite meaningful for standard programs in some areas, such as web servers, program servers, small structured databases, data movement, etc., as the number of data and users has grown, the requirements for infrastructure have also changed . Web servers now have a caching layer; databases require local hard drives to support massive parallelism; and the amount of data migration exceeds what can be handled locally.
Most teams start building their Hadoop clusters without knowing the actual workload requirements.
Hardware providers have produced innovative product systems to address these needs, including storage blade servers, serial SCSI switches, external SATA disk arrays and high-capacity rack units. However, Hadoop is based on new implementations to store and process complex data with reduced data migration. Rather than relying on SANs for mass storage and reliability, Hadoop handles big data and reliability at the software level.
Hadoop distributes data across a balanced cluster of nodes and uses synchronous replication to ensure data availability and fault tolerance. Because the data is distributed to the nodes with computing power, the processing of the data can be sent directly to the nodes where the data is stored. Since each node in a Hadoop cluster stores and processes data, these nodes need to be configured to meet data storage and computing requirements.
Does workload matter?
In almost all cases, MapReduce will either encounter a bottleneck in reading data from disk or the network (called an IO-bound application), or in processing the data (CPU-bound). Sorting is an IO-bound example that requires very little CPU processing (just simple comparison operations), but requires a lot of reading and writing data from disk. Pattern classification is a CPU-bound example of complex processing of data to determine ontologies.
Here are more examples of IO-bound workloads:
- index
- grouping
- Data import and export
- Data movement and transformation
Here are more examples of CPU-bound workloads:
- Clustering/Classification
- complex text mining
- natural language processing
- Feature extraction
Cloudera's customers need to fully understand their workloads in order to choose the optimal Hadoop hardware, which seems like a chicken-and-egg problem. Most workgroups set up Hadoop clusters without thoroughly dissecting their workloads, and often Hadoop runs workloads that vary widely as they become more proficient. Also, some workloads may be limited for some unforeseen reasons. For example, some workloads that were theoretically IO-bound ended up being CPU-bound, either because the user chose a different compression algorithm, or a different implementation of the algorithm changed the way MapReduce tasks are constrained. For these reasons, when the workgroup is not yet familiar with the types of tasks to run, profiling it is the most logical thing to do before building a balanced Hadoop cluster.
The next step is to run MapReduce benchmark tasks on the cluster and analyze how they are limited. The most straightforward way to accomplish this goal is to add monitors in place in the running workload to detect bottlenecks. We recommend installing Cloudera Manager on a Hadoop cluster, which provides real-time statistics on CPU, disk, and network load. (Cloudera Manager is a component of Cloudera Standard and Enterprise Editions, and Enterprise Edition also supports rolling upgrades.) After Cloudera Manager is installed, Hadoop administrators can run MapReduce tasks and view Cloudera Manager's dashboard to monitor the performance of each machine. working condition.
The first step is to figure out what hardware your workgroup already has
在为你的工作负载构建合适的集群之外，我们建议客户和它们的硬件提供商合作确定电力和冷却方面的预算。由于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期望你配置它可以使用的2×8,2×10和2×12核心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的系统工程师。
英文原文：How-to: Select the Right Hardware for Your New Hadoop Cluster
翻译：http://www.oschina.net/translate/how-to-select-the-right-hardware-for-your-new-hadoop-cluster
附：
淘宝Hadoop集群机器硬件配置
国内外使用Hadoop的公司比较多，全球最大的Hadoop集群在雅虎，有大约25000个节点，主要用于支持广告系统与网页搜索。国内用Hadoop的主要有百度、淘宝、腾讯、华为、中国移动等，其中淘宝的Hadoop集群属于较大的（如果不是最大）。
淘宝Hadoop集群现在超过1700个节点，服务于用于整个阿里巴巴集团各部门，数据来源于各部门产品的线上数据库（Oracle, MySQL）备份，系统日志以及爬虫数据，截止2011年9月，数量总量已经超过17个PB，每天净增长20T左右。每天在Hadoop集群运行的MapReduce任务有超过4万（有时会超过6万），其中大部分任务是每天定期执行的统计任务，例如数据魔方、量子统计、推荐系统、排行榜等等。这些任务一般在凌晨1点左右开始执行，3-4个小时内全部完成。每天读数据在2PB左右，写数据在1PB左右。
Hadoop包括两类节点Master和Slave节点，
- Master节点包括Jobtracker，Namenode, SecondName, Standby，
- 硬件配置：16CPU*4核，96G内存。
- Slave节点主要是TaskTracker和DataNode，
- 硬件配置存在一定的差别：8CPU*4核-16CPU*4核，16G-24G内存
- （注：通常是一个slave节点同时是TaskTracker和DataNode，目的是提高数据本地性data locality）。
- 每个slave节点会划分成12~24个slots。整个集群约34,916个slots，其中Map slots是19,643个，Reduce slots是15，273个
所有作业会进行分成多个Group，按照部门或小组划分，总共有38个Group。整个集群的资源也是按各个Group进行划分，定义每个Group的最大并发任务数，Map slots与Reduce slots的使用上限。每个作业只能使用自己组的slots资源。