[
https://issues.apache.org/jira/browse/HDFS-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680758#comment-16680758
]
Chen Liang commented on HDFS-14017:
-----------------------------------
The URI here is passed from
{{NameNodeProxiesClient#createFailoverProxyProvider}} which can be further
traced up to from places such as DFSClient. Which, most of time, is likely
gonna be the URI from fs.defaultFS. That's all I meant to say... The original
statement was just mentioning a potential way to leverage. This was not meant
to be an absolute judgement, and yes, it can be reconfigured to other address
passed in. Sorry for the miscommunication. But still, whatever the URI is, the
URI is passed to the IPFailover failover proxy, to serve as the address for
failover proxy address. In current patch, the only place that actually really
uses {{fs.defaultFS}} is one place, which is getNameServiceAddress
(DFSUtilClient.getAddresses call) so that when it failed to find any configured
physical addresses, it took the defaultFS as the last hope. I also considered
maybe this is probably an error case, but I think both ways can be argued. This
is also why changing fs.defaultFS client still works, because the difference
only in failover.
I agree that current approach is not ideal and absolutely agree with {{only
NameNodes that are relevant to this specific nameservice ID}}. This is only
temporary and still with TODOs. I have been trying to make this point the whole
time... When there is only one nameservice ID, no other choice anyway. But when
there are multiple nameservices, the question here is not we need to find the
right NNs of a given nameservice, how do we even determine *which nameservice*
to look up. I don't think we have a full picture about supporting federation
yet, there are known places that need to be revisited as well e.g. how does
ViewFS work here. I can think of ways but that would be a separate JIRA. So
even we support multiple nameservices here, it's not adding any value and
likely is subject to changes in future. The purpose here is not to get it
perfect, but only as a current temporary solution with target of supporting one
nameservice only. I did have considered locating the right NameNodes since the
beginning (that's why the TODO has been there since first patch). It was just
it is not yet clear how that should happen without a full picture of
interaction with Federation at all. When we sort it out, we surely should come
back and revisit this.
> 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,
> HDFS-14017-HDFS-12943.006.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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
