前言
该部署文档是笔者在一台配置稍微较高的笔记本电脑上利用虚拟化技术(VMware)创建3台linux操作系统虚拟机作为分布式搭建基础来操练大数据hadoop框架搭建，高度模拟出符合/类似生产环境的搭建方式进行部署，为在生产环境使用提供更真实的参考价值!
附录A中简单列出了真实生产环境部署的方式建议供参考
改文章属于笔记性文章，这里笔者只是纯属记录方便以后查阅。
HDFS原理
NameNode和DataNode
HDFS具有主/从架构。HDFS集群由单个NameNode，一个管理文件系统命名空间的主服务器和管理客户端对文件的访问组成。此外，还有许多DataNode，通常是群集中每个节点一个，用于管理连接到它们运行的节点的存储。HDFS公开文件系统命名空间，并允许用户数据存储在文件中。在内部，文件被分成一个或多个块，这些块存储在一组DataNode中。NameNode执行文件系统命名空间操作，如打开，关闭和重命名文件和目录。它还确定了块到DataNode的映射。DataNode负责提供来自文件系统客户端的读写请求。DataNodes还执行块创建，删除。
NameNode和DataNode是设计用于在商用机器上运行的软件。这些机器通常运行GNU / Linux操作系统（OS）。HDFS是使用Java语言构建的; 任何支持Java的机器都可以运行NameNode或DataNode软件。使用高度可移植的Java语言意味着可以在各种计算机上部署HDFS。典型部署具有仅运行NameNode软件的专用计算机。群集中的每台其他计算机都运行一个DataNode软件实例。该体系结构不排除在同一台机器上运行多个DataNode，但在实际部署中很少出现这种情况。
群集中存在单个NameNode极大地简化了系统的体系结构。NameNode是所有HDFS元数据的仲裁者和存储库。系统的设计使用户数据永远不会流经NameNode
数据副本
HDFS旨在可靠地在大型群集中的计算机上存储非常大的文件。它将每个文件存储为一系列块。复制文件的块以实现容错。块大小和复制因子可根据文件进行配置。
除最后一个块之外的文件中的所有块都具有相同的大小，而用户可以在添加对可变长度块的支持以追加和hsync之后启动新块而不将最后一个块填充到配置的块大小。
应用程序可以指定文件的副本数。复制因子可以在文件创建时指定，并可以在以后更改。HDFS中的文件是一次写入的（除了追加和截断），并且在任何时候都有一个写入器。
NameNode做出有关块复制的所有决定。它定期从群集中的每个DataNode接收Heartbeat和Blockreport。收到心跳意味着DataNode正常运行。Blockreport包含DataNode上所有块的列表。
副本安置
复制品的放置对HDFS的可靠性和性能至关重要。优化副本放置可将HDFS与大多数其他分布式文件系统区分开来。这是一项需要大量调整和体验的功能。机架感知副本放置策略的目的是提高数据可靠性，可用性和网络带宽利用率。副本放置策略的当前实现是朝这个方向的第一次努力。实施此政策的短期目标是在生产系统上验证它，更多地了解其行为，并为测试和研究更复杂的策略奠定基础。
大型HDFS实例在通常分布在多个机架上的计算机群集上运行。不同机架中两个节点之间的通信必须通过交换机。在大多数情况下，同一机架中的计算机之间的网络带宽大于不同机架中的计算机之间的网络带宽。
NameNode通过Hadoop Rack Awareness中概述的过程确定每个DataNode所属的机架ID 。一个简单但非最优的策略是将复制品放在独特的机架上。这可以防止在整个机架出现故障时丢失数据，并允许在读取数据时使用来自多个机架的带宽。此策略在群集中均匀分布副本，这样可以轻松平衡组件故障的负载。但是，此策略会增加写入成本，因为写入需要将块传输到多个机架。
对于常见情况，当复制因子为3时，HDFS的放置策略是在编写器位于datanode上时将一个副本放在本地计算机上，否则放在随机datanode上，在另一个（远程）机架上的节点上放置另一个副本，最后一个在同一个远程机架中的另一个节点上。此策略可以减少机架间写入流量，从而提高写入性能。机架故障的可能性远小于节点故障的可能性; 此策略不会影响数据可靠性和可用性保证。但是，它确实减少了读取数据时使用的聚合网络带宽，因为块只放在两个唯一的机架而不是三个。使用此策略时，文件的副本不会均匀分布在机架上。三分之一的副本位于一个节点上，三分之二的副本位于一个机架上，另外三分之一均匀分布在剩余的机架上。此策略可提高写入性能，而不会影响数据可靠性或读取性能。
如果复制因子大于3，则随机确定第4个及以下副本的放置，同时保持每个机架的副本数量低于上限（基本上是（副本 - 1）/机架+ 2）。
由于NameNode不允许DataNode具有同一块的多个副本，因此创建的最大副本数是此时DataNode的总数。
在将存储类型和存储策略的支持添加到HDFS之后，除了上述机架感知之外，NameNode还会考虑策略以进行副本放置。NameNode首先根据机架感知选择节点，然后检查候选节点是否具有与文件关联的策略所需的存储。如果候选节点没有存储类型，则NameNode将查找另一个节点。如果在第一个路径中找不到足够的节点来放置副本，则NameNode会在第二个路径中查找具有回退存储类型的节点。
此处描述的当前默认副本放置策略是正在进行的工作。
副本选择
为了最大限度地减少全局带宽消耗和读取延迟，HDFS尝试满足最接近读取器的副本的读取请求。如果在与读取器节点相同的机架上存在副本，则该副本首选满足读取请求。如果HDFS群集跨越多个数据中心，则驻留在本地数据中心的副本优先于任何远程副本。
部署服务器清单
这里仅说明3台机子，ip是笔者部署后的ip地址，读者请按你自己的为准（具体ip设置方式后面有讲解）! 另外由于用于学习，所以机子配置很低，实际中的生产环境应该使用更多的机子和更高的配置；
笔者物理机（DELL 笔记本）配置信息：
cpu（Intel(R) i5-7200U） | 内存（RAM） | 磁盘（SSD） |
4Core | 8G | 256M |
虚拟化3台虚拟机配置信息：
节点名称 | ip | cpu | 内存 | 磁盘 |
node1 | 192.168.137.101 | 1C | 2G | 10G |
node2 | 192.168.137.102 | 1C | 2G | 10G |
node3 | 192.168.137.103 | 1C | 2G | 10G |
虚拟化3个节点
这里参考笔者的另外一篇文章：创建虚拟机
集群部署前期工作
节点时间同步
这里笔者使用XShell ssh客户端访问3个服务器节点，访问比较方便，可以将某条命令发送到当前的所有会话
安装/更新 ntpdate命令，发送到3个节点
yum install -y ntpdate
笔者使用阿里云网络服务器，读者可以自行百度其它的
ntpdate ntp1.aliyun.com
配置/etc/hosts
vi /etc/hosts
复制下面内容到hosts文件
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.137.101 node1
192.168.137.102 node2
192.168.137.103 node3
分发到其它两台节点在node2 node3节点分别执行：
scp -r root@node1:/etc/hosts /etc/hosts
配置ssh免密
所有节点执行：
ssh-keygen -t rsa
一路回车即可创建ssh公私钥，创建ssh公私钥匙后通过执行下面命令配置免密：
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node1
yes 输入密码
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node2
yes 输入密码
ssh-copy-id -i /root/.ssh/id_rsa.pub root@node3
yes 输入密码
测试免密：
ssh node1
exit
ssh node2
exit
ssh node3
exit
测试OK后进入下一步
下载、安装jdk8
jdk8下载和安装不演示，这里主要给出规划的目录：
1、软件压缩包放置目录: /opt/zip
2、软件解压放置目录: /opt/soft
3、hdfs数据存储目录: /var/hadoop/hdfs
下载hadoop3
自行下载，这里注意版本号为：3.1.1，下载到/opt/zip 解压到/opt/soft， 配置环境变量
vi /etc/profile
笔者追加内容到/etc/profile如下：
export JAVA_HOME=/opt/soft/jdk1.8.0_161
export HADOOP_HOME=/opt/soft/hadoop-3.1.1
PATH=$PATH:$JAVA_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
export PATH
执行source /etc/profile使配置生效。
检查命令：
javac
hadoop version
部署计划
hdfs | |
node1(Master) | NameNode Secondary Namenode |
node2(Work) | DataNode |
node3(Work) | DataNode |
配置HDFS相关文件
由于集群环境节点比较多，配置需要方法，这里思路是先配置好一个节点，然后使用scp命令分发到其它节点，下面是分别对不同的配置文件进行配置说明：
hadoop-env.sh
$HADOOP_HOME/etc/hadoop/hadoop-env.sh末尾追加如下内容：
export JAVA_HOME=/opt/soft/jdk1.8.0_161
export HDFS_NAMENODE_USER="root"
export HDFS_DATANODE_USER="root"
export HDFS_SECONDARYNAMENODE_USER="root"
注意：官方推荐hdfs，yarm，分别创建用户,这里简单起见，直接统一使用root用户，生产环境建议按官方推荐方式配置。
core-site.xml
$HADOOP_HOME/etc/hadoop/core-site.xml配置内容如下：
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://node1:9000</value>
</property>
<property>
<name>io.file.buffer.size</name>
<value>131072</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/var/hadoop</value>
</property>
</configuration>
hdfs.site.xml
$HADOOP_HOME/etc/hadoop/hdfs-site.xml配置内容如下：
<configuration>
<!-- Configurations for NameNode: -->
<property>
<name>dfs.namenode.name.dir</name>
<value>/var/hadoop/hdfs/namenode</value>
</property>
<property>
<name>dfs.blocksize</name>
<value>268435456</value>
</property>
<property>
<name>dfs.namenode.handler.count </name>
<value>100</value>
</property>
<!-- Configurations for DataNode: -->
<property>
<name>dfs.datanode.data.dir</name>
<value>/var/hadoop/hdfs/datanode</value>
</property>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
</configuration>
workers
$HADOOP_HOME/etc/hadoop/workersl配置内容如下：
node2
node3
分发到其它节点
在需要分发的节点上执行:
scp -r root@node1:/opt/soft/ /opt/
scp -r root@node1:/etc/profile /etc/profile
所有节点执行: source /etc/profile使配置生效。
启动hadoop
用jps命令检查目前节点是否有java进程，如果有请先停掉，然后在master（node1）节点执行启动脚本：
start-dfs.sh
start-yarm.sh
mapred --daemon start historyserver
node1:
node2:
node3:
浏览器访问：
节点信息界面：http://192.168.137.101:9870
所有应用管理界面：http://192.168.137.101:8088
job任务历史记录界面：http://192.168.137.101:19888
还有一点要说明的是启动log在$HADOOP_HOME/logs目录下，可以在hadoop-env.sh进行配置HADOOP_LOG_DIR；如HADOOP_LOG_DIR=/tmp/hadoop/logs
操作HDFS
查看命令帮助：
hadoop fs -help
查看目录列表：
创建目录后查看:
更多命令可以查看官网：
https://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/FileSystemShell.html#ls
NameNode高可用
概述
在典型的HA群集中，两个或多个单独的计算机配置为NameNode。在任何时间点，其中一个NameNode处于活动状态，而其他NameNode 处于待机状态。Active NameNode负责集群中的所有客户端操作，而Standbys只是充当工作者，维持足够的状态以在必要时提供快速故障转移。
为了使备用节点保持其状态与Active节点同步，两个节点都与一组称为“JournalNodes”（JN）的单独守护进程通信。当Active节点执行任何名称空间修改时，它会将修改记录持久地记录到大多数这些JN中。待机节点能够从JN读取编辑，并且不断观察它们对编辑日志的更改。当备用节点看到编辑时，它会将它们应用到自己的命名空间。如果发生故障转移，Standby将确保在将自身升级为Active状态之前已从JournalNodes读取所有编辑内容。这可确保在发生故障转移之前完全同步命名空间状态。
为了提供快速故障转移，备用节点还必须具有关于群集中块的位置的最新信息。为了实现这一点，DataNode配置了所有NameNode的位置，并向所有人发送块位置信息和心跳。
对于HA群集的正确操作而言，一次只有一个NameNode处于活动状态至关重要。否则，命名空间状态将在两者之间快速分歧，冒着数据丢失或其他不正确结果的风险。为了确保这个属性并防止所谓的“裂脑情景”，JournalNodes只允许一个NameNode一次成为一个作家。在故障转移期间，要激活的NameNode将简单地接管写入JournalNodes的角色，这将有效地阻止其他NameNode继续处于Active状态，从而允许新的Active安全地进行故障转移。
部署计划
通过QJM实现NameNode的HA群集，您应准备以下内容：
NameNode - 运行Active和Standby NameNode的计算机应具有彼此相同的硬件，以及与非HA集群中使用的硬件等效的硬件。
JournalNode - 运行JournalNodes的计算机。JournalNode守护程序相对轻量级，因此这些守护程序可以合理地与其他Hadoop守护程序并置在机器上，例如NameNodes，JobTracker或YARN ResourceManager。注意：必须至少有3个JournalNode守护进程，因为编辑日志修改必须写入大多数JN。这将允许系统容忍单个机器的故障。您也可以运行3个以上的JournalNodes，但为了实际增加系统可以容忍的失败次数，您应该运行奇数个JN（即3,5,7等）。请注意，当使用N JournalNodes运行时，系统最多可以容忍（N-1）/ 2个故障并继续正常运行。
请注意，在HA群集中，备用NameNode还会执行命名空间状态的检查点，因此无需在HA群集中运行Secondary NameNode，CheckpointNode或BackupNode。事实上，这样做会是一个错误。这还允许正在重新配置启用HA的HDFS群集的人员启用HA，以重用他们之前专用于Secondary NameNode的硬件。
通过QJM实现NameNode的高可用部署，具体部署如下：
现有部署如下：
hdfs | |
node1(Master) | NameNode Secondary Namenode |
node2(Work) | DataNode |
node3(Work) | DataNode |
在现有部署结构上增加Quorum Journal Manager相关角色进来之后的部署如下：
hdfs | QJM | |
node1(Master) | NameNode | JournalNode |
node2(Work) | NameNode DataNode | JournalNode |
node3(Work) | NameNode DataNode | JournalNode |
配置
hdfs-site.xml
要配置HA NameNode，必须向hdfs-site.xml配置文件添加多个配置选项。首先配置集群名称
以及集群中每个namenode id
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2, nn3</value>
</property>
上面设置的这些配置的顺序并不重要，但您为dfs.nameservices和dfs.ha.namenodes。[nameservice ID]选择的值将确定后面的那些键。因此，在设置其余配置选项之前，您应该决定这些值。
HA的NameNode最小数量为2，但您可以配置更多。由于通信开销，建议不要超过5 - 推荐3个NameNodes。
下面对于两个先前配置的NameNode ID，设置NameNode进程的完整地址和IPC端口
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>node1:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>node2:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn3</name>
<value>node3:8020</value>
</property>
与上面的rpc-address类似，设置两个NameNodes的HTTP服务器的地址以进行侦听
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>node1:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>node2:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn3</name>
<value>node3:9870</value>
</property>
这是一个配置JournalNodes的地址的地方，它提供共享编辑存储，由Active nameNode写入并由Standby NameNode读取，以保持Active NameNode所做的所有文件系统更改的最新状态。虽然您必须指定多个JournalNode地址，但您应该只配置其中一个URI。URI应该是以下形式：qjournal：// * host1：port1 *; * host2：port2 *; * host3：port3 * / * journalId *。Journal ID是此nameservice的唯一标识符，它允许一组JournalNodes为多个联合名称系统提供存储。虽然不是必需的，但最好重用日志标识符的名称服务ID。
例如，如果此群集的JournalNodes在计算机“node1”，“node2”和“node3”上运行，并且名称服务ID是“mycluster”，则您将使用以下为此设置的值（JournalNode的默认端口为8485）：
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node1:8485;node2:8485;node3:8485/mycluster</value>
</property>
存储JN使用的编辑和其他本地状态
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/var/hadoop/hdfs/journal</value>
</property>
配置Java类的名称，DFS客户端将使用该名称来确定哪个NameNode是当前的Active，以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（对于第一次调用，它同时调用所有名称节点以确定活动的名称，并在后续请求中调用活动的名称节点直到发生故障转移），所以除非您使用自定义代理提供程序，否则请使用其中一个。
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
对于系统的正确性，期望在任何给定时间只有一个NameNode处于活动状态。重要的是，在使用Quorum Journal Manager时，只允许一个NameNode写入JournalNodes，因此不存在从裂脑情况中破坏文件系统元数据的可能性。但是，当发生故障转移时，以前的Active NameNode仍可能向客户端提供读取请求，这可能已过期，直到NameNode在尝试写入JournalNode时关闭。因此，即使使用Quorum Journal Manager，仍然需要配置一些防护方法。但是，为了在防护机制失败的情况下提高系统的可用性，建议配置防护方法，该方法可保证作为列表中的最后一个防护方法返回成功
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>
如果shell命令返回退出代码0，则确定防护成功。如果它返回任何其他退出代码，则防护不成功，将尝试列表中的下一个防护方法。所以为了加强防护能力，可以适当多配置几个选项， 如：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(test -d /)</value>
</property>
配置完成后的hdfs-site.xml文件内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!-- Put site-specific property overrides in this file. -->
<configuration>
<!-- Configurations for NameNode: -->
<property>
<name>dfs.namenode.name.dir</name>
<value>/var/hadoop/hdfs/namenode</value>
</property>
<property>
<name>dfs.blocksize</name>
<value>268435456</value>
</property>
<property>
<name>dfs.namenode.handler.count </name>
<value>100</value>
</property>
<!-- Configurations for DataNode: -->
<property>
<name>dfs.datanode.data.dir</name>
<value>/var/hadoop/hdfs/datanode</value>
</property>
<property>
<name>dfs.replication</name>
<value>2</value>
</property>
<!-- NameNode HA With QJM Added Config Item -->
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2,nn3</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>node1:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>node2:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn3</name>
<value>node3:8020</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>node1:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>node2:9870</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn3</name>
<value>node3:9870</value>
</property>
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node1:8485;node2:8485;node3:8485/mycluster</value>
</property>
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/var/hadoop/hdfs/journal</value>
</property>
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(test -d /)</value>
</property>
</configuration>
core-site.xml
配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
配置完成后新的core-site.xml文件内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!-- Put site-specific property overrides in this file. -->
<configuration>
<property>
<name>hadoop.tmp.dir</name>
<value>/var/hadoop</value>
</property>
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
<property>
<name>io.file.buffer.size</name>
<value>131072</value>
</property>
</configuration>
hadoop-env.sh
末尾追加:
export HDFS_JOURNALNODE_USER="root"
分发到其它节点
其它节点执行命令:
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/hadoop-env.sh /opt/soft/hadoop-3.1.1/etc/hadoop/hadoop-env.sh
启动高可用集群
在设置了所有必需的配置选项后，必须在将运行它们的一组计算机上启动JournalNode守护程序。这可以通过运行命令“ hdfs --daemon start journalnode ”并等待守护进程在每个相关机器上启动来完成。
一旦启动了JournalNodes，就必须首先同步两个HA NameNodes的磁盘元数据。
如果要设置新的HDFS集群，则应首先在其中一个NameNode上运行format命令（hdfs namenode -format）。
如果您已经格式化了NameNode，或者正在将启用了HA的群集转换为启用HA，则现在应该通过运行命令将NameNode元数据目录的内容复制到其他未格式化的NameNode上。hdfs namenode -bootstrapStandby “在未格式化的NameNode上。运行此命令还将确保JournalNodes（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务，以便能够启动两个NameNode。
如果要将非HA NameNode转换为HA，则应运行命令“ hdfs namenode -initializeSharedEdits ”，该命令将使用本地NameNode编辑目录中的编辑数据初始化JournalNodes。
我们适用的情况是将非HA NameNode转换为HA，则应运行命令“ hdfs namenode -initializeSharedEdits ”，在运行该命令前需要先停止Secondary NameNode，CheckpointNode或BackupNode，以及namenode，具体执行命令步骤如下：
在所有节点执行：
mkdir -p /var/hadoop/hdfs/journal
在主节点node1执行：
dfs -daemon stop secondarynamenode
在主节点node1继续执行stop-dfs.sh：
在主节点node1继续执行start-dfs.sh：
执行jps命令查看启动情况：
其它节点执行:
jps
回到node1节点执行:
hdfs --daemon stop namenode
hdfs namenode -initializeSharedEdits
此时，您可以像通常启动NameNode一样启动所有HA NameNode。
node1执行命令:
hdfs --daemon start namenode
node2、node3执行命令:
hdfs namenode -bootstrapStandby
hdfs --daemon start namenode
您可以通过浏览到配置的HTTP地址，分别访问每个NameNodes的网页。您应该注意到，配置的地址旁边将是NameNode的HA状态（“待机”或“活动”）。每当HA NameNode启动时，它最初处于待机状态。
参考网络文章：
https://www.cnblogs.com/smartloli/p/4298430.html
命令管理
现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。具体来说，您应该熟悉“ hdfs haadmin ”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下用法信息：
用法：haadmin
[-transitionToActive <serviceId>]
[-transitionToStandby <serviceId>]
[-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
[-getServiceState <serviceId>]
[-getAllServiceState]
[-checkHealth <serviceId>]
[-help <command>]
本指南介绍了每个子命令的高级用法。有关每个子命令的特定用法信息，您应该运行“ hdfs haadmin -help <command >”。
transitionToActive和transitionToStandby - 将给定NameNode的状态转换为Active或Standby这些子命令使给定的NameNode分别转换为Active或Standby状态。这些命令不会尝试执行任何防护，因此很少使用。相反，人们几乎总是喜欢使用“ hdfs haadmin -failover ”子命令。
failover - 在两个NameNode之间启动故障转移此子命令导致从第一个提供的NameNode到第二个NameNode的故障转移。如果第一个NameNode处于Standby状态，则此命令只是将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态，将尝试将其正常转换为待机状态。如果失败，将按顺序尝试防护方法（由dfs.ha.fencing.methods配置），直到成功为止。只有在此过程之后，第二个NameNode才会转换为Active状态。如果没有防护方法成功，则第二个NameNode将不会转换为活动状态，并且将返回错误。
getServiceState - 确定给定的NameNode是Active还是Standby连接到提供的NameNode以确定其当前状态，适当地将“待机”或“活动”打印到STDOUT。此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机而表现不同。
getAllServiceState - 返回所有NameNode的状态连接到已配置的NameNodes以确定当前状态，适当地将“待机”或“活动”打印到STDOUT。
checkHealth - 检查给定NameNode的运行状况连接到提供的NameNode以检查其运行状况。NameNode能够对自身执行某些诊断，包括检查内部服务是否按预期运行。如果NameNode是健康的，则此命令将返回0，否则返回非零。可以使用此命令进行监视。注意：这尚未实现，并且除非给定的NameNode完全关闭，否则目前将始终返回成功。
自动故障转移
概述
以上部分介绍了如何配置手动故障转移。在该模式下，即使活动节点发生故障，系统也不会自动触发从活动状态到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。
组件 ZKFC
自动故障转移为HDFS部署添加了两个新组件：ZooKeeper仲裁和ZKFailoverController进程（缩写为ZKFC）。
Apache ZooKeeper是一种高可用性服务，用于维护少量协调数据，通知客户端该数据的更改以及监视客户端是否存在故障。自动HDFS故障转移的实现依赖于ZooKeeper来实现以下功能：
故障检测 - 集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，ZooKeeper会话将过期，通知其他NameNode应该触发故障转移。
Active NameNode选举 - ZooKeeper提供了一种简单的机制，可以将节点专门选为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能在ZooKeeper中采用特殊的独占锁，指示它应该成为下一个活动的。
ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端，它还监视和管理NameNode的状态。运行NameNode的每台机器也运行ZKFC，ZKFC负责：
运行状况监视 - ZKFC定期使用运行状况检查命令对其本地NameNode进行ping操作。只要NameNode及时响应健康状态，ZKFC就认为该节点是健康的。如果节点已崩溃，冻结或以其他方式进入不健康状态，则运行状况监视器会将其标记为运行状况不佳。
ZooKeeper会话管理 - 当本地NameNode运行正常时，ZKFC在ZooKeeper中保持会话打开。如果本地NameNode处于活动状态，它还拥有一个特殊的“锁定”znode。此锁使用ZooKeeper对“短暂”节点的支持; 如果会话过期，将自动删除锁定节点。
基于ZooKeeper的选举 - 如果本地NameNode是健康的，并且ZKFC发现没有其他节点当前持有锁znode，它将自己尝试获取锁。如果成功，那么它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移：首先，必要时对先前的活动进行隔离，然后本地NameNode转换为活动状态。
有关自动故障转移设计的更多详细信息，请参阅Apache HDFS JIRA上附加到HDFS-2185的设计文档。
部署计划
在典型部署中，ZooKeeper守护程序配置为在三个或五个节点上运行。由于ZooKeeper本身具有轻量级资源要求，因此可以在与HDFS NameNode和备用节点相同的硬件上并置ZooKeeper节点。许多运营商选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。建议将ZooKeeper节点配置为将数据存储在与HDFS元数据不同的磁盘驱动器上，以获得最佳性能和隔离。
ZooKeeper的设置超出了本文档的范围。我们假设您已经设置了在三个或更多节点上运行的ZooKeeper集群，并通过使用ZK CLI进行连接来验证其正确的操作。
由于资源有限，我们依旧在现有的3台机子上进行部署Zookeeper，部署结构如下:
hdfs | QJM | ZK | |
node1(Master) | NameNode ZKFC | JournalNode | leader |
node2(Work) | NameNode ZKFC DataNode | JournalNode | follower |
node3(Work) | NameNode ZKFC DataNode | JournalNode | follower |
部署Zookeeper
1、所有节点创建目录
mkdir -p /var/zookeeper/data
mkdir -p /var/zookeeper/logs
2、在其中node1节点上下载解压zookeeper
3、配置ZOO_HOME到/etc/profile
cd $ZOO_HOME/conf/
cp zoo_sample.cfg zoo.cfg
4、vi zoo.cfg内容如下：
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/zookeeper/data
dataLogDir=/var/zookeeper/logs
clientProt=21819
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
5、分发到node2 node3
scp -r root@node1:/opt/soft/zookeeper-3.3.6/ /opt/soft/
scp -r root@node1:/etc/profile /etc/profile
node1执行：
echo "1" > /var/zookeeper/data/myid
source /etc/profile
zkServer.sh start
node2执行：
echo "2" > /var/zookeeper/data/myid
source /etc/profile
zkServer.sh start
node3执行：
echo "3" > /var/zookeeper/data/myid
source /etc/profile
zkServer.sh start
配置
在开始配置自动故障转移之前，应关闭群集。当群集运行时，目前无法从手动故障转移设置转换为自动故障转移设置。
自动故障转移的配置需要在配置中添加两个新参数。在hdfs-site.xml文件中，添加：
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
开启群集以进行自动故障转移
在您的core-site.xml文件中，添加：
<property>
<name>ha.zookeeper.quorum</name>
<value>node1:2181,node2:2181,node3:2181</value>
</property>
列出运行ZooKeeper服务的主机端口对
在您的hadoop-env.sh文件中追加：
HDFS_ZKFC_USER=”root”
将hdfs-site.xml和core-site.xml在需要分发的其它节点(如果像笔者总是在node1进行配置，然后分发到node2,node3)上执行
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/hadoop-env.sh /opt/soft/hadoop-3.1.1/etc/hadoop/hadoop-env.sh
初始化
下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来执行此操作。我们选择在node1节点执行:
hdfs zkfc -formatZK
这将在ZooKeeper中创建一个znode，为自动故障转移系统存储其数据。
启动
由于配置中已启用自动故障转移，因此start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。当ZKFC启动时，它们将自动选择其中一个NameNode变为活动状态。
手动启动zkfs
hdfs --daemon start zkfc
手动停止zkfs
hdfs --daemon stop zkfc
验证故障转移
通过下面三个地址进行测试：
http://node1:9870
http://node2:9870
http://node3:9870
首先找到Active的NameNode所在节点，然后在那个节点上执行: hdfs --daemon stop namenode将其NameNode停止模拟故障，然后我们再看看其它两个节点是否有其它一个状态变为Active。笔者机子测试时node1状态变为Active
我们在node1也执行:hdfs --daemon stop namenode，此时来看看node2状态是否从standby变为active
再刷新一下可以看到变为activie.
然后再启动node1和node3,可以看到node1和node3都是standby,node2为active：
可以看到，NameNode目前确实做到了自动故障转移的能力！
Zookeeper的访问安全性
如果您正在运行安全群集，则可能需要确保ZooKeeper中存储的信息也是安全的。这可以防止恶意客户端修改ZooKeeper中的元数据或可能触发错误的故障转移。
在配置之前，我们可以登录zookeeper，尝试随意访问：
可以看到，没有任何限制，全世界都具有对hadoop-ha节点的cdrwa所有权限；
为了保护ZooKeeper中的信息，首先将以下内容添加到core-site.xml文件中：
<property>
<name>ha.zookeeper.auth</name>
<value>@/opt/etc/zk-auth.txt</value>
</property>
<property>
<name>ha.zookeeper.acl</name>
<value>@/opt/etc/zk-acl.txt</value>
</property>
请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取（请参阅hadoop-common项目中的CredentialProviderAPI指南）。
第一个配置的文件指定ZooKeeper身份验证列表，格式与ZK CLI使用的格式相同。例如，您可以指定以下内容：
digest:hdfs-zkfcs:mypassword
其中hdfs-zkfcs是ZooKeeper的唯一用户名，mypassword是一些用作密码的唯一字符串
接下来，使用如下命令生成与此身份验证对应的ZooKeeper ACL：
java -cp $ZOO_HOME/lib/*:$ZOO_HOME/zookeeper-3.3.6.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
注意：
zookeeper-3.3.6.jar是你所安装zookeeper的具体名称；
$ZOO_HOME是你具体配置的环境变量名称；
hdfs-zkfcs:mypassword是你写入zk-auth.txt去掉digest:前缀后的内容
执行完成后输出：
hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=:cdrwa
其中cdrwa代表具体权限
将此输出的部分复制并粘贴到“ - >”字符串后面的zk-acl.txt文件中，前缀为字符串“ digest： ”。例如：
digest:hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=
最后在所有节点执行如下命令：
mkdir -p /opt/etc
echo digest:hdfs-zkfcs:mypassword > /opt/etc/zk-auth.txt
echo digest:hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs= > /opt/etc/zk-acl.txt
在需要分发的节点执行如下命令：
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/core-site.xml
为了使这些ACL生效，您应该重新运行hdfs zkfc -formatZK命令，执行此操作后，您可以从ZK CLI验证ACL，如下所示：
所有节点执行命令如下：
hdfs --daemon stop zkfc
其中一个节点，笔者这里选择node1执行:
hdfs zkfc -formatZK
中途有询问时输入Y进行确认
所有节点执行命令如下：
hdfs --daemon start zkfc
连接zookeeper:
zkCli.sh -server node1:2181
可以看到限制目录对指定的用户和密码才有cdrwa的权限
HDFS联邦
概述
虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题。
（1） 系统扩展性方面，元数据存储在NN内存中，受内存上限的制约。
（2） 整体性能方面，吞吐量受单个NN的影响。
（3） 隔离性方面，一个程序可能会影响其他运行的程序，如一个程序消耗过多资源导致其他程序无法顺利运行。HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。
在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。
HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。
联邦解决的问题
1、命名空间可伸缩性 - 联合添加命名空间水平扩展。通过允许将更多Namenode添加到群集中，使用大量小文件的大型部署或部署可从命名空间扩展中受益。
2、性能 - 文件系统吞吐量不受单个Namenode的限制。向集群添加更多名称节点可扩展文件系统读/写吞吐量。
3、隔离 - 单个Namenode在多用户环境中不提供隔离。例如，实验应用程序可能会使Namenode过载并减慢生产关键应用程序的速度。通过使用多个Namenode，可以将不同类别的应用程序和用户隔离到不同的名称空间。
联邦一般在大公司内使用，中小企业使用场景相对较少，具体配置和搭建这里不做介绍，有兴趣可以自行查询网络资料进行搭建。
HDFS磁盘平衡器
概述
在HDFS中，DataNode 将数据块存储到本地文件系统目录中，具体的目录可以通过配置 hdfs-site.xml 里面的 dfs.datanode.data.dir 参数。在典型的安装配置中，一般都会配置多个目录，并且把这些目录分别配置到不同的设备上，比如分别配置到不同的HDD(HDD的全称是Hard Disk Drive)和SSD(全称Solid State Drives，就是我们熟悉的固态硬盘)上。
当我们往HDFS上写入新的数据块，DataNode 将会使用volume选择策略来为这个块选择存储的地方。目前Hadoop支持两种volume选择策略：round-robin 和 available space(详情参见：HDFS-1804)，我们可以通过 dfs.datanode.fsdataset.volume.choosing.policy 参数来设置。
循环(round-robin)策略将新块均匀分布在可用磁盘上;而可用空间( available-space )策略优先将数据写入具有最大可用空间的磁盘(通过百分比计算的)。正如下图所示：
默认情况下，DataNode 是使用基于round-robin策略来写入新的数据块。然而在一个长时间运行的集群中，由于HDFS中的大规模文件删除或者通过往DataNode 中添加新的磁盘仍然会导致同一个DataNode中的不同磁盘存储的数据很不均衡。即使你使用的是基于可用空间的策略，卷(volume)不平衡仍可导致较低效率的磁盘I/O。比如所有新增的数据块都会往新增的磁盘上写，在此期间，其他的磁盘会处于空闲状态，这样新的磁盘将会是整个系统的瓶颈。
Diskbalancer是一个命令行工具，可以在datanode的所有磁盘上均匀分配数据。此工具与Balancer不同， 后者负责集群范围的数据平衡。由于多种原因，数据在节点上的磁盘之间可能存在不均匀的扩散。这可能是由于大量写入和删除或由于磁盘更换造成的。此工具针对给定的datanode运行，并将块从一个磁盘移动到另一个磁盘。
准备
让我们通过一个例子逐步探讨这个有用的功能。首先，确保所有DataNode上的 dfs.disk.balancer.enabled 参数设置成true。本例子中，我们的DataNode已经挂载了一个磁盘(/mnt/disk1)，现在我们往这个DataNode上挂载新的磁盘(/mnt/disk2)，我们使用 df命令来显示磁盘的使用率：
df -h
从上面的输出可以看出，两个磁盘的使用率很不均衡，所以我们来将这两个磁盘的数据均衡一下。
开启平衡器
在这之前，先停掉hdfs集群:
stop-dfs.sh
请注意，群集上默认情况下不启用磁盘平衡器。要启用diskbalancer，必须在hdfs-site.xml 中将dfs.disk.balancer.enabled设置为true。
配置好之后分发到其它节点：
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/hdfs-site.xml
启动hdfs集群：
start-dfs.sh
典型的磁盘平衡器任务涉及三个步骤(通过HDFS的diskbalancer 命令)：plan, execute 和 query。第一步，HDFS客户端从NameNode上读取指定DataNode的的必要信息以生成执行计划：
hdfs diskbalancer -plan node2(这里必须是DataNode)
磁盘平衡执行计划生成的文件内容格式是Json的，并且存储在HDFS之上。在默认情况下，这些文件是存储在 /system/diskbalancer 目录下面：
hdfs dfs -ls /system/diskbalancer/xxxxxx (具体路径从控制台输出复制)
可以通过下面的命令在DataNode上执行这个生成的计划：
hdfs diskbalancer -execute /system/diskbalancer/xxxxx (具体路径从控制台输出复制)
这个命令将JSON里面的计划提交给DataNode，而DataNode会启动一个名为BlockMover的线程中执行这个计划。我们可以使用 query 命令来查询DataNode上diskbalancer任务的状态：
hdfs diskbalancer -query node2
上面结果输出的PLAN_DONE表示disk-balancing task已经执行完成。为了验证磁盘平衡器的有效性，我们可以使用df -h 命令来查看各个磁盘的空间使用率：
df -h
HDFS数据备份
概述
HDFS快照是文件系统的只读时间点副本。可以在文件系统的子树或整个文件系统上拍摄快照。快照的一些常见用例是数据备份，防止用户错误和灾难恢复。
HDFS快照的实施非常有效：
快照创建是即时的：成本是O（1），不包括inode查找时间。
仅当相对于快照进行修改时才使用附加内存：内存使用量为O（M），其中M是已修改文件/目录的数量。
不复制datanode中的块：快照文件记录块列表和文件大小。没有数据复制。
快照不会对常规HDFS操作产生负面影响：以反向时间顺序记录修改，以便可以直接访问当前数据。通过从当前数据中减去修改来计算快照数据。
快照目录
一旦将目录设置为snapshottable，就可以在任何目录上拍摄快照。快照目录可以容纳65,536个同步快照。快照目录的数量没有限制。管理员可以将任何目录设置为快照。如果快照目录中有快照，则在删除所有快照之前，既不能删除也不能重命名目录。
目前不允许嵌套的快照目录。换句话说，如果其祖先/后代之一是快照目录，则无法将目录设置为snapshottable。
快照路径
针对一个snapshottable目录，“.snapshot”路径用来指定存放的快照。例如：/foo是一个snapshottable目录，/foo/bar是一个 /foo下的一个文件/目录，并且/foo有一个快照s0，那么路径/foo/.snapshort/s0/bar 指向/foo/bar的快照。
操作命令
参考官方文档
yarn原理
概述
Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。
模块角色介绍
YARN是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）。其中，ResourceManager负责所有资源的监控、分配和管理；ApplicationMaster负责每一个具体应用程序的调度和协调；NodeManager负责每一个节点的维护。对于所有的applications，RM拥有绝对的控制权和对资源的分配权。而每个AM则会和RM协商资源，同时和NodeManager通信来执行和监控task。几个模块之间的关系如图所示。
ResourceManager:负责整个集群的资源管理和分配，是一个全局的资源管理系统。
NodeManager以心跳的方式向ResourceManager汇报资源使用情况（目前主要是CPU和内存的使用情况）。RM只接受NM的资源回报信息，对于具体的资源处理则交给NM自己处理。
YARN Scheduler根据application的请求为其分配资源，不负责application job的监控、追踪、运行状态反馈、启动等工作。
NodeManager是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN集群每个节点都运行一个NodeManager。
NodeManager定时向ResourceManager汇报本节点资源（CPU、内存）的使用情况和Container的运行状态。当ResourceManager宕机时NodeManager自动连接RM备用节点.
NodeManager接收并处理来自ApplicationMaster的Container启动、停止等各种请求。
ApplicationMaster用户提交的每个应用程序均包含一个ApplicationMaster，它可以运行在ResourceManager以外的机器上。负责与RM调度器协商以获取资源（用Container表示）。将得到的任务进一步分配给内部的任务(资源的二次分配)。与NM通信以启动/停止任务。监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。当前YARN自带了两个ApplicationMaster实现，一个是用于演示AM编写方法的实例程序DistributedShell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM—MRAppMaster。
注：RM只负责监控AM，并在AM运行失败时候启动它。RM不负责AM内部任务的容错，任务的容错由AM完成。
运行流程
(1) client向RM提交应用程序，其中包括启动该应用的ApplicationMaster的必须信息，例如ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
(2) ResourceManager启动一个container用于运行ApplicationMaster。
(3) 启动中的ApplicationMaster向ResourceManager注册自己，启动成功后与RM保持心跳。
(4) ApplicationMaster向ResourceManager发送请求，申请相应数目的container。
(5) ResourceManager返回ApplicationMaster的申请的containers信息。申请成功的container，由ApplicationMaster进行初始化。container的启动信息初始化后，AM与对应的NodeManager通信，要求NM启动container。AM与NM保持心跳，从而对NM上运行的任务进行监控和管理。
(6) container运行期间，ApplicationMaster对container进行监控。container通过RPC协议向对应的AM汇报自己的进度和状态等信息。
(7) 应用运行期间，client直接与AM通信获取应用的状态、进度更新等信息。
(8) 应用运行结束后，ApplicationMaster向ResourceManager注销自己，并允许属于它的container被收回。
部署服务器清单
这里再次罗列出现有虚拟化3台机子的配置清单
节点名称 | ip | cpu | 内存 | 磁盘 |
node1 | 192.168.137.101 | 1C | 2G | 10G |
node2 | 192.168.137.102 | 1C | 2G | 10G |
node3 | 192.168.137.103 | 1C | 2G | 10G |
部署计划
在原有的机子上继续添加yarn集群进程，添加后的部署架构如下：
hdfs | ZK | QJM | yarn | |
node1(Master) | NameNode | leader | JournalNode | ResourceManager |
node2(Work) | NameNode DataNode | follower | JournalNode | NodeManager |
node3(Work) | NameNode DataNode | follower | JournalNode | NodeManager |
配置yarn相关文件
hadoop-env.sh
末尾追加:
export YARN_RESOURCEMANAGER_USER="root"
export YARN_NODEMANAGER_USER=”root”
yarn-site.xml
在任意节点（笔者选择node1）修改配置：
<property>
<name>yarn.resourcemanager.hostname</name>
<value>node1</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
MapReduct ON yarn
修改mapre-site.xml
<property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
<property>
<name>mapreduce.application.classpath</name>
<value>$HADOOP_HOME/share/hadoop/mapreduce/*:$HADOOP_HOME/share/hadoop/mapreduce/lib/*</value>
</property>
分发到其它节点
启动yarn
在主节点node1 执行 start-yarn.sh 启动完成后在所有节点执行jps:
node1:
node2:
node3:
ResourceManager高可用性
概述
类似HDFS中的NameNode一样，yarn组件的ResouRceManager角色同样存在单点故障问题，在生产环境中，一般我们需要为ResouRceManager配置高可用从节点。以下是HA架构图：
ResourceManager HA通过主/备架构实现 - 在任何时间点，其中一个RM处于活动状态，并且一个或多个RM处于待机模式，等待活动发生任何事情时接管。转换为活动的触发器来自管理员（通过CLI）或启用自动故障转移时的集成故障转移控制器。
如果未启用自动故障转移，则管理员必须手动将其中一个RM转换为活动。要从一个RM故障转移到另一个RM，它们应首先将Active-RM转换为待机状态，并将Standby-RM转换为Active。所有这些都可以使用“ yarn rmadmin ”CLI完成。
RM可以选择嵌入基于Zookeeper的ActiveStandbyElector来决定哪个RM应该是Active。当Active关闭或无响应时，另一个RM自动被选为Active，然后接管。请注意，不需要像HDFS那样运行单独的ZKFC守护程序，因为嵌入在RM中的ActiveStandbyElector充当故障检测器和领导者选择器而不是单独的ZKFC守护程序。
部署计划
在原有的机子上继续添加yarn resourceManager HA高可用节点，在node2部署一个备用ResourceManager，高可用zk集群使用现有的部署集群，添加后的部署架构如下：
hdfs | ZK | QJM | yarn | |
node1(Master) | NameNode ZKFC | leader | JournalNode | ResourceManager |
node2(Work) | NameNode DataNode ZKFC | follower | JournalNode | NodeManager ResourceManager |
node3(Work) | NameNode DataNode ZKFC | follower | JournalNode | NodeManager |
配置yarn-site.xml
现yarn-site.xml完整配置信息如下：
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
<property>
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
</property>
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>cluster1</value>
</property>
<property>
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm1</name>
<value>node1</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm2</name>
<value>node2</value>
</property>
<property>
<name>yarn.resourcemanager.webapp.address.rm1</name>
<value>node1:8088</value>
</property>
<property>
<name>yarn.resourcemanager.webapp.address.rm2</name>
<value>node2:8088</value>
</property>
<property>
<name>yarn.resourcemanager.zk-address</name>
<value>node1:2181,node2:2181,node3:2181</value>
</property>
分发到其它两个节点,在需要分发的节点上执行命令：
scp -r root@node1:/opt/soft/hadoop-3.1.1/etc/hadoop/yarn-site.xml /opt/soft/hadoop-3.1.1/etc/hadoop/yarn-site.xml
重启yarn, 在node1节点上执行:
stop-yarn.sh
start-yarn.sh
在所有节点执行： jps
node1:
node2:
node3:
web访问yarn集群
http://node1:8088
如果继续访问node2：http://node2:8088 ，注意url地址会自动跳转到active节点上：http://node1:8088
管理员命令：
yarn rmadmin有一些特定于HA的命令选项，用于检查RM的运行状况和状态，并转换为Active / Standby。HA的命令将yarn.resourcemanager.ha.rm-ids设置的RM的服务id 作为参数。
yarn rmadmin -getServiceState rm1
输出结果：active
yarn rmadmin -getServiceState rm2
输出结果：standby
警告
如果启用了自动故障转移，则无法使用手动转换命令。虽然您可以通过-forcemanual标志覆盖它，但您需要谨慎。
yarn rmadmin -transitionToStandby rm1
提交mapreduce作业
在任意节点上执行下面命令即可：
hadoop jar xxxxx.jar 主类全路径
至此，整个hdfs分布式部署讲解完毕！
附录A
真实生产环境部署建议
由于集器资源有限，笔者在该文档中使用的虚拟机配置极低，不适合生产使用，如果需要在真实生产环境部署分布式hdfs 和mapreduce yarn资源管理器，需要加大节点资源配置，比如每个节点资源为：
CPU（核数） | 内存 | 磁盘（SSD） | 节点数量 | 类型 |
4 | 8 | 500G | 6 | 小型/初期数据量 |
8 | 16 | 500G | 按数据量计算 | 中大型/后期数据量 |
除此之外，还需要添加节点数量，这里建议开始部署的节点数量是6台，部署计划如下：
server | hdfs | ZK | QJM | yarn |
node1 | NameNode ZKFC | follower | JournalNode | ResourceManager |
node2 | NameNode ZKFC | follower | JournalNode | |
node3 | leader | JournalNode | ResourceManager | |
node4 | DataNode | NodeManager
| ||
node5 | DataNode | NodeManager
| ||
node6 | DataNode | NodeManager | ||
... |
随着数据量增大，通常对DataNode经常节点扩展。对于DataNode集群扩展技术可以参考hadoop官方文档相关内容。
116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
