基于Hadoop的云盘系统客户端技术难点之二 HDFS文件访问控制
作者:张子良
版权所有,转载请注明出处
一、概述
Hadoop开源技术框架在实际业务应用中,其早期的安全机制饱受诟病,具体到HDFS应用方面的问题,主要包括以下几个方面:
1.用户到服务器的认证问题
(1)Namenode上没有用户认证:用户只要知道NameNode服务地址和端口信息,就可以访问HDFS,并获取文件namespace信息。
(2)Datanode上没有认证机制:Datanode对读入输出并没有认证,导致如果客户端知道Blockid,就可以任意的访问Datanode上的Block数据。
2.服务器到服务器的认证信息
(1)Namenode对Datanode没有认证机制:非法用户可以伪装成Datanode,去接收Namenode的文件存储任务。
二、hadoop的Security
针对用户到服务器的认证问题,Hadoop在1.0.0版本以后增加了Security认证机制。该机制采用类Unix用户管理机制,文件的创建用户和超级用户拥有对文件的所有权限,包括读和写,其他用户拥有访问权,无写权限。具体来讲就是,连接到hadoop 集群的用户/组信息取决于客户端环境,即客户端主机中`whoami`和`bash –c groups`取到的用户名和组名,没有uid和gid,用户属组列表中只要有一个与集群配置的用户组相同即拥有该组权限。
值得注意的是当前Hadoop的三个主要版本分支中并不是都实现了对其的支持,具体实施时需要注意不同版本的区别。
三、hadoop的kebores
Hadoop的Kebores认证机制,用来解决服务器到服务器的认证,主要涉及云盘系统后台服务分布式集群安全问题,将另开专题讨论。在此不作讨论。
四、云盘系统客户端文件安全保障
云盘系统客户端HDFS文件安全保障主要涉及用户对HDFS文件服务集群的安全访问问题,包括某一个注册用户只能访问属于该用户的空间和某一个用户只能在HDFS空间上访问指定大小的空间两个问题。这里面是涉及一个用户管理和空间管理的问题,在此不作详细介绍。
针对问题一,我们可以通过改造现有HadoopThriftServer或者新增服务机制来解决,即客户端登陆时,返回HDFS上该用户的允许访问路径,用户操作过程中进行访问路径检测,非授权路径自动过滤,不允许访问。
针对问题二,提供用户注册机制,服务端根据用户注册的权属组,调用FSadmin设置用户文件夹的授权大小。
作者:张子良
出处:http://www.cnblogs.com/hadoopdev
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于Hadoop的云盘系统客户端技术难点之一 上传和下载效率优化
作者:张子良 声明:版权所有,转载请注明出处 一、概述 基于任何平台实现的云盘系统,面临的首要的技术问题就是客户端上传和下载效率优化问题。基于Hadoop实现的云盘系统,受到Hadoop文件读写机制的影响,采用Hadoop提供的API进行HDFS文件系统访问,文件读取时默认是顺序、逐block读取;写入时是顺序写入。 二、读写机制 首先来看文件读取机制:尽管DataNode实现了文件存储空间的水平扩展和多副本机制,但是针对单个具体文件的读取,Hadoop默认的API接口并没有提供多DataNode的并行读取机制。基于Hadoop提供的API接口实现的云盘客户端也自然面临同样的问题。Hadoop的文件读取流程如下图所示: 使用HDFS提供的客户端开发库,向远程的Namenode发起RPC请求; Namenode会视情况返回文件的部分或者全部block列表,对于每个block,Namenode都会返回有该block拷贝的datanode地址; 客户端开发库会选取离客户端最接近的datanode来读取block; 读取完当前block的数据后,关闭与当前的datanode连接,并为读取下一个...
- 下一篇
基于Hadoop的云盘系统客户端技术难点之三 小文件存储优化
作者:张子良 版权所有,转载请注明出处。 一、概述 首先明确概念,这里的小文件是指小于HDFS系统Block大小的文件(默认64M),如果使用HDFS存储大量的小文件,将会是一场灾难,这取决于HDFS的实现机制和框架结构,每一个存储在HDFS中的文件、目录和块映射为一个对象存储在NameNode服务器内存中,通常占用150个字节。如果有1千万个文件,就需要消耗大约3G的内存空间。如果是10亿个文件呢,简直不可想象。这里需要特别说明的是,每一个小于Block大小的文件,存储是实际占用的存储空间仍然是实际的文件大小,而不是整个block大小。 为解决小文件的存储Hadoop自身提供了两种机制来解决相关的问题,包括HAR和SequeueFile,这两种方式在某些方面解决了本层面的问题,单仍然存在着各自的不足。下文讲详细说明。 二、Hadoop HAR Hadoop Archives (HAR files) ,这个特性从Hadoop 0.18.0版本就已经引入了,他可以将众多小文件打包成一个大文件进行存储,并且打包后原来的文件仍然可以通过Map-reduce进行操作,打包后的文件由索引和存储两...
相关文章
文章评论
共有0条评论来说两句吧...