[原创]Hadoop-2.5.2-HA原文译

使用the Quorum Journal Manager实现HDFS高可用

2017/1/22 11:57:22

原文

目的(Purpose)

* 这个指南提供了对HDFS-HA特性，使用QJM特性如何去配置和管理一个HA集群的概述。

---

Note

* 通过QJM在Active和Standby NameNodes之间共享edit logs

---

背景（Background）

* 在Hadoop 2.0.0之前(Prior), NameNode在一个HDFS集群中是存在单点故障（SPOF）。每个集群有一个NameNode，如果这个机器或进程不可用，整个集群将不可用，直到此NameNode被重启，或在另一个单独的机器上新生成。
* 在两个主要方面影响HDFS集群的总可用性
	* 没计划的事件，如一个机器crash, 这个集群将不可用，直到操作员重启NameNode。
	* 计划维护的事件，如在NameNode的机器上软件或硬件升级将会导致集群的窗口停机时间。
* HA特性旨在以上问题，通过 在具有热备份的主动/被动配置中 提供 在同一个集群中 运行两个冗余的NameNodes选项 解决上述问题

---

架构（Architecture）

* 在一个典型的HA集群中，两个单独的机器被配置做为NameNodes。在任何时间点，这些NameNodes中的确切的一个是Active状态，另一个是Standby状态。这个Active NameNode负责集群中所有客户操作请求，然而Standby简单的扮演做为一个slave,保持足够的状态，在必须时提供快速的故障转移。
* 为了Standby 节点和Active节点保持状态同步，两个节点通过一组被称为“JournalNodes”(JNs)独立守护进程交流。当任何namespace修改被Active 节点执行时，它持久地将修改的记录记录到这些JNs中的大多数中。Standby节点能从JNs中读取edits log,并且不断地观察他们对edit log的更改。当Standby节点看到这些改变的edits,它将应用它们到自己的namespace. 在故障转移时，Standby提升自己到Active状态之前，它将会确保它已经从JNs读取所有的edits. 这确保namespace状态在故障转移发生之前是完全同步的。
* 为了提供快速地故障转移，Standby节点具有集群中块位置的最新信息是必须的。为了实现这些，所有DataNodes被配置有两个NameNode的位置，并向两者发送块位置信息和心跳。
* 对于HA集群的正确操作，每次只有一个NameNodes是Active状态是至关重要的。否则，namespace状态将会快速地在两者之间发散（diverge）,数据丢失危险和别的不正确的结果。为了确保这种性质和防止被称为“split-brain scenario”(脑裂)，JNs只允许在一个时间只有一个NameNode称为一个writer. 在故障转移期间，将要变成Active状态的NameNode将简单地接管向JNs写的角色，这将有效防止别的处在Active状态的NameNodes继续写，允许新的Active状态的NameNode去安全地处理故障转移。

---

硬件资源（Hardware resources）

* 为了部署一个HA集群，你应该准备以下：
	* NameNode machines - 运行Active和Standby NameNodes的机器，应该有相同的硬件，
	* JournalNode machines - 运行JournalNodes的机器。JournalNode 守护进程（daemon）是相对轻量级的，因此它们可以合理地并置在具有其他Hadoop守护进程的机器上，如NameNode,JobTracker, YARN ResourceManager.
		Note: 必须至少3个JournalNode daemons,因为edit log 修改必须被写到大多数JNs上。这将允许系统容忍一台机器故障，你也可以运行超过3个JournalNodes，但是为了实际增加系统可以容忍的故障数，你应该运行奇数个JNs，(i.e. 3, 5, 7, etc).
			   当运行N个JournalNodes,系统能容忍最多（N-1）/2 个故障并能继续正常工作。
	* 在一个HA集群中，Standby NameNode 也扮演checkpoints of the namespace state, 因此在HA集群中运行一个Secondary NameNode, CheckpointNode,BackupNode不是必须的. 事实上，这样做将会是一个错误。这还允许重新配置一个非启用HA的HDFS集群到启用HA的人员去重用他们先前专用于Secondary NameNode的硬件

---

部署（Deployment）

* 配置概述
	* 与联合配置类似，HA配置向后兼容，允许现有的单个NameNode配置工作而不更改。新配置被设计为使得集群中的所有节点可以具有相同的配置，而不需要基于节点的类型将不同的配置文件部署到不同的机器。
	* 与HDFS联合一样，HA群集使用名称服务ID（nameservice ID）来标识可能实际上由多个HA NameNode组成的单个HDFS实例.此外，一个称为NameNode ID的新抽象与HA一起添加.集群中的每个不同NameNode具有不同的NameNode ID以区分它。为了支持所有NameNode的单个配置文件，相关的配置参数后面加上nameservice ID和NameNode ID。
* 配置详情
	* hdfs-site.xml
	* 要配置HA NameNode，必须向hdfs-site.xml配置文件中添加多个配置选项。
	* 设置这些配置的顺序并不重要，但是为dfs.nameservices和dfs.ha.namenodes [nameservice ID]选择的值将确定后面的那些键。因此，在设置其余配置选项之前，应决定这些值
		* dfs.nameservices - 新nameservice的逻辑名
			* 为此名称服务选择一个逻辑名称，例如“mycluster”，并将此逻辑名称用于此配置选项的值。你选择的名字是任意的。它将用于配置和作为集群中绝对HDFS路径的权限组件。
			Note:如果您还使用HDFS Federation，此配置设置还应包括其他名称服务（HA或其他）的列表，以逗号分隔列表。
			<property>
				<name>dfs.nameservices</name>
				<value>mycluster</value>
			</property>
		* dfs.ha.namenodes.[nameservice ID] - 唯一标识在nameservice中的每个NameNode
			* 使用逗号分隔的NameNode ID列表进行配置。 DataNodes将使用它来确定集群中的所有NameNode。
			* 例如，如果以前使用“mycluster”作为名称服务ID，并且您希望使用“nn1”和“nn2”作为NameNode的各个ID，您可以这样配置：
			<property>
				<name>dfs.ha.namenodes.mycluster</name>
				<value>nn1,nn2</value>
			</property>
			Note:目前，每个nameservice最多只能配置两个NameNode。
		* dfs.namenode.rpc-address.[nameservice ID].[name node ID] - 每个NameNode的完全限定RPC监听地址
			* 对于之前配置的NameNode ID，设置NameNode进程的完整地址和IPC端口。请注意，这将产生两个单独的配置选项。例如：
			<property>
				<name>dfs.namenode.rpc-address.mycluster.nn1</name>
				<value>machine1.example.com:8020</value>
			</property>
			<property>
				<name>dfs.namenode.rpc-address.mycluster.nn2</name>
				<value>machine2.example.com:8020</value>
			</property>
			Note:如果您愿意，您可以类似地配置“servicerpc-address”设置。
		* dfs.namenode.http-address.[nameservice ID].[name node ID] - 每个NameNode的完全限定HTTP监听地址
			* 与上面的rpc-address类似，设置NameNode的HTTP服务器的地址以进行侦听。例如：
			<property>
				<name>dfs.namenode.http-address.mycluster.nn1</name>
				<value>machine1.example.com:50070</value>
			</property>
			<property>
				<name>dfs.namenode.http-address.mycluster.nn2</name>
				<value>machine2.example.com:50070</value>
			</property>
			Note:如果您启用了Hadoop的安全功能，您还应该为每个NameNode设置类似的https地址。
		* dfs.namenode.shared.edits.dir - 标识NameNode将要读写edits的JNs组的URI
			* 这是配置提供共享编辑存储的JournalNode的地址的地方，由Active NameNode写入并由Standby NameNode读取以保持最新与Active NameNode做出的所有文件系统更改。
			* 虽然必须指定多个JournalNode地址，但您只应配置其中一个URI。 URI的格式应为：“qjournal：// host1：port1; host2：port2; host3：port3 / journalId”。Journal ID是此名称服务的唯一标识符，它允许单个集合的JournalNode为多个 Federated namesystems 提供存储. 尽管不是必需的，但是对于Journal ID 重用nameservice ID是个好主意。
			* 例如，如果此群集的JournalNode在计算机“node1.example.com”，“node2.example.com”和“node3.example.com”上运行，并且名称服务ID为“mycluster”，则可以使用以下作为此设置的值（JournalNode的默认端口为8485）：
			<property>
				<name>dfs.namenode.shared.edits.dir</name>
				<value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
			</property>
		* dfs.client.failover.proxy.provider.[nameservice ID] - HDFS客户端用来去和Active NameNode联系的JAVA Class
			* 配置将由DFS客户端使用的Java类的名称，以确定哪个NameNode是当前活动的，以及因此哪个NameNode当前为客户端请求提供服务。
			* 目前Hadoop附带的唯一实现是ConfiguredFailoverProxyProvider，所以使用它，除非你使用自定义。例如：
			<property>
				<name>dfs.client.failover.proxy.provider.mycluster</name>
				<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
			</property>
		* dfs.ha.fencing.methods - 将用于在故障转移期间屏蔽Active NameNode的脚本或Java类的列表
			* 期望系统的正确性，在任何给定时间只有一个NameNode处于活动状态
			* 重要的是，当使用Quorum Journal Manager时，只有一个NameNode允许写入JournalNode，因此没有可能破坏来自裂脑情景的文件系统元数据。
			* 但是，当发生故障转移时，以前的Active NameNode仍然可能为客户端提供读取请求，这可能已过期，直到该NameNode在尝试写入JournalNode时关闭。
			* 因此，仍然需要配置一些防护方法，即使在使用Quorum Journal Manager时也是如此。
			* 但是，为了在防护机制发生故障的情况下提高系统的可用性，建议配置可确保作为列表中最后一个防护方法返回成功的防护方法。
			* 请注意，如果选择不使用实际的防护方法，您仍然必须为此设置配置一些内容，例如“shell（/ bin / true）”。
			* 在故障转移过程中使用的防护方法被配置为一个回车符分隔的列表，将在顺序尝试，直到一个表明防护成功。
			* Hadoop提供了两种方法：shell和sshfence。
			* 有关实现自己的自定义防护方法的信息，请参阅org.apache.hadoop.ha.NodeFencer类
				* sshfence - SSH 给Active NameNode 并 杀掉此进程
					* sshfence选项SSH到目标节点，并使用fuser来终止监听服务的TCP端口的进程。
					* 为了使此防护选项可以工作，它必须能够SSH到目标节点，而不提供密码短语。
					* 因此，还必须配置dfs.ha.fencing.ssh.private-key-files选项，这是一个用逗号分隔的SSH私钥文件列表。例如：
					<property>
						<name>dfs.ha.fencing.methods</name>
						<value>sshfence</value>
					</property>
					<property>
	 					<name>dfs.ha.fencing.ssh.private-key-files</name>
						<value>/home/exampleuser/.ssh/id_rsa</value>
					</property>
					* 可选地，可以配置非标准用户名或端口以执行SSH。
					* 还可以为SSH配置超时（以毫秒为单位），之后此防护方法将被视为失败。它可以这样配置：
					<property>
						<name>dfs.ha.fencing.methods</name>
						<value>sshfence([[username][:port]])</value>
					</property>
					<property>
						<name>dfs.ha.fencing.ssh.connect-timeout</name>
						<value>30000</value>
					</property>
				* shell - 运行一个任意的shell命令来防护 Active NameNode
					* shell防护方法运行任意shell命令。它可以这样配置：
					<property>
						<name>dfs.ha.fencing.methods</name>
						<value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
					</property>
					* '（'和'）'之间的字符串直接传递给bash shell，不能包含任何括号。
					* shell命令将使用设置为包含所有当前Hadoop配置变量的环境运行，其中“_”字符替换在配置键中的任何“.”字符。
					* 所使用的配置已经将任何特定于namenode的配置提升为其通用形式
					* 例如dfs_namenode_rpc-address将包含目标节点的RPC地址，即使配置可能将该变量指定为dfs.namenode.rpc-address.ns1.nn1。
					* 此外，还可以使用以下指向要保护的目标节点的变量：
						$target_host:	hostname of the node to be fenced
						$target_port:	IPC port of the node to be fenced
						$target_address:	the above two, combined as host:port
						$target_nameserviceid:	the nameservice ID of the NN to be fenced
						$target_namenodeid:	the namenode ID of the NN to be fenced
					* 这些环境变量也可以用作shell命令本身的替换。例如：
					<property>
						<name>dfs.ha.fencing.methods</name>
						<value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
					</property>
					* 如果shell命令返回退出代码0，则确定防护成功。如果它返回任何其他退出代码，防护不成功，将尝试列表中的下一个防护方法。
					Note:此防护方法不实现任何超时。如果超时是必要的，它们应该在shell脚本本身中实现（例如通过派生子shell在几秒钟内杀死它的父进程）。
		* dfs.journalnode.edits.dir - JournalNode守护进程将存储其本地状态的路径
			* 这是JournalNode计算机上的绝对路径，将存储JN使用的编辑和其他本地状态。
			* 您只能对此配置使用单个路径。
			* 此数据的冗余通过运行多个单独的JournalNode或通过在本地连接的RAID阵列上配置此目录来提供。例如：
			<property>
				<name>dfs.journalnode.edits.dir</name>
				<value>/path/to/journal/node/local/data</value>
			</property>			
		* core-site.xml	(可选的)
		* fs.defaultFS - 当没有给出时，Hadoop FS客户端使用的默认路径前缀
			* 可选的配置项，您现在可以配置Hadoop客户端的默认路径以使用新的HA启用的逻辑URI。
			* 如果您之前使用“mycluster”作为名称服务ID，则这将是所有HDFS路径的权限部分的值。
			* 这可能是这样配置的，在您的core-site.xml文件中：
			<property>
				<name>fs.defaultFS</name>
				<value>hdfs://mycluster</value>
			</property>
* 部署详情
	* 在设置了所有必需的配置选项后，必须在将要运行它们的计算机集上启动JournalNode守护程序。
	* 这可以通过运行命令“hdfs-daemon.sh journalnode”并等待守护程序在每个相关机器上启动来完成。
	* 一旦启动了JournalNode，必须首先同步两个HA NameNode的磁盘元数据。
		* 如果要设置一个新的HDFS集群，您应该首先在一个NameNode上运行format命令（hdfs namenode -format）。
		* 如果您已经格式化了NameNode，或者正在将非HA启用的集群转换为启用HA，那么现在应该通过在未被格式化的NameNode上运行命令“hdfs namenode -bootstrapStandby" 复制元数据目录的内容到别的，未被格式化的NameNode上。
		* 运行此命令还将确保JournalNode（由dfs.namenode.shared.edits.dir配置）包含足够的编辑事务，以便能够启动两个NameNode。
		* 如果要将非HA NameNode转换为HA，则应运行命令“hdfs -initializeSharedEdits”，该命令将使用来自本地NameNode edits目录的edits数据初始化JournalNodes。
	* 此时，您可以像启动一个NameNode一样启动两个HA NameNode。
	* 您可以通过浏览其配置的HTTP地址单独访问每个NameNodes的网页。
	* 您应该注意到，配置的地址旁边将是NameNode的HA状态（“备用”或“活动”。）每当HA NameNode启动时，它最初处于备用状态。
* 管理命令
	* 现在您的HA NameNode已配置并启动，您将可以访问一些其他命令来管理HA HDFS集群。
	* 具体来说，您应该熟悉“hdfs haadmin”命令的所有子命令。
	* 运行此命令而没有任何其他参数将显示以下使用信息：
		Usage: DFSHAAdmin [-ns <nameserviceId>]
					[-transitionToActive <serviceId>]
					[-transitionToStandby <serviceId>]
					[-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
					[-getServiceState <serviceId>]
					[-checkHealth <serviceId>]
					[-help <command>]
	* 本指南介绍了每个子命令的高级用法。有关每个子命令的具体使用信息，应运行“hdfs haadmin -help <command>”。
	* transitionToActive and transitionToStandby - 将给定NameNode的状态转换为Active或Standby.
		* 这些子命令分别使给定的NameNode转换到活动或待机状态。
		* 这些命令不尝试执行任何防护，因此很少使用。
		* 相反，人们应该总是喜欢使用“hdfs haadmin -failover”子命令。
	* failover - 启动两个NameNode之间的故障转移
		* 此子命令导致从第一个提供的NameNode到第二个提供的NameNode的故障转移。
		* 如果第一个NameNode处于待机状态，则该命令简单地将第二个转换为活动状态而没有错误。
		* 如果第一个NameNode处于活动状态，将尝试正常地将其转换到备用状态。
		* 如果失败，将依次尝试防护方法（由dfs.ha.fencing.methods配置），直到成功。
		* 只有在此过程之后，第二个NameNode才会转换为活动状态。
		* 如果没有成功的防护方法，则第二个NameNode将不会转换为活动状态，并返回错误。
	* getServiceState - 确定给定的NameNode是活动还是备用
		* 连接到提供的NameNode以确定其当前状态，适当地打印“待机”或“活动”到STDOUT。
		* 此子命令可能由cron作业或监视脚本使用，这些脚本需要根据NameNode当前是活动还是待机来进行不同的操作。
	* checkHealth - 检查给定NameNode的运行状况
		* 连接到提供的NameNode以检查其健康状况。
		* NameNode能够对自身执行一些诊断，包括检查内部服务是否按预期运行。
		* 如果NameNode健康，此命令将返回0，否则为非零。可以使用此命令进行监视。
		Note:这还没有实现，并且目前将始终返回成功，除非给定的NameNode完全关闭。

---

自动故障转移（Automatic Failover）

* Introduction
	* 上述部分介绍如何配置手动故障转移。
	* 在该模式下，即使活动节点发生故障，系统也不会自动触发从活动节点到备用节点的故障转移。
	* 本节介绍如何配置和部署自动故障转移。
* Components
	* 自动故障转移为HDFS部署添加了两个新组件：ZooKeeper quorum(仲裁)和ZKFailoverController进程（缩写为ZKFC）。
	* Apache ZooKeeper是一种高可用性的服务，用于维护少量协调数据，通知客户端数据中的更改，以及监控客户端的故障。
	* 自动HDFS故障转移的实现依赖于ZooKeeper，用于以下事情：
		* Failure detection（故障检测）
			* 集群中的每个NameNode机器都在ZooKeeper中维护一个持久会话。
			* 如果机器崩溃，ZooKeeper会话将过期，通知其他NameNode应该触发故障转移。
		* Active NameNode election（Active NameNode 选举）
			* ZooKeeper提供了一种简单的机制来将节点专门选为活动节点。
			* 如果当前活动的NameNode崩溃，另一个节点可能在ZooKeeper中采用特殊的排它锁，表明它应该成为下一个活动。
	* ZKFailoverController（ZKFC）是一个新的组件，它是一个ZooKeeper客户端，也监视和管理NameNode的状态。
	* 每个运行NameNode的机器都运行一个ZKFC，ZKFC负责：
		* Health monitoring
			* ZKFC使用health-check命令周期性地ping它的本地NameNode。
			* 只要NameNode及时响应，健康状态，ZKFC认为节点健康。
			* 如果节点崩溃，冻结或以其他方式进入不正常状态，则健康状况监视器将其标记为不健康。
		* ZooKeeper session management
			* 当本地NameNode健康时，ZKFC在ZooKeeper中保持一个打开的会话。
			* 如果本地NameNode是活动的，它还拥有一个特殊的“锁”znode。
			* 这个锁使用ZooKeeper的支持“临时”节点;如果会话过期，则锁节点将被自动删除。
		* ZooKeeper-based election（基于ZooKeeper的选举）
			* 如果本地NameNode是健康的，并且ZKFC看到没有其他节点当前持有锁znode，它本身将尝试获取锁。
			* 如果它成功，则它“赢得选举”，并且负责运行故障转移以使其本地NameNode变为Active
			* 故障转移过程类似于上述的手动故障转移：首先，如果必要，先前的活动被防护，然后本地NameNode转换到Active状态。
	* 有关自动故障切换设计的更多详细信息，请参阅Apache HDFS JIRA上的HDFS-2185附带的设计文档。
* Deploying ZooKeeper
	* 在典型的部署中，ZooKeeper守护程序配置为在三个或五个节点上运行。
	* 由于ZooKeeper本身具有轻量资源要求，因此可以在与HDFS NameNode和Standby Node相同的硬件上并置ZooKeeper节点。
	* 许多运营商选择在与YARN ResourceManager相同的节点上部署第三个ZooKeeper进程。
	* 建议将ZooKeeper节点配置为将其数据存储在HDFS元数据的不同磁盘驱动器上，以实现最佳性能和隔离。
	* ZooKeeper的设置超出了本文档的范围。我们假设您已经设置了一个在三个或更多节点上运行的ZooKeeper集群，
	* 并通过使用ZK CLI连接来验证其正确的操作。
* Before you Begin
	* 在开始配置自动故障转移之前，应该关闭集群。
	* 当集群运行时，当前不可能从手动故障转移设置转换为自动故障转移设置。
* Configuring automatic failover
	* 自动故障转移的配置需要为您的配置添加两个新参数。在您的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>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
	</property>
	* 这列出了运行ZooKeeper服务的主机端口对。
	* 与文档中先前描述的参数一样,可以通过用名称服务ID后缀配置键来在每个名称服务的基础上配置这些设置.
	* 例如，在启用了联合的集群中，可以通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id来为仅一个名称服务器显式启用自动故障切换。
	* 还有几个其他配置参数可以设置为控制自动故障转移的行为;然而，它们对于大多数安装不是必需的。
	* 有关详细信息，请参阅配置键特定文档
* Initializing HA state in ZooKeeper
	* 添加配置键后，下一步是在ZooKeeper中初始化所需的状态。您可以通过从一个NameNode主机运行以下命令来执行此操作。
	$ hdfs zkfc -formatZK
	* 这将在ZooKeeper中创建一个znode，其中自动故障转移系统存储其数据。
* Starting the cluster with start-dfs.sh
	* 由于在配置中启用了自动故障转移，start-dfs.sh脚本现在将在运行NameNode的任何计算机上自动启动ZKFC守护程序。
	* 当ZKFC启动时，它们将自动选择一个NameNode成为Active。
* Starting the cluster manually
	* 如果手动管理集群上的服务，则需要在运行NameNode的每台计算机上手动启动zkfc后台驻留程序。
	* 您可以通过运行以下命令来启动守护程序：
	$ hadoop-daemon.sh start zkfc
* Securing access to ZooKeeper
	* 如果您正在运行安全集群，您可能想要确保存储在ZooKeeper中的信息也是安全的。
	* 这防止恶意客户端修改ZooKeeper中的元数据或潜在地触发错误的故障转移。
	* 为了保护ZooKeeper中的信息，首先将以下内容添加到您的core-site.xml文件中：
	<property>
		<name>ha.zookeeper.auth</name>
		<value>@/path/to/zk-auth.txt</value>
	</property>
	<property>
		<name>ha.zookeeper.acl</name>
		<value>@/path/to/zk-acl.txt</value>
	</property>
	* 请注意这些值中的“@”字符 - 这指定配置不是内联的，而是指向磁盘上的文件。
	* 第一个配置的文件指定ZooKeeper身份验证的列表，格式与ZK CLI所使用的格式相同。
	* 例如，您可以指定以下内容： digest:hdfs-zkfcs:mypassword
	* 其中hdfs-zkfcs是ZooKeeper的唯一用户名，mypassword是一个用作密码的唯一字符串。
	* 接下来，使用以下命令生成与此身份验证对应的ZooKeeper ACL：
	* $ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
		output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=
	* 将此输出的“ - >”字符串部分复制并粘贴到文件zk-acls.txt中，前缀为字符串“digest：”。例如：
		digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
	* 为了使这些ACL生效，您应该如上所述重新运行zkfc -formatZK命令。
	* 执行此操作后，您可以从ZK CLI验证ACL，如下所示：
		[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
		'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
		: cdrwa
* Verifying automatic failover
	* 一旦设置了自动故障切换，您应该测试其操作
	* 为此，首先查找活动的NameNode。
	* 您可以通过访问NameNode Web界面来确定哪个节点处于活动状态 - 每个节点都会在页面顶部报告其HA状态。
	* 找到活动的NameNode后，尝试导致该节点出现故障。
	* 例如，可以使用kill -9 <pid of NN>来模拟JVM崩溃。
	* 或者，您可以重新启动机器或拔掉其网络接口以模拟不同类型的中断。
	* 在触发您希望测试的中断之后，其他NameNode应在几秒钟内自动变成Active。
	* 检测故障和触发故障切换所需的时间取决于ha.zookeeper.session-timeout.ms的配置，但默认为5秒。
	* 如果测试不成功，您可能配置不正确。
	* 检查zkfc守护程序以及NameNode守护程序的日志，以便进一步诊断问题。

---

自动故障转移FAQ

	Q:我以任何特定的顺序启动ZKFC和NameNode守护进程,重要吗？
	A:No,在任何给定的节点上，您可以在相应的NameNode之前或之后启动ZKFC。
	Q:我应该进行什么额外的监控？
	A:	* 您应该在运行NameNode的每个主机上添加监视，以确保ZKFC保持运行。
		* 在某些类型的ZooKeeper故障中，例如，ZKFC可能意外退出，
		* 并应重新启动以确保系统准备好进行自动故障转移。
		* 此外，您应该监视ZooKeeper仲裁中的每个服务器。
		* 如果ZooKeeper崩溃，则自动故障切换将不起作用。
	Q:如果ZooKeeper关闭会发生什么？
	A:	* 如果ZooKeeper群集崩溃，则不会触发自动故障转移。
		* 但是，HDFS将继续运行而没有任何影响。
		* 当ZooKeeper重新启动时，HDFS将重新连接没有问题。
	Q:我可以将我的一个NameNode指定为主要/首选吗？
	A:	* No,目前不支持。
		* 无论哪个NameNode首先启动都将变为活动状态。
		* 您可以选择以特定顺序启动集群，以便首选节点首先启动。
	Q:当配置自动故障转移时，如何启动手动故障转移？
	A:	* 即使配置了自动故障转移，也可以使用相同的hdfs haadmin命令启动手动故障转移。
		* 它将执行协调故障转移。

---

HDFS升级/完成/回滚,带有启用HA的（HDFS Upgrade/Finalization/Rollback with HA Enabled）

* 当在HDFS的版本之间移动时，有时可以简单地安装较新的软件并重新启动集群。
* 然而，有时，升级您正在运行的HDFS版本可能需要更改磁盘数据。
* 在这种情况下，必须在安装新软件后使用HDFS升级/完成/回滚工具。
* 在HA环境中，这个过程变得更加复杂，因为NN依赖的磁盘元数据是定义分布式的，
* 在该对的两个HA NN上，以及在使用QJM的情况下的JournalNode共享编辑存储。
* 本文档部分介绍在HA设置中使用HDFS升级/完成/回滚功能的过程。
To perform an HA upgrade 操作员必须执行以下操作：
1.正常关闭所有NN，并安装较新的软件。
2.启动所有JN。请注意，执行升级，回滚或最终化操作时，所有JN都必须正在运行。如果任何JN在运行任何这些操作时都关闭，操作将失败。
3.使用'-upgrade'标志启动其中一个NN。
4.开始时，此NN不会像通常在HA设置中那样进入备用状态。相反，该NN将立即进入活动状态，执行其本地存储盘的升级，并且还执行共享编辑日志的升级。
5.在这一点上，HA对中的另一NN将与升级的NN不同步。为了使其恢复同步并且再次具有高可用性设置，您应该通过使用'-bootstrapStandby'标志运行NN来重新引导此NameNode。使用'-upgrade'标志启动第二个NN是一个错误。
Note: 如果在任何时候想要在完成或回滚升级之前重新启动NameNodes，则应该正常启动NN，即没有任何特殊的启动标志。
To finalize an HA upgrade
* 操作员将使用`hdfs dfsadmin -finalizeUpgrade'命令，而NN正在运行并且其中之一处于活动状态。
* 在发生此时的Active NN将执行共享日志的最终化，并且其本地存储目录包含先前FS状态的NN将删除其本地状态。
To perform a rollback of an upgrade
* 两个NN应首先关闭
* 操作员应在NN上运行回滚命令，在那里它们发起升级过程，这将在本地dirs上以及在共享日志（NFS或JN上）上执行回滚。
* 之后，应该启动此NN，并且操作员应在其他NN上运行`-bootstrapStandby'，以使两个NN与此回滚的文件系统状态同步。