在给学生授课和搭建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
关于Hadoop生态中的HA方案的一点思考
原创
©著作权归作者所有:来自51CTO博客作者孟伯的原创作品,请联系作者获取转载授权,否则将追究法律责任
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
关于空指针的一点思考
问题与背景新人在编写代码的时候,往往会出现想当然的情况,
python 开发语言 后端 空指针 数据 -
关于去中台化的一点思考
大概意思就是所有的公共逻辑都给你定义好了,你想创新还创新不了,我只能说这个中台没留钩子
阿里云 云计算 spring 架构师 技术问题