cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jane Deng (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9386) Ec2MultiRegionSnitch causing internode encryption to always connect on secure port, even when set to 'dc'
Date Fri, 29 Apr 2016 05:04:12 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263548#comment-15263548
] 

Jane Deng edited comment on CASSANDRA-9386 at 4/29/16 5:03 AM:
---------------------------------------------------------------

A customer reported the issue when GPFS was used. The cluster was on AWS multi-region. It
could be reproduced in house on DSE 4.8.6 (C* 2.1.13). 




was (Author: jane.deng@datastax.com):
A customer reported the issue when GPFS is used. The cluster is on AWS multi-region. It could
be reproduced in house on DSE 4.8.6 (C* 2.1.13). 



> Ec2MultiRegionSnitch causing internode encryption to always connect on secure port, even
when set to 'dc'
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9386
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9386
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Blake Eggleston
>            Priority: Minor
>             Fix For: 2.1.x
>
>
> [~csplinter] found a problem the Ec2MultiRegionSnitch is causing with dc internode encryption
with 2.0.x:
> {quote}
> When nodes in the same DC are started on _(DSE)_ 4.6.x _(C* 2.0.x)_ they use private
IPs but start communicating over the ssl_storage_port (7001) instead of the normal storage_port
(7000), despite having internode_encryption set to "dc".
> {quote}
> It looks like the issue was introduced with CASSANDRA-5542. The OTCPool in 2.0.x is now
using the ip address it's attempting to connect to (in our case, the private ip) to determine
if the remote node is in the same dc. Since all of the gossiped state (including dc) is associated
with the node's public ip, it can't find any info for it, and connects to it over the ssl
port.
> I need to do some more investigation, but I think having the ReconnectableSnitchHelper
maintain a map of private->public ips and consulting that before determining dc/rack info
would fix the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message