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

Posted 2020-11-28

    在给学生授课和搭建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极易产生的脑裂问题。
            从安全运维的角度讲，掌握一种解决方案并不在于使用了多少花哨和前卫的技术，而在于是否能通过分析某一个示例性的解决方案、依据自己的学习和工作经验、根据项目约束条件提出备用解决方案，能否减少平台组件的安装数量、能否在公开采用的解决方案被破解后迅速组织起替代性的解决方案来把可见于潜在的损失降到最低。

                                                                                                                                孟伯，20200229.
                                                                                                     交流联系：微信 1807479153 ，QQ 1807479153