Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of dhruba@gmail.com designates
 209.85.211.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=c+i2Xum3RFHBKMkLYEdSiOa5dTu00fbSnUk7hVTo6JEzoqHMZDVt12WjEUmR8U4WPu
         S9+I7hSrClmzteUjOypl0bRaHknBszMWyluweqQIZp2EsQzDPY0CPuWT+JcAKAql0EgR
         y6C4u1mSF/EWougVw+bocFSRedyLq+ZfbD2ak=
MIME-Version: 1.0
In-Reply-To: <7ef0f1a90910210915p6e404c1eq7979c0a969a504a3@mail.gmail.com>
References: <7ef0f1a90910210915p6e404c1eq7979c0a969a504a3@mail.gmail.com>
Date: Wed, 21 Oct 2009 11:22:03 -0700
Message-ID: <4aa34eb70910211122k389f5c6al26e860054b2a45f4@mail.gmail.com>
Subject: Re: Namenode with External Storage?
From: Dhruba Borthakur <dhruba@gmail.com>
To: general@hadoop.apache.org
Content-Type: multipart/alternative; boundary=000e0cd23b2039f2060476760e8b

--000e0cd23b2039f2060476760e8b
Content-Type: text/plain; charset=ISO-8859-1

The namenode uses storage to write file system transaction logs as well as
to write server-debug-log-messages. Both of these could be stored in a NFS
mounted file system, should work well.

thanks,
dhruba


On Wed, Oct 21, 2009 at 9:15 AM, Jonathan Seidman <
jonathan.seidman@gmail.com> wrote:

> Apologies if this has been answered previously, but I'm unable to find
> anything that seems to cover this.
>
> It's clear that datanodes require local storage for Hadoop to function
> efficiently, but is there any significant disadvantage to using external
> storage for namenodes? We're exploring the possibility of using a different
> class of hardware for our namenodes with attached storage and little or no
> internal storage. Some of the benefits this would provide us are: 1)
> allowing our sysadmins to deploy hardware that they're familiar with and
> already have considerable experience keeping up in a production
> environment.
> 2) no namenode downtime to replace a failed disk.
>
> We don't anticipate that this approach would cause any significant
> degradation to performance, but let me know if there's something we're not
> considering.
>
> Thanks.
>
> Jonathan
>


-- 
Connect to me at http://www.facebook.com/dhruba

--000e0cd23b2039f2060476760e8b--