构建 Hadoop 集群_IT分享知识网

构建 Hadoop 集群

—————————————————————————————————————————————–

安装选项：

1. Apache tarballs ：The Apache Hadoop project and related projects provide binary (and source) tarballs for each release.

2. Packages ：RPM and Debian packages are available from the Apache Bigtop project http://bigtop.apache.org/

3. Hadoop cluster management tools ：Cloudera Manager and Apache Ambari are examples of dedicated tools for installing and

managing a Hadoop cluster over its whole lifecycle. They provide a simple web UI,

and are the recommended way to set up a Hadoop cluster for most users and operators.

1 集群规范 (Cluster Specification)

—————————————————————————————————————————————–

硬件：

————————————————————————————————————————————-

a typical choice of machine for running an HDFS datanode and a YARN node manager in 2014 would have had the following specifications:

处理器： Two hex/octo-core 3 GHz CPUs

内存： 64−512 GB ECC RAM[68]

存储器： 12−24 × 1−4 TB SATA disks

网络： Gigabit Ethernet with link aggregation

Hadoop 一般使用多核 CPU 和多磁盘，以充分利用硬件的强大功能。

Master node scenarios

————————————————————————————————————————————

根据集群的大小，运行 master daemon 由很多不同的配置：the namenode, secondary namenode, resource manager, and history server

For a small cluster (on the order of 10 nodes), it is usually acceptable to run the namenode and the resource manager on

a single master machine (as long as at least one copy of the namenode’s metadata is stored on a remote filesystem).

namenode 对内存要求较高，因为它要在内存中保持整个名称空间文件和块的元数据信息。

网络拓扑 (Network Topology)

————————————————————————————————————————————

A common Hadoop cluster architecture consists of a two-level network topology 。

每个机架有 30-40 台服务器，内部用一台 10GB 交换机，向上连接一台核心交换机或路由器(至少10GB，或更大带宽)，使机架间互联。该架构的突出

特点是同一机架内部的节点之间的总带宽要远高于不同机架上节点间的带宽。

机架注意事项 (Rack awareness)

————————————————————————————————————————————–

为了获得 Hadoop 最佳性能，配置 Hadoop 以让其了解网络拓扑状况极为重要。如果集群只有一个机架，就无须做什么，因为这是默认配置。然而，对于

多机架集群，需要将节点映射到机架。这允许 Hadoop 在节点上部署 MapReduce 任务时更优先选择机架内(within-rack) 传输(拥有更多的可用带宽)而非

跨机架(off-rack)传输。 HDFS 也能够更智能地部署块复本以达到性能和弹性的平衡。

网络位置例如节点和机架表现在一棵树中，从而反映出位置间的网络距离(network distance)。namenode 使用网络位置确定复本的放置位置，MapReduce

调度器使用网络位置确定其 map 任务输入的最近复本。

示例：对于网络，机架拓扑描述为两个网络位置 ———— /switch1/rack1 和 /switch1/rack2. 因为集群中只有一个顶级的(top-level) 交换机，位置可以

简化为 /rack1 和 /rack2.

Hadoop 配置必须指定节点地址和网络位置的一个映射。这个映射由一个 Java 接口描述， DNSToSwitchMapping:

public interface DNSToSwitchMapping {

public List<String> resolve(List<String> names);

}

names 参数是一个 IP 地址列表，返回值是一个对应的网络位置字符串列表。

net.topology.node.switch.mapping.impl

配置属性定义了一个 DNSToSwitchMapping 接口实现, namenode 和 resource manager 用于解析工作节点(worker node)的网络位置。

对于本例的网络，我们将 node1, node2, and node3 映射到 /rack1, 以及将 node4, node5, and node6 映射到 /rack2.

大多数安装不需要自己实现接口，然而，因为默认实现是 ScriptBasedMapping, 即运行一个用户定义的脚本来确定映射，脚本位置由属性：

net.topology.script.file.name

控制。脚本必须接受可变数量的参数，要映射的主机名或 IP 地址，并且必须将对应的网络位置发送到标准输出，空格分隔。

如果没有指定脚本位置，默认是将所有节点映射为一个网络位置，称为 /default-rack

2 集群的构建和安装 (Cluster Setup and Installation)

—————————————————————————————————————————————–

1. Installing Java： Java 7 或更高版本

————————————————————————————————————————————-

2. Creating Unix User Accounts ：

————————————————————————————————————————————-

It’s good practice to create dedicated Unix user accounts to separate the Hadoop processes from each other, and from other services

running on the same machine. The HDFS, MapReduce, and YARN services are usually run as separate users, named hdfs, mapred, and yarn,

respectively. They all belong to the same hadoop group.

最佳实践是在同一台机器上，为 Hadoop 进程分别创建专用的 Unix 用户帐户，并与其他服务分开。 HDFS, MapReduce, 以及 YARN 通常作为不同的用户

运行，用户名分别为 hdfs, mapred, and yarn. 他们同属于一个 hadoop 用户组。

3. 安装 Hadoop (Installing Hadoop)

————————————————————————————————————————————-

% cd /usr/local

% sudo tar xzf hadoop-x.y.z.tar.gz

同样，需要改变 Hadoop 文件的用户名和组：

% sudo chown -R hadoop:hadoop hadoop-x.y.z

It’s convenient to put the Hadoop binaries on the shell path too:

% export HADOOP_HOME=/usr/local/hadoop-x.y.z

% export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

4. 配置 SSH (Configuring SSH)

————————————————————————————————————————————-

Hadoop 的控制脚本(but not the daemons) 依靠 SSH 执行整体集群(cluster-wide)的操作。例如，停止和启动集群上所有 daemon 的脚本。注意，控制

脚本是可选的，整体集群的操作也可以通过其他机制执行，例如一个分布式脚本或专用的 Hadoop 管理应用程序。

为了无间断工作，SSH 要设置为允许 hdfs 和 yarn 用户从集群任何机器上无密码登录。实现这个任务最简单的方法是生成一个 public/private 密钥对

并把它们放到一个 NFS 位置以在整个集群上共享。

首先，通过如下指令生成一个 RSA key 对。需要做两次，一次作为 hdfs 用户，一次作为 yarn 用户。

% ssh-keygen -t rsa -f ~/.ssh/id_rsa

纵然想要无密码登录，没有密码的密钥不认为是个好的实践，因此当提示时，应输入一个密码。使用 ssh-agent 来避免为每一个连接输入密码。

下一步，需要确保 public key 存在于集群上所有要连接机器的 ~/.ssh/authorized_keys 文件中。如果用户的主目录存储在一个 NFS 系统上，

密钥可以通过输入如下指令跨集群共享 (first as hdfs and then as yarn)：

% cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

如果用户主目录没有使用 NFS 共享，则 public key 需要通过其他方法共享，例如， ssh-copy-id 。

Test that you can SSH from the master to a worker machine by making sure ssh-agent is running, and then run ssh-add to store your

passphrase. You should be able to SSH to a worker without entering the passphrase again.

5. Configuring Hadoop

————————————————————————————————————————————-

6. 格式化 HDFS 文件系统 ( Formatting the HDFS Filesystem )

————————————————————————————————————————————-

在能够使用之前，一个崭新的 HDFS 安装需要被格式化。格式化过程通过创建存储目录(storage directories) 和名称节点(namenode) 的持久化数据

结构的初始化版本来创建一个空的文件系统。datanode 不包含在初始格式化过程中，因为 namenode 管理着所有文件系统元数据，而 datanode 可以

动态加入集群或从集群中移除。由于相同的原因，不需要说明创建多大的文件系统，因为这是由集群内 datanode 的数量决定的，可以在文件系统格式化

之后按需增加。

格式化操作非常快，运行下面命令：Run the following command as the hdfs user:

% hdfs namenode -format <cluster_name>

7. 启动和停止 Daemons

————————————————————————————————————————————-

Hadoop 自带了一些脚本用于运行命令以及启动和停止整个集群的 daemon 。使用这些脚本(可以在安装目录的 sbin 内找到)，需要告知 Hadoop 有哪些

机器在集群中。有一个文件用于此目的，称为 slaves, 包含一个机器的主机名或 IP 地址列表，每行一个。

slaves 文件列出 datanodes 和 node managers 运行在其上的机器。它存在于 Hadoop 的配置目录，但它可以放置到其他地方或给出另外的名称，通过

在 hadoop-env.sh 文件中改变 HADOOP_SLAVES 设置值。另外，这文件不需要分发给工作节点(to be distributed to worker nodes), 因为它们仅仅由

运行在 namenode 或 resource manager 的控制脚本使用。

The HDFS daemons are started by running the following command as the hdfs user:

% start-dfs.sh

namenode 和 secondary namenode 运行的机器通过查询 Hadoop 配置属性的主机名确定。例如，脚本通过执行如下指令，找到 namenode 的主机名：

% hdfs getconf -namenodes

默认情况下，指令从 fs.defaultFS 属性找到 namenode 的主机名称。

稍微相信一些， start-dfs.sh 脚本做如下这些事：

————————————————————————————————————

① Starts a namenode on each machine returned by executing hdfs getconf -namenodes

② Starts a datanode on each machine listed in the slaves file

③ Starts a secondary namenode on each machine returned by executing hdfs getconf -secondarynamenodes

YARN daemons 以类似的方式启动，yarn 用户在 resource manager 机器上运行如下命令启动：

% start-yarn.sh

resource manager 总是运行在 startyarn.sh 脚本运行的机器上。更明确地，脚本执行下列过程：

————————————————————————————————————

① Starts a resource manager on the local machine

② Starts a node manager on each machine listed in the slaves file

也提供了 stop-dfs.sh 和 stop-yarn.sh 脚本来停止由相应启动脚本启动的守护进程。

% stop-yarn.sh

% stop-dfs.sh

这些脚本启动和停止 Hadoop daemons 使用的是 hadoop-daemon.sh 脚本(或者是 yarn-daemon.sh，YARN 情形)。如果使用前述脚本，不应直接使用

hadoop-daemon.sh 脚本。但如果需要从另一个系统或从自己脚本控制 Hadoop daemon, hadoop-daemon.sh 脚本是一个好的结合点。同样，在一组机

器上启动相同的守护进程，hadoop-daemons.sh (with an “s”) 是一个方便的工具。

最后，只有一个 MapReduce 守护进程 ———— job history server, 以 mapred 用户通过如下命令启动：

% mr-jobhistory-daemon.sh start historyserver

8. 创建用户目录 (Creating User Directories)

————————————————————————————————————————————-

一旦有了一个 Hadoop 集群并处于运行中，需要让用户访问它。这包括为每一个用户创建主目录并为之设置所有者许可权限：

% hadoop fs -mkdir /user/username

% hadoop fs -chown username:username /user/username

这是为目录设置空间限制的好时机。下面的指令为给定的用户目录设置 1 TB 限制：

% hdfs dfsadmin -setSpaceQuota 1t /user/username

3 Hadoop 配置 ( Hadoop Configuration )

—————————————————————————————————————————————–

有很多控制 Hadoop 安装的文件，最重要文件如下表所示：

Hadoop configuration files

+===============================+===================+===================================================================================+

| 文件名 | 格式 | 描述 |

+——————————-+——————-+———————————————————————————–+

| hadoop-env.sh | Bash script | Environment variables that are used in the scripts to run Hadoop |

+——————————-+——————-+———————————————————————————–+

| mapred-env.sh | Bash script | Environment variables that are used in the scripts to run MapReduce |

| | |(overrides variables set in hadoop-env.sh) |

+——————————-+——————-+———————————————————————————–+

| yarn-env.sh | Bash script | Environment variables that are used in the scripts to run YARN (overrides |

| | | variables set in hadoop-env.sh) |

+——————————-+——————-+———————————————————————————–+

| core-site.xml | Hadoop | Configuration settings for Hadoop Core, such as I/O settings that are common |

| | configuration XML | to HDFS, MapReduce, and YARN |

+——————————-+——————-+———————————————————————————–+

| hdfs-site.xml | Hadoop | Configuration settings for HDFS daemons: the namenode, the secondary |

| | configuration XML | namenode, and the datanodes |

+——————————-+——————-+———————————————————————————–+

| mapred-site.xml | Hadoop | Configuration settings for MapReduce daemons: the job history server |

| | configuration XML | |

+——————————-+——————-+———————————————————————————–+

| yarn-site.xml | Hadoop | Configuration settings for YARN daemons: the resource manager, the web app |

| | configuration XML | proxy server, and the node managers |

+——————————-+——————-+———————————————————————————–+

| slaves | Plain text | A list of machines (one per line) that each run a datanode and a node manager |

+——————————-+——————-+———————————————————————————–+

| hadoop-metrics2.properties | Java properties | Properties for controlling how metrics are published in Hadoop |

+——————————-+——————-+———————————————————————————–+

| log4j.properties | Java properties | Properties for system logfiles, the namenode audit log, and the task log for the |

| | | task JVM process |

+——————————-+——————-+———————————————————————————–+

| hadoop-policy.xml | Hadoop | Configuration settings for access control lists when running Hadoop in secure |

| | configuration XML | mode |

+——————————-+——————-+———————————————————————————–+

这些配置文件在 Hadoop 发布包 etc/hadoop 目录下。配置文件目录可以迁移到文件系统其他位置(Hadoop 安装目录之外，这样使得升级更容易些)，只要 daemons

启动的时候带上 –config 选项(或者，与其等价的，设置 HADOOP_CONF_DIR 环境变量) 指定在本地文件系统上的配置目录位置。

1. 配置管理 ( Configuration Management )

————————————————————————————————————————————-

Hadoop 没有一个单一的，全局的位置放置配置信息。相反，集群中每一个 Hadoop 节点有它自己的一套配置文件，并且系统管理员确保它们在系统中保

持同步。有些并发 shell 工具可以帮助做这些工作，例如，dsh 或 pdsh。这是 Hadoop 集群管理工具如 Cloudera Manager 和 Apache Ambari 真正

突出的领域，因为它们注重于配置变化跨集群传播。

Hadoop 设计为可以使用一套配置文件用于所有的 master 和 worker 机器，这种方式最大的好处是简单，不论是概念上(因为只有一个配置文件要处理)

还是操作上(因为 Hadoop 脚本管理一个单一的配置设置就足够了)。

但有些集群，这种 one-size-fits-all 的配置模式不适用。例如，如果加入新机器扩展集群，而这些机器与现有机器相比有不同的硬件规范，对这些新

机器需要一个不同的配置来利用它们那些特别的资源。

这种场景下，需要有一类机器的概念(concept of a class of machine), 并为每一个类维护一个单独的配置。 Hadoop 不为此提供工具，但有几个优秀的

工具可以精确地处理这种类型的配置管理，例如 Chef, Puppet, CFEngine, 以及 Bcfg2 。

对于任何规模的集群，保持所有的机器同步可能是一个挑战。考虑当移除一个更新时如果一台机器不可用会发生什么。谁能确保获得更新它就能变得可用？

这是个很大的问题并可能导致安装分歧了，因此，尽管用户能够使用控制脚本来管理 Hadoop ，仍然推荐使用控制管理工具管理集群。

使用这些管理工具对日常维护也非常出色，例如为安全漏洞打补丁，升级系统包等。

环境设置 (Environment Settings)

———————————————————————————————————————————–

hadoop-env.sh

mapred-env.sh

yarn-env.sh

Note that the MapReduce and YARN files override the values set in hadoop-env.sh

Java :

——————————————————————————————————————————-

要使用的 Java 实现的位置由 hadoop-env.sh 里的 JAVA_HOME 设置确定，或者，如果 hadoop-env.sh 没有设置，使用 JAVA_HOME 的 shell 环境变量。

建议在 hadoop-env.sh 内设置，这样在一个位置定义清晰，并确保整个集群使用同一版本的 Java 。

内存堆大小 (Memory heap size)：

——————————————————————————————————————————-

默认情况下， Hadoop 为各个守护进程(daemon) 分配 1000 MB(1GB)内存。该内存值由 hadoop-env.sh 文件的 HADOOP_HEAPSIZE 变量设置。

也有环境变量可以改变单独 daemon 的堆大小，例如，可以在 yarn-env.sh 里设置 YARN_RESOURCEMANAGER_HEAPSIZE 为 resource manager 重写堆大小。

没有为 HDFS daemon 设置的对应的环境变量，尽管一般会给 namenode 更多的堆空间。设置 namenode 堆大小有另外的方法。

HOW MUCH MEMORY DOES A NAMENODE NEED?

—————————————————————————————————————————-

默认为 1000MB 的 namenode 内存对于几百万个文件，一般来说是足够了，但凭经验来说，内存大小可以保守地按每百万个数据块使用 1000MB

内存来估算。

可以在不改变其他 Hadoop daemon 内存分配的情况下，通过设置 hadoop-env.sh 里的 HADOOP_NAMENODE_OPTS JVM 选项来设置内存大小。

HADOOP_NAMENODE_OPTS 允许向 namenode 的 JVM 传递额外的选项。因此，例如，-Xmx2000m 指定2000MB 的内存分配给 namenode 。

如果改变了 namenode 的内存分配，不要忘了为 secondary namenode 做相同的更改 (使用 HADOOP_SECONDARYNAMENODE_OPTS 变量)，因为

它的内存需求和 primary namenode 是差不多的。

除了守护进程的内存要求外， node manager 为应用程序分配容器，因此，对于工作机器(worker machine)需要把这部分因素考虑到整个内存占用空间中去。

系统日志文件 (System logfiles)：

———————————————————————————————————————————

默认情况下， Hadoop 生成的系统日志文件存放在 $HADOOP_HOME/logs 目录，可以通过 hadoop-env.sh 文件中的 HADOOP_LOG_DIR 设置更改。

修改默认值使日志文件从 Hadoop 的安装目录独立出来是个好的想法，这样的话，即使 Hadoop 升级之后安装路径发生变化，也会保证日志文件保持

在一个位置不变。通常选择 /var/log/hadoop, 在 hadoop-env.sh 文件中包含下面的内容设置：

export HADOOP_LOG_DIR=/var/log/hadoop

如果日志目录不存在则会被创建。(如果没有创建，确认相关的 Unix Hadoop user 是否拥有权限创建该目录).每个运行在一台机器上的 Hadoop

daemon 产生两个日志文件。

第一个是通过 log4j 输出的，文件名以 .log 结尾，大多数应用程序日志会写到这个日志文件中，因此是问题诊断的第一入口。

标准的 Hadoop log4j 采用每日滚动文件追加器( a daily rolling file appender )来滚动日志文件。旧的日志文件不会被删除，因此用户应该

安排定期删除或存档，以免本地节点磁盘空间耗尽。

第二个日志文件是联合标准输出(standard output)和标准错误日志(standard error log)，这类日志文件以 .out 结尾，由于 Hadoop 使用 log4j

记录日志，通常包含很少或没有输出。这类日志只有在守护进程重新启动时才轮转。而且仅保留最后的5个日志文件，旧的日志文件由一个 1 至 5 的

数字作为后缀，后缀 5 是最早的文件。

日志文件名(包括两种类型)是一个联合体，由运行守护进程的用户名(user running the daemon)，守护进程名称(the daemon name)，机器的

主机名(the machine hostname) 组成。例如，hadoop-hdfs-datanode-ip-10-45-174-112.log.2014-09-20 是一个轮转后的日志文件名称。

这种命名结构使得在集群内将所有机器上的日志文件存档到一个单一的目录内成为可能，因为文件名是唯一的。

日志文件名中的 username 部分实际上是 hadoop-env.sh 文件内 HADOOP_IDENT_STRING 设置的默认值，如果为了命名日志文件希望给 Hadoop 实例一个

不同的标识(identity)，修改 HADOOP_IDENT_STRING 的值为一个想要的标识符。

SSH settings

——————————————————————————————————————————-

使用控制脚本(control scripts) 可以通过 SSH 在 master 节点上运行 worker(远程)节点上的命令。自定义 SSH 有很多好处，各种理由。例如，

可以降低连接超时，使用 ConnectTimeout 选项。另一个有用的 SSH 设置是 StrictHostKeyChecking, 可以设置为 no 来自动添加新的 host keys

到 known hosts files ，默认是 ask ，提示用户确认 key fingerprint has been verified, 这在大的集群环境下是不恰当的设置。

要向 SSH 传递更多的选项，在 hadoop-env.sh 文件中定义 HADOOP_SSH_OPTS 环境变量。

2. Hadoop 守护进程的重要属性 (Important Hadoop Daemon Properties)

———————————————————————————————————————————–

Hadoop 的配置属性之多2让人眼花缭乱。本节讨论真实工作集群需要定义的重要属性(至少理解为何默认属性值是恰当的)。

这些属性在 Hadoop site 文件中设置：

core-site.xml

hdfs-site.xml

yarn-site.xml

要查看运行中的 daemon 的实际配置，访问它的 web server 的 /conf 页，例如：http://resource-manager-host:8088/conf 显示运行在此服务器上的

资源管理器的配置。这个页面显示的是 site 和默认配置文件的组合属性，也显示了每个属性是从哪个文件选出来的。

例子：

——————————————————————————–

<?xml version=”1.0″?>

<!– core-site.xml –>

<name>fs.defaultFS</name>

<value>hdfs://namenode/</value>

</property>

</configuration>

—————————————————————————

<?xml version=”1.0″?>

<!– hdfs-site.xml –>

<name>dfs.namenode.name.dir</name>

<value>/disk1/hdfs/name,/remote/hdfs/name</value>

</property>

<name>dfs.datanode.data.dir</name>

</property>

<name>dfs.namenode.checkpoint.dir</name>

<value>/disk1/hdfs/namesecondary,/disk2/hdfs/namesecondary</value>

</property>

</configuration>

—————————————————————————-

<?xml version=”1.0″?>

<!– yarn-site.xml –>

<name>yarn.resourcemanager.hostname</name>

<value>resourcemanager</value>

</property>

<name>yarn.nodemanager.local-dirs</name>

<value>/disk1/nm-local-dir,/disk2/nm-local-dir</value>

</property>

<name>yarn.nodemanager.aux-services</name>

<value>mapreduce.shuffle</value>

</property>

<name>yarn.nodemanager.resource.memory-mb</name>

</property>

<name>yarn.nodemanager.resource.cpu-vcores</name>

</property>

</configuration>

HDFS

————————————————————————————————————————————

运行 HDFS ，需要指定一台机器作为 namenode ，本例中，属性 fs.defaultFS 是 HDFS 文件系统 URI , 它的主机(host) 是 namenode 的主机名(

hostname) 或 IP 地址，端口是 namenode 将要监听的RPC端口，如果没有指定端口，默认使用8020 。

fs.defaultFS 属性也兼顾指定的默认文件系统。默认文件系统用于解析相对路径，这很便于使用，可以减少键盘输入(避免硬编码特定 namenode 的地址

信息), 例如上个例子中，相对 URI /a/b 被解析为 hdfs://namenode/a/b

提示：

——————————————————————————————————————————–

如果正在运行 HDFS, 在服务器配置中指定 fs.defaultFS 同时用于指定 HDFS 的 namenode 和默认文件系统的事实意味着 HDFS 必须是默认的文件

系统。然而，出于方便性，在客户端配置中指定一个不同的文件系统也是可以的。

例如，如果要同时使用 HDFS 和 S3 文件系统，在客户端配置中可以指定其中一个作为默认文件系统，作为相对 URI 参考的默认值，而另外一个

使用绝对 URI。

还有几个其他的配置属性用于设置 HDFS: 这些用于为 namenode 和 datanode 设置存储目录。

□ dfs.namenode.name.dir 属性：

————————————————————————————————————————————-

用于指定一个目录列表，namenode 在这些目录内存储持久化文件系统元数据(编辑日志和文件系统映像 —— filesystem image)。

每个目录存储一份元数据文件的拷贝用于冗余备份。通常配置 dfs.namenode.name.dir 为使 namenode 元数据写入一个或两个

本地磁盘和一个远程磁盘，例如 NFS 挂载的(NFS-mounted)目录。这样的设置可以防护本地磁盘故障以及整个 namenode 失效

因为在这两种状况下，文件可以恢复并启动一个新的 namenode 。(secondary namenode 只是定期保存 namenode 的监测点，因此，

它不能提供一个最新的 namenode 的备份)

□ dfs.datanode.data.dir 属性：

————————————————————————————————————————————–

为 datanode 指定一个目录列表来存储它的数据块(to store its blocks in)。不像 namenode, 使用多个目录提供冗余备份，

datanode 在它列出的多个存储目录中循环地写入，因此，出于性能考虑应该为每个本地磁盘指定一个存储目录。读性能也能够从

多个磁盘存储中获益，因为数据块分布到不同的磁盘中，对不同数据块的并发读操作会相应地分布到不同的磁盘上，从而提高性能。

提示：

——————————————————————————————————————

为了充分发挥性能，应该使用 noatime 选项挂载磁盘。这个设置意味着在进行文件读操作时，accessed time 信息不会写入到文件

中，这会获得显著的性能提升。

□ dfs.namenode.checkpoint.dir 属性：

—————————————————————————————————————————————

为 secondary namenode 配置文件系统 checkpoint 的存储位置，指定一个目录列表来保存检查点。类似于 namenode 的存储目录，

为 namenode metadata 保存冗余拷贝，检查点的文件系统映像(checkpointed filesystem image) 会存储到每个检查点目录，用于

冗余备份。

注意：

—————————————————————————————————————————————-

HDFS 的存储目录默认都在 Hadoop 的临时目录下(由 hadoop.tmp.dir 属性配置，它的默认值是 /tmp/hadoop-${user.name})。因此，设置这些目录是极其

重要的，这样，当系统清除临时目录时数据才不会丢失。

Important HDFS daemon properties

+===============================+===================+===============================================+===============================================================+

| 属性名 | 类型 | 默认值 | 描述 |

+——————————-+——————-+———————————————–+—————————————————————+

| | | | and port that the namenode’s RPC server runs on. The default |

| | | | port is 8020. This property is set in core-site.xml. |

+——————————-+——————-+———————————————–+—————————————————————+

| dfs.namenode.name.dir | Commaseparated | file://${hadoop.tmp.dir}/dfs/name | The list of directories where the namenode stores its |

+——————————-+——————-+———————————————–+—————————————————————+

| dfs.datanode.data.dir | Commaseparated | file://${hadoop.tmp.dir}/dfs/data | A list of directories where the datanode stores blocks. |

+——————————-+——————-+———————————————–+—————————————————————+

| dfs.namenode.checkpoint.dir | Commaseparated | file://${hadoop.tmp.dir}/dfs/namesecondary | A list of directories where the secondary namenode stores |

| | | | checkpoints. It stores a copy of the checkpoint in each |

+——————————-+——————-+———————————————–+—————————————————————+

YARN

—————————————————————————————————————————————–

运行 YARN ，需要指定一台机器作为 resource manager 。最简单的方法是设置 yarn.resourcemanager.hostname 属性指向运行 resource manager 的主机名

或 IP 地址。多个资源管理器的服务器地址从这个属性衍生出来，例如，yarn.resourcemanager.address 使用主机-端口对(host-port pair), host 的默认值

是 yarn.resourcemanager.hostname, 在 MapReduce 客户端配置中，这个属性用于在 RPC 上连接 resource manager 。

在 MapReduce 作业期间，中间数据和工作文件被写入到临时的本地文件，因为这些数据包括可能非常大的 map 任务输出，因此，需要确保

yarn.nodemanager.local-dirs 属性配置使用的磁盘分区要足够大，它控制者 YARN 容器的本地临时存储的位置。这个属性使用一个逗号分隔的名称列表，最好

将这些目录分散到所有的本地磁盘，以提升磁盘 I/O 操作效率(这些目录采用循环方式 —— in round-robin fashion)。典型地，应该为 YARN 本地存储使用

与 datanode 块存储相同的磁盘和分区，由 dfs.datanode.data.dir 属性控制的内容。

与 MapReduce 1 不同， YARN 没有 tasktracker 来处理 map 输出到 reduce 任务，它依赖于 shuffle handlers 来处理这类操作，是一些在节点管理器上长期

运行的辅助服务(auxiliary services)。由于 YARN 是一个通用的服务(a general-purpose service), MapReduce 的 shuffle handlers 需要在 yarn-site.xml

中明确启用，通过设置 yarn.nodemanager.aux-services 属性值为 mapreduce_shuffle 。

Important YARN daemon properties

+=======================================+===================+===============================+===================================================================================+

| 属性名 | 类型 | 默认值 | 描述 |

+—————————————+——————-+——————————-+———————————————————————————–+

| | | | resource manager runs on. Abbreviated ${y.rm.hostname} below. |

+—————————————+——————-+——————————-+———————————————————————————–+

| yarn.resourcemanager.address | Hostname and port | ${y.rm.hostname}:8032 | The hostname and port that the resource manager’s RPC server runs on. |

+—————————————+——————-+——————————-+———————————————————————————–+

| yarn.nodemanager.local-dirs | Comma-separated | ${hadoop.tmp.dir}/nmlocal-dir | A list of directories where node managers allow containers to store |

| | directory names | | intermediate data. The data is cleared out when the application ends. |

+—————————————+——————-+——————————-+———————————————————————————–+

| | | | implemented by the class defined by the property yarn.nodemanager.auxservices. |

+—————————————+——————-+——————————-+———————————————————————————–+

| yarn.nodemanager.resource.memory-mb | int | 8192 | The amount of physical memory (in MB) that may be allocated to containers |

+—————————————+——————-+——————————-+———————————————————————————–+

| | | | may exceed the allocation by this amount. |

+—————————————+——————-+——————————-+———————————————————————————–+

| yarn.nodemanager.resource.cpu-vcores | int | 8 | The number of CPU cores that may be allocated to containers being run by the |

+—————————————+——————-+——————————-+———————————————————————————–+

Memory settings in YARN and MapReduce：

————————————————————————————————————————————-

YARN 以一种比 MapReduce 1 更细腻的方式处理内存，不是指定一个在一个节点上一次运行固定的最多数量的 map 和 reduce 槽(slot), YARN允许应用

程序为任务请求任意数量的内存(在限制范围内). 在 YARN 模型上，节点管理器从内存池分配内存，因此在一个特定节点上能运行的任务数量取决于它们

内存需求的总和，而不是简单的一个固定的槽的数量。

计算一个节点管理器有多少内存用于运行任务容器取决于这台机器上有多少物理内存。每个 Hadoop daemon 占用 1000 MB，因此对于数据节点，运行一个

datanode 和一个 node manager 所占用内存总数为 2000MB, 再留出足够的内存运行本机上的其他进程，然后剩下的可以提供给节点管理器的容器使用，

通过设置配置属性：

yarn.nodemanager.resource.memory-mb

设置总的分配，单位为 MB, 默认为 8192

下一步是该确定如何为单个作业设置内存选项了。有两个主要的控制：一个是由 YARN 分配的容器(container) 的大小，另一个是容器内运行的 Java

进程的堆大小。

提示：

—————————————————————————————————————————-

MapReduce 的内存控制都由客户端在 job configuration 设置， YARN 设置是集群设置并且不能被客户端修改。

容器内存大小通过 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 确定，它们的默认值都是 1024MB 。

Java 进程的堆大小由 mapred.child.java.opts 设置，默认值是 200MB 。也可以分别指定 map 和 reduce 任务。

MapReduce job memory properties (set by the client)

+===============================+===========+===========+=======================================================================+

| 属性名 | 类型 | 默认值 | 描述 |

+——————————-+———–+———–+———————————————————————–+

| mapreduce.map.memory.mb | int | 1024 | The amount of memory for map containers. |

+——————————-+———–+———–+———————————————————————–+

| mapreduce.reduce.memory.mb | int | 1024 | The amount of memory for reduce containers. |

+——————————-+———–+———–+———————————————————————–+

| | | | map and reduce tasks. In addition to memory settings, this property |

| | | | can include JVM properties for debugging, for example. |

+——————————-+———–+———–+———————————————————————–+

+——————————-+———–+———–+———————————————————————–+

+——————————-+———–+———–+———————————————————————–+

举例，假设 mapred.child.java.opts 设置为 -Xmx800m 并且 mapreduce.map.memory.mb 保持其默认值 1024 MB ，当一个 map 任务运行时，node manager

会分配一个 1024 MB 的 container(会降低内存池的大小为任务运行占用的内存数量) 并以配置为 800 MB 的最大堆内存运行任务 JVM 。

注意， JVM 进程会有比堆内存稍大些的内存占用，这个开销取决于是否使用了本地库(native libraries), 永久性生成空间的大小，等等。

比较重要的是， JVM 进程使用的物理内存，包括它产生的任何子进程，例如 Streaming 进程，不会超过它的分配内存(1024 MB)。如果一个 container

使用了比分配给它的更多的内存，它会被 node manager 终止并标记为失败的。

YARN 调度器(schedulers) 受限于一个最小或最大内存分配，最小值默认为 1024 MB(由 yarn.scheduler.minimum-allocation-mb 设置),最大值默认为

8192 MB(由 yarn.scheduler.maximum-allocation-mb 设置)。

也有容器必须满足的虚拟内存的约束，如果容器的虚拟内存使用超出了一个给定的分配的物理内存的倍数， node manager 可能会终止进程。倍数由

yarn.nodemanager.vmem-pmem-ratio 属性设置，默认为 2.1 。例如，超出任务可能被终止的虚拟内存阈值是 2150 MB ，由 2.1 x 1024 MB 计算而来。

配置内存参数时，能够在任务运行期间监视实际的内存使用是非常有用的，这可以通过 MapReduce 计数器(counter)。计数器 PHYSICAL_MEMORY_BYTES,

VIRTUAL_MEMORY_BYTES, and COMMITTED_HEAP_BYTES 提供了内存使用的快照值因此非常适合于在任务尝试过程中观察。

CPU settings in YARN and MapReduce

————————————————————————————————————————————–

除了内存， YARN 将 CPU 的使用(usage), 也作为可管理的资源，并且应用程序能够按需请求线程的数量(the number of cores)。一个 node manager 能

够分配给容器的核心(core)数量由 yarn.nodemanager.resource.cpu-vcores 属性控制，它应该设置为机器上总的线程数量，减去本机上运行的每个 daemon

进程对应一个后核心后剩余的值(datanode, node manager, 以及其他长期运行的进程)。

MapReduce jobs 能够控制分配给 map 和 reduce 容器的核心数量，通过设置 mapreduce.map.cpu.vcores 和 mapreduce.reduce.cpu.vcores 属性，这两个

值默认为 1，适合于一般情况下单线程(single-threaded) MapReduce 任务，占用一个单一的内核(core)。

3. Hadoop 守护进程的地址和端口 (Hadoop Daemon Addresses and Ports)

—————————————————————————————————————————————————-

Hadoop 守护进程通常会同时运行两个进程， RPC 服务器用于守护进程间通信，HTTP 服务器用于为用户交互提供 web 页面。每个服务器都要进行配置，设置其网络地址

和监听端口。端口号为 0 指示服务器在一个空闲的端口上启动服务，但一般不推荐使用，因为会与集群范围的防火墙策略不兼容。

通常，设置服务器的 RPC 和 HTTP 地址具有双重职责：确定服务器绑定的网络接口，以及用于客户端或集群中其他机器连接到该服务器。例如，节点管理器使用

yarn.resourcemanager.resource-tracker.address 属性找到资源管理器的地址。

将服务器绑定到多个网络接口一般情况下是可取的。但把网络地址设置成 0.0.0.0 ，对服务器来说可以工作，而另一方面的职责无法工作，因为这个地址不会被客户端或

集群内其他机器解析。一个解决方案是为客户端和服务器分别配置，但更好的方法是为服务器设置绑定主机。通过设置 yarn.resourcemanager.hostname 为主机名或 IP

地址，再设置 yarn.resourcemanager.bind-host 为 0.0.0.0, 确保资源管理器绑定到本机的所有地址上，同时也为 node manager 和客户端提供了可解析的地址。

除了一个 RPC server, 数据节点为数据块传输运行一个 TCP/IP 服务器，服务器的地址和端口通过 dfs.datanode.address 属性设置，默认值为 0.0.0.0:50010

RPC server properties

+===============================================+=======================+===================================================================================================+

| 属性名 | 默认值 | 描述 |

+———————————————–+———————–+—————————————————————————————————+

| fs.defaultFS | file:/// | When set to an HDFS URI, this property determines the namenode’s |

| | | RPC server address and port. The default port is 8020 if not specified. |

+———————————————–+———————–+—————————————————————————————————+

| dfs.namenode.rpc-bind-host | | The address the namenode’s RPC server will bind to. If not set (the default), the bind |

| | | address is determined by fs.defaultFS. It can be set to 0.0.0.0 to make the namenode |

| | | listen on all interfaces. |

+———————————————–+———————–+—————————————————————————————————+

| dfs.datanode.ipc.address | 0.0.0.0:50020 | The datanode’s RPC server address and port. |

+———————————————–+———————–+—————————————————————————————————+

| mapreduce.jobhistory.address | 0.0.0.0:10020 | The job history server’s RPC server address and port. This is used by the |

| | | client (typically outside the cluster) to query job history. |

+———————————————–+———————–+—————————————————————————————————+

| mapreduce.jobhistory.bind-host | | The address the job history server’s RPC and HTTP servers will bind to. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.hostname | 0.0.0.0 | The hostname of the machine the resource manager runs on. |

| | | Abbreviated ${y.rm.hostname} below. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.bind-host | | The address the resource manager’s RPC and HTTP servers will bind to. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.address | ${y.rm.hostname}:8032 | The resource manager’s RPC server address and port. This is used by the client (typically |

| | | outside the cluster) to communicate with the resource manager. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.admin.address | ${y.rm.hostname}:8033 | The resource manager’s admin RPC server address and port. This is used by the admin |

| | | client (invoked with yarn rmadmin, typically run outside the cluster) to communicate with |

| | | the resource manager. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.scheduler.address | ${y.rm.hostname}:8030 | The resource manager scheduler’s RPC server address and port. This is used by (incluster) |

| | | application masters to communicate with the resource manager. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.resourcemanager.resource-tracker.address | ${y.rm.hostname}:8031 | The resource manager resource tracker’s RPC server address and port. This is used by (incluster) |

| | | node managers to communicate with the resource manager. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.nodemanager.hostname | 0.0.0.0 | The hostname of the machine the node manager runs on. Abbreviated ${y.nm.hostname} below. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.nodemanager.bind-host | | The address the node manager’s RPC and HTTP servers will bind to. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.nodemanager.address | ${y.nm.hostname}:0 | The node manager’s RPC server address and port. This is used by (in-cluster) application |

| | | masters to communicate with node managers. |

+———————————————–+———————–+—————————————————————————————————+

| yarn.nodemanager.localizer.address | ${y.nm.hostname}:8040 | The node manager localizer’s RPC server address and port. |

+———————————————–+———————–+—————————————————————————————————+

HTTP server properties

+=======================================+=======================+===============================================================================================+

| 属性名 | 默认值 | 描述 |

+—————————————+———————–+———————————————————————————————–+

| dfs.namenode.http-address | 0.0.0.0:50070 | The namenode’s HTTP server address and port. |

+—————————————+———————–+———————————————————————————————–+

| dfs.namenode.http-bind-host | | The address the namenode’s HTTP server will bind to. |

+—————————————+———————–+———————————————————————————————–+

| dfs.namenode.secondary.http-address | 0.0.0.0:50090 | The secondary namenode’s HTTP server address and port. |

+—————————————+———————–+———————————————————————————————–+

| dfs.datanode.http.address | 0.0.0.0:50075 | The datanode’s HTTP server address and port. |

| | | (Note that the property name is inconsistent with the ones for the namenode.) |

+—————————————+———————–+———————————————————————————————–+

| mapreduce.jobhistory.webapp.address | 0.0.0.0:19888 | The MapReduce job history server’s address and port. This property is set in mapred-site.xml. |

+—————————————+———————–+———————————————————————————————–+

| mapreduce.shuffle.port | 13562 | The shuffle handler’s HTTP port number. This is used for serving map outputs, and is not a |

| | | useraccessible web UI. This property is set in mapred-site.xml. |

+—————————————+———————–+———————————————————————————————–+

| yarn.resourcemanager.webapp.address | ${y.rm.hostname}:8088 | The resource manager’s HTTP server address and port. |

+—————————————+———————–+———————————————————————————————–+

| yarn.nodemanager.webapp.address | ${y.nm.hostname}:8042 | The node manager’s HTTP server address and port. |

+—————————————+———————–+———————————————————————————————–+

| yarn.web-proxy.address | | The web app proxy server’s HTTP server address and port. If not set (the default), then the |

| | | web app proxy server will run in the resource manager process. |

+—————————————+———————–+———————————————————————————————–+

也有一个设置用于控制 datanode 使用哪个网络接口作为它的 IP 地址(HTTP 和 RPC 服务器)，相关属性为 dfs.datanode.dns.interface, 设置为 default 使用默认网络接口。

可以明确设置为指定的接口来作为地址(例如 eho0 )

4. Hadoop 其他属性 (Other Hadoop Properties)

—————————————————————————————————————————————————-

集群成员(Cluster membership)

————————————————————————————————————————————————

为了帮助将来添加和移除节点，可以指定一个文件包含一个授权机器的列表允许加入集群作为 datanode 或 node manager 。这类文件由 dfs.hosts 和

yarn.resourcemanager.nodes.include-path 属性设置(分别用于指定 datanode 和 node manager)，默认为空表示允许所有机器加入。对应的 dfs.hosts.exclude

和 yarn.resourcemanager.nodes.exclude-path 属性用于指定不允许加入集群的主机文件列表。

缓冲区大小(Buffer size)

————————————————————————————————————————————————

Hadoop 使用 4KB(4096 bytes)的缓冲区进行 I/O 操作。这是一个很保守的设置，对于现代的硬件和操作系统来说，增大缓冲区会显著提高性能，128KB (131072

bytes) 是一个比较常用的选择，通过 core-site.xml 文件中 io.file.buffer.size 属性设置以字节为单位的值来设置缓冲区大小。

HDFS 数据块大小 (HDFS block size)

————————————————————————————————————————————————

HDFS 数据块默认大小为 128MB，但很多集群使用更大的块(例如， 256 MB，即 268,435,456 bytes)以缓解 namenode 的内存压力，并给 mapper 提供更多的数据

进行操作。可以通过 hdfs-site.xml 文件中的 dfs.blocksize 属性设置以字节为单位的值指定块大小。

保留的存储空间(Reserved storage space)

————————————————————————————————————————————————

默认情况下， datanode 会使用存储目录上所有闲置的空间。如果计划将这些存储空间保留一部分给其他应用程序(非 HDFS )，可以设置 dfs.datanode.du.reserved

以字节为单位的数值，用于存储空间保留。

回收站 (Trash)

————————————————————————————————————————————————

Hadoop 文件系统也有回收站设施，被删除文件并未真正被删除，而是移到回收站文件夹中，回收站中的文件在被系统永久删除之前会保留一个最小期限。文件在回收

站内保留的最小期限由 core-site.xml 文件内的 fs.trash.interval 配置属性设置，单位为分钟(in minutes)。默认值为 0 ，表示禁用回收站机制。

类似许多操作系统， Hadoop 的回收站设施是用户级特性，也就是说，只有使用文件系统 shell 直接删除的文件才会被放入回收站。编程实现的文件删除会被立即删除。

然而，编程使用回收站也是可以的，构造一个 Trash 实例，然后调用它的 moveToTrash() method, 提供要删除的文件的 Path 参数。该方法返回值指定操作是否成功，

值 false 意味着或者回收站没有启用，或者该文件已存在于回收站中。

当回收站启用时，每个用户都有其自己的回收站目录，在其自己的 home 目录内，名为 .Trash 。文件恢复很简单：在 .Trash 子目录内找到要恢复的文件，并把它

移出.Trash 子目录。

HDFS 能自动删除回收站文件夹中的文件，但其他文件系统不会，因此，应该安排定期删除。可以清理(expunge)回收站，删除回收站内已经超过最小期限的文件。使用

如下文件系统 shell 命令：

% hadoop fs -expunge

Trash 类的 expunge() method 具有相同的效果。

作业调度 (Job scheduler)

————————————————————————————————————————————————

特别在多用户设置中，考虑升级作业调度器(job scheduler) 队列配置以反映组织的需要。例如，可以设置为每个使用集群的组使用一个队列。

慢启动 reduce (Reduce slow start)

————————————————————————————————————————————————

默认情况下，调度器会等待作业中有 5% 的 map 任务完成后调度同一作业中的 reduce 任务。对于大型作业来说，这可能会导致集群的利用率问题，因为在等待 map

任务完成期间会占用 reduce container. 设置 mapreduce.job.reduce.slowstart.completedmaps 为一个更高的值，例如 0.80 (80%), 能够帮助提升吞吐量。

短路本地读取 (Short-circuit local reads)

————————————————————————————————————————————————

当从 HDFS 读取一个文件的时候，客户端联系 datanode, 然后数据通过 TCP 连接发送给客户端。如果要读取的数据块与客户端在同一节点上，那会非常高效，因为

客户端不需要经过(bypass)网络，直接从磁盘读取块数据，这被称为短路本地读取( short-circuit local read ), 这使应用程序像 HBase 一样执行高效执行。

可以通过设置 dfs.client.read.shortcircuit 值为 true 来启用短路本地读取。本地短路读取使用 Unix domain sockets Unix domain sockets 实现，使用一个

本地路径为 client-datanode 提供通信。路径(path) 由 dfs.domain.socket.path 设置，而且必须是一个只能 datanode user (typically hdfs) 或 root 创建的

路径，例如， /var/run/hadoop-hdfs/dn_socket.

4 安全性 ( Security )

———————————————————————————————————————————————————

雅虎公司在 2009 年组织了一个工程师团队来实现 Hadoop 的安全认证。

在这个设计中， Hadoop 本身不管理用户凭证(user credentials), 而是依赖于 Kerberos ———— 一个成熟的开源网络认证协议，来认证用户。

然而，Kerberos 并不管理许可权限(permissions), Kerberos 的职责在于鉴定一个用户是她所声称的那个人，确定这个用户是否有权限执行一个给定的操作

是 Hadoop 的工作。

1. Kerberos 和 Hadoop (Kerberos and Hadoop)

—————————————————————————————————————————————————-

从高级的角度看，使用 Kerberos ，客户端必须通过三个步骤才可以访问一个服务，每一个步骤都包含一个与一个服务器交换的消息：

① 认证(Authentication) ：客户端向认证服务器(Authentication Server) 认证自己，并接收一个带有时间戳的 Ticket-Granting Ticket(TGT)

② 授权(Authorization) ：客户端使用 TGT 向授权服务器 Ticket-Granting Server 请求一个服务票据(service ticket).

③ 服务请求(Service request)：客户端将 service ticket 提供给客户端要使用服务的服务器，来认证它自己。在 Hadoop 场景内，这可能是一个namenode 或者

resource manager 等。

认证服务器(Authentication Server)和授权服务器(Ticket Granting Server) 一起构成了密钥分配中心( Key Distribution Center —— KDC) 。

授权和服务请求步骤不是用户级(user-level)操作，客户端代表用户执行这两个步骤。认证阶段则通常由用户使用 kinit 命令明确执行，这个命令会提示用户口令。这并不

意味着每次运行一个作业或访问 HDFS 都需要输入口令，因为 TGT 默认有10个小时的有效期(可以更新至一周)。通常的做法是在操作系统登录时自动认证，从而提供单次登

录(single sign-on) 到 Hadoop 。

在有些场景下不期望被提示输入密码(例如执行一个无人职守的 MapReduce 作业), 可以使用 ktutil 命令创建一个 Kerberos keytab 文件。 keytab 文件保存了用户密码,

可以通过 -t 选项提供给 kinit 命令。

示例：

————————————————————————————————————————————————-

第一步，通过 core-site.xml 中设置 hadoop.security.authentication 属性值为 kerberos 来启用 Kerberos 认证，默认值是 simple, 表示传统的向后兼容(

backward-compatible)方式 ———— 但不安全，即利用操作系统用户名确定登录者身份。

也需要设置 hadoop.security.authorization 值为 true 来启用服务级别授权(service-level authorization), 可以在hadoop-policy.xml 配置文件中配置访问控制

列表(access control lists, ACLs) 来控制哪些用户和组具有连接各个 Hadoop 服务的许可权限(permission)。服务定义在协议级别，因此有针对 MapReduce 作业提

交的，有针对 namenode 通信的，等等。

默认情况下，所有的 ACLs 都设置为 * ，意味着所有的用户都有访问各个服务的许可权限；而在实际的集群中，应该将 ACL 仅仅锁定在那些需要访问的用户和组上。

ACL 的格式是一个逗号分隔的用户名列表，后跟一个空格，后面是一个逗号分隔的组名称列表。例如，这个 ACL:

preston,howard directors,inventors

授权访问给用户名为 preston 或 howard, 或者在 directors 或 inventors 组中的用户。

Kerberos 认证启用之后，需要从 KDC 获取 Kerberos ticket ，然后才能工作：

% kinit

Password for hadoop-user@LOCALDOMAIN: password

% hadoop fs -put quangle.txt .

% hadoop fs -stat %n quangle.txt

quangle.txt

拿到 ticket 之后，各项工作就跟平常情况下一样了。

2. 委托令牌 (Delegation Tokens)

—————————————————————————————————————————————————–

在如 HDFS 或 MapReduce 的分布式系统中，有众多的客户端-服务器交互，每次交互都必须认证。例如，一个 HDFS 的读操作包括几次的 namenode 调用和一或多次的

datanode 调用。并非每次调用都使用 Kerberos ticket 的三步交换协议认证，那会给一个繁忙集群中的 KDC 造成很高的负载， Hadoop 使用委托令牌来支持后续的认证

不必再次访问 KDC 。委托令牌的创建和使用透明地由 Hadoop 代表用户的行为进行，因此用户使用 kinit 登录之后就没有什么需要做的了。

对于默认的 HDFS 实例，委托令牌会自动获得，但如果一个作业需要访问其他的 HDFS 集群，需要设置 mapreduce.job.hdfs-servers 作业属性的值为逗号分隔的 HDFS URI

列表才能载入那个集群的委托令牌。

3. 其他安全性改进 (Other Security Enhancements)

—————————————————————————————————————————————————-

Hadoop stack 已全面强化安全性来防护未授权的资源访问，显著的特性如下：

① 任务可以使用提交作业的操作系统帐号运行，而不必由运行 node manager 的用户运行。这意味着操作系统可以用于隔离任务运行，使它们彼此不能发送信号(

例如，杀掉另一用户的任务), 同时，本地的信息，例如任务数据，会通过本地文件系统许可权保持私有。

这个特性通过设置 yarn.nodemanager.container-executor.class 属性为 org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor 启用。另外，

管理员要确保每个用户在集群的每个节点上都有一个帐号(通常使用 LDAP).

② 当任务以提交作业的用户运行时，分布式缓存(distributed cache)是安全的。

③ 用户只能看到和修改他们自己的作业，无法操作其他人的作业。启用这个特性需要设置 mapreduce.cluster.acls.enabled 值为 true 。有两个作业配置属性

mapreduce.job.acl-view-job 和 mapreduce.job.acl-modify-job, 可以设置一个逗号分隔的用户列表，用于控制哪些用户可以查看或修改一个特定的作业。

④ shuffle 是安全的，阻止恶意用户请求获取其他用户的 map 输出。

⑤ 正确配置之后，可以阻止恶意用户运行虚假的 secondary namenode, datanode, 或 nodemanager 加入集群，潜在地窃取集群上存储的数据。可以通过强制要求

daemon 与它要连接的 master 节点间认证来实现。要启用这个特性，首先需要配置 Hadoop 使用一个由 ktutil 命令生成的 keytab 文件。例如，对于一个

datanode, 需要设置 dfs.datanode.keytab.file 值为 keytab 文件名，并且设置 dfs.datanode.kerberos.principal 的值为使用这个 datanode 的用户名。

最后，hadoop-policy.xml 文件中 DataNodeProtocol 的 ACL 必须设置(用于 datanode 和 namenode 间通信)，限制 security.datanode.protocol.acl 为

datanode 的用户名。

⑥ datanode 可以运行在专有端口上(小于1024)，使客户端确信它是安全启动的。

⑦ 任务仅与其父 application master 通信，因而阻止攻击者从其他的用户作业获取到 MapReduce 作业。

⑧ Hadoop 的很多部分可以加密网络数据，包括 RPC (hadoop.rpc.protection), HDFS 块传输 (dfs.encrypt.data.transfer), MapReduce shuffle (

mapreduce.shuffle.ssl.enabled), web UI (hadoop.ssl.enabled)

5 利用基准评测程序测试 Hadoop 集群 (Benchmarking a Hadoop Cluster)

——————————————————————————————————————————————————–

基准测试程序(Benchmarks)能进行很好的测试，用户可以拿测试结果与其他集群进行比较，以检查新集群是否粗略地按预期效果执行。还可以使用评测结果调整集群，以榨取

它的最佳性能。一般通过监视系统，观察集群上资源的使用情况。

1. Hadoop 基准评测程序 (Hadoop Benchmarks)

—————————————————————————————————————————————————

Hadoop 自带几个基准评测程序，极小的安装开销，运行方便。基准评测程序都打包到 tests JAR 文件中，通过无参数调用，可以获得这些程序的列表及其描述：

% hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-*-tests.jar

当使用无参数调用时，大多数基准评测程序都显示其使用方法，例如：

% hadoop jar $HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-*-tests.jar TestDFSIO

TestDFSIO.1.7

Missing arguments.

Usage: TestDFSIO [genericOptions] -read [-random | -backward |

-skip [-skipSize Size]] | -write | -append | -clean [-compression codecClassName]

[-nrFiles N] [-size Size[B|KB|MB|GB|TB]] [-resFile resultFileName]

[-bufferSize Bytes] [-rootDir]

使用 TeraSort 评测 MapReduce (Benchmarking MapReduce with TeraSort)

————————————————————————————————————————————————

Hadoop 自带的 MapReduce 程序 TeraSort 对它的输入进行全部排序。它对同时评测 HDFS 和 MapReduce 是很有用的，因为整个数据集都是通过 shuffle 传输的。

测试过程经过三个步骤：创建随机数，执行排序和验证结果。

首先，使用 teragen 生成一些随机数据。

It runs a map-only job that generates a specified number of rows of binary data. Each row is 100 bytes long, so to generate one

terabyte of data using 1,000 maps, run the following (10t is short for 10 trillion)

% hadoop jar \

$HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \

teragen -Dmapreduce.job.maps=1000 10t random-data

下一步，运行 terasort:

% hadoop jar \

$HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \

terasort random-data sorted-data

最后的检查，验证 sorted-data 中的数据，是否正确排序了：

% hadoop jar \

$HADOOP_HOME/share/hadoop/mapreduce/hadoop-mapreduce-examples-*.jar \

teravalidate sorted-data report

其他基准测试程序 (Other benchmarks)）

———————————————————————————————————————————————–

Hadoop 自带了很多基准测试程序，但下面内容的使用广泛：

TestDFSIO ：测试 HDFS 的 I/O 性能，它使用个 MapReduce 作业并发地读写文件。

MRBench (invoked with mrbench) ：多次运行一个小型作业，与 TeraSort 不同，该基准测试的目的是检验小型作业能否快速响应。

NNBench (invoked with nnbench) ：用于 namenode 硬件加载测试 (load-testing)

Gridmix : 一个基准测试套件，设计通过模拟真实常见的数据访问模式来为集群负载建模。

SWIM, or the Statistical Workload Injector for MapReduce ：is a repository of real-life MapReduce workloads that you can use to generate

representative test workloads for your system.

TPCx-HS ：is a standardized benchmark based on TeraSort from the Transaction Processing Performance Council.

2. 用户作业 (User Jobs)

—————————————————————————————————————————————————-

为了集群调优，最好包含一些用户运行的代表性作业，这样集群调优针对这些作业而不仅仅是标准基准测试。如果这是第一个 Hadoop 集群，还没有任何的用户作业，

Gridmix 或 SWIM 是一个很好的替代。

如果运行自己的作业作为基准测试，应该为自己的用户作业选择一个数据集，并且每次运行都使用它能对不同的运行结果进行比较。当设置新的集群或升级时，可以

使用相同的数据集比较前后的运行性能。

免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/5477.html

构建 Hadoop 集群

相关推荐

发表回复