Thanks for your input! I added an issue for improving the fallback mechanism: https://issues.apache.org/jira/browse/HADOOP-6797
Johannes On May 28, 2010, at 7:46 PM, Michael Segel wrote: > > > >> Date: Fri, 28 May 2010 13:13:56 -0400 >> Subject: Re: DNS.reverseDns() fallback >> From: [email protected] >> To: [email protected] >> CC: [email protected] > [SNIP] >>> IMHO, after looking at this issue, it really doesn't matter since the cloud >>> shouldn't be getting a lot of external traffic except on the name node/job >>> tracker nodes which could be multi-homed. >> >> It might be useful in the case where you're streaming data off of HDFS >> directly to clients rather than in the MR or HBase case. Data import / >> export comes to mind. Remember that clients establish a direct >> connection to data nodes so a multihomed NN is insufficient. In that >> case, "external" doesn't necessarily mean a public (routable) IP, but >> simply another network. We've seen use cases for this in some >> installations. One example is a data aggregation or ingestion network >> is separate from the Hadoop internal network and you'd like to get >> data into HDFS. >> > > Eric, > I don't disagree that it is useful. > > I was just offering up an alternative cloud design which would work as a > work-around. > As you point out, clients need to talk to all of the nodes. > So you can make your name node your gateway for the rest of the cloud. > (not a great idea but it works.) > Or you can launch your jobs from a client or clients, who are multi-homed. > > If you're a Cloudera fan, you could use the cloudera desktop to launch jobs. > So as long as that machine is visible to the cloud, you'll be OK too. ;-) > > I don't really recommend this, but its still a viable solution. > > -Mike > > > > _________________________________________________________________ > Hotmail is redefining busy with tools for the New Busy. Get more from your > inbox. > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
