hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <michael_se...@hotmail.com>
Subject RE: decommissioning node woes
Date Sat, 19 Mar 2011 03:30:43 GMT


When you look at the default value... and compare it to DNs having 7+TB of disk space... 
The math doesn't look good.

If you have 1GBe and a good ToR from Cisco, Blade Networks (now IBM), and a couple of others...
they can do it. 
I had a conversation with a switch provider and he indicated that by the end of this year
its realistic to find 10GBe on the motherboard.
Then budget 12K (USD) for the ToR. Depending on the model, you can trunk with 1 or more 10GBe
or they may have a separate module for trunking/uplinks.
(There, prices may be more).

But I digress.

With a 1GBe port, you could go 100Mbs for the bandwidth limit. 
If you bond your ports, you could go higher. 

I guess the point is that many don't realize that they need to up the default limit.



> Date: Fri, 18 Mar 2011 17:57:06 +0000
> From: stevel@apache.org
> To: common-user@hadoop.apache.org
> Subject: Re: decommissioning node woes
> On 18/03/11 17:34, Ted Dunning wrote:
> > I like to keep that rather high.  If I am decommissioning nodes, I generally
> > want them out of the cluster NOW.
> Depends on your backbone B/W I guess. And how well the switches really 
> work vs claim to work.
> One thought here, does the decommissioning give priority to blocks that 
> are only replicated on the machine(s) being decommissioned. If not, it's 
> something to consider prioritising.
> >
> > That is probably a personality defect on my part.
> >
> > On Fri, Mar 18, 2011 at 9:59 AM, Michael Segel<michael_segel@hotmail.com>wrote:
> >
> >> Once you see those blocks successfully replicated... you can take down the
> >> next.
> >>
> >> Is it clean? No, not really.
> >> Is it dangerous? No, not really.
> >> Do I recommend it? No, but its a quick and dirty way of doing things...
> >>
> >> Or you can up your dfs.balance.bandwidthPerSecIn the configuration files.
> >> The default is pretty low.
> >>
> >> The downside is that you have to bounce the cloud to get this value
> >> updated, and it could have a negative impact on performance if set too high.
> >>
> >
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message