一、Hadoop HA的Web页面访问
Hadoop开启HA后，会同时存在两个Master组件提供服务，其中正在使用的组件称为Active，另一个作为备份称为Standby，例如HDFS的NameNode、YARN 的ResourceManager。HDFS的web页面只有通过Active的NameNode才能正常访问，同样地，YARN的web页面也只有通过Active的ResouceManager才能正常访问。
(1) HDFS HA的Web访问
正常使用Nginx的proxy_pass代理单一的Web服务地址时非常简单（参考博文最简反向代理配置），而面对Hadoop HA这样的多Web服务地址时就会有点麻烦。
(2) HDFS HA的Web代理
虽然Nginx的upstream支持配置多个Web地址，默认会随机将Web请求随机转发到任意一个Web地址，只有某个web地址被认为不可达后，才会被Nginx列入黑名单。而Hadoop HA的Active和Standby节点都是一直服务的，只是同一个时刻，最多只有一个节点的Web访问是有效的，这就要求Nginx对upstream中的Web地址更细致地检查，而非粗略地判断是否可达。
二、Nginx的upstream健康检查
对upstream的地址有效性检查称为健康检查。通过定期的调用检查逻辑，对upstream配置的Web地址进行标记，不健康的Web地址会被临时列入黑名单内，直到该地址被标记为健康状态时，才会有新的Web请求转发到该地址上。
（1）Nginx本身对upstream的健康检查支持并不强大，做不到对检查逻辑的自由定制。
（2）开源项目nginx_upstream_check_module以Nginx补丁的方式扩展了Nginx的upstream语法，支持自定义HTTP请求的方式检查Web服务的健康状态。但在实际使用过程中，遇到一个很不方便的地方。
upstream resourcemanagers { server 192.168.0.1:8084; server 192.168.0.2:8084; check interval=30000 rise=1 fall=3 timeout=5000 type=http; check_http_send "HEAD / HTTP/1.0\r\n\r\n"; check_http_expect_alive http_3xx; keepalive 2000; }
nginx_upstream_check_module使用check命令定义健康检查的基本属性，使用check_http_send自定义HTTP请求，check_http_expect_alive定义期望的健康状态HTTP code。这里使用http_3xx是该模块定义的内置匹配语法，表示以3开头的HTTP code。想必大家已经想到，这种定义方式是无法精确区分301、302、307报文的。当然正常情况下，3xx的报文应该是同类型的报文，不需要如此精确的区分，但是不巧的是Hadoop2.7.2版本的Active ResourceManager和Standby ResourceManager分别返回的是302和307报文！
（3）以上两种方案并不是解决Nginx upstream健康检查的完美方案，真正完美的方案是OpenResty的lua-resty-upstream-healthcheck。OpenResty内置了大量的Lua库，可以自由扩展、定制Nginx的功能。其中healthcheck.lua模块用于upstream的健康检查。
不过我希望在Nginx的基础上只扩展upstream健康检查的功能，而非用OpenResty代替Nginx，因此需要使用Nginx的lua-upstream-nginx-module模块。
下面关于Hadoop的文章您也可能喜欢，不妨看看：
Ubuntu14.04下Hadoop2.4.1单机/伪分布式安装配置教程
CentOS安装和配置Hadoop2.2.0
Ubuntu 12.10 +Hadoop 1.2.1版本集群配置
三、编译安装扩展Nginx