大数据最佳实践-hdfs

写流程

1. Client 调用 DistributedFileSystem 对象的 create 方法，创建一个文件输出流（FSDataOutputStream）对象；
2. 通过 DistributedFileSystem 对象与集群的 NameNode 进行一次 RPC 远程调用，在 HDFS 的 Namespace 中创建一个文件条目（Entry），此时该条目没有任何的 Block，NameNode 会返回该数据每个块需要拷贝的 DataNode 地址信息；
3. 通过 FSDataOutputStream 对象，开始向 DataNode 写入数据，数据首先被写入 FSDataOutputStream 对象内部的数据队列中，数据队列由 DataStreamer 使用，它通过选择合适的 DataNode 列表来存储副本，从而要求 NameNode 分配新的 block；
4. DataStreamer 将数据包以流式传输的方式传输到分配的第一个 DataNode 中，该数据流将数据包存储到第一个 DataNode 中并将其转发到第二个 DataNode 中，接着第二个 DataNode 节点会将数据包转发到第三个 DataNode 节点；
5. DataNode 确认数据传输完成，最后由第一个 DataNode 通知 client 数据写入成功；
6. 完成向文件写入数据，Client 在文件输出流（FSDataOutputStream）对象上调用 close 方法，完成文件写入；
7. 调用 DistributedFileSystem 对象的 complete 方法，通知 NameNode 文件写入成功，NameNode 会将相关结果记录到 editlog 中。

hdfs创建一个文件的流程

1. 客户端通过ClientProtocol协议向RpcServer发起创建文件的RPC请求。
2. FSNamesystem封装了各种HDFS操作的实现细节，RpcServer调用FSNamesystem中的相关方法以创建目录。
3. 进一步的，FSDirectory封装了各种目录树操作的实现细节，FSNamesystem调用FSDirectory中的相关方法在目录树中创建目标文件，并通过日志系统备份文件系统的修改。
4. 最后，RpcServer将RPC响应返回给客户端。

读流程

1. Client 通过 DistributedFileSystem 对象与集群的 NameNode 进行一次 RPC 远程调用，获取文件 block 位置信息；
2. NameNode 返回存储的每个块的 DataNode 列表；
3. Client 将连接到列表中最近的 DataNode；
4. Client 开始从 DataNode 并行读取数据；
5. 一旦 Client 获得了所有必须的 block，它就会将这些 block 组合起来形成一个文件。

小文件解决

Hadoop Archive
Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。

Sequence file
sequence file由一系列的二进制key/value组成，如果为key小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

CombineFileInputFormat
它是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

提升写性能

dfs.datanode.drop.cache.behind.reads
设置为true表示丢弃缓存的数据（需要在DataNode中配置）。
当同一份数据，重复读取的次数较少时，建议设置为true，使得缓存能够被其他操作使用。重复读取的次数较多时，设置为false能够提升重复读取的速度。

dfs.client-write-packet-size
当HDFS Client往DataNode写数据时，将数据生成一个包。然后将这个包在网络上传出。此参数指定传输数据包的大小，可以通过各Job来指定。单位：字节。
在万兆网部署下，可适当增大该参数值，来提升传输的吞吐量。

使用客户端元数据缓存提高读取性能
通过使用客户端缓存元数据块的位置来提高HDFS读取性能。
此功能仅用于读取不经常修改的文件。因为在服务器端由某些其他客户端完成的数据修改，对于高速缓存的客户端将是不可见的，这可能导致从缓存中拿到的元数据是过期的。

dfs.client.metadata.cache.enabled
启用/禁用块位置元数据的客户端缓存。将此参数设置为“true”，搭配“dfs.client.metadata.cache.pattern”参数以启用缓存。

dfs.client.metadata.cache.pattern
需要缓存的文件路径的正则表达式模式。只有这些文件的块位置元数据被缓存，直到这些元数据过期。此配置仅在参数“dfs.client.metadata.cache.enabled”设置为“true”时有效。
示例：“/test.*”表示读取其路径是以“/test”开头的所有文件。
为确保一致性，配置特定模式以仅缓存其他客户端不经常修改的文件。
正则表达式模式将仅验证URI的path部分，而不验证在Fully Qualified路径情况下的schema和authority。

dfs.client.metadata.cache.expiry.sec
缓存元数据的持续时间。缓存条目在该持续时间过期后失效。即使在缓存过程中经常使用的元数据也会发生失效。
配置值可采用时间后缀s/m/h表示，分别表示秒，分钟和小时。
若将该参数配置为“0s”，将禁用缓存功能。

dfs.client.metadata.cache.max.entries
缓存一次最多可保存的非过期数据条目。
要在过期前完全清除客户端缓存，可调用DFSClient#clearLocatedBlockCache()。
用法如下所示。

    FileSystem fs = FileSystem.get(conf);
    DistributedFileSystem dfs = (DistributedFileSystem) fs;
    DFSClient dfsClient = dfs.getClient();
dfsClient.clearLocatedBlockCache();

使用当前活动缓存提升客户端与NameNode的连接性能

HDFS部署在具有多个NameNode实例的HA（High Availability）模式中，HDFS客户端需要依次连接到每个NameNode，以确定当前活动的NameNode是什么，并将其用于客户端操作。

一旦识别出来，当前活动的NameNode的详细信息就可以被缓存并共享给在客户端机器中运行的所有客户端。这样，每个新客户端可以首先尝试从缓存加载活动的Name Node的详细信息，并将RPC调用保存到备用的NameNode。在异常情况下有很多优势，例如当备用的NameNode连接长时间不响应时。

当发生故障，将另一个NameNode切换为活动状态时，缓存的详细信息将被更新为当前活动的NameNode的信息。

dfs.client.failover.proxy.provider.[nameservice ID]
配置客户端Failover proxy provider类，该类使用传递的协议创建NameNode proxy。该参数可以被配置为“org.apache.hadoop.hdfs.server.namenode.ha.BlackListingFailoverProxyProvider”或者“org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider”。
org.apache.hadoop.hdfs.server.namenode.ha.AdaptiveFailoverProxyProvider

dfs.client.failover.activeinfo.share.flag
启用缓存并将当前活动的NameNode的详细信息共享给其他客户端。若要启用缓存，需将其设置为“true”。

dfs.client.failover.activeinfo.share.path
指定将在机器中的所有客户端创建的共享文件的本地目录。如果要为不同用户共享缓存，该文件夹应具有必需的权限（如在给定目录中创建，读写缓存文件）。

dfs.client.failover.activeinfo.share.io.timeout.sec
控制超时的可选配置。用于在读取或写入缓存文件时获取锁定。如果在该时间内无法获取缓存文件上的锁定，则放弃尝试读取或更新缓存。单位为秒。
由HDFS客户端创建的缓存文件必须由其他客户端重新使用。因此，这些文件永远不会从本地系统中删除。若禁用该功能，可能需要进行手动清理。

HA实现

在标准配置中，NameNode 是HDFS集群中的单点故障（SPOF）。每个群集都有一个NameNode ，如果该主机或进程不可用，则整个群集都不可用，直到重新启动该NameNode 或在新主机上启动该NameNode 。辅助NameNode 不提供故障转移功能。

标准配置通过两种主要方式降低HDFS集群的总可用性：
在发生意外事件（如主机崩溃）的情况下，群集不可用，直到操作员重新启动NameNode 。
计划内的维护事件（如NameNode 计算机上的软件或硬件升级）会导致集群停机。
HDFSHA通过在主动/被动配置中提供在同一集群中运行两个NameNode 的选项来解决上述问题。它们被称为活动NameNode 和备用NameNode 。与辅助NameNode 不同，备用NameNode 是热备份的，允许在主机崩溃的情况下快速自动故障转移到新的NameNode ，或允许优雅的管理员为计划维护而启动的故障转移。NameNode 不能超过两个。

Cloudera Manager和CDH支持基于 Quorum的存储来实现HA。

Quorum-based Storage
Quorum-based Storage是指使用仲裁日志管理器（QJM）的HA实现。
为了使备用NameNode 的状态与此实现中的活动NameNode 保持同步，两个节点都与一组称为journalNodes的独立守护进程通信。当任何名称空间修改由活动的NameNode 执行时，它会将修改的记录持久地记录到大多数日志节点中。备用NameNode 能够从日志代码中读取编辑内容，并不断观察编辑日志的更改。当备用节点看到编辑时，它将它们应用到自己的名称空间。在故障转移的情况下，备用服务器确保在将自己提升到活动状态之前已从日志代码读取所有编辑。这样可以确保在发生故障转移之前完全同步命名空间状态。

为了提供快速的故障转移，还需要备用NameNode 提供有关集群中块位置的最新信息。为了实现这一点，数据节点配置了两个NameNode 的位置，它们向两个NameNode 发送块位置信息和心跳信号。

一次只有一个NameNode 处于活动状态对于HA集群的正确操作至关重要。否则，名称空间状态将很快在这两者之间发生分歧，从而可能导致数据丢失或其他不正确的结果。为了确保这个属性并防止所谓的“分裂大脑场景”，JournalNodes一次只允许一个NameNode 作为编写者。在故障转移过程中，要变为活动状态的NameNode 仅接管写入日志节点的角色，这有效地阻止了其他NameNode 继续处于活动状态，从而允许新的活动NameNode 安全地继续进行故障转移。
因此，不需要设置围栏，但它仍然有用
自动故障转移
自动故障转移依赖于HDF中的两个附加组件：ZooKeeper quorum和zkFailoverController进程（缩写为zkfc）。在ClouderaManager中，zkfc进程映射到hdfs故障转移控制器角色。

ApacheZooKeeper是一种高度可用的服务，用于维护少量的协调数据，通知客户机该数据的更改，以及监控客户机的故障。HDFS自动故障转移的实现依赖于ZooKeeper执行以下功能：

故障检测-集群中的每个NameNode 机器在ZooKeeper中维护一个持久会话。如果机器崩溃，ZooKeeper会话将过期，通知另一个NameNode 应该触发故障转移。
主动NameNode 选择-ZooKeeper提供了一种简单的机制，专门选择一个节点作为主动节点。如果当前活动的NameNode 崩溃，另一个节点可以在ZooKeeper中获得一个特殊的独占锁，指示它应该成为下一个活动的NameNode 。
zkfailovercontroller（zkfc）是一个ZooKeeper客户机，它还监视和管理NameNode 的状态。运行NameNode 的每个主机也运行一个zkfc。ZKFC负责：

运行状况监视-zkfc使用运行状况检查命令定期与本地NameNode 联系。只要namenode以健康状态迅速响应，zkfc就认为namenode健康。如果NameNode 崩溃、冻结或以其他方式进入不正常状态，则运行状况监视器将其标记为不正常。
ZooKeeper会话管理-当本地NameNode 正常时，zkfc在ZooKeeper中保持会话打开。如果本地NameNode 处于活动状态，它还拥有一个特殊的锁znode。该锁使用ZooKeeper对“临时”节点的支持；如果会话过期，则会自动删除该锁节点。
基于ZooKeeper的选择-如果本地NameNode 是健康的，并且zkfc发现当前没有其他NameNode 持有锁znode，那么它将自己尝试获取该锁。如果成功，那么它将“赢得选举”，并负责运行故障转移以使其本地NameNode 处于活动状态。故障转移过程类似于上面描述的手动故障转移：首先，如果需要，将前一个活动节点隔离，然后本地NameNode 转换为活动状态。

如何启用HDFS HA
硬件配置
要使用Quorum-based Storage部署HA群集，应准备以下内容：

NameNode 主机-这些是运行活动和备用NameNode 的主机。它们应该具有相互等效的硬件，以及与非HA集群中使用的硬件相同的硬件。

JournalNode主机-这些是运行JournalNodes的主机。Cloudera建议您将journalNode守护进程部署在“master”主机（namenode、standby namenode、jobtracker等）上，以便journalNodes的本地目录可以使用这些计算机上可靠的本地存储。

如果位于同一主机上，则每个journalNode进程和每个namenode进程都应该有自己的专用磁盘。对于这些目录，不应使用SAN或NAS存储。

必须至少有三个journalnode守护程序，因为编辑日志修改必须写入大多数journalnode。这将允许系统容忍单个主机的故障。您还可以运行三个以上的日志代码，但要实际增加系统能够容忍的失败次数，您应该运行奇数个日志代码（三个、五个、七个等）。请注意，当使用n个日志代码运行时，系统最多可以容忍（n-1）/2个故障，并继续正常运行。如果所需的仲裁不可用，则namenode将不会格式化或启动，并且您将看到与此类似的错误：
12/10/01 17:34:18 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping.
java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

在HA集群中，备用NameNode 还执行命名空间状态的检查点，因此不需要在HA集群中运行辅助NameNode 、检查点节点或备份节点。事实上，这样做是一个错误。如果要将未启用HA的HDFS群集重新配置为启用HA，则可以重用以前专用于辅助NameNode 的硬件。
启用HA

HDFS高可用性（HA）集群使用两个NameNode ：活动NameNode 和备用NameNode 。任何时间点只能有一个NameNode 处于活动状态。hdfs-ha依赖于在两个NameNode 都可用的位置维护所有名称空间修改的日志，以便在发生故障时，备用NameNode 具有有关编辑和集群中块位置的最新信息。
注意：启用和禁用HA会导致HDFS服务和所有依赖HDFS的服务中断。在启用或禁用HA之前，请确保集群上没有运行任何作业。

您可以使用ClouderaManager为HDFS HA和自动故障转移配置CDH集群。在Cloudera Manager中，HA是使用Quorum-based storage 来实现的。Quorum-based storage 依赖于一组日志代码，每个日志代码维护一个本地编辑目录，记录对命名空间元数据的修改。启用HA将启用自动故障转移作为同一命令的一部分。

注意:

启用或禁用HA会导致以前的监视历史变得不可用。
启用JobTracker HA后，一些参数将自动设置如下。如果要更改这些参数的默认值，请使用高级配置片段。
mapred.jobtracker.restart.recover: true
mapred.job.tracker.persist.jobstatus.active: true
mapred.ha.automatic-failover.enabled: true
mapred.ha.fencing.methods: shell(true)

“启用高可用性”工作流将引导您添加第二个（备用）NameNode 并配置JournalNodes。

1、执行“为HDFS HA配置硬件”中描述的所有配置和设置任务。
2、确保你有ZK服务。
3、转到HDFS服务。
选择操作>启用高可用性。显示有资格运行备用NameNode 的主机和日志代码的屏幕。
指定名称服务的名称，然后单击“继续”。
注意：为名称服务使用唯一的名称。
4、在“NameNode 主机”字段中，单击“选择主机”。将显示“主机选择”对话框。
选中要在其中设置备用NameNode 的主机旁边的复选框，然后单击“确定”。备用NameNode 不能与活动NameNode 位于同一主机上，并且所选主机应具有与活动NameNode 相同的硬件配置（RAM、磁盘空间、核心数等）。
5、在JournalNode主机字段中，单击选择主机。将显示“主机选择”对话框。
选中奇数个主机（至少三个）旁边的复选框以用作日志代码，然后单击“确定”。JournalNodes应托管在具有与NameNode 类似的硬件规范的主机上。Cloudera建议您将JournalNode分别放在与活动和备用NameNode 相同的主机上，并将第三个JournalNode放在类似的硬件上，如JobTracker。
6、单击继续。
7、在journalnode edits directory属性中，将journalnode edits目录的目录位置输入到每个journalnode主机的字段中。
每个日志代码只能输入一个目录。每个journalNode上的路径不需要相同。
指定的目录应为空。
目录所有者应该是hdfs:hadoop，并且必须具有读、写和执行权限drwx------

额外选项：决定ClouderaManager是否应清除ZooKeeper、备用NameNode 和日志代码中的现有数据。如果目录不是空的（例如，您正在启用以前的HA配置），则Cloudera Manager不会自动删除您可以通过保留默认复选框选择来删除内容的内容。建议的默认设置是清除目录。如果选择不这样做，则数据应在日记节点的编辑目录之间保持同步，并且应具有与NameNode 相同的版本数据。

8、点击继续
Cloudera Manager执行一组命令，这些命令停止依赖服务、根据需要删除、创建和配置角色和目录、创建名称服务和故障转移控制器、重新启动依赖服务以及部署新的客户端配置。

重要提示：如果操作已完成，某些步骤（如格式化NameNode ）可能会报告失败。但是，在报告非关键失败步骤之后，配置步骤将继续执行。
如果要在配置了HA的集群中使用其他服务，请按照配置其他CDH组件以使用HDFS HA中的过程操作。
https://www.cloudera.com/documentation/enterprise/6/6.1/topics/cdh_hag_hdfs_ha_cdh_components_config.html#topic_2_6

注意：
如果在启用自动故障转移时更改NameNode 服务RPC端口（df.namenode.service rpc地址），这将导致zookeeper/hadoop ha znode中保存的NameNode 地址与故障转移控制器配置的NameNode 地址不匹配。这将阻止故障转移控制器重新启动。如果启用自动故障转移后需要更改NameNode 服务RPC端口，则必须执行以下操作以重新初始化znode：

1、Stop the HDFS service.
2、Configure the service RPC port:
Go to the HDFS service.
Click the Configuration tab.
Select Scope > NameNode.
Select Category > Ports and Addresses.
Locate the NameNode Service RPC Port property or search for it by typing its name in the Search box.
3、Change the port value as needed.
To apply this configuration property to other role groups as needed, edit the value for the appropriate role group. See Modifying Configuration Properties Using Cloudera Manager.
https://www.cloudera.com/documentation/enterprise/6/6.1/topics/cm_mc_mod_configs.html#cmug_topic_5_3

4、On a ZooKeeper server host, run zookeeper-client.
Execute the following to remove the configured nameservice. This example assumes the name of the nameservice is nameservice1. You can identify the nameservice from the Federation and High Availability section on the HDFS Instances tab:
rmr /hadoop-ha/nameservice1
5、Click the Instances tab.
6、Select Actions > Initialize High Availability State in ZooKeeper.
7、Start the HDFS service.

Fencing Methods

为了确保一次只有一个NameNode 处于活动状态，共享编辑目录需要一个Fencing Methods
。在故障转移期间，Fencing Methods负责确保前一个活动NameNode 不再具有对共享编辑目录的访问权，以便新的活动NameNode 可以安全地继续向其写入内容。

Fencing Configuration
dfs.ha.fencing.methods
一个脚本或Java类的列表，用于在故障转移期间屏蔽活动的NAMENODE

对于系统的正确性来说，在任何给定的时间内，只有一个NameNode 处于活动状态是可取的。

当您使用Quorum-based Storage时，将永远只允许一个NameNode 写入日志节点，因此在“分裂大脑”场景中不存在损坏文件系统元数据的可能性。这反映在dfs.ha.fence.methods的shell（true）的默认值中，该值不会明确尝试对备用NameNode 进行隔离。

在没有明确划分的情况下，存在一个很窄的时间窗口，以前活动的NameNode 可能提供过期的响应，以供从客户机读取数据。当先前活动的NameNode 尝试写入日志节点时，此窗口将结束，此时NameNode 将关闭。

对于应用程序来说，这种陈旧的读取响应窗口很少是一个问题，因为不存在分裂大脑损坏的危险。在需要强读一致性的罕见或特殊情况下，使用一种显式的击剑方法，如基于代理的击剑手。

注意：如果选择使用基于代理的Fencing Methods，则仍应将shell（true）配置为回退围栏选项，因为如果另一个NameNode 没有响应，则基于代理的围栏将失败。
故障转移期间使用的Fencing Methods被配置为一个回车分隔列表，并且将依次尝试这些方法，直到其中一个方法指示围栏已成功。

有关实现自己的自定义Fencing Methods的信息，请参见org.apache.hadoop.ha.nodefencer类。

Configuring the shell fencing method

shell-运行任意shell命令以隔离活动的NameNode
shellFencing Methods运行任意shell命令，您可以按如下所示进行配置：

dfs.ha.fencing.methods shell(/path/to/my/script.sh arg1 arg2 ...)

（‘and’）'之间的字符串直接传递给bash shell，不能包含任何右括号。

执行时，配置脚本的第一个参数将是要隔离的NameNode 的地址，后跟配置中指定的所有参数。

shell命令将在设置为包含所有当前Hadoop配置变量的环境中运行，配置键中的“u”字符将替换任何“.”字符。所使用的配置已将任何特定于NameNode 的配置升级为其通用形式-例如，DFSNameNode 的RPC-Address将包含目标节点的RPC地址，即使配置可能将该变量指定为DFS.NAMENODE.RPC-Address.NS1.nn1。

以下变量也适用于要隔离的目标节点：
Variable Description
$target_host Hostname of the node to be fenced
$target_port IPC port of the node to be fenced
$target_address The above two variables, combined as host:port
$target_nameserviceid The nameservice ID of the NameNode to be fenced
$target_namenodeid The NameNode ID of the NameNode to be fenced

您还可以在shell命令本身中使用这些环境变量作为替换。例如：

dfs.ha.fencing.methods shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)

如果shell命令返回退出代码0，则确定围栏成功。如果返回任何其他退出代码，则围栏未成功，将尝试列表中的下一个Fencing Methods。

注意：此Fencing Methods不实现任何超时。如果超时是必需的，那么它们应该在shell脚本本身中实现（例如，by forking a subshell to kill its parent in some number of seconds）

测试
mkdir journal /opt/journal/
chown hdfs:hadoop /opt/journal/

https://www.cloudera.com/documentation/enterprise/6/latest/topics/cdh_hag_hdfs_ha_config.html

其他组件使用HDFS HA
Configuring the Hive Metastore to Use HDFS HA.
https://www.cloudera.com/documentation/enterprise/6/latest/topics/cdh_hag_hdfs_ha_cdh_components_config.html#topic_2_6_3

Cloudera Manager ensures that one NameNode is active, and saves the namespace. Then it stops the standby NameNode, creates a SecondaryNameNode, removes the standby NameNode role, and restarts all the HDFS services.

Configuring HBase to Use HDFS HA
If you configure HBase to use an HA-enabled HDFS instance, Cloudera Manager automatically handles HA configuration for you.

Configuring the Hive Metastore to Use HDFS HA
The Hive metastore can be configured to use HDFS high availability by using Cloudera Manager or by using the command-line for unmanaged clusters.

In the Cloudera Manager Admin Console, go to the Hive service.
Select Actions > Stop.
Note: You may want to stop the Hue and Impala services first, if present, as they depend on the Hive service.
Click Stop again to confirm the command.
Back up the Hive metastore database.
Select Actions > Update Hive Metastore NameNodes and confirm the command.
Select Actions > Start and click Start to confirm the command.
Restart the Hue and Impala services if you stopped them prior to updating the metastore.
Configuring Hue to Work with HDFS HA Using Cloudera Manager
Add the HttpFS role.
After the command has completed, go to the Hue service.
Click the Configuration tab.
Locate the HDFS Web Interface Role property or search for it by typing its name in the Search box.
Select the HttpFS role you just created instead of the NameNode role, and save your changes.
Restart the Hue service.
Configuring Impala to Work with HDFS HA
Complete the steps to reconfigure the Hive metastore database, as described in the preceding section. Impala shares the same underlying database with Hive, to manage metadata for databases, tables, and so on.
Issue the INVALIDATE METADATA statement from an Impala shell. This one-time operation makes all Impala daemons across the cluster aware of the latest settings for the Hive metastore database. Alternatively, restart the Impala service.
Configuring Oozie to Use HDFS HA
To configure an Oozie workflow to use HDFS HA, use the HDFS nameservice instead of the NameNode URI in the element of the workflow.

Example:

${jobTracker} hdfs://ha-nn where ha-nn is the value of dfs.nameservices in hdfs-site.xml.

取消HA
Go to the HDFS service.
Select Actions > Disable High Availability.
Select the hosts for the NameNode and the SecondaryNameNode and click Continue.
Select the HDFS checkpoint directory and click Continue.
Confirm that you want to take this action.
Configuring the Hive Metastore to Use HDFS HA.

https://www.cloudera.com/documentation/enterprise/6/latest/topics/cdh_hag_hdfs_ha_cdh_components_config.html#topic_2_6_3

Cloudera Manager ensures that one NameNode is active, and saves the namespace. Then it stops the standby NameNode, creates a SecondaryNameNode, removes the standby NameNode role, and restarts all the HDFS services.

管理HA
https://www.cloudera.com/documentation/enterprise/6/latest/topics/cdh_hag_hdfs_ha_admin.html#topic_2_7

更换NameService名称

https://www.cloudera.com/documentation/enterprise/6/latest/topics/admin_ha_change_nameservice.html#concept_rw1_sxx_3r

HDFS Federated
https://www.cloudera.com/documentation/enterprise/6/latest/topics/cm_dg_manage_federated_hdfs.html#cmug_topic_4_6

HDFS HA
本指南适用于希望通过配置集群而不出现单点故障来实现连续可用性的ApacheHadoop系统管理员。

目前并非所有Hadoop组件都支持高可用性配置。但是，一些当前的SPOF（单点故障）组件可以配置为在发生故障时自动重新启动（下表中的自动重新启动可配置）。一些组件隐式支持高可用性，因为它们包含分布式进程（表中用星号（）标识）。此外，一些组件依赖于外部数据库，这些数据库也必须配置为支持高可用性。
High Availability Auto-Restart Configurable Components with External Databases
Alert Publisher Hive Metastore Activity Monitor
Cloudera Manager Agent Impala catalog service Cloudera Navigator Audit Server
Cloudera Manager Server Impala statestore Cloudera Navigator Metadata Server
Data Node* Sentry Service Hive Metastore Server
Event Server Spark Job History Server Oozie Server
Flume* YARN Job History Server Reports Manager
HBase Master Sentry Server
Host Monitor Sqoop Server
Hue (add multiple services, use load balancer)
Impalad* (add multiple services, use load balancer)
NameNode
Navigator Key Trustee
Node Manager*
Oozie Server
RegionServer*
Reports Manager
Resource Manager
Service Monitor
Solr Server*
Zookeeper server*
Continue reading:

HDFS High Availability
MapReduce (MRv1) and YARN (MRv2) High Availability
Cloudera Navigator Key Trustee Server High Availability
Enabling Key Trustee KMS High Availability
Enabling Navigator HSM KMS High Availability
High Availability for Other CDH Components
Navigator Data Management in a High Availability Environment
Configuring Cloudera Manager for High Availability With a Load Balancer
Categories: Administrators | High Availability | All Categories

FAQ
有关HDFS HA的一般问题
“状态待机时不支持操作类别读/写”是什么意思？
以下信息来自Apache Hadoop wiki：
在启用了HA的集群中，DFS客户机无法提前知道在给定时间内哪个名称节点处于活动状态。因此，当客户机联系一个名称节点，而它恰好是备用节点时，读或写操作将被拒绝，并记录此消息。然后客户端将自动联系另一个名称节点并重试该操作。只要集群中有一个活动和一个备用名称节点，就可以安全地忽略此消息。

如果应用程序配置为始终只与一个名称节点联系，则此消息表示应用程序无法执行任何读/写操作。在这种情况下，需要修改应用程序以使用集群的HA配置。jira hdfs-3447处理降低要调试的此消息（以及类似消息）的严重性，以减少日志中的噪声，但截至2018年10月仍未解决。

Federation

FAQ

NameNode启动慢
DataNode状态正常，但无法正常上报数据块
HDFS Web UI无法正常刷新损坏数据的信息
distcp命令在安全集群上失败并抛出异常
当dfs.datanode.data.dir中定义的磁盘数量等于dfs.datanode.failed.volumes.tolerated的值时，DataNode启动失败
当多个data.dir被配置在一个磁盘分区内，DataNode的容量计算将会出错
当Standby NameNode存储元数据（命名空间）时，出现断电的情况，Standby NameNode启动失败
在存储小文件过程中，系统断电，缓存中的数据丢失
FileInputFormat split的时候出现数组越界
当分级存储策略为LAZY_PERSIST时，为什么文件的副本的存储类型都是DISK
NameNode节点长时间满负载，HDFS客户端无响应
DataNode禁止手动删除或修改数据存储目录
成功回滚后，为什么NameNode UI上显示有一些块缺失
为什么在往HDFS写数据时报"java.net.SocketException: No buffer space available"异常
为什么主NameNode重启后系统出现双备现象
HDFS执行Balance时被异常停止，再次执行Balance会失败
IE浏览器访问HDFS原生UI界面失败，显示无法显示此页
EditLog不连续导致NameNode启动失败