Hadoop运维记录系列(十九)

Kerberos保护下的Hive排错记录，5月14日，Megadeth北京见。

同事想在zeppelin里面使用Hive，这是在新的kerberos保护下的集群里第一次使用Hive，不幸的是，使用过程中还是出现了验证授权的问题，所以我不得不去排查问题。

Hive的客户端服务器已经安装的hadoop-client，并且把所有需要的keytabs文件都放到了配置文件夹下且设置了正确的权限。但是仍然无法连接到集群，日志一直显示验证失败。

首先我得描述一下这个给全球五百强企业搭建的安全集群，按照合同要求，使用正版的Cloudera Manager来安装集群，版本必须是5.10，但是在安装的时候，Cloudera已经升级到了5.11，用过的同学应该都了解，CM是闭源的，而且安装器一定会强制使用和下载当前最新的版本，所以为了保证合同约定，我想了一些办法，来强迫5.11的安装器用parcels的方式安装了5.10的hadoop和周边的兼容组件。然后由于我们的MR，spark开发都是基于5.9的，所以提交作业的服务器都是安装的5.9，虽然理论上说5.9和5.10是兼容的，但是为了避免出现可能发生的问题，提交作业的服务器还是仍然安装了5.9，所以现在的情况是5.11的Manager管理5.10的parcels包，然后client是5.9。然后我们的Zeppelin是基于Apache发行版进行修改并自己进行rpm封装发行的。叫做zin-1.1.0+adh2.4.1+1-1.adh2.4.1.p0.0.el6.noarch。

整个安装和部署过程填埋了无数的坑，还加上了kerberos，不过总算是可以稳定运行了。

现在，回到关于kerberos的技术讨论上来，所以，为了排错，我登录到了集群的从节点，尝试使用hive和beeline命令使用hive，看上去一切正常。

在从节点上的Hive提示

然后是beeline

看上去一切正常，这是在集群里的服务器，是从节点，parcels安装，5.10的slave

那么再来看看client，试试。这是rpm安装，5.9的client。

再试试beeline

全部失败了。

当我看到有一句HS2 may be unavailable的时候，我被误导了，我以为是网络连通问题，可能是hiveserver2可能挂了，或者被iptables拦截了，所以我在CM里同时用pa aux来检查hiveserver2的存活，发现都没有问题，然后我关掉了iptables，在client服务器通过telnet hiveserver2 10000来查看是否能打开端口，结果一切正常，metastore也毫无问题，所以我有些困惑，再次查看日志，里面有SASL的错误。WTF?

那么这就有了合理的解释，是kerberos验证的问题，我google了一圈，发现并没有什么有用的能解决我遇到的问题的信息，所以，我打开hive-env.sh，添加了以下这行参数，同时在能正常工作的服务器的hive-env里也添加了这个参数。

下面是正常服务器的日志

接下来是失败服务器的日志

我早先已经给client服务器创建好了pricipal和keytab，不过还是失败了。但是看到没有，在client这个失败节点上没有kerberos的验证信息。

所以我开始思考kerberos的工作原理，kerberos本身会为被访问的服务创建本地缓存，来避免每次请求都访问KDC服务器。每次都会在本地进行验证。那么可能的情况就是失败的client没有读取kerberos的本地缓存，但这跟kerberos无关，是hive的配置问题，于是我将hadoop的core-site文件拷贝到了hive的配置文件夹，并且设置了hadoop.security.auth_to_local为DEFAULT，然后问题解决。

其实这里面有一个坑就是用CM的parcels安装的hadoop，每次服务重启都会创建一个新的配置文件夹，这里面的hive-env.sh里面的各种LIBS的export并不会指向真正hadoop或者hive的配置文件夹，所以你无法使用CM来查看你的配置选项。然后rpm也是会有这个问题。

然后附赠一些其他的日志

/tmp/root/hive.log

hiveserver2.log

metastore_server.log