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

9.4.1 配置管理

hadoop 小红牛 15℃ 0评论

Hadoop并没有将所有配置信息放在一个单独的全局位置中。反之,集群的每个Hadoop节点都各自保存一系列配置文件,并由管理员完成这些配置文件的同步工作。Haddoop提供一个基本工具来进行同步配置,即rsync(参见后文的讨论)。此外,诸如dsh或pdsh等并行shell工具也可完成该任务。

 

Hadoop也支持为所有master机器和worker机器采用同一套配置文件。这个做法的最大优势在于简单,不仅体现在理论上(仅需处理一套配置文件),也体现在可操作性上(使用Hadoop脚本就能进行管理)

 

但是,这种一体适用的配置模型并不合适某些集群。以扩展集群为例,当试图为集群添加新机器,且新机器的硬件规格与现有机器不同时,则需要 新建一套配置文件,以充分利用新硬件的额外资源。

 

在这种情况下,需要引入“机器类”的概念,为每一机器类维护单独的配置文件。Hadoop没有提供执行这个操作的工具,需要借助外部工具来执行 该配置操作,例如ChefPuppetcfenginebcfg2等。

 

 对于任何规模的集群来说,同步所有机器上的配置文件都极具挑战性。例如,假设某台机器正好处于异常状态,而此时用户正好发出一条更新配置的指令,如何保证这台机器在恢复正常状态之后也能够更新配置?这个问题很严重,可能会导致集群中各机器的配置不一致。因此,尽管用户能'够使用控制脚本来管理Hadoop,仍然推荐使用控制管理工具管理集群。使用这些工具也可以顺利完成日常维护,例如为安全漏洞打补丁、升级系统包等。

1.控制脚本

Hadoop内置一些脚本来运行指令、在集群内启动和终止守护进程。为了运行这些脚本(存放在bin目录中),需要预先知道集群内的所有机器。有两个文件能达成该目标,即masters和slaves。各文件逐行记录一些机器的名称或IP地址。masters文件的名称确实有点误导人,它主要记录拟运行辅助namenode的所有机器。slaves文件记录了运行datanode和tasktracker的所有机器。这两个文件存放在配置目录之中。用户也可以改变hadoop_env.sh的HADOOP_SLAVES项的值,将slaves文件放在其他地方(也可以改变文件名称)。此外,这些文件无需分发到各个工作节点,因为只有运行在namenodejobtracker上的控制脚本能使用这些文件。

 

用户无需指定究竟由masters文件中的哪台(或哪些)机器来运行namenodejobtracker,这是由运行脚本的机器决定的。(实际上,在masters文件上指定机器会导致在这台(或这些)机器上运行一个辅助namenode,而这可能违背用户期望。)例如,start-dfs.sh脚本用于启动集群中所有的HDFS守护进程,它会在运行该脚本的机器上启动namenode。详细步骤如下。

 

(1)在本地机器上启动一个namenode(脚本所运行的机器)

 

(2)在slaves文件中记录的各机器上启动一个datanode。

 

(3)在masters文件中记录的所有机器上均启动一个辅助namenode。

 

脚本文件start-mapred.sh与start-dfs.sh类似,它启动集群中所有的 MapReduce守护进程。详细步骤如下。

 

(1)在本地机器上启动一个jobtracker。

(2)在slaves文件记录的每台机器上启动一个tasktracker。

 

注意,MapReduce控制脚本不使用masters文件。

 

此外,stop-dfs.sh和stop-mapred.sh脚本能终止由相关启动脚本启动的守护进程。

如果用户已经使用前述脚本,则不宜直接调用hadoop-daemon.sh。但是如果用户需要从其他系统(或利用自己编写的脚本)控制Hadoop守护进程,则可以调用 hadoop-daemon.sh 脚本。类似地,hadoop-daemons.sh(注意,多了 “s”后缀)用于在多个主机上启动同一守护进程。

2.master节点场景

由于集群规模差异较大,对于主节点守护进程的配置也差异很大,包括 namenode、辅助namenodejobtracker。对于一个小型集群来说(几十个节点),可以直接将这些守护进程放到单独的一台机器上。但是,对于大型集群来说,则最好让这些守护进程分别运行在不同机器上。

namenode在内存中保存整个命名空间中的所有文件元数据和块元数据,其内存需求很大。辅助namenode在大多数时间里空闲,但是它在创建检查点时的内存需求与主namenode差不多。详情参见10.1.2节对文件系统映像和编辑日志的讨论。一旦文件系统包含大量文件,单台机器的物理内存便无法同时运行主namenode和辅助namenode

辅助namenode保存一份最新的检査点,记录它创建的文件系统的元数据。将这些历史信息备份到其他节点上,有助于在数据丢失(或系统崩溃)情况下 恢复namenode的元数据文件。详见第10章的讨论。

在一个运行大量MapReduce作业的高负载集群上,jobtracker会占用大量内存和CPU资源,因此它最好运行在一个专用节点上。

不管主守护进程运行在一个还是多个节点上,以下规则均适用:

  •在namenode机器上运行HDFS控制脚本。wakens文件包含辅助 namenode的地址

  •在jobtracker机器上运行MapReduce控制脚本

 

当namenode和jobtracker运行在不同节点之上时,集群中的各节点将运行一个datanode和一个tasktracker,因此各个slaves文件要保持同步。

 

转载请注明:全栈大数据 » 9.4.1 配置管理

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

表情

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

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