[
https://issues.apache.org/jira/browse/HADOOP-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049067#comment-14049067
]
Andrew Purtell commented on HADOOP-10768:
-----------------------------------------
bq. Even GSSAPI supports using AES, but without AES-NI support by default, so
the encryption is slow and will become bottleneck.
Java's GSSAPI uses JCE ciphers for crypto support. Would it be possible to
simply swap in an accelerated provider like Diceros?
On the other hand, whether to wrap payloads using the SASL client or server or
not is an application decision. One could wrap the initial payloads with
whatever encryption was negotiated during connection initiation until
completing additional key exchange and negotiation steps, then switch to an
alternate means of applying a symmetric cipher to RPC payloads.
bq. On the other hand, RPC message is small
This is a similar issue we had/have with HBase write ahead log encryption,
because we need to encrypt on a per-entry boundary for avoiding data loss
during recovery, and each entry is small. You might think that small payloads
mean we won't be able to increase throughput with accelerated crypto, and you
would be right, but the accelerated crypto still reduces on CPU time
substantially, with proportional reduction in latency introduced by
cryptographic operations. I think for both the HBase WAL and Hadoop RPC,
latency is a critical consideration.
> Optimize Hadoop RPC encryption performance
> ------------------------------------------
>
> Key: HADOOP-10768
> URL: https://issues.apache.org/jira/browse/HADOOP-10768
> Project: Hadoop Common
> Issue Type: Improvement
> Components: performance, security
> Affects Versions: 3.0.0
> Reporter: Yi Liu
> Assignee: Yi Liu
> Fix For: 3.0.0
>
>
> Hadoop RPC encryption is enabled by setting {{hadoop.rpc.protection}} to
> "privacy". It utilized SASL {{GSSAPI}} and {{DIGEST-MD5}} mechanisms for
> secure authentication and data protection. Even {{GSSAPI}} supports using
> AES, but without AES-NI support by default, so the encryption is slow and
> will become bottleneck.
> After discuss with [~atm], [~tucu00] and [~umamaheswararao], we can do the
> same optimization as in HDFS-6606. Use AES-NI with more than *20x* speedup.
> On the other hand, RPC message is small, but RPC is frequent and there may be
> lots of RPC calls in one connection, we needs to setup benchmark to see real
> improvement and then make a trade-off.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
