[
https://issues.apache.org/jira/browse/HADOOP-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893027#comment-15893027
]
Yongjun Zhang commented on HADOOP-14104:
----------------------------------------
Discussed with [~jojochuang] and [~jzhuge], we looked at the code together and
saw KMS provider already support multiple key provider servers in its
configuration, for example:
{code}
<property>
<name>hadoop.security.key.provider.path</name>
<value>kms://[email protected];kms02.example.com:16000/kms</value>
</property>
{code}
and
{code}
* If multiple hosts are provider, the Factory will create a
* {@link LoadBalancingKMSClientProvider} that round-robins requests
* across the provided list of hosts.
{code}
This is a form of KeyProvider HA handling (also handles load balancing).
[~andrew.wang],
{quote}
I like that getServerDefaults is lock-free, but I'm still worried about the
overhead. MR tasks are short lived and thus don't benefit from the caching.
This also affects all clients, on both encrypted and unencrypted clusters. I
think getServerDefault is also currently only called when SASL is enabled. Have
you done any performance testing of this RPC?
{quote}
getServerDefaults mechanism has been there and the patch here just included an
additional field. Calling it once an hour should not be a problem to me, at
least not a regression. It's just that if things changed within the hour, the
errors may not be handled correctly (for example, all old key provider hosts
are replaced with new ones), but it's less of a concern assuming that's rare. I
don't see that sasl is checked when getServerDefaults is called.
Thanks.
> Client should always ask namenode for kms provider path.
> --------------------------------------------------------
>
> Key: HADOOP-14104
> URL: https://issues.apache.org/jira/browse/HADOOP-14104
> Project: Hadoop Common
> Issue Type: Improvement
> Components: kms
> Reporter: Rushabh S Shah
> Assignee: Rushabh S Shah
> Attachments: HADOOP-14104-trunk.patch, HADOOP-14104-trunk-v1.patch
>
>
> According to current implementation of kms provider in client conf, there can
> only be one kms.
> In multi-cluster environment, if a client is reading encrypted data from
> multiple clusters it will only get kms token for local cluster.
> Not sure whether the target version is correct or not.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
