cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7431) Hadoop integration does not perform reverse DNS lookup correctly on EC2
Date Sun, 22 Jun 2014 19:33:24 GMT

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

Paulo Motta commented on CASSANDRA-7431:
----------------------------------------

I guess Hadoop's InputSplit.getLocations() method (implemented by ColumnFamilySplit) expects
a list of hostnames to be able to schedule local tasks, since task trackers are identified
by hostnames, not IPs.

Using only private IPs in Hadoop is not feasible because you may want to access task tracker
WEB interfaces from outside EC2, so it's handy to use EC2 public DNS (ec2-*.compute-1.amazonaws.com)
to identify hadoop trackers, since this DNS is resolved internally to private IPs and externally
to public IPs.

Another issue when the C* cluster uses public IPs as broadcast_address (such as with the EC2MultiRegionSnitch),
is that Hadoop tasks will access ColumnFamilySplits of non-local tasks via the public IP,
which costs $0.01 per GB. If the ColumnFamilySplit's locations are EC2 hostnames instead (ec2-*.compute-1.amazonaws.com),
then that will be internally resolved by Amazon to the private IP, lowering transfer costs
for non-local tasks.

> Hadoop integration does not perform reverse DNS lookup correctly on EC2
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-7431
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7431
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Hadoop
>            Reporter: Paulo Motta
>            Assignee: Paulo Motta
>
> The split assignment on AbstractColumnFamilyInputFormat:247 peforms a reverse DNS lookup
of Cassandra IPs in order to preserve locality in Hadoop (task trackers are identified by
hostnames).
> However, the reverse lookup of an EC2 IP does not yield the EC2 hostname of that endpoint
when running from an EC2 instance due to the use of InetAddress.getHostname().
> In order to show this, consider the following piece of code:
> {code:title=DnsResolver.java|borderStyle=solid}
> public class DnsResolver {
>     public static void main(String[] args) throws Exception {
>         InetAddress namenodePublicAddress = InetAddress.getByName(args[0]);
>         System.out.println("getHostAddress: " + namenodePublicAddress.getHostAddress());
>         System.out.println("getHostName: " + namenodePublicAddress.getHostName());
>     }
> }
> {code}
> When this code is run from my machine to perform reverse lookup of an EC2 IP, the output
is:
> {code:none}
> ➜  java DnsResolver 54.201.254.99
> getHostAddress: 54.201.254.99
> getHostName: ec2-54-201-254-99.compute-1.amazonaws.com
> {code}
> When this code is executed from inside an EC2 machine, the output is:
> {code:none}
> ➜  java DnsResolver 54.201.254.99
> getHostAddress: 54.201.254.99
> getHostName: 54.201.254.99
> {code}
> However, when using linux tools such as "host" or "dig", the EC2 hostname is properly
resolved from the EC2 instance, so there's some problem with Java's InetAddress.getHostname()
and EC2.
> Two consequences of this bug during AbstractColumnFamilyInputFormat split definition
are:
> 1) If the Hadoop cluster is configured to use EC2 public DNS, the locality will be lost,
because Hadoop will try to match the CFIF split location (public IP) with the task tracker
location (public DNS), so no matches will be found.
> 2) If the Cassandra nodes' broadcast_address is set to public IPs, all hadoop communication
will be done via the public IP, what will incurr additional transference charges. If the public
IP is mapped to the EC2 DNS during split definition, when the task is executed, ColumnFamilyRecordReader
will resolve the public DNS to the private IP of the instance, so there will be not additional
charges.
> A similar bug was filed in the WHIRR project: 
> https://issues.apache.org/jira/browse/WHIRR-128



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message