Hadoop是由Apache开源软件基金会开发的，运行于大规模普通服务器上的分布式系统基础架构，用于大规模数据的存储、计算、分析等。通过使用Hadoop平台用户可以在不了解分布式底层细节的情况下，开发分布式程序，充分利用集群的威力进行高速运算和存储。2007年雅虎发布了第一个Apache Hadoop版本0.14.1；2008年雅虎用Hadoop做到全网尺度的搜索；2009年雅虎把内部版本全部开源，于是IBM也加入Hadoop的开发阵营；2010年Facebook宣布正式运行世界最大的Hadoop集群；2011年Apache Hadoop1.0版本发布；2012年Apache Hadoop2.0版本发布。下面具体介绍一下Hadoop系统的架构。
Hadoop由许多元素构成，如下图图所示，包括HBase、Hive、Pig、Chukwa、Oozie和ZooKeeper等，但是其核心组件为HDFS和MapReduce。
HDFS是Hadoop Distributed File System系统的缩写，是一个使用JAVA语言实现的、分布式的、可扩展的文件系统，它存储 Hadoop 集群中所有存储节点上的文件，由NameNode和DataNode两部分组成。HDFS的上一层是 MapReduce 引擎，该引擎由 JobTrackers 和 TaskTrackers 组成，用来对存储在HDFS上的数据进行计算分析。下面来具体介绍HDFS和MapReduce的工作原理及应用。
HDFS
HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode是集群中的数据节点，用来存储实际的数据，并负责管理它所在节点上的数据存储。HDFS公开了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间 *** 作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制，下面就具体来阐述HDFS系统中涉及的基本概念；
数据块（Block） HDFS和传统的分布式文件系统一样，也采用了数据块的概念，将数据分割成固定大小的数据块进行存储，默认大小为64MB，块的大小可针对每个文件配置，由客户端任意指定，并且每个块都有属于自己的全局ID，作为一个独立的单位存储在集群服务器上。与传统分布式文件系统不同的是，如果实际数据没有达到块大小时，则并不实际占用磁盘空间。 HDFS元数据 HDFS元数据由文件系统目录树信息、文件和数据块的对应关系和块的存放位置三个部分组成，文件系统目录树信息包括文件名、目录名及文件和目录的从属关系，文件和目录的大小，创建及最后访问时间。文件和块的对应关系记录了文件由哪些块组成。此外元数据还记录了块的存放位置，包括存放块的机器名和块ID。 NameNode HDFS对元数据和实际数据采取分别存储的方式，元数据存储在一台指定的服务器上，称为NameNode，实际数据则存储在集群中的其他机器上的文件系统中，称为DataNode。NameNode是用来管理文件系统命名空间的组件，并且一个HDFS集群只有一台NameNode，由于元数据存储在NameNode上，当NameNode出现故障时将导致整个集群无法工作。元数据保存在NameNode的内存当中，以便快速查询，1G内存大致可以存放1000000个块对应的元数据信息。 DataNode DataNode用来存储块的实际数据，每个块会在本地文件系统产生两个文件，一个是实际的数据文件，另一个是块的附加信息文件，其中包括数据的校验和生成时间等信息。DataNode通过心跳包(Heartbeat)与NameNode通信，当客户端读取/写入数据的时候将直接与DataNode进行通信。 Secondary NameNode Secondary NameNode在Hadoop集群中起到至关重要的作用，首先需要明确它并不是NameNode的备份节点，它和NameNode运行在不同的主机上，它主要的工作是阶段性地合并NameNode的日志文件，控制NameNode日志文件的大小。此外，在NameNode硬盘损坏的情况下，Secondary NameNode也可用作数据恢复，但恢复的只是部分数据。
HDFS架构及工作原理
下图为HDFS对数据存储的原理图，NameNode存储了DataNode节点所存储数据的元数据，即Hdfs和MapReduce两个文件的分块信息，假设单个文件的存储份数为3，即每个数据块有三份备份，那么数据在DataNode上的存储的原则为：相同的两个数据块存储在同一机架的不同的DataNode节点上；第三个数据块存储在不同机架上的DataNode节点上。这样就解决了当某个DataNode节点出现故障的时候数据丢失的问题，保障了存储在HDFS系统上数据的可用性。
Hadoop MapReduce
MapReduce是Google公司的核心计算模型，它将运行于大规模集群上的复杂的并行计算过程高度地抽象为两个函数：Map和Reduce。MapReduce也可以看成是一种解决问题的方法，它把一个复杂的任务分解成多个任务，Map负责把任务分解成多个任务，Reduce负责把分解后多任务处理的结果汇总起来。
Hadoop中的MapReduce是一个简易的软件框架，基于它写出来的应用程序能够运行在由上千台机器组成的大型集群上，并以一种可靠容错的方式并行处理TB级别的数据集，实现了Hadoop在集群上的数据和任务的并行计算与处理。在并行计算中其他的种种复杂的问题，如分布式存储、工作调度、负载均衡、容错处理、网络通信等均由MapReduce框架负责处理，编程人员可以不用关心。用MapReduce来处理的数据集必须具备这样的特点：待处理的数据集可以分解成许多小的数据集，并且每个小的数据集都可以完全并行地进行处理。
Hadoop MapReduce实现
Hadoop MapReduce是基于HDFS的MapReduce编程框架实现的，我们把MapReduce处理的问题称为作业 (Job)，并将作业分解为任务 (Task)，在MapReduce执行过程中需要有两种任务。
Map 把输入的键/值对转换成一组中间结果的键/值对. Reduce 把Map任务产生的一组具有相同键的中间结果根据逻辑转换生成较小的最终结果。
Hadoop MapReduce的服务进程
Hadoop MapReduce有两个主要的服务进程，一个是单独运行在主节点上的JobTracker进程，另一个是运行在每个集群从节点上的TaskTracker进程。服务进程部署如下图所示。
JobTraker和NameNode运行在同一个服务器上，我们称为Hadoop集群的主节点，负责接收客户端提交的作业，并将任务分配到不同的计算节点TaskTracker上，同时监控作业的运行情况，完成作业的更新和容错处理；Tasktracker通常和DataNode装在一起，称为Hadoop集群的从节点，它调用Map和Reduce执行JobTracker指派的任务，并发送心跳消息给JobTracker，向JobTracker汇报可运行任务的数量。
Hadoop安全机制
Hadoop 一直缺乏安全机制，主要表现在以下几个方面。
User to Service：NameNode或者JobTracker缺乏安全认证机制；DataNode缺乏安全授权机制；JobTracker缺乏安全授权机制。 Service to Service安全认证：Datanode与TaskTracker缺乏安全授权机制，这使得用户可以随意启动假的DataNode和TaskTracker。 磁盘或者通信连接没有经过加密。
为了增强Hadoop的安全机制， 从2009年起Apache专门抽出一个团队为Hadoop增加安全认证和授权机制，Apache Hadoop 1.0.0版本之后的版本添加了安全机制，但是升级到该版本后可能会导致Hadoop的一些应用不可用。
在与客户交流Hadoop安全时，提及kerberos的频率非常高，并提出了一些关于kerberos的安全问题，比如它的安全机制，具体是解决Hadoop什么安全问题，存在哪些不足等等，下面就由小编对kerberos做一个详细的归纳，更加清晰kerberos在Hadoop安全中担任的角色。
1. Hadoop安全问题：
Hadoop设计之初，默认集群内所有的节点都是可靠的。由于用户与HDFS或M/R进行交互时不需要验证，恶意用户可以伪装成真正的用户或者服务器入侵到hadoop集群上，导致：恶意的提交作业，修改JobTracker状态，篡改HDFS上的数据，伪装成NameNode 或者TaskTracker接受任务等。 尽管在版本之后， HDFS增加了文件和目录的权限，但并没有强认证的保障，这些权限只能对偶然的数据丢失起保护作用。恶意的用户可以轻易的伪装成其他用户来篡改权限，致使权限设置形同虚设。不能够对Hadoop集群起到安全保障。
(1) 用户到服务器的认证问题：
NameNode，JobTracker上没有用户认证
用户可以伪装成其他用户入侵到一个HDFS 或者MapReduce集群上。
DataNode上没有认证
Datanode对读入输出并没有认证。导致如果一些客户端如果知道block的ID，就可以任意的访问DataNode上block的数据
JobTracker上没有认证
可以任意的杀死或更改用户的jobs，可以更改JobTracker的工作状态
(2) 服务器到服务器的认证问题：
没有DataNode, TaskTracker的认证
用户可以伪装成datanode ,tasktracker，去接受JobTracker, Namenode的任务指派。
2、kerberos解决的安全问题：
加入Kerberos认证机制使得集群中的节点就是它们所宣称的，是信赖的。Kerberos可以将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时，集群内的节点使用密钥得到认证。只有被认证过节点才能正常使用。企图冒充的节点由于没有事先得到的密钥信息，无法与集群内部的节点通信。
kerberos实现的是机器级别的安全认证，也就是前面提到的服务到服务的认证问题。事先对集群中确定的机器由管理员手动添加到kerberos数据库中，在KDC上分别产生主机与各个节点的keytab(包含了host和对应节点的名字，还有他们之间的密钥)，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从KDC上获得与目标节点通信的密钥，进而被目标节点所认证，提供相应的服务，防止了被冒充的可能性。
解决服务器到服务器的认证
由于kerberos对集群里的所有机器都分发了keytab，相互之间使用密钥进行通信，确保不会冒充服务器的情况。集群中的机器就是它们所宣称的，是可靠的。
防止了用户伪装成Datanode，Tasktracker，去接受JobTracker，Namenode的任务指派。
解决client到服务器的认证
Kerberos对可信任的客户端提供认证，确保他们可以执行作业的相关 *** 作。防止用户恶意冒充client提交作业的情况。
用户无法伪装成其他用户入侵到一个HDFS 或者MapReduce集群上
用户即使知道datanode的相关信息，也无法读取HDFS上的数据
用户无法发送对于作业的 *** 作到JobTracker上
对用户级别上的认证并没有实现
无法控制用户提交作业的 *** 作。不能够实现限制用户提交作业的权限。不能控制哪些用户可以提交该类型的作业，哪些用户不能提交该类型的作业。这些由ACL模块控制(参考)
3、Kerberos在Hadoop安全中担任什么角色以及存在什么问题：
通俗来说Kerberos在Hadoop安全中起到是一个单因素(只有一种如账号、密码的验证方式)身份验证的作用，kerberos就如一个房间的门锁，进门的人需要提供正确的密码，而对于进门后的人做了什么样的 *** 作kerberos就无法控制了。
存在的问题：
kerberos验证方式单一、安全性低的问题，首先其只提供类似linux文件系统的帐户权限验证，而且可以通过简单的手段冒充用户名，如果有恶意用户，直接冒充为hadoop的super用户，那整个集群是很危险的。其次不能对认证过的用户做任何权限控制
部署复杂，生成证书和配置的步骤相当繁琐，首次配置还可以接受，但是对于用户权限的修改，机器的减容扩容，会造成证书重新生成，再分发证书，重启hadoop。且还存在kerberos的宕机导致整个集群无法服务的风险，加上kerberos本身也比较复杂。
影响效率，网上搜罗一个真实案例，支付宝曾用了kerberos，导致其效率极低运维困难。原因是因为请求次数过多，具体看下面关于kerberos的工作原理就知道了。
4、 Kerberos工作原理介绍
4.1基本概念
Princal(安全个体)：被认证的个体，有一个名字和口令
KDC(key distribution center ) : 是一个网络服务，提供ticket 和临时会话密钥
Ticket：一个记录，客户用它来向服务器证明自己的身份，包括客户标识、会话密钥、时间戳。
AS (Authentication Server)： 认证服务器
TSG(Ticket Granting Server)： 许可证服务器
4.2 kerberos 工作原理
4.2.1 Kerberos协议
Kerberos可以分为两个部分：
Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。(此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式)
Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别
4.3 Kerberos认证过程
Kerberos协议的重点在于第二部分(即认证过程)：
(1)Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址(IP)，服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service，不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service，所以有了第二步。
(2)此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个密钥(KDC在第一步为它们创建的Session Key)，KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。
(3)为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址(IP)打包成Authenticator用Session Key加密也发送给Service。
(4)Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址(IP)，服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址(IP)将其与之前Ticket中解密出来的用户名，用户地址(IP)做比较从而验证Client的身份。
(5)如果Service有返回结果，将其返回给Client。
4.4 kerberos在Hadoop上的应用
Hadoop集群内部使用Kerberos进行认证
具体的执行过程可以举例如下：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）