hdfs

  • 使用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方案，可以直接看官方文档。

  • HDFS架构

    前段时间搭建了一套Hadoop集群的测试环境，因为服务器故障，废了。这几天闲来无事，想着把Storm用Yarn管理起来，于是再来一遍，同时也梳理下Hadoop组件中的一些概念。所谓书读百遍其义自见，不熟的系统多搭几遍，总会熟悉了，也就是所谓的刻意练习吧。

    先简单的说下。

    Hadoop文件存储的基础是HDFS(Hadoop Distributed File System)，HDFS的实现依赖于NameNode和DataNode，DataNode用来存储具体数据，NameNode用来管理多个DataNode中分别存储的是什么。

    理解起来也不难，因为HDFS是分布式的文件系统，也就是有很多机器用来存储数据，一个大文件可能分布在多个机器上，也可能是一台机器上，具体分布在哪些或哪个机器上，每块数据块的副本在哪，得需要一个总管来管理，这个总管就是NameNode，具体存储机器的就是DataNode。

    简单的说完了，接下来就复杂的说。