您所在的位置： &
深入理解Hadoop集群和网络
深入理解Hadoop集群和网络
Brad Hedlund
本文将着重于讨论Hadoop集群的体系结构和方法，及它如何与网络和服务器基础设施的关系。最开始我们先学习一下Hadoop集群运作的基础原理。
云计算和Hadoop中网络是讨论得相对比较少的领域。本文原文由Dell企业技术专家撰写，他曾在思科工作多年，专长是数据中心、云网络等。文章素材基于作者自己的研究、实验和Cloudera的培训资料。
本文将着重于讨论Hadoop集群的体系结构和方法，及它如何与网络和服务器基础设施的关系。最开始我们先学习一下Hadoop集群运作的基础原理。
Hadoop里的服务器角色
Hadoop主要的任务部署分为3个部分，分别是：Client机器，主节点和从节点。主节点主要负责Hadoop两个关键功能模块HDFS、Map Reduce的监督。当Job Tracker使用Map Reduce进行监控和调度数据的并行处理时，名称节点则负责HDFS监视和调度。从节点负责了机器运行的绝大部分，担当所有数据储存和指令计算的苦差。每个从节点既扮演者数据节点的角色又冲当与他们主节点通信的守护进程。守护进程隶属于Job Tracker，数据节点在归属于名称节点。
Client机器集合了Hadoop上所有的集群设置，但既不包括主节点也不包括从节点。取而代之的是客户端机器的作用是把数据加载到集群中，递交给Map Reduce数据处理工作的描述，并在工作结束后取回或者查看结果。在小的集群中（大约40个节点）可能会面对单物理设备处理多任务，比如同时Job Tracker和名称节点。作为大集群的中间件，一般情况下都是用独立的服务器去处理单个任务。
在真正的产品集群中是没有虚拟服务器和管理层的存在的，这样就没有了多余的性能损耗。Hadoop在Linux系统上运行的最好，直接操作底层硬件设施。这就说明Hadoop实际上是直接在虚拟机上工作。这样在花费、易学性和速度上有着无与伦比的优势。
Hadoop集群
上面是一个典型Hadoop集群的构造。一系列机架通过大量的机架转换与机架式服务器（不是刀片服务器）连接起来，通常会用1GB或者2GB的宽带来支撑连接。10GB的带宽虽然不常见，但是却能显著的提高CPU核心和磁盘驱动器的密集性。上一层的机架转换会以相同的带宽同时连接着许多机架，形成集群。大量拥有自身磁盘储存器、CPU及DRAM的服务器将成为从节点。同样有些机器将成为主节点，这些拥有少量磁盘储存器的机器却有着更快的CPU及更大的DRAM。
下面我们来看一下应用程序是怎样运作的吧：
adoop的工作流程
在计算机行业竞争如此激烈的情况下，究竟什么是Hadoop的生存之道？它又切实的解决了什么问题？简而言之，商业及政府都存在大量的数据需要被快速的分析和处理。把这些大块的数据切开，然后分给大量的计算机，让计算机并行的处理这些数据 & 这就是Hadoop能做的。
下面这个简单的例子里，我们将有一个庞大的数据文件（给客服部门的电子邮件）。我想快速的截取下&Refund&在邮件中出现的次数。这是个简单的字数统计练习。Client将把数据加载到集群中（File.txt），提交数据分析工作的描述（word cout），集群将会把结果储存到一个新的文件中（Results.txt），然后Client就会读结果文档。
向HDFS里写入File
Hadoop集群在没有注入数据之前是不起作用的，所以我们先从加载庞大的File.txt到集群中开始。首要的目标当然是数据快速的并行处理。为了实现这个目标，我们需要竟可能多的机器同时工作。最后，Client将把数据分成更小的模块，然后分到不同的机器上贯穿整个集群。模块分的越小，做数据并行处理的机器就越多。同时这些机器机器还可能出故障，所以为了避免数据丢失就需要单个数据同时在不同的机器上处理。所以每块数据都会在集群上被重复的加载。Hadoop的默认设置是每块数据重复加载3次。这个可以通过hdfs-site.xml文件中的dfs.replication参数来设置。
Client把File.txt文件分成3块。Cient会和名称节点达成协议（通常是TCP 9000协议）然后得到将要拷贝数据的3个数据节点列表。然后Client将会把每块数据直接写入数据节点中（通常是TCP 50010协议）。收到数据的数据节点将会把数据复制到其他数据节点中，循环只到所有数据节点都完成拷贝为止。名称节点只负责提供数据的位置和数据在族群中的去处（文件系统元数据）。
Hadoop的Rack Awareness
Hadoop还拥有&Rack Awareness&的理念。作为Hadoop的管理员，你可以在集群中自行的定义从节点的机架数量。但是为什么这样做会给你带来麻烦呢？两个关键的原因是：数据损失预防及网络性能。别忘了，为了防止数据丢失，每块数据都会拷贝在多个机器上。假如同一块数据的多个拷贝都在同一个机架上，而恰巧的是这个机架出现了故障，那么这带来的绝对是一团糟。为了阻止这样的事情发生，则必须有人知道数据节点的位置，并根据实际情况在集群中作出明智的位置分配。这个人就是名称节点。
假使通个机架中两台机器对比不同机架的两台机器会有更多的带宽更低的延时。大部分情况下这是真实存在的。机架转换的上行带宽一般都低于其下行带宽。此外，机架内的通信的延时一般都低于跨机架的（也不是全部）。那么假如Hadoop能实现&Rack Awareness&的理念，那么在集群性能上无疑会有着显著的提升！是的，它真的做到了！太棒了，对不对？
但是扫兴的事情发生了，首次使用你必须手动的去定义它。不断的优化，保持信息的准确。假如机架转换能够自动的给名称节点提供它的数据节点列表，这样又完美了？或者反过来，数据节点可以自行的告知名称节点他们所连接的机架转换，这样也的话也同样完美。
在括补结构中网络中，假如能知道名称节点可以通过OpenFlow控制器查询到节点的位置，那无疑是更加令人兴奋的。
准备HDFS写入
现在Client已经把File.txt分块并做好了向集群中加载的准备，下面先从Block A开始。Client向名称节点发出写File.txt的请求，从名称节点处获得通行证，然后得到每块数据目标数据节点的列表。名称节点使用自己的Rack Awareness数据来改变数据节点提供列表。核心规则就是对于每块数据3份拷贝，总有两份存在同一个机架上，另外一份则必须放到另一个机架上。所以给Client的列表都必须遵从这个规则。
在Client将File.txt的&Block A&部分写入集群之前，Client还期待知道所有的目标数据节点是否已准备就绪。它将取出列表中给Block A准备的第一个数据节点，打开TCP 50010协议，并告诉数据节点，注意！准备好接收1块数据，这里还有一份列表包括了数据节点5和数据节点6，确保他们同样已准备就绪。然后再由1传达到5，接着5传达到6。
数据节点将从同样的TCP通道中响应上一级的命令，只到Client收到原始数据节点1发送的的&就绪&。只到此刻，Client才真正的准备在集群中加载数据块。
HDFS载入通道
当数据块写入集群后，3个（当然数据节点个数参照上文的设置）数据节点将打开一个同步通道。这就意味着，当一个数据节点接收到数据后，它同时将在通道中给下一个数据节点送上一份拷贝。
这里同样是一个借助Rack Awareness数据提升集群性能的例子。注意到没有，第二个和第三个数据节点运输在同一个机架中，这样他们之间的传输就获得了高带宽和低延时。只到这个数据块被成功的写入3个节点中，下一个就才会开始。
HDFS通道载入成功
当3个节点都成功的接收到数据块后，他们将给名称节点发送个&Block Received&报告。并向通道返回&Success&消息，然后关闭TCP回话。Client收到成功接收的消息后会报告给名称节点数据已成功接收。名称节点将会更新它元数据中的节点位置信息。Client将会开启下一个数据块的处理通道，只到所有的数据块都写入数据节点。
Hadoop会使用大量的网络带宽和存储。我们将代表性的处理一些TB级别的文件。使用Hadoop的默认配置，每个文件都会被复制三份。也就是1TB的文件将耗费3TB的网络传输及3TB的磁盘空间。
Client写入跨度集群
每个块的复制管道完成后的文件被成功写入到集群。如预期的文件被散布在整个集群的机器，每台机器有一个相对较小的部分数据。个文件的块数越多，更多的机器的数据有可能传播。更多的CPU核心和磁盘驱动器，意味着数据能得到更多的并行处理能力和更快的结果。这是建造大型的、宽的集群的背后的动机，为了数据处理更多、更快。当机器数增加和集群增宽时，我们的网络需要进行适当的扩展。
扩展集群的另一种方法是深入。就是在你的机器扩展更多个磁盘驱动器和更多的CPU核心，而不是增加机器的数量。在扩展深度上，你把自己的注意力集中在用较少的机器来满足更多的网络I/O需求上。在这个模型中，你的Hadoop集群如何过渡到万兆以太网节点成为一个重要的考虑因素。
名称节点包含所有集群的文件系统元数据和监督健康状况的数据节点以及协调对数据的访问。这个名字节点是HDFS的中央控制器。它本身不拥有任何集群数据。这个名称节点只知道块构成一个文件，并在这些块位于集群中。
数据节点每3秒通过TCP信号交换向名称节点发送检测信号，使用相同的端口号定义名称节点守护进程，通常TCP 9000。每10个检测信号作为一个块报告，那里的数据节点告知它的所有块的名称节点。块报告允许名称节点构建它的元数据和确保第三块副本存在不同的机架上存在于不同的节点上。
名称节点是Hadoop分布式文件系统（HDFS）的一个关键组件。没有它，客户端将无法从HDFS写入或读取文件，它就不可能去调度和执行Map Reduce工作。正因为如此，用双电源、热插拔风扇、冗余网卡连接等等来装备名称节点和配置高度冗余的企业级服务器使一个不错的想法。
重新复制缺失副本
如果名称节点停止从一个数据节点接收检测信号，假定它已经死亡，任何数据必须也消失了。基于块从死亡节点接受到报告，这个名称节点知道哪个副本连同节点块死亡，并可决定重新复制这些块到其他数据节点。它还将参考机架感知数据，以保持在一个机架内的两个副本。
考虑一下这个场景，整个机架的服务器网络脱落，也许是因为一个机架交换机故障或电源故障。这个名称节点将开始指示集群中的其余节点重新复制该机架中丢失的所有数据块。如果在那个机架中的每个服务器有12TB的数据，这可能是数百个TB的数据需要开始穿越网络。
二级名称节点
Hadoop服务器角色被称为二级名称节点。一个常见的误解是，这个角色为名称节点提供了一个高可用性的备份，这并非如此。
二级名称节点偶尔连接到名字节点，并获取一个副本的名字节点内存中的元数据和文件用于存储元数据。二级名称节点在一个新的文件集中结合这些信息，并将其递送回名称节点，同时自身保留一份复本。
如果名称节点死亡，二级名称节点保留的文件可用于恢复名称节点。
从HDFS客户端读取
当客户想要从HDFS读取一个文件，它再一次咨询名称节点，并要求提供文件块的位置。
客户从每个块列表选择一个数据节点和用TCP的50010端口读取一个块。直到前块完成，它才会进入下一个块。
从HDFS中读取数据节点
有些情况下，一个数据节点守护进程本身需要从HDFS中读取数据块。一种这样的情况是数据节点被要求处理本地没有的数据，因此它必须从网络上的另一个数据节点检索数据，在它开始处理之前。
另一个重要的例子是这个名称节点的Rack Awareness认知提供了最佳的网络行为。当数据节点询问数据块里名称节点的位置时，名称节点将检查是否在同一机架中的另一种数据节点有数据。如果是这样，这个名称节点从检索数据里提供了机架上的位置。该流程不需要遍历两个以上的交换机和拥挤的链接找到另一个机架中的数据。在机架上检索的数据更快，数据处理就可以开始的更早，,工作完成得更快。
现在file.txt在我的机器集群中蔓延，我有机会提供极其快速和高效的并行处理的数据。包含Hadoop的并行处理框架被称为Map Reduce，模型中命名之后的两个步骤是Map和Reduce。
第一步是Map过程。这就是我们同时要求我们的机器他们本地的数据块上来运行一个计算。在这种情况下，我们要求我们的机器对&Refund&这个词在File.txt的数据块中出现的次数进行计数。
开始此过程，客户端机器提交Map Reduce作业的Job Tracker，询问&多少次不会在File.txt 中出现Refund&(意译Java代码)。Job Tracker查询名称节点了解哪些数据节点有File.txt块。Job Tracker提供了这些节点上运行的Task Tracker与Java代码需要在他们的本地数据上执行的Map计算。这个Task Tracker启动一个Map任务和监视任务进展。这Task Tracker提供了检测信号并向Job Tracker返回任务状态。
每个Map任务完成后，每个节点在其临时本地存储中存储其本地计算的结果。这被称作&中间数据&。 下一步将通过网络传输发送此中间数据到Reduce任务最终计算节点上运行。
Map Task非本地
虽然Job Tracker总是试图选择与当地数据做Map task的节点，但它可能并不总是能够这样做。其中一个原因可能是因为所有的节点与本地数据，已经有太多的其他任务运行，并且不能接受了。
在这种情况下, Job Tracker将查阅名称节点的Rack Awareness知识，可推荐同一机架中的其他节点的名称节点。作业跟踪器将把这个任务交给同一机架中的一个节点，节点去寻找的数据时，它需要的名称节点将指示其机架中的另一个节点来获取数据。
Reduce Task从Map Tasks计算接收到的数据
第二阶段的Map Reduce框架称为Reduce。机器上的Map任务已经完成了和生成它们的中间数据。现在我们需要收集所有的这些中间数据，组合并提纯以便进一步处理，这样我们会有一个最终结果。
Job Tracker在集群中的任何一个节点上开始一个Reduce任务，并指示Reduce任务从所有已完成的Map任务中获取中间数据。Map任务可能几乎同时应对Reducer，导致让你一下子有大量的节点发送TCP数据到一个节点。这种流量状况通常被称为&Incast&或者&fan-in&。对于网络处理大量的incast条件，其重要的网络交换机拥有精心设计的内部流量管理能力，以及足够的缓冲区（不太大也不能太小）。
Reducer任务现在已经从Map任务里收集了所有的中间数据，可以开始最后的计算阶段。在本例中，我们只需添加出现&Refund&这个词的总数，并将结果写入到一个名为Results的txt文件里。
这个名为Results的txt文件，被写入到HDFS以下我们已经涵盖的进程中，把文件分成块，流水线复制这些块等。当完成时，客户机可以从HDFS和被认为是完整的工作里读取Results.txt。
我们简单的字数统计工作并不会导致大量的中间数据在网络上传输。然而，其他工作可能会产生大量的中间数据，比如对TB级数据进行排序。
如果你是一个勤奋的网络管理员，你将了解更多关于Map Reduce和你的集群将运行的作业类型，以及作业类型如何影响你的网络流量。如果你是一个Hadoop网络明星，你甚至能够提出更好的代码来解决Map Reduce任务，以优化网络的性能，从而加快工作完工时间。
不平衡的Hadoop集群
Hadoop可以为你的组织提供一个真正的成功，它让你身边的数据开发出了很多之前未发现的业务价值。当业务人员了解这一点，你可以确信，很快就会有更多的钱为你的Hadoop集群购买更多机架服务器和网络。
当你在现有的Hadoop集群里添加新的机架服务器和网络这种情况时，你的集群是不平衡的。在这种情况下，机架1&2是我现有的包含File.txt的机架和运行我的Map Reduce任务的数据。当我添加了两个新的架到集群，我的File.txt数据并不会自动开始蔓延到新的机架。
新的服务器是闲置的，直到我开始加载新数据到集群中。此外,如果机架1&2上服务器都非常繁忙，Job Tracker可能没有其他选择，但会指定File.txt上的Map任务到新的没有本地数据的服务器上。新的服务器需要通过网络去获取数据。作为结果，你可能看到更多的网络流量和较长工作完成时间。
Hadoop集群均衡器
为了弥补集群的平衡性，Hadoop还包含了均衡器。
Balancer目光聚焦于节点间有效储存的差异，力所能及的将平衡维持在一定的临界值上。假如发现剩余大量储存空间的节点，Balancer将找出储存空间剩余量少的节点并把数据剪切到有大量剩余空间的节点上。只有的终端上输入指令Balancer才会运行，当接收到终端取消命令或者终端被关闭时，Balancer将会关闭。
Balancer可以调用的网络带宽很小，默认只有1MB/s。带宽可以通过hdfs-site.xml文件中的dfs.balance.bandwidthPerSec参数来设置。
Balancer是集群的好管家。没当有新机组添加时候就会用到它，甚至一经开启就会运行整个星期。给均衡器低带宽可以让它保持着长时间的运行。
个人认为假如均衡器能成为Hadoop的核心而不是只是一项功能，那样一定会比较有意思！
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
关于的更多文章
转眼十一月份了，天气逐渐变冷了。又到了起床靠毅力，洗澡靠勇气
Linux界极具活力，面向不同的用户可以使用不同的Linux发行版，比如适合新手和游戏爱好者等。
10月17日，微软正式发布了Windows 8的首个重大升级―
日前，由51CTO传媒举办的2013年云计算架构师峰会圆满
北京时间10月18日，Ubuntu 13.10（代号为Saucy Salama
本书全面介绍了Windows Server 2003 R2中最常用的各种服务，包括域名服务、动态IP地址服务、Windows名称服务、活动目录服务、Web
51CTO旗下网站为你的 Hadoop 集群选择合适的硬件 - 开源中国社区
当前访客身份：游客 [
为你的 Hadoop 集群选择合适的硬件
英文原文：
One of the first questions Cloudera customers raise when getting started with Apache Hadoop is how to select appropriate hardware for their new Hadoop clusters.
Although Hadoop is designed to run on industry-standard hardware, recommending an ideal cluster configuration is not as easy as delivering a list of hardware specifications. Selecting hardware that provides the best balance of performance and economy for a given workload requires testing and validation. (For example, users with IO-intensive workloads will invest in more spindles per core.)
In this blog post, you’ll learn some of the principles of workload evaluation and the critical role it plays in hardware selection. You’ll also learn the various factors that Hadoop administrators should take into account during this process.
随着Apache Hadoop的起步，云客户的增多面临的首要问题就是如何为他们新的的Hadoop集群选择合适的硬件。
尽管Hadoop被设计为运行在行业标准的硬件上，提出一个理想的集群配置不想提供硬件规格列表那么简单。&选择硬件，为给定的负载在性能和经济性提供最佳平衡是需要测试和验证其有效性。（比如，IO密集型工作负载的用户将会为每个核心主轴投资更多）。
在这个博客帖子中，你将会学到一些工作负载评估的原则和它在硬件选择中起着至关重要的作用。在这个过程中，你也将学到Hadoop管理员应该考虑到各种因素。&
Marrying Storage with Compute
Over the past decade, IT organizations have standardized on blades and SANs (Storage Area Networks) to satisfy their grid and processing-intensive workloads. While this model makes a lot of sense for a number of standard applications such as web servers, app servers, smaller structured databases, and data movement, the requirements for infrastructure have changed as the amount of data and number of users has grown. Web servers now have caching tiers, databases have gone massively parallel with local disk, and data movement jobs are pushing more data than they can handle locally.
Most teams building a Hadoop cluster don’t yet know the eventual profile of their workload.
Hardware vendors have created innovative systems to address these requirements including storage blades, SAS (Serial Attached SCSI) switches, external SATA arrays, and larger capacity rack units. However, Hadoop is based on a new approach to storing and processing complex data, with data movement minimized. Instead of relying on a SAN for massive storage and reliability then moving it to a collection of blades for processing, Hadoop handles large data volumes and reliability in the software tier.
Hadoop distributes data across a cluster of balanced machines and uses replication to ensure data reliability and fault tolerance. Because data is distributed on machines with compute power, processing can be sent directly to the machines storing the data. Since each machine in a Hadoop cluster stores as well as processes data, those machines need to be configured to satisfy both data storage and processing requirements.
结合存储和计算
过去的十年，IT组织已经标准化了刀片服务器和存储区域网(SAN)来满足联网和处理密集型的工作负载。尽管这个模型对于一些方面的标准程序是有相当意义 的，比如网站服务器，程序服务器，小型结构化数据库，数据移动等，但随着数据数量和用户数的增长，对于基础设施的要求也已经改变。网站服务器现在有了缓存 层；数据库需要本地硬盘支持大规模地并行；数据迁移量也超过了本地可处理的数量。
大部分的团队还没有弄清楚实际工作负载需求就开始搭建他们的Hadoop集群。
硬 件提供商已经生产了创新性的产品系统来应对这些需求，包括存储刀片服务器，串行SCSI交换机，外部SATA磁盘阵列和大容量的机架单元。然 而，Hadoop是基于新的实现方法，来存储和处理复杂数据，并伴随着数据迁移的减少。 相对于依赖SAN来满足大容量存储和可靠性，Hadoop在软件层次处理大数据和可靠性。
Hadoop在一簇平衡的节点间分派数据并使用同步复制来保证数据可用性和容错性。因为数据被分发到有计算能力的节点，数据的处理可以被直接发送到存储有数据的节点。由于Hadoop集群中的每一台节点都存储并处理数据，这些节点都需要配置来满足数据存储和运算的要求。
Why Workloads Matter
In nearly all cases, a MapReduce job will either encounter a bottleneck reading data from disk or from the network (known as an IO-bound job) or in processing data (CPU-bound). An example of an IO-bound job is sorting, which requires very little processing (simple comparisons) and a lot of reading and writing to disk. An example of a CPU-bound job is classification, where some input data is processed in very complex ways to determine ontology.
Here are several more examples of IO-bound workloads:
Data importing and exporting
Data movement and transformation
Here are several more examples of CPU-bound workloads:
Clustering/Classification
Complex text mining
Natural-language processing
Feature extraction
工作负载很重要吗？
在几乎所有情形下，MapReduce要么会在从硬盘或者网络读取数据时遇到瓶颈（称为IO受限的应用），要么在处理数据时遇到瓶颈（CPU受限）。排序是一个IO受限的例子，它需要很少的CPU处理（仅仅是简单的比较操作），但是需要大量的从硬盘读写数据。模式分类是一个CPU受限的例子，它对数据进行复杂的处理，用来判定本体。
下面是更多IO受限的工作负载的例子：
数据导入导出
数据移动和转换
下面是更多CPU受限的工作负载的例子：
复杂文本挖掘
自然语言处理
Because Cloudera’s customers need to thoroughly understand their workloads in order to fully optimize Hadoop hardware, a classic chicken-and-egg problem ensues. Most teams looking to build a Hadoop cluster don’t yet know the eventual profile of their workload, and often the first jobs that an organization runs with Hadoop are far different than the jobs that Hadoop is ultimately used for as proficiency increases. Furthermore, some workloads might be bound in unforeseen ways. For example, some theoretical IO-bound workloads might actually be CPU-bound because of a user’s choice of compression, or different implementations of an algorithm might change how the MapReduce job is constrained. For these reasons, when the team is unfamiliar with the types of jobs it is going to run, as an initial approach it makes sense to invest in a balanced Hadoop cluster.
Cloudera的客户需要完全理解他们的工作负载，这样才能选择最优的Hadoop硬件，而这好像是一个鸡生蛋蛋生鸡的问题。大多数工作组在没有彻底剖析他们的工作负载时，就已经搭建好了Hadoop集群，通常Hadoop运行的工作负载随着他们的精通程度的提高而完全不同。而且，某些工作负载可能会被一些未预料的原因受限。例如，某些理论上是IO受限的工作负载却最终成为了CPU受限，这是可能是因为用户选择了不同的压缩算法，或者算法的不同实现改变了MapReduce任务的约束方式。基于这些原因，当工作组还不熟悉要运行任务的类型时，深入剖析它才是构建平衡的Hadoop集群之前需要做的最合理的工作。
The next step would be to benchmark MapReduce jobs running on the balanced cluster to analyze how they’re bound. To achieve that goal, it’s straightforward to measure live workloads and determine bottlenecks by putting thorough monitoring in place. We recommend installing Cloudera Manager on the Hadoop cluster to provide real-time statistics about CPU, disk, and network load. (Cloudera Manager is an included component of Cloudera Standard and Cloudera Enterprise — in the latter case with enterprise functionality, such as support for rolling upgrades, in place.) With Cloudera Manager installed, Hadoop administrators can then run their MapReduce jobs and check the Cloudera Manager dashboard to see how each machine is performing. &
接下来需要在集群上运行MapReduce基准测试任务，分析它们是如何受限的。完成这个目标最直接的方法是在运行中的工作负载中的适当位置添加监视器来检测瓶颈。我们推荐在Hadoop集群上安装Cloudera Manager，它可以提供CPU，硬盘和网络负载的实时统计信息。（Cloudera Manager是Cloudera 标准版和企业版的一个组件，其中企业版还支持滚动升级）Cloudera Manager安装之后，Hadoop管理员就可以运行MapReduce任务并且查看Cloudera Manager的仪表盘，用来监测每台机器的工作情况。
The first step is to know which hardware your operations team already manages.
In addition to building out a cluster appropriate for the workload, we encourage customers to work with their hardware vendor to understand the economics of power and cooling. Since Hadoop runs on tens, hundreds, or thousands of nodes, an operations team can save a significant amount of money by investing in power-efficient hardware. Each hardware vendor will be able to provide tools and recommendations for how to monitor power and cooling.
第一步是弄清楚你的作业组已经拥有了哪些硬件
在为你的工作负载构建合适的集群之外，我们建议客户和它们的硬件提供商合作确定电力和冷却方面的预算。由于Hadoop会运行在数十台，数百台到数千台节点上。通过使用高性能功耗比的硬件，作业组可以节省一大笔资金。硬件提供商通常都会提供监测功耗和冷却方面的工具和建议。
Selecting Hardware for Your CDH Cluster
The first step in choosing a machine configuration is to understand the type of hardware your operations team already manages. Operations teams often have opinions or hard requirements about new machine purchases, and will prefer to work with hardware with which they’re already familiar. Hadoop is not the only system that benefits from efficiencies of scale. Again, as a general suggestion, if the cluster is new or you can’t accurately predict your ultimate workload, we advise that you use balanced hardware.
There are four types of roles in a basic Hadoop cluster: NameNode (and Standby NameNode), JobTracker, TaskTracker, and DataNode. (A node is a machine performing a particular task.) Most machines in your cluster will perform two of these roles, functioning as both DataNode (for data storage) and TaskTracker (for data processing).
为你的CDH(Cloudera distribution for Hadoop) Cluster选择硬件
选择机器配置类型的第一步就是理解你的运维团队已经在管理的硬件类型。在购买新的硬件设备时，运维团队经常根据一定的观点或者强制需求来选择，并且他们倾向于工作在自己业已熟悉的平台类型上。Hadoop不是唯一的从规模效率上获益的系统。再一次强调，作为更通用的建议，如果集群是新建立的或者你并不能准确的预估你的极限工作负载，我们建议你选择均衡的硬件类型。
Hadoop集群有四种基本任务角色:名称节点（包括备用名称节点），工作追踪节点，任务执行节点，和数据节点。节点是执行某一特定功能的工作站。大部分你的集群内的节点需要执行两个角色的任务，作为数据节点（数据存储）和任务执行节点（数据处理）。
Here are the recommended specifications for DataNode/TaskTrackers in a balanced Hadoop cluster:
12-24 1-4TB hard disks in a JBOD (Just a Bunch Of Disks) configuration
2 quad-/hex-/octo-core CPUs, running at least 2-2.5GHz
64-512GB of RAM
Bonded Gigabit Ethernet or 10Gigabit Ethernet (the more storage density, the higher the network throughput needed)
The NameNode role is responsible for coordinating data storage on the cluster, and the JobTracker for coordinating data processing. (The Standby NameNode should not be co-located on the NameNode machine for clusters and will run on hardware identical to that of the NameNode.) Cloudera recommends that customers purchase enterprise-class machines for running the NameNode and JobTracker, with redundant power and enterprise-grade disks in RAID 1 or 10 configurations.
这是在一个平衡Hadoop集群中，为数据节点/任务追踪器提供的推荐规格：
在一个磁盘阵列中要有12到24个1~4TB硬盘
2个频率为2~2.5GHz的四核、六核或八核CPU
64~512GB的内存
有保障的千兆或万兆以太网（存储密度越大，需要的网络吞吐量越高）
名字节点角色负责协调集群上的数据存储，作业追踪器协调数据处理（备用的名字节点不应与集群中的名字节点共存，并且运行在与之相同的硬件环境上。）。Cloudera推荐客户购买在RAID1或10配置上有足够功率和企业级磁盘数的商用机器来运行名字节点和作业追踪器。
The NameNode will also require RAM directly proportional to the number of data blocks in the cluster. A good rule of thumb is to assume 1GB of NameNode memory for every 1 million blocks stored in the distributed file system. With 100 DataNodes in a cluster, 64GB of RAM on the NameNode provides plenty of room to grow the cluster. We also recommend having HA configured on both the NameNode and JobTracker, features that have been available in the CDH4 line for some time.
Here are the recommended specifications for NameNode/JobTracker/Standby NameNode nodes. The drive count will fluctuate depending on the amount of redundancy:
4–6 1TB hard disks in a JBOD configuration (1 for the OS, 2 for the FS image [RAID 1], 1 for Apache ZooKeeper, and 1 for Journal node)
2 quad-/hex-/octo-core CPUs, running at least 2-2.5GHz
64-128GB of RAM
Bonded Gigabit Ethernet or 10Gigabit Ethernet
Remember, the Hadoop ecosystem is designed with a parallel environment in mind.
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 体系设计为用于一种并行环境。
If you expect your Hadoop cluster to grow beyond 20 machines, we recommend that the initial cluster be configured as if it were to span two racks, where each rack has a top-of-rack 10 GigE switch. As the cluster grows to multiple racks, you will want to add redundant core switches to connect the top-of-rack switches with 40GigE. Having two logical racks gives the operations team a better understanding of the network requirements for intra-rack and cross-rack communication.
With a Hadoop cluster in place, the team can start identifying workloads and prepare to benchmark those workloads to identify hardware bottlenecks. After some time benchmarking and monitoring, the team will understand how additional machines should be configured. Heterogeneous Hadoop clusters are common, especially as they grow in size and number of use cases – so starting with a set of machines that are not “ideal” for your workload will not be a waste of time. Cloudera Manager offers templates that allow different hardware profiles to be managed in groups, making it simple to manage heterogeneous clusters.
如果你希望Hadoop集群扩展到20台机器以上，那么我们推荐最初配置的集群应分布在两个机架，而且每个机架都有一个位于机架顶部的10G的以太网交换。当这个集群跨越多个机架的时候，你将需要添加核心交换机使用40G的以太网来连接位于机架顶部的交换机。两个逻辑上分离的机架可以让维护团队更好地理解机架内部和机架间通信对网络需求。
Hadoop集群安装好后，维护团队就可以开始确定工作负载，并准备对这些工作负载进行基准测试以确定硬件瓶颈。经过一段时间的基准测试和监视，维护团队将会明白如何配置添加的机器。异构的Hadoop集群是很常见的，尤其是在集群中用户机器的容量和数量不断增长的时候更常见-因此为你的工作负载所配置的“不理想”开始时的那组机器不是在浪费时间。Cloudera管理器提供了允许分组管理不同硬件配置的模板，通过这些模板你就可以简单地管理异构集群了。