ha

  • 使用QJM实现HDFS的HA

    本文是在hadoop集群部署(yarn)基础上增加的配置内容,因为那篇缺少HDFS的HA配置,在生产环境不够完整。

    hadoop官方提供了两种HDFS的HA配置方案,两种方案殊途同归,但是需要的钱、精力和技术不同。

    如果对HDFS架构熟悉的话(如果不熟悉,可以通过HDFS架构了解),就应该知道,NameNode通过FsImage和EditLog两个文件管理DataNode的数据,Secondary NameNode会定期合并EditLog,以减少NameNode启动时的安全检查。EditLog文件存储的是对文件的一条条的操作,也就是说,只要保证有另外一个NameNode的EditLog文件一直与当前正在运行的NameNode的EditLog文件是一样的,那就可以随时使用新的NameNode替换老的NameNode。官方目前给出的两种HA方案也大体是这样:

    • QJM:the Quorum Journal Manager,翻译是法定经济管理人,实在没法想象,所以大家都亲切的称之为QJM。这种方案是通过JournalNode共享EditLog的数据,使用的是Paxos算法(没错,zookeeper就是使用的这种算法),保证活跃的NameNode与备份的NameNode之间EditLog日志一致。
    • NFS:Network File System 或 Conventional Shared Storage,传统共享存储,其实就是在服务器挂载一个网络存储(比如NAS),活跃NameNode将EditLog的变化写到NFS,备份NameNode检查到修改就读取过来,是两个NameNode数据一致。

    客观的说,Secondary NameNode也算是对NameNode的备份,但是使用Secondary NameNode需要手动处理,不如QJM和NFS两种可以自动处理简单,所以没有被列入HA解决方案中。

    但是,这两种方案在部署方式上差别比较大。QJM需要启动几个JournalNode即可,NFS需要挂在一个共享存储。因为条件限制,我只能通过QJM的方式实现HDFS的HA,如果想看NFS方案,可以直接看官方文档

  • ResourceManager HA 配置

    陆续的把Hadoop集群部署HDFS的HA配置完成,把ResourceManager的HA配置好之后,Hadoop集群配置也算是完整了,可以满足小型中型生产环境Hadoop集群搭建的需要。如果真要搭建超大型的Hadoop集群,这些只能算是参考,还需要修改很多其他参数,使性能更好一些。

    ResourceManager(RM)负责跟踪集群中资源使用情况,调度应用程序(比如MapReduce作业)。在Hadoop 2.4之前,ResourceManager存在单点故障,需要通过其他方式实现HA。官方给出的HA方案是Active/Standby两种状态ResourceManager的冗余方式,类似于HDFS的HA方案,也就是通过冗余消除单点故障。