ECS: Konfigurowanie Hadoop na ECS z separacją sieci
Summary: Konfigurowanie Hadoop w ECS z separacją sieci.
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
Podsumowanie:
Gdy klaster ECS jest skonfigurowany do separacji sieci w celu podzielenia zarządzania i ruchu danych, węzły Hadoop prawdopodobnie wysyłają ruch na adresy IP "danych".
Podczas konfigurowania uwierzytelniania Kerberos dla Hadoop użytkownicy mogą skonfigurować kartę klucza głównego dla nazwy hosta "mgmt".
Gdy usługa Active Directory (lub LDAP) próbuje uwierzytelnić żądanie, wykonuje odwrotne wyszukiwanie adresu IP węzła ECS w celu potwierdzenia nazwy hosta. To przekazuje adres IP "data" i nie uwierzytelnia się przy użyciu żądanej karty kluczy, ponieważ jest skonfigurowany dla nazwy hosta "mgmt".
Instrukcje:
Aby ustalić, czy ten problem występuje, zapoznaj się z błędem klienta Hadoop i ECS dataheadsvc:
Przykład błędu klienta Hadoop:
ECS dataheadsvc:
Rozwiązanie:
Rozwiązaniem jest użycie polecenia setspn na hoście usługi Active Directory w celu utworzenia aliasu dla podmiotu zabezpieczeń opartego na "mgmt", który uwzględni użytkownika opartego na "danych".
Przykład: ECS ma dwa adresy IP:
10.10.10.1 dla danych i 10.10.10.2 dla zarządzania.
Wyszukiwanie DNS dla adresu IP danych jest ecsdata1.corp.com, a wyszukiwanie DNS dla adresu IP zarządzania jest ecsmgmt1.corp.com.
Nazwa hosta w węźle to "ecsmgmt1.corp.com"
Sprawdź, czy jest poprawny za pomocą polecenia setspn -Q:
Teraz usługa Active Directory uwierzytelnia podmiot zabezpieczeń "vipr/ecsmgmt1.corp.com@CORP.COM", mimo że żądanie pochodzące z węzła Hadoop używało adresu IP "ecsdata1.corp.com".
Gdy klaster ECS jest skonfigurowany do separacji sieci w celu podzielenia zarządzania i ruchu danych, węzły Hadoop prawdopodobnie wysyłają ruch na adresy IP "danych".
Podczas konfigurowania uwierzytelniania Kerberos dla Hadoop użytkownicy mogą skonfigurować kartę klucza głównego dla nazwy hosta "mgmt".
Gdy usługa Active Directory (lub LDAP) próbuje uwierzytelnić żądanie, wykonuje odwrotne wyszukiwanie adresu IP węzła ECS w celu potwierdzenia nazwy hosta. To przekazuje adres IP "data" i nie uwierzytelnia się przy użyciu żądanej karty kluczy, ponieważ jest skonfigurowany dla nazwy hosta "mgmt".
Instrukcje:
Aby ustalić, czy ten problem występuje, zapoznaj się z błędem klienta Hadoop i ECS dataheadsvc:
Przykład błędu klienta 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]
Rozwiązanie:
Rozwiązaniem jest użycie polecenia setspn na hoście usługi Active Directory w celu utworzenia aliasu dla podmiotu zabezpieczeń opartego na "mgmt", który uwzględni użytkownika opartego na "danych".
Przykład: ECS ma dwa adresy IP:
10.10.10.1 dla danych i 10.10.10.2 dla zarządzania.
Wyszukiwanie DNS dla adresu IP danych jest ecsdata1.corp.com, a wyszukiwanie DNS dla adresu IP zarządzania jest ecsmgmt1.corp.com.
Nazwa hosta w węźle to "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
Sprawdź, czy jest poprawny za pomocą polecenia 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
Teraz usługa Active Directory uwierzytelnia podmiot zabezpieczeń "vipr/ecsmgmt1.corp.com@CORP.COM", mimo że żądanie pochodzące z węzła Hadoop używało adresu IP "ecsdata1.corp.com".
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.