ECS: Configuración de Hadoop en ECS con separación de red
Summary: Configuración de Hadoop en ECS con separación de red.
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
Resumen:
Cuando un clúster de ECS está configurado para la separación de la red a fin de dividir la administración y el tráfico de datos, es probable que los nodos de Hadoop envíen tráfico a las direcciones
IP de "datos".Al configurar la autenticación Kerberos para Hadoop, los usuarios pueden configurar keytab principal para el nombre de host "mgmt".
Cuando Active Directory (o LDAP) intenta autenticar la solicitud, realiza una búsqueda inversa de la dirección IP del nodo de ECS para confirmar el nombre de host. Esto pasa la IP de "datos" y no se puede autenticar mediante el keytab deseado, ya que está configurado para el nombre de host "mgmt".
Instrucciones:
Para determinar si este problema está presente, revise el error del cliente de Hadoop y el dataheadsvc de ECS:
Ejemplo de error de cliente Hadoop:
Servicio de cabeza de datos de ECS:
Solución:
La solución es usar setspn en el host de Active Directory a fin de crear un alias para la entidad de seguridad basada en "mgmt" a fin de incluir al usuario basado en "datos".
Ejemplo: ECS tiene dos direcciones IP:
10.10.10.1 para datos y 10.10.10.2 para administración
La búsqueda de DNS para IP de datos es ecsdata1.corp.com y la búsqueda de DNS para IP de administración es ecsmgmt1.corp.com.
El nombre de host en el nodo es "ecsmgmt1.corp.com"
Verifique que sea correcto con setspn -Q:
Active Directory autentica la entidad de seguridad "vipr/ecsmgmt1.corp.com@CORP.COM, a pesar de que la solicitud originada por el nodo de Hadoop usaba la dirección IP "ecsdata1.corp.com".
Cuando un clúster de ECS está configurado para la separación de la red a fin de dividir la administración y el tráfico de datos, es probable que los nodos de Hadoop envíen tráfico a las direcciones
IP de "datos".Al configurar la autenticación Kerberos para Hadoop, los usuarios pueden configurar keytab principal para el nombre de host "mgmt".
Cuando Active Directory (o LDAP) intenta autenticar la solicitud, realiza una búsqueda inversa de la dirección IP del nodo de ECS para confirmar el nombre de host. Esto pasa la IP de "datos" y no se puede autenticar mediante el keytab deseado, ya que está configurado para el nombre de host "mgmt".
Instrucciones:
Para determinar si este problema está presente, revise el error del cliente de Hadoop y el dataheadsvc de ECS:
Ejemplo de error de cliente 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.
Servicio de cabeza de datos de ECS:
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]
Solución:
La solución es usar setspn en el host de Active Directory a fin de crear un alias para la entidad de seguridad basada en "mgmt" a fin de incluir al usuario basado en "datos".
Ejemplo: ECS tiene dos direcciones IP:
10.10.10.1 para datos y 10.10.10.2 para administración
La búsqueda de DNS para IP de datos es ecsdata1.corp.com y la búsqueda de DNS para IP de administración es ecsmgmt1.corp.com.
El nombre de host en el nodo es "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
Verifique que sea correcto con 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 autentica la entidad de seguridad "vipr/ecsmgmt1.corp.com@CORP.COM, a pesar de que la solicitud originada por el nodo de Hadoop usaba la dirección 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.