一种Hadoop 集群限量使用模型
2016-06-29汪健蔡丽
汪健 蔡丽
摘要：Hadoop是当今主要的云平台之一，采用Kerberos作为身份认证机制实现单点登录，底层以SLA实现访问授权。该模型可提供基本的安全访问控制，但无法监控用户通过认证授权后的行为。该文提出了一种基于访问统计的控制模型，以限制用户不能过量占用Hadoop集群计算能力。
关键词：Hadoop；访问控制；限量使用；LDAP
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2016）13-0047-02
随着当今社会的发展，所需要处理的信息量越来越大，Hadoop[1]作为一种高可靠、高可用、低成本的集群环境，已经逐渐成为并行处理事实上的标准。致力于高效处理数据的初衷，Hadoop的开发及维护者最初并未将安全问题置于第一位，Hadoop集群管理者将内网和所有主机置于一个绝对安全的封闭环境，所有作业只能由管理员运行，也就是说，基本将Hadoop集群视为与外界隔绝的一台“超级计算机”。随着Hadoop的发展，各种新的应用逐渐出现于Hadoop生态圈中，如Hive、Storm、Hbase等，而不仅仅只限于最初的HDFS和MapReduce[2]，单个管理员难以管理越来越多的应用；同时作为一种稀缺资源，开放Hadoop集群的计算能力给多个部门或用户使用也逐渐成为必然。
然而，开放Hadoop集群也同时带来了安全风险[3]，因此Hadoop在身份认证方面，采用了Simple（Linux用户/组身份认证）和Kerberos（单点登录）两种方式[4]。在身份认证通过后，对于服务的访问可打开SLA（Service Level Authorization）开关以控制哪些用户可以访问某种服务[5]。Hadoop提供了基本的认证及授权保护，但并未对用户通过授权之后的行为进行限制，一个“贪心”甚至是恶意的用户可能会提交大量的作业或是HDFS操作，从而挤占宝贵的集群资源，使其他用户不能公平地来分享集群。Hadoop YARN中的Fair Scheduler作业调度机制[6]尽可能保证当前每个用户的作业都获得等量的资源份额，可在一定程度上解决该问题，但不能从根本上避免此类问题。因此，我们提出了一种基于“消费”的权限控制手段，在对Hadoop底层机制仅作少量修改、不影响集群运行效率的前提下，统计每个用户在使用集群时耗费的计算资源，从而限制每个用户不能过度的使用集群资源。
1 Hadoop现有的认证授权过程
对于开放共享的Hadoop集群，Simple认证方式太过简单，无法起到保护作用，必须使用Kerberos单点登录。Hadoop中基于Kerberos认证的访问过程[7]如图1所示。
1）客户端访问Hadoop服务前，先向Kerberos KDC（Key Distribution Center，密钥分发中心）验证身份。
2）若身份认证通过，KDC返回一个TGT票据（Ticket Granting Ticket），单点登录成功。客户端今后可持该票据向其他服务器表明身份并请求服务。在Hadoop集群中，客户端接下来可向NameNode或ResourceMananger发出服务请求。
先看一下对HDFS的访问流程。
3a. 客户端持TGT与NameNode进行通信，双方互相证明身份，这里双方均需与KDC交互，该过程不做详述。
4a. 如果每次验证都使用TGT，开销较大，因此NameNode第一次验证客户端后，便向向客户端分发一个NameNodeDelegation Token，以后客户端就可以使用开销较小的Token来证明身份。
5a. 客户端接着使用Delegation Token向NameNode请求服务，例如需要对HDFS中某个文件进行读/写，向NameNode发出询问。
6a. NameNode根据MetaData映射表得出文件信息，包括文件对应的Block块以及Block块对应的DataNode信息等，并生成一个Block Access Token分发给用户。
7a. 用户持Block Access Token向相应的DataNode请求服务，DataNode执行读写请求并返回结果。
客户端提交/查询/中止作业需要与ResourceManager进行交互，流程与上类似。
3b. 客户端持TGT与ResourceManager进行通信，双方互相证明身份。
4b. ResourceManager向客户端分发一个ResourceManager Delegation Token。
5b. 客户端使用Delegation Token向ResourceManager发起作业请求，ResourceManager作为资源调度器，分配一个适当的Container运行该作业的ApplicationMaster，再由ApplicationMaster向ResourceManager请求新的Container以运行子任务。客户端只与ResourceManager进行交互。
Hadoop中提供了最基本的系统级权限控制SLA，SLA通过设定权限控制表ACL的方式对Client-DFS、Client-Datanode、Datanode-Namenode等之间的访问进行控制。SLA可通过core-site.xml文件中的hadoop.security.authorization开关打开，并在hadoop-policy.xml文件中设置权限。客户端在单点登录并获取Delegation Token后可以发起请求，ResourceManager/NameNode检查ACL列表核实用户身份是否有请求权限，通过后再调用相关行为函数。在SLA之上，各种应用可具备进一步的访问控制，例如HDFS提供了类似于POSIX的文件和目录权限管理DFS Permission；MapReduce可打开Access Control on Job Queues开关以配置多个队列以及每个队列的的权限；HBase可在表上对用户行为（RWXCA五种权限）进行授权等等。
2 基于访问统计的增强控制模型
为了限制用户对Hadoop集群的过量使用，我们提出了一种对Hadoop中现有访问控制进行增强的模型，如图2所示。
在该模型中，我们引入了用户可用余额（User AvailableQuota，UAQ）的概念，并在集群中增加一个LDAP服务器来存储所有用户的UAQ和其他相关属性。与Hadoop中的其他节点一样，LDAP服务器也是通过keytab文件预先向KDC注册身份。集群中其他服务器通过基于Kerberos身份验证的SASL-GSSAPI接口来访问LDAP目录服务[8]。
如前述可知，客户端发起请求时，ResourceManager/NameNode先查询ACL列表，若通过，再调用相应处理函数。在这中间我们插入一个判定，当ACL权限审核通过后，根据请求的类型，可能还要向LDAP服务器查询并取回用户UAQ相关信息，若LDAP不存在该用户或UAQ不足，则拒绝此请求。有些请求不需要访问LDAP来取得权限，例如作业的杀死和查询。
ResourceManager/NameNode除了检查用户UAQ外，还要承担收集用户所消耗的计算资源数量工作，并适时地将该信息发送到LDAP服务器，由LDAP服务器负责更新用户UAQ。NameNode的收集工作如图3所示。
在前面分析可知，客户端先向NameNode发起文件读/写请求，NameNode从MetaData映射表中查询该文件分布的Block块和所在的DataNode，生成Block Access Token分发给客户端。客户端在每次读/写DataNode上的block时，DataNode在UserGroupInformation上下文中可取得用户信息，将此次所做操作和块号存入文件块访问记录BlockAccessRecord={User，Request，BlockId}。由于每个DataNode会周期地向NameNode发送心跳信息（Heartbeat），因此我们在心跳信息中，将这段周期内记录下的所有用户的文件块访问记录表List
ResourceManager的收集工作与NameNode类似。ResourceManager以Container的形式来分配资源，每个Container对应一个RMContainer状态机对象用于维护Container的生命周期。NodeManager通过心跳机制周期地将Container信息汇报给ResourceManager，ResourceManager从而可以修改RMContainer中的状态。RMContainer状态机中共有9种状态，通过修改RMContainer接口的实现类RMContainerImpl，记录状态转换时的时刻，可以得到状态-状态的间隔时间。
为了收集用户消耗的计算资源，这里我们可记录Container从实际分配到任务结束的时间，即ACQUIRED到COMPLETED状态的时间，ResourceManager从RMContainer对象中读取所需信息，生成Container使用记录ContainerRecord={User，ContainerId，NodeId，Resource{CPU，Memory}，Period}，并以文件形式存放在本地磁盘中，定期将该文件拷贝至LDAP服务器特定目录。若该Container因某种原因未能正常结束，可视为未占用资源。
LDAP服务器作最后的统计工作，每隔一段时间从上传文件中读取BlockAccessRecord和ContainerRecord记录，从而统计每个用户在这段时间内消耗的资源量，并刷新用户的UAQ属性。UAQ消耗后需要恢复，用户才能再次使用Hadoop资源，可以设置每天恢复一定的数量，或者由管理员手动恢复。
3分析
该模型并未对Hadoop底层机制做任何修改，仅在ResourceManager和NameNode正常工作过程中加入少许记录功能以及增加与LDAP进行通信环节，因此不会对Hadoop的性能有影响。LDAP具有良好的查询性能，基于目录的管理也较为方便，在大规模集群管理中应用较多，Hadoop中的Hive、Impala等都可以配置LDAP工作，因此这里选用LDAP来管理用户UAQ也方便将来Hadoop集群的集中管理。
在模型中，LDAP中的UAQ并不是实时更新的，这不仅是为了减少与LDAP的通信，更重要的是防止作业在执行中因为UAQ不足而中断。在此前提下，UAQ可以为负值，意味着用户可以预支额度，在当前作业完成之后，需要等待UAQ恢复才能进行下一次作业的提交。
在系统搭建时，需要增加一台LDAP服务器，NameNode和ResourceManager服务器需要安装LDAP客户端环境，所增加的安装工作并不多。传送的数据量较小，因此也不会对网络流量造成影响。
存在的问题主要在于所耗费资源量的计算标准，对于Container以占用的CPU、内存量和时间来衡量，由于ResourceManager对CPU和内存资源的分配仅是最大阀值而非实际值，而操作系统线程实际运行情况未可知，这样对实际的耗费量会有一定误差。
4 结束语
Hadoop安全机制较为简陋，无法满足多用户下的安全保护需求。本文通过提出基于访问统计的限量使用模型，在一定程度上对用户行为进行限制，增强了现有安全模型，减轻Hadoop管理工作。今后还可在此基础上进一步实现更细粒度的资源使用统计。
参考文献：
[1] Apache Hadoop [EB/OL].http：//hadoop.apache.org，2016-2-13
[2] Dean J， GhemawatS. MapReduce：Simplified data processingon large clusters[J]. Communications of the ACM， 2008， 51（1）.
[3] Zissis D，Lekkas D. Addressing cloud computing security issues[J]. Future Generation Computer Systems， 2012， 28（3）.
[4] 朱建波， 李萍， 于炯，等. 改进的Kerberos协议在HDFS环境下的研究[J]. 计算机工程与设计， 2014， 35（10）.
[5] Apache Hadoop. Service Level Authorization Guide [EB/OL]. （2014-11-14）.http：//hadoop.apache.org/docs/r2.5.2/hadoop-proje ct-dist/hadoop-common/ServiceLevelAuth.html.
[6] Amr M Elkholy， Elsayed A H，Sallam.Self adaptiveHadoop scheduler for heterogeneous resources[C]. Computer Engineering & Systems（ICCES）， 2014， 9th International Conference on， 2014.
[7] 刘莎， 谭良. Hadoop云平台中基于信任的访问控制模型[J]. 计算机科学， 2014， 41（5）.
[8] 郑之华. 基于SASL框架下身份认证机制的研究[J]. 长春大学学报， 2015， 25（2）.
