复制下面内容到hosts文件

一路回车即可创建ssh公私钥，创建ssh公私钥匙后通过执行下面命令配置免密：

jdk8下载和安装不演示，这里主要给出规划的目录：

自行下载，这里注意版本号为：3.1.1，下载到/opt/zip 解压到/opt/soft， 配置环境变量

由于集群环境节点比较多，配置需要方法，这里思路是先配置好一个节点，然后使用scp命令分发到其它节点，下面是分别对不同的配置文件进行配置说明：

注意：官方推荐hdfs，yarm，分别创建用户,这里简单起见，直接统一使用root用户，生产环境建议按官方推荐方式配置。

在需要分发的节点上执行:

用jps命令检查目前节点是否有java进程，如果有请先停掉，然后在master（node1）节点执行启动脚本：

更多命令可以查看官网：

在典型的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群集，您应准备以下内容：

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的高可用部署，具体部署如下：

在现有部署结构上增加Quorum Journal Manager相关角色进来之后的部署如下：

要配置HA NameNode，必须向hdfs-site.xml配置文件添加多个配置选项。首先配置集群名称

上面设置的这些配置的顺序并不重要，但您为dfs.nameservices和dfs.ha.namenodes。[nameservice ID]选择的值将确定后面的那些键。因此，在设置其余配置选项之前，您应该决定这些值。

HA的NameNode最小数量为2，但您可以配置更多。由于通信开销，建议不要超过5 - 推荐3个NameNodes。

下面对于两个先前配置的NameNode ID，设置NameNode进程的完整地址和IPC端口

例如，如果此群集的JournalNodes在计算机“node1”，“node2”和“node3”上运行，并且名称服务ID是“mycluster”，则您将使用以下为此设置的值（JournalNode的默认端口为8485）：

存储JN使用的编辑和其他本地状态

配置Java类的名称，DFS客户端将使用该名称来确定哪个NameNode是当前的Active，以及哪个NameNode当前正在为客户端请求提供服务。目前Hadoop附带的两个实现是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（对于第一次调用，它同时调用所有名称节点以确定活动的名称，并在后续请求中调用活动的名称节点直到发生故障转移），所以除非您使用自定义代理提供程序，否则请使用其中一个。

对于系统的正确性，期望在任何给定时间只有一个NameNode处于活动状态。重要的是，在使用Quorum Journal Manager时，只允许一个NameNode写入JournalNodes，因此不存在从裂脑情况中破坏文件系统元数据的可能性。但是，当发生故障转移时，以前的Active NameNode仍可能向客户端提供读取请求，这可能已过期，直到NameNode在尝试写入JournalNode时关闭。因此，即使使用Quorum Journal Manager，仍然需要配置一些防护方法。但是，为了在防护机制失败的情况下提高系统的可用性，建议配置防护方法，该方法可保证作为列表中的最后一个防护方法返回成功

如果shell命令返回退出代码0，则确定防护成功。如果它返回任何其他退出代码，则防护不成功，将尝试列表中的下一个防护方法。所以为了加强防护能力，可以适当多配置几个选项， 如：

配置Hadoop客户端的默认路径以使用新的启用HA的逻辑URI

配置完成后新的core-site.xml文件内容如下：

在设置了所有必需的配置选项后，必须在将运行它们的一组计算机上启动JournalNode守护程序。这可以通过运行命令“ hdfs --daemon start journalnode ”并等待守护进程在每个相关机器上启动来完成。

如果您已经格式化了NameNode，或者正在将启用了HA的群集转换为启用HA，则现在应该通过运行命令将NameNode元数据目录的内容复制到其他未格式化的NameNode上。hdfs namenode

在主节点node1执行：

执行jps命令查看启动情况：

您可以通过浏览到配置的HTTP地址，分别访问每个NameNodes的网页。您应该注意到，配置的地址旁边将是NameNode的HA状态（“待机”或“活动”）。每当HA NameNode启动时，它最初处于待机状态。

现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。具体来说，您应该熟悉“ hdfs haadmin ”命令的所有子命令。在没有任何其他参数的情况下运行此命令将显示以下用法信息：

• 在两个NameNode之间启动故障转移此子命令导致从第一个提供的NameNode到第二个NameNode的故障转移。如果第一个NameNode处于Standby状态，则此命令只是将第二个NameNode转换为Active状态而不会出现错误。如果第一个NameNode处于活动状态，将尝试将其正常转换为待机状态。如果失败，将按顺序尝试防护方法（由dfs.ha.fencing.methods配置），直到成功为止。只有在此过程之后，第二个NameNode才会转换为Active状态。如果没有防护方法成功，则第二个NameNode将不会转换为活动状态，并且将返回错误。

• getServiceState - 确定给定的NameNode是Active还是Standby连接到提供的NameNode以确定其当前状态，适当地将“待机”或“活动”打印到STDOUT。此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机而表现不同。

• checkHealth - 检查给定NameNode的运行状况连接到提供的NameNode以检查其运行状况。NameNode能够对自身执行某些诊断，包括检查内部服务是否按预期运行。如果NameNode是健康的，则此命令将返回0，否则返回非零。可以使用此命令进行监视。注意：这尚未实现，并且除非给定的NameNode完全关闭，否则目前将始终返回成功。

以上部分介绍了如何配置手动故障转移。在该模式下，即使活动节点发生故障，系统也不会自动触发从活动状态到备用NameNode的故障转移。本节介绍如何配置和部署自动故障转移。

Apache ZooKeeper是一种高可用性服务，用于维护少量协调数据，通知客户端该数据的更改以及监视客户端是否存在故障。自动HDFS故障转移的实现依赖于ZooKeeper来实现以下功能：

故障检测 - 集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，ZooKeeper会话将过期，通知其他NameNode应该触发故障转移。

Active NameNode选举 - ZooKeeper提供了一种简单的机制，可以将节点专门选为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能在ZooKeeper中采用特殊的独占锁，指示它应该成为下一个活动的。

运行状况监视 - 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-site.xml文件中，添加：

开启群集以进行自动故障转移

列出运行ZooKeeper服务的主机端口对

下一步是在ZooKeeper中初始化所需的状态。您可以通过从其中一个NameNode主机运行以下命令来执行此操作。我们选择在node1节点执行:

这将在ZooKeeper中创建一个znode，为自动故障转移系统存储其数据。

由于配置中已启用自动故障转移，因此start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。当ZKFC启动时，它们将自动选择其中一个NameNode变为活动状态。

通过下面三个地址进行测试：

再刷新一下可以看到变为activie.

可以看到，NameNode目前确实做到了自动故障转移的能力！

如果您正在运行安全群集，则可能需要确保ZooKeeper中存储的信息也是安全的。这可以防止恶意客户端修改ZooKeeper中的元数据或可能触发错误的故障转移。

在配置之前，我们可以登录zookeeper，尝试随意访问：

可以看到，没有任何限制，全世界都具有对hadoop-ha节点的cdrwa所有权限；

为了保护ZooKeeper中的信息，首先将以下内容添加到core-site.xml文件中：

请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。身份验证信息也可以通过CredentialProvider读取（请参阅hadoop-common项目中的CredentialProviderAPI指南）。

第一个配置的文件指定ZooKeeper身份验证列表，格式与ZK CLI使用的格式相同。例如，您可以指定以下内容：

接下来，使用如下命令生成与此身份验证对应的ZooKeeper ACL：

$ZOO_HOME是你具体配置的环境变量名称；

其中cdrwa代表具体权限

将此输出的部分复制并粘贴到“ - >”字符串后面的zk-acl.txt文件中，前缀为字符串“ digest： ”。例如：

最后在所有节点执行如下命令：

在需要分发的节点执行如下命令：

为了使这些ACL生效，您应该重新运行hdfs zkfc -formatZK命令，执行此操作后，您可以从ZK CLI验证ACL，如下所示：

所有节点执行命令如下：

其中一个节点，笔者这里选择node1执行:

中途有询问时输入Y进行确认

所有节点执行命令如下：

可以看到限制目录对指定的用户和密码才有cdrwa的权限

虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题。

（1）   系统扩展性方面，元数据存储在NN内存中，受内存上限的制约。

（3）   隔离性方面，一个程序可能会影响其他运行的程序，如一个程序消耗过多资源导致其他程序无法顺利运行。HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。

在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。

HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。

1、命名空间可伸缩性 - 联合添加命名空间水平扩展。通过允许将更多Namenode添加到群集中，使用大量小文件的大型部署或部署可从命名空间扩展中受益。

2、性能 - 文件系统吞吐量不受单个Namenode的限制。向集群添加更多名称节点可扩展文件系统读/写吞吐量。

3、隔离 - 单个Namenode在多用户环境中不提供隔离。例如，实验应用程序可能会使Namenode过载并减慢生产关键应用程序的速度。通过使用多个Namenode，可以将不同类别的应用程序和用户隔离到不同的名称空间。

联邦一般在大公司内使用，中小企业使用场景相对较少，具体配置和搭建这里不做介绍，有兴趣可以自行查询网络资料进行搭建。

在HDFS中，DataNode 将数据块存储到本地文件系统目录中，具体的目录可以通过配置 hdfs-site.xml 里面的 dfs.datanode.data.dir 参数。在典型的安装配置中，一般都会配置多个目录，并且把这些目录分别配置到不同的设备上，比如分别配置到不同的HDD(HDD的全称是Hard Disk Drive)和SSD(全称Solid State Drives，就是我们熟悉的固态硬盘)上。

循环(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命令来显示磁盘的使用率：

从上面的输出可以看出，两个磁盘的使用率很不均衡，所以我们来将这两个磁盘的数据均衡一下。

在这之前，先停掉hdfs集群:

配置好之后分发到其它节点：

磁盘平衡执行计划生成的文件内容格式是Json的，并且存储在HDFS之上。在默认情况下，这些文件是存储在 /system/diskbalancer 目录下面：

可以通过下面的命令在DataNode上执行这个生成的计划：

上面结果输出的PLAN_DONE表示disk-balancing task已经执行完成。为了验证磁盘平衡器的有效性，我们可以使用df -h 命令来查看各个磁盘的空间使用率：

HDFS快照是文件系统的只读时间点副本。可以在文件系统的子树或整个文件系统上拍摄快照。快照的一些常见用例是数据备份，防止用户错误和灾难恢复。

HDFS快照的实施非常有效：

快照创建是即时的：成本是O（1），不包括inode查找时间。

仅当相对于快照进行修改时才使用附加内存：内存使用量为O（M），其中M是已修改文件/目录的数量。

不复制datanode中的块：快照文件记录块列表和文件大小。没有数据复制。

快照不会对常规HDFS操作产生负面影响：以反向时间顺序记录修改，以便可以直接访问当前数据。通过从当前数据中减去修改来计算快照数据。

一旦将目录设置为snapshottable，就可以在任何目录上拍摄快照。快照目录可以容纳65,536个同步快照。快照目录的数量没有限制。管理员可以将任何目录设置为快照。如果快照目录中有快照，则在删除所有快照之前，既不能删除也不能重命名目录。

目前不允许嵌套的快照目录。换句话说，如果其祖先/后代之一是快照目录，则无法将目录设置为snapshottable。

 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自己处理。

• NodeManager是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN集群每个节点都运行一个NodeManager。

• ApplicationMaster用户提交的每个应用程序均包含一个ApplicationMaster，它可以运行在ResourceManager以外的机器上。负责与RM调度器协商以获取资源（用Container表示）。将得到的任务进一步分配给内部的任务(资源的二次分配)。与NM通信以启动/停止任务。监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。当前YARN自带了两个ApplicationMaster实现，一个是用于演示AM编写方法的实例程序DistributedShell，它可以申请一定数目的Container以并行运行一个Shell命令或者Shell脚本；另一个是运行MapReduce应用程序的AM—MRAppMaster。

注：RM只负责监控AM，并在AM运行失败时候启动它。RM不负责AM内部任务的容错，任务的容错由AM完成。

(7) 应用运行期间，client直接与AM通信获取应用的状态、进度更新等信息。

这里再次罗列出现有虚拟化3台机子的配置清单

在原有的机子上继续添加yarn集群进程，添加后的部署架构如下：

在任意节点（笔者选择node1）修改配置：

类似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集群使用现有的部署集群，添加后的部署架构如下：

分发到其它两个节点,在需要分发的节点上执行命令：

在所有节点执行： jps

如果启用了自动故障转移，则无法使用手动转换命令。虽然您可以通过-forcemanual标志覆盖它，但您需要谨慎。

在任意节点上执行下面命令即可：

至此，整个hdfs分布式部署讲解完毕！

由于集器资源有限，笔者在该文档中使用的虚拟机配置极低，不适合生产使用，如果需要在真实生产环境部署分布式hdfs 和mapreduce  yarn资源管理器，需要加大节点资源配置，比如每个节点资源为：

   除此之外，还需要添加节点数量，这里建议开始部署的节点数量是6台，部署计划如下：

  随着数据量增大，通常对DataNode经常节点扩展。对于DataNode集群扩展技术可以参考hadoop官方文档相关内容。