关于Hadoop生态中的HA方案的一点思考

     在给学生授课和搭建Hadoop生态实验环境的过程中，我发现无论是网络上的参考资料、还是来自大数据服务功供应商的运维文档，给出Hadoop的HA解决方案都如出一辙——使用 ZooKeeper 加 Quorum Journal Manager 方案。

     诚然，这一方案久经考验，是十分成熟的可靠方案。与NFS方案相比较，它解除了大量写场景下NFS仅支持单个共享编辑目录的系统可用性限制；与Federation方案相比较，则较好地解决了单个joint-namespace中的单点故障问题，因为篱笆内的各namespace是联合作业的，无需协调，各自为政地管理着自己的区域，如果某个 namenode 挂掉了，其管理的相应的文件便不可以访问。

     通过分析ZKFC和JournalNode工作原理及相关配置文件，发现ZooKeeper 和 Quorum Journal Manager的组合就干了6件事：HealthMonitor、ZKFailoverController、ActiveStandbyElector、share&Sync EditLog、加锁EpochNumber以防止脑裂、合并成新的FSImage。

     干这6件事是否只能依赖ZooKeeper 和 Quorum Journal Manager的组合呢？

     在部署小规模的Web高可用集群时，我曾用keepalived来解决过failover问题，经过适当的修改和定制化后它似乎可以取代ZooKeeper的功用，这样就可以解决HealthMonitor、ZKFailoverController、ActiveStandbyElector问题了。剩下的问题归结起来就是存储和共享元数据的额问题了，这个可以借助于HDFS存储系统实现，利用HDFS的多副本冗余来确保元数据不丢失。当然，依照这个思路解决Hadoop的HA问题，要达到与ZooKeeper 加 Quorum Journal Manager 方案相当的而效果，还需要额外的脚本工具帮助实现，比如用脚本解决Keepalived极易产生的脑裂问题。