hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen Liang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-14017) ObserverReadProxyProviderWithIPFailover should work with HA configuration
Date Wed, 07 Nov 2018 19:22:00 GMT

    [ https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678668#comment-16678668

Chen Liang commented on HDFS-14017:

Hmm...I don't see it does not work, as long as both nn1 and nn2 shows up in {{dfs.namenode.rpc-address.\*.\*}}
configs, there will be two proxies created, and client should be able to find them. I did
a quick in the test cluster, seem to worked, although it was checking from command line and
won't tell about DT.

I agree that with all the {{dfs.namenode.rpc-address}} configs we have all information. In
fact, in current patch, the call to {{DFSUtilClient.getAddresses(...)}} is already getting
ALL the host physical addresses for ALL the nameservices. All these addresses will have proxies
created and DT cloned. The issue I had was that, it may not be true that all these addresses
should be considered (and clone DT for) in case of federation. Probably should be based on
different {{fs.defaultFS}}, which is what IPFailover is largely relying on, maybe only a subset
should be checked. This is what I meant by the need to tie fs.defaultFS to some name service/physical
address. And this, needs to be answered under the context of how IPFailover should work with

> ObserverReadProxyProviderWithIPFailover should work with HA configuration
> -------------------------------------------------------------------------
>                 Key: HDFS-14017
>                 URL: https://issues.apache.org/jira/browse/HDFS-14017
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>            Reporter: Chen Liang
>            Assignee: Chen Liang
>            Priority: Major
>         Attachments: HDFS-14017-HDFS-12943.001.patch, HDFS-14017-HDFS-12943.002.patch,
HDFS-14017-HDFS-12943.003.patch, HDFS-14017-HDFS-12943.004.patch, HDFS-14017-HDFS-12943.005.patch
> Currently {{ObserverReadProxyProviderWithIPFailover}} extends {{ObserverReadProxyProvider}},
and the only difference is changing the proxy factory to use {{IPFailoverProxyProvider}}.
However this is not enough because when calling constructor of {{ObserverReadProxyProvider}}
in super(...), the follow line:
> {code:java}
> nameNodeProxies = getProxyAddresses(uri,
>         HdfsClientConfigKeys.DFS_NAMENODE_RPC_ADDRESS_KEY);
> {code}
> will try to resolve the all configured NN addresses to do configured failover. But in
the case of IPFailover, this does not really apply.
> A second issue closely related is about delegation token. For example, in current IPFailover
setup, say we have a virtual host nn.xyz.com, which points to either of two physical nodes
nn1.xyz.com or nn2.xyz.com. In current HDFS, there is always only one DT being exchanged,
which has hostname nn.xyz.com. Server only issues this DT, and client only knows the host
nn.xyz.com, so all is good. But in Observer read, even with IPFailover, the client will no
longer contacting nn.xyz.com, but will actively reaching to nn1.xyz.com and nn2.xyz.com.
During this process, current code will look for DT associated with hostname nn1.xyz.com or nn2.xyz.com,
which is different from the DT given by NN. causing Token authentication to fail. This happens
in {{AbstractDelegationTokenSelector#selectToken}}. New IPFailover proxy provider will need
to resolve this as well.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org

View raw message