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 位址的反向查詢,以確認主機名稱。這會傳遞「data」IP,且無法使用想要的金鑰表進行驗證,因為這是為「mgmt」主機名稱設定的。
指示:
若要判斷是否有此問題,請檢閱 Hadoop 用戶端錯誤和 ECS dataheadsvc:
Hadoop 用戶端錯誤範例:
ECS dataheadsvc:
解決方案:
解決方案是在 Active Directory 主機上使用 setspn 為以「mgmt」為基礎的主體建立別名,以包含以「資料」為基礎的使用者。
範例:
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 位址的反向查詢,以確認主機名稱。這會傳遞「data」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」為基礎的主體建立別名,以包含以「資料」為基礎的使用者。
範例:
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.