ECS:使用网络分离在 ECS 上配置 Hadoop
Summary: 使用网络分离在 ECS 上配置 Hadoop。
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
摘要:
配置 ECS 群集进行网络分离以分离管理和数据流量时,Hadoop 节点可能会将流量发送到“数据”IP 地址。
为 Hadoop 配置 Kerberos 身份验证时,用户可以为“mgmt”主机名配置主体密钥表。
当 Active Directory(或 LDAP)尝试对请求进行身份验证时,它会对 ECS 节点 IP 地址执行反向查找以确认主机名。这会传递“数据”IP,并且无法使用所需的密钥表进行身份验证,因为它是针对“mgmt”主机名配置的。
指示:
要确定是否存在此问题,请查看 Hadoop 客户端错误和 ECS dataheadsvc:
Hadoop 客户端错误示例:
ECS dataheadsvc:
解决方案:
解决方案是在 Active Directory 主机上使用 setspn 为基于“mgmt”的主体创建别名,以包含基于“data”的用户。
示例:
ECS 有两个 IP 地址:10.10.10.1 用于数据,10.10.10.2 用于管理
ecsdata1.corp.com 数据 IP 的 DNS 查找,ecsmgmt1.corp.com 管理 IP 的 DNS 查找。
节点上的主机名为“ecsmgmt1.corp.com”
使用 setspn -Q 验证它是否正确:
现在,Active Directory 会对“vipr/ecsmgmt1.corp.com@CORP.COM 主体”进行身份验证,即使 Hadoop 节点发起的请求使用的是“ecsdata1.corp.com”IP 地址也是如此。
配置 ECS 群集进行网络分离以分离管理和数据流量时,Hadoop 节点可能会将流量发送到“数据”IP 地址。
为 Hadoop 配置 Kerberos 身份验证时,用户可以为“mgmt”主机名配置主体密钥表。
当 Active Directory(或 LDAP)尝试对请求进行身份验证时,它会对 ECS 节点 IP 地址执行反向查找以确认主机名。这会传递“数据”IP,并且无法使用所需的密钥表进行身份验证,因为它是针对“mgmt”主机名配置的。
指示:
要确定是否存在此问题,请查看 Hadoop 客户端错误和 ECS dataheadsvc:
Hadoop 客户端错误示例:
20/10/12 15:57:27 DEBUG vipr.ClientConnection: Read StatRequestMessage[kind=STAT_REQUEST,namespace=ns-datalake,bucket=ns-datalake-s3-bucket-ifrs17,path=/,hdfsTrustedStatus=HDFS_USER_TRUSTED] from '10.20.46.71' 20/10/12 15:57:27 DEBUG vipr.ClientConnection: The Message request kind from the client is RESPONSE The registered Socket Address is: /10.20.46.71 and port is 9040 20/10/12 15:57:27 DEBUG vipr.ViPRFileSystemClientBase: Generic failure for request: User: hdfs@HDFS.COM (auth:KERBEROS), host: ns-datalake-s3-bucket-ifrs17.ns-datalake.federation1, namespace: ns-datalake, bucket: ns-datalake-s3-bucket-ifrs17 20/10/12 15:57:27 DEBUG vipr.ViPRFileSystemClientBase: Request message sent: StatRequestMessage[kind=STAT_REQUEST,namespace=ns-datalake,bucket=ns-datalake-s3-bucket-ifrs17,path=/,hdfsTrustedStatus=HDFS_USER_TRUSTED] 20/10/12 15:57:27 DEBUG vipr.ViPRFileSystemClientBase: Reply message received: ResponseMessage[kind=RESPONSE,status=ERROR(100)] 20/10/12 15:57:27 DEBUG util.ExceptionHelper: ExceptionHelper l_method checkResponse, l_errstr ERROR_INSUFFICIENT_PERMISSIONS java.lang.Exception: Stack Trace at com.emc.hadoop.fs.vipr.util.ExceptionHelper.throwException(ExceptionHelper.java:110) at com.emc.hadoop.fs.vipr.ViPRFileSystemClientBase.checkResponse(ViPRFileSystemClientBase.java:988) at com.emc.hadoop.fs.vipr.ViPRFileSystemClientBase.sendFileStatusRequest(ViPRFileSystemClientBase.java:1008) at com.emc.hadoop.fs.vipr.ViPRFileSystemClientBase.stat(ViPRFileSystemClientBase.java:654) at com.emc.hadoop.fs.vipr.ViPRFileSystemBase.getFileStatus(ViPRFileSystemBase.java:313) at org.apache.hadoop.fs.Globber.getFileStatus(Globber.java:65) at org.apache.hadoop.fs.Globber.doGlob(Globber.java:294) at org.apache.hadoop.fs.Globber.glob(Globber.java:149) at org.apache.hadoop.fs.FileSystem.globStatus(FileSystem.java:2016) at org.apache.hadoop.fs.shell.PathData.expandAsGlob(PathData.java:353) at org.apache.hadoop.fs.shell.Command.expandArgument(Command.java:250) at org.apache.hadoop.fs.shell.Command.expandArguments(Command.java:233) at org.apache.hadoop.fs.shell.FsCommand.processRawArguments(FsCommand.java:104) at org.apache.hadoop.fs.shell.Command.run(Command.java:177) at org.apache.hadoop.fs.FsShell.run(FsShell.java:328) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90) at org.apache.hadoop.fs.FsShell.main(FsShell.java:391) ls: ViPRFS internal error (ERROR). 20/10/12 15:57:27 DEBUG util.ShutdownHookManager: Completed shutdown in 0.003 seconds; Timeouts: 0 20/10/12 15:57:27 DEBUG util.ShutdownHookManager: ShutdownHookManger completed shutdown.
ECS dataheadsvc:
2020-10-12T08:51:17,178 [pool-103-thread-1] ERROR TokenAuthenticator.java (line 100) Exception in authenticating user javax.security.auth.login.LoginException: Client not found in Kerberos database (6) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:804) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) 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 com.emc.vipr.hdfs.auth.TokenAuthenticator.authenticateClientPrincipal(TokenAuthenticator.java:81) at com.emc.vipr.hdfs.fs.RequestProcessor.getPrincipal(RequestProcessor.java:2200) at com.emc.vipr.hdfs.fs.RequestProcessor.accept(RequestProcessor.java:195) at com.emc.vipr.hdfs.net.ConnectionManager$RequestThread.run(ConnectionManager.java:141) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: KrbException: Client not found in Kerberos database (6) at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:76) at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:316) at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:776) ... 19 more Caused by: KrbException: Identifier doesn't match expected value (906) at sun.security.krb5.internal.KDCRep.init(KDCRep.java:140) at sun.security.krb5.internal.ASRep.init(ASRep.java:64) at sun.security.krb5.internal.ASRep.<init>(ASRep.java:59) at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:60) ... 22 more 2020-10-12T08:51:17,217 [pool-103-thread-1] ERROR RequestProcessor.java (line 2110) Request from 10.20.136.117 : ERROR : StatRequestMessage[kind=STAT_REQUEST,namespace=ns-datalake,bucket=ns-datalake-s3-bucket-ifrs17,path=/,hdfsTrustedStatus=HDFS_USER_TRUSTED]
解决方案:
解决方案是在 Active Directory 主机上使用 setspn 为基于“mgmt”的主体创建别名,以包含基于“data”的用户。
示例:
ECS 有两个 IP 地址:10.10.10.1 用于数据,10.10.10.2 用于管理
ecsdata1.corp.com 数据 IP 的 DNS 查找,ecsmgmt1.corp.com 管理 IP 的 DNS 查找。
节点上的主机名为“ecsmgmt1.corp.com”
setspn -U -S vipr/ecsmgmt1.corp.com ecsdata1.corp.com setspn -U -S vipr/ecsmgmt2.corp.com ecsdata2.corp.com setspn -U -S vipr/ecsmgmt3.corp.com ecsdata3.corp.com setspn -U -S vipr/ecsmgmt4.corp.com ecsdata4.corp.com setspn -U -S vipr/ecsmgmt5.corp.com ecsdata5.corp.com setspn -U -S vipr/ecsmgmt6.corp.com ecsdata6.corp.com
使用 setspn -Q 验证它是否正确:
setspn -Q vipr/ecsmgmt1.corp.com Checking domain DC=atradiusnet,DC=com CN=vipr/gbcdfecsdata1.atradiusnet.com,OU=HDP_DEV,OU=Dedicated,OU=GroupWide,DC=atradiusnet,DC=com vipr/ecsmgmt1.corp.com vipr/ecsdata1.corp.com
现在,Active Directory 会对“vipr/ecsmgmt1.corp.com@CORP.COM 主体”进行身份验证,即使 Hadoop 节点发起的请求使用的是“ecsdata1.corp.com”IP 地址也是如此。
Affected Products
ECS ApplianceProducts
ECS Appliance, ECS Appliance Hardware SeriesArticle Properties
Article Number: 000180919
Article Type: How To
Last Modified: 02 Jul 2025
Version: 5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.