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
[Summary]:
管理トラフィックとデータ トラフィックを分離するためにECSクラスターがネットワーク分離されるように構成されている場合、Hadoopノードは「データ」IPアドレスにトラフィックを送信する可能性が高くなります。
HadoopのKerberos認証を構成する場合、ユーザーは「mgmt」ホスト名のプリンシパル キータブを構成できます。
Active Directory(またはLDAP)は、リクエストの認証を試みる際に、ECSノードのIPアドレスの逆引き参照を実行してホスト名を確認します。これは「data」IPを渡し、「mgmt」ホスト名用に構成されているため、目的のkeytabを使用した認証に失敗します。
指示:
この問題が存在するかどうかを判断するには、Hadoopクライアント エラーとECS dataheadsvc:
Hadoopクライアント エラーの例:
ECS dataheadsvc:
解決策:
解決策は、Active Directoryホストで setspnを使用して、「mgmt」ベースのプリンシパルのエイリアスを作成し、「data」ベースのユーザーを含めることです。
例:
ECSには次の2つのIPアドレスがあります。データは10.10.10.1、管理は10.10.10.2です。
データIPのDNSルックアップは ecsdata1.corp.com で、管理IPのDNSルックアップは ecsmgmt1.corp.com です。
ノードのホスト名は「ecsmgmt1.corp.com」です
setspn -Qを使用して正しいことを確認します。
現在、Active Directoryは、Hadoopノードによって発信されたリクエストが「ecsdata1.corp.com」IPアドレスを使用していた場合でも、「vipr/ecsmgmt1.corp.com@CORP.COM プリンシパル」を認証します。
管理トラフィックとデータ トラフィックを分離するためにECSクラスターがネットワーク分離されるように構成されている場合、Hadoopノードは「データ」IPアドレスにトラフィックを送信する可能性が高くなります。
HadoopのKerberos認証を構成する場合、ユーザーは「mgmt」ホスト名のプリンシパル キータブを構成できます。
Active Directory(またはLDAP)は、リクエストの認証を試みる際に、ECSノードのIPアドレスの逆引き参照を実行してホスト名を確認します。これは「data」IPを渡し、「mgmt」ホスト名用に構成されているため、目的のkeytabを使用した認証に失敗します。
指示:
この問題が存在するかどうかを判断するには、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には次の2つのIPアドレスがあります。データは10.10.10.1、管理は10.10.10.2です。
データIPのDNSルックアップは ecsdata1.corp.com で、管理IPのDNSルックアップは ecsmgmt1.corp.com です。
ノードのホスト名は「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は、Hadoopノードによって発信されたリクエストが「ecsdata1.corp.com」IPアドレスを使用していた場合でも、「vipr/ecsmgmt1.corp.com@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.