Hadoop_HDFS HA 及解决方案

1. HDFS系统架构

HDFS(Hadoop Distributed File System),及Hadoop分布式文件系统
作用: 为Hadoop分布式计算框架提供高性能,高可靠,高可扩展的存储服务
架构：典型的主(NameNode)从(DataNode)架构,两者一对多的关系,一个节点对应一个DataNode,NameNode是整个文件系统的管理节点(文件系统的最高管理者), 负责对文件系统命名空间的
     管理与维护,另外, 也负责面向于客户端对文件的操作,控制,存储统一管理与分配,而DataNode则是存储具体文件
数据类型：在HDFS上,有两种数据类型,分别是元数据类型(Metadata由NameNode存储在镜像文件中),所谓元数据就是文件除了实际内容外所有表示文件信息的数据,即MetaNode
　　　　  另外一种数据类型则是实际的文件数据了,在DataNode上存储形式是块(block,Hadoop1.x:64M;Hadoop2.x:128M),每个块可能有多个副本(默认3个,可自定义),因为由于副本机制,提高了文件数据的可靠性
　　　　　NameNode启动时加载镜像文件(fsimage.xxx)和操作文件(edits.xxx)到内存,并等待DataNode上报元数据,形成文件系统结构,一旦NameNode宕掉,则导致整个HDFS无法正常服务

2. HA定义

HA(High Availability,高可用性):系统对外提供正常服务时间的百分比
举个例子：Hadoop运行时会有两种情况
    1. 是Hadoop正常提供服务时间(MTTF),
    2. 是不能提供正常服务时间(MTTR), 所以HA=MTTF/(MTTF+MTTR)*100%
通过上面可以看出,HA能精确度量系统对对外提供正常服务的能力,也就是说系统的高可用程度
HDFS出现无法提供正常服务情况: 正常的软硬件升级,维护;客户误操作导致HDFS发生故障绝大部分是由于软件导致

3. HDFS HA 原因分析及应对措施

可靠性: NameNode作为管理节点,统一维护和控制HDFS文件系统,而DataNode存储实际文件,且有副本护驾,
　　　　也就是说NameNode成为了HDFS系统的单一故障点,NameNode能否正常运行决定了HDFS的可靠性
可维护性: 一旦NameNode无法提供正常服务,如果元数据没有损坏,那就好说,重新启动即可,
　　　　　但元数据一旦损坏且没有任何措施,那么,NameNode的维护时间将无限大;
　　　　　DataNode因为副本的原故,既是块文件损坏,也会很快恢复,NameNode也决定了系统的可维护性,
　　　　　精确一点是NameNode元数据的可维护性决定HDFS的可维护性

4. 现有HDFS HA解决方案

主要是从使用者的角度出发,提高元数据的可靠性,减少NameNode服务恢复时间,措施主要是给元数据做备份,另外HDFS自身就有多种机制来确保元数据的可靠性,减少NameNode服务恢复时间的措施有两种思路:
1. 基于NameNode重启恢复模式,对NameNode自身启动过程进行分析,优化加载过程,减少启动时间
2. 启动一个NameNode热备节点,当主节点不能正常提供服务,切换为热节点,切换时间成为恢复时间
从效率上分析，第一种思路尽管进行了优化,但NameNode的启动时间仍受文件系统规模的限制,
第二种则突破了这种限制,现有比较成熟的HA解决方案有:
a. Hadoop元数据备份
　　利用Hadoop自身元数据备份机制,NameNode可以将元数据保存到多个目录,一般是一个本地目录,有个远程目录(通过NFS进行共享),当NameNode发生故障,可以启动备用机器NameNode,加载远程目录中的元数据信息提供服务
优点:
　　Hadoop自带机制,成熟可靠,使用简单方便,无需开发,配置即可
　　元数据有多个备份,可有效保证元数据的可靠性,并且元数据内容保持在最新状态
缺点:
　　元数据需要同步写入多个备份目录,效率低于单个NameNode
　　恢复NameNode也就是重启NameNode,这样恢复时间与文件系统规模成正比
　　由于备份的元数据在远程目录上,那么NFS在操作阻塞情况下,将无法提供正常服务　　
b. Hadoop的SecondaryNameNode方案
　　启动一个SecondaryNameNode节点,定期从元数据信息(fsimage)和元数据操作日志(edits)下载,然后两个文件合并生生成新的镜像文件,推送给NameNode并重置edits,NameNode启动时,只需加载新的fsimage
优点:
　　Hadoop自带机制,成熟可靠,使用简单方便,无需开发,配置即可
　　减少NameNode启动所需时间,防止edits文件过去庞大
缺点：
　　没有做热备,那么重启时,文件系统的规模和启动时间成正比
　　有概率在NameNode宕掉时,SecondaryNameNode并未做同步,也就可能一部分操作数据会丢失,重启后的文件系统并不是最新的
c. Hadoop 的 CheckPoint Node 方案
　　CheckPoint(检查点)原理基本与SecondaryNameNode相同,实现方式不同,该方案利用Hadoop 的CheckPoint机制进行备份,配置一个CheckPoint Node节点,该节点定期区合并元数据镜像文件和用户操作日志edits,在本地形成最新的CheckPoint
　　并上传到Primary NameNode 进行更新,一旦NameNode宕掉,可以启动备份NameNode节点读取CheckPoint信息,并提供服务
优点:
　　使用简单方便,无需开发,配置即可
　　元数据有多个备份
缺点:
　　没有做热备,切换节点时间长和SecondaryNameNode一样
　　有概率恢复的元数据信息不是最新的
d. Hadoop 的Backup Node 方案
　　利用Hadoop自身的Failover措施,配置一个Backup Node,Backup Node 在内存和本地都保存一份HDFS最新的命名空间元数据信息,一旦NameNode宕掉,可使用Backup Node中最新的元数据信息
优点:
　　Hadoop自带机制,无需开发,配置即用
　　Backup Node的内存中保留了最新的元数据信息避免NFS挂载进行备份的所带来的风险,Backup Node可以直接利用内存中的元数据信息进行CheckPoint并保存到本地,效率比从
　　NameNode下载元数据进行CheckPoint效率高,Backup Node在内存中保存,一旦有操作日志,Backup Node内存同步,并更新本地磁盘的edits,两个步骤都成功,整个操作才算成功,并保证了元数据的最新状态
缺点:
　　该方案还不成熟,NameNode无法提供服务时,Backup Node 还不能直接接替NameNode提供服务
　　Backup Node未保存Block的位置信息,等待DataNode上报,即便后期实现了热备,仍需要一部分时间进行切换,当前版本只允许一个Backup Node 连接到NameNode
e. DRDB方案
　　利用DRDB方案机制进行元数据备份,也就是在NameNode无法提供服务时,启动备用机器的NameNode,读取DRDB备份的元数据信息
优点:
　　比较成熟的备份机制
　　元数据有多个备份,保证了元数据的最新状态
　　备份工作由DRDB完成,对于新的操作日志,NameNode无需同步到多个备份目录,效率上优于元数据备份
缺点:
　　没有做热备,切换机器启动NameNode时间长
　　元数据的可靠性没有保障,需要引入新的机制去保证
f. FaceBook 的AvatarNode方案
　　一种热备机制,首先AvatarNode作为Primary NameNode对外提供服务,Standby Node处于SafeMode模式,在内存中保存Primary NameNode最新的元数据信息,两者依靠NFS进行交互,
　　DataNode报告操作日志时会同时向两个Node中发送Block位置信息,因此保证了元数据的最新状态一但Primary NameNode宕掉,直接由Standby Node接替并成为Primary Node对外提供服务,大大缩短切换时间
优点:
　　提供热备、切换时间大大缩短
　　集成在FaceBook自用的Hadoop中,并部署到了自己的集群
缺点:
　　修改了部分源码,增加了一定的复杂性,在软件维护上带来一定问题
　　参考资料少,只提供一个备份节点

5. 方案优缺点比较