记住Hadoop生态系统的设计是考虑了并行环境这点非常重要。当购买处理器时，我们不建议购买最高频率(GHZ)的芯片，这些芯片都有很高的功耗（130瓦以上）。这么做会产生两个问题：电量消耗会更高和热量散发会更大。处在中间型号的CPU在频率、价格和核心数方面性价比是最好的。
当我们碰到生成大量中间数据的应用时-也就是说输出数据的量和读入数据的量相等的情况-我们推荐在单个以太网接口卡上启用两个端口，或者捆绑两个以太网卡，让每台机器提供2Gbps的传输速率。绑定2Gbps的节点最多可容纳的数据量是12TB。一旦你传输的数据超过12TB，你将需要使用传输速率为捆绑方式实现的4Gbps(4x1Gbps)。另外，对哪些已经使用10Gb带宽的以太网或者无线网络用户来说，这样的方案可以用来按照网络带宽实现工作负载的分配。如果你正在考虑切换到10GB的以太网络上，那么请确认操作系统和BIOS是否兼容这样的功能。
当计算需要多少内存的时候，记住Java本身要使用高达10%的内存来管理虚拟机。我们建议把Hadoop配置为只使用堆，这样就可以避免内存与磁盘之间的切换。切换大大地降低MapReduce任务的性能，并且可以通过给机器配置更多的内存以及给大多数Linux发布版以适当的内核设置就可以避免这种切换。
优化内存的通道宽度也是非常重要的。例如，当我们使用双通道内存时，每台机器就应当配置成对内存模块（DIMM）。当我们使用三通道的内存时，每台机器都应当使用三的倍数个内存模块（DIMM）。类似地，四通道的内存模块（DIMM)就应当按四来分组使用内存。
超越MapReduceHadoop不仅仅是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的系统工程师。