HDFS ACLs测试

Hadoop从2.4开始支持HDFS层面的ACLs,新的ACLs功能包含了新的api,使用方法以及使用场景,本测试探查ACLs与我们原先基于主机与组的ACLs的结合,以及ACLs使用方法等。

一、配置增加

    为了使用ACLs,需要在NameNode增加一个配置选项,为:

  <property>

    <name>dfs.namenode.acls.enabled</name>

    <value>true</value>

  </property>

    默认是不开启的。


 

二、说明及使用场景

 

    hadoop原先使用的permission比较简单,采用的是类似Linux POSIX,即定义User,Group 和Other的权限。对文件或者目录做的任何操作都会进行permission check。permission check的步骤如下:

    1、检查用户是否是文件或者目录Owner,如果是检查权限,权限符合返回

    2、检查用户组是否在文件或者目录的Group中,用户组是通过原先的ACLs获得,如果在相应的组中,符合权限就返回

    3、最后检查Other的权限,如果满足就返回

    4、如果都不符合,抛出AccessControlException

 

    可以看到,以前的权限检查比较简单,相应的角色也只有User,Group,Other,对于稍微复杂的需求存在缺陷。比如:

    1、需要对某些文件对多个用户开放读权限,但是所有用户都不属于同一个组

    2、某些文件开放对多个组用户的访问权限,但是不同组中所有用户并不能归为一个大组等其它很多用处。所以新增的ACLs能够满足用户的大量对权限管理的需求。



 

二、API使用方法

 

    对于FSShell,新增了一些接口,我们这次关注的是有关ACLs的两个接口,分别是getfacl,setfacl,对应了获取ACLs和设置ACLs。

    (一)getfacl

    使用说明:获取目录或者文件的ACLs

    使用方法:hdfs dfs -getfacl [-R] path                  加-R 是递归的获得ACLs

    使用举例:

2
 

    (二)setfacl

    1、setfacl -b path

    移除所有的ACLs设置,只保留最基本的Permission信息


1
 

    2、setfacl -k path

    移除default ACLs,关于default ACLs,它不会直接作用于权限验证,但是对于设定了default ACLs的目录,它新创建的子目录和文件都会继承其default ACLs


3
 

    3、setfacl -mACLs path

    设定ACLs权限,可以根据user或者group进行设定

    比如对于文件owner为jiangyu2,可以设定housong可以具有读权限,峰超可以有读写权限,那么对于目录testacl,就需要做如下操作:


4
 

    4、setfacl -x ACLs path

    删除特定的ACLs权限,可以根据user或者group删除,其它user和group不受影响。

    比如对于3、中我们设定的ACLs权限,我们需要删除用户housong的ACLs权限,而保留其它的权限。


5
 

    5、setfacl —set ACLs path

    删除ACLs操作,并且用user,group,other权限来设定。

    例如:


6
 

三、现有ACLs与原有UserGroupMapping的兼容问题

    原有UserGroupMapping作用是当进行权限验证的时候由用户来获得组的映射信息,从而进行组的验证等。所有的User到Group的映射都继承自    GroupMappingServiceProvider类,默认的配置是采用JniBasedUnixGroupMapping,但是并不能满足我们对于gateway IP的管理等问题。所以后期由侯松开发了基于文件的用户与组的映射,就是现在的FileBasedGroupMapping,采用的是初始化及刷新时读取    文件从而获得用户与组的映射。

    新的ACLs对于原有的检查是兼容的,所以我们只需要移植原有的模块即可在2.4中重复利用。

 

 

四、ACLs测试

    (一)读测试

    本次测试测试ACLs对读操作的影响,通过设置不同的ACLs来测试读操作的速度,从而获得ACLs对性能的影响。

    测试步骤:

    1、通过SliveTest框架单纯写操作,灌数据,写入50000个文件

    2、不设置ACLs,同样使用SliveTest框架单纯读操作,记录各种结果

    3、将ACLs设置满,即设置32个规则,同样用SliveTest框架单纯读操作,记录各种结果

    4、将ACLs设置一半,即设置16个规则,同样用SliveTest框架测试,记录结果

 

 

    注:

    2-4的所有测试都需要测试5次,记录平均值。

    所有设置了ACLs的测试都采取与owner不同的账号去跑。

 

    测试结果:

    对于2、不设置ACLs的进行测试结果为:

 

 

 8

 

    对于3、设置32个规则,测试结果为:

10

 

 

 

 

 

    对于4、设置16个规则,测试结果为:

11

 

    注:操作数速度op/s较低的原因是SliveTest框架采用随机选取文件读,而随机选取文件有可能造成无法命中即选取读的文件不存在的情况,导致操作数即正常读取的操作数不大。

 

    结果汇总:从上面三张表中我们可以看出ACLs的设置对于用户来说影响不是很大,从代码层面分析,ACLs只在设置的INode上面进行配置,读取的时候同原来的permission check读取相同,只不过增加了一个hash映射,对于总的操作影响微乎其微。

    ACLs的影响主要在于对NameNode的内存影响,由于ACLs是缓存在内存中的,所以过多的ACLs设置会占用更多地内存。

 

 

    (二)内存影响

     新增加的ACLs会随着INode存储在内存中,所以设置ACLs会对NameNode的内存具有一定影响。

 

7

 

  

    AclEntry对应了所有的ACL属性,如果设置了ACLs,那么每个设置ACLs的INode都会又一个List,去保存AclEntry。

    粗略计算一下,每个AclEntry对像占用120个bytes(算上了String)。所有的AclEntryType占用了64个bytes,FsAction占用了96*8,AclEntryScope占用了32个bytes。所以最终计算后可以忽略剩余的属性,就计算1个AclEntry占据的内存为120个bytes。

    这样设置了32(设置满)ACLs的INode会增加4152 bytes。设置16个ACLs的INode会增加2232 bytes,设置3个ACLs的INode会增加672 bytes。

12


   以上是100,000 INode增加的内存,可以作为以后的参考。

 

 

五、ACLs的bug

    已知的bug是经过反复设置ACLs,最后会将ACLs设置超过32个最大值,导致NN从Journal恢复过程抛Exception,使得启动失败。

Print Friendly

jiang yu

Leave a Reply