Really, for 5 nodes, the master is your SPOF, so unless you plan to use ZK for anything else then it's probably going to be easier/faster to have only 1 ZK server. Collocating ZK and region servers is risky if ZK doesn't have it's own disk, doing it 3 times is 3 times worse :)
Also it may save you a few hours of debugging weird issues. J-D On Thu, Dec 9, 2010 at 1:49 AM, Hari Sreekumar <[email protected]> wrote: > I have master also serving as regionserver. I'll run ZK also on 3 of the > regionservers. I don't have too much data (few TBs only), so I guess it > would be fine? > > > On Thu, Dec 9, 2010 at 12:44 AM, Ted Dunning <[email protected]> wrote: > >> Ahh... that is very much at the other end of the spectrum from what I am >> used to. >> >> Yes. It would not be good to run ZK on a system where the disk is >> essentially unavailable for >> significant amounts of time. >> >> On Wed, Dec 8, 2010 at 10:24 AM, Jean-Daniel Cryans <[email protected] >> >wrote: >> >> > Ted, >> > >> > Sorry, wrong choice of words, HBase will be unreliable. I'm referring >> > to a situation where the session timeout is caused by a very slow >> > quorum because, as I saw it happening before, the datanodes where >> > pegging the disk(s) while being hammered by the region servers. >> > >> > J-D >> > >> > On Wed, Dec 8, 2010 at 10:20 AM, Ted Dunning <[email protected]> >> > wrote: >> > > This is a bit misleading. ZK is always reliable regardless of disk >> > latency. >> > > All that happens on a busy disk is that >> > > you get longer latency for ZK transactions. For a dedicated and >> > > well-configured machine, you can have average >> > > latency (including committing to disk) of about 7 ms. For a >> > multi-purpose >> > > busy machine, you may see latencies >> > > of 300 ms. >> > > >> > > Neither case will cause unreliable operation. >> > > >> > > On Wed, Dec 8, 2010 at 10:14 AM, Jean-Daniel Cryans < >> [email protected] >> > >wrote: >> > > >> > >> Basically, ZK simply needs the lowest latency to disk and network in >> > >> order to work reliably. It's not CPU intensive, and it's only memory >> > >> intensive if you are using tons of znodes (HBase doesn't). >> > >> >> > > >> > >> >
