本文主要通过ranger在hdfs acl中的应用以及原理介绍一下ranger的使用,另外介绍一下实际使用过程中碰到的问题。

上篇文章回顾:

目前公司内部大多通过数据工场来管理hdfs上的数据,工场开发团队和hdfs、yarn的SRE同学也配合紧密。由于涉及到管理数据,那么不得不说到权限控制的问题。

接触过hadoop的同学都应该了解hdfs上数据的权限类似linux中的权限,分为r、w、x三种权限。数据工场中也提供了各个表的数据权限的访问申请,底层通过java api去设置hdfs的acl,具体的每张表有访问权限的详情,但是缺少整体的供管理者预览的权限展示。

另外有一些没有在数据工场管理的目录,需要配置acl的话就需要通知SRE去手动添加或者删除。ranger一方面整体可以控制集群的acl,管理者在页面中就可以配置相关的权限,同时也提供了直观的权限展示。当然,不仅仅是hdfs目录的acl,包括hive、hbase、yarn、storm这些大数据生态的服务,都可以通过ranger来控制权限。

首先看一下ranger登录后的整体页面:

这里就是当前ranger可以进行权限控制的各个组件,每点开一个组件都可以编辑,比如hdfs,点开后就是如下配置界面:

上图主要配置的是namenode的地址,可以把这步骤配置叫做service配置,service配置完毕后,可以配置policy,也就是具体的针对某个集群的目录权限控制策略,如下图所示:

定义policy的名字(Policy Name)、定义需要控制权限的路径(Resource Path)、定义user或者group的访问权限(这里的uesr和group是hdfs上的user和group)。add之后就生成了一条完整的访问策略。在hdfs层面就完成了权限控制。

总结来看在ranger控制台,可以完成如下操作:

(1)service manager:目前支持hdfs、yarn、hbase、hive、storm等服务的管理

(2)service:通过某个service manager可以创建一个service,如hdfs服务,可以根据不同集群创建不同的service从而管理不同的集群

(3)policy:具体的权限控制策略,在service的基础上建立策略来控制权限

(4)audit:审计。包括用户登录情况和触发policy记录

(5)settings:可以手动增加和删除用户(安装了usersync插件后,这里的用户会自动更新同步namenode上的用户)

ranger的权限控制离不开各项plugin的使用。在安装初始,编译完代码之后会生成很多plugin,如admin、usersync、hdfs、yarn等。

(1)admin插件是用作web页面的生成,需要注意的是admin配置文件中的mysql配置需要能够创建用户的权限,或者填写的mysql的用户名密码已经地址在mysql的user表中存在

(2)usersync插件用于同步namenode上的用户至ranger中,需要启动在namenode节点上(访问集群的用户必须在namenode本地机器上存在这个用户)

(3)剩下插件就是上面提到的各个组件的控制访问需要用到的插件。文件格式类似ranger-{$version}-{$pluginName}.tar.gz。解压这些文件到各个服务对应的master节点进行安装(解压后会有setup.sh文件,运行文件进行安装),同时重新启动master服务即可完成

hdfs本身自带了权限控制,在配置文件中dfs.namenode.inode.attributes.provider.class默认值是空,在使用ranger进行权限控制的时候,需要将此项设置成org.apache.ranger.authorization.hadoop.RangerHdfsAuthorizer。

ranger控制权限主要是通过启动插件时候生成的配置文件以及插件自带的jar包来进行(plugin配置中有说明plugin的安装),会将jar包放到hadoop安装目录的lib目录下,将xml配置文件放到hadoop安装目录的etc/hadoop目录下9与hdfs-site.xml这些文件在同一路径下)。

且ranger控制的权限在hdfs自带的权限控制之上,也就是启动了ranger控制权限之后,用户访问hdfs的时候会先通过ranger的认证,如果发现没有权限,直接拒绝访问;如果有权限,之后仍然会去通过hdfs自带的权限控制去判断是否有访问权限,所以不用担心ranger的权限控制会覆盖原有的已经设置的权限。

在低版本的ranger中,元数据可以通过配置到mysql中存储,较新版本(0.5)以后取消了mysql的配置,统一将元数据存储到了solr中。solr是一个高性能的、基于Lucene的全文搜索服务器,它也经常被拿来和现今流行的elasticsearch做比较。一般来说,solr在实时搜索逊于es,且在数据量增大的时候,solr的查询效率降低,但是在对单纯的已有的数据进行搜索时候,solar表现得更为突出,且solr支持多种数据格式,而es只支持json。

solr的安装很简单,直接下载solr-6.6.0.tar.gz解压即可。解压之后,cd到solr的bin目录下启动即可。

solr start -c  -s '/usr/local/solr/server/solr '-z zkaddress:port/solr要提前在zookeeper上建立 'solr' 这个znode才行,而后使用solr create -c {$collection}-rf 2(2个副本)创建collection。访问http://ip:8983/solr即可打开页面,可以在页面中执行查询操作。集群搭建的话,就是所有机器重复以上步骤。使用bin/post -c {$collection}  path/,其中collection是索引的名称;path/表示path路径下的文件,该命令表示将path下的所有文件标记为索引{$collection} 放到solr中去。

在使用的过程中也碰到过问题,在使用ranger来进行yarn权限控制,控制用户提交任务权限的时候,ranger做得不够完善。在建立新的service的时候,填写入'YARN REST URL' 后,点击test connection,出现了问题,页面弹出框提示无法通过该url获得队列,查看ranger-admin运行日志也没有报错。翻看底层代码后发现,ranger在对yarn的支持上只支持了capacity调度,对fair调度没有支持。当将运行中的集群的调度改为capacity调度后,test connection成功。根本原因就是,resourcemanager的rest api(http://rm:port/ws/v1/cluster/scheduler)在不同的调度器下,得到的json文件不同,由于ranger底层单纯地只解析了capacity调度的json文件,没有解析fair调度的,所以出现了上述问题。需要针对fair调度下的rest api返回的json重新做解析。