5_HDFS常用操作指令及管理命令（权限、节点上下线、balancer、disk balancer）

2020/12/16 [email protected]

HDFS常用操作指令及管理命令（权限、节点上下线、balancer、disk balancer）

一、HDFS权限

1.1、HDFS权限简介

​ Hdfs的权限管理分为2大部分：

• 第一部分类似于Linux的基本权限管理，也就是粗粒度将管理对象分为user、group和other三类去进行权限的管理。
• 第二部分是ACL方式的权限管理，也是更加细粒度的权限管理，可以精确控制到某个user与某个group具有的对应权限上。

1.2、HDFS基本权限管理

1.2.1、初始目录权限

​ 当我们创建文件或者目录的时候可以指定权限，没有指定的话就会使用默认的权限。

• 文件默认权限：666
• 目录默认权限：777

1.2.2、修改默认权限配置umask

​ 作用:客户端自己主宰文件或者目录的初始创建权限

​ 添加core-site.xml设置用户组默认权限

<property>
     <name>fs.permissions.umask-mode</name>
     <value>022</value>  
</property>

实际计算方式为：应用客户端配置的umask其实就是拿用户设置的权限减去上述umask权限，就得到文件或目录的最终权限了。如创建目录，默认777权限，然后减去umask权限022就等于755，即默认情况下owner拥有读写和可执行权限，owner所在group拥有读和可执行权限，other拥有读和可执行的权限

创建文件和目录时使用的umask，默认值为八进制022，每位数字对应了拥有者，组和其他用户。该值既可以使用八进制数字，如022，也可以使用符号，如u=rwx,g=r-x,o=r-x(对应022)

1.3、HDFSACL权限管理

​ 解决问题：假设，我们有一个HDFS目录/user/tao/xt-data，它目前的权限为drwxrwxr-x tao supergroup。我希望让另一个用户Hbase（不属于任何group）对该目录有rwx的权限，这可以使用ACL权限解决

1.3.1、开启HDFS ACL

​ 添加hdfs-site.xml文件的两个配置项为true：

<property>
    <name>dfs.permissions.enabled</name>
    <value>true</value>
</property>
<property>
  <name>dfs.namenode.acls.enabled</name>
  <value>true</value>
</property>

1.3.2、HDFS ACLshell命令

• 获取目录和文件的ACL信息

hdfs dfs -getfacl [-R] path

• 设置目录和文件的ACL信息

hdfs dfs -setfacl [-R] [-b|-k -m|-x <acl_spec> <path>]|[--set <acl_spec> <path>]
-R: 遍历路径里的所有文件。
-m: 添加新的权限来使用此ACL。不影响现有权限。
-b: 撤销除了基本用户和组权限以外的所有权限。
-k: 撤销默认的ACL设置。
-x: 只撤销指定的ACL。
<acl_spec>: 逗号分隔的ACL权限列表。
--set: 使用该选项指定的路径完全取代现有的ACL。之前的ACL将不再适用。

hdfs dfs -setfacl -R -m user:testUser:rw- /test/acl

• 显示文件和目录的访问控制列表（ACL），如果目录具有默认的AClL，则getFacl还会显示默认的ACL

hdfs dfs -getfacl [R] <path>
-R: 以递归方式列出所有文件和目录的ACL。

1.3.3、HDFS ACL权限实体类别

• 默认ACL必须包含所有最小要求的ACL项，包括文件拥有者项，文件所属的组项和其它用户项即：

user::rwx
group::r-x
other::r-x

• 每个ACL项由类型，可选的名称和权限字符串组成，它们之间使用冒号（:）如：

user::rw-
user:bruce:rwx         #effective:r--      
//bruce这个用户实际拥有读执行权限 (rwx, r--(mask) 两者执行‘相与’操作得到实际权限）
group::r-x                 #effective:r--
group:sales:rwx       #effective:r--
mask::r--
other::r--
	这组ACL访问列表中：文件的拥有者具有读写权限，文件所属的组具有读和执行的权限，其他用户具有读权限；除此之外，还有两个扩展的ACL项，分别为用户bruce和组sales，并都授予了读写执行的权限。
	最大有效权限mask：mask项是一个特殊的项，用于过滤授予所有命名用户，命名组及未命名组的权限，即过滤除文件拥有者和其他用户(other)之外的任何ACL项

• 默认访问控制列表：有目录可能拥有默认访问控制列表，当创建新文件或者子目录时，自动拷贝父辈的默认访问控制列表到自己的访问控制列表中，新的子目录也拷贝父辈默认的访问控制列表到自己的默认访问控制列表中。这样，当创建子目录时默认ACL将沿着文件系统树被任意深层次地拷贝。

user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:bruce:rwx     #effective:r-x     //有效权限，rwx r-x‘相与’操作后得到
default:group::r-x
default:group:sales:rwx    #effective:r-x
default:mask::r-x
default:other::r-x

1.3.4、HDFS ACL权限生效的算法规则

• 如果是owner，则取owner的权限
• 如果针对用户设置了ACL，则用户的ACL生效
• 如果用户在组里，则取各组ACL的并集
• 其他情况，取other的权限
• default权限：设置default之后，对新添加的文件和目录生效，对于现有的文件和目录不生效。

如：目录A拥有default:user:bruce:rwx权限，则在目录A下创建目录B，则目录B拥有user:bruce:rwx，default:user:bruce:rwx权限

延伸话题：

前面讨论的ACL条目定义了文件/目录当前的访问权限，称为**访问ACLs（access ACLs）**，另一种类型叫做**默认ACLs（default ACL）**，它定义了当一个文件系统对象被创建时如何从父目录继承权限。只有目录可以被设置默认ACLs，**默认ACLs不会用于权限检查，仅用于权限继承**。

创建一个新的目录时，如果父目录设置了默认ACLs，则新目录会继承父目录的默认ACLs作为自己的访问ACLs，同时也作为自己的默认ACLs。新的文件则只会继承父目录的默认ACLs作为自己的访问ACLs。

从父目录默认ACLs继承来的权限并非最终的权限，由于在创建新的目录/文件时client一定会传给NameNode一个文件模式权限（见“传统的POSIX权限模型”一节说明3），两者的计算结果才是最终的权限。计算方式采用**与运算**，即取继承的ACLs中某类权限与模式权限中对应类别权限的交集。

二、节点上下线

​ 在维护Hadoop集群时，需要动态增加和删除datanode或者yarn管理节点，而不是停掉整个集群

2.1、黑名单白名单

​ 在hadoop 配置文件目录下的hdfs-site.xml文件中维护着集群【黑名单】【白名单】两个文件，如果没有的话需要在配置文件中添加这两个属性

<property>
  <!-- 白名单信息-->
  <name>dfs.hosts</name>
  <value>/home/hadoop/hadoop/etc/dfs.include</value>
</property>
<property>
  <!-- 黑名单信息-->
  <name>dfs.hosts.exclude</name>
  <value>/home/hadoop/hadoop/etc/dfs.exclude</value>
</property>

2.2、服役（添加）datanode节点

• 在/etc/hosts文件钟增加新增节点ip地址及节点名称对应关系
• 在/home/hadoop/hadoop/etc/dfs.include文件钟增加新节点名称/ip地址
• namenode上刷新新节点：hdfs dfsadmin -refreshNodes
• 在/home/hadoop/hadoop/etc/slaves文件中添加新增的节点名称（以便集群重启时，带上此节点）
• 通过webUI查看datanode的信息
• 在新节点上启动datanode进程：hadoop-daemon.sh start datanode

2.3、退役（删除）datanode节点

• 添加退役节点的ip到黑名单，不需要修改白名单
• 刷新namenode节点：hdfs dfsadmin -refreshNodes
• 查看webUI，该节点状态在decommisstion in progerss
• 稍后该节点状态变为decommissioned状态，说明数据转移工作完成。
• 在退役节点主机上停止datanode进程：hadoop -daemon.sh stop datanode
• 刷新namenode节点，查看所有datanode节点：hdfs dfsadmin -refreshNodes

当你下线一个datanode节点， 有可能该节点长时间处于Decommission In Progress 状态， 一直不能转变成Decommissioned。 请你用hadoop fsck / 检查下是否有些块少于指定的块数， 特别注意那些mapreduce的临时文件。 将这些删除， 并且从垃圾箱移除， 该节点就可以顺利下线。

三、balancer

3.1、概述

​ Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况，比如集群中添加新的数据节点。当HDFS出现不平衡状况的时候，将引发很多问题，比如MR程序无法很好地利用本地计算的优势，机器之间无法达到更好的网络带宽使用率，机器磁盘无法利用等等。可见，保证HDFS中的数据平衡是非常重要的。

3.2、原则

Hadoop的开发人员在开发Balancer程序的时候，遵循了以下几点原则：

• 在执行数据重分布的过程中，必须保证数据不能出现丢失，不能改变数据的备份数，不能改变每一个rack中所具备的block数量。

• 系统管理员可以通过一条命令启动数据重分布程序或者停止数据重分布程序。

• Block在移动的过程中，不能暂用过多的资源，如网络带宽。

• 数据重分布程序在执行的过程中，不能影响name node的正常工作。

3.3、流程

Rebalance程序作为一个独立的进程与name node进行分开执行。

• Rebalance Server从Name Node中获取所有的Data Node情况：每一个Data Node磁盘使用情况。

• Rebalance Server计算哪些机器需要将数据移动，哪些机器可以接受移动的数据。并且从Name Node中获取需要移动的数据分布情况。

• Rebalance Server计算出来可以将哪一台机器的block移动到另一台机器中去。

• 需要移动block的机器将数据移动的目的机器上去，同时删除自己机器上的block数据。

• Rebalance Server获取到本次数据移动的执行结果，并继续执行这个过程，一直没有数据可以移动或者HDFS集群以及达到了平衡的标准为止。

Hadoop现有的这种Balancer程序工作的方式在绝大多数情况中都是非常适合的。

3.4、命令

​ 在Hadoop中，包含一个Balancer程序，通过运行这个程序，可以使得HFDS集群达到一个平衡的状态，使用这个程序的命令

$[]:hdfs balancer -help
Usage: java Balancer
    [-policy <policy>]    the balancing policy: datanode or blockpool
    [-threshold <threshold>]    Percentage of disk capacity
    [-exclude [-f <hosts-file> | comma-sperated list of hosts]]    Excludes the specified datanodes.
    [-include [-f <hosts-file> | comma-sperated list of hosts]]    Includes only the specified datanodes.

-threshold
某datanode的使用率和整个集群使用率的百分比差值阈值，达到这个阈值就启动hdfs balancer，取值从1到100，不宜太小，因为在平衡过程中也有数据写入，太小无法达到平衡
-policy
分为blockpool和datanode，前者是block pool级别的平衡后者是datanode级别的平衡
-exclude
不为空，则不在这些机器上进行平衡
-include
不为空，则仅在这些机器上进行平衡
-idleiterations  最大迭代次数

example
bin/start-balancer.sh	//start the balancer with a default threshold of 10%  
bin/start-balancer.sh-threshold 5//start the balancer with a default threshold of 5% 
bin/start-balancer.sh -t 10
bin/stop-balancer.sh

​ 这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果机器与机器之间磁盘使用率偏差小于10%，那么我们就认为HDFS集群已经达到了平衡的状态。

​ 由于HDFS需要启动单独的Rebalance Server来执行Rebalance操作，所以尽量不要在NameNode上执行start-balancer.sh，而是找一台比较空闲的机器。

3.5、调优

​ -threshold默认设置为10，参数取值范围0-100，参数含义：判断集群是否平衡的目标参数，每一个 datanode 存储使用率和集群总存储使用率的差值都应该小于这个阀值 ，理论上，该参数设置的越小，整个集群就越平衡，但是在线上环境中，hadoop集群在进行balance时，还在并发的进行数据的写入和删除，所以有可能无法到达设定的平衡参数值

​ 修改dfs.datanode.balance.bandwidthPerSec = 31457280 ,指定DataNode用于balancer的带宽为30MB，这个示情况而定，如果交换机性能好点的，完全可以设定为50MB，单位是Byte，如果机器的网卡和交换机的带宽有限，可以适当降低该速度，默认是1048576(1MB)

​ 修改dfs.datanode.balance.max.concurrent.moves = 50，指定DataNode上同时用于balance待移动block的最大线程个数，这个值默认是5

​ 其他参数

dfs.balancer.moverThreads
用于执行block移动的线程池大小，默认1000
dfs.balancer.max-size-to-move
每次balance进行迭代的过程最大移动数据量，默认10737418240(10GB)
dfs.balancer.getBlocks.size
获取block的数量，默认2147483648(2GB)
dfs.balancer.getBlocks.minblock-size
用来平衡的最小block大小，默认10485760（10MB）

四、disk balancer

4.1、概述

​ Hadoop集群使用久了,各个节点上的数据会变得不均衡,多的达到70,80%,少的就10,20%.面对这种场景,我们的办法一般就是用HDFS自带的Balancer工具对其进行数据平衡.但有的时候,你会发现尽管节点间数据平衡了,但是节点内各个磁盘块的数据出现了不平衡的现象.这可是Balancer工具所干不了的事情.通过这个场景,我们引入本文的一个话题点:HDFS节点内数据平衡

​ 如果磁盘间数据不均衡现象确实出现了,它会给我们造成什么影响呢?从HDFS的读写层面来对这个现象做一个分析.这里归纳出了以下2点:

• 磁盘间数据不均衡间接引发了磁盘IO压力的不同:HDFS上的数据访问频率是很高的,这就会涉及到大量读写磁盘的操作,数据多的盘自然的就会有更高频率的访问操作.如果一块盘的IO操作非常密集的话,势必会对它的读写性能造成影响.
• 高使用率磁盘导致节点可选存储目录减少:HDFS在写Block数据的时候,会挑选剩余可用空间满足待写Block的大小的情况下时,才会进行挑选,如果高使用率磁盘目录过多,会导致这样的候选块变少.所以这方面其实偏向的是对HDFS的影响.

传统解决磁盘间数据不均衡方案

• 节点下线再上线.将节点内数据不均衡的机器进行Decommision下线操作,下线之后再次上线.上线之后相当于是一个全新的节点了,数据也将会重新存储到各个盘上.这种做法给人感觉会比较暴力,当集群规模比较小的时候,代价太高,此时下线一个节点会对集群服务造成不小的影响.

• 人工移动部分数据block存储目录.此方案比方案一更加灵活一些,但是数据目录的移动要保证准确性,否则会造成移动完目录后数据找不到的现象.下面举一个实际的例子,比如我们想将磁盘1上的数据挪到磁盘2上.现有磁盘1的待移动存储目录如下:

  /data/1/dfs/dn/ current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/ finalized/subdir0/subdir1/

  我移动到目标盘上的路径应该维持这样的路径格式不变,只变化磁盘所在的目录,目标路径如下:

  /data/2/dfs/dn/current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/finalized/subdir0/subdir1/

  如果上述目录结构出现变化,就会造成HDFS找不到此数据块的情况.

4.2、设计

​ Balancer的核心点在于数据的平衡,数据平衡好就OK了.而DiskBalancer在设计的时候提出了2点目标:

• Data Spread Report.数据分布式的汇报.这是一个report汇报的功能.也就是说,DiskBalancer工具能支持各个节点汇报磁盘块使用情况的功能,通过这个功能我可以了解到目前集群内使用率TopN的节点磁盘.
• Disk Balancing.第二点才是磁盘数据的平衡.但是在磁盘内数据平衡的时候,要考虑到各个磁盘storageType的不同,因为之前提到过HDFS的异构存储,不同盘可能存储介质会不同,目前DiskBalancer不支持跨存储介质的数据转移,所以目前都是要求在一个storageType下的.

4.3、架构

​ DiskBalancer的架构设计.DiskBalancer的核心架构思想分为三个部分

4.3.1Discover

​ 通过计算各个节点内的磁盘使用情况,然后得出需要数据平衡的磁盘列表.这里会通过Volume Data Density（磁盘使用密度）的概念作为一个评判的标准,这个标准值将会以节点总使用率作为比较值.举个例子,如果一个节点,总使用率为75%,就是0.75,其中A盘使用率0.5(50%),那么A盘的volumeDataDensity密度值就等于0.75-0.5=0.25.同理,如果超出的话,则密度值将会为负数.于是我们可以用节点内各个盘的volumeDataDensity的绝对值来判断此节点内磁盘间数据的平衡情况,如果总的绝对值的和越大,说明数据越不平衡,这有点类似于方差的概念.Discover阶段将会用到如下的连接器对象:

• DBNameNodeConnector
• sonConnector
• NullConnector

其中第一个对象会调用到Balancer包下NameNodeConnector对象,以此来读取集群节点,磁盘数据情况

4.3.2、Plan

​ 拿到上一阶段的汇报结果数据之后,将会进行执行计划的生成.Plan并不是一个最小的执行单元,它的内部由各个Step组成.Step中会指定好源,目标磁盘.这里的磁盘对象是一层经过包装的对象:DiskBalancerVolume,并不是原来的FsVolume.这里顺便提一下DiskBalancer中对磁盘节点等概念的转化:

• 1.DiskBalancerCluster.通过此对象可以,读取到集群中的节点信息,这里的节点信息以DiskBalancerDataNode的方式所呈现.
• 2.DiskBalancerDataNode.此对象代表的是一个包装好后的DataNode.
• 3.DiskBalancerVolume和DiskBalancerVolumeSet.DataNode磁盘对象以及磁盘对象集合.DiskBalancerVolumeSet内的磁盘存储目录类型需要是同种StorageType.

4.3.3、Execute

​ 最后一部分是执行阶段,所有的plan计划生成好了之后,就到了执行阶段.这些计划会被提交到各自的DataNode上,然后在DiskBalancer类中进行执行.DiskBalancer类中有专门的类对象来做磁盘间数据平衡的工作,这个类名称叫做DiskBalancerMover.在磁盘间数据平衡的过程中,高使用率的磁盘会移动数据块到相对低使用率的磁盘,等到满足一定阈值关系的情况下时,DiskBalancer会渐渐地退出.在DiskBalancer的执行阶段,有以下几点需要注意:

• 1.带宽的限制.DiskBalancer中同样可以支持带宽的限制,默认是10M,通过配置项dfs.disk.balancer.max.disk.throughputInMBperSec进行控制.
• 2.失败次数的限制.DiskBalancer中会存在失败次数的控制.在拷贝block数据块的时候,出现IOException异常,会进行失败次数的累加计数,如果超出最大容忍值,DiskBalancer也会退出.
• 3.数据平衡阈值控制.DiskBalancer中可以提供一个磁盘间数据的平衡阈值,以此作为是否需要继续平衡数据的标准,配置项为dfs.disk.balancer.block.tolerance.percent.

4.4、命令

hdfs-site.xml:支持diskBalancer
<property>
  <name>dfs.disk.balancer.enabled</name>
  <value>true</value>
</property>

• DiskBalancer内部提供了许多类别的命令操作,比如下面的查询命令:

hdfs diskbalancer -query node101

• 执行相应的plan命令来生成plan计划文件.

hdfs diskbalancer (-uri hdfs://mycluster) -plan node101

• 用生成好后的json文件进行DiskBalancer的执行

hdfs diskbalancer -execute /system/diskbalancer/nodename.plan.json111

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EBmktQin-1614602637443)(C:\Users\19701\AppData\Roaming\Typora\typora-user-images\1608111190427.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NZsDK5jn-1614602637445)(C:\Users\19701\AppData\Roaming\Typora\typora-user-images\1608111108157.png)]

• 发现执行了错误的plan,可以通过cancel命令进行清除:

hdfs diskbalancer -cancel /system/diskbalancer/nodename.plan.json111

或

hdfs diskbalancer -cancel <planID> -node <nodename>111

​ 在DiskBalancer中会涉及到比较多的object-json的关系转换,所以会看到一些带.json后缀的文件

• 结束以及检查

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t6C0TA7k-1614602637446)(C:\Users\19701\AppData\Roaming\Typora\typora-user-images\1608111152543.png)]

存中…(img-EBmktQin-1614602637443)]

[外链图片转存中…(img-NZsDK5jn-1614602637445)]

• 发现执行了错误的plan,可以通过cancel命令进行清除:

hdfs diskbalancer -cancel /system/diskbalancer/nodename.plan.json111

或

hdfs diskbalancer -cancel <planID> -node <nodename>111

​ 在DiskBalancer中会涉及到比较多的object-json的关系转换,所以会看到一些带.json后缀的文件

• 结束以及检查

[外链图片转存中…(img-t6C0TA7k-1614602637446)]