accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Basit Mustafa (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1585) Provide option for FQDN/verbatim data from config files of servers to be stored in ZooKeeper rather than resolved IP
Date Mon, 22 Jul 2013 18:04:51 GMT

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

Basit Mustafa commented on ACCUMULO-1585:
-----------------------------------------

Keith, I think it solves the (secondary + somewhat related) problem that was raised in the
discussion thread I referenced above about IP changing on machine restart (also quite common
on virtualized machines, almost guaranteed on IaaS providers such as EC2). But, it does not
solve the reachability issue that (at least for me, and in creating this issue, is the primary
problem/goal to fix). 
                
> Provide option for FQDN/verbatim data from config files of servers to be stored in ZooKeeper
rather than resolved IP
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-1585
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1585
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>         Environment: All
>            Reporter: Basit Mustafa
>            Assignee: Eric Newton
>            Priority: Minor
>             Fix For: 1.6.0
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> There are some situations (esp in virtualized/cloud environments) where "hardwiring"
the IP into ZooKeeper can create reachability issues and an FQDN (or, better/also, the verbatim
string/line from the concerned config file) would fix this problem. 
> For example, hostname node1.company.com specified in configuration files resolves to
an Amazon EC2 *internal* IP of 10.2.3.4 (internal on virtualized network). Externally (e.g.
from your dev machine, your offsite/non-VPN/non-VPCed data center, other client machines on
different networks/clouds), node1.company.com will resolve to a public IP (e.g. Amazon Elastic
IP, etc) of something more routeable, like 54.55.56.57. 
> Accumulo currently stores 10.2.3.4 in ZooKeeper based on this resolution, but, if you
try to connect to Accumulo from outside these machines/machines in the same cloud/vitualized
network/non routeable network, and the same FQDN (node1.company.com) resolves to the public
address now (54.55.56.57), you will not be able to connect, because the Accumulo client will
have pulled the resolved, and from here, unreachable, IP of 10.2.3.4.
> Using the FQDN (or in some other way allowing for client-side name resolution/address
translation, although this seems kludgy) would fix this issue in a relatively standard way.
Ideally, this would not incur a performance issue beyond the first resolution assuming the
TCP/IP stack is doing its job and caching stuff effectively (I assume). 
> This doesn't really hurt/break things if you give an option in some config, and, really,
taking the literal from the file allows you to use whatever you want, the ultimate in flexibility.

> See discussion http://mail-archives.apache.org/mod_mbox/accumulo-user/201307.mbox/%3CCAGFNOZTMVz0R2e0meDj%3DKqPPPJP6f5baaMqh8%3D07V7NZ8vToJg%40mail.gmail.com%3E
for more details and others having the same issue. 
> I will look into creating a patch for this as soon as I have some time to find/look at
relevant code portions (I need to find where accumulo is making these writes to ZK and if
the read FQDNs would need any resolution/their use further down the line expects strictly
IP or is in host or IP safe API calls, etc). Any suggestions on where I can begin this are
always appreciated. Otherwise, I'll try and submit a patch when I can. 
> Figure I'd open this issue to at least provide a discussion on what more experienced
Accumulo devs and users think and what a solution based on the style/patterns accepted for
Accumulo development/configuration are. I can read the guidelines myself, of course, and will,
but someone suggested opening an issue, so I am...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message