背景

我们公司的Hadoop集群已经存在多年的时间，大大小小也有五六个集群，每个集群由两个NameNode节点来实现高可用架构。

Hadoop HA架构

但一直存在一个让用户用着很不舒服的问题：两个NameNode节点都是以hostname的方式暴露给用户，由用户在客户端实现对Active NameNode的判断逻辑。如果客户端部署了 Hadoop 环境通过修改配置文件能自动实现对Active NameNode的判断，但很多时候用户并不会在机器上部署 Hadoop 环境,而是通过Java、Python、C++等接口包访问 Hadoop，于是用户就不得不在自己的代码里每次访问 Hadoop 之前都判断一下当前哪个 NameNode 处于 Active 状态。很多时候，新用户并不知道需要这么判断，总是要等出了事故之后才忍痛加上这个判断逻辑。这个问题造成是大大小小的事故已经数不胜数，Hadoop 负责人的回复都是：别人都是这么用的。
这个坑，我刚到公司的时候也踩过，当时我给 Hadoop 负责人提出的方案是：为 NameNode 添加一个反向代理,并通过一个定时任务判断两个 NameNode 的Active状态，一旦发生变化就修改代理规则，并提供一个统一的域名给用户去访问。

反向代理Hadoop NameNode

这个方案有以下优势：

1. NameNode 的切换对用户透明，用户操作 Hadoop 的成本降低很多，且不容易出事故
1. 一旦 NameNode 所在机器发生故障,不需要推动所有用户去修改代码或配置

但他们根本不想做任何改变，如此沟通几次之后，我看对方实在懒得动弹，我也只能长叹一口气不了了之了。

终于，前几天算法部刚引入的机器学习训练框架 Paddle 离线训练也遭遇了这个问题,所有的实验由于 NameNode 切换而访问 Hadoop 失败,导致实验全部宕机了，而 Paddle 源码公司无人能改，之前判断 NameNode Active的逻辑无法实现。如此严重的事故，负责 Hadoop 的同学也意识到了这个问题的严重性，赶紧开始想办法解决。正好我在负责机器学习管理平台，也被拉到了事故处理群里，我就再次把这个方案提了出来，他们才开始重视我提出的方案。于是，我把算法、运维、Hadoop相关同学紧急拉到一起开会讨论，讨论出3个方案。