整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

9.1 集群规范

hadoop 小红牛 12℃ 0评论

Hadoop运行在商业硬件上。用户可以选择普通硬件供应商生产的标准化的、广泛有效的硬件来构建集群,无需使用特定供应商生产的昂贵、专有的硬件设备。

 

首先澄清两点。第一,商业硬作并不等同于低端硬件。低端机器常常使用便宜的零部件,其故障率远高于更贵一些(但仍是商业级别)的机器。当用户管理几十台、上百台,甚至几千台机器时,选择便宜的零部件并不划算,

因为更髙的故障率推高了维护成本。第二,也不推荐使用大型的数据库级别的机器,因为这类机器的性价比太低了。用户可能会考虑使用少数几台数据库级别的机器来构建一个集群,使其性能达到一个中等规模的商业机器集群。然而,某一台机器所发生的故障会对整个集群产生更大的负面影响,原因在于更大比例的集群硬件将无法使用。
硬件规格很快就会过时。但为了举例说明,下面列举一下硬件规格。在2010年年中,运行Hadoopdatanodetasktracker的典型机器具有以下规格:

 •  处理器,两个四核2〜2.5 GHzCPU

 •  内存,16~24 GB ECC RAM®

 •  存储器,4xlTBSATA硬盘

  •  网络,千兆以太网

尽管各个集群采用的硬件规格肯定有所不同,但是Hadoop —般使用多核 CPU和多磁盘,以充分利用硬件的强大功能。

为何不使用RAIO?

尽管建议采用RAID(Redundant Array of lndependent Disk,即磁盘阵列)作为 namenode的存储器以保护元数据,但是若将RAID作为datanode的存储设备则不会给HDFS带来益处。HDFS所提供的节点间数据复制技术已可满足数据备份需求,无需使用RAID的冗余机制。

此外,尽管RAID条带化技术(RAID 0)被广泛用于提升性能,但是其速度仍然比用在HDFS里的JBOD(Just a Bunch Of Disks)配置慢。JBOD在所有磁 盘之间循环调度HDFS块。RAID 0的读写操作受限于磁盘阵列中最慢盘片的速度,而JBOD的磁盘操作均独立,因而平均读写速度高于最慢盘片的 读写速度„需要强调的是,各个磁盘的性能在实际使用中总存在相当大的差异,即使对于相同型号的磁盘。针对某一雅虎集群的评测报告表明,在一个测试(Gridmix) 中,JBODRAID 010%;在另一测试(HDFS写吞吐量)中,JBODRAID 0 30%

最后,若JBOD配置的某一磁盘出现故障,HDFS可以忽略该磁盘,继续工作。而RAID的某一盘片故障会导致整个磁盘阵列不可用,进而使相应节 点失效。

 

Hadoop的主体由Java语言写成,能够在任意一个安装了 JVM的平台上运行。但由于仍有部分代码(例如控制脚本)需在Unix环境下执行,因而

Hadoop并不适宜以最终产品的形态运行在非Unix平台上。

事实上,Windows操作系统主要作为一个开发平台(安装了 Cygwin之后), 而非生产平台,详情参见附录A

一个Hadoop集群到底应该有多大?这个问题并无确切答案。但是,Hadoop 的魅力在于用户可以在初始阶段构建一个小集群(大约10个节点),并随存储与计算需求增长持续扩充。从某种意义上讲,更恰当的问题是:你的集群需要增长得多快?用户通过以下一个关于存储的例子可以体会更深。

假如数据每周增长1TB。如果采用三路HDFS复制技术,则每周需要增加 3 TB存储能力。再加上一些中间文件和日志文件(约占30%),基本上相当于每周添设一台机器(2010年的典型机器)。实际上,用户一般不会每周去购买一台新机器并将其加入集群。类似粗略计算的意义在于让用户了解集 群的规模:在本例中,保存两年数据大致需要100台机器。

对于一个小集群(几十个节点)而言,在一台master机器上同时运行 namenodejobtracker通常没问题(需确保至少一份namenode的元数据被另存在远程文件系统中)。随着HDFS中的集群和文件数不断增长, namenode需要使用更多内存,在这种情况下namenodejobtracker,最好 分別放在不同机器中。

辅助namenode可以和namenode —起运行在同一台机器之中,但是同样由 于内存使用的原因(辅助namenode和主namenode的内存需求相同),二者 最好运行在独立的硬件之上;对于大规模集群来说,更是如此。详情可参 见9.4.1节对主节点场景的讨论。运行namenode的机器一般采用64位硬 件,以避免在32位体系结构下Java堆的3 GB内存限制。®

网络拓扑

Hadoop集群架构通常包含两级网络拓扑,如图9-1所示。一般来说,各机架装配30~40个服务器,共享一个1 GB的交换机(该图中各机架只画了 3 个服务器),各机架的交换机又通过上行链路与一个核心交换机或路由器(通常为1GB或更高)互联。该架构的突出特点是同一机架内部的节点之间的总带宽要远高于不同机架上的节点间的带宽。

 

图片.png 

 

机架的注意事项

为了达到Hadoop的最佳性能,配置Hadoop系统以让其了解网络拓扑状况就极为关键。如果集群只包含一个机架,就无需做什么,因为这是默认配置。但是对于多机架的集群来说,描述清楚节点机架间的映射关系就很有必要。这样的话,当HadoopMapReduce任务分配到各个节点时,会倾向于执行机架内的数据传输(拥有更多带宽),而非跨机架数据传输。HDFS 将能够更加智能地放置复本(replica),以取得性能和弹性的平衡。

 

诸如节点和机架等的网络位置以树的形式来表示,从而能够体现出各个位 置之间的网络“距离”。namenode使用网络位置来确定在哪里放置块的复 本(参见3.6.2节);MapReduce的调度器根据网络位置来查找最近的复 本,将它作为map任务的输入。

 

在图9-1所示的网络中,机架拓扑由两个网络位置来描述,即/switch1/rack1 和Awz7c/z//racA:2。由于该集群只有•个顶层路由器,这两个位置可以简写 为/switch1和/rack2

Hadoop配置需要通过一个Java接口 DNSToSwitchMapping来指定节点地址和网络位置之间的映射关系。该接口定义如下:

public interface DNSToSwitchMapping {
public List<String> resolve(List<String> names);
  }

 resolve()函数的输入参数names描述IP地址列表,返回相应的网络位置字符串列表。topology .node .switch.mapping.impl 配置属性实现了 DNSToSwitchMapping 接口,namenode jobtracker 均采用它来解析工作节点的网络位置。

在上例的网络拓扑中,可将nodel、node2node3映射到/rack1,将 node4node5 node6映射到/rack2中。

但是,大多数安装并不需要额外实现新的接口,只需使用默认ScriptBasedMapping实现即可,它运行用户定义的脚本来描述映射关系。脚本的存放路径由属性topology.script.file.name控制。脚本接 受一系列输入参数,描述带映射的主机名称或IP地址,再将相应的网络位 置以空格分开,输出到标准输出。

如果没有指定脚本位置,默认情况下会将所有节点映射到单个网络位置,即/default-rack。

转载请注明:全栈大数据 » 9.1 集群规范

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址