HDFS高级-集群管理和运维

1 HDFS数据迁移解决方案

1.1 数据迁移

数据迁移的使用场景：

• 冷热集群数据同步、分类存储

• 集群数据整体搬迁

当公司的业务迅速的发展,导致当前的服务器数量资源出现临时紧张的时候,为了更高效的利用资源,会将原A机房数据整体迁移到B机房的,原因可能是B机房机器多,而且B机房本身开销较A机房成本低些等；

• 数据的准实时同步

数据准实时同步的目的在于数据的双备份可用,比如某天A集群突然宣告不允许再使用了,此时可以将线上使用集群直接切向B的同步集群,因为B集群实时同步A集群数据,拥有完全一致的真实数据和元数据信息,所以对于业务方使用而言是不会受到任何影响的。

数据迁移要素考量：

• Bandwidth-带宽

带宽用的多了,会影响到线上业务的任务运行,带宽用的少了又会导致数据同步过慢的问题。

• Performance-性能

是采用简单的单机程序?还是多线程的性能更佳的分布式程序?

• Data-Increment-增量同步

当TB,PB级别的数据需要同步的时候,如果每次以全量的方式去同步数据,结果一定是非常糟糕。如果仅针对变化的增量数据进行同步将会是不错的选择。可以配合HDFS快照等技术实现增量数据同步。

• Syncable-数据迁移的同步性

数据迁移的过程中需要保证周期内数据是一定能够同步完的,不能差距太大.比如A集群7天内的增量数据,我只要花半天就可以完全同步到B集群,然后我又可以等到下周再次进行同步.最可怕的事情在于A集群的7天内的数据,我的程序花了7天还同步不完,然后下一个周期又来了,这样就无法做到准实时的一致性.其实7天还是一个比较大的时间,最好是能达到按天同步.

1.2 HDFS分布式拷贝工具：DistCp

• DistCp是Hadoop中的一种工具，在hadoop-tools工程下，作为独立子工程存在。
• 定位用于数据迁移，定期在集群之间和集群内部备份数据。
• 在备份过程中，每次运行DistCp都称为一个备份周期。尽管性能相对较慢，但它的普及程度已经越来越高。
• DistCp底层使用MapReduce在群集之间或并行在同一群集内复制文件。执行复制的MapReduce只有mapper阶段。

优势：

• 带宽限流

DistCp可以通过命令参数 bandwidth 来为程序进行带宽限流。

• 增量数据同步

在DistCp中可以通过update 、append 和diff 这3个参数实现增量同步。

Update 只拷贝不存在的文件或者目录。

Append 追加写目标路径下己存在的文件。

Diff 通过快照的diff对比信息来同步源端路径与目标路径。

Update解决了新增文件、目录的同步。Append解决己存在文件的增量更新同步。 Diff解决删除或重命名类型文件的同步。

• 高效的性能：分布式特性

DistCp底层使用MapReduce执行数据同步，MapReduce本身是一类分布式程序。

命令：

$ hadoop distcp
usage: distcp OPTIONS [source_path...] <target_path>
-append                //拷贝文件时支持对现有文件进行追加写操作
-async                  //异步执行distcp拷贝任务
-bandwidth <arg>        //对每个Map任务的带宽限速
-delete                 //删除相对于源端,目标端多出来的文件
-diff <arg>             //通过快照diff信息进行数据的同步                  
-overwrite              //以覆盖的方式进行拷贝,如果目标端文件已经存在,则直接覆盖
-p <arg>                //拷贝数据时,扩展属性信息的保留,包括权限信息,块大小信息等等
-skipcrccheck          //拷贝数据时是否跳过cheacksum的校验
-update                 //拷贝数据时,只拷贝相对于源端 ,目标端不存在的文件数据

其中 source_path 、target_path 需要带上地址前缀以区分不同的集群

例如 ：hadoop distcphdfs://nnl:8020/foo/a hdfs://nn2:8020/bar/foo

上面的命令表示从nnl集群拷贝／foo/a 路径下的数据到nn2集群的／bar/foo 路径下。

2 HDFS NAMENODE安全模式

概述：

• Hadoop中的安全模式safe mode是NameNode的维护状态，在此状态下NameNode不允许对文件系统进行任何更改，可以接受读数据请求。
• 在NameNode启动过程中，首先会从fsimage和edits日志文件加载文件系统状态。然后，等待DataNodes汇报可用的block信息。在此期间，NameNode保持在安全模式。随着DataNode的block汇报持续进行，当整个系统达到安全标准时，HDFS自动离开安全模式。在NameNode Web主页上会显示安全模式是打开还是关闭。
• 如果HDFS处于安全模式下，不允许HDFS客户端进行任何修改文件的操作,包括上传文件，删除文件，重命名，创建文件夹,修改副本数等操作。

安全模式自动进入：HDFS集群启动时，当NameNode启动成功之后，此时集群就会自动进入安全模式。

安全模式自动离开：自动离开条件（hdfs-site.xml、hdfs-default.xml）

dfs.replication      #hdfs block的副本数据，默认3
dfs.replication.max   #最大块副本数，默认512
dfs.namenode.replication.min   #最小块副本数，默认1
dfs.namenode.safemode.threshold-pct  #已汇报可用数据块数量占整体块数量的百分比阈值。默认0.999f。
#小于或等于0，则表示退出安全模式之前，不要等待特定百分比的块。
# 大于1的值将使安全模式永久生效。
dfs.namenode.safemode.min.datanodes  #指在退出安全模式之前必须存活的DataNode数量，默认0
dfs.namenode.safemode.extension  #达到阈值条件后持续扩展的时间。倒计时结束如果依然满足阈值条件
# 自动离开安全模式。默认30000毫秒

安全模式手动进入离开：

• 手动获取安全模式状态信息

hdfs dfsadmin -safemode get

• 手动进入命令

hdfs dfsadmin -safemode enter

手动进入安全模式对于集群维护或者升级的时候非常有用，因为这时候HDFS上的数据是只读的。

• 手动离开命令

hdfs dfsadmin -safemode leave

3 HDFS高阶优化方案

3.1 短路本地读取

概述：

• 在HDFS中，不管是Local Reads（DFSClient和Datanode在同一个节点）还是Remote Reads（DFSClient和Datanode不在同一个节点），底层处理方式都是一样的，都是先由Datanode读取数据，然后再通过RPC（基于TCP）把数据传给DFSClient。这样处理是比较简单的，但是性能会受到一些影响，因为需要Datanode在中间做一次中转。
• 尤其Local Reads的时候，既然DFSClient和数据是在一个机器上面，那么很自然的想法，就是让DFSClient绕开Datanode自己去读取数据。所谓的“短路”读取绕过了DataNode，从而允许客户端直接读取文件。显然，这仅在客户端与数据位于同一机器的情况下才可行。短路读取为许多应用提供了显着的性能提升。

老版本实现：

• HDFS-2246这个JIRA中，工程师们的想法是既然读取数据DFSClient和数据在同一台机器上，那么Datanode就把数据在文件系统中的路径，从什么地方开始读(offset)和需要读取多少(length)等信息告诉DFSClient，然后DFSClient去打开文件自己读取。
• 想法很好，问题在于配置复杂以及安全问题。
• 首先是配置问题，因为是让DFSClient自己打开文件读取数据，那么就需要配置一个白名单，定义哪些用户拥有访问Datanode的数据目录权限。
• 如果有新用户加入，那么就得修改白名单。需要注意的是，这里是允许客户端访问Datanode的数据目录，也就意味着，任何用户拥有了这个权限，就可以访问目录下其他数据，从而导致了安全漏洞。
• 因此，这个实现已经不建议使用了。

安全性改进版设计实现：

• 在HDFS-347中，提出了一种新的解决方案，让短路本地读取数据更加安全。
• 在Linux中，有个技术叫做Unix Domain Socket。Unix DomainSocket是一种进程间的通讯方式，它使得同一个机器上的两个进程能以Socket的方式通讯。
• 它带来的另一大好处是，利用它两个进程除了可以传递普通数据外，还可以在进程间传递文件描述符。
• 假设机器上的两个用户A和B，A拥有访问某个文件的权限而B没有，而B又需要访问这个文件。
• 借助Unix Domain Socket，可以让A打开文件得到一个文件描述符，然后把文件描述符传递给B，B就能读取文件里面的内容了即使它没有相应的权限。
• 在HDFS的场景里面，A就是Datanode，B就是DFSClient，需要读取的文件就是Datanode数据目录中的某个文件。

配置：

• libhadoop.so

因为Java不能直接操作Unix Domain Socket，所以需要安装Hadoop的native包libhadoop.so。在编译Hadoop源码的时候可以通过编译native模块获取。可以用如下命令来检查native包是否安装好。

hadoop checknative

• hdfs-site.xml

ldfs.client.read.shortcircuit 是打开短路本地读取功能的开关

ldfs.domain.socket.path 是Datanode和DFSClient之间沟通的Socket的本地路径。

<property>
<name>dfs.client.read.shortcircuit</name>
<value>true</value>
</property>
<property>
<name>dfs.domain.socket.path</name>
<value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>

还要确保Socket本地路径提前创建好

mkdir -p /var/lib/hadoop-hdfs

注意：这里创建的是文件夹hadoop-hdfs，而上述配置中的dn_socket是datanode自己创建的，不是文件夹

确认配置生效：

• 方式1：查看Datanode的日志
• 方式2：读取一个文件到本地
• 方式3：ReadStatistics API

3.2 HDFS Block负载平衡器

背景：

• HDFS数据可能并不总是在DataNode之间均匀分布。一个常见的原因是向现有群集中添加了新的DataNode。HDFS提供了一个Balancer程序，分析block放置信息并且在整个DataNode节点之间平衡数据，直到被视为平衡为止。
• 所谓的平衡指的是每个DataNode的利用率（本机已用空间与本机总容量之比）与集群的利用率（HDFS整体已用空间与HDFS集群总容量的比）之间相差不超过给定阈值百分比。
• 平衡器无法在单个DataNode上的各个卷（磁盘）之间进行平衡。

命令行：

hdfs balancer []
-threshold  10                     //集群平衡的条件,datanode间磁盘使用率相差阈值,区间选择:0~100
-policy datanode                 //平衡策略,默认为datanode, 如果datanode平衡,则集群已平衡.
-exclude  -f  /tmp/ip1.txt      //默认为空,指定该部分ip不参与balance, -f:指定输入为文件
-include  -f  /tmp/ip2.txt       //默认为空,只允许该部分ip参与balance,-f:指定输入为文件
-idleiterations  5                  //迭代 5

运行：

• Step1：设置平衡数据传输带宽

hdfs dfsadmin -setBalancerBandwidth   newbandwidth

其中newbandwidth是每个DataNode在平衡操作期间可以使用的最大网络带宽量，以每秒字节数为单位。

比如：hdfs dfsadmin -setBalancerBandwidth 104857600（100M）

• Step2：运行balancer

默认参数运行：hdfs balancer

指定阈值运行：hdfs balancer -threshold 5 Balancer将以阈值5％运行（默认值10%）。

这意味着程序将确保每个DataNode上的磁盘使用量与群集中的总体使用量相差不超过5％。例如，如果集群中所有DataNode的总体使用率是集群磁盘总存储容量的40％，则程序将确保每个DataNode的磁盘使用率在该DataNode磁盘存储容量的35％至45％之间。

3.3 磁盘均衡器

背景：

• 相比较于个人PC，服务器一般可以通过挂载多块磁盘来扩大单机的存储能力。
• 在Hadoop HDFS中，DataNode负责最终数据block的存储，在所在机器上的磁盘之间分配数据块。当写入新block时，DataNodes将根据选择策略（循环策略或可用空间策略）来选择block的磁盘（卷）。
• 循环策略：它将新block均匀分布在可用磁盘上。默认此策略。
• 可用空间策略：此策略将数据写入具有更多可用空间（按百分比）的磁盘。
• 在长期运行的群集中采用循环策略时，DataNode有时会不均匀地填充其存储目录（磁盘/卷），从而导致某些磁盘已满而其他磁盘却很少使用的情况。发生这种情况的原因可能是由于大量的写入和删除操作，也可能是由于更换了磁盘。
• 另外，如果我们使用基于可用空间的选择策略，则每个新写入将进入新添加的空磁盘，从而使该期间的其他磁盘处于空闲状态。这将在新磁盘上创建瓶颈。
• 因此，需要一种Intra DataNode Balancing（DataNode内数据块的均匀分布）来解决Intra-DataNode偏斜（磁盘上块的不均匀分布），这种偏斜是由于磁盘更换或随机写入和删除而发生的。
• 因此，Hadoop 3.0中引入了一个名为Disk Balancer的工具，该工具专注于在DataNode内分发数据。

概述：HDFS disk balancer是Hadoop 3中引入的命令行工具，用于平衡DataNode中的数据在磁盘之间分布不均匀问题。 这里要特别注意，HDFS diskbalancer与HDFS Balancer是不同的：

• HDFS disk balancer针对给定的DataNode进行操作，并将块从一个磁盘移动到另一个磁盘,是DataNode内部数据在不同磁盘间平衡；
• HDFS Balancer平衡了DataNode节点之间的分布。

3.3.1 HDFS Disk Balancer功能

功能1-数据传播报告

• 为了衡量集群中哪些计算机遭受数据分布不均的影响，磁盘平衡器定义了Volume Data Density metric（卷/磁盘数据密度度量标准）和Node Data Density metric（节点数据密度度量标准）。
  • 卷（磁盘）数据密度：比较同台机器上不同卷之间的数据分布情况。
  • 节点数据密度：比较的是不同机器之间的。

计算方式：

• Volume data density metric（卷数据密度）计算：

volumeData Density的正值表示磁盘未充分利用，而负值表示磁盘相对于当前理想存储目标的利用率过高。

假设有一台具有四个卷/磁盘的计算机-Disk1，Disk2，Disk3，Disk4，各个磁盘使用情况：

	Disk1	Disk2	Disk3	Disk4
capacity	200 GB	300 GB	350 GB	500 GB
dfsUsed	100 GB	76 GB	300 GB	475 GB
dfsUsedRatio	0.5	0.25	0.85	0.95
volumeDataDensity	0.20	0.45	-0.15	-0.24

Total Capacity= 200 + 300 + 350 + 500 = 1350 GB
Total Used= 100 + 76 + 300 + 475 = 951 GB
因此，每个卷/磁盘上的理想存储为：
Ideal Storage = Total Used ÷ Total Capacity= 951÷1350 = 0.70 
也就是每个磁盘应该保持在70%理想存储容量。
Volume Data Density = Ideal Storage – dfs Used Ratio
比如Disk1的卷数据密度 = 0.70 - 0.50 = 0.20。其他以此类推。

• Node Data Density metric计算过程

Node Data Density（节点数据密度）= 该节点上所有volume data density卷（磁盘）数据密度绝对值的总和。

​ 上述例子中的节点数据密度=|0.20|+|0.45|+|-0.15|+|-0.24|=1.04

​ 较低的node Data Density值表示该机器节点具有较好的扩展性，而较高的值表示节点具有更倾斜的数据分布。

一旦有了volume Data Density和nodeData Density，就可以找到集群中数据分布倾斜的节点和机器上数据分步倾斜的磁盘。

功能2-磁盘平衡

当指定某个DataNode节点进行disk数据平衡，就可以先计算或读取当前的volume Data Density（磁卷数据密度）。

有了这些信息，我们可以轻松地确定哪些卷已超量配置，哪些卷已不足。

为了将数据从一个卷移动到DataNode中的另一个卷，Hadoop开发实现了基于RPC协议的Disk Balancer。

HDFS Disk Balancer开启：

• HDFS Disk Balancer通过创建计划进行操作，该计划是一组语句，描述应在两个磁盘之间移动多少数据，然后在DataNode上执行该组语句。计划包含多个移动步骤。计划中的每个移动步骤都具有目标磁盘，源磁盘的地址。移动步骤还具有要移动的字节数。该计划是针对可操作的DataNode执行的。
• 默认情况下，Hadoop群集上已经启用了Disk Balancer功能。通过在hdfs-site.xml中调整dfs.disk.balancer.enabled参数值，选择在Hadoop中是否启用磁盘平衡器。

HDFS Disk Balancer相关命令：

• plan计划

hdfs diskbalancer -plan <datanode>
-out  	#控制计划文件的输出位置
-bandwidth    #设置用于运行Disk Balancer的最大带宽.默认带宽10 MB/s.
-thresholdPercentage  #定义磁盘开始参与数据重新分配或平衡操作的值.默认的thresholdPercentage值为10％,
					#这意味着仅当磁盘包含的数据比理想存储值多10％或更少时,磁盘才用于平衡操作.
-maxerror      #它允许用户在中止移动步骤之前为两个磁盘之间的移动操作指定要忽略的错误数.
-v 	#详细模式,指定此选项将强制plan命令在stdout上显示计划的摘要.
-fs  	#此选项指定要使用的NameNode.如果未指定,则Disk Balancer将使用配置中的默认NameNode

• Execute执行

命令：hdfs diskbalancer -execute <JSON file path>
execute命令针对为其生成计划的DataNode执行计划。

• Query查询

命令：hdfs diskbalancer -query <datanode>
query命令从运行计划的DataNode获取HDFS磁盘平衡器的当前状态。

• Cancel取消

命令：hdfs diskbalancer -cancel <JSON file path>
hdfs diskbalancer -cancel planID node <nodename>
cancel命令取消运行计划。

• Report汇报

命令：hdfs diskbalancer -fs hdfs://nn_host:8020 -report

3.4 纠删码技术

背景：3副本策略弊端

• 为了提供容错能力，HDFS会根据replicationfactor（复制因子）在不同的DataNode上复制文件块。
• 默认复制因子为3（注意这里的3指的是1+2=3，不是额外3个），则原始块除外，还将有额外两个副本。每个副本使用100％的存储开销，因此导致200％的存储开销。这些副本也消耗其他资源，例如网络带宽。
• 在复制因子为N时，存在N-1个容错能力，但存储效率仅为1/N。

概述：

• 纠删码技术（Erasure coding）简称EC，是一种编码容错技术。最早用于通信行业，数据传输中的数据恢复。它通过对数据进行分块，然后计算出校验数据，使得各个部分的数据产生关联性。当一部分数据块丢失时，可以通过剩余的数据块和校验块计算出丢失的数据块。
• Hadoop 3.0 之后引入了纠删码技术（Erasure Coding），它可以提高50%以上的存储利用率，并且保证数据的可靠性。

3.4.1 Reed-Solomon（RS）码

• Reed-Solomon（RS）码是常用的一种纠删码，它有两个参数k和m，记为RS(k，m)。
• k个数据块组成一个向量被乘上一个生成矩阵（Generator Matrix）GT从而得到一个码字（codeword）向量，该向量由k个数据块（d0,d1…d3）和m个校验块（c0,c1）构成。
• 如果数据块丢失，可以用GT逆矩阵乘以码字向量来恢复出丢失的数据块。

3.4.2 Hadoop EC架构

为了支持纠删码，HDFS体系结构进行了一些更改调整。

• Namenode扩展

​ 条带化的HDFS文件在逻辑上由block group（块组）组成，每个块组包含一定数量的内部块。这允许在块组级别而不是块级别进行文件管理。

• 客户端扩展

​ 客户端的读写路径得到了增强，可以并行处理块组中的多个内部块。

• Datanode扩展

​ DataNode运行一个附加的ErasureCodingWorker（ECWorker）任务，以对失败的纠删编码块进行后台恢复。 NameNode检测到失败的EC块，然后NameNode选择一个DataNode进行恢复工作。

• 纠删编码策略

​ 为了适应异构的工作负载，允许HDFS群集中的文件和目录具有不同的复制和纠删码策略。纠删码策略封装了如何对文件进行编码/解码。默认情况下启用RS-6-3-1024k策略， RS表示编码器算法Reed-Solomon，6 、3中表示数据块和奇偶校验块的数量，1024k表示条带化单元的大小。

​ 目录上还支持默认的REPLICATION方案。它只能在目录上设置，以强制目录采用3倍复制方案，而不继承其祖先的纠删码策略。此策略可以使3x复制方案目录与纠删码目录交错。REPLICATION始终处于启用状态。

​ 此外也支持用户通过XML文件定义自己的EC策略，Hadoop conf目录中有一个名为user_ec_policies.xml.template的示例EC策略XML文件，用户可以参考该文件。

• Intel ISA-L

​ 英特尔ISA-L代表英特尔智能存储加速库。 ISA-L是针对存储应用程序而优化的低级功能的开源集合。它包括针对Intel AVX和AVX2指令集优化的快速块Reed-Solomon类型擦除代码。 HDFS纠删码可以利用ISA-L加速编码和解码计算。

3.4.3 Erasure Coding部署方式

• Step1：集群和硬件配置

​ 编码和解码工作会消耗HDFS客户端和DataNode上的额外CPU。

​ 纠删码文件也分布在整个机架上，以实现机架容错。这意味着在读写条带化文件时，大多数操作都是在机架上进行的。因此，网络带宽也非常重要。

​ 对于机架容错，拥有足够数量的机架也很重要，每个机架所容纳的块数不超过EC奇偶校验块的数。机架数量=（数据块+奇偶校验块）/奇偶校验块后取整。

​ 比如对于EC策略RS（6,3），这意味着最少3个机架（由（6 + 3）/ 3 = 3计算），理想情况下为9个或更多，以处理计划内和计划外的停机。对于机架数少于奇偶校验单元数的群集，HDFS无法维持机架容错能力，但仍将尝试在多个节点之间分布条带化文件以保留节点级容错能力。因此，建议设置具有类似数量的DataNode的机架。

• Step2：纠删码策略设置

​ 纠删码策略由参数dfs.namenode.ec.system.default.policy指定，默认是RS-6-3-1024k，其他策略默认是禁用的。

​ 可以通过hdfs ec[-enablePolicy -policy ]命令启用策略集。

• Step3：启用英特尔ISA-L（智能存储加速库）

默认RS编解码器的HDFS本机实现利用Intel ISA-L库来改善编码和解码计算。要启用和使用Intel ISA-L，需要执行三个步骤。

1. 建立ISA-L库；
2. 使用ISA-L支持构建Hadoop；
3. 使用-Dbundle.isal将isal.lib目录的内容复制到最终的tar文件中。使用tar文件部署Hadoop。确保ISA-L在HDFS客户端和DataNode上可用。

• Step4：EC命令

hdfs ec 
[-setPolicy -path <path> [-policy <policy>] [-replicate]]
#在指定路径的目录上设置擦除编码策略。
#path：HDFS中的目录。这是必填参数。设置策略仅影响新创建的文件，而不影响现有文件。
#policy：用于此目录下文件的擦除编码策略。默认RS-6-3-1024k策略。
#-replicate在目录上应用默认的REPLICATION方案，强制目录采用3x复制方案。replicate和-policy <policy>是可	选参数。不能同时指定它们。
[-getPolicy -path < path >]
#获取指定路径下文件或目录的擦除编码策略的详细信息。
[-unsetPolicy -path < path >]
#取消设置先前对目录上的setPolicy的调用所设置的擦除编码策略。如果该目录从祖先目录继承了擦除编码策略	，则unsetPolicy是no-op。在没有显式策略集的目录上取消策略将不会返回错误。
[-listPolicies]	#列出在HDFS中注册的所有（启用，禁用和删除）擦除编码策略。只有启用的策略才适合与	setPolicy命令一起使用。
[-addPolicies -policyFile <文件>]	#添加用户定义的擦除编码策略列表。
[-listCodecs]	#获取系统中支持的擦除编码编解码器和编码器的列表。
[-removePolicy -policy <policyName>]	#删除用户定义的擦除编码策略。
[-enablePolicy -policy <policyName>]	#启用擦除编码策略。
[-disablePolicy -policy <policyName>]	#禁用擦除编码策略。

4 HDFS动态节点管理

4.1 节点上线、动态扩容

节点上线：已有HDFS集群容量已不能满足存储数据的需求，需要在原有集群基础上动态添加新的DataNode节点。俗称动态扩容、节点服役。

step1：新机器基础环境准备:

• 主机名、IP

• Hosts映射

• 防火墙、时间同步

• SSH免密登录

• JDK环境

Step2：Hadoop配置

• 修改namenode节点workers配置文件，增加新节点主机名，便于后续一键启停。
• 从namenode节点复制hadoop安装包到新节点，注意不包括hadoop.tmp.dir指定的数据存储目录。
• 新机器上配置hadoop环境变量

Step3：手动启动DataNode进程

Step4：Web页面查看情况

Step5：DataNode负载均衡服务

4.2 动态缩容、节点下线

节点下线：服务器需要进行退役更换，需要在当下的集群中停止某些机器上datanode的服务.俗称动态缩容、节点退役。

Step1：添加退役节点

• 在namenode机器的hdfs-site.xml配置文件中需要提前配置dfs.hosts.exclude属性，该属性指向的文件就是所谓的黑名单列表，会被namenode排除在集群之外。如果文件内容为空，则意味着不禁止任何机器。
• 提前配置好的目的是让namenode启动的时候就能加载到该属性，只不过还没有指定任何机器。否则就需要重启namenode才能加载，因此这样的操作我们称之为具有前瞻性的操作。

<property>
<name>dfs.hosts.exclude</name>
<value>/export/server/hadoop-3.1.4/etc/hadoop/excludes</value>
</property>

• 编辑dfs.hosts.exclude属性指向的excludes文件，添加需要退役的主机名称。
• 注意：如果副本数是3，服役的节点小于等于3，是不能退役成功的，需要修改副本数后才能退役。

Step2：刷新集群

• 在namenode所在的机器刷新节点：hdfs dfsadmin-refreshNodes
• 等待退役节点状态为decommissioned（所有块已经复制完成）

Step3：手动关闭DataNode进程

hdfs --daemon stop datanode

Step4：DataNode负载均衡服务

如果需要可以对已有的HDFS集群进行负载均衡服务。

hdfs balancer -threshold 5

4.3 黑白名单机制

白名单

• 所谓的白名单指的是允许哪些机器加入到当前的HDFS集群中，是一种准入机制。
• 白名单由dfs.hosts参数指定，该参数位于hdfs-site.xml。默认值为空。
• dfs.hosts指向文件，该文件包含允许连接到namenode的主机列表。必须指定文件的完整路径名。如果该值为空，则允许所有主机准入。

黑名单

• 所谓的黑名单指的是禁止哪些机器加入到当前的HDFS集群中，是一种禁入机制。
• 黑名单由dfs.hosts.exclude参数指定，该参数位于hdfs-site.xml。默认值为空。
• dfs.hosts.exclude指向文件，该文件包含不允许连接到名称节点的主机列表。必须指定文件的完整路径名。如果该值为空，则不禁止任何主机加入。

5 HDFS HA高可用机制

5.1 高可用（HA）的背景知识

单点故障：（英语：single point of failure，缩写SPOF）是指系统中某一点一旦失效，就会让整个系统无法运作，换句话说，单点故障即会整体故障。

如何解决单点故障：

• 解决单点故障，实现系统服务高可用的核心并不是让故障永不发生，而是让故障的发生对业务的影响降到最小。因为软硬件故障是难以避免的问题。
• 当下企业中成熟的做法就是给单点故障设置备份，形成主备架构。通俗描述就是当主挂掉，备份顶上，短暂的中断之后继续提供服务。
• 常见的是一主一备架构，当然也可以一主多备。备份越多，容错能力越强，与此同时，冗余也越大，浪费资源。

主备集群角色：

• Active：主角色。活跃的角色，代表正在对外提供服务的角色服务。任意时间有且只有一个active对外提供服务。
• Standby：备份角色。需要和主角色保持数据、状态同步，并且时刻准备切换成主角色（当主角色挂掉或者出现故障时），对外提供服务，保持服务的可用性。

高可用：

• 高可用性（英语：high availability，缩写为 HA），IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统意味着系统服务可以更长时间运行，通常通过提高系统的容错能力来实现。
• 高可用性或者高可靠度的系统不会希望有单点故障造成整体故障的情形。一般可以通过冗余的方式增加多个相同机能的部件，只要这些部件没有同时失效，系统（或至少部分系统）仍可运作，这会让可靠度提高。

集群可用性评判标准（x个9）：

• 在系统的高可用性里有个衡量其可靠性的标准——X个9，这个X是代表数字3-5。

• X个9表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比。

  • 3个9：(1-99.9%)36524=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
  • 4个9：(1-99.99%)36524=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
  • 5个9：(1-99.999%)36524*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

• 可以看出，9越多，系统的可靠性越强，能够容忍的业务中断时间越少，但是要付出的成本更高。

HA系统设计核心问题：

• 脑裂问题

脑裂(split-brain)是指“大脑分裂”,本是医学名词。

在HA集群中，脑裂指的是当联系主备节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点。由于相互失去了联系，主备节点之间像"裂脑人"一样，使得整个集群处于混乱状态。

脑裂的严重后果：

1）集群无主：都认为对方是状态好的，自己是备份角色，后果是无服务；

2）集群多主：都认为对方是故障的，自己是主角色。相互争抢共享资源，结果会导致系统混乱，数据损坏。此外对于客户端访问也是一头雾水，找谁呢？

避免脑裂问题的核心是：保持任意时刻系统有且只有一个主角色提供服务。

• 数据状态同步问题

​ 主备切换保证服务持续可用性的前提是主备节点之间的状态、数据是一致的，或者说准一致的。如果说备用的节点和主节点之间的数据差距过大，即使完成了主备切换的动作，那也是没有意义的。

​ 数据同步常见做法是：通过日志重演操作记录。主角色正常提供服务，发生的事务性操作通过日志记录，备用角色读取日志重演操作。

5.2 NAMENODE单点故障问题

概述：

• 在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。
• 每个群集只有一个NameNode，如果NameNode进程不可用，则整个HDFS群集不可用。

解决：

• 在同一群集中运行两个（从3.0.0起，支持超过两个）冗余NameNode。形成主备架构。
• 这样可以在机器崩溃的情况下快速故障转移到新的NameNode，或者出于计划维护的目的由管理员发起的正常故障转移。

5.3 HDFS HA解决方案–QJM

Quorum Journal Manager介绍：

• QJM全称Quorum Journal Manager（仲裁日志管理器），是Hadoop官方推荐的HDFS HA解决方案之一。
• 使用zookeeper中ZKFC来实现主备切换；
• 使用Journal Node（JN）集群实现edits log的共享以达到数据同步的目的。

主备切换、脑裂问题解决：

ZK FailoverController（ZKFC）是一个ZooKeeper客户端。主要职责：

• 监视和管理NameNode健康状态

ZKFC通过命令监视的NameNode节点及机器的健康状态。

• 维持和ZK集群联系

如果本地NameNode运行状况良好，并且ZKFC看到当前没有其他节点持有锁znode，它将自己尝试获取该锁。如果成功，则表明它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于Active状态。如果已经有其他节点持有锁，zkfc选举失败，则会对该节点注册监听，等待下次继续选举。

• 故障转移过程也就是俗称的主备角色切换的过程，切换过程中最怕的就是脑裂的发生。因此需要Fencing机制来避免，将先前的Active节点隔离，然后将Standby转换为Active状态。
• Hadoop公共库中对外提供了两种Fenching实现，分别是sshfence和shellfence（缺省实现）。

sshfence是指通过ssh登陆目标节点上，使用命令fuser将进程杀死（通过tcp端口号定位进程pid，该方法比jps命令更准确）；

shellfence是指执行一个用户事先定义的shell命令（脚本）完成隔离。

主备数据状态同步问题解决：

• Journal Node（JN）集群是轻量级分布式系统，主要用于高速读写数据、存储数据。
• 通常使用2N+1台JournalNode存储共享Edits Log（编辑日志）。–底层类似于zk的分布式一致性算法。
• 任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录edits log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取JN里面的edits log，然后重演操作记录同步到自己的目录镜像树里面。

5.4 HA集群搭建

Step1：集群基础环境准备

1.修改Linux主机名 /etc/hostname

2.修改IP /etc/sysconfig/network-scripts/ifcfg-ens33

3.修改主机名和IP的映射关系 /etc/hosts

4.关闭防火墙

5.ssh免登陆

6.安装JDK，配置环境变量等 /etc/profile

7.集群时间同步

8.配置主备NN之间的互相免密登录

Step2：HA集群规划

机器	运行角色
node1.itcast.cn	namenode zkfc datanode zookeeper journal node
node2.itcast.cn	namenode zkfc datanode zookeeper journal node
node3.itcast.cn	datanode zookeeper journal node

Step3：上传安装包、配置环境变量（node1）

Step4：修改Hadoop配置文件

Step5：集群同步安装包

Step6：HA集群初始化

Step7：HA集群启动

6 HDFS Federation联邦机制

6.1 当前HDFS体系架构

当前的HDFS架构有两个主要的层：

• 命名空间（namespace）

由文件，块和目录组成的统一抽象的目录树结构。由namenode根据用户操作实时维护树结构。

• 块存储层（Block Storage）包括两个部分：
  • 块管理： NameNode执行块管理。块管理通过处理注册和定期心跳来提供DataNode群集成员身份。它处理块报告并支持与块相关的操作，如创建，删除，修改或获取块位置。它还维护块的位置，副本位置。为未复制的块管理块复制，并在已复制的块中删除。
  • 存储： DataNode通过在本地文件系统上存储块并提供读/写访问权限来管理存储空间。

局限性：

• DataNode磁盘存储空间不够增加节点，NameNode内存不够是否可以无限扩容。思考一下：一种是DataNode横向扩展机器增加节点，一种是纵向扩展单机加内存。
• 由于名称空间和存储层的紧密耦合，NameNode的替代实现很困难。这限制了其他服务直接使用块存储。NameNode成了唯一入口。
• 文件系统的操作还限于NameNode一次处理的任务数。因此，群集的性能取决于NameNode吞吐量。
• 同样，由于使用单个名称空间，因此使用群集的占用者组织之间没有隔离。

6.2 HDFS Federation架构

概述：

• Federation中文意思为联邦,联盟，是NameNode之间的Federation,也就是集群中会有多个NameNode。多个NameNode的情况意味着有多个namespace。注意，这区别于HA模式下的多NameNode，HA中它们是拥有着同一个namespace。
• Federation体系中多个namenode之间相互独立且不需要互相协调，各自分工，管理自己的区域。每个DataNode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。

好处

• 命名空间可伸缩性

  使用Federation，可以水平扩展名称空间。这对大型群集或包含太多小文件的群集有利，因为向群集添加了更多的NameNode。

• 性能

  由于文件系统操作不受单个NameNode吞吐量的限制，因此可以提高文件系统的性能。

• 隔离

  由于有多个名称空间，它可以为使用群集的占用者组织提供隔离。

7 HDFS集群滚动升级

7.1 HDFS集群滚动升级

概述：

• 在Hadoop v2中，HDFS支持NameNode高可用（HA）。使得不停机升级HDFS变得可行。请注意，仅从Hadoop-2.4.0起才支持滚动升级。
• 因此为了在不停机的情况下升级HDFS群集，必须使用HA设置群集。
• 在HA群集中，有两个或多个NameNode（NN），许多DataNode（DN），一些JournalNode（JN）和一些ZooKeeperNode（ZKN）。
• JN相对稳定，在大多数情况下，升级HDFS时不需要升级。
• 滚动升级过程中，仅针对NNs和DNs，JNS和ZKNs都没有。升级JN和ZKN可能会导致群集停机。

7.1.1 不停机滚动升级–非联邦HA集群

假设有两个名称节点NN1和NN2，其中NN1和NN2分别处于Active和StandBy状态。

• Step1:滚动升级准备

#创建一个新的fsimage文件用于回滚
hdfs dfsadmin -rollingUpgrade prepare
#不断运行下面命令检查回滚fsimage是否创建完毕。
#如果显示Proceeding with Rolling Upgrade表示已经完成。
hdfs dfsadmin -rollingUpgrade query

• Step2:升级Active NN和Standbys NN

#关闭NN2：
hdfs --daemon stop namenode
#升级启动NN2:
hdfs --daemon start namenode -rollingUpgrade started
#做一次failover切换,使得NN2成为Active节点,NN1变为Standby节点。
#关闭NN1:
hdfs --daemon stop namenode
#升级启动NN1：
hdfs --daemon start namenode -rollingUpgrade started

• Step3:升级DN

#选择整体中的一小部分DataNode节点进行升级(比如按照DataNode所在的不同机架来筛选)。
#关闭升级所选的DN 其中IPC_PORT由参数dfs.datanode.ipc.address指定，默认9867。
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST：IPC_PORT> upgrade
#检查下线DataNode是否已经停止服务.如果还能得到节点信息,意味着此节点还未真正被关闭。
hdfs dfsadmin -getDatanodeInfo <DATANODE_HOST：IPC_PORT>
#启动DN节点。
hdfs --daemon start datanode
#对选中的所有DN节点执行以上步骤。
#重复上述步骤，直到升级群集中的所有DN节点。

• Step4:完成滚动升级

#完成滚动升级
hdfs dfsadmin -rollingUpgrade finalize

7.1.2 不停机滚动升级–联邦HA集群

• 联邦集群（federation）是拥有多namespace的集群。每个namespace对应一对主备NameNode节点。
• 上述这套集群就是俗称的联邦+HA集群。
• 联邦集群的升级过程与非联邦集群的升级过程比较相似,没有什么本质区别，只是需要为不同的namespace多重复执行几遍升级操作而已。

#1、在每个namespace下执行升级准备
hdfs dfsadmin -rollingUpgrade prepare
#2、升级每个namespace下的Active/Standby节点.
#2.1、关闭NN2：
hdfs --daemon stop namenode
#2.2、升级启动NN2:
hdfs --daemon start namenode -rollingUpgrade started
#2.3、做一次failover切换,使得NN2成为Active节点,NN1变为Standby节点。
#2.4、关闭NN1:
hdfs --daemon stop namenode
#2.5、升级启动NN1：
hdfs --daemon start namenode -rollingUpgrade started
#3、升级每个DataNode节点
#3.1、关闭升级所选的DN 其中IPC_PORT由参数dfs.datanode.ipc.address指定，默认9867。
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST：IPC_PORT> upgrade
#3.2、检查下线DataNode是否已经停止服务.如果还能得到节点信息,意味着此节点还未真正被关闭。
hdfs dfsadmin -getDatanodeInfo <DATANODE_HOST：IPC_PORT>
#3.3、启动DN节点。
hdfs --daemon start datanode
#4、升级过程执行完毕,在每个namespace下执行finalize确认命令.
hdfs dfsadmin -rollingUpgrade finalize

7.1.3 停机滚动升级–非HA集群

• 在升级的过程中,势必会存在服务短暂停止的时间,因为NameNode需要重启,而这段时间并没有备用节点可选.
• 整体过程同非联邦HA模式的4个步骤类似。不过步骤二的过程要略微修改：

#Step1:滚动升级准备
#Step2:升级NN和SNN
#1、关闭NN
hdfs --daemon stop namenode
#2、升级启动NN
hdfs --daemon start namenode -rollingUpgrade started
#3、停止SNN
hdfs --daemon stop secondarynamenode
#4、升级启动SNN
hdfs --daemon start secondarynamenode -rollingUpgrade started
#Step3:升级DN
#Step4:完成滚动升级
hdfs dfsadmin -rollingUpgrade finalize

7.2 HDFS集群降级和回滚

降级和回滚区别：

• 共同点:

  都会将版本退回到升级前的版本；

  在升级的finalize动作执行之后,将不允许再执行降级和回滚。

• 不同点:

  降级能支持rollling的方式,可以滚动降级,而回滚需要停止服务一段时间.

  降级过程只会将软件版本还原成升级前的,会保留用户现有的数据状态；

  而回滚则会将用户数据还原成升级前的状态模式，现有的数据状态不保存。

友情提示：升级慎重，降级、回滚更要慎重。

• 生产环境中，集群升级之前必须进行科学调研，评估升级后的版本跟现有业务的兼容性。
• 在测试环境下完整模拟升级流程，并且针对升级前集群状态进行备份，避免意外发生导致集群中断。
• 不要奢求升级失败时，通过回滚、降级等操作挽救集群。

HA集群降级（downgrade）操作：

• Step1：降级DataNode

#1.选中部分集合DataNode节点(可以按照机架进行区分)
#执行降级操作，其中IPC_PORT由参数dfs.datanode.ipc.address指定，默认9867。
hdfs dfsadmin -shutdownDatanode <DATANODE_HOST：IPC_PORT> upgrade
#执行命令检查节点是否完全停止
hdfs dfsadmin -getDatanodeInfo <DATANODE_HOST：IPC_PORT> 
#在选中集合内的其他DataNode节点上重复执行上述操作.
#2.在集群中所有的DataNode节点上重复执行1.的操作.

• Step2：降级Active NameNode和Standby NameNode

#停止并降级Standby NameNode.
#正常启动Standby NameNode.
#触发failover切换,使得主备角色对调
#停止并降级之前属于Active（现属于Standby的NameNode）
#正常启动作为Standby节点.

• Step3：降级操作的确认

#完成降级操作
hdfs dfsadmin -rollingUpgrade finalize

HA集群降级（downgrade）注意事项：

• 降级与升级在HA模式下有一个共同点

在操作NameNode时,都是先从Standby节点开始操作,等Standby节点升/降结束,做一次切换,使另外一个节点得以进行升/降操作.在全程中,始终保持一个Active节点对外提供服务。

• 降级过程NameNode与DataNode的操作和在升级时操作顺序正好相反

新版本一般在协议、API是兼容老版本的,如果先降级NN,那么则会造成DN是新版,NN是旧版。

新版DN中的许多协议将会在旧版NN中可能不兼容。

所以这里必须要先降级DN,然后再把服务端NN进行降级.看似简单的一次顺序颠倒,背后其实是有更深层的原因的.

• 联邦集群和非HA集群的降级操作与升级操作相对应，进行相应操作命令的替换即可。

集群回滚（rollback）操作：

注意事项：

Rollback不支持滚动操作的方式,在操作期间,它需要集群对外停止提供服务.

Rollback操作不仅会将软件版本退回到升级前的版本,还会将用户数据退回到升级前的状态.

回滚步骤：

#1.停止所有的NameNode和DataNode节点.
#2.在所有的节点机器上恢复升级前的软件版本.
#3.在NN1节点上执行-rollingUpgrade rollback命令来启动NN1,将NN1作为Active节点.
#4.在NN2上执行-bootstrapStandby命令并正常启动NN2,将NN2作为Standby节点.
#5.以-rollback参数启动所有的DataNode.