被这个参数三杀了

原创
2022/06/07 23:57
阅读数 446

最近接连排查了几个问题,居然都是同一个参数引起的,本文就通过实际案例讲述下该参数如何引发问题的,以及问题最终又是如何解决的~

【First Blood】


在我们的环境中,RM是基于HA的方式部署的,并且RM是基于容器的方式运行的,即两个RM运行在各自的容器中;同时,我们还开启了kerberos认证,因此两个RM的hostname配置的是域名主要的配置信息如下所示:

<property>
    <name>yarn.resource.ha.enabled</name>
    <value>true</value>
</property>
<property>
    <name>yarn.resourcemanager.ha.automatic-failover.enable</name>
    <value>true</value>
</property>
<property>
    <name>yarn.resourcemanager.ha.rm-ids</name>
    <value>rm1,rm2</value>
</property>
<property>
    <name>yarn.resourcemanager.hostname.rm1</name>
    <value>rm-0.svc.cluster.local</value>
</property>
<property>
    <name>yarn.resourcemanager.hostname.rm2</name>
    <value>rm-1.svc.cluster.local</value>
</property>

在一次测试过程中,RM的其中一个(容器所在)节点异常宕机了,此后向RM提交了一个任务,但该任务的AM启动后就失败了,报错信息为:

java.lang.IllegalArgumentException: java.net.UnknownHostException: hadoop-resourcemanager-0.hadoop-resourcemanager.hncscwc-198.svc.cluster.local1
        at org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:418)
        at org.apache.hadoop.yarn.client.ClientRMProxy.getTokenService(ClientRMProxy.java:153)
        at org.apache.hadoop.yarn.client.ClientRMProxy.getAMRMTokenService(ClientRMProxy.java:138)
        at org.apache.hadoop.yarn.client.ClientRMProxy.setAMRMTokenService(ClientRMProxy.java:80)
        at org.apache.hadoop.yarn.client.ClientRMProxy.getRMAddress(ClientRMProxy.java:99)
        at org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider.getProxyInternal(ConfiguredRMFailoverProxyProvider.java:76)
        at org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider.getProxy(ConfiguredRMFailoverProxyProvider.java:90)
        at org.apache.hadoop.io.retry.RetryInvocationHandler$ProxyDescriptor.<init>(RetryInvocationHandler.java:197)
        at org.apache.hadoop.io.retry.RetryInvocationHandler.<init>(RetryInvocationHandler.java:317)
        at org.apache.hadoop.io.retry.RetryInvocationHandler.<init>(RetryInvocationHandler.java:311)
        at org.apache.hadoop.io.retry.RetryProxy.create(RetryProxy.java:59)
        at org.apache.hadoop.yarn.client.RMProxy.createRMProxy(RMProxy.java:120)
        at org.apache.hadoop.yarn.client.RMProxy.createRMProxy(RMProxy.java:93)
        at org.apache.hadoop.yarn.client.ClientRMProxy.createRMProxy(ClientRMProxy.java:72)
        at org.apache.hadoop.mapreduce.v2.app.rm.RMCommunicator.createSchedulerProxy(RMCommunicator.java:311)
        at org.apache.hadoop.mapreduce.v2.app.rm.RMCommunicator.serviceStart(RMCommunicator.java:117)
        at org.apache.hadoop.mapreduce.v2.app.rm.RMContainerAllocator.serviceStart(RMContainerAllocator.java:263)

RM配置了高可用,其中一个宕机,另外一个RM也确实提升为Active了,任务也能正确提交和调度,但为什么运行就报错了呢?

顺着报错的堆栈信息,走读相关的代码,我们发现了问题的所在。

《YARN任务运行中的token》中提到了yarn任务的AM在启动后,会从指定的文件中加载AMRMToken,而rm的客户端在初始化时需要给token设置服务端的地址,也就是rm的地址。

关键代码如下所示:

在buildTokenService中,判断如果必须使用IP(userIpForTokenService),则会对rm的域名进行解析,如果无法解析出具体的ip地址,则抛出异常;异常会逐层往上抛,最终导致程序退出。

结合实际情况来分析,由于其中一个rm出现了宕机,其域名确实无法解析出对应的ip来,因此这也就是导致任务失败的根本原因

至于useIpForTokenService的值,是由配置项hadoop.security.token.service.use_ip来决定的,默认为true,即tokenService需要使用ip,而不是域名。

最终,将该配置参数设置为false后,再次测试验证,在同样的场景下,任务可以正确提交和运行。

【Double Kill】


在上面问题解决后的第二天,重新部署环境时,发现jobHistoryServer由于无法正确进行kerberos认证,导致启动失败,具体报错信息为:

org.apache.hadoop.yarn.exceptions.YarnRuntimeException: History Server Failed to login
        at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.serviceInit(JobHistoryServer.java:130)
        at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
        at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.launchJobHistoryServer(JobHistoryServer.java:231)
        at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.main(JobHistoryServer.java:241)
              
Caused by: java.io.IOException: Login failure for hadoop/172.16.20.18@BIGDATA.COM from keytab /home/hncscwc/hadoop/etc/hadoop/hdfs.keytab: javax.security.auth.login.LoginException: Unable to obtain password from user

        at org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:1144)
        at org.apache.hadoop.security.SecurityUtil.login(SecurityUtil.java:286)
        at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.doSecureLogin(JobHistoryServer.java:183)
        at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.serviceInit(JobHistoryServer.java:128)
        ... 3 more
Caused by: javax.security.auth.login.LoginException: Unable to obtain password from user

        at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Krb5LoginModule.java:901)
        at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:764)
        at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:618)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
        at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
        at org.apache.hadoop.security.UserGroupInformation$HadoopLoginContext.login(UserGroupInformation.java:522)
        at org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(UserGroupInformation.java:1135)
        ... 6 more

问题出现后,先对jobHistoryServer的配置文件进行了确认,发现与之前是一样的,并没有什么不对的地方,关键配置项如下所示:

<property>
    <name>mapreduce.jobhistory.address</name>
    <value>172.16.20.18</value>
</property>
<property>
    <name>mapreduce.jobhistory.principal</name>
    <value>hadoop/_HOST@BIGDATA.COM</value>
</property>

jobHistoryServer启动后进行kerberos登陆时,会对principal中的_HOST进行替换,替换内容为mapreduce.jobhistory.address的值,即最终以ip形式进行了替换,导致认证失败。

正常来说,向kdc登陆认证的principal应该是包含服务的主机名,而不是ip地址,并且之前在这种配置下也都没有任何问题,怎么突然就不正常了?

还是结合源码进行分析,找到了问题所在:

配置项hadoop.security.token.service.use_ip配置为true或false时,内部会产生不同的主机地址解析对象:

  • 设置为true时为StandardHostResolver

  • 设置为false时为QualifiedHostResolver

两者对于host地址为ipv4的解析有所不同

对于StandardHostResolver:

对于QualifiedHostResolver:

也就是说,StandardHostResolver可以通过getByName正确解析出ip对应的主机名,而后者直接将ip返回

之前hadoop.security.token.service.use_ip配置为true,因此配置项mapreduce.jobhistory.address即便配置为ip,也能正确解析出对应的主机名,然后在principal替换_HOST时,也是正确的。

修改上面的问题后,将配置的值改为了false,就导致了该问题的出现。

最后,我们通过将配置项mapreduce.jobhistory.address的值修改为主机名解决了该问题。

【Triple Kill】


没有问题的日志维持了两三天,再次遇到问题,这次的现象是在sparkHistory节点上向hdfs上传文件失败。

首先,我们先在其它节点上进行了同样的操作,发现向hdfs上传文件是没有任何问题的,同时查看nn/dn的进程情况,结合对应日志确认nn/dn都是正常的

接着,我们重新回到该节点上,检查了hdfs-site.xml中的相关配置项,没有发现异常的地方,然后向nn/dn的节点执行了ping操作,确认网络也没有问题,但发现hdfs相关的所有操作都失败。

最后,通过tcpdump进行了抓包分析,发现与nn建立连接时,tcp的源端地址为127.0.0.1,这导致syn发送后,根本得不到sync ack应答。而正常情况下,源ip应该是该节点自身的ip。

那么这里为什么会是127.0.0.1,是谁指定的127.0.0.1?

继续通过strace来分析,发现socket创建后,主动进行了一次bind源地址的操作,并且绑定的源端地址就是127.0.0.1

进一步调整日志为TRACE后,发现是在hdfs的客户端进行了bind的操作

22/04/19 17:10:50 TRACE ipc.ProtobufRpcEngine: 1: Call -> namenode.svc.cluster.local/172.16.22.234:9000: getFileInfo {src: "/"}
22/04/19 17:10:50 DEBUG ipc.Client: The ping interval is 60000 ms.
22/04/19 17:10:50 DEBUG ipc.Client: Connecting to namenode.svc.cluster.local/172.16.22.234/9000
22/04/19 17:10:50 TRACE secruity.SecruityUtil: Name lookup for spark-history.svc.cluster.local took 3ms.
22/04/19 17:10:50 DEBUG ipc.Client: Binding hadoop/spark-history.svc.cluster.local@BIGDATA.COM to spark-history.svc.cluster.local.localdomain/127.0.0.1

既然知道是hdfs客户端中对socket进行了源IP的绑定动作,那么就结合源码梳理下hdfs客户端向nn建立连接的逻辑:

在开启kerberos认证的场景中,客户端向nn建立连接的流程包括:创建socket,然后从ticket中解析出bind地址并进行bind操作,最后进行连接

从ticket中解析出本地bind地址的具体步骤又分为:

  • 从ticket中获取principal

  • 从principal中获取主机名

  • 如果主机名为空,则不进行bind操作

  • 如果主机名非空,对主机名进行解析,如果解析后的地址非空,则进行bind操作。

对于主机名解析又分为两种情况

如果配置项"hadoop.security.token.service.use_ip"的值为true,则直接获取主机名对应的ip,如果为false,则继续按下面的逻辑解析(其本意是想要获取主机名对应的完全合规域名)

  • 如果主机名为ipv4,通过ip地址获取对应的全域名

  • 如果主机名以"."结尾,直接获取主机名对应的全域名

  • 如果主机名包含".",先在主机名末尾加上".",并继续上一步的逻辑解析,如果解析出的域名为空,则在主机名末尾依次添加"/etc/resolve.conf"中的"search"指定的域,进行主机名的解析

以实际情况来分析:

  • sparkHistory进程kerberos登陆使用的principal为"hadoop/spark-history.svc.cluster.local@BIGDATA.COM"

  • 从pincipal中解析出主机名为"spark-history.svc.cluster.local"

  • 配置项"hadoop.security.token.service.use_ip"的值为false,因此进入全域名的解析流程。主机名不是完全合规(即不是以"."结尾),但又包含了".",因此先在末尾加上".",使其成为完全合规域名,并按照该域名来解析。

  • 而由于sparkHistory所在的容器,配置了就绪探针,容器未就绪时,无法解析出任何地址。因此继续在"spark-history.svc.cluster.local."后再加上"/etc/resolve.conf"中search指定的域,便利进行全域名解析,如果其中任意一个能解析出地址,则退出循环

  • 该节点中"/etc/resolve.conf"中的search中仅有一个localdomain,因此以"spark-history.svc.cluster.local.localdomain"来解析,解析出的ip恰好就是127.0.0.1,导致了问题的出现

该节点的/etc/resolve.conf文件中之所以只有"search localdomain",怀疑是人为进行了修改导致的。最后,修改该文件,问题得以解决。

【总结】


通过这三个问题分析定位解决,对"hadoop.security.token.service.use_ip"有了较深入的理解,同时也深刻领会源码是不会骗人的

好了,这就是本文的全部内容,如果觉得本文对您有帮助,不要吝啬点赞在看转发,也欢迎加我微信交流~

本文分享自微信公众号 - hncscwc(gh_383bc7486c1a)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部