ECS: Konfigurieren von Hadoop auf ECS mit Netzwerktrennung
Summary: Konfigurieren von Hadoop auf ECS mit Netzwerktrennung.
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
Zusammenfassung:
Wenn ein ECS-Cluster für die Netzwerktrennung konfiguriert ist, um den Management- und Datenverkehr aufzuteilen, senden Hadoop-Nodes wahrscheinlich Datenverkehr an die "Daten"-IP-Adressen.
Bei der Konfiguration der Kerberos-Authentifizierung für Hadoop können Nutzer die Prinzipal-Keytab für den Hostnamen "mgmt" konfigurieren.
Wenn Active Directory (oder LDAP) versucht, die Anforderung zu authentifizieren, führt es eine Rückwärtssuche nach der ECS-Node-IP-Adresse durch, um den Hostnamen zu bestätigen. Dadurch wird die IP "data" übergeben und die Authentifizierung mit der gewünschten Keytab-Datei ist fehlgeschlagen, da sie für den Hostnamen "mgmt" konfiguriert ist.
Anweisungen:
Um festzustellen, ob dieses Problem vorliegt, überprüfen Sie den Hadoop-Clientfehler und ECS dataheadsvc:
Beispiel für Hadoop-Clientfehler:
ECS dataheadsvc:
Lösung:
Die Lösung besteht darin, setspn auf dem Active Directory-Host zu verwenden, um einen Alias für den auf "management" basierenden Prinzipal zu erstellen, der den "datenbasierten" Nutzer einschließt.
Beispiel: ECS verfügt über zwei IP-Adressen:
10.10.10.1 für Daten und 10.10.10.2 für mgmt.
Die DNS-Suche nach der Daten-IP ist ecsdata1.corp.com und die DNS-Suche nach der Management-IP ist ecsmgmt1.corp.com.
Der Hostname auf dem Node lautet "ecsmgmt1.corp.com".
Überprüfen Sie mit setspn -Q, ob er korrekt ist:
Jetzt authentifiziert Active Directory den "vipr/ecsmgmt1.corp.com@CORP.COM-Prinzipal", obwohl die vom Hadoop-Node stammende Anforderung die IP-Adresse "ecsdata1.corp.com" verwendet hat.
Wenn ein ECS-Cluster für die Netzwerktrennung konfiguriert ist, um den Management- und Datenverkehr aufzuteilen, senden Hadoop-Nodes wahrscheinlich Datenverkehr an die "Daten"-IP-Adressen.
Bei der Konfiguration der Kerberos-Authentifizierung für Hadoop können Nutzer die Prinzipal-Keytab für den Hostnamen "mgmt" konfigurieren.
Wenn Active Directory (oder LDAP) versucht, die Anforderung zu authentifizieren, führt es eine Rückwärtssuche nach der ECS-Node-IP-Adresse durch, um den Hostnamen zu bestätigen. Dadurch wird die IP "data" übergeben und die Authentifizierung mit der gewünschten Keytab-Datei ist fehlgeschlagen, da sie für den Hostnamen "mgmt" konfiguriert ist.
Anweisungen:
Um festzustellen, ob dieses Problem vorliegt, überprüfen Sie den Hadoop-Clientfehler und ECS dataheadsvc:
Beispiel für Hadoop-Clientfehler:
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]
Lösung:
Die Lösung besteht darin, setspn auf dem Active Directory-Host zu verwenden, um einen Alias für den auf "management" basierenden Prinzipal zu erstellen, der den "datenbasierten" Nutzer einschließt.
Beispiel: ECS verfügt über zwei IP-Adressen:
10.10.10.1 für Daten und 10.10.10.2 für mgmt.
Die DNS-Suche nach der Daten-IP ist ecsdata1.corp.com und die DNS-Suche nach der Management-IP ist ecsmgmt1.corp.com.
Der Hostname auf dem Node lautet "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
Überprüfen Sie mit setspn -Q, ob er korrekt ist:
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
Jetzt authentifiziert Active Directory den "vipr/ecsmgmt1.corp.com@CORP.COM-Prinzipal", obwohl die vom Hadoop-Node stammende Anforderung die IP-Adresse "ecsdata1.corp.com" verwendet hat.
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.