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. 方案优缺点比较
